Identités machine

Disponible

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

Une machine n'a pas de navigateur : elle prouve son identité autrement, puis obtient une session de tenant comme vous. Elle n'y peut rien tant qu'une policy ne lui est pas attachée.

Identité	Pour qui	Ce qu'elle présente	Principal à attacher
Application machine	un serveur, un script, une de vos applications	un identifiant et un secret client (`client_credentials`)	`--app <nom>`
Job CI	GitLab CI, GitHub Actions	sa propre identité de job, sans secret, via un `IAMOIDCTrust`	`--oidc-trust <nom>`

Applications déployées sur la plateforme

Une application qui tourne sur la plateforme pourra obtenir une session de son tenant sans aucun secret. Ce parcours n'est pas encore disponible depuis un manifeste App : en attendant, donnez-lui une application machine et passez-lui ses identifiants comme un secret.

Prérequis

Une session sur le tenant : sng tenant use acme.
policy:admin pour attacher (policy admin).

Option A : une application machine (`client_credentials`)

1. Déclarer l'application

ci-deployer.yml
apiVersion: iam.stackngo.io/v1alpha1
kind: IAMApplication
metadata:
  name: ci-deployer
spec:
  displayName: Déployeur externe
  grantTypes: [client_credentials]
  token:
    expireInHours: 1

sng apply ci-deployer.yml

2. Trouver son nom et ses identifiants

sng kind get IAMApplication ci-deployer --json      # status.provider.name = sng-<empreinte>-app-ci-deployer
sng iam app credentials ci-deployer            # clientId, clientSecret, issuer

status.provider.name donne le nom complet de l'application (à passer à sng tenant policy attach --app) ; credentials affiche son clientId et son clientSecret (action auth:ReadCredentials, policy admin). Pour une de vos App, les mêmes identifiants sont disponibles sous le nom ci-deployer-oidc (clés clientId, clientSecret, issuer), à référencer comme un secret dans env :

env:
  CLIENT_ID: { secret: ci-deployer-oidc, key: clientId }
  CLIENT_SECRET: { secret: ci-deployer-oidc, key: clientSecret }

3. Attacher une policy

sng tenant policy attach readwrite --app sng-1a2b3c4d-5e6f7a8b-app-ci-deployer --with-assume

--with-assume est nécessaire : dans cette version, une application machine n'a pas de tenant d'origine. Elle doit recevoir assume-role et préciser le tenant à l'ouverture de sa session.

4. Obtenir une session depuis la machine

# 1. identité auprès du service de connexion
ACCESS=$(curl -s -X POST https://auth.dev.stackngo.app/api/login/oauth/access_token \
  -d grant_type=client_credentials -d client_id="$CLIENT_ID" -d client_secret="$CLIENT_SECRET" \
  | jq -r .access_token)
# 2. session sur le tenant
SESSION=$(curl -s -X POST https://api.dev.stackngo.fr/v1/iam/session \
  -H "Authorization: Bearer $ACCESS" -H "Content-Type: application/json" \
  -d '{"tenant":"acme"}' | jq -r .access_token)
# 3. un appel
curl -s https://api.dev.stackngo.fr/v1/secrets -H "Authorization: Bearer $SESSION"

Avec la CLI, les deux premières étapes tiennent en deux commandes :

sng sso login --client-credentials --client-id "$CLIENT_ID" --client-secret "$CLIENT_SECRET"
sng tenant use acme
sng secret list

--client-id et --client-secret peuvent aussi venir de STNG_OAUTH_CLIENT_ID et STNG_OAUTH_CLIENT_SECRET, pour ne rien laisser dans l'historique des commandes.

Option B : un job CI (OIDC, sans secret)

GitLab CI et GitHub Actions donnent une identité à chaque job. Un IAMOIDCTrust dit à StackNGO de l'accepter ; aucun secret n'est stocké dans la CI. Le guide complet est CI sans secret (OIDC) ; le principal à attacher est --oidc-trust <nom>.

Vérification

sng tenant policy principals readwrite

STATE      KIND  ID
applied    app   sng-1a2b3c4d-5e6f7a8b-app-ci-deployer
requested  app   sng-1a2b3c4d-5e6f7a8b-app-ci-deployer

Et depuis la machine, un appel qui réussit : GET /v1/secrets répond 200 ; sans policy, 403 forbidden.

Ce que vous pouvez en attendre

Une session machine dure 1 h au plus : rejouez POST /v1/iam/session à l'expiration (401).
Pour agir sur un autre tenant depuis une session : POST /v1/iam/session/assume avec {"tenant": "autre"}, si une policy de l'autre tenant accorde iam:AssumeRole à votre application.
Le registre d'images et le service de secrets acceptent la même session (Authorization: Bearer), avec les actions registry:* et ssm:* du catalogue.

Erreurs fréquentes

Symptôme	Cause	Correction
`401 invalid identity token` à `POST /v1/iam/session`	identité expirée ou mal copiée	redemander une identité (étape 4.1)
`400 tenant required`	`tenant` absent du corps	ajouter `{"tenant": "acme"}`
`403 forbidden: no iam:AssumeRole on tenant/acme`	`assume-role` non attachée à l'application	`sng tenant policy attach assume-role --app …`
`403 forbidden` sur une route du tenant	session obtenue mais aucune policy	`sng tenant policy attach … --app …`

Prérequis​

Option A : une application machine (client_credentials)​

1. Déclarer l'application​

2. Trouver son nom et ses identifiants​

3. Attacher une policy​

4. Obtenir une session depuis la machine​

Option B : un job CI (OIDC, sans secret)​

Vérification​

Ce que vous pouvez en attendre​

Erreurs fréquentes​

Voir aussi​