Secrets und Schlüssel in der Schweiz, für Apps, CI und Kubernetes.

Das Prinzip passt in einen Satz: das Secret liegt nie in Ihrem Repository, es wird zur Laufzeit von einer berechtigten Identität angefragt. Diese Verlagerung bringt den Auditwert, mehr als der Tresor selbst.

• Sie legen das Secret einmal ab: Datenbank-Zugangsdaten, ein Registry-Token, einen Partner-API-Key
• Sie entscheiden, wer es lesen darf, eine Anwendung, eine Pipeline, ein Kubernetes-Namespace, und diese Entscheidung ist die Policy, kein geteiltes Passwort
• Die Anwendung holt es beim Start: nichts im Git-Repository, nichts in einer Variablen eines US-CI-SaaS
• Die Rotation wird zur Operation statt zum Projekt, weil es nur eine Stelle zu ändern gibt
• Das klassische Loch bleibt: ein in einer anderswo gehosteten Pipeline vergessenes Token hebt den Nutzen auf, was auch immer im Tresor liegt

Vault as a Service deckt die Secrets der Lasten ab, die Sie auf Hikube betreiben, im selben Schweizer Tenant wie Compute und Storage. Es deckt nicht ab, was anderswo liegt: ein in einem US-Konzern-KMS verbliebenes Secret bleibt unter jener Jurisdiktion, und der Tresor ändert daran nichts. Ein Punkt gehört klar gesagt, weil der Name die Annahme nahelegt: diese Seite beansprucht keine API-Kompatibilität mit HashiCorp Vault. Hängt Ihr Werkzeug an einer bestimmten API, ein Terraform-Provider, ein Injection-Agent, eine Client-Bibliothek, lassen Sie die Schnittstelle bestätigen, bevor Sie darauf bauen. Es ist auch kein HSM, das Sie im Raum betreiben, und kein Ersatz für Ihre Zugriffsrichtlinie. Die verfügbaren Authentifizierungsmethoden und die Grenzen des Service stehen hier nicht: fragen Sie sie ab, bevor Sie eine Kette darauf bauen. Weitere Bausteine: das Managed Kubernetes und die Image-Registry.

Weil Daten «at rest» die Schlüssel einschliessen. Ein Schweizer Cluster mit US-KMS ist ein schwaches Argument. Vault as a Service legt den Tresor in dieselbe Jurisdiktion wie Compute.