Aller au contenu principal

Attacher une 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.

Une policy ne fait rien tant qu'elle n'est pas attachée à un sujet. sng tenant policy attach lie une policy (la vôtre ou une policy gérée) à des utilisateurs, des rôles, des machines ; detach défait le lien. C'est aussi par là que vous ajoutez quelqu'un à votre tenant.

sng tenant policy attach readonly --user bob --with-assume
policy "readonly" bound to user:bob (pending: applied in a few minutes)
policy "assume-role" bound to user:bob (pending: applied in a few minutes)

Bob peut maintenant faire sng tenant use acme (grâce à assume-role) et lire (grâce à readonly), quelques minutes plus tard.

Prérequis​

  • Une session sur le tenant : sng tenant use acme.
  • L'action policy:admin sur la policy visée (policy gérée admin).
  • Pour --oidc-trust, un trust déclaré (CI sans secret).

Étapes​

1. Choisir le sujet​

Flag (répétable)SujetForme attenduePrincipal résolu
--userun utilisateur de StackNGObob, stackngo/bob ou bob@example.comuser:<sub> (stable même si l'utilisateur est renommé)
--roleun rôle porté par des utilisateurs de StackNGOorg/NOM, ex. stackngo/srerole:org/NOM
--appune application machine (client_credentials)nom complet de l'application, donné par status.provider.name (sng kind get IAMApplication NOM --json)app:<nom>
--oidc-trustles jobs CI fédérés par un trust du tenantgitlab-deploy (nom seul, sans /)oidc:acme/gitlab-deploy

Règles :

  • au moins un sujet ; les valeurs vides et le joker * sont refusés (« un groupe d'utilisateurs est un rôle ») ;
  • --role exige la forme org/NOM ;
  • --app attend le nom complet de l'application (sng-<empreinte>-app-<nom>), lu dans status.provider.name de l'IAMApplication (voir Identités machine).
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.

Le flag --oidc-trust est activé progressivement avec la fédération CI.

2. Attacher​

sng tenant policy attach NAME [sujets...] [--with-assume] [-t TENANT]
  • --with-assume attache en plus la policy gérée assume-role aux mêmes sujets : sans elle, un utilisateur ou une application machine ne peut pas ouvrir de session sur le tenant. Les jobs CI fédérés par un trust du tenant n'en ont pas besoin.
  • -t TENANT vise un autre tenant que le courant : sng ouvre une session sur ce tenant pour la commande (il vous faut iam:AssumeRole là-bas).
  • Attacher est cumulatif : les sujets s'ajoutent à ceux déjà liés.

Exemples :

# un rôle complet en lecture-écriture, avec entrée dans le tenant
sng tenant policy attach readwrite --role stackngo/dev --with-assume

# une CI GitLab fédérée : publie le CDN, rien d'autre
sng tenant policy attach cdn-publisher --oidc-trust gitlab-deploy

# une application machine lit les secrets
sng tenant policy attach ops-read --app sng-1a2b3c4d-5e6f7a8b-app-ci-deployer --with-assume

3. Détacher​

sng tenant policy detach readonly --user bob --with-assume
policy "readonly" unbound from user:bob (pending: applied in a few minutes)
policy "assume-role" unbound from user:bob (pending: applied in a few minutes)

Avec detach, --with-assume retire aussi assume-role. Détacher le dernier sujet supprime le binding.

Vérification​

sng tenant policy principals readonly
STATE      KIND  ID
applied    user  7f3e2c1a-…
requested  user  bob
  • applied : principaux réellement en vigueur, identifiants résolus (un utilisateur apparaît par son sub) ;
  • requested : sujets tels que vous les avez demandés, en attente ou déjà appliqués.

Tant qu'un sujet n'apparaît que dans requested, il n'est pas encore en vigueur (quelques minutes). sng tenant list, côté utilisateur, montre les tenants où il détient une policy.

L'équivalent déclaratif : IAMPolicyBinding​

Chaque attach écrit un binding nommé bind-<policy> dans l'état désiré de votre tenant :

bind-readonly.yml (écrit par l'API, lecture seule)
apiVersion: iam.stackngo.io/v1alpha1
kind: IAMPolicyBinding
metadata:
  name: bind-readonly
spec:
  policyRef:
    name: readonly
  subjects:
    users: [bob]
    roles: [stackngo/dev]
    applications: [sng-1a2b3c4d-5e6f7a8b-app-ci-deployer]
    oidcTrusts: [gitlab-deploy]

Vous n'écrivez pas ce fichier : sng tenant policy attach/detach le maintiennent, et sng tenant policy principals le lit. Voir IAMPolicyBinding.

Erreurs fréquentes​

MessageCauseCorrection
at least one --user, --role, … is requiredaucun sujetajouter un flag de sujet
--role "dev": expected org/NAMErôle sans organisation--role stackngo/dev
subjects must be explicit (no empty value, no global *)jokernommer chaque sujet, ou créer un rôle
not foundla policy n'existe pas dans le tenantsng tenant policy list
forbidden (no policy of this tenant allows it: see sng tenant policy list)pas de policy:admindemander la policy admin
policies: reserved …tenant réservé à la plateformeviser votre propre tenant

Pour aller plus loin​

  • Les attachements créés avec le tenant (le créateur sur assume-role et admin) appartiennent à la plateforme ; vos attach sur ces policies créent un second binding bind-<policy> à côté. Un principal n'est détaché d'une policy que si plus aucun binding ne le porte.
  • Un utilisateur renommé garde ses droits : le binding est résolu en sub. Un utilisateur supprimé n'a plus d'effet (InvalidReference) ; retirez-le du binding.
  • Supprimer un trust OIDC laisse ses bindings en place, sans effet : plus aucune identité ne peut les porter.

Voir aussi​