sng 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.

Le groupe sng tenant gère vos tenants et la session qui vous y donne accès : lister, créer, entrer dans un tenant (use), passer d'un tenant à l'autre (assume), le détruire. Ses sous-groupes règlent qui peut faire quoi (policy), la taille du tenant (tier), les pipelines CI de confiance (oidc) et le compte qui paie le tenant (billing).

sng tenant create acme
sng tenant use acme
sng tenant policy attach readonly --user bob --with-assume

Le modèle (identité, session, frontière de tenant) est expliqué dans Le modèle identité, session, tenant. Les flags globaux (--config, --json, -v, --version) sont décrits dans l'index de la CLI.

Deux jetons, deux familles de commandes.

• list, create et use présentent votre identité (sng sso login). Sans elle : not authenticated: run sng sso login.
• Toutes les autres commandes présentent la session du tenant (1 h). La CLI la rouvre toute seule avec votre identité quand elle expire ou qu'elle est refusée (401), et enregistre la nouvelle. Sans session : tenant session required: run sng tenant use NAME.

Actions IAM par commande :

Commande	Action IAM	Ressource	Route
list	aucune (identité)	—	GET /v1/tenants
create	aucune (organisation plateforme)	—	POST /v1/tenants
use	iam:assumerole (policy du tenant visé)	tenant/<tenant>	POST /v1/iam/session
assume	iam:assumerole (policy du tenant visé)	tenant/<tenant>	POST /v1/iam/session/assume
destroy	iam:admin	tenant/<tenant>	DELETE /v1/tenants/{tenant}
policy list	policy:list	policy/*	GET /v1/iam/policies
policy get, policy principals	policy:read	policy/<nom>	GET /v1/iam/policies/{name}[/principals]
policy create, update, delete	policy:admin	policy/<nom>	PUT / DELETE /v1/iam/policies/{name}
policy attach, detach	policy:admin	policy/<nom>	POST /v1/iam/policies/{name}/attach / detach
tier list	tier:list	tier/<tenant>	GET /v1/tiers
tier show	tier:read	tier/<tenant>	GET /v1/tier
tier set	tier:write	tier/<tenant>	PUT /v1/tier
oidc list	oidctrust:list	oidctrust/*	GET /v1/iam/oidc-trusts
oidc get	oidctrust:read	oidctrust/<nom>	GET /v1/iam/oidc-trusts/{name}
oidc create, delete	oidctrust:admin	oidctrust/<nom>	GET puis PUT / DELETE /v1/iam/oidc-trusts/{name}
billing get, set	iam:admin	tenant/<tenant>	GET /v1/billing/tenants/{tenant} / POST /v1/tenants/{tenant}/billing-owner/invitations

Le détail de chaque action est dans le catalogue des actions.

sng tenant list

sng tenant list [--json]

Liste les tenants où vous détenez au moins une policy, directement ou par un de vos rôles SSO. Le tenant courant est marqué *.

Flag	Type	Défaut	Description
(aucun flag propre)

sng tenant list

TENANT        POLICIES            CURRENT
acme          admin,assume-role   *
acme-staging  assume-role,readonly

Sans tenant : no tenants. Figurer dans la liste ne suffit pas pour entrer : il faut assume-role (voir use).

Sortie --json : {"tenants": [{"tenant": "acme", "policies": ["admin", "assume-role"]}]}.

sng tenant create

sng tenant create NAME

Crée un tenant. Vous en devenez administrateur : ses policies par défaut vous lient à assume-role et admin en quelques minutes. La commande est ouverte aux utilisateurs de l'organisation de la plateforme ; une machine ne crée pas de tenant.

Argument	Description
NAME	nom du tenant : minuscules, chiffres et -, commence par une lettre ou un chiffre, 30 caractères au plus

Le nom devient aussi un nom de domaine et un annuaire d'identité : les noms d'environnement (dev, prod, staging…), de composants de la plateforme (api, auth, iam, console…), les termes génériques (admin, tenant, default…) et les préfixes kube-, stackngo-, sng- sont réservés.

sng tenant create acme

tenant "acme" created: its default policies (assume-role and admin for you) are usually applied within a minute
next: sng tenant use acme

Sortie --json : {"name": "acme"}.

Erreurs typiques :

Message	Cause
reserved name (400)	nom réservé
bad request (400)	nom invalide ou trop long
conflict (409)	le tenant existe déjà, ou le nom est déjà pris sur la plateforme
forbidden … (403)	votre compte n'appartient pas à l'organisation de la plateforme
… lookup unavailable (503)	vérification du nom impossible pour l'instant : réessayez

sng tenant use

sng tenant use NAME

Ouvre une session sur le tenant NAME avec votre identité, l'enregistre dans le fichier de configuration et en fait le tenant courant. La session dure 1 h ; la CLI la renouvelle ensuite toute seule.

Il faut qu'une policy du tenant visé vous accorde iam:assumerole sur tenant/NAME (policy gérée assume-role). Un tenant créé il y a moins de 5 minutes répond 409 policies_pending : la commande attend et réessaie jusqu'à 6 minutes, au rythme indiqué par Retry-After.

Argument	Description
NAME	tenant visé

sng tenant use acme

waiting for the tenant default policies to be applied...
current tenant: acme

La première ligne, sur la sortie d'erreur, n'apparaît que pour un tenant tout neuf.

Erreurs typiques :

Message	Cause
no assume-role on tenant "acme": ask an admin to run `sng tenant policy attach assume-role -t acme --user YOU` (403)	aucune policy d'acme ne vous accorde iam:assumerole : demandez à un administrateur de lancer la commande indiquée, avec votre nom d'utilisateur. Avec -v, la réponse de l'API suit le message
tenant policies not applied yet; retry `sng tenant use acme` in a minute (409)	tenant neuf, encore en attente après 6 minutes : relancez sng tenant use un peu plus tard
not authenticated: run sng sso login	identité absente, expirée ou refusée (401)
unknown tenant (404)	le tenant n'existe pas

sng tenant assume

sng tenant assume NAME [--print]

Échange la session courante contre une session sur NAME (POST /v1/iam/session/assume), sans rejouer votre identité. C'est la voie des scripts et des machines, qui n'ont qu'une session. Une policy de NAME doit accorder iam:assumerole au sujet de la session courante. La nouvelle session garde la trace du tenant d'origine (origin_tenant) et n'expire jamais après la session dont elle vient.

Argument	Description
NAME	tenant visé

Flag	Type	Défaut	Description
--print	bool	false	imprime le jeton de session au lieu de changer le tenant courant

sng tenant assume acme-staging
TOKEN=$(sng tenant assume acme-staging --print)

current tenant: acme-staging (assumed from acme)

Sortie --json (sans --print) : {"tenant": "acme-staging", "origin_tenant": "acme"}.

Erreurs typiques : no assume-role on tenant "acme-staging" for the current session subject (403, aucune policy d'acme-staging n'accorde iam:assumerole au sujet de la session ; -v ajoute la réponse de l'API) ; tenant session required: run sng tenant use NAME (pas de session à échanger) ; unknown tenant (404).

Renouvellement après assume

Le tenant courant devient NAME. À l'expiration, la CLI renouvelle la session avec votre identité sur NAME (comme sng tenant use NAME), pas par un nouvel assume.

sng tenant destroy

sng tenant destroy NAME [--yes]

Détruit un tenant et tout ce qu'il contient : annuaire d'identité (sng iam), secrets, état désiré et historique de déploiement, policies. Irréversible. Demande confirmation (tapez oui) sauf avec --yes.

Il faut une session sur ce tenant (sng tenant use NAME avant) et l'action iam:admin sur tenant/NAME (policy admin).

Argument	Description
NAME	tenant à détruire ; doit être le tenant courant

Flag	Type	Défaut	Description
--yes, -y	bool	false	confirmer sans invite interactive

sng tenant use acme-old
sng tenant destroy acme-old

⚠ Permanently destroy tenant "acme-old" (users, applications, secrets, resources).
Tapez « oui » pour confirmer : oui
tenant "acme-old" destroyed

Le tenant courant est ensuite vidé : lancez sng tenant use sur un autre tenant.

Erreurs typiques : session tenant is "acme"; run `sng tenant use acme-old` first ; confirmation requise : relancez avec --yes ou depuis un terminal interactif ; forbidden (403, pas d'iam:admin).

sng tenant policy

Disponible

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

sng tenant policy (list | get | create | update | delete | attach | detach | principals) [-t TENANT]

Gère les policies du tenant : des documents Effect / Actions / Resources qui disent qui peut faire quoi, et leurs attachements à des sujets. Le format du document est décrit dans Écrire une policy ; les sujets dans Attacher une policy.

Les écritures sont acceptées puis appliquées en quelques minutes : le statut passe de pending à applied. Les policies gérées (assume-role, readonly, readwrite, admin, plus celles que la plateforme utilise pour ses propres services) ne se modifient ni ne se suppriment, mais s'attachent.

Flag commun à toutes les sous-commandes :

Flag	Type	Défaut	Description
--tenant, -t	string	(tenant courant)	tenant visé ; la CLI ouvre une session sur ce tenant pour la seule commande, sans changer le tenant courant (il vous y faut iam:assumerole)

sng tenant policy list

sng tenant policy list [-t TENANT] [--json]

Liste les policies du tenant, gérées comprises.

sng tenant policy list

NAME          DEFAULT  STATUS   VERSION  DESCRIPTION
admin         yes      applied  1        Accès complet au tenant, y compris la gestion des utilisateurs, des rôles et des policies.
assume-role   yes      applied  1        Permet d'ouvrir une session sur ce tenant.
ops-read               pending           lecture des secrets hors production
readonly      yes      applied  1        Lecture seule : consulter les ressources du tenant sans rien modifier.
readwrite     yes      applied  1        Lecture et écriture des ressources du tenant (secrets, déploiements, sites, images), sans gestion des accès.
…

Les policies gérées portent une description rédigée par la plateforme ; celles qui lui sont réservées sont signalées « Réservée à la plateforme … Ne pas attacher. ».

Statut	Signification
applied	le document demandé est en vigueur
pending	créé ou modifié, pas encore appliqué
deleting	suppression demandée, policy encore en vigueur quelques instants

Sans policy : no policies.

Sortie --json : un tableau [{"name": "…", "description": "…", "default": false, "status": "applied", "version": 2, "document": {…}}].

sng tenant policy get

sng tenant policy get NAME [-t TENANT] [--json]

Imprime le document JSON de la policy. Avec --json, l'objet complet : name, description, default, status, version, document.

Argument	Description
NAME	nom de la policy

sng tenant policy get readonly

{
  "Version": "1",
  "Statement": [
    {
      "Effect": "Allow",
      "Actions": ["*:read", "*:list", "*:describe", "deploy:logs", "registry:pull", "GET", "HEAD"],
      "Resources": ["*"]
    }
  ]
}

Erreur : not found (404).

sng tenant policy create

sng tenant policy create NAME -f FILE [--description TEXT] [-t TENANT]

Crée une policy. Refuse une policy qui existe déjà.

Argument	Description
NAME	nom : minuscules, chiffres et -, 63 caractères au plus ; ni un nom de policy gérée, ni le préfixe bind-

Flag	Type	Défaut	Description
--file, -f	string	(requis)	document de policy en JSON ou YAML, sortie de policy get --json, ou manifeste IAMPolicy ; - lit l'entrée standard
--description	string		description ; à défaut, celle du fichier (description, ou spec.description d'un manifeste)

sng tenant policy create ops-read -f ops-read.json --description "lecture des secrets hors production"
sng tenant policy create ops-read -f ops-read.yml        # manifeste IAMPolicy

policy "ops-read" created (pending: usually applied within a minute)

Sortie --json : la policy telle qu'acceptée, status: "pending".

Erreurs typiques :

Message	Cause
policy "ops-read" already exists: use `sng tenant policy update ops-read -f FILE`	la policy existe (y compris une policy gérée)
ops-read.json: not a JSON or YAML object	fichier illisible
IAMPolicy: spec.statement is empty	manifeste sans statement
policies: invalid request: … (400)	document invalide (effet, action, ressource, limite) ou nom invalide
policies: reserved: … (409)	nom d'une policy gérée, ou tenant système

sng tenant policy update

sng tenant policy update NAME -f FILE [--description TEXT] [-t TENANT]

Remplace le document d'une policy existante. Mêmes flags et formats que create.

policy "ops-read" updated (pending: usually applied within a minute)

Erreur propre : policy "x" does not exist: use `sng tenant policy create x -f FILE` . Sur une policy gérée : 409.

sng tenant policy delete

sng tenant policy delete NAME [--yes] [-t TENANT]

Supprime une policy et son attachement (bind-<nom>). Demande confirmation sauf avec --yes.

Flag	Type	Défaut	Description
--yes, -y	bool	false	confirmer sans invite interactive

sng tenant policy delete ops-read --yes

policy "ops-read" deletion requested (usually applied within a minute)

Erreurs : not found (404) ; 409 sur une policy gérée.

sng tenant policy attach

sng tenant policy attach NAME [--user U]... [--role ORG/NOM]...
                              [--app NOM]... [--oidc-trust TRUST]...
                              [--with-assume] [-t TENANT]

Attache une policy (la vôtre ou une policy gérée) à des sujets. Cumulatif : les sujets s'ajoutent à ceux déjà attachés. C'est aussi ainsi qu'on ajoute quelqu'un à un tenant (--with-assume).

Argument	Description
NAME	policy à attacher

Flag	Type	Défaut	Description
--user	string, répétable		utilisateur du SSO : nom, org/nom ou e-mail
--role	string, répétable		rôle du SSO, forme org/NOM obligatoire
--app	string, répétable		application machine, nom SSO (status.provider.name de l'IAMApplication)
--oidc-trust	string, répétable		trust OIDC du tenant, nom seul (sans /) — Bêta
--with-assume	bool	false	attache aussi la policy assume-role aux mêmes sujets (nécessaire pour qu'un utilisateur ouvre une session)

sng tenant policy attach readonly --user bob --with-assume
sng tenant policy attach readwrite --role stackngo/dev --with-assume
sng tenant policy attach ops-read --app sng-1a2b3c4d-5e6f7a8b-app-ci-deployer

policy "readonly" bound to user:bob (pending: usually applied within a minute)
policy "assume-role" bound to user:bob (pending: usually applied within a minute)

Erreurs typiques :

Message	Cause
at least one --user, --role, … is required	aucun sujet
--role "dev": expected org/NAME (e.g. stackngo/platform-admin)	rôle sans organisation
--oidc-trust "acme/ci": expected a trust NAME of the tenant (see `sng tenant oidc list`)	nom de trust avec /
subjects must be explicit (no empty value, no global *)	valeur vide ou *
not found (404)	la policy n'existe pas dans le tenant
forbidden: insufficient permissions (no policy of this tenant allows it: …) (403)	pas de policy:admin

Avec --with-assume, la CLI attache d'abord NAME, puis assume-role : si la seconde écriture échoue, la première reste faite (la ligne bound to déjà affichée le montre).

sng tenant policy detach

sng tenant policy detach NAME [mêmes flags de sujets] [--with-assume] [-t TENANT]

Retire des sujets d'une policy. --with-assume les retire aussi d'assume-role. Retirer le dernier sujet supprime l'attachement.

sng tenant policy detach readonly --user bob --with-assume

policy "readonly" unbound from user:bob (pending: usually applied within a minute)
policy "assume-role" unbound from user:bob (pending: usually applied within a minute)

sng tenant policy principals

sng tenant policy principals NAME [-t TENANT] [--json]

Montre à qui la policy est attachée : les principaux appliqués (identifiants résolus, un utilisateur apparaît par son sub) et les sujets demandés.

sng tenant policy principals readonly

STATE      KIND  ID
applied    user  7f3e2c1a-0b5d-4c1e-9a77-2d0c4e8f1b23
requested  user  bob

Sans attachement : not bound.

Sortie --json : {"principals": [{"kind": "user", "id": "…"}], "desired": {"users": ["bob"]}} (desired vaut null sans attachement demandé).

sng tenant tier

Bêta

Fonctionnalité en cours de déploiement. L'interface décrite ici est celle de la prochaine livraison : elle peut encore évoluer, et n'est pas forcément activée sur votre tenant.

Activé progressivement sur les tenants.

sng tenant tier (list | show | set TIER) [-t TENANT]

Le tier borne les ressources de votre tenant : CPU et mémoire garantis (requests.*), plafonds (limits.*), stockage et nombre d'instances. Grille, du plus petit au plus grand : 3XS, 2XS, XS, S, M, L, XL, 2XL, 3XL ; les anciens noms XXS, XXL et XXXL restent acceptés et désignent 3XS, 2XL et 3XL. Le catalogue vient de l'API ; la CLI n'envoie jamais que le nom du tier. Un nouveau tenant démarre en 3XS. Valeurs : Tiers et quotas. Monter est toujours permis ; descendre est refusé tant que la consommation actuelle ne tient pas dans le tier demandé.

Flag	Type	Défaut	Description
--tenant, -t	string	(tenant courant)	tenant visé

sng tenant tier list

sng tenant tier list

TIER  REQUESTS.CPU  REQUESTS.MEMORY  LIMITS.CPU  LIMITS.MEMORY  …
3XS   500m          1Gi              1           2Gi            …
2XS   500m          1Gi              2           4Gi            …
XS    1             2Gi              4           8Gi            …
S     4             8Gi              4           8Gi            …
…

La sortie de votre sng tenant tier list fait foi. La dernière colonne donne le nombre maximal d'instances.

Sortie --json : {"tiers": [{"name": "3XS", "hard": {"requests.cpu": "500m", …}}], "keys": ["requests.cpu", "requests.memory", "limits.cpu", "limits.memory", …]}.

sng tenant tier show

sng tenant tier show

tenant acme: tier 3XS
RESOURCE         USED   HARD
requests.cpu     250m   500m
requests.memory  512Mi  1Gi
limits.cpu       500m   1
limits.memory    1Gi    2Gi
…

Juste après un changement de tier, tant que la consommation n'est pas encore calculée, USED vaut - et la commande ajoute usage not available yet (quota not synced).

Sortie --json : {"tenant": "acme", "tier": "3XS", "hard": {…}, "used": {…}, "keys": […]} (used absent si indisponible).

sng tenant tier set

sng tenant tier set TIER [-t TENANT]

Change le tier (nom insensible à la casse ; XXS, XXL et XXXL valent 3XS, 2XL et 3XL). Exige tier:write : la policy admin, pas readwrite.

sng tenant tier set S

tenant acme: tier 3XS -> S (…)

Si le tenant est déjà sur ce tier : tenant acme: already on tier S.

Sortie --json : {"tenant": "acme", "tier": "S", "previous": "3XS"}.

Erreurs typiques :

Message	Cause
unknown tier "4XL" (see GET /v1/tiers) (400)	nom hors catalogue
tier too small: cannot downgrade to 3XS: requests.memory 1536Mi > 1Gi (409)	la consommation actuelle dépasse le tier demandé
tier usage unavailable (503)	consommation illisible : une descente est refusée par prudence, réessayez
forbidden (…) (403)	pas de tier:write

sng tenant oidc

Bêta

Fonctionnalité en cours de déploiement. L'interface décrite ici est celle de la prochaine livraison : elle peut encore évoluer, et n'est pas forcément activée sur votre tenant.

La fédération des pipelines CI est activée progressivement.

sng tenant oidc (list | get NAME | create NAME | delete NAME)

Gère les trusts OIDC du tenant courant (IAMOIDCTrust) : les pipelines GitLab CI ou GitHub Actions autorisés à ouvrir une session avec le jeton OIDC de leur job, sans secret stocké. Un trust n'accorde aucun droit : attachez-lui une policy avec sng tenant policy attach POLICY --oidc-trust NAME. Le guide complet est Déployer sans secret (OIDC).

Ces commandes agissent toujours sur le tenant de la session : elles n'ont pas de flag -t.

sng tenant oidc list

sng tenant oidc list

NAME           ISSUER              SUBJECT                                           STATUS
gitlab-deploy  https://gitlab.com  project_path:acme/infra:ref_type:branch:ref:main  applied

Sans trust : no OIDC trusts. Statuts : applied, pending, deleting.

Sortie --json : un tableau [{"name": "…", "status": "…", "version": 1, "spec": {…}}].

sng tenant oidc get

sng tenant oidc get gitlab-deploy

name:        gitlab-deploy
status:      applied
issuer:      https://gitlab.com
audiences:   https://api.dev.stackngo.fr
subject:     project_path:acme/infra:ref_type:branch:ref:main
claims:      project_id=4242; ref_protected=true
max session: 1h (default)
discovery:   ok

La ligne discovery donne le résultat de la vérification de l'émetteur, faite quand le trust est appliqué : ok, ou failed: <cause> (retried on use) si l'émetteur n'a pas répondu (la vérification est refaite à chaque échange de jeton). Elle est absente tant que le trust n'a pas encore été vérifié (statut pending).

sng tenant oidc create

sng tenant oidc create NAME (-f FILE | --gitlab-project GROUP/PROJECT | --github-repo ORG/REPO | --issuer URL --subject MOTIF)
                            [--ref BRANCHE] [--gitlab-url URL] [--audience AUD]... [--claim K=V1,V2]...
                            [--max-session DURÉE]

Déclare un trust. Refuse un nom déjà utilisé (supprimez d'abord l'ancien).

Argument	Description
NAME	nom du trust : minuscules, chiffres et -, 63 caractères au plus

Flag	Type	Défaut	Description
--file, -f	string		manifeste IAMOIDCTrust (sans tenant précisé), sortie de oidc get --json, ou spec seule, en JSON ou YAML ; - lit l'entrée standard ; exclusif avec tous les autres flags
--gitlab-project	string		aide GitLab : émetteur = --gitlab-url, sujet project_path:GROUP/PROJECT:ref_type:branch:ref:REF
--gitlab-url	string	https://gitlab.com	instance GitLab (avec --gitlab-project seulement)
--github-repo	string		aide GitHub : émetteur https://token.actions.githubusercontent.com, sujet repo:ORG/REPO:ref:refs/heads/REF
--ref	string	main	branche de confiance des aides ; * = toutes les branches
--issuer	string		émetteur quelconque, en https:// (avec --subject, sans aide)
--subject	string		motif du sub (joker *, au moins 8 caractères littéraux avant le premier *)
--audience	string, répétable	(URL de l'API)	audience acceptée
--claim	CLÉ=V1,V2, répétable		claim exigé : ET entre clés, OU entre valeurs
--max-session	durée	1h	durée des sessions ouvertes par ce trust, de 5m à 1h

sng tenant oidc create gitlab-deploy --gitlab-project acme/infra --ref main \
  --claim project_id=4242 --claim ref_protected=true
sng tenant oidc create github-deploy --github-repo acme/infra --claim repository_id=123456789
sng tenant oidc create ci -f ci-trust.yml

OIDC trust "gitlab-deploy" created in tenant "acme" (pending: …)
subject: project_path:acme/infra:ref_type:branch:ref:main
next: sng tenant policy attach POLICY --oidc-trust gitlab-deploy

Sortie --json : le trust accepté, status: "pending".

Erreurs typiques : -f and --gitlab-project are mutually exclusive ; --gitlab-project and --github-repo are mutually exclusive ; --gitlab-project generates issuer and subject: drop --issuer ; --ref only applies with --gitlab-project or --github-repo ; -f FILE, --issuer and --subject, --gitlab-project or --github-repo is required ; subject "*": must not start with '*' ; maxSessionDuration "2h": must be between 5m and 1h ; ci-trust.yml: metadata.… (acme) is not allowed: … (tenant précisé dans le manifeste) ; OIDC trust "gitlab-deploy" already exists in tenant "acme": delete it first ; policies: invalid request: at most 20 oidc trusts per tenant (400).

sng tenant oidc delete

sng tenant oidc delete NAME [--yes]

Supprime un trust : les jobs CI qui s'y appuient ne peuvent plus ouvrir de session. Les sessions déjà ouvertes vont jusqu'à leur expiration. Les attachements qui le citent restent, sans effet.

Flag	Type	Défaut	Description
--yes, -y	bool	false	confirmer sans invite interactive

OIDC trust "gitlab-deploy" deletion requested (…)

sng tenant billing

Bêta

Fonctionnalité en cours de déploiement. L'interface décrite ici est celle de la prochaine livraison : elle peut encore évoluer, et n'est pas forcément activée sur votre tenant.

sng tenant billing get TENANT
sng tenant billing set TENANT EMAIL

Réservé aux administrateurs du tenant. Un tenant est facturé à un compte StackNGO, son payeur : son créateur au départ, puis le compte qui accepte une invitation à reprendre la facturation. get montre le payeur (nom et e-mail masqué), l'invitation en attente et, le cas échéant, la date de suppression d'un tenant que plus personne ne paie. set invite une adresse : rien ne change tant que le compte invité n'a pas accepté.

Argument	Description
TENANT	tenant concerné
EMAIL	adresse vérifiée du compte invité

sng tenant billing get acme
sng tenant billing set acme jane@example.com

TENANT  TIER  PAYER       E-MAIL            PENDING                            NOTICE
acme    3XS   Jane (you)  j***@example.com  bob@example.com (until 2026-11-16)  -
If a Stackngo account matches this address, an invitation has been sent to it.

Si un compte StackNGO porte cette adresse vérifiée, il reçoit un lien valable 7 jours ; la réponse est la même dans tous les cas. Une nouvelle invitation remplace celle en attente. Le payeur ne reçoit aucun droit sur le tenant.

Sortie --json de get : {"tenant": "acme", "tier": "3XS", "payer": {"name": "Jane", "email": "j***@example.com", "isYou": true}, "pending": {…} | null, "notice": {"deleteAt": "…"} | null}. Sans la policy admin du tenant : 403.

Voir aussi

• Guides : Le modèle identité, session, tenant, Écrire une policy, Attacher une policy, Catalogue des actions, Machines et comptes de service, Déployer sans secret (OIDC)
• Manifestes : IAMPolicy, IAMPolicyBinding, IAMOIDCTrust
• Commandes voisines : sng sso, sng iam
• API : Authentification