Base64 encoding in Secrets in Kubernetes - Commands & Configuration

Introduction

Kubernetes Secrets store sensitive data like passwords or tokens. They require data to be encoded in base64 to keep the content safe and compatible with the system.

When you want to store a database password securely in Kubernetes.

When you need to pass an API key to your application without exposing it in plain text.

When configuring TLS certificates as secrets for your services.

When you want to avoid putting sensitive environment variables directly in pod specs.

When sharing credentials between multiple pods securely.

Config File - secret.yaml

secret.yaml

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

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

The data section holds key-value pairs where values are base64 encoded strings.

Here, username is encoded as bXl1c2Vy which decodes to 'myuser', and password is c2VjdXJlcGFzcw== which decodes to 'securepass'.

Commands

Encode the username 'myuser' to base64 format to store in the Secret.

Terminal

echo -n 'myuser' | base64

Expected Output

bXl1c2Vy

→

-n - Prevents echo from adding a newline character

Encode the password 'securepass' to base64 format for the Secret.

Terminal

echo -n 'securepass' | base64

Expected Output

c2VjdXJlcGFzcw==

→

-n - Prevents echo from adding a newline character

Create the Secret in Kubernetes using the base64 encoded data from the YAML file.

Terminal

kubectl apply -f secret.yaml

Expected Output

secret/my-secret created

Verify the Secret was created and view its base64 encoded data.

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: 123e4567-e89b-12d3-a456-426614174000

→

-o yaml - Outputs the Secret details in YAML format

Key Concept

If you remember nothing else from this pattern, remember: Kubernetes Secrets require all data values to be base64 encoded strings.

Common Mistakes

Putting plain text passwords directly in the Secret YAML without base64 encoding.

Kubernetes will reject the Secret or treat the data incorrectly because it expects base64 encoded values.

Always encode your secret values using base64 before adding them to the Secret YAML.

Using echo without the -n flag when encoding, which adds a newline character.

The extra newline changes the encoded value, causing authentication failures or errors.

Use 'echo -n' to avoid adding a newline when encoding secrets.

Summary

Encode secret values using base64 before adding them to Kubernetes Secret YAML files.

Apply the Secret YAML with kubectl to create the secret in the cluster.

Verify the Secret data is stored base64 encoded by retrieving it with kubectl.

Practice

1. What is the main reason Kubernetes Secrets use Base64 encoding for their data?

easy

A. To compress the secret data to save space

B. To encrypt the secret data for security

C. To convert binary data into text format for safe storage

D. To convert text data into binary format for faster access

Solution

1. Step 1: Understand Base64 encoding purpose

   Base64 encoding changes binary data into readable text characters so it can be stored in text files or systems.

2. Step 2: Apply to Kubernetes Secrets

   Kubernetes Secrets store sensitive data as text in YAML files, so Base64 encoding is used to safely represent binary or special characters as text.

3. Final Answer:

   To convert binary data into text format for safe storage -> Option C

4. Quick Check:

   Base64 encoding = text format for storage [OK]

Hint: Base64 makes binary data safe as text in Secrets [OK]

Common Mistakes:

• Thinking Base64 encrypts data
• Confusing Base64 with compression
• Assuming Base64 changes data speed

2. Which of the following is the correct YAML snippet for a Kubernetes Secret with a key named password and value cGFzc3dvcmQ= (Base64 encoded)?

easy

A. apiVersion: v1
kind: Secret
stringData:
password: cGFzc3dvcmQ=

B. apiVersion: v1
kind: Secret
data:
password: cGFzc3dvcmQ=

C. apiVersion: v1
kind: Secret
secrets:
password: cGFzc3dvcmQ=

D. apiVersion: v1
kind: Secret
values:
password: cGFzc3dvcmQ=

Solution

1. Step 1: Identify correct field for Base64 data

   Kubernetes Secrets use the data field to store Base64 encoded values.

2. Step 2: Check YAML structure

   The correct YAML must have apiVersion, kind, and data with the key and Base64 value.

3. Final Answer:

   apiVersion: v1 kind: Secret data: password: cGFzc3dvcmQ= -> Option B

4. Quick Check:

   Base64 data goes under data field [OK]

Hint: Base64 values go under 'data', not 'stringData' or others [OK]

Common Mistakes:

• Using stringData for Base64 encoded values
• Wrong field names like secrets or values
• Missing apiVersion or kind fields

3. Given this command:
kubectl create secret generic mysecret --from-literal=username=admin --from-literal=password=pass123
What will be the Base64 encoded value of the password key in the Secret?

medium

A. cGFzczEyMw==

B. cGFzc3dvcmQ=

C. cGFzc3dvcmQxMjM=

D. cGFzc3dvcmQxMjM0

Solution

1. Step 1: Identify the literal value for password

   The password literal is pass123.

2. Step 2: Base64 encode 'pass123'

   Encoding 'pass123' in Base64 results in cGFzczEyMw==.

3. Final Answer:

   cGFzczEyMw== -> Option A

4. Quick Check:

   Base64('pass123') = cGFzczEyMw== [OK]

Hint: Encode exact literal value, not similar words [OK]

Common Mistakes:

• Encoding 'password' instead of 'pass123'
• Missing padding characters '=='
• Confusing similar Base64 strings

4. You created a Secret YAML with this data field:
data: apiKey: mysecretkey
What is the problem with this Secret definition?

medium

A. The value 'mysecretkey' is not Base64 encoded

B. The key 'apiKey' is invalid in Secrets

C. The data field should be named stringData

D. The Secret kind is missing

Solution

1. Step 1: Check the data field requirements

   The data field requires Base64 encoded values, not plain text.

2. Step 2: Identify the error in the value

   The value 'mysecretkey' is plain text and must be Base64 encoded before placing under data.

3. Final Answer:

   The value 'mysecretkey' is not Base64 encoded -> Option A

4. Quick Check:

   data values must be Base64 encoded [OK]

Hint: data field values must be Base64, else error [OK]

Common Mistakes:

• Putting plain text in data instead of Base64
• Confusing data with stringData field
• Ignoring required apiVersion and kind fields

5. You want to create a Kubernetes Secret from a file config.json containing JSON data. Which command correctly creates the Secret with Base64 encoding handled automatically?

hard

A. kubectl create secret generic myconfig --from-file=config.json --encode

B. kubectl create secret generic myconfig --from-literal=config.json=$(cat config.json | base64)

C. kubectl create secret generic myconfig --from-literal=config.json=config.json

D. kubectl create secret generic myconfig --from-file=config.json

Solution

1. Step 1: Understand kubectl create secret from-file option

   The --from-file option reads the file and automatically Base64 encodes its content for the Secret.

2. Step 2: Evaluate other options

   kubectl create secret generic myconfig --from-literal=config.json=$(cat config.json | base64) manually encodes but is unnecessary; kubectl create secret generic myconfig --from-literal=config.json=config.json uses literal text; kubectl create secret generic myconfig --from-file=config.json --encode uses a non-existent flag.

3. Final Answer:

   kubectl create secret generic myconfig --from-file=config.json -> Option D

4. Quick Check:

   Use --from-file to auto Base64 encode files [OK]

Hint: Use --from-file to auto Base64 encode file content [OK]

Common Mistakes:

• Manually encoding file content before command
• Using wrong flags like --encode
• Passing file name as literal string