What is the point of Kubernetes secrets if I can decode them?

Question

I can easily get the secrets stored in Kubernetes.

$ kubectl get secret my-app-secrets -o yaml

Select secret value from output that I want to decode.

Example ZXhwb3NlZC1wYXNzd29yZAo=

$ echo ZXhwb3NlZC1wYXNzd29yZAo= | base64 --decode
> exposed-password

I'm not sure I understand the effectiveness of the secrets resources in Kubernetes ecosystem since it's easy to obtain this.

Answer 1

base64 is encoding, not encryption, it allows you to simply encode information in a convenient way.

The data that you encode may contain many unrecognized characters, line feeds, etc., so it is convenient to encode them.

In kubernetes, you can enable encryption using this instruction.

But kubernetes should not be the only source of truth, rather kubernetes loads these secrets from an external vault that you need to select, such as hashicorp's vault, as indicated in the comments.

In addition to hashicorp vault, there are various ways to store secrets in git:

• Helm secrets
• Kamus
• Sealed secrets
• git-crypt

You may also be interested in the kubesec project, which can be used to analyze kubernetes resources for security risks.

Answer 2

The point is that in Kubernetes, the secret allows you to protect your password (what you want to do by encrypting it) by controlling the access to the secret, instead of by encrypting it.

There are several mechanisms for it:

• Secrets can only by accessed by those of their very same namespace.
• Secrets have permissions as any other file, so you choose who has access to it.
• They are only sent to pods whenever required, not before.
• They're not written in local disk storage.

That said, in case something goes wrong, solutions as Sealed Secrets created by Bitnami or others solutions (see Mokrecov answer) have arisen to give even more robustness to the matter, just in case someone undesired gained access to your secret.

Answer 3

Secrets in kubernetes are separate manifests NOT to protect your secret data, but to separate your secret data from your deployment/pod configuration.

Then it's up to you how to secure your secrets, there are many options with it's pros and cons (see Mokrecov's answer). There is also some advantages of secrets compared to other types. Like namespace restriction, seperate access management, not available in pod before it's needed and they are not written in the local disc storage.

Let's think other way around, let's imagine there wasn't any Secrets in kubernetes. Now, your secret data will be inside your deployment/pod/configmap. You have several problems. For example:

1. You want to give access to deployment manifest to all users but restrict access to Secrets to person A and B only. How do you do that?
2. If you want to encrypt secrets, you will have to encrypt all data together with deployment data which will make maintenance impossible. Or you can encrypt each secret value but you have to come up with some decryption mechanism for each of them, and keys to decrypt will be unvailed in that phase anyway.
3. You can use ConfigMap to seperate secret data from configuration. But then when you want to add encryption mechanism, or some access restrictions to it, you will be restricted by characteristics of ConfigMap, because it's intention is only to store non secret data. With Secrets you have easy options to add encryption/restrictions.