4 ms·

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

• twalla 5y ago
  Encryption at rest for secrets can be enabled, the base64 thing is more of an artifact of how JSON serialization works with byte arrays.
• notwedtm 5y ago
  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.
  • gscho 5y ago
    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.
    • threeseed 5y ago
      But it can be a secret. You can store Base64-encoded, encrypted data. And you can encode it for example using an external KMS.
      • gscho 5y ago
        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.
      • rdtsc 5y ago
        Is that built-in though? Because if it isn’t then it is a bit silly to call it a secret.
    • Nullabillity 5y ago
      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.
    • deleted 5y ago
      [deleted]
  • jhugo 5y ago
    I think you're looking for "bad rap" (as in "rap sheet"). A bad wrap is an unappetising tortilla.
    • kitsune_cw 5y ago
      I've always seen it written as "bad rep" as in reputation.
      • dharmab 5y ago
        Bad rap is the older form: https://www.merriam-webster.com/words-at-play/usage-bad-rap-vs-bad-rep-vs-bad-wrap https://www.merriam-webster.com/words-at-play/usage-bad-rap-...
    • morelisp 5y ago
      If it's only base64 and not encrypted, that also seems like a bad wrap.
• dharmab 5y ago
  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.
• zaat 5y ago
  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-data/ https://kubernetes.io/docs/tasks/administer-cluster/encrypt-...
• jhugo 5y ago
  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.
  • remram 5y ago
    Can't ConfigMap be binary data? I never understood why one is base64 and the other not.
    • dharmab 5y ago
      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.
      • remram 5y ago
        I didn't know about ConfigMap's binaryData or Secret's stringData, thanks!
• knlam 5y ago
  this is why I use configmap instead of secrets. Why complicate yourself without the upside ¯\_(ツ)_/¯
  • dharmab 5y ago
    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)