Secrets are not encrypted by default in Kubernetes - Step-by-Step Execution

Process Flow - Secrets are not encrypted by default

Create Secret YAML

↓

kubectl apply Secret

↓

Secret stored in etcd

↓

Secret stored as base64 (not encrypted)

↓

Anyone with etcd access can decode Secret

↓

Enable Encryption at Rest to protect Secret

This flow shows how Kubernetes stores Secrets by default as base64 in etcd without encryption, exposing them unless encryption at rest is enabled.

Execution Sample

Kubernetes

apiVersion: v1
kind: Secret
metadata:
  name: mysecret
data:
  password: cGFzc3dvcmQ=

This YAML creates a Kubernetes Secret named 'mysecret' with a base64 encoded password.

Process Table

Step	Action	Data Stored in etcd	Security State
1	Create Secret YAML with password 'password'	password encoded as cGFzc3dvcmQ=	Secret is base64 encoded, not encrypted
2	Apply Secret with kubectl	Secret saved in etcd as base64 string	Secret still not encrypted
3	Access etcd storage directly	Retrieve base64 string cGFzc3dvcmQ=	Secret can be decoded easily
4	Decode base64 string	Decoded value: 'password'	Secret exposed in plain text
5	Enable Encryption at Rest in Kubernetes	Secret stored encrypted in etcd	Secret protected from direct etcd access

💡 By default, Secrets are stored base64 encoded but not encrypted, so enabling encryption at rest is needed for protection.

Status Tracker

Variable	Start	After Step 1	After Step 2	After Step 3	After Step 5
Secret Data	none	password base64 encoded	stored base64 in etcd	retrieved base64 from etcd	stored encrypted in etcd

Key Moments - 3 Insights

Why is base64 encoding not the same as encryption?

Base64 encoding only changes the format to text; it does not hide the data. As shown in execution_table step 4, anyone can decode base64 to get the original secret.

What happens if someone accesses etcd directly without encryption enabled?

They can read Secrets easily because they are stored as base64 strings, which can be decoded to reveal the secret, as shown in execution_table step 3 and 4.

How does enabling Encryption at Rest change Secret storage?

Encryption at Rest stores Secrets encrypted in etcd, so even if someone accesses etcd, they cannot read the Secrets without the encryption keys, as shown in execution_table step 5.

Visual Quiz - 3 Questions

Look at the execution table, what is the format of the Secret stored in etcd after applying kubectl?

A Base64 encoded string

B Plain text

C Encrypted data

D Hashed value

💡 Hint

Check execution_table row 2 under 'Data Stored in etcd'

At which step does the Secret become readable in plain text?

A Step 2

B Step 3

C Step 4

D Step 5

💡 Hint

Look at execution_table where decoding happens

If Encryption at Rest is enabled, what changes in the Secret storage?

A Secrets are stored as base64 strings

B Secrets are stored encrypted in etcd

C Secrets are stored in plain text

D Secrets are deleted after use

💡 Hint

Refer to execution_table step 5 under 'Security State'

Concept Snapshot

Kubernetes Secrets are stored base64 encoded by default, not encrypted.
Base64 encoding only changes format, not security.
Anyone with etcd access can decode Secrets.
Enable Encryption at Rest to protect Secrets in etcd.
Encryption stores Secrets securely, preventing easy access.

Full Transcript

In Kubernetes, when you create a Secret, it is stored in etcd as a base64 encoded string, not encrypted. This means anyone who can access etcd can decode and read the Secret easily. The flow starts with creating a Secret YAML, applying it with kubectl, and storing it in etcd. Without encryption, the Secret is exposed. To protect Secrets, Kubernetes supports Encryption at Rest, which encrypts Secrets in etcd, making them safe from direct access. Base64 encoding is not encryption; it only changes the data format. Enabling Encryption at Rest is essential for securing sensitive data in Kubernetes.