Secrets and ConfigMaps

There are three main ways to mount Secrets and ConfigMaps in Kubernetes:

 

1. Environment Variables: ConfigMap and Secret values can be exposed as environment variables to a container.
2. Volume Mounts: ConfigMap and Secret data can be mounted as a file in a volume to a container.
3. Command Line Arguments: The values from a ConfigMap and Secret can be passed as command-line arguments to a container.

Secrets:

Secrets are used to store sensitive information such as passwords, tokens, and encryption keys. Secrets are encrypted and stored as base64-encoded data, and they can be used in a variety of ways in your deployment, such as environment variables, command-line arguments, and volume mounts.

 

Here’s an example of how to create a secret in YAML:

 

apiVersion: v1

kind: Secret

metadata:

  name: mysecret

type: Opaque

data:

  password: cGFzc3dvcmQ= # this is the base64 encoded representation of “password”

  token: dG9rZW4= # this is the base64 encoded representation of “token”

In this example, we’re creating a Secret called “mysecret” with two key-value pairs: “password” and “token”. The values are base64-encoded.

 

In Kubernetes, you can mount Secrets as a volume in a Pod to make the data accessible to the containers running in the Pod. This is useful when you need to use sensitive information, such as passwords or tokens, in your application.

 

As a volume mount: You can mount a Secret as a volume in a Pod, making the data accessible to the containers running in the Pod. The contents of the Secret can be read from a specified path in the file system.

 

Here’s an example of how to mount a Secret as a volume in a Pod:

 

apiVersion: v1

kind: Pod

metadata:

  name: mypod

spec:

  containers:

  – name: mycontainer

    image: myimage

    volumeMounts:

    – name: mysecret-volume

      mountPath: /etc/secrets

  volumes:

  – name: mysecret-volume

    secret:

      secretName: mysecret

In this example, we’re creating a Pod called “mypod” with a single container called “mycontainer”. The container is using an image called “myimage”.

 

The Secret called “mysecret” is being mounted as a volume in the Pod and is accessible at the path “/etc/secrets”. The containers running in the Pod can read the contents of the Secret from this path.

 

It’s important to note that Secrets are encrypted and stored as base64-encoded data, so you’ll need to decode the data in your application to use it.

 

Here’s an example of how to use a Secret as an environment variable in a Pod:

 

apiVersion: v1

kind: Pod

metadata:

  name: mypod

spec:

  containers:

  – name: mycontainer

    image: myimage

    env:

    – name: MY_PASSWORD

      valueFrom:

        secretKeyRef:

          name: mysecret

          key: password

In this example, we’re creating a Pod called “mypod” with a single container called “mycontainer”. The container is using an image called “myimage”.

 

The Secret called “mysecret” is being referenced as an environment variable in the container with the name “MY_PASSWORD”. The value of the environment variable is being set to the “password” key in the Secret.

 

Here’s an example of how to use a Secret as a command-line argument in a Pod:

 

apiVersion: v1

kind: Pod

metadata:

  name: mypod

spec:

  containers:

  – name: mycontainer

    image: myimage

    command:

    – myapp

    args:

    – –password=$(MY_PASSWORD)

    env:

    – name: MY_PASSWORD

      valueFrom:

        secretKeyRef:

          name: mysecret

          key: password

In this example, we’re creating a Pod called “mypod” with a single container called “mycontainer”. The container is using an image called “myimage”.

 

The Secret called “mysecret” is being referenced as a command-line argument in the container with the name “MY_PASSWORD”. The value of the argument is being set to the “password” key in the Secret.

 

In both examples, it’s important to note that Secrets are encrypted and stored as base64-encoded data, so you’ll need to decode the data in your application to use it.

 

ConfigMaps:

ConfigMaps, on the other hand, are used to store non-sensitive configuration data. This data can be used in a variety of ways, such as environment variables, command-line arguments, and volume mounts.

 

Here’s an example of how to create a ConfigMap in YAML:

 

apiVersion: v1

kind: ConfigMap

metadata:

  name: myconfigmap

data:

  app.setting: production # this could be a setting value for your app

  app.port: “8080” # this could be the port that your app runs on

In this example, we’re creating a ConfigMap called “myconfigmap” with two key-value pairs: “app.setting” and “app.port”.

 

1. Environment Variables:

apiVersion: v1

kind: Pod

metadata:

  name: configmap-demo

spec:

  containers:

  – name: demo

    image: <image-name>

    env:

    – name: <ENV_VAR_NAME>

      valueFrom:

        configMapKeyRef:

          name: <configmap-name>

          key: <key-name>

2. Volumes:

 

apiVersion: v1

kind: Pod

metadata:

  name: configmap-demo

spec:

  containers:

  – name: demo

    image: <image-name>

    volumeMounts:

    – name: config-volume

      mountPath: <mount-path>

      readOnly: true

volumes:

  – name: config-volume

    configMap:

      name: <configmap-name>

      items:

      – key: <key-name>

        path: <file-name>

3. Command Line Arguments:

 

apiVersion: v1

kind: Pod

metadata:

  name: configmap-demo

spec:

  containers:

  – name: demo

    image: <image-name>

    command: [ “sh”, “-c”]

    args:

    – |

      echo <configmap-value>

    env:

    – name: <ENV_VAR_NAME>

      valueFrom:

        configMapKeyRef:

          name: <configmap-name>

          key: <key-name>

In summary, Secrets are used to store sensitive information, and ConfigMaps are used to store non-sensitive configuration data. Both can be used in a variety of ways to configure your applications in Kubernetes.

 

Vault:

 

Vault is a tool for securely storing and accessing secrets. It can be used to manage secrets such as API keys, passwords, and certificates, and can provide secure access to these secrets from apps and services. Vault provides a centralized way to manage and control access to secrets, and has features such as encryption, dynamic secrets, and audit logging. Vault can be used with various environments and infrastructure, including Kubernetes.

 

Vault can be used in various ways, including:

 

Secrets Management: Store, manage, and control access to secrets such as API keys, passwords, and certificates.

Data Encryption: Encrypt data in transit and at rest using industry standard algorithms.

Dynamic Secrets: Generate dynamic secrets on-demand, and revoke access to secrets when needed.

Identity Management: Manage authentication and authorization for users, apps, and services.

Audit Logging: Track and monitor access to secrets and sensitive data.

To deploy Vault on Kubernetes, there are several options available:

 

Manually deploy and configure Vault on a Kubernetes cluster.

Use a Helm chart to deploy and configure Vault on a Kubernetes cluster.

Use the Vault operator to manage the deployment and operation of Vault on a Kubernetes cluster.

Regardless of the deployment method, it is important to properly secure Vault and follow best practices for managing secrets in production environments.