How to restrict access to sensitive environment variables in K8S's Pod

General Discussions
1

K8S can securely store sensitive configuration items through Secret, but once the Pod starts and references this configuration item through environment variables, any user with Pod access can view this sensitive configuration item through the Env of the process in the Pod, what is the solution to restrict the access of this environment variable?

2

Can you describe how you think it should work? Outside processes can not change the environment of a running process (as far as I know).

3

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.

4

It’s not the user who access the secret; it’s the pod using the service account defined in the pod’s specification or the default service account created by Kubernetes on each namespace (see Configure Service Accounts for Pods | Kubernetes).

You may restrict access to Secrets for the default service account in the namespace (or create a specific Service Account to be used by the pod with no access to Secrets), but the application will not have access to Secrets, and that may prevent the Pod to run (the pod will be stuck in “pending” state waiting for the Secret to be mounted, most likely).

If your user has permissions to create a Pod (an the application needs some Secret to function properly), you have no way to prevent read access to the Secret (and then, the user may expose the Secret’s value).

You can read about it here: Revealing the secrets of Kubernetes secrets

Pods: If a user has sufficient permissions to create a pod that mounts and uses a secret, the secret’s value will also be visible to them. Even if you set RBAC rules to limit access to secrets, the user could start a pod that exposes the secret by sending the secret outside or writing it into pod logs. Just think about the unwanted association between secrets and their consumers when designing your security concept.

1 Like
5

Thanks, it seems like it is better to use a third-party central config center to deliver sensitive data to the application by an intranet network and some integration methods.