Apporter ou conserver sa clé

La garde client couvre les secrets stockés d'organisation et d'espace de travail ainsi que les jetons d'extension de l'organisation. Les sessions, comptes de connexion, paramètres SSO, données d'audit et identifiants des connexions conservent leur protection de déploiement. Une valeur autorisée existe en mémoire pendant son utilisation ; la garde client ne chiffre pas toute la base de données.

Prérequis opérateur

Deux limites relèvent de l'opérateur du déploiement Scrydon, pas d'un administrateur d'organisation. Elles se règlent dans les valeurs Helm, sous auth.secretsCustody :

• platformIdentityBindings — l'authentification Kubernetes et l'identité de charge de travail Azure font s'authentifier Scrydon avec sa propre identité. Elle est commune à toutes les organisations du déploiement : sans liaison explicite, un coffre qui lui fait confiance répondrait à n'importe quelle organisation qui le désigne. Une connexion utilisant l'une de ces méthodes est refusée tant que l'opérateur n'a pas lié cette organisation à ce coffre :

  auth:
    secretsCustody:
      platformIdentityBindings:
        - organizationId: "<identifiant de votre organisation>"
          vaultUrl: "https://customer-vault.vault.azure.net"

  Un jeton Vault ou AppRole ne nécessite aucune liaison : présenter un identifiant que vous avez émis prouve quel client s'adresse au coffre. Sur un déploiement partagé, privilégiez ces méthodes.

• allowPrivateNetworks — l'URL du coffre est appelée depuis Scrydon ; par défaut elle doit donc désigner un hôte HTTPS public. Ne passez cette valeur à true que si toutes les organisations du déploiement vous appartiennent et que le coffre se trouve sur votre réseau privé. Le http:// n'est accepté que dans ce mode, car Transit renvoie les clés de données dans sa réponse.

Déployer OpenBao sous contrôle client

Exploitez OpenBao séparément de la release Helm Scrydon, avec trois réplicas Raft, des volumes persistants, TLS et une procédure de restauration vérifiée. Le mode développement est réservé aux tests jetables. Ajoutez le dépôt Helm officiel et choisissez une version approuvée :

helm repo add openbao https://openbao.github.io/openbao-helm
helm repo update
helm search repo openbao/openbao --versions
helm template customer-bao openbao/openbao --version "$BAO_CHART_VERSION" \
  --namespace customer-bao --values customer-bao-values.yaml

Vérifiez les manifests avant l'installation. Configurez server.ha.enabled: true, server.ha.replicas: 3 et server.ha.raft.enabled: true, désactivez le mode standalone et configurez découverte Raft, TLS, stockage et permissions selon la référence du chart.

Pour le déverrouillage automatique statique, injectez dans chaque pod une clé de 32 octets provenant d'une source de confiance du client. Séparez-la du volume Raft et de ses sauvegardes :

seal "static" {
  current_key_id = "customer-seal-1"
  current_key = "file:///openbao/secrets/customer-seal-1.key"
}

Le client contrôle ce fichier et sa copie de récupération. Ce modèle repose sur la source qui injecte la clé ; il ne constitue pas une preuve HSM. Consultez les conditions du sceau statique, initialisez le cluster, joignez les pairs, activez l'audit et testez la restauration indépendamment de Scrydon.

Clé Transit et identité restreinte

En tant qu'opérateur OpenBao autorisé, créez une clé dédiée. N'utilisez pas le jeton root dans Scrydon :

bao secrets enable transit
bao write transit/keys/scrydon type=aes256-gcm96
bao secrets enable -path=secret kv-v2
bao kv put secret/scrydon/probe value=connection-check
bao policy write scrydon - <<'POLICY'
path "transit/keys/scrydon" { capabilities = ["read"] }
path "transit/datakey/plaintext/scrydon" { capabilities = ["update"] }
path "transit/decrypt/scrydon" { capabilities = ["update"] }
path "secret/data/scrydon/*" { capabilities = ["read"] }
POLICY

Omettez KV et sa règle si seules les valeurs stockées sont nécessaires. Ne réactivez pas un montage existant.

Pour l'authentification Kubernetes, configurez TokenReview sur le cluster Scrydon. Dans le même cluster, le compte de service OpenBao peut utiliser son jeton et son CA locaux avec la permission system:auth-delegator :

bao auth enable kubernetes
bao write auth/kubernetes/config kubernetes_host="$KUBERNETES_API_URL"
bao write auth/kubernetes/role/scrydon \
  bound_service_account_names="$SCRYDON_SERVICE_ACCOUNT" \
  bound_service_account_namespaces="$SCRYDON_NAMESPACE" \
  policies=scrydon ttl=15m

L'authentification Kubernetes présente l'identité de charge de travail de Scrydon et nécessite donc une liaison opérateur (voir Prérequis opérateur). Utilisez le véritable compte des processus qui résolvent les secrets. Entre clusters, configurez le CA distant et une identité TokenReview adaptée. Scrydon lit le JWT projeté à l'emplacement standard du compte de service ; une connexion ne peut pas désigner un fichier local arbitraire.

Ouvrez Paramètres → Plateforme → Secrets → Connexions et sélectionnez Ajouter une connexion. Choisissez OpenBao / Vault Transit, indiquez l'origine HTTPS et la clé scrydon, puis la méthode de connexion : Jeton, AppRole ou Kubernetes (rôle scrydon). Les champs de chaque méthode apparaissent juste en dessous. Pour résoudre des secrets référencés depuis ce coffre, activez Secrets référencés : le montage KV v2 vaut secret par défaut, et un chemin de test facultatif comme scrydon/probe#value est alors lu lors du test. Le montage Transit (transit par défaut), l'espace de noms et un CA privé ou un certificat client se trouvent sous Options avancées.

Tester la connexion vérifie la connexion avant l'enregistrement, sans rien stocker. Enregistrer effectue le même contrôle et refuse une connexion que le coffre n'accepte pas, en affichant la raison : identifiants rejetés, clé absente, adresse injoignable ou chemin de test illisible.

Les identifiants ne sont plus jamais affichés après l'enregistrement. Lors d'une modification, laissez un identifiant vide pour conserver celui enregistré, ou saisissez une valeur pour le remplacer. Changer de méthode d'authentification exige ses identifiants. Le montage KV d'une connexion qui sert encore des secrets référencés ne peut être ni modifié ni retiré : déplacez ou supprimez d'abord ces références.

HashiCorp Vault utilise le même type de connexion Transit/KV v2. Renseignez son namespace si nécessaire et suivez les procédures de déploiement et d’authentification Vault approuvées par le client.

Azure Key Vault

Une connexion Azure s'authentifie toujours avec l'identité de charge de travail de Scrydon : chacune nécessite une liaison opérateur (voir Prérequis opérateur). Utilisez une origine du cloud public comme https://customer-vault.vault.azure.net, une clé RSA compatible RSA-OAEP-256 et une identité fédérée autorisée à lire, envelopper et désenvelopper cette clé. Ajoutez secret get uniquement pour les références. Configurez la fédération Entra avec l'émetteur, le sujet et l'audience d'échange du jeton de charge de travail. Montez l'assertion projetée et renseignez AZURE_FEDERATED_TOKEN_FILE dans le déploiement.

La connexion reçoit l'URL, les identifiants de tenant et de client et le nom de clé. Une version facultative fixe les nouveaux enveloppements ; chaque enveloppe conserve sa version précise. Conservez les anciennes versions nécessaires aux sauvegardes. Cette connexion ne propose ni secret client ni endpoint de cloud souverain.

Le client utilise le flux client-credentials fédéré et l'API REST Key Vault 7.4. Les tests locaux de protocole ne prouvent pas l'accès à votre tenant : exécutez le test de connexion et l'exercice de révocation avec l'identité déployée.

Migration et récupération

Dans l'onglet Connexions, la section Clé de chiffrement choisit qui détient la clé. Sélectionnez la connexion sous Clé détenue par (seules les connexions dont le dernier test a réussi sont proposées), le mode sous Accès à la clé, puis Appliquer. Le test précède la sélection ; le rechiffrement se fait par lots reprenables. La couverture compte les secrets stockés et les champs de jetons d'extension non vides, y compris les anciennes valeurs en clair. Elle exclut les références et les champs d'identité internes.

Gardez les anciennes et nouvelles clés accessibles jusqu'à la couverture complète. Après une interruption, restaurez l'accès puis utilisez Reprendre. Une valeur illisible avec sa clé actuelle (corrompue, ou enveloppée par une clé disparue) est ignorée et comptée au lieu de bloquer le reste ; la page indique combien ont été ignorées, et elles conservent leur protection précédente jusqu'à leur résolution. Conservez aussi les anciennes connexions et clés pendant la rétention des sauvegardes qui en dépendent.

Exercice de révocation

Utilisez une organisation, une clé et une identité jetables. Enregistrez version applicative, version OpenBao, mode, couverture et horodatages, sans valeurs secrètes.

1. Créez un secret stocké, sélectionnez la garde client et attendez la couverture complète. Lisez le secret puis effectuez une écriture pour initialiser les caches. Ajoutez une référence si nécessaire.
2. Révoquez les permissions effectives de l'identité dédiée. Modifier un rôle Kubernetes seul peut laisser des jetons déjà émis valides : révoquez ces jetons ou leur ACL effective. Horodatez le premier refus du coffre.
3. Vérifier la révocation doit constater le refus sans cache. Un coffre inaccessible est un résultat distinct.
4. En mode Strict, la prochaine lecture et écriture doivent échouer. En mode Performance, les opérations en cache peuvent réussir pendant 300 secondes après leur dernière vérification ; elles doivent ensuite échouer. Une référence doit échouer immédiatement dans les deux modes.
5. Restaurez les permissions, testez la connexion et vérifiez lecture, écriture et référence. Après un échec d'authentification AppRole/Kubernetes, le délai entre tentatives peut atteindre une minute.
6. Revenez à la garde plateforme pendant que la clé client reste accessible. Attendez la couverture complète, supprimez les références de test puis la connexion jetable. Préservez les clés nécessaires aux sauvegardes.

Une panne du coffre suit le même comportement fermé. Sélectionner la plateforme ne récupère pas une donnée dont l'unique clé d'enveloppement a été détruite : il faut restaurer cette clé, sa version utilisable ou une sauvegarde avec ses clés correspondantes.