Aller au contenu principal

Créer et lire un secret

Disponible

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

Un secret est une valeur chiffrée, rangée dans votre tenant sous un nom, que vos applications consomment comme variable d'environnement. Ce guide montre comment en créer un avec sng secret set, le relire avec sng secret get, et inspecter l'inventaire avec list et describe.

Prérequis​

  • La CLI sng installée et authentifiée : sng sso login.
  • Une session sur votre tenant : sng tenant use mon-tenant.
  • Le droit d'écrire des secrets : la policy gérée readwrite (ou admin) suffit. En lecture seule (readonly), vous pouvez lister, décrire et lire, mais pas écrire. Voir Identité et accès.

1. Créer un secret avec une valeur générée​

Sans valeur fournie, sng secret set tire une valeur aléatoire de 16 caractères (lettres, chiffres, ponctuation) et l'enregistre.

sng secret set db-password
secret "db-password" saved with a generated 16-character value (sng secret get db-password)

Ajustez la forme de la valeur générée :

# 32 caractères, lettres et chiffres seulement
sng secret set api-key --length 32 --contains letters,numbers

# sans symboles, sans les caractères gênants dans une URL
sng secret set smtp-password --no-symbols --exclude-chars '@:/'

Deux façons de choisir les classes de caractères, exclusives l'une de l'autre :

  • en positif avec --contains : letter, number, symbol, lower, upper (alias acceptés : letters, alpha, digit, digits, numbers, symbols, punctuation, lowercase, uppercase) ;
  • en soustraction avec --no-lowercase, --no-uppercase, --no-numbers, --no-symbols.

Par défaut (--require-each-type), la valeur contient au moins un caractère de chaque classe retenue ; --length doit donc être au moins égal au nombre de classes.

2. Créer un secret avec une valeur que vous fournissez​

La méthode recommandée est le fichier : la valeur ne passe ni par l'historique du shell ni par la liste des processus.

printf '%s' 'S3cr3t-value' > /tmp/db-password
sng secret set db-password --from-file /tmp/db-password
rm /tmp/db-password
secret "db-password" saved

Le contenu du fichier est pris tel quel, saut de ligne final compris : utilisez printf plutôt que echo.

Pour un secret à plusieurs clés (par exemple tous les paramètres d'une connexion), passez --data autant de fois que nécessaire :

sng secret set shop-api \
--data DATABASE_URL=postgres://shop:pass@db:5432/shop \
--data SMTP_HOST=smtp.example.net \
--data SMTP_PASSWORD=xyz

--value existe aussi, mais la valeur apparaît alors dans l'historique de votre shell : réservez-le aux tests.

Où va la valeur ?

Un secret posé sans --data est stocké sous une seule clé nommée value. C'est cette clé que vous référencez ensuite depuis une App : { secret: db-password, key: value }. Avec --data, les clés sont celles que vous avez données. Voir Injecter un secret dans une App.

3. Relire un secret​

sng secret get db-password
{
"value": "S3cr3t-value"
}

Extraire une seule clé (sortie brute, sans JSON) :

sng secret get shop-api --key SMTP_PASSWORD
xyz

Écrire dans un fichier protégé plutôt qu'à l'écran :

sng secret get db-password --key value --out-file ./db-password
wrote ./db-password (mode 0600)

Le message est sur la sortie d'erreur ; le fichier est créé avec les permissions 0600.

Lire une version antérieure avec --version-id : voir Versions et restauration.

4. Lister et décrire​

sng secret list
NAME KEYS UPDATED
api-key 2026-10-07T09:12:41Z
db-password 2026-10-07T09:10:03Z
shop-api 2026-10-07T09:15:27Z

La colonne KEYS est vide dans cette version : la liste ne charge pas les clés. Utilisez describe pour les connaître.

sng secret describe shop-api
{
"name": "shop-api",
"keys": ["DATABASE_URL", "SMTP_HOST", "SMTP_PASSWORD"],
"updated_at": "2026-10-07T09:15:27Z",
"version_id": "1",
"version_stages": { "current": "1" },
"bindings": { "…": "…" }
}

describe ne renvoie jamais la valeur. Il renvoie les clés, la version courante et, si une rotation est armée, rotation_enabled, rotation_days et next_rotation_date. Le bloc bindings est un héritage : ignorez-le et utilisez la forme { secret, key } des Apps.

Vérification​

sng secret describe db-password --json | grep version_id

Une version "1" confirme la première écriture ; chaque set suivant incrémente.

Si ça ne marche pas​

MessageCauseCorrection
forbidden (no policy of this tenant allows it: see sng tenant policy list)Votre session n'a pas le droit d'écrire ou de lire des secretsDemander readwrite (ou une policy ciblée) à un administrateur
secret not foundNom mal orthographié, ou secret supprimésng secret list
Refus du nomMajuscule, / ou .. dans le nomVoir les règles de nommage ci-dessous
get renvoie une valeur avec un saut de ligne en tropLe fichier source a été écrit avec echoReposer la valeur avec printf

Pour aller plus loin​

  • Nom d'un secret : minuscules, chiffres, ., _, -, 128 caractères au plus, sans / ni ... Le nom est aussi celui que vos Apps référencent : choisissez-le comme un identifiant stable (db-password, pas db-password-v2).
  • Mettre à jour : relancer sng secret set NAME sur un nom existant crée une nouvelle version ; l'ancienne reste lisible avec --version-id.
  • Rotation planifiée : set accepte --rotation N pour demander à la plateforme de renouveler la valeur tous les N jours. Un set sans --rotation ne touche pas à une rotation déjà armée. Voir Rotation.
  • Permissions et API : set correspond à PUT /v1/secrets/{name} (action IAM ssm:write), get à GET /v1/secrets/{name}/value (ssm:read), list et describe à GET /v1/secrets et GET /v1/secrets/{name} (ssm:list, ssm:describe). Chaque lecture d'une valeur est tracée (nom et version, jamais la valeur).
  • Sortie machine : --json sur set, list, versions renvoie les objets de l'API tels quels.

Voir aussi​