RBAC as Code

RBAC in version control.

Git

RBAC drift is one of the largest sources of insider-risk incidents. Roles get added in the UI for a one-time need and never removed. Bindings accumulate across years of org changes. The map of "who can do what" lives in nobody's head and matches reality only by accident. The fix is RBAC as code: every role definition and every role binding lives in version control.

What RBAC as code actually requires:

• Roles in git.: Every role definition (the set of permissions that role grants) is stored as a YAML or JSON file in a version-controlled repository. Adding a permission to a role is a code change with a PR; removing one is the same. The role definitions are themselves reviewable artifacts.
• Bindings in git.: Every assignment of a role to a user, group, or service account is recorded in source control. The file lists who has which role in which scope. Granting access to a new engineer is a PR; revoking access is a PR.
• Reviewed via PR process.: Role and binding changes go through code review like any other change. Reviewers check whether the requested permission is appropriate, whether the binding scope is correct, whether the change matches the team's documented access policies.
• Deployable via automation.: The git state is the source of truth; the actual platform configuration (Kubernetes RBAC, AWS IAM, GCP IAM, application-level RBAC) is reconciled to match. A merged PR triggers the apply. No manual sync.
• Drift detection.: A continuous process compares the actual platform state to the git state. Anything that diverged points to either out-of-band changes (someone clicked in the console) or config that was not applied. Both warrant investigation.

RBAC as code replaces the implicit, console-driven, drift-prone model with an explicit, reviewable, source-of-truth model. The investment is the migration; the payoff is permanent visibility into who has access to what.

CI

The CI pipeline is the mechanism that turns the git state into actual platform configuration. The pipeline reads the role and binding definitions, validates them, and applies them to the target platforms. The discipline is making sure no other path can change RBAC.

• RBAC changes deployed via CI.: The pipeline takes the merged role and binding definitions and applies them to the live platforms. Changes flow through the pipeline; the pipeline is the only path that should be able to modify production RBAC.
• No manual UI changes.: Direct edits in the AWS console, the GCP console, or Kubernetes via kubectl edit are forbidden. The drift detector catches them; the policy treats them as security incidents. The discipline is what keeps git as the source of truth.
• Pipeline applies validation first.: Before applying, the pipeline runs validation: the YAML parses correctly, the referenced roles exist, the principals are valid identities, no role has more permissions than the policy allows. Invalid changes fail the pipeline and the bad config never reaches production.
• Apply requires special credentials.: The pipeline uses elevated credentials to apply RBAC changes. Those credentials are scoped to RBAC operations only and rotated frequently. The blast radius if the pipeline is compromised is the RBAC plane, not the broader infrastructure.
• Per-environment policy.: Different environments may have different policy levels. Dev RBAC might be looser, prod tighter. The pipeline applies the right scope to the right environment based on the declared target. Mistakes here are the kind that produce serious incidents, so the configuration is itself reviewed.

The CI path is the operational control that keeps RBAC manageable. Without it, the git state is just documentation; with it, git is the actual source of truth and the platforms reconcile to match.

Audit trail

The third leg of RBAC as code is the audit trail. Every RBAC change is now a commit, with an author, a timestamp, a reviewer, a reason. The audit story that compliance teams previously had to construct from disparate sources (AWS CloudTrail, console actions, screenshots from manual reviews) lives in one queryable place: git.

• Git history is the audit trail.: Who got access to what, when, who approved it, why. All in the git log of the RBAC repository. The audit trail extends backward to the start of the practice and forward indefinitely.
• Compliance-friendly.: SOC 2, ISO 27001, PCI DSS, HIPAA all require evidence of access management: who has access, who approved it, when access was granted and revoked. The git history of the RBAC repo is the literal answer to the controls. Auditors verify the process; the artifacts are sitting right there.
• Easy queries.: "Who currently has admin access to the prod database?" is a grep against the bindings file. "When did Sarah's access change?" is a git log on the file that mentions her identity. The questions security and compliance teams ask routinely become 30-second queries instead of multi-hour investigations.
• Quarterly access review.: Most compliance frameworks require periodic access review. With RBAC as code, the review is structured: pull a list of all bindings, send to managers for confirmation, capture the approvals. The review report is the diff of the bindings file before and after. Mechanical, repeatable, defensible.
• Forensic ready.: When a security incident requires reconstructing who could have done what at the time of the incident, the git history is the foundation. Check out the RBAC repo at the timestamp of the incident; you have the exact access state. No reconstruction; no guessing.

RBAC as code with git, CI-driven apply, and git history as audit log is the access management architecture pattern that scales from a five-person team to a five-thousand-person organization. Nova AI Ops integrates with RBAC repos, runs drift detection between git state and platform reality, and surfaces the access pattern across the org so security teams have visibility without having to chase down each platform's access reports separately.