Kubernetes Identity Manifest Management

Kubernetes Identity Manifest Management is the practice of defining and maintaining the YAML manifests that represent identity and access objects — ServiceAccount, Role, ClusterRole, RoleBinding, and ClusterRoleBinding — as version-controlled, declarative artifacts rather than as state created and modified through imperative kubectl commands. Treating identity configuration as manifests brings the same review, history, and reproducibility benefits to access control that infrastructure-as-code brings to the rest of a cluster's configuration.

Structuring Identity Manifests

Grouping Related Objects

A common convention places a workload's ServiceAccount, its Role, and its RoleBinding in a single manifest or a small set of co-located files alongside the workload's own Deployment manifest, so that the identity a workload runs as and the permissions it holds are reviewed and deployed together rather than managed in a separate, disconnected process.

apiVersion: v1
kind: ServiceAccount
metadata:
  name: billing-worker
  namespace: payments
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: payments
  name: billing-worker-role
rules:
- apiGroups: [""]
  resources: ["configmaps"]
  verbs: ["get", "list", "watch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  namespace: payments
  name: billing-worker-binding
subjects:
- kind: ServiceAccount
  name: billing-worker
  namespace: payments
roleRef:
  kind: Role
  name: billing-worker-role
  apiGroup: rbac.authorization.k8s.io

Separating Cluster-Scoped Manifests

Because ClusterRole and ClusterRoleBinding objects carry cluster-wide consequence, keeping them in a distinct directory or repository from namespaced identity manifests, with a narrower set of approvers, mirrors the tighter governance those objects warrant compared to ordinary namespace-scoped identity configuration.

Managing Change Through Version Control

Pull-Request Review as Access Governance

Requiring every identity manifest change to go through the same pull-request review process as application code turns access changes into reviewable, discussable proposals with a durable record of who requested the change, who approved it, and why — a substantial improvement over untracked kubectl create rolebinding commands run interactively against a live cluster.

Diffing Permission Changes

Because RBAC manifests are declarative, a pull request diff shows precisely which verbs, resources, or subjects were added or removed, making it straightforward for a reviewer to spot an unexpectedly broad grant (a new wildcard verb, an unexpected cluster-admin reference) before it is ever applied to the cluster.

Applying and Synchronizing Manifests

GitOps-Driven Reconciliation

Tools that continuously reconcile a cluster's live state against a Git repository extend naturally to identity manifests, automatically detecting and correcting drift if someone modifies a Role or binding directly against the cluster outside the declared manifests, keeping the manifests as the single source of truth.

kubectl apply -f identity/payments/ --prune -l app.kubernetes.io/managed-by=gitops

Templating for Repeated Patterns

Organizations that provision similar identity structures repeatedly — one service account and role per microservice, for example — often template the manifest generation itself, ensuring every workload's identity configuration follows the same least-privilege pattern rather than being authored freely each time with inconsistent scoping.

Validating Manifests Before Deployment

Schema and Policy Validation

Running identity manifests through schema validation and policy-as-code checks in a CI pipeline — flagging wildcard rules, missing namespace fields on service account subjects, or bindings to cluster-admin — catches structural and policy problems before the manifest ever reaches kubectl apply.

kubectl apply --dry-run=server -f identity/payments/role.yaml

Testing Against Intended Effect

Beyond schema validation, verifying that an applied manifest grants exactly the intended permissions — using kubectl auth can-i --as against the resulting service account — confirms the manifest's actual authorization outcome, not merely its syntactic correctness.

Lifecycle and Cleanup

Manifests as the Source for Deletion

Removing a workload's identity manifests from the source repository and letting the reconciliation process delete the corresponding cluster objects avoids the common failure mode where a workload is decommissioned but its service account, role, and bindings are left behind, quietly retaining access indefinitely.