Kubernetes 秘密真的是秘密吗？

Question

While I developed an API server, I needed to give some account information to API server, which should not be shown to anyone. K8s recommends secret for this kind of situation, so I used.

But I wonder if the secret is really secret. Secret is just base 64 "encoded" text, not "encrypted".

When I see an arbitary secret like below,

namespace: ZGVmYXVsdA==

I can easily know the real value of it by decoding.

namespace: default

In such a this situation, is secret really helpful for security? What I know about the security advantage of secret is that it is on-memory not on-node file system. But I think that is not enough for security.

Thank you.

Answer 1

FromKubernetes Secrets documentation :

Risks

• In the API server, secret data is stored in etcd( by default, etcd data is not encrypted ); therefore:
  1. Administrators should enable encryption at rest for cluster data (requires v1.13 or later).
  2. Administrators should limit access to etcd to admin users.
  3. Administrators may want to wipe/shred disks used by etcd when no longer in use.
  4. If running etcd in a cluster, administrators should make sure to use SSL/TLS for etcd peer-to-peer communication.
• If you configure the secret through a manifest (JSON or YAML) file which has the secret data encoded as base64, sharing this file or checking it in to a source repository means the secret is compromised. Base64 encoding is not an encryption method and is considered the same as plain text.
• Applications still need to protect the value of secret after reading it from the volume, such as not accidentally logging it or transmitting it to an untrusted party.
• A user who can create a Pod that uses a secret can also see the value of that secret. Even if the API server policy does not allow that user to read the Secret, the user could run a Pod which exposes the secret.
• Currently, anyone with root permission on any node can read any secret from the API server , by impersonating the kubelet. It is a planned feature to only send secrets to nodes that actually require them, to restrict the impact of a root exploit on a single node.

Also check great post Can Kubernetes Keep a Secret? It all depends what tool you're using , especcially " What's wrong with Kubernetes plain Secrets? " part..

I hope that answered your question, but generally @Harsh Manvar is right: you should have an access first to that secret.

Answer 2

You should limit access using authorization policies such as RBAC.

You'll need to create a Role/ClusterRole with appropriate permissions and then bind (using RoleBinding/ClusterRoleBinding ) that to a user and/or a service account (can be used in pod definition then), depending on your use case.

You can look at the documentation here to create Role & ClusterRole and the docs here for RoleBinding and ClusterRoleBinding.