Kubernetes Secret configuration

Kubernetes Secrets are a Kubernetes resource that allows you to store and manage sensitive data such as passwords, API keys, and other confidential information.

Secrets are similar to ConfigMaps in that they provide a way to decouple configuration data from your application code. However, unlike ConfigMaps, Secrets are specifically designed to store sensitive data and are encrypted at rest.

Kubernetes secret

Read more — Secret resource

Here are some key characteristics of Kubernetes Secrets:

• Secrets can be used to store any kind of sensitive data, including passwords, certificates, and API keys.
• Secrets are stored in etcd, the Kubernetes key-value store, and are encrypted at rest.
• Secrets are stored as base64-encoded data, which means that the actual data is not visible in plain text within Kubernetes. However, it’s important to note that base64 encoding is not a form of encryption and can be easily decoded.
• Secrets can be mounted as files or passed as environment variables to your application containers.
• Secrets can be managed and updated independently of your application code.
• Secrets can be restricted to specific namespaces or roles, providing more granular access controls.

Kubernetes Secrets are designed to provide a secure way to store and manage sensitive data, and are encrypted at rest. They also provide more granular access controls, and can be restricted to specific namespaces or roles.

While ConfigMaps can be used to store sensitive data, they are not encrypted at rest and can be read in plaintext by anyone who has access to the ConfigMap.

Therefore, for sensitive data such as database passwords, it’s recommended to use Secrets instead of ConfigMaps. Here’s an example YAML file for a Secret that stores a database password:

To create a Kubernetes Secret, you can use the kubectl create secret command. Here's an example command to create a Secret:

kubectl create secret generic my-secret --from-literal=PASSWORD=mysupersecretpassword=

we’ve created a Secret named ‘my-secret’ that contains a single key-value pair, ‘PASSWORD=mysupersecretpassword’.

In this example, I’ve created a Secret named db-password that stores a base64-encoded password. The type: Opaque field indicates that this Secret does not have any predefined structure, and is opaque to Kubernetes.

Next, we can mount this Secret as a volume or pass it as an environment variable to a container that requires access to the database. Here’s an example YAML file for a deployment that mounts this Secret as a volume:

In this example, we’ve updated the deployment YAML file to include the DB_PASSWORD environment variable, which is read from the password key of the db-password Secret. We've also mounted the db-password Secret as a volume at the path /etc/secrets, which can be accessed by the container. The readOnly: true field ensures that the Secret is not modified by the container.

Thank you for reading !!

Please follow for more DevOps blogs…….

Promise Imeh