secure k8 s

Wiki log

Append-only record of wiki operations. Newest entries at the bottom.

2026-05-19 — Bootstrap

Initial bootstrap of the wiki from raw/docs/ (316 files) and raw/blog/ (23 files), the upstream OpenBao documentation and blog.

  • Created wiki/index.md as TOC.
  • Created wiki/openbao.md as the top-level overview.
  • Created core concept pages: auth.md, secrets.md, policies.md, tokens.md, leases.md, seal-unseal.md, storage.md, high-availability.md, namespaces.md, identity.md.
  • Created subsystem pages: agent-and-proxy.md, audit.md, plugins.md, configuration.md, commands-cli.md, kubernetes-platform.md, upgrading.md, internals.md.
  • Created blog-timeline.md summarizing the 23 announcement / release / event posts chronologically.

Scope was a curated set of ~20 top-level concept pages rather than one summary page per source — per-source pages would be hundreds and add little above the existing source structure. Per-source pages can be added later as questions arise.

2026-05-19 — Added k8s-ha-setup

Added wiki/k8s-ha-setup.md — step-by-step procedure for bringing up an OpenBao HA cluster on Kubernetes with the Helm chart and integrated Raft storage. Driven by a how-to question from the user; the existing kubernetes-platform and high-availability pages covered the what but not the how.

Linked the new page from kubernetes-platform.md, high-availability.md, and index.md. Sources: raw/docs/platform/k8s/helm/examples/ha-with-raft.md, raw/docs/platform/k8s/helm/examples/ha-tls.md, and surrounding Helm/example files.

2026-05-19 — Added deployment-vm-vs-k8s

Added wiki/deployment-vm-vs-k8s.md — Entscheidungshilfe für Enterprise-Kunden, die zwischen einer klassischen VM-HA-Installation und einer Helm-basierten HA-Installation auf Kubernetes wählen. Gemeinsame Basis (Raft, Auto-Unseal, Audit), Vor-/Nachteile beider Varianten, Direktvergleichs-Tabelle und das hybride Default-Muster (zentrales VM-HA + K8s-External-Mode). Linked von index.md. Sources: bestehende Wiki-Seiten zu HA/Storage/Helm sowie raw/docs/install.md, raw/docs/platform/k8s/, raw/docs/configuration/seal/.

2026-05-19 — Added raft

