Why Secrets manage sensitive data in Kubernetes - Why It Works

Introduction

When you run applications, sometimes they need passwords or keys. Storing these sensitive details safely is important so others cannot see them. Kubernetes Secrets help keep this sensitive data hidden and secure.

When your app needs a database password to connect securely.

When you want to store API keys without putting them in your app code.

When you need to share TLS certificates with your app safely.

When you want to avoid exposing sensitive info in plain text in configuration files.

When you want to update sensitive data without changing your app code.

Config File - secret.yaml

secret.yaml

apiVersion: v1
kind: Secret
metadata:
  name: my-secret
  namespace: default
type: Opaque
data:
  username: bXl1c2Vy
  password: c2VjdXJlcGFzcw==

This file creates a Kubernetes Secret named my-secret in the default namespace.

The data section holds sensitive info encoded in base64. Here, username and password are stored securely.

The type: Opaque means it holds generic secret data.

Commands

This command creates the Secret in Kubernetes using the configuration file. It stores the sensitive data safely inside the cluster.

Terminal

kubectl apply -f secret.yaml

Expected Output

secret/my-secret created

This command shows the Secret details in YAML format. The sensitive data remains base64 encoded and not shown in plain text.

Terminal

kubectl get secret my-secret -o yaml

Expected Output

apiVersion: v1

data:

  password: c2VjdXJlcGFzcw==

  username: bXl1c2Vy

kind: Secret

metadata:

  creationTimestamp: "2024-06-01T12:00:00Z"

  name: my-secret

  namespace: default

  resourceVersion: "12345"

  uid: abcdef12-3456-7890-abcd-ef1234567890

type: Opaque

→

-o yaml - Outputs the secret details in YAML format

This command shows a summary of the Secret without revealing the actual sensitive data, helping you verify it exists.

Terminal

kubectl describe secret my-secret

Expected Output

Name:         my-secret

Namespace:    default

Labels:       <none>

Annotations:  <none>

Type:         Opaque

Data

====

password:  12 bytes

username:  6 bytes

Key Concept

If you remember nothing else from this pattern, remember: Kubernetes Secrets store sensitive data encoded and separate from app code to keep it safe.

Common Mistakes

Storing sensitive data directly in plain text in Pod or Deployment YAML files.

This exposes secrets to anyone who can read those files or see the pod specs, risking leaks.

Use Kubernetes Secrets to store sensitive data separately and reference them in your pods.

Not encoding secret data in base64 before creating the Secret.

Kubernetes requires secret data to be base64 encoded; otherwise, the Secret creation fails.

Encode your sensitive values using base64 before adding them to the Secret YAML.

Using 'kubectl get secret my-secret' without '-o yaml' and expecting to see plain text data.

The data is base64 encoded and not shown in plain text by default, so it looks like gibberish.

Use 'kubectl get secret my-secret -o yaml' and decode base64 values to see actual data.

Summary

Create a Secret YAML file with sensitive data encoded in base64.

Apply the Secret to Kubernetes using 'kubectl apply -f secret.yaml'.

Verify the Secret exists and check its details without exposing the data.

Practice

1. Why does Kubernetes use Secrets to manage sensitive data?

easy

A. To store large files efficiently

B. To keep passwords and keys hidden from plain view

C. To speed up application deployment

D. To replace ConfigMaps for all configurations

Solution

1. Step 1: Understand the purpose of Secrets

   Kubernetes Secrets are designed to store sensitive information like passwords and keys securely.

2. Step 2: Compare with other options

   Secrets do not speed up deployment, store large files, or replace ConfigMaps entirely.

3. Final Answer:

   To keep passwords and keys hidden from plain view -> Option B

4. Quick Check:

   Secrets protect sensitive data = C [OK]

Hint: Secrets hide sensitive info, not speed or size [OK]

Common Mistakes:

• Thinking Secrets speed up deployment
• Confusing Secrets with ConfigMaps
• Assuming Secrets store large files

2. Which of the following is the correct way to create a Secret from literal values in Kubernetes?

easy

A. kubectl create configmap mysecret --from-literal=password=12345

B. kubectl secret create mysecret --literal=password=12345

C. kubectl create secret generic mysecret --from-literal=password=12345

D. kubectl create secret mysecret --from-file=password=12345

Solution

1. Step 1: Recall the correct kubectl syntax for Secrets

   The command to create a generic Secret from literal values is 'kubectl create secret generic'.

2. Step 2: Verify the options

   kubectl create secret generic mysecret --from-literal=password=12345 uses the correct syntax. kubectl secret create mysecret --literal=password=12345 uses wrong command structure. kubectl create configmap mysecret --from-literal=password=12345 creates a ConfigMap, not a Secret. kubectl create secret mysecret --from-file=password=12345 uses incorrect flag for literal.

3. Final Answer:

   kubectl create secret generic mysecret --from-literal=password=12345 -> Option C

4. Quick Check:

   Correct Secret creation syntax = A [OK]

Hint: Use 'kubectl create secret generic' for literals [OK]

Common Mistakes:

• Using 'kubectl secret create' which is invalid
• Confusing ConfigMap creation with Secret
• Using --from-file instead of --from-literal for literals

3. Given this Secret YAML snippet, what will be the decoded value of the key api-key?

apiVersion: v1
kind: Secret
metadata:
  name: mysecret
data:
  api-key: YXBpa2V5MTIz

medium

A. apikey123

B. api-key123

C. YXBpa2V5MTIz

D. api_key_123

Solution

1. Step 1: Understand base64 encoding in Secrets

   Kubernetes Secrets store data base64 encoded. The value 'YXBpa2V5MTIz' is base64 encoded.

2. Step 2: Decode the base64 string

   Decoding 'YXBpa2V5MTIz' gives 'apikey123'.

3. Final Answer:

   apikey123 -> Option A

4. Quick Check:

   Base64 decode 'YXBpa2V5MTIz' = apikey123 [OK]

Hint: Decode base64 to read Secret values [OK]

Common Mistakes:

• Using the encoded string as the value
• Confusing underscores and hyphens
• Not decoding base64 before reading

4. You tried to create a Secret with this command but got an error: kubectl create secret generic mysecret --from-literal=password. What is the problem?

medium

A. Missing value for the literal key

B. Secret name is invalid

C. Command should use --from-file instead

D. Secrets cannot be created from literals

Solution

1. Step 1: Analyze the command syntax

   The command uses --from-literal=password but does not provide a value after '='.

2. Step 2: Identify the error cause

   --from-literal requires a key=value pair. Missing value causes syntax error.

3. Final Answer:

   Missing value for the literal key -> Option A

4. Quick Check:

   Literal needs key=value format = A [OK]

Hint: Always provide key=value with --from-literal [OK]

Common Mistakes:

• Omitting the value after '='
• Using wrong flags for literals
• Assuming Secrets can't be created from literals

5. You want to mount a Secret containing database credentials into a Pod as environment variables. Which approach best protects sensitive data from being exposed in the Pod spec?

hard

A. Write the credentials directly in the Pod spec environment variables

B. Encode credentials in base64 and write them in the Pod spec environment variables

C. Store credentials in a ConfigMap and reference it in the Pod spec

D. Reference the Secret in the Pod spec environment variables using secretKeyRef

Solution

1. Step 1: Understand how to use Secrets in Pods

   Using secretKeyRef in environment variables references Secrets securely without exposing raw data in Pod spec.

2. Step 2: Evaluate other options

   Writing credentials directly or in ConfigMaps exposes sensitive data. Base64 encoding alone is not secure as it is easily decoded.

3. Final Answer:

   Reference the Secret in the Pod spec environment variables using secretKeyRef -> Option D

4. Quick Check:

   Use secretKeyRef to protect sensitive env vars = B [OK]

Hint: Use secretKeyRef to keep secrets safe in Pods [OK]

Common Mistakes:

• Putting raw passwords in Pod spec
• Using ConfigMaps for sensitive data
• Relying on base64 as encryption