Kubernetes Day-7: Securing Sensitive Data with Secrets in Kubernetes

In the previous session, we successfully deployed a multi-tier WordPress application connected to MySQL on Kubernetes. During that setup, we passed database credentials using environment variables directly through the CLI and YAML files.

Although that approach works technically, it is not secure.

In today’s session, we will correct that mistake and learn how to securely manage sensitive information in Kubernetes using Secrets.

This is a very important real-world concept, especially if you want to work professionally with Kubernetes.

Why Passing Credentials Directly is Dangerous

Earlier, we configured MySQL like this:

env:
  - name: MYSQL_ROOT_PASSWORD
    value: redhat

This creates multiple security risks:

1. Password visible in kubectl describe
Anyone who runs:

kubectl describe pod mydb

can see the environment variables including the password.

2. Password visible in terminal history

If credentials are passed through CLI commands, anyone running:

history

can view the password.

3. Password visible in YAML files

If multiple team members are working on the same YAML file, everyone can see the credentials.

Imagine a team of four developers. As a manager, you may need to provide database credentials — but you don’t want everyone to see the password.

So what is the solution?

Introducing Kubernetes Secrets

Kubernetes provides a special resource called a Secret.

A Secret is used to store sensitive information such as:

• Passwords

• Usernames

• Tokens

• API keys

• Certificates

Instead of writing credentials directly inside the Pod YAML, we store them in a Secret and reference them inside the Pod.

Think of a Secret as a small vault managed by Kubernetes.

Important: Encoding vs Encryption

By default, Kubernetes Secrets use Base64 encoding.

Base64:

• Converts text into encoded format

• Can easily be decoded

• Is NOT encryption

This means Secrets are not fully secure by default. They simply prevent casual viewing.

In production environments, encryption at rest can be enabled, but for now we focus on understanding the basics.

Structure of a Secret

Secrets store data in key-value pairs.

Example:

• Username → vimal

• Password → redhat

Before storing them in a Secret YAML file, we encode them in Base64.

How to Encode Values

You can encode text using Linux:

echo -n "redhat" | base64

Output:

cmVkaGF0

Now we use this encoded value inside our Secret file.

Creating a Secret Using YAML

Create a file called secret.yaml:

apiVersion: v1
kind: Secret
metadata:
  name: mysecret
type: Opaque
data:
  username: dmltYWw=
  password: cmVkaGF0

Where:

• dmltYWw= → Base64 for vimal

• cmVkaGF0 → Base64 for redhat

Now create the Secret:

kubectl create -f secret.yaml

Verify:

kubectl get secrets

Describing a Secret

Run:

kubectl describe secret mysecret

You will see:

Data
====
username: 5 bytes
password: 6 bytes

Notice:

• Kubernetes does NOT show the actual password.

• It only shows the size of the stored value.

This provides basic protection.

Using Secret Inside a Pod

Now instead of writing:

value: redhat

We reference the Secret:

env:
  - name: MYSQL_ROOT_PASSWORD
    valueFrom:
      secretKeyRef:
        name: mysecret
        key: password

Explanation:

• valueFrom → fetch value from another resource

• secretKeyRef → reference to Secret

• name → Secret name

• key → specific key inside the Secret

YAML indentation is very important. One wrong space can cause configuration errors.

What Happens Now?

After creating the Pod and running:

kubectl describe pod mydb

You will see something like:

MYSQL_ROOT_PASSWORD: <set to the key 'password' in secret 'mysecret'>

The password is no longer visible.

This is the correct professional approach.

Can We Still View the Password?

Yes. we can view the password

Run:

kubectl get secret mysecret -o yaml

You will see:

data:
  password: cmVkaGF0

To decode:

echo "cmVkaGF0" | base64 --decode

Output:

redhat

Again Base64 encoding does NOT fully secure data. It only hides it from direct display.

Creating Secret Directly from CLI

You can also create a Secret using:

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

Breakdown:

• create secret → create Secret resource

• generic → general-purpose Secret

• mysecret → Secret name

• --from-literal → key-value pair

Kubernetes automatically encodes the value.

However, this method is not recommended for highly sensitive data because the password may appear in terminal history.

Understanding How Kubernetes Processes Everything

Whether we use:

• CLI commands

• YAML files

• API calls

Everything ultimately communicates with the Kubernetes API Server.

For example:

kubectl run myweb --image=nginx

Internally, Kubernetes converts this command into a YAML/JSON definition and sends it to the API server.

You can view any resource definition using:

kubectl get pod myweb -o yaml

Understanding this helps you think like a Kubernetes administrator.

Key Takeaways

✔ Never store passwords directly in Pod YAML

✔ Use Kubernetes Secrets for sensitive data

✔ Base64 encoding is not encryption

✔ Avoid passing credentials directly via CLI

✔ Always reference Secrets using valueFrom

This concept is extremely important in real-world Kubernetes environments.

Conclusion

In this session, we learned why storing credentials directly inside Pod configurations is not a secure practice and how Kubernetes Secrets help us manage sensitive information in a more professional way.

We understood:

• The risks of exposing passwords via CLI and YAML

• How to create and manage Secrets

• How to reference Secrets securely inside Pods

• The difference between encoding and encryption

In the next session, we will move one step ahead and learn how to make our application data persistent so that it survives Pod restarts and deletions.