Using Secrets as mounted volumes in Kubernetes - Mini Project: Build & Apply

Using Secrets as mounted volumes

📖 Scenario: You are managing a Kubernetes application that needs to securely access sensitive data like passwords. Instead of hardcoding secrets in your app, you will use Kubernetes Secrets and mount them as volumes inside your pod.

🎯 Goal: Create a Kubernetes Secret with exact key-value pairs, configure a pod to mount this Secret as a volume, and verify the secret data is accessible inside the pod.

📋 What You'll Learn

Create a Secret named db-secret with keys username and password and exact values admin and p@ssw0rd

Create a pod named secret-demo-pod that mounts the db-secret as a volume at /etc/secret-volume

Verify the secret files username and password exist inside the pod and contain the correct values

💡 Why This Matters

🌍 Real World

Kubernetes Secrets are used to store sensitive information like passwords, tokens, and keys securely. Mounting them as volumes allows applications to read secrets as files without exposing them in environment variables or code.

💼 Career

Understanding how to manage secrets securely in Kubernetes is essential for DevOps engineers and cloud-native developers to protect sensitive data and comply with security best practices.

1

Create the Kubernetes Secret

Create a Kubernetes Secret named db-secret with the exact key-value pairs: username: admin and password: p@ssw0rd using a YAML manifest.

Kubernetes

# Write the YAML manifest for the Secret named db-secret
# with keys username and password
# Your code here

Hint

Use base64 encoding for the values: 'admin' -> 'YWRtaW4=', 'p@ssw0rd' -> 'cEBzc3cwcmQ='

2

Add volume configuration to the pod

Create a pod named secret-demo-pod that mounts the Secret db-secret as a volume named secret-volume at the path /etc/secret-volume inside the container. Use the image busybox and command sleep 3600.

Kubernetes

apiVersion: v1
kind: Secret
metadata:
  name: db-secret
type: Opaque
data:
  username: YWRtaW4=
  password: cEBzc3cwcmQ=

# Add pod manifest below
# Your code here

Hint

Mount the secret as a volume inside the container under /etc/secret-volume.

3

Verify secret files inside the pod

Use kubectl exec to run cat /etc/secret-volume/username and cat /etc/secret-volume/password inside the pod secret-demo-pod to verify the secret values are accessible.

Kubernetes

apiVersion: v1
kind: Secret
metadata:
  name: db-secret
type: Opaque
data:
  username: YWRtaW4=
  password: cEBzc3cwcmQ=
---
apiVersion: v1
kind: Pod
metadata:
  name: secret-demo-pod
spec:
  containers:
  - name: busybox
    image: busybox
    command: ["sleep", "3600"]
    volumeMounts:
    - name: secret-volume
      mountPath: "/etc/secret-volume"
      readOnly: true
  volumes:
  - name: secret-volume
    secret:
      secretName: db-secret

# Run kubectl exec commands below
# Your code here

Hint

Use kubectl exec with the pod name and cat command to read secret files.

4

Display the secret values

Print the output of the commands kubectl exec secret-demo-pod -- cat /etc/secret-volume/username and kubectl exec secret-demo-pod -- cat /etc/secret-volume/password to show the secret values admin and p@ssw0rd respectively.

Kubernetes

apiVersion: v1
kind: Secret
metadata:
  name: db-secret
type: Opaque
data:
  username: YWRtaW4=
  password: cEBzc3cwcmQ=
---
apiVersion: v1
kind: Pod
metadata:
  name: secret-demo-pod
spec:
  containers:
  - name: busybox
    image: busybox
    command: ["sleep", "3600"]
    volumeMounts:
    - name: secret-volume
      mountPath: "/etc/secret-volume"
      readOnly: true
  volumes:
  - name: secret-volume
    secret:
      secretName: db-secret

# Print the secret values below
# Your code here

Hint

Print the exact secret values as output.

Practice

1. What is the main benefit of mounting Kubernetes Secrets as volumes inside a pod instead of using environment variables?

easy

A. Environment variables are more secure than mounted volumes.

B. Mounted volumes require manual pod restart to update secrets.

C. Secrets mounted as volumes can be updated automatically without restarting the pod.

D. Secrets cannot be mounted as volumes in Kubernetes.

Solution

1. Step 1: Understand how secrets are exposed

   Secrets can be exposed as environment variables or mounted as files in volumes inside pods.

2. Step 2: Compare update behavior

   Mounted secrets update automatically when changed in Kubernetes, environment variables do not update without pod restart.

3. Final Answer:

   Secrets mounted as volumes can be updated automatically without restarting the pod. -> Option C

4. Quick Check:

   Mounted secrets auto-update = B [OK]

Hint: Mounted secrets auto-update; env vars need pod restart [OK]

Common Mistakes:

• Thinking environment variables update automatically
• Believing secrets cannot be mounted as volumes
• Assuming mounted volumes require pod restart

