À propos

Consultez les sections suivantes pour trouver du contenu pour vous aider à connaître et à utiliser ROSA avec HCP.

Dans le cadre de ROSA avec HCP, Red Hat doit obtenir les autorisations nécessaires pour gérer les ressources d’infrastructure dans votre compte AWS. Avec HCP, ROSA accorde aux logiciels d’automatisation du cluster un accès limité et à court terme aux ressources de votre compte AWS.

La méthode STS utilise des rôles et des politiques prédéfinis pour accorder des autorisations temporaires et moins privilégiées aux rôles IAM. Les informations d’identification expirent généralement une heure après avoir été demandées. Lorsqu’ils ont expiré, ils ne sont plus reconnus par AWS et n’ont plus accès au compte à partir des demandes d’API faites avec eux. Consultez la documentation AWS pour plus d’informations.

Les rôles AWS IAM STS doivent être créés pour chaque ROSA avec le cluster HCP. L’interface de ligne de commande ROSA (CLI) (rosa) gère les rôles STS et vous aide à joindre les stratégies spécifiques de ROSA gérées par AWS à chaque rôle. Le CLI fournit les commandes et les fichiers pour créer les rôles, joindre les stratégies gérées par AWS, et une option pour permettre au CLI de créer automatiquement les rôles et de joindre les stratégies.

Les fonctionnalités de sécurité pour AWS STS comprennent:

Le ROSA avec HCP accorde des composants logiciels de cluster moins privilégiés avec des informations d’identification de sécurité à court terme pour des rôles IAM spécifiques et séparés. Les informations d’identification sont associées à des rôles IAM spécifiques à chaque composant et cluster qui font des appels API AWS. Cette méthode s’harmonise avec les principes des pratiques moins privilégiées et sécurisées dans la gestion des ressources de service cloud.

Le déploiement d’un ROSA avec le cluster HCP suit les étapes suivantes:

Au cours du processus de création de cluster, le ROSA CLI crée les fichiers JSON requis pour vous et produit les commandes dont vous avez besoin. Au besoin, le ROSA CLI peut également exécuter les commandes pour vous.

Le ROSA CLI peut créer automatiquement les rôles pour vous, ou vous pouvez les créer manuellement en utilisant les drapeaux automatiques --mode ou --mode. En savoir plus sur le déploiement, voir Création d’un cluster avec des personnalisations.

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.

View larger image

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.

View larger image

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:

View larger image