Drift Detection for Kubernetes: The Missing Link in Secure GitOps

Drift Detection for Kubernetes: The Missing Link in Secure GitOps What is Drift Detection? Implications for Security Why Drift Detection Matters — Even with GitOps Customer Use Case: Detecting Unauthorized RBAC Drift Policy-as-Code to the Rescue Example Policy: Detect Unauthorized Changes to ClusterRoles and ClusterRoleBindings How It Works Testing the Policy Beyond RBAC: Other Drift Detection Possibilities Summary Next Steps Modern Kubernetes environments are meant to be declarative — what you define in Git is what should be running in production. But in reality, things drift. Resources change without review, permissions are updated manually, or configuration baselines diverge. This phenomenon — known as configuration drift — silently erodes the reliability and security of even the most well-engineered platforms. In this post, we’ll explore what drift detection means for Kubernetes, why it’s critical even in GitOps workflows, and how Policy-as-Code can help teams prevent and detect it automatically. Drift detection is the process of identifying when the actual state of a Kubernetes resource deviates from its declared or desired state. Drift can occur in many ways: A user manually edits a resource ( kubectl edit/apply ) outside of GitOps workflows. An automated tool or controller changes a setting unexpectedly. A misconfigured Helm or CI/CD pipeline overwrites values. When drift occurs, your clusters may no longer match compliance, security, or operational expectations — and those changes often go unnoticed until an incident occurs. Uncontrolled drift can create shadow configurations — resources that bypass review and violate security policies. For example: An altered ClusterRole granting unintended privileges.