17.2. Tutoriel : ROSA avec AWS STS expliqué

Dans le cadre de ROSA, Red Hat gère les ressources d’infrastructure de votre compte AWS et doit recevoir les autorisations nécessaires. Il existe actuellement deux méthodes prises en charge pour accorder ces autorisations:

De nombreux composants essentiels rendent ROSA avec STS plus sécurisé que ROSA avec IAM Users:

La ROSA utilise AWS STS pour accorder des autorisations les moins privilégiées 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. L’outil d’interface de ligne de commande ROSA (CLI) gère les rôles et les stratégies STS qui sont assignés pour des tâches uniques et agit sur les ressources AWS dans le cadre de la fonctionnalité OpenShift.

Les rôles et les politiques STS doivent être créés pour chaque cluster ROSA. Afin de faciliter cette tâche, les outils d’installation fournissent toutes les commandes et fichiers nécessaires pour créer les rôles en tant que stratégies et une option permettant à la CLI de créer automatiquement les rôles et les stratégies. Consultez Créer un cluster ROSA avec STS en utilisant des personnalisations pour plus d’informations sur les différentes options --mode.

Il n’est pas prévu de créer les ressources énumérées dans les étapes ci-dessous à partir de zéro. Le ROSA CLI crée les fichiers JSON requis pour vous et affiche les commandes dont vous avez besoin. Le ROSA CLI peut également aller plus loin et exécuter les commandes pour vous, si vous le souhaitez.

Les rôles et les stratégies peuvent être créés automatiquement par le ROSA CLI, ou ils peuvent être créés manuellement en utilisant les drapeaux automatiques --mode ou --mode dans le ROSA CLI. Cliquez ici pour plus de détails sur le déploiement, voir Créer un cluster avec des personnalisations ou le tutoriel Déploiement du cluster.

L’utilisateur crée les rôles requis à l’échelle du compte et les politiques à l’échelle du compte. Consultez la section des composants de ce tutoriel pour plus d’informations. 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. L’utilisateur peut alors attribuer une stratégie d’autorisation 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, les rôles d’opérateur sont créés 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 du client, 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

L’ensemble du flux de travail est représenté dans le graphique suivant:

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 ci-dessous:

View larger image

Le même processus s’applique également aux cas de soutien. Dans les cas de soutien, un ingénieur de fiabilité du site Red Hat (SRE) remplace le programme d’installation.