Photo by Bob Jenkin on Unsplash

Checking Kubernetes Security Drift

Against the Current

When you run multiple Kubernetes (K8s) clusters (e.g., production, staging, disaster recovery), you expect them to enforce the same security controls. But do they? Emergency fixes, temporary permission grants, and one-off exceptions slowly cause clusters to diverge. Driftwatch is a lightweight, open source command-line interface (CLI) tool that catches these security discrepancies before they lead to incidents or audit failures.

Security Drift in Multicluster Environments

Consider a scenario where a deployment issue arises on a Friday afternoon. A service account is granted elevated permissions as a quick fix, but those permissions are never revoked. Meanwhile, in another cluster, a developer modifies a NetworkPolicy to resolve a connectivity issue and forgets to revert the change. These seemingly minor actions accumulate over time – a phenomenon known as security drift – leaving clusters in a less secure state than intended [1].

Most tools look at each cluster separately. They check whether a cluster is following practices, but they do not check whether your production and disaster recovery clusters have the same security controls. That's where Driftwatch comes in.

Driftwatch

Instead of comparing static configuration files, Driftwatch evaluates how clusters behave across three areas:

• Role-based access control (RBAC) authorization: Check the permissions that each user or service account has and compare them across clusters.
• NetworkPolicy segmentation: Examine the NetworkPolicies in each cluster and check whether they allow the same traffic [2].
• Namespace-level Pod Security Admission (PSA): Inspect the security labels applied to each namespace and flag any differences between