Secrets et clés en Suisse, pour apps, CI et Kubernetes.

Le principe tient en une phrase : le secret n’est jamais dans votre dépôt, il est demandé à l’exécution par une identité qui a le droit de le lire. C’est ce déplacement qui vaut l’audit, plus que le coffre lui-même.

• Vous rangez le secret une fois : identifiants de base, jeton de registry, clé d’API partenaire
• Vous décidez qui peut le lire, une application, un pipeline, un namespace Kubernetes, et cette décision est la politique, pas un partage de mot de passe
• L’application le récupère au démarrage : rien dans le dépôt Git, rien dans une variable d’un SaaS CI américain
• La rotation devient une opération et non un chantier, parce qu’il n’y a qu’un endroit à changer
• Le trou classique reste possible : un jeton oublié dans un pipeline hébergé ailleurs annule le bénéfice, quoi que contienne le coffre

Vault as a Service couvre les secrets des charges que vous posez sur Hikube, dans le même tenant suisse que le compute et le stockage. Il ne couvre pas ce qui vit ailleurs : un secret resté dans un KMS de groupe américain reste sous cette juridiction, et le coffre n’y change rien. Un point mérite d’être dit franchement, parce que le nom l’invite : cette page ne revendique aucune compatibilité d’API avec HashiCorp Vault. Si votre outillage dépend d’une API précise, un provider Terraform, un agent d’injection, une bibliothèque cliente, faites confirmer l’interface avant de construire dessus. Ce n’est pas non plus un HSM que vous exploitez en salle, ni un substitut à votre politique de gestion des accès. Les méthodes d’authentification disponibles et les limites du service ne sont pas publiées ici : demandez-les avant de concevoir une chaîne qui en dépend. Détail des autres briques : le Kubernetes managé et le registry d’images.

Parce que la donnée « au repos » inclut les clés qui l’ouvrent. Un cluster suisse avec un KMS américain est un argument faible. Vault as a Service aligne le coffre sur la même juridiction que le compute.