Kubernetes ohne Cloud-Anbieter: Go-Operators für Automatisierung und Self-Service

In der zweiten Folge unserer Kubernetes-Reihe zeigen wir, wie Entwicklerteams die Komplexität von manuellen YAML-Konfigurationen umgehen können – besonders, wenn Cloud-Anbieter-Abfraktionen fehlen. Die Lösung liegt in der Erstellung von Custom Operators in Go, die als Self-Service-Tools für Plattformteams fungieren.

Mit den beiden Open-Source-Operators vaultreaver und platform-operator demonstrieren wir, wie sich Sicherheitsrichtlinien, TLS-Zertifikate und geheime Datenflüsse in Kubernetes vollständig automatisieren lassen. Beide Projekte integrieren sich nahtlos mit HashiCorp Vault, Cert-Manager und dem ExternalSecrets Operator.

Warum Kubernetes-Operators die manuelle Arbeit reduzieren

Die manuelle Konfiguration von Kubernetes-Komponenten wie Custom Resource Definitions (CRDs), Rollen und Ingress-Regeln führt oft zu einem unübersichtlichen Wust an YAML-Manifesten. Besonders problematisch wird es, wenn zusätzliche Sicherheitsebenen wie Vault-Integration oder TLS-Zertifikatsverwaltung hinzukommen.

Die beiden Hauptprobleme, die wir in unserer Arbeit identifiziert haben:

• Sicherheitskomplexität: Jede Anwendung benötigt eine eigene ServiceAccount, Vault-Rolle und Zugriffsrichtlinie – eine repetitive und fehleranfällige Aufgabe.
• Lernkurve: Entwickler müssen sich nicht nur mit Kubernetes, sondern auch mit Vault, RBAC und Cert-Manager vertraut machen.

Unsere Lösung: Zwei Go-Operators, die diese Prozesse automatisieren und Entwicklern eine einfache Declarative API bieten.

vaultreaver: Automatisierte Vault-Integration für Kubernetes

Der vaultreaver-Operator übernimmt die Brücke zwischen Kubernetes und Vault. Er verwaltet zwei zentrale Custom Resources:

• `VaultPolicy`: Definiert, welche Vault-Pfade eine Anwendung lesen oder schreiben darf.
• `VaultKubernetesRoleBinding`: Verknüpft die Vault-Richtlinie mit einer Kubernetes-ServiceAccount.

Ein praktisches Beispiel zeigt, wie eine Anwendung im Namespace nginx-apps Lesezugriff auf einen geheimen Pfad in Vault erhält:

apiVersion: security.platform.io/v1alpha1
kind: VaultPolicy
metadata:
  name: nginx-deployment-external-secret
  namespace: nginx-apps
spec:
  vaultPolicyName: nginx-deployment-external-secret-policy
  policy: |
    path "kv/data/app-teste/secret-secreto" {
      capabilities = ["read"]
    }
---
apiVersion: security.platform.io/v1alpha1
kind: VaultKubernetesRoleBinding
metadata:
  name: nginx-deployment-external-secret
  namespace: nginx-apps
spec:
  authMount: kubernetes
  boundNamespaces:
    - nginx-apps
  boundServiceAccounts:
    - nginx-deployment-external-secret
  tokenPolicies:
    - nginx-deployment-external-secret-policy
  tokenTTL: 1h
  audience: vault

Sobald diese Ressourcen erstellt sind, generiert der Operator automatisch einen Vault-Token für die ServiceAccount – ohne manuelle Eingriffe.

platform-operator: Self-Service für TLS und geheime Daten

Während vaultreaver die externe Vault-Anbindung regelt, fungiert der platform-operator als zentraler Automatisierungs-Hub innerhalb des Clusters. Seine API ist darauf ausgelegt, Entwicklern eine einfache Self-Service-Oberfläche zu bieten.

Ein typischer Anwendungsfall ist die Bereitstellung von TLS-Zertifikaten über Cert-Manager mit Vault als PKI-Backend. Statt komplexer YAML-Manifeste für ClusterIssuer, Issuer und Certificate muss der Entwickler nur einen einzigen CR erstellen:

apiVersion: security.platform.io/v1alpha1
kind: VaultCertificate
metadata:
  name: nginx-deployment-tls
  namespace: nginx-apps
spec:
  vaultUrl: 
  authPath: /v1/auth/kubernetes
  vaultRole: nginx-deployment-tls-role
  pkiPath: pki/sign/internal-dot-infra
  commonName: my-app.internal.infra
  dnsNames:
    - my-app.internal.infra
    - my-app-teste.internal.infra
  SecretName: nginx-deployment-tls
  certManagerServiceAccount: cert-manager
  certManagerNamespace: cert-manager

Der Operator erstellt daraufhin automatisch:

• Eine ServiceAccount mit den notwendigen RBAC-Rechten.
• Einen ClusterIssuer oder Issuer, der auf Vault verweist.
• Das Certificate-Ressource, das die Zertifikatsausstellung auslöst.

Ein weiterer Controller innerhalb des platform-operator vereinfacht die Arbeit mit ExternalSecrets. Statt manuell SecretStore und ExternalSecret zu konfigurieren, reicht eine einfache Ressource:

apiVersion: security.platform.io/v1alpha1
kind: ExternalSecret
metadata:
  name: app-secrets
  namespace: nginx-apps
spec:
  refreshInterval: 1h
  secretStoreRef:
    name: vault-backend
    kind: ClusterSecretStore
  target:
    name: app-secrets
  data:
    - secretKey: db-password
      remoteRef:
        key: kv/data/app-teste/secret-secreto

Validierung im Labor: TLS und geheime Daten im Praxistest

Um die Funktionalität unserer Operatoren zu überprüfen, haben wir ein vollständiges Laborumfeld aufgebaut. Dieses ist im Repository homelab-app-demo dokumentiert und umfasst:

• Ein Nginx-Deployment mit TLS-Integration.
• Automatisierte Geheimnis-Injektion über ExternalSecrets.
• End-to-End-Tests für Zertifikatsausstellung und Geheimnisabruf.

Die Tests bestätigten:

• Idempotenz: Mehrfache Anwendungen derselben CRs führen zu identischen Ergebnissen.
• Sicherheit: Vault-Tokens werden korrekt generiert und haben begrenzte Laufzeiten.
• Zuverlässigkeit: TLS-Zertifikate werden ohne manuelle Schritte provisioniert.

Ausblick: Kubernetes-Operators als Standard für Plattformteams

Die manuelle Verwaltung von Kubernetes-Ressourcen ist fehleranfällig und skaliert schlecht. Mit Go-basierten Operators lassen sich wiederkehrende Aufgaben automatisieren – besonders in Umgebungen ohne Cloud-Anbieter-Abfraktionen.

Unsere Projekte vaultreaver und platform-operator zeigen, wie Entwicklerteams durch Self-Service-APIs entlastet werden können. Die nächste Evolutionsstufe könnte die Integration weiterer Tools wie ArgoCD oder Prometheus-Operator umfassen, um die Automatisierung weiter zu zentralisieren.

Für Teams, die ähnliche Herausforderungen bewältigen müssen, bieten diese Operatoren ein solides Fundament – und eine Blaupause für die eigene Plattformautomatisierung.