06: Secrets — podstawy i użycie jako env

Secrets w Kubernetes: podstawy i użycie jako zmienne środowiskowe

15 min

Cel zadania

Celem zadania jest nauka tworzenia Secrets w Kubernetes i używania ich jako zmiennych środowiskowych — analogicznie do ConfigMap poznanego w poprzednim ćwiczeniu.

Teoria

Secrets w Kubernetes

• Secret: Obiekt przechowujący wrażliwe dane jako pary klucz-wartość
• Zastosowanie: Oddzielenie wrażliwych danych od definicji Pod
• Kodowanie: Wartości w Secrets są kodowane w base64
• Typy Secrets:
  • Opaque — domyślny typ dla dowolnych danych
  • kubernetes.io/tls — certyfikaty TLS (poznasz w późniejszym ćwiczeniu)

Porównanie z ConfigMap

| Cecha | ConfigMap | Secret | |——-|———–|——–| | Przeznaczenie | Dane konfiguracyjne | Wrażliwe dane | | Kodowanie | Tekst jawny | base64 | | Użycie w env | configMapKeyRef | secretKeyRef | | Użycie envFrom | configMapRef | secretRef |

Dlaczego nie trzymać haseł w ConfigMap?

• ConfigMap przechowuje dane jako tekst jawny — każdy z dostępem do API widzi wartości
• Secret koduje dane w base64 — uwaga: to nie jest szyfrowanie! Base64 to tylko kodowanie, które można łatwo odkodować
• Prawdziwe bezpieczeństwo Secrets wynika z:
  • Ograniczenia dostępu przez RBAC (kto może czytać Secrets)
  • Możliwości szyfrowania etcd at rest (szyfrowanie w bazie danych)
  • Kubernetes nie loguje zawartości Secrets w eventach
• Zasada: Jeśli dane są wrażliwe (hasła, tokeny, klucze API) — zawsze użyj Secret, nigdy ConfigMap

Zadanie 1: Tworzenie Secrets

1.1. Utwórz Secret z pliku YAML

Utwórz plik app-secrets-XX.yaml:

apiVersion: v1
kind: Secret
metadata:
  name: app-secrets-XX
type: Opaque
data:
  username: YWRtaW4=        # base64 encoded 'admin'
  password: cGFzc3dvcmQxMjM= # base64 encoded 'password123'

Aby zakodować wartość w base64:

echo -n 'admin' | base64
echo -n 'password123' | base64

kubectl apply -f app-secrets-XX.yaml

1.2. Tworzenie Secret z linii poleceń

# Tworzenie secret z wartości literalnych
kubectl create secret generic db-secrets-XX \
  --from-literal=username=admin \
  --from-literal=password=password123

# Sprawdzenie utworzonego secretu
kubectl get secret db-secrets-XX -o jsonpath='{.data}'

Zadanie 2: Używanie Secrets jako zmiennych środowiskowych

2.1. Pod z secretKeyRef

Utwórz plik kuard-secrets-XX.yaml:

apiVersion: v1
kind: Pod
metadata:
  name: kuard-secrets-XX
spec:
  containers:
  - name: kuard
    image: gcr.io/kuar-demo/kuard-amd64:1
    ports:
      - containerPort: 8080
        name: http
    env:
    - name: DB_USERNAME
      valueFrom:
        secretKeyRef:
          name: db-secrets-XX
          key: username
    - name: DB_PASSWORD
      valueFrom:
        secretKeyRef:
          name: db-secrets-XX
          key: password

kubectl apply -f kuard-secrets-XX.yaml

# Uruchom port-forward aby zobaczyć UI
kubectl port-forward pod/kuard-secrets-XX 8080:8080

# Otwórz http://localhost:8080 i przejdź do zakładki "ENV" aby zobaczyć secrets

Zadanie 3: Weryfikacja

3.1. Sprawdzanie Secrets przez kubectl

# Lista wszystkich Secrets
kubectl get secrets

# Dekodowanie Secret
kubectl get secret app-secrets-XX -o jsonpath='{.data.username}' | base64 --decode

# Sprawdzanie zmiennych środowiskowych w Pod
kubectl exec kuard-secrets-XX -- env | grep DB_

Najczęstsze problemy

Dobre praktyki

1. Bezpieczeństwo
   • Nigdy nie przechowuj Secrets w repozytorium
   • Używaj RBAC do ograniczenia dostępu
   • Regularnie rotuj hasła
2. Organizacja
   • Grupuj powiązane dane w jednym Secret
   • Używaj opisowych nazw
   • Dokumentuj strukturę i przeznaczenie Secrets

Podsumowanie

• Secrets przechowują wrażliwe dane zakodowane w base64
• Używamy secretKeyRef zamiast configMapKeyRef — wzorzec jest identyczny
• Secrets można tworzyć z YAML lub CLI (kubectl create secret generic)
• W następnych ćwiczeniach poznasz montowanie Secrets jako wolumeny oraz certyfikaty TLS