Aller au contenu principal

Injecter un secret dans une App

Disponible

Fonctionnalité déployée et prise en charge. Les champs et commandes décrits ici sont stables au sein de la version v1alpha1.

Vos services lisent les secrets comme des variables d'environnement, sans appel réseau ni bibliothèque : vous nommez le secret et la clé dans le manifeste App, StackNGO fait le reste. Ce guide montre les deux formes, env pour une variable à la fois et envFrom pour toutes les clés d'un coup.

Prérequis​

1. Une variable, une clé : env​

shop.yml
apiVersion: deploy.stackngo.io/v1alpha1
kind: App
metadata:
  name: shop
spec:
  services:
    api:
      image: registry.gitlab.com/acme/shop-api:1.4.2
      ports: ["8080"]
      env:
        LOG_LEVEL: info
        DB_PASSWORD: { secret: db-password, key: value }
sng apply shop.yml

secret est le nom du secret, key la clé à l'intérieur. Les deux sont obligatoires. Un secret posé sans --data a une seule clé, nommée value.

Avec un secret multi-clés :

sng secret set shop-db --data host=db --data user=shop --data password=S3cr3t
      env:
        DB_HOST: { secret: shop-db, key: host }
        DB_USER: { secret: shop-db, key: user }
        DB_PASSWORD: { secret: shop-db, key: password }

2. Toutes les clés d'un coup : envFrom​

Quand le secret est conçu pour cela, nommez ses clés comme les variables attendues par votre application et injectez-le en bloc :

sng secret set shop-api \
  --data DATABASE_URL=postgres://shop:S3cr3t@db:5432/shop \
  --data SMTP_HOST=smtp.example.net \
  --data SMTP_PASSWORD=xyz
    api:
      image: registry.gitlab.com/acme/shop-api:1.4.2
      envFrom: [shop-api]
      env:
        LOG_LEVEL: info

Chaque clé du secret devient une variable d'environnement du même nom. envFrom accepte jusqu'à 10 secrets. Une variable définie dans env l'emporte sur la même clé venue d'envFrom.

3. Vérifier​

sng app describe shop

Tant qu'un secret référencé n'existe pas ou n'a pas de valeur, le service correspondant ne démarre pas et l'état de l'App l'indique :

reason:  SecretNotFound
message: Secrets absents (…) : shop-api

sng app describe est activée progressivement sur les tenants ; en son absence, sng secret describe shop-api vous dit si le secret a une valeur (version_id différent de "0").

Posez la valeur (sng secret set shop-api …) : le service démarre dans les minutes qui suivent, sans réappliquer l'App.

Ce que vous pouvez en attendre​

  • Vos conteneurs reçoivent la version courante du secret au démarrage. Les clés du secret sont celles que vous pouvez citer dans key et que envFrom transforme en variables.
  • Un secret référencé qui n'existe pas encore est créé pour vous, en attente, sans valeur. Il apparaît dans sng secret list ; sng secret describe le montre en version_id: "0". C'est un inventaire gratuit : déployez d'abord, posez les valeurs ensuite.
  • Quand la valeur change (nouveau set, rotation), les services deployment qui l'utilisent sont redémarrés en douceur dans les 5 minutes, avec la nouvelle valeur. Voir Rotation — comment une App voit la nouvelle valeur.
  • Quand le secret est supprimé, les conteneurs en cours gardent leur valeur en mémoire, mais un conteneur qui redémarre ne démarre plus tant que le secret n'est pas recréé.

Si ça ne marche pas​

SymptômeCauseCorrection
L'App passe en Invalid : « secret et key sont requis »{ secret: db-password } sans key, ou l'inverseDonnez les deux : { secret: db-password, key: value }
L'App passe en Invalid : « objet attendu de la forme {secret, key} »Une autre clé dans l'objet (name, from…)Seules secret et key sont acceptées. sng apply accepte le manifeste, l'erreur apparaît dans l'état de l'App
Le service reste en attente avec SecretNotFoundLe secret n'a pas de valeur (déclaré vide ou créé automatiquement)sng secret set NAME …
Le service démarre mais la variable est vide ou le conteneur échoue sur key not foundLa clé n'existe pas dans le secret (value attendu, password donné, ou l'inverse)sng secret describe NAME liste les clés exactes
Avec envFrom, les variables ont des noms inattendusLes clés du secret ne sont pas des noms de variables (password et non DB_PASSWORD)Reposez le secret avec --data DB_PASSWORD=…, ou utilisez env clé par clé
Une variable env n'a pas la valeur du secret envFromenv l'emporte sur envFrom pour la même cléRetirez la définition dans env

Pour aller plus loin​

  • Un secret, plusieurs services : rien n'empêche deux services (ou deux Apps) de référencer le même secret. Une rotation redémarre tous ceux qui l'utilisent.
  • Images privées : imagePullSecrets ne lit pas les secrets créés avec sng secret (seuls env et envFrom le font) ; les identifiants de registre viennent du Registre OCI.
  • Jobs et cronjobs : ils lisent le secret au lancement de chaque exécution et ne sont pas redémarrés par une rotation.
  • Pas de montage fichier : dans cette version, les secrets sont exposés comme variables d'environnement uniquement ; il n'y a pas d'option pour les monter en fichier dans un service d'App.
  • Pourquoi le secret est créé en attente plutôt qu'ignoré : le service ne peut pas démarrer sans lui, et l'attente est visible (SecretNotFound) ; un secret ignoré silencieusement donnerait un service qui démarre avec une variable vide.

Voir aussi​