Security had been compromised, and the cause was clear: a misconfigured Helm chart left the door wide open for privilege escalation.
Privilege escalation in Kubernetes happens when a container gains permissions it should never have. With Helm chart deployments, the danger often hides in values files, RoleBindings, or improperly scoped service accounts. A single runAsUser: 0 or an unconfined securityContext can give an attacker root access to the node.
When deploying with Helm, every chart value touching security must be audited. Review the securityContext for pods and containers. Confirm runAsNonRoot: true, drop all unused Linux capabilities, and block privilege escalation using allowPrivilegeEscalation: false. The principle is simple: no container should have more privileges than it needs to run.
Cluster-wide roles demand extra scrutiny. Avoid binding service accounts to cluster-admin unless absolutely necessary. A Helm deployment that ships with default permissive RBAC rules is an open invitation for exploitation. Modify or override these configurations before applying them, even in staging.