Added wiki/raft.md — didaktischer Artikel “von Anfänger bis Profi”. Sechs Levels: (1) das Problem (Konsens-Bedarf, CAP-Einordnung), (2) Mechanik (Knotenzustände, Terms, Election, Log-Replikation, Quorum, Heartbeats), (3) Raft in OpenBao (Integrated Storage, Join-Prozess, mTLS, retry_join, Voter/Non-Voter, Autopilot), (4) Profi-Betrieb (Sizing, paarweises Skalieren, performance_multiplier, Snapshots, Entry-Limits, Telemetry-SLOs, Operator-Cheat-Sheet), (5) Recovery (Quorum erhalten vs verloren, peers.json, Snapshot-Restore), (6) Antipatterns. Bisher gab es nur Raft-Erwähnungen in internals.md, storage.md, high-availability.md, aber keine zusammenhängende Lernkurve. Linked von index.md. Sources: raw/docs/internals/integrated-storage.md, raw/docs/concepts/integrated-storage/*, raw/docs/configuration/storage/raft.md, raw/docs/commands/operator/raft.md, raw/docs/internals/telemetry/metrics/raft.md.

2026-05-19 — Added backups

Added wiki/backups.md — eigene Seite für Backup-/Restore-Strategie, da das Thema vorher quer über storage.md (Stub), raft.md (Snapshot-Mechanik) und upgrading.md (Snapshot-vor-Upgrade) verteilt war. Inhalte: was gesichert wird (Daten + Seal-Material), Wofür/Wofür-nicht (Abgrenzung gegen HA), Integrated-Storage-Snapshot-Mechanik, Abgrenzung Raft-interne vs. operator-getriggerte Snapshots, Offline-vs.-Online-Empfehlung, Automatisierung über openbao-snapshot-agent (VM-systemd und Helm-CronJob mit values.yaml-Beispiel und Policy/Auth-Role), Restore-Verfahren, Anti-Patterns. Linked von index.md und storage.md. Sources: raw/docs/concepts/storage.md, raw/docs/commands/operator/raft.md, raw/docs/platform/k8s/helm/examples/snapshot-cronjob.md, raw/docs/configuration/storage/raft.md, raw/docs/internals/integrated-storage.md.

2026-05-19 — Updated k8s-ha-setup: Helm-Repo hinzufügen

Ergänzt um einen neuen Schritt “1 — Add the OpenBao Helm chart repository” mit helm repo add openbao https://openbao.github.io/openbao-helm, helm repo update, helm search repo openbao/openbao sowie Alternativen (Terraform, lokaler Clone). Bisherige Schritte 1–4 zu 2–5 umnummeriert; Prerequisites-Eintrag “openbao/openbao Helm repo configured” entfernt, da jetzt eigener Schritt. Source: raw/docs/platform/k8s/helm/terraform.md (Repo-URL), raw/docs/platform/k8s/helm/run.md (helm search).

2026-05-20 — Added k8s-backups

Neue Seite wiki/k8s-backups.md — K8s-spezifisches Backup-/Restore-Runbook, komplementär zur konzeptionellen backups-Seite (die das Warum und Was erklärt; die neue Seite ist das Wie auf Kubernetes). Bisheriger K8s-Abschnitt in backups.md war kurz (snapshotAgent values + Policy/Role). Neue Seite vertieft Restore-Verfahren auf K8s, Drei-Schichten-Modell, Sandbox-Tests, Monitoring/Alerting, NetworkPolicies und Antipatterns. Aufbau: (0) Drei-Schichten-Tabelle (Raft-Snapshot + Seal-Material + Cluster-Manifests) mit Verlustfolgen, (1) Helm-snapshotAgent-Variante: S3-Credentials als Sealed-/External-Secret, IAM ohne Delete-Right, Bucket-Lifecycle, Policy + kubernetes-Auth-Role mit ttl=1h, values-Block, Verifikation per kubectl create job --from=cronjob, (2) eigener CronJob als Alternative für Sonderfälle (Nicht-S3-Endpoint, age/gpg-Verschlüsselung, AppRole-Auth) mit komplettem YAML inkl. concurrencyPolicy: Forbid, backoffLimit: 2, KMS-SSE auf S3, BAO_ADDR auf openbao-active, (3) Schicht 2 Seal-Material: KMS Cross-Region-Replication, Transit-Token, Shamir-Shards niemals in K8s/Git, (4) Schicht 3 Manifeste: Git-Repo mit Secrets via Sealed/External Secrets, Velero als Sekundär-Layer (PVCs explizit ausschließen!), etcd-Snapshots der K8s-Distribution, (5) CiliumNetworkPolicy für den Snapshot-Pfad: Egress auf OpenBao-Service, kube-apiserver, DNS, S3-FQDN, (6) Restore-Verfahren Schritt-für-Schritt im laufenden Cluster (Snapshot holen, kubectl cp, snapshot restore auf dem Leader, Verifikation) plus Full-Disaster-Recovery-Sequenz (K8s wiederherstellen → cert-manager → Helm → openbao-0 unsealen → restore → weitere Pods unsealen), (7) Sandbox-Test-Restore mit Network-Isolation gegen Cred-Rotation in Production, (8) Monitoring: Prometheus-Queries auf kube_cronjob_status_last_successful_time (stale), Snapshot-Größen-Anomalien (24h-Vergleich), Bucket-Probe, Audit-Trail-Bestätigung, (9) Antipatterns (Snapshot ins PVC, plain S3-Secret, fehlendes Forbid, Recovery-Keys in K8s-Secret, Velero allein, Schedule-vs-RPO-Mismatch, kein Test-Restore, Bucket im selben Account), (10) Minimal-Checkliste für Production-Ready. Verlinkt aus index.md und mit Cross-Ref aus backups.md (am Anfang des K8s-Abschnitts und in Related). Sources: raw/docs/platform/k8s/helm/examples/snapshot-cronjob.md, raw/docs/commands/operator/raft.md, raw/docs/concepts/storage.md, raw/docs/configuration/storage/raft.md. Velero/SealedSecrets/kube-state-metrics-Schritte folgen Upstream-Docs.

2026-05-20 — Added k3s-ha-setup

Neue Seite wiki/k3s-ha-setup.md — End-to-End-Runbook für OpenBao HA auf k3s mit 3 stacked Nodes (jeder Node gleichzeitig Control-Plane mit embedded etcd und Workload-Host). Dritte Distro-Variante neben kubeadm (k8s-ha-from-scratch) und RKE2 (rke2-ha-setup); k3s ist die Light-Variante mit eingebauter containerd, Flannel, kube-proxy, CoreDNS, Traefik und local-path-Provisioner — Pre-Flight kürzer, Footprint kleiner. Aufbau: (0) Vergleichs-Tabelle kubeadm vs. k3s vs. RKE2 mit Entscheidungshilfe wann welche Variante, (1) Architektur-Diagramm 3 stacked Nodes mit VIP-Layer, (2) Pre-Reqs (VIP, K3S_TOKEN, /etc/hosts), (3) minimaler Ubuntu-Prep (Update, Swap off, ufw raus, hostnames, ip_forward), (4) kube-vip statisches Manifest in /var/lib/rancher/k3s/server/manifests/ mit ARP-Mode und Leader-Election, (5) k3s Server-Install auf node-1 mit cluster-init: true, tls-san, disable: traefik, (6) node-2/-3 via server: https://VIP:6443 (k3s nutzt 6443 für API+Supervisor, anders als RKE2 mit 9345), (7) Cluster-Verifikation inkl. VIP-Failover-Test, (8) StorageClass-Check — local-path ist bei k3s Default (out-of-the-box im Gegensatz zu RKE2), (9) Helm + cert-manager, (10) komplette TLS-PKI via cert-manager (selfSigned-Bootstrap → CA → CA-Issuer → Server-Cert mit allen SANs), (11) OpenBao Helm-Values mit Raft, drei retry_join mit leader_tls_servername, service_registration "kubernetes" {}, Pod-Anti-Affinity, storageClass: local-path, (12) helm install, (13) Init + Pod-für-Pod-Unseal, (14) Verifikation per raft list-peers, Service-Registration-Labels, externem bao status + Failover-Test, (15) Production-Hardening (Auto-Unseal, Audit, Snapshots, Cilium statt Flannel für NetworkPolicies, etcd-Backup nach extern, Longhorn als Upgrade-Pfad, kube-vip BGP), (16) Stolperfallen (cluster-init mehrfach gesetzt, falscher Token, kube-vip Interface, local-path-Volume-Affinity-Conflict, x509-CN-Mismatch, k3s-Upgrade nicht via apt, Traefik kommt automatisch zurück). Verlinkt aus index.md und mit Cross-Refs aus k8s-ha-from-scratch.md und rke2-ha-setup.md. Sources: raw/docs/platform/k8s/helm/examples/ha-with-raft.md, raw/docs/platform/k8s/helm/examples/ha-tls.md, raw/docs/platform/k8s/helm/examples/standalone-tls.md, raw/docs/platform/k8s/helm/configuration.md, raw/docs/platform/k8s/helm/run.md, raw/docs/configuration/storage/raft.md, raw/docs/configuration/service-registration/kubernetes.md. k3s/kube-vip-Schritte folgen den jeweiligen Upstream-Docs.

2026-05-20 — Added rke2-ha-setup

Neue Seite wiki/rke2-ha-setup.md — End-to-End-Runbook für OpenBao HA auf RKE2 mit dedizierter 3+3-Topologie (3 Server/etcd, 3 Worker). Unterschied zu k8s-ha-from-scratch: andere K8s-Distribution (RKE2 statt kubeadm), andere Topologie (dedicated Master/Worker statt stacked), echte API-VIP via kube-vip statt single-endpoint, Longhorn als Distributed Storage statt local-path, Worker-Pinning für OpenBao-Pods via nodeSelector und bewusst fehlende Toleration für den CriticalAddonsOnly=NoExecute-Taint der Server-Nodes. Aufbau: (0) Architektur-Diagramm 3+3 mit VIP-Layer, Quorum-Begründung, Hardware-Tabelle, (1) Pre-Reqs inkl. VIP-IP-Reservierung und gemeinsamem RKE2-Token, (2) Ubuntu-Prep (swap, ufw raus, NetworkManager-Exception, hostnames), (3) kube-vip als statisches Pod-Manifest in /var/lib/rancher/rke2/server/manifests/ mit RBAC + ARP-Mode + Leader-Election, (4) RKE2 Server auf server-1 mit cluster-init: true, tls-san, cni: cilium, Worker-protection-Taint und disable: rke2-ingress-nginx, (5) server-2/-3 joinen via server: https://VIP:9345 (Port 9345 erklärt), (6) Agent-Install auf den drei Workern mit INSTALL_RKE2_TYPE=agent und node-label: node-role.kubernetes.io/worker=true, (7) Cluster-Verifikation inkl. VIP-Failover-Test, (8) Longhorn via Helm mit open-iscsi-Voraussetzung und defaultReplicaCount=3, (9) cert-manager, (10) komplette TLS-PKI (selfSigned-Bootstrap → CA-Cert → CA-Issuer → Server-Cert mit allen SANs), (11) OpenBao Helm-Values mit Worker-Pinning via nodeSelector + Pod-Anti-Affinity + drei retry_join-Blöcken + service_registration "kubernetes" {} + storageClass: longhorn, (12) helm install + Pod-Verteilungs-Check (1 Pod pro Worker), (13) Init + Pod-für-Pod-Unseal, (14) Verifikation per raft list-peers, Service-Registration-Labels, externem bao status + Failover-Test, (15) Production-Hardening-Pointer (Auto-Unseal, Audit, Snapshots, Cilium-NetPol, etcd-Backups, kube-vip BGP-Mode), (16) Stolperfallen (kube-vip-Interface, etcd-Quorum-Race beim Bootstrap, Pending-Pods durch fehlendes Worker-Label, x509-CN-Mismatch, Longhorn-Degraded, iSCSI fehlt, VIP-Failover-Tuning, RKE2 nicht via Apt upgraden). Verlinkt aus index.md und mit Cross-Ref aus k8s-ha-from-scratch.md. Sources: raw/docs/platform/k8s/helm/examples/ha-with-raft.md, raw/docs/platform/k8s/helm/examples/ha-tls.md, raw/docs/platform/k8s/helm/examples/standalone-tls.md, raw/docs/platform/k8s/helm/configuration.md, raw/docs/platform/k8s/helm/run.md, raw/docs/configuration/storage/raft.md, raw/docs/configuration/service-registration/kubernetes.md. RKE2/kube-vip/Longhorn-Schritte folgen den jeweiligen Upstream-Docs.

2026-05-20 — Added k8s-ha-from-scratch

Neue Seite wiki/k8s-ha-from-scratch.md — Ende-zu-Ende-Runbook von drei nackten Ubuntu-24.04-Servern bis zum funktionsfähigen 3-Node-OpenBao-HA-Cluster. Lücke gegenüber bestehender k8s-ha-setup-Seite: die kompakte Variante setzt einen funktionierenden K8s-Cluster + Helm + StorageClass voraus, die neue Seite baut das alles. Aufbau: (0) Architektur-Diagramm + Quorum-Begründung, (1) Pre-Reqs (Hardware, IPs, Hostnames), (2) Ubuntu-Prep (swap, br_netfilter/overlay, sysctl, /etc/hosts), (3) containerd inkl. SystemdCgroup-Driver, (4) kubeadm/kubelet/kubectl via pkgs.k8s.io mit apt-mark hold, (5) kubeadm init auf node-1 mit Begründung von --control-plane-endpoint und --upload-certs, (6) node-2/-3 als Control-Plane joinen + Taint-Removal, (7) Cilium mit kubeProxyReplacement via Helm, (8) local-path-provisioner als StorageClass-Default, (9) cert-manager via Helm, (10) komplette TLS-PKI mit cert-manager: selfSigned Bootstrap → CA-Certificate → CA-Issuer → Server-Certificate mit allen Service-/Pod-DNS-SANs, (11) OpenBao Helm-Repo + komplette values-ha.yaml mit HA-Raft, TLS-Volumes, drei retry_join mit leader_tls_servername, Pod-Anti-Affinity, service_registration “kubernetes” {}, (12) helm install, (13) bao operator init + Pod-für-Pod-Unseal mit Erklärung warum Unseal nicht repliziert wird, (14) Verifikation per raft list-peers, Service-Registration-Labels, Active-Service-Endpoint und externem bao status mit CA-Cert, (15) Production-Hardening-Pointer, (16) typische Stolperfallen (cgroup-Mismatch, x509-CN-Mismatch, Anti-Affinity vs. zu wenige Nodes, CA-Ablauf). Verlinkt aus index.md und aus k8s-ha-setup.md (Cross-Reference im Prerequisites-Abschnitt). Sources: raw/docs/platform/k8s/helm/examples/ha-with-raft.md, raw/docs/platform/k8s/helm/examples/ha-tls.md, raw/docs/platform/k8s/helm/examples/standalone-tls.md, raw/docs/platform/k8s/helm/configuration.md, raw/docs/platform/k8s/helm/run.md, raw/docs/configuration/storage/raft.md, raw/docs/configuration/service-registration/kubernetes.md. Ubuntu/K8s/Cilium/cert-manager-Steps folgen jeweiligen Upstream-Docs (außerhalb raw/).

2026-05-20 — Added service-registration-reactivation

Neue Seite wiki/service-registration-reactivation.md — Operations-Runbook für den Fall, dass service_registration "kubernetes" {} im Chart als Workaround gegen einen TLS-Handshake-Hang auskommentiert wurde und jetzt sauber reaktiviert werden soll. Aufbau strikt prozedural in der einzigen Reihenfolge, die nicht den ursprünglichen Hang reproduziert: (0) Ausgangslage und Konsequenzen heute, (1) Begründung der Reihenfolge, (2) NetworkPolicy-Egress zur K8s-API verifizieren und ggf. öffnen — Cilium kube-apiserver-Entity vs. vanilla NetworkPolicy mit ipBlock, (3) RBAC per kubectl auth can-i prüfen, (4) Downward API verifizieren, (5) Stanza in Helm-Values setzen + Render-Check der ConfigMap, (6) gestaffeltes OnDelete-Rollout (Standbys zuerst, Leader zuletzt) inkl. Failover-Test, (7) Active-/Standby-Service-Endpoints prüfen, (8) Rollback-Plan, (9) bewusste Nicht-Änderungen (retry_join bleibt explizit — anderes Subsystem), (10) Antipatterns. Verlinkt aus index.md und kubernetes-service-registration.md. Sources: raw/docs/configuration/service-registration/kubernetes.md, raw/docs/configuration/service-registration/index.md, raw/docs/platform/k8s/helm/terraform.md, raw/docs/platform/k8s/helm/run.md, raw/docs/concepts/ha.md.

2026-05-20 — Added kubernetes-service-registration

Neue Seite wiki/kubernetes-service-registration.md — didaktisch von “warum überhaupt” bis Antipatterns. Vorher war das Thema in kubernetes-platform auf einen Satz reduziert (“service_registration setzt Pod-Labels”) — der Mechanismus, die RBAC-Voraussetzung, das genaue Label-Set und die beiden Hauptanwendungsmuster (Active-Service per Selector, kontrollierte Upgrades) fehlten. Aufbau: (1) das Problem (Leader-Findung in HA), (2) Grundidee mit drei Bausteinen, (3) minimale Stanza + Downward API, (4) Abgrenzung zum Storage-Backend, (5) RBAC-Role mit get/update/patch auf pods, (6) Tabelle aller fünf Labels mit Bedeutung, (7) Beispiel-Service mit openbao-active=true-Selector, (8) chirurgische Upgrade-Sequenz, (9) Helm-Chart-Integration, (10) Antipatterns inkl. fehlende RBAC, manuelles Label-Overwrite, fehlendes Auto-Unseal. Verlinkt aus index.md und kubernetes-platform.md. Sources: raw/docs/configuration/service-registration/index.md, raw/docs/configuration/service-registration/kubernetes.md, raw/docs/platform/k8s/helm/terraform.md, raw/docs/platform/k8s/helm/run.md.