2. Which of the following is the correct YAML snippet to mount a secret named mysecret as a volume at path /etc/secret-volume inside a pod?

easy

A. volumes:\n - name: secret-volume\n secret:\n secretName: mysecret\ncontainers:\n - name: app\n volumeMounts:\n - name: secret-volume\n path: /etc/secret-volume

B. volumes:\n - name: secret-volume\n configMap:\n name: mysecret\ncontainers:\n - name: app\n volumeMounts:\n - name: secret-volume\n mountPath: /etc/secret-volume

C. volumes:\n - name: secret-volume\n secret:\n name: mysecret\ncontainers:\n - name: app\n volumeMounts:\n - name: secret-volume\n mountPath: /etc/secret-volume

D. volumes:\n - name: secret-volume\n secret:\n secretName: mysecret\ncontainers:\n - name: app\n volumeMounts:\n - name: secret-volume\n mountPath: /etc/secret-volume

Solution

1. Step 1: Check volume secret syntax

   The correct key to specify the secret is secretName, not name.

2. Step 2: Verify volumeMount path key

   The correct key to specify mount path is mountPath, not path.

3. Final Answer:

   Uses correct keys: secretName and mountPath. -> Option D

4. Quick Check:

   secretName + mountPath = A [OK]

Hint: Use secretName for secret, mountPath for volume mount [OK]

Common Mistakes:

• Using configMap instead of secret
• Using 'name' instead of 'secretName'
• Using 'path' instead of 'mountPath'

3. Given this pod spec snippet mounting a secret as a volume:

volumes:
  - name: secret-vol
    secret:
      secretName: mysecret
containers:
  - name: app
    volumeMounts:
      - name: secret-vol
        mountPath: /etc/secret

If the secret mysecret contains a key password with value abc123, what will be the content of the file /etc/secret/password inside the container?

medium

A. password

B. abc123

C. mysecret

D. The file will not exist

Solution

1. Step 1: Understand secret volume mounting

   Each key in the secret becomes a file inside the mounted path with the key as filename and value as file content.

2. Step 2: Identify file content for key 'password'

   The file /etc/secret/password will contain the secret value abc123.

3. Final Answer:

   abc123 -> Option B

4. Quick Check:

   Secret key value = file content [OK]

Hint: Secret keys become filenames; values become file contents [OK]

Common Mistakes:

• Confusing filename with secret name
• Expecting filename to contain key name instead of value
• Thinking file won't be created

4. You mounted a secret as a volume in your pod, but inside the container the secret files are empty. What is the most likely cause?

medium

A. The secret was created but has no data keys.

B. The pod spec used configMap instead of secret in volumes.

C. The volumeMount path is incorrect.

D. Secrets cannot be mounted as volumes.

Solution

1. Step 1: Check secret data content

   If the secret exists but has no keys or empty values, mounted files will be empty.

2. Step 2: Verify volume type and mount path

   Using secret in volumes and correct mountPath is required; wrong type or path causes missing files, not empty files.

3. Final Answer:

   The secret was created but has no data keys. -> Option A

4. Quick Check:

   Empty secret data = empty files [OK]

Hint: Empty secret data means empty files inside container [OK]

Common Mistakes:

• Confusing empty files with wrong mount path
• Assuming secrets can't be mounted
• Mixing configMap with secret volumes

5. You want to mount a secret as a volume in a pod, but only expose the key db-password as a file named password.txt inside the container at /etc/db. Which volume configuration achieves this?

hard

A. volumes:
- name: db-secret
secret:
secretName: mysecret
items:
- key: db-password
path: password.txt
containers:
- name: app
volumeMounts:
- name: db-secret
mountPath: /etc/db

B. volumes:
- name: db-secret
secret:
secretName: mysecret
items:
- key: password.txt
path: db-password
containers:
- name: app
volumeMounts:
- name: db-secret
mountPath: /etc/db

C. volumes:
- name: db-secret
secret:
secretName: mysecret
containers:
- name: app
volumeMounts:
- name: db-secret
mountPath: /etc/db/password.txt

D. volumes:
- name: db-secret
configMap:
name: mysecret
items:
- key: db-password
path: password.txt
containers:
- name: app
volumeMounts:
- name: db-secret
mountPath: /etc/db

Solution

1. Step 1: Use secret volume with items to map keys to filenames

   The items field allows selecting specific keys and renaming files.

2. Step 2: Verify correct key and path mapping

   Key db-password mapped to password.txt with mountPath /etc/db matches volumes: - name: db-secret secret: secretName: mysecret items: - key: db-password path: password.txt containers: - name: app volumeMounts: - name: db-secret mountPath: /etc/db.

3. Final Answer:

   Correctly maps the secret key to the desired filename and mount path. -> Option A

4. Quick Check:

   Use items to rename secret keys in volume [OK]

Hint: Use items to rename secret keys as files [OK]

Common Mistakes:

• Swapping key and path in items
• Using configMap instead of secret
• Mounting secret directly without items for renaming