The core problem, as described by Varonis, lies in the architecture of GitOps controllers like KCC. These controllers are designed to remove the need for individual developers to possess cloud credentials. Instead, developers submit YAML configuration files to a shared Git repository. A controller running inside a Kubernetes cluster reads those files and creates or updates cloud resources on the developers' behalf.
The advantage is clear: developers have no access to cloud credentials, and the platform team manages only a single service account. This solves the problem of "secret sprawl," where dozens of credentials leak through copied files, Git repositories, and forgotten laptops.
However, Varonis points out that this solution concentrates all the power in one place. To manage infrastructure across multiple projects, folders, or an entire organization, the KCC service account is often granted broad, organization-level roles such as roles/owner or roles/resourcemanager.organizationAdmin.
A developer who submits a simple YAML file declaring an IAMPolicyMember resource can, through the controller, grant any permission to any account. For instance, a request to grant a service account the roles/storage.objectViewer role on a project looks innocent enough. But because KCC authenticates with organization-level privileges, a compromised controller or a malformed YAML file could be used to escalate privileges and take over the entire cloud organization.
"Every namespace shares KCC's single organization-level identity," Varonis notes in its analysis, highlighting how a compromise of the single Kubernetes interface could be catastrophic.