Chapitre 13. Jetons de cadrage


13.1. À propos des jetons de cadrage

Vous pouvez créer des jetons de portée pour déléguer certaines de vos autorisations à un autre utilisateur ou compte de service. Par exemple, un administrateur de projet peut vouloir déléguer le pouvoir de créer des pods.

Un jeton à portée limitée est un jeton qui s'identifie comme un utilisateur donné mais qui est limité à certaines actions par sa portée. Seul un utilisateur ayant le rôle cluster-admin peut créer des jetons à portée limitée.

Les champs d'application sont évalués en convertissant l'ensemble des champs d'application d'un jeton en un ensemble de PolicyRules. La demande est ensuite comparée à ces règles. Les attributs de la demande doivent correspondre à au moins une des règles de portée pour être transmis à l'autorisateur "normal" pour d'autres contrôles d'autorisation.

13.1.1. Portée de l'utilisateur

Les champs d'application utilisateur visent à obtenir des informations sur un utilisateur donné. Elles sont basées sur l'intention, de sorte que les règles sont automatiquement créées pour vous :

  • user:full - Permet un accès complet en lecture/écriture à l'API avec toutes les autorisations de l'utilisateur.
  • user:info - Permet d'accéder en lecture seule aux informations relatives à l'utilisateur, telles que son nom et ses groupes.
  • user:check-access - Permet l'accès à self-localsubjectaccessreviews et self-subjectaccessreviews. Il s'agit des variables pour lesquelles vous passez un utilisateur et des groupes vides dans votre objet de requête.
  • user:list-projects - Permet un accès en lecture seule à la liste des projets auxquels l'utilisateur a accès.

13.1.2. Champ d'application du rôle

L'étendue du rôle vous permet d'avoir le même niveau d'accès qu'un rôle donné filtré par l'espace de noms.

  • role:<cluster-role name>:<namespace or * for all> - Limits the scope to the rules specified by the cluster-role, but only in the specified namespace .

    Note

    Mise en garde : cela empêche l'escalade de l'accès. Même si le rôle autorise l'accès à des ressources telles que les secrets, les attributions de rôles et les rôles, cette portée interdira l'accès à ces ressources. Cela permet d'éviter les escalades inattendues. Beaucoup de gens ne pensent pas qu'un rôle comme edit est un rôle d'escalade, mais avec l'accès à un secret, c'est le cas.

  • role:<cluster-role name>:<namespace or * for all>:! - This is similar to the example above, except that including the bang causes this scope to allow escalating access.
Retour au début
Red Hat logoGithubredditYoutubeTwitter

Apprendre

Essayez, achetez et vendez

Communautés

À propos de la documentation Red Hat

Nous aidons les utilisateurs de Red Hat à innover et à atteindre leurs objectifs grâce à nos produits et services avec un contenu auquel ils peuvent faire confiance. Découvrez nos récentes mises à jour.

Rendre l’open source plus inclusif

Red Hat s'engage à remplacer le langage problématique dans notre code, notre documentation et nos propriétés Web. Pour plus de détails, consultez le Blog Red Hat.

À propos de Red Hat

Nous proposons des solutions renforcées qui facilitent le travail des entreprises sur plusieurs plates-formes et environnements, du centre de données central à la périphérie du réseau.

Theme

© 2025 Red Hat