03 - Implement Secrets

1. The Core Concept: What is a Secret and Why Use It?

What it is: A Secret is a Kubernetes object specifically designed to hold a small amount of sensitive data such as passwords, API keys, SSH keys, or database connection strings.

Why we use it: While ConfigMaps are for plain-text settings, putting a password like DB_PASSWORD in a ConfigMap allows anyone with access to the cluster (or your source code repository) to read it in plain text.

• The Bad Way: Hardcoding passwords in your code, or committing a secret.yaml file to GitHub with real passwords in it.
• The Kubernetes Way (Secrets): Store the sensitive data as a Kubernetes Secret. Kubernetes keeps it separate from your application code and injects it into your containers at runtime (usually keeping it in memory rather than writing it to disk).

2. Creating a Secret

Because Secrets are sensitive, it's often safer to create them directly from the command line rather than writing a YAML file that might accidentally get pushed to Git.

kubectl create secret generic app-secrets \
  --from-literal=DB_CONNECTION="Host=db;User=app;Password=secure" \
  --from-literal=API_KEY="your-api-key"

Explaining the Command:

• create secret generic: generic (also known as opaque) is the standard type for basic key-value pairs like passwords. (Note: Kubernetes has special types for other things, like tls for SSL certificates or dockerconfigjson for private registry logins).
• app-secrets: The name of the Secret we are creating.
• --from-literal=KEY="VALUE": This injects the key and value directly into the cluster without needing a YAML file on your hard drive.

3. Consuming a Secret

Once the Secret is in the cluster, you give it to your app (Pod) almost exactly the same way you do with ConfigMaps.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-api
spec:
  replicas: 2
  selector:
    matchLabels:
      app: web-api
  template:
    metadata:
      labels:
        app: web-api
    spec:
      containers:
      - name: api
        image: myregistry.azurecr.io/web-api:v1
        env:
        - name: DB_CONNECTION
          valueFrom:
            secretKeyRef:
              name: app-secrets     # Points to the Secret we made via CLI
              key: DB_CONNECTION    # Plucks the connection string out of it

Explaining the Code:

• valueFrom.secretKeyRef: This tells Kubernetes to look up a Secret (not a ConfigMap) named app-secrets, grab the DB_CONNECTION value, and inject it as an environment variable inside the container.
• Result: The application can now read the database connection string from its environment without ever knowing it came from a Kubernetes Secret.

4. Verification & Security

How do you check it worked without exposing the password to anyone looking over your shoulder?

# List all secrets
kubectl get secrets 

# Describe a specific secret
kubectl describe secret app-secrets

• What this does: When you run describe secret, Kubernetes is smart enough to show you that the keys (DB_CONNECTION, API_KEY) exist and how many bytes they are, but it hides the actual values so they don't print to your terminal screen.

5. Enterprise Secret Management (Azure Integrations)

In real-world production environments, native Kubernetes Secrets aren't always secure enough (for example, they are just base64 encoded by default, not heavily encrypted). Microsoft recommends two Azure integrations for serious workloads.

Method 1: Azure Key Vault + CSI Driver (Maximum Security)

The Problem: Storing passwords in Kubernetes means they are stored in the cluster's database (etcd). If someone hacks the cluster, they get the passwords. The Solution: The CSI Driver acts like a highly trained security guard. It fetches the password from a secure bank vault (Azure Key Vault) and holds it in the application's temporary memory (RAM). The password is never written to the cluster's hard drive.

Method 2: Azure App Configuration (Central Management)

The Problem: If you have 20 different microservices, configuring the CSI driver 20 times and managing 20 different sets of configurations is a nightmare for DevOps engineers. The Solution: Azure App Configuration is a master spreadsheet. You manage all 20 apps from one screen. For passwords, you just put a "pointer" (a link) to Key Vault. A background worker (the Kubernetes Provider) reads the spreadsheet, follows the pointers to get the real passwords, and does all the hard work of building standard Kubernetes Secrets for you.

6. Best Practices to Remember

• Never commit Secrets to source control.
• Use RBAC (Role-Based Access Control): Ensure only specific service accounts or admins have permission to run kubectl get secrets.
• Enable etcd encryption: If someone steals the hard drive of your Kubernetes control plane, encrypting the etcd database ensures they still can't read your secrets.