Kubernetes secret is really secret?

user_11340204 0
Viewed 455

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.

kubernetes
2 Answers

From Kubernetes 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.

user_99290150

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.

user_17223260
Related