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:

```yaml
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:

```yaml
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:

```bash
# 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:

```bash
# 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:

```bash
# 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?