Using Secrets as mounted volumes in Kubernetes - Step-by-Step Execution

Process Flow - Using Secrets as mounted volumes

Create Secret

↓

Define Pod Spec with Volume

↓

Mount Secret as Volume in Pod

↓

Pod Starts

↓

Container Accesses Secret Files

↓

Use Secret Data Securely

This flow shows how a Kubernetes Secret is created, then mounted as a volume inside a Pod, allowing containers to access secret data as files.

Execution Sample

Kubernetes

kubectl create secret generic mysecret --from-literal=password=abc123

apiVersion: v1
kind: Pod
metadata:
  name: secret-pod
spec:
  containers:
  - name: app
    image: busybox
    volumeMounts:
    - name: secret-volume
      mountPath: /etc/secret
  volumes:
  - name: secret-volume
    secret:
      secretName: mysecret

Creates a secret named 'mysecret' with a password, then defines a Pod that mounts this secret as a volume at /etc/secret.

Process Table

Step	Action	Kubernetes Resource	Result	Notes
1	Create Secret with password	Secret mysecret	Secret 'mysecret' created	Stores 'password=abc123' securely
2	Define Pod spec with volume referencing secret	Pod secret-pod	Pod spec includes volume 'secret-volume' linked to 'mysecret'	Volume will mount secret data
3	Mount secret volume in container	Pod secret-pod	Container mounts volume at /etc/secret	Files from secret appear here
4	Start Pod	Pod secret-pod	Pod running	Container can read secret files
5	Container reads /etc/secret/password	Container filesystem	File contains 'abc123'	Secret data accessible as file content
6	Pod terminates or deleted	Pod secret-pod	Secret volume unmounted	Secret data no longer accessible
7	Secret remains in cluster	Secret mysecret	Secret still exists	Can be reused by other pods

💡 Execution ends after Pod runs and secret volume is accessible; secret persists independently.

Status Tracker

Resource	Initial State	After Step 1	After Step 2	After Step 4	After Step 6
Secret mysecret	Not present	Created with password=abc123	Exists	Exists	Exists
Pod secret-pod	Not present	Not present	Defined with secret volume	Running with secret mounted	Terminated, volume unmounted

Key Moments - 3 Insights

Why does the secret data appear as files inside the container?

Because the secret is mounted as a volume, Kubernetes creates files inside the mount path where each key in the secret becomes a filename containing the secret value (see execution_table step 5).

Does deleting the Pod delete the secret?

No, the secret is a separate Kubernetes resource and remains after the Pod is deleted (see execution_table step 7).

Can the container write to the secret files inside the mounted volume?

No, the secret volume is mounted as read-only by default, so containers cannot modify secret files.

Visual Quiz - 3 Questions

Look at the execution table, at which step does the container start running with the secret volume mounted?

A Step 3

B Step 4

C Step 5

D Step 2

💡 Hint

Check the 'Result' column for when the Pod is running and secret volume is mounted.

According to the variable tracker, what is the state of the secret after the Pod terminates?

A Secret is deleted

B Secret is modified

C Secret still exists

D Secret is inaccessible

💡 Hint

Look at the 'Secret mysecret' row after Step 6 in variable_tracker.

If the secret was not mounted as a volume, what would happen when the container tries to read /etc/secret/password?

A File would not exist

B File would be empty

C File would contain the secret value

D Container would crash

💡 Hint

Refer to execution_table step 5 about secret volume mounting and file presence.

Concept Snapshot

Create a Secret resource with sensitive data.
Define a Pod spec that includes a volume referencing the Secret.
Mount the Secret volume inside the container at a path.
Secret keys appear as files with their values inside the container.
Secret volumes are read-only and persist beyond Pod lifecycle.

Full Transcript

This visual execution shows how to use Kubernetes Secrets as mounted volumes. First, a Secret named 'mysecret' is created with a password key. Then, a Pod is defined that includes a volume referencing this Secret. The volume is mounted inside the container at /etc/secret. When the Pod runs, the container can read the secret data as files inside this directory. The secret files are read-only and the Secret resource remains in the cluster even after the Pod is deleted. This method allows secure access to sensitive data inside containers without embedding secrets in images or environment variables.