[blakesterz]

"... a user who can create or update ingress objects, can use the custom snippets feature to obtain all secrets in the cluster." I'm not a Kubernetes guy, so I'm curious, how often is there a user with only those permissions? Is it common to have a user that can create/update and then doesn't already have some kind of other access to everything else? I don't know much about Kubernetes permissions.

(I also just learned that the word Kubernetes is in the default Chrome spell checker thing, which was sure helpful in writing this comment!)

[cassianoleal]

A user can have many permissions in his/her own namespace without compromising the other tenants. This sounds like it would allow any user with Ingress create/update access in any namespace to compromise secrets across all namespaces.

[cassianoleal]

It is unclear whether this is a problem if you're running namespaced ingress-controllers though. This comment [0] in the bug report says:

    there's definitely an attack path that gets the ingress-nginx service account token, which has list rights on secrets at a cluster level (so allowing for all secret values to be retrieved).

I can't see how list permissions would allow retrieval of the secret value though. You'd need get permissions for that.

[0] https://github.com/kubernetes/ingress-nginx/issues/7837#issu...

[xnxn]

> You'd need get permissions for that.

I'm afraid not. HTTP GET on a collection endpoint (which is the operation represented by the list verb) returns the full object content.

https://kubernetes.io/docs/reference/access-authn-authz/auth...

[cassianoleal]

Interesting, thanks for the reference. This is at best surprising, at worst sloppy security design IMO.

[nanis]

> "... a user who can create or update ingress objects, can use the custom snippets feature to obtain all secrets in the cluster."

To this point, handling of secrets in the Kubernetes ecosystem always seemed like a mess to me. Both `vault` and AWS SecretsManager/KMS in combination with IAM allow me to finely partition access to secrets by instance or developer identity whereas in the Kubernetes world one expects "secrets" to be handled by a small core group and machines seem to have mostly unfettered access.

Specifically[1],

>> Caution:

>> Kubernetes Secrets are, by default, stored unencrypted in the API server's underlying data store (etcd). Anyone with API access can retrieve or modify a Secret, and so can anyone with access to etcd. Additionally, anyone who is authorized to create a Pod in a namespace can use that access to read any Secret in that namespace; this includes indirect access such as the ability to create a Deployment.

>> In order to safely use Secrets, take at least the following steps:

>> * Enable Encryption at Rest for Secrets[2].

>> * Enable or configure RBAC rules that restrict reading data in Secrets (including via indirect means).[3]

>> * Where appropriate, also use mechanisms such as RBAC to limit which principals are allowed to create new Secrets or replace existing ones.

When you dig deeper, both [2] and [3] look like they are someone's job security plan. No wonder it was developed at a place which employs people just to keep them off the market.

Especially since you really don't gain much unless you also have a KMS Provider[4].

No wonder most K8 setups I've seen still have BASE64 encoded secrets in some YAML file.

There is also no shortage of tutorial-spam -- so unless you happen to be lucky enough to apprentice with people who know what they are doing, it is hard to gain a solid understanding and move confidently.

[1]: https://kubernetes.io/docs/concepts/configuration/secret/

[2]: https://kubernetes.io/docs/tasks/administer-cluster/encrypt-...

[3]: https://kubernetes.io/docs/reference/access-authn-authz/auth...

[4]: https://kubernetes.io/docs/tasks/administer-cluster/kms-prov...