Secrets

Configuration Management: Secrets

In the world of cloud-native applications, sensitive data—like passwords, API keys, and tokens—presents a critical challenge. When improperly handled, this data can leak into your infrastructure, compromise security, and lead to devastating breaches. Kubernetes provides robust mechanisms to manage secrets securely, but understanding why and how secrets work is foundational to building resilient systems. This section dives into the realities of sensitive data in Kubernetes and the role of base64 encoding in secret management.

Sensitive Data

Sensitive data refers to any information that, if exposed, could cause significant harm to your application, users, or infrastructure. In Kubernetes contexts, this includes:

• Database credentials
• API tokens
• SSH keys
• OAuth tokens
• Payment processing details
• Environment variables for production systems

Why sensitive data is dangerous in Kubernetes

Hardcoding secrets in configuration files (like docker-compose.yml or kubectl apply commands) creates a fundamental security flaw. When these files are committed to version control or accidentally exposed in logs, the secrets become unrecoverable. Here’s a real-world example of a dangerous practice:

<code class="language-yaml"># This is a dangerous practice: hardcoding credentials in a config file
<p>apiVersion: v1</p>
<p>kind: ConfigMap</p>
<p>metadata:</p>
<p>  name: app-config</p>
<p>data:</p>
<p>  DB_PASSWORD: "letmein123!"  # This password is exposed in version control!</code>

The consequences? If this file leaks, attackers gain full access to your database. Kubernetes addresses this through secrets, which are designed specifically to store sensitive information securely within the cluster.

How Kubernetes secrets work

Kubernetes secrets are encrypted key-value stores that:

1. Store data in the cluster’s etcd database (with encryption at rest in production clusters)
2. Are never exposed in plaintext to users or pods
3. Can be dynamically injected into pods via volume mounts
4. Are automatically rotated through cluster policies

Unlike config maps (which store non-sensitive data), secrets are treated as high-security assets. When you create a secret, Kubernetes:

• Generates a unique key for the secret
• Stores the actual secret data in encrypted form (not base64-encoded)
• Provides read-only access to pods that explicitly request it

Here’s how to create a secure secret:

<code class="language-bash">kubectl create secret generic database-creds \
<p>  --from-literal=DB_USER="admin" \</p>
<p>  --from-literal=DB<em>PASSWORD="secure</em>password_123" \</p>
<p>  --from-literal=DB_HOST="postgres.example.com"</code>

This command creates a secret named database-creds with three sensitive fields. Crucially, the actual password is never printed in plaintext—Kubernetes handles the encryption internally.

Base64 Encoding

Base64 encoding is a text representation of binary data that’s widely used in Kubernetes to safely transmit secrets over text-based interfaces (like API requests). It’s not encryption—it’s a reversible encoding scheme that converts binary data into ASCII characters. Here’s why it matters in Kubernetes:

Why Kubernetes uses base64

When you create a secret via kubectl create secret, Kubernetes encodes the secret values in base64 for two key reasons:

1. Compatibility: Kubernetes APIs are text-based (JSON), so base64 allows binary secrets (like passwords) to be stored as strings without corruption.
2. Minimal security overhead: Base64 is reversible but not cryptographically secure. This is intentional—it’s a step in the secret lifecycle, not the final security layer.

The base64 misconception: It’s not encryption!

Many developers mistakenly think base64-encoding = encryption. This is false. Base64 is just a translation layer—it doesn’t protect data from unauthorized access. For example:

• If you base64-encode a password: echo -n "password123" | base64 → cGFzdG9yZDEyMw==
• If an attacker intercepts this string, they can easily decode it back to plaintext using echo "cGFzdG9yZDEyMw==" | base64 -d

This is why Kubernetes never stores secrets in base64 in production clusters—the actual secrets are encrypted at rest (via etcd encryption) and only decoded within the secure context of the pod.

Real-world example: Base64 in action

Let’s see how base64 fits into the secret workflow. First, create a secret with a password:

<code class="language-bash"># Encode a password in base64 (this is what Kubernetes does internally)
<p>echo -n "password123" | base64</p>
<h1>Output: cGFzdG9yZDEyMw==</code>

Now, when Kubernetes mounts this secret into a pod, it decodes the base64 string to retrieve the original password:

<code class="language-yaml"># Pod spec that uses the secret
<p>apiVersion: v1</p>
<p>kind: Pod</p>
<p>metadata:</p>
<p>  name: secure-app</p>
<p>spec:</p>
<p>  containers:</p>
<p>  - name: app</p>
<p>    image: my-secure-app:latest</p>
<p>    env:</p>
<p>    - name: DB_PASSWORD</p>
<p>      valueFrom:</p>
<p>        secretKeyRef:</p>
<p>          name: database-creds</p>
<p>          key: DB_PASSWORD</code>

Here’s what happens under the hood:

1. Kubernetes retrieves the DB_PASSWORD value from the secret
2. The secret is stored as cGFzdG9yZDEyMw== in etcd
3. The pod’s kubelet decodes the base64 string to password123 before injecting it into the pod’s environment

Critical security implications

Scenario	Security Risk	Kubernetes Mitigation
Base64 in version control	Secrets exposed in logs or repos	Never commit secrets to version control
Base64 in pod logs	Secrets leaked via debugging tools	Use kubectl get secret with --output=json
Base64 in API requests	Secrets intercepted in transit	Always use TLS (e.g., --insecure-skip-tls-verify for testing)

Key takeaway: Base64 is a temporary encoding step in Kubernetes secrets workflows. It enables safe transmission but does not provide security—the real protection comes from Kubernetes’ encryption at rest, access controls, and secure pod injection.

Summary

In this section, we’ve explored how sensitive data requires special handling in Kubernetes, and why base64 encoding plays a critical—but often misunderstood—role in secret management. Remember: never hardcode secrets in configuration files, and always use Kubernetes Secrets to store sensitive information. Base64 is a reversible encoding mechanism that Kubernetes uses internally to transmit secrets over text-based interfaces, but it does not encrypt data—this is why Kubernetes secrets are encrypted at rest (via etcd) and only decoded within secure pod contexts. 🔒