📖 Scenario: You are working on a Kubernetes cluster for a small company. You need to store sensitive information like passwords and API keys safely so that only the right parts of your applications can use them.
🎯 Goal: Learn how to create and use Kubernetes Secrets to manage sensitive data securely in your cluster.
📋 What You'll Learn
Create a Kubernetes Secret with exact key-value pairs
Add a configuration variable to reference the Secret name
Use the Secret in a Pod specification environment variable
Display the Pod environment variable to confirm Secret usage
💡 Why This Matters
🌍 Real World
Kubernetes Secrets help keep sensitive information safe and separate from application code, preventing accidental exposure.
💼 Career
Managing Secrets is a key skill for DevOps engineers and system administrators working with Kubernetes clusters.
Progress0 / 4 steps
1
Create a Kubernetes Secret with sensitive data
Create a Kubernetes Secret named mysecret with these exact key-value pairs: username: admin and password: s3cr3t using the kubectl command.
Kubernetes
Hint
Use kubectl create secret generic with --from-literal for each key-value pair.
2
Add a variable for the Secret name
Create a variable called SECRET_NAME and set it to the string mysecret.
Kubernetes
Hint
Use SECRET_NAME=mysecret to store the Secret name in a variable.
3
Use the Secret in a Pod environment variable
Write a Pod YAML snippet that uses the Secret named mysecret to set environment variables USERNAME and PASSWORD from the Secret keys username and password. Use the variable SECRET_NAME for the Secret name in the YAML.
Kubernetes
Hint
Use env with valueFrom.secretKeyRef referencing name: ${SECRET_NAME} and the correct keys.
4
Display the Pod environment variables to confirm Secret usage
Print the Pod YAML stored in the variable pod_yaml to show the environment variables set from the Secret.
Kubernetes
Hint
Use print(pod_yaml) to display the Pod YAML content.
Practice
(1/5)
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
Step 1: Understand the purpose of Secrets
Kubernetes Secrets are designed to store sensitive information like passwords and keys securely.
Step 2: Compare with other options
Secrets do not speed up deployment, store large files, or replace ConfigMaps entirely.
Final Answer:
To keep passwords and keys hidden from plain view -> Option B
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
Step 1: Recall the correct kubectl syntax for Secrets
The command to create a generic Secret from literal values is 'kubectl create secret generic'.
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.
Final Answer:
kubectl create secret generic mysecret --from-literal=password=12345 -> Option C
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?
Kubernetes Secrets store data base64 encoded. The value 'YXBpa2V5MTIz' is base64 encoded.
Step 2: Decode the base64 string
Decoding 'YXBpa2V5MTIz' gives 'apikey123'.
Final Answer:
apikey123 -> Option A
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
Step 1: Analyze the command syntax
The command uses --from-literal=password but does not provide a value after '='.
Step 2: Identify the error cause
--from-literal requires a key=value pair. Missing value causes syntax error.
Final Answer:
Missing value for the literal key -> Option A
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
Step 1: Understand how to use Secrets in Pods
Using secretKeyRef in environment variables references Secrets securely without exposing raw data in Pod spec.
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.
Final Answer:
Reference the Secret in the Pod spec environment variables using secretKeyRef -> Option D
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
Recommended
Ready to prove it?
Pass the test and this pattern moves unknownstrongwhile earning +1 Grip toward your certificate.