Kubernetes API Server Bypass Risks

[raesene]

Based on a suggestion from @JimBugwadia on slack an idea for a good page on the Kubernetes website would be to collate configurations or privileges which could allow a malicious user or attacker to bypass the API server. As many key security controls (e.g. Auditing and admission control) are handled at the API server layer, attacks which bypass it can present a serious risk to cluster security.

Some examples :-

• node/proxy rights at the cluster level can allow users to directly communicate with the kubelet API, bypassing the API server.
• To an extent users being able to create static pods bypasses some API server controls
• Direct access to the etcd database will effectively allow attackers to retrieve things like secrets without that access being visible in API server audit logs.

/sig security docs

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[savitharaghunathan]

/remove-lifecycle stale

[savitharaghunathan]

/assign @raesene

[raesene]

I've put some initial thoughts for this in a hackmd here feel free to add/suggest changes :)

Once we've gathered some ideas, we can create a PR for k/website to get wider feedback

[p4ck3t0]

What is about the pause container? An attacker who can change the pause container image, also bypasses the API? 🤔
Is that something we could add to that list?

[raesene]

@p4ck3t0 so at the moment we're focusing more on how things are changed rather than what they'd change, but you raise a good point, in that people could modify container images either on-host or via the CRI daemon, and that's definitely worth including.

[raesene]

This has been merged now woooo kubernetes/website#35908