kubern-everything/08_Vault/README.md

Helm

Installation

helm repo add hashicorp https://helm.releases.hashicorp.com

helm install vault hashicorp/vault \
--set='server.dev.enabled=true'
--set='ui.enabled=true'
--set='ui.serviceType=LoadBalancer'
--namespace vault
--create-namespace

Running Vault in “dev” mode. This requires no further setup, no state management, and no initialization. This is useful for experimenting with Vault without needing to unseal, store keys, et. al. All data is lost on restart — do not use dev mode for anything other than experimenting. See https://developer.hashicorp.com/vault/docs/concepts/dev-server to know more

Output

$ kubectl get all -n vault
NAME                                        READY   STATUS    RESTARTS   AGE
pod/vault-0                                 1/1     Running   0          2m39s
pod/vault-agent-injector-8497dd4457-8jgcm   1/1     Running   0          2m39s

NAME                               TYPE           CLUSTER-IP       EXTERNAL-IP    PORT(S)             AGE
service/vault                      ClusterIP      10.245.225.169   <none>         8200/TCP,8201/TCP   2m40s
service/vault-agent-injector-svc   ClusterIP      10.245.32.56     <none>         443/TCP             2m40s
service/vault-internal             ClusterIP      None             <none>         8200/TCP,8201/TCP   2m40s
service/vault-ui                   LoadBalancer   10.245.103.246   24.132.59.59   8200:31764/TCP      2m40s

NAME                                   READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/vault-agent-injector   1/1     1            1           2m40s

NAME                                              DESIRED   CURRENT   READY   AGE
replicaset.apps/vault-agent-injector-8497dd4457   1         1         1       2m40s

NAME                     READY   AGE
statefulset.apps/vault   1/1     2m40s

Configuration

Enter Pod

kubectl exec -it vault-0 -n vault -- /bin/sh

Create policy

cat <<EOF > /home/vault/read-policy.hcl
path "secret*" {
  capabilities = ["read"]
}
EOF

Apply

vault policy write read-policy /home/vault/read-policy.hcl

Enable Kubernetes

vault auth enable kubernetes

Configure Kubernetes Auth

Configure to communicate with API server

vault write auth/kubernetes/config \
   token_reviewer_jwt="$(cat /var/run/secrets/kubernetes.io/serviceaccount/token)" \
   kubernetes_host=https://${KUBERNETES_PORT_443_TCP_ADDR}:443 \   kubernetes_ca_cert=@/var/run/secrets/kubernetes.io/serviceaccount/ca.crt

Create a Role

Create a role(vault-role) that binds the above policy to a Kubernetes service account(vault-serviceaccount) in a specific namespace. This allows the service account to access secrets stored in Vault:

vault write auth/kubernetes/role/vault-role \
   bound_service_account_names=vault-serviceaccount \
   bound_service_account_namespaces=vault \
   policies=read-policy \
   ttl=1h

Create Secrets

Via CLI

vault kv put secret/login pattoken=ytbuytbytbf765rb65u56rv

Via UI

Now you can login to vault using the Token method, initially use Token=root to login.

Accessing Secrets in Pods

Using the above steps, we have installed Vault and configured a Vault role(vault-role) to allow the service account(vault-serviceaccount) to access secrets stored in Vault.

Additionally, we have created two secrets: login and my-first-secret with key-value pairs. Now, let's create a simple Kubernetes deployment and try to access those secrets.

First, let’s create a service account named vault-serviceaccount in the vault namespace. This service account is granted permissions for the Vault role as defined in the "Create a Role" step above.

Apply the above manifest using the below command

kubectl apply -f vault-sa.yaml -n vault

This deployment manifest creates a single replica of an Nginx pod configured to securely fetch secrets from Vault. The Vault Agent injects the secrets login and my-first-secret into the pod according to the specified templates. The secrets are stored in the pod's filesystem and can be accessed by the application running in the container. The vault-serviceaccount service account, which has the necessary permissions, is used to authenticate with Vault.

kubectl apply -f vault-secret-test-deploy.yaml -n vault

These annotations are used to configure the Vault Agent to inject secrets into the pod volume.

-vault.hashicorp.com/agent-inject: “true”: Enables Vault Agent injection for this pod. -vault.hashicorp.com/agent-inject-status: “update”: Ensures the status of secret injection is updated. -vault.hashicorp.com/agent-inject-secret-login: “secret/login”: Specifies that the secret stored at secret/login in Vault should be injected. -vault.hashicorp.com/agent-inject-template-login: Defines the template for the injected login secret, specifying the format in which the secret will be written. -vault.hashicorp.com/agent-inject-secret-my-first-secret: “secret/my-first-secret”: Specifies that the secret stored at secret/my-first-secret in Vault should be injected. -vault.hashicorp.com/agent-inject-template-my-first-secret: Defines the template for the injected my-first-secret, specifying the format in which the secret will be written. -vault.hashicorp.com/role: “vault-role”: Specifies the Vault role to be used for authentication. -serviceAccountName: Uses the service account vault-serviceaccount which has permissions to access Vault.

Use the below command to check the vault secrets from the pod volume

kubectl exec -it vault-test-84d9dc9986-gcxfv -- sh -c "cat /vault/secrets/login && cat /vault/secrets/my-first-secret" -n vault

---

Wenn du Kubernetes mit Vault konfiguriert hast, ermöglichst du eine sichere Integration zwischen deinem Kubernetes-Cluster und HashiCorp Vault. Hier sind die wichtigsten Szenarien und Vorteile:

Hauptfunktionen

1. Automatische Pod-Authentifizierung

Pods können sich automatisch bei Vault authentifizieren, ohne dass du Credentials manuell verteilen musst. Vault nutzt Kubernetes Service Accounts zur Identitätsverifizierung.

2. Dynamische Secrets für Anwendungen

Anwendungen können zur Laufzeit Secrets von Vault abrufen, statt sie in ConfigMaps oder Kubernetes Secrets zu speichern.

Praktische Szenarien

Szenario 1: Vault Agent Sidecar Injection

Vault injiziert automatisch einen Sidecar-Container, der Secrets abruft und für deine App bereitstellt:

apiVersion: v1
kind: Pod
metadata:
  annotations:
    vault.hashicorp.com/agent-inject: "true"
    vault.hashicorp.com/role: "myapp"
    vault.hashicorp.com/agent-inject-secret-database: "database/creds/myapp-role"
spec:
  serviceAccountName: myapp
  containers:
  - name: app
    image: myapp:latest

Ergebnis: Datenbank-Credentials werden automatisch in /vault/secrets/database bereitgestellt.

Szenario 2: Dynamische Datenbank-Credentials

Statt statische DB-Passwörter zu verwenden, generiert Vault temporäre Credentials:

• Jeder Pod bekommt eigene DB-Credentials
• Credentials sind zeitlich begrenzt (z.B. 24h)
• Automatische Rotation
• Einfaches Widerrufen bei Kompromittierung

Szenario 3: Externe Secrets Operator (ESO)

Secrets werden als native Kubernetes Secrets synchronisiert:

apiVersion: external-secrets.io/v1beta1
kind: SecretStore
metadata:
  name: vault-backend
spec:
  provider:
    vault:
      server: "https://vault.test.k8s.schnrbs.work"
      path: "secret"
      auth:
        kubernetes:
          mountPath: "kubernetes"
          role: "myapp"

Szenario 4: Verschlüsselung als Service

Anwendungen können Vault's Transit Engine nutzen:

# Daten verschlüsseln ohne den Key zu kennen
vault write transit/encrypt/my-key plaintext=$(base64 <<< "sensitive data")

# Daten entschlüsseln
vault write transit/decrypt/my-key ciphertext="vault:v1:abc..."

Szenario 5: PKI/Zertifikats-Management

Automatische Ausstellung von TLS-Zertifikaten für Service-to-Service-Kommunikation:

• Kurzlebige Zertifikate (z.B. 1h)
• Automatische Rotation
• Zero-Trust-Netzwerk

Szenario 6: Multi-Tenancy

Verschiedene Namespaces/Teams haben isolierten Zugriff:

# Team A darf nur auf secret/team-a/* zugreifen
# Team B darf nur auf secret/team-b/* zugreifen

Vorteile gegenüber Kubernetes Secrets

Aspekt	Kubernetes Secrets	Vault Integration
Verschlüsselung at rest	Optional, etcd-Ebene	Immer, zusätzlich verschlüsselt
Secret Rotation	Manuell	Automatisch/dynamisch
Audit Log	Begrenzt	Detailliert für jeden Zugriff
Dynamische Secrets	Nein	Ja (DB, Cloud, etc.)
Granulare Policies	Begrenzt	Sehr feinkörnig
Encryption-as-a-Service	Nein	Ja

Typischer Workflow nach der Konfiguration

1. Policy erstellen: Definiere, wer auf welche Secrets zugreifen darf
2. Role erstellen: Verknüpfe Kubernetes Service Accounts mit Vault Policies
3. Secrets bereitstellen: Nutze Vault Agent Injection oder CSI Driver
4. Anwendung deployen: Pods authentifizieren sich automatisch

Best Practice Setup

Nach der Kubernetes Auth-Aktivierung solltest du:

# 1. Policy erstellen
vault policy write myapp - <<EOF
path "secret/data/myapp/*" {
  capabilities = ["read"]
}
EOF

# 2. Role erstellen
vault write auth/kubernetes/role/myapp \
  bound_service_account_names=myapp \
  bound_service_account_namespaces=production \
  policies=myapp \
  ttl=1h

# 3. Service Account in K8s erstellen
kubectl create serviceaccount myapp -n production

Möchtest du ein spezifisches Szenario genauer erkunden oder brauchst du Hilfe bei der Konfiguration eines bestimmten Use Cases?