K8s Anti-Design Pattern Series – handling secrets

Introduction

If you’re already using a dynamic service for managing configuration changes, it makes sense to use the same (or a comparable) service for managing secrets as well. Containers should have their secrets communicated to them in real time. Simple storing, git (encrypted), and comprehensive secret solutions like Hashicorp vault are just a few examples.

Some typical hazards include:

• Methods of secrecy redundancy
• mixing up source code security with runtime security
• Through the use of intricate, top-secret injection methods that render local development and testing extremely challenging, if not impossible.
• Choose a course of action and commit to it. The same strategy for handling secrets should be used by all organizations. It’s important to be consistent when dealing with secrets from different settings. This facilitates the monitoring of covert activities (knowing when and where a secret was used).

Each program should only be given access to the secrets it requires.After a program has been deployed, it will require secrets known only at runtime. Instances of this include database passwords, SSL certificates, and secret keys. A build secret is a piece of information that is required by a program during the packaging process but not at any other time. Such passwords could be for an S3 bucket used to store files or your artifact repository (like Artifactory or Nexus). Never send these credentials to a Kubernetes system; they have no place there. All secrets needed by a deployed program should be given to that application alone (and this is true even for non-production clusters).

Your app’s secret management should be handled in a manner that’s versatile enough to facilitate simple testing and local deployment. This implies the app should only be concerned with how the secrets are being used, and not where they came from.

Even though services like Hashicorp Vault provide an adaptable API for retrieving secrets and credentials, your Kubernetes app should NOT call that API directly. This makes local testing of the app difficult, since the developer will need to either build up a local instance of the vault or mock the vault responses in order to run the app.