3.5. Flux de travail ROSA avec HCP

L’utilisateur crée les rôles nécessaires à l’échelle du compte. Au cours de la création de rôles, une politique de confiance, connue sous le nom de politique de confiance intercompte, est créée, ce qui permet à un rôle appartenant à Red Hat d’assumer les rôles. Des politiques de confiance sont également créées pour le service EC2, ce qui permet aux charges de travail des instances EC2 d’assumer des rôles et d’obtenir des pouvoirs. AWS attribue une politique d’autorisations correspondante à chaque rôle.

Après la création des rôles et des politiques à l’échelle du compte, l’utilisateur peut créer un cluster. Lorsque la création de cluster est lancée, l’utilisateur crée les rôles d’opérateur afin que les opérateurs de cluster puissent faire des appels API AWS. Ces rôles sont ensuite attribués aux politiques d’autorisation correspondantes qui ont été créées plus tôt et à une politique de confiance avec un fournisseur OIDC. Les rôles d’opérateur diffèrent des rôles à l’échelle du compte en ce qu’ils représentent en fin de compte les pods qui ont besoin d’accéder aux ressources AWS. Comme un utilisateur ne peut pas joindre les rôles IAM aux pods, il doit créer une politique de confiance avec un fournisseur OIDC afin que l’opérateur, et donc les pods, puissent accéder aux rôles dont ils ont besoin.

Lorsque l’utilisateur attribue les rôles aux autorisations de stratégie correspondantes, l’étape finale est de créer le fournisseur OIDC.

Lorsqu’un nouveau rôle est nécessaire, la charge de travail actuellement utilisée dans le rôle Red Hat assumera le rôle dans le compte AWS, obtiendra des informations d’identification temporaires d’AWS STS et commencera à effectuer les actions à l’aide d’appels API dans le compte AWS de l’utilisateur, comme le permet la politique de permissions du rôle assumé. Les informations d’identification sont temporaires et ont une durée maximale d’une heure.

Les opérateurs utilisent le processus suivant pour obtenir les informations d’identification requises pour effectuer leurs tâches. Chaque opérateur se voit attribuer un rôle d’opérateur, une politique d’autorisations et une politique de confiance avec un fournisseur OIDC. L’opérateur assumera le rôle en passant un jeton Web JSON qui contient le rôle et un fichier jeton (web_identity_token_file) au fournisseur OIDC, qui authentifie ensuite la clé signée avec une clé publique. La clé publique est créée lors de la création de clusters et stockée dans un seau S3. L’opérateur confirme ensuite que le sujet dans le fichier de jeton signé correspond au rôle dans la politique de confiance des rôles, ce qui garantit que le fournisseur OIDC ne peut obtenir que le rôle autorisé. Le fournisseur OIDC retourne ensuite les informations d’identification temporaires à l’opérateur afin que l’opérateur puisse effectuer des appels API AWS. Dans le cas d’une représentation visuelle, voir le diagramme suivant: