Secrets and keys in Switzerland, for apps, CI and Kubernetes.

The principle fits in one sentence: the secret is never in your repository, it is requested at runtime by an identity entitled to read it. That displacement is what earns the audit, more than the vault itself.

• You store the secret once: database credentials, a registry token, a partner API key
• You decide who may read it, an application, a pipeline, a Kubernetes namespace, and that decision is the policy, not a shared password
• The application fetches it at startup: nothing in the Git repository, nothing in a US CI SaaS variable
• Rotation becomes an operation rather than a project, because there is only one place to change
• The classic hole remains: a token left in a pipeline hosted elsewhere cancels the benefit, whatever the vault holds

Vault as a Service covers the secrets of the workloads you place on Hikube, in the same Swiss tenant as compute and storage. It does not cover what lives elsewhere: a secret left in a US group’s KMS stays under that jurisdiction, and the vault changes nothing there. One point deserves saying plainly, because the name invites the assumption: this page claims no API compatibility with HashiCorp Vault. If your tooling depends on a specific API, a Terraform provider, an injection agent, a client library, have the interface confirmed before building on it. Nor is it an HSM you operate in a room, or a substitute for your access management policy. The available authentication methods and the service limits are not published here: ask for them before designing a chain that depends on either. Other building blocks: managed Kubernetes and the image registry.

Because data “at rest” includes the keys that open it. A Swiss cluster with a US KMS is a weak argument. Vault as a Service aligns the vault with the same jurisdiction as compute.