We need to take additional precautions to protect ourselves. That might include, but is not limited to, the following actions:

Secure the communication between etcd instances with SSL/TLS.

Limit the access to etcd and wipe the disk or partitions that were used by it.

Do not define Secrets in YAML files stored in a repository. Create Secrets through ad-hoc kubectl create secret commands. If possible, delete commands history afterward.

Make sure that the applications using Secrets do not accidentally output them to logs or transmit them to other applications.

Create policies that allow only trusted users to retrieve secrets. However, you should be aware that even with proper policies in place, any user with permissions to run a Pod could mount a Secret and read it.

We did not yet explore etcd configuration, nor did we learn how to set up authorization policies. For now, just remember that Secrets are not as secured as one might think. At least, not those provided by Kubernetes community. We do encourage you to use them, as long as you’re aware of their shortcomings.