Policies

À quoi sert cet écran

Une policy est l’endroit où l’on choisit des permissions et, surtout, où on les limite. Une policy est composée de statements ; chaque statement liste des permissions et peut les restreindre à des clusters précis (ressources) et à des environnements (conditions).

C’est le seul endroit où le cantonnement existe. Une permission sélectionnée sans portée s’applique partout : tous les clusters, tous les environnements.

Avant de commencer

Enregistrez d’abord vos clusters et environnements, dans Infrastructure. Un statement ne peut pas être cantonné à quelque chose qui n’existe pas encore, et c’est la raison habituelle pour laquelle une policy du premier jour se retrouve sans portée.

Ouvrir l’écran

1. Settings › People & Access
2. Sélectionnez l’onglet Policies.

L’interface

📸 Capture d’écran : L’éditeur de policy avec un statement déplié. Repères : (1) l’arbre des permissions, (2) le sélecteur de clusters, (3) le sélecteur d’environnements, (4) la ligne de résumé du statement, (5) Save.

La ligne de résumé est votre vérification la plus rapide. Si elle ne mentionne ni cluster ni environnement, le statement n’a pas de portée.

Procédures

Créer une policy cantonnée

Nécessite platform-settings.permission-policy.create.

1. Settings › People & Access › Policies, cliquez sur Add Policy.
2. Nommez-la d’après ce qu’elle autorise, par ex. Dev Deploy, pas d’après qui la reçoit.
3. Dans le statement, sélectionnez les permissions dans l’arbre.
4. Sélectionnez les clusters concernés.
5. Sélectionnez les environnements — un ou plusieurs.
6. Lisez la ligne de résumé et confirmez qu’elle nomme bien les deux.
7. Save.

Élargir ou restreindre une policy existante

Nécessite platform-settings.permission-policy.update.

1. Ouvrez la policy, ajustez permissions ou portée, puis enregistrez.
2. Le changement atteint tous les rôles portant cette policy, et donc tous les utilisateurs détenant ces rôles. Vérifiez quels rôles l’utilisent avant de modifier.

Supprimer une policy

Nécessite platform-settings.permission-policy.delete.

Les rôles qui la référencent perdent ce qu’elle accordait. Vérifiez d’abord ces rôles : un rôle qui se retrouve sans policy n’accorde plus rien et ne signale pas qu’il accordait quelque chose auparavant.

Scénario

Permettre à l’équipe d’astreinte de redémarrer des workloads de production sans lui donner les déploiements en production.

La distinction est fine, et c’est précisément le genre de cas pour lequel les policies existent.

1. Créez une policy nommée Prod Oncall.
2. Dans le statement, ne sélectionnez que les permissions opérationnelles nécessaires à l’astreinte. Ne sélectionnez pas les permissions de déploiement.
3. Cantonnez les ressources au seul cluster de production.
4. Fixez la condition d’environnement à production uniquement.
5. Vérifiez que le résumé nomme un cluster et un environnement.
6. Enregistrez, puis rattachez la policy à un rôle On-Call — seule, et non aux côtés d’une policy de déploiement plus large, sinon c’est la plus large qui l’emporte.
7. Vérifiez dans Access Explorer qu’une permission de déploiement en production reste refusée pour un utilisateur d’astreinte.

L’étape 7 compte, car les permissions sont cumulatives : un utilisateur détenant deux rôles obtient l’union des deux. Restreindre une policy ne sert à rien si une autre accorde la même chose.

En cas de problème

Pour aller plus loin

• Comment fonctionnent les permissions — le modèle complet
• Rôles — rattachez cette policy à un rôle