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.
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.
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.
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.
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.
- 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)
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.