Hacker News Reader

Comment by gscho | Hacker News Reader

Wait until you find out that kubernetes secrets aren’t actually secrets but base64 encoded strings.

I think K8S secrets get a bad wrap. They are not intended to be secret in the sense that they are "kept from prying eyes by default". The secret object is simply a first-class citizen that differentiates it from a ConfigMap in a way that allows distinct ACL's.

Most organizations I know will still use something like ExternalSecret for source control and then populate the Secret with the values once in cluster and to an object with very few access points.

I think calling it a secret when it isn’t gave it a bad wrap. The last time I looked at the documentation it didn’t even clearly describe that it is not a secure object (that may have changed recently). Why call it a secret when it is not even close to one? I guess thing-to-store-secrets-if-you-use-rbac was too long.

But it can be a secret. You can store Base64-encoded, encrypted data.

And you can encode it for example using an external KMS.

Yes I understand that. My point is until you configure it in that way it is not “secret” and the name of the object is a bit misleading, especially when first learning k8s.

Is that built-in though? Because if it isn’t then it is a bit silly to call it a secret.

If you don't use RBAC (or some other ACL mechanism) then it's already game over, everyone with access to your cluster already has full root access.

I think you're looking for "bad rap" (as in "rap sheet"). A bad wrap is an unappetising tortilla.

I've always seen it written as "bad rep" as in reputation.

Bad rap is the older form: https://www.merriam-webster.com/words-at-play/usage-bad-rap-...

If it's only base64 and not encrypted, that also seems like a bad wrap.

They're base64 encoded because they can be binary data; it's got nothing to do with hiding their value. K8s secrets are for delineating secret (as opposed to non-secret, ConfigMap) data, so that access to it can be controlled differently.

You can set up encryption at rest, you can use RBAC to control the access, etc — those features are possible because Secret gives a specific resource for secret data.

Can't ConfigMap be binary data? I never understood why one is base64 and the other not.

Because these objects were defined earlier in Kubernetes' history the fields have inconsistent names and defaults. In Secret there is a canonical data field which stores bytes and a stringData field which will convert text to bytes for you. ConfigMap has separate data (text) and binaryData (bytes) fields which are both canonical.

If the interface were redesigned today, Secrets would probably look like a renamed clone of ConfigMap.

I didn't know about ConfigMap's binaryData or Secret's stringData, thanks!

Encryption at rest for secrets can be enabled, the base64 thing is more of an artifact of how JSON serialization works with byte arrays.

They're not necessarily strings. You can put binary data in the data field, which is why it is base64.

You can also configure the apiserver/etcd to encrypt specific keyspaces, such as the secrets/ key space.

It is in your hands (the version where it became available is more than a year end of life, basically forever in Kubernetes life), maybe they will change the default too. At least there's a fine bold warning box in the docs.

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

this is why I use configmap instead of secrets. Why complicate yourself without the upside ¯\_(ツ)_/¯

Some real concrete reasons:

- You can configure etcd to encrypt Secrets without taking the encryption performance hit on ConfigMaps

- You can configure the audit logs to log the diff whenever a ConfigMap was created or updated while only logging metadata and redacting content when Secrets are created or updated

- You can configure RBAC policies that grant access to ConfigMaps without Secrets (e.g. for a controller or operator)

Reply on news.ycombinator.com