Confusion in the community around Secrets

[dims]

We have a very decent page around Secret(s) here:
https://kubernetes.io/docs/concepts/configuration/secret/#information-security-for-secrets

Unfortunately we repeatedly see:

• https://stackoverflow.com/questions/61347824/what-is-the-point-of-kubernetes-secrets-if-i-can-decode-them
• https://news.ycombinator.com/item?id=27731249 for example.

One recent question/observation i had internally was - Does anyone actually care about leaking k8s secrets to the console? I was working with some OSS code and they were explicitly redacting the k8s secrets data from API requests but its just base64 encoded by default so its like security by obfuscation. it is just really unintuitive at first sight when something is called a secret but its just base64 encoded and not encrypted by default. Its not clear what makes it a 'secret' in the simplest case

How do make this better? clearer? especially things like: ( hat tip to @cppforlife )

• at rest, secrets might be encrypted or unencrypted (depends on k8s config used)
• in flight, secrets go over TLS
• in flight, secret access is controller via RBAC
• API format uses base64 encoding to support binary and non-binary secret contents

While we are at it, could we write down guidance for logging secrets ... to say don't log the contents of it? :)

thanks!
-- Dims

[dims]

cc @nikhita @MadhavJivrajani @palnabarun (can one of you please see how we can update existing documentation?)

[johnSchnake]

FWIW I was the quoted person asking about the "leaking of secrets to the console"

After being pointed to a few resources my thoughts were this:

I think the most clear answer is the last comment on the stackoverflow issue; which also gives practical examples of a few workflows that would be awkward if k8s secrets didnt exist. Yes they could be configmaps or stored with other data, but then access control and encryption would apply to both equally. The separate data type just provides a means of singling them out when necessary.

It seems like its a case of the community:

• identifying the need for secrets
• splitting the implementation in two (k8s secret type vs actual secret encryption/storage)
• it not being clear that the object (k8s.secret) is only half of the solution to 'keeping a secret'

It's still slightly unclear why leaking them to console would be bad; if users didn't encrypt them its assumed they aren't sensitive and if they do encrypt them it doesn't matter if you print them. However, I can understand the general design of secrets better by understanding that its necessary condition for "actual-secrets" but not a sufficient one. Being part of that chain of security makes sense why we should, by convention, not leak them in principle.

[dims]

@johnSchnake let's use this issue to reflect what is currently the design/implementation.

Any future suggestions, we take it to sig-auth for debate and resolution. Let's keep the two separate please.

thanks!

[reylejano]

/triage accepted

[sftim]

/language en
/kind feature

/priority backlog
(but definitely nice-to-have)

[sftim]

My take on this is that the problem is mostly not the Secret API itself; instead, it's the huge amount of effort you have to go to if you want to restrict reading it back (and still allow it to be useful to the Pod, or whatever, that needs to use it). Encryption at rest gets you nothing if too many people can ask the API server for the plaintext.

I'm not sure how far we can get at documenting that but we can at least point out how important access control measures are when you have valuable Secrets.

There's probably a KEP or similar that would cover a more complicated design using asymmetry, where the API server does not have direct access to the plaintext of a Secret at any point, or maybe not after initial encryption. The only part of that that I'd want to cover in docs would be to make it clear that access to read the metadata of Secret always also means access to all its fields, including the plaintext.

[dims]

@sftim : +1 to documenting The only part of that that I'd want to cover in docs would be to make it clear that access to read the metadata of Secret always also means access to all its fields, including the plaintext.

[sftim]

We could document that you, a cluster operator, have the option of adding your own authz mechanism to restrict direct Secret readback, and that you can also use admission control to limit indirect readback by creating a Pod / Pod template.

Is that useful?

[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

[reylejano]

/remove-lifecycle stale

[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

[divya-mohan0209]

/remove-lifecycle stale

[k8s-triage-robot]

This issue has not been updated in over 1 year, and should be re-triaged.

You can:

• Confirm that this issue is still relevant with /triage accepted (org members only)
• Close this issue with /close

For more details on the triage process, see https://www.kubernetes.dev/docs/guide/issue-triage/

/remove-triage accepted