Aller au contenu principal

Le modèle identité, session, tenant

Disponible

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

StackNGO sépare qui vous êtes (votre identité, vérifiée à la connexion) de ce que vous pouvez faire dans un tenant (une session, décidée par les policies du tenant). Comprendre ce découpage explique chaque message 401, 403 ou 409 que vous rencontrerez.

En pratique, tout tient en trois commandes :

sng sso login                 # 1. identité : connexion dans le navigateur
sng tenant use acme           # 2. session sur le tenant acme (1 h, renouvelée par sng)
sng secret list               # 3. une action, décidée par les policies de acme

Prérequis​

  • La CLI sng installée (Démarrer).
  • Un compte sur https://auth.dev.stackngo.app (la page de connexion de StackNGO).
  • Un tenant où une policy vous a été attachée (le créateur d'un tenant l'est automatiquement, voir Policies).

Les trois étapes​

1. L'identité​

sng sso login ouvre votre navigateur sur la page de connexion de StackNGO et enregistre votre identité dans ~/.config/stackngo/config.yaml. Elle prouve qui vous êtes ; elle ne donne accès à aucun tenant.

Il existe quatre formes d'identité ; la vôtre est la première :

IdentitéPrincipal à qui l'on attache des policiesTenant d'origine
Utilisateur (connexion dans le navigateur)votre utilisateur, et vos rôles org/nomaucun
Application machine (client_credentials, déclarée par une IAMApplication)app:<nom>aucun dans cette version (voir Machines)
Application déployée sur la plateforme—son tenant (pas encore disponible)
Job CI (GitLab ou GitHub, déclaré par un IAMOIDCTrust)oidc:<tenant>/<trust>le tenant du trust

Les trois dernières sont détaillées dans Identités machine et CI sans secret.

2. La session de tenant​

sng tenant use acme échange votre identité contre une session du tenant acme (POST /v1/iam/session). Pour qu'un utilisateur l'obtienne, une policy du tenant visé doit lui accorder l'action iam:AssumeRole sur la ressource tenant/acme. La policy gérée assume-role fait exactement cela.

La session porte votre identité, vos rôles et le tenant. Elle dure 1 heure : la CLI en rouvre une automatiquement quand elle expire. Toutes les commandes de tenant (sng apply, sng secret …, sng tenant policy …) utilisent cette session.

$ sng tenant use acme
current tenant: acme

Un tenant que vous venez de créer répond pendant quelques minutes 409 policies_pending : ses policies par défaut ne sont pas encore en vigueur. sng tenant use attend et réessaie tout seul (jusqu'à 6 minutes) :

$ sng tenant use acme
waiting for the tenant default policies...
current tenant: acme

3. L'action​

Chaque appel porte une action (ssm:read, deploy:write…) et une ressource (secret/db-password, app/api…). StackNGO cherche dans les policies attachées à votre identité dans le tenant de la session et décide :

  1. un Deny qui correspond → refus, quoi qu'il y ait ailleurs ;
  2. sinon un Allow qui correspond → accord ;
  3. sinon → refus (rien n'est permis par défaut).

Le catalogue des actions donne l'action et la ressource de chaque commande.

Changer de tenant : assume​

Vous avez une session sur acme et devez agir sur acme-staging ? Deux voies :

  • sng tenant use acme-staging : repart de votre identité (le cas normal pour une personne) ;
  • sng tenant assume acme-staging : échange la session courante contre une session sur l'autre tenant (POST /v1/iam/session/assume). C'est la voie des scripts et des machines, qui n'ont qu'une session à présenter.

Dans les deux cas, c'est une policy d'acme-staging qui doit accorder iam:AssumeRole sur tenant/acme-staging. La session obtenue par assume garde la trace du tenant d'origine et n'expire jamais après la session dont elle vient : enchaîner des assume ne prolonge pas un accès.

$ sng tenant assume acme-staging
current tenant: acme-staging (assumed from acme)

Vue d'ensemble​

La frontière de tenant​

Comme un compte chez un fournisseur de cloud, un tenant est une frontière : une policy ne s'applique qu'aux ressources de son tenant, quel que soit son contenu. Même la policy admin (* sur *) de acme ne donne rien sur acme-staging.

  • Une demande sur une ressource d'un autre tenant est refusée, quelles que soient vos policies (raison cross_tenant).
  • Sur les routes /v1/tenants/<tenant>/…, le tenant du chemin doit être celui de la session, sinon 403.
  • Le tenant d'une requête vient uniquement de la session. Aucun en-tête, aucun paramètre ne permet d'en désigner un autre ; l'ancien en-tête X-Tenant-Token est refusé (400).

Pour agir sur un autre tenant, il faut donc une session de cet autre tenant : sng tenant use ou sng tenant assume.

Ce que vous pouvez en attendre​

  • Refus par défaut : si une permission ne peut pas être vérifiée, l'API répond 503 authorization service unavailable, jamais un accord. Réessayez quelques instants plus tard.
  • Délais : un droit accordé ou retiré prend effet en quelques minutes ; le retrait d'un rôle prend effet à l'expiration de la session (1 h au plus).

Messages que vous rencontrerez​

Message de sngCauseQue faire
not authenticated: run sng sso loginpas d'identité enregistrée, ou expiréesng sso login
tenant session required: run sng tenant use NAMEcommande de tenant sans sessionsng tenant use <tenant>
session expired: run sng tenant use NAMEsession de 1 h expirée et renouvellement impossiblesng tenant use <tenant>
forbidden: no iam:AssumeRole on tenant/acme …aucune policy d'acme ne vous accorde iam:AssumeRoledemander à un admin : sng tenant policy attach readonly -t acme --user vous --with-assume
forbidden (no policy of this tenant allows it…)action refusée par les policiessng tenant policy list, puis attacher une policy adaptée
policies_pendingtenant neuf, plus de 6 min d'attenteréessayer sng tenant use
authorization service unavailable: retry laterpermission impossible à vérifier pour l'instantréessayer plus tard

Pour aller plus loin​

  • Les variables STNG_ACCESS_TOKEN, STNG_TENANT_TOKEN et STNG_TENANT remplacent l'identité, la session et le tenant enregistrés dans ~/.config/stackngo/config.yaml : utile en CI.
  • Les détails d'appel (corps, codes) sont dans Authentification de l'API.
  • Les garanties d'isolement sont résumées dans Sécurité et confidentialité.

Voir aussi​