Helm Chart Permission Analyser That Finds Kubernetes Cluster Takeover Paths Before Install

The problem: add-ons that hold the keys to the cluster

Teams run more than their own apps on Kubernetes. They install ingress controllers, certificate managers, monitoring agents, backup tools and database operators, usually as Helm charts written by someone else. Each chart creates service accounts and grants them permissions. Some of those permissions are enormous: read every secret in the cluster, create pods on any node, or patch other workloads. If an attacker compromises one pod of that add-on, through a bug in the add-on itself, those permissions become theirs.

Most teams never read the RBAC section of a chart. It is long, spread across templates, and changes with values. Even when they do read it, it is hard to see that "create pods" plus "any node" is a route to the control plane.

What already exists and the gap

• KubiScan from CyberArk finds risky roles and service accounts in a running cluster using a configurable risk model.
• audit2rbac and Audicia generate least-privilege roles from Kubernetes audit logs of what a user or workload actually did.
• Trivy, Checkov and kube-score lint manifests for misconfigurations such as privileged containers.
• kubectl auth can-i answers single permission questions.

The gap is analysis before install that connects the dots: not "this role is broad" but "a compromised pod of this chart can read the token of that service account, which can create a privileged pod on a control plane node, which gives cluster admin". It should work on a chart file, before anything touches a real cluster.

Inspiration

"Take Over the Whole Cluster: Attacking Kubernetes via Excessive Permissions of Third-party Applications" by Nanzi Yang, Wenbo Shen and colleagues (ACM CCS 2023) analysed the third-party applications in the CNCF landscape and found that 51 of 153 had potential security risks from excessive critical permissions, which an attacker could use to escape from a worker node and take over the cluster. This project turns that analysis into a tool anyone can run on a chart before installing it.

What you build

• Platform engineers run analyse chart-name --values my-values.yaml and get a ranked list of takeover paths, each with a fix.
• Security reviewers attach the report to the change that adds a new add-on.
• Chart maintainers can run it in their own CI and ship tighter defaults.

The technically interesting part

• Rendering faithfully. Risk depends on values: a flag may turn on cluster-wide access. Render the chart with the user's values and with common alternatives, and say which values change the risk.
• Modelling escalation. Encode the critical permissions from the paper and Kubernetes documentation: creating pods with host mounts, reading secrets that hold tokens, impersonation, binding roles, patching nodes, changing admission webhooks. Each becomes an edge in a graph from one identity or node to another.
• Placement matters. A pod that can only land on worker nodes is less dangerous than one tolerated onto control plane nodes. Model node selectors, tolerations and daemon sets.
• Proving it. For selected findings, run the chart in a kind cluster, act as the compromised pod and carry out the escalation. A confirmed path is far more convincing than a rule hit.
• Suggesting a fix. Propose a narrower role (namespaced instead of cluster-wide, named resources instead of all) and check that the chart still starts with it.

How to evaluate it

• Agreement with the paper: for charts covered by the CCS study, compare your findings with theirs.
• Confirmed paths: share of high-risk findings you could demonstrate in kind.
• False alarms: findings a reviewer judges unreachable after reading the chart.
• Fix quality: share of suggested narrower roles that still let the chart pass its own health checks.

Suggested plan

• Weeks 1 to 3: Kubernetes RBAC and pod security in a kind cluster; render and read five charts by hand.
• Weeks 4 to 8: permission model and rule set; first attack graph.
• Weeks 9 to 14: report, values handling and the first proof-of-concept escalations.
• Second semester: 50-chart study, fix suggestions, CI check and the write-up.

Path to a product

Cluster add-ons are part of the software supply chain, and platform teams need a review step for them. A public catalogue of risk reports for popular charts, plus private scanning, would be useful to many teams, and the study is publishable. It is also excellent preparation for cloud security and platform roles.

Scope warning

Run every proof of concept in a disposable local cluster, never a shared or production one. Start with RBAC and pod placement; leave network policies and cloud identity integrations as later work. If you find a chart with a dangerous default, tell its maintainers privately first.

Learn what you need on Sefism

• Platform engineering and SRE roadmap: running clusters and add-ons safely.
• Kubernetes Documentation: RBAC, service accounts and pod security.
• kind (Kubernetes IN Docker): disposable local clusters for your proofs of concept.
• Kubernetes Production Best Practices: the defaults charts should follow.
• Cybersecurity roadmap: privilege escalation and cloud security basics.

Get help with this idea

The challenge is modelling escalation precisely enough to be believed without trying to model all of Kubernetes. Tauseef can help you choose the rule set, plan the chart study and structure the report. If you are new here, create a free account first.

• Discuss this idea with a mentor
• Send a query to Tauseef
• Book a 1:1 session