Installer des clusters ROSA Classic
Installation, accès et suppression du service OpenShift Red Hat sur les clusters AWS (ROSA).
Résumé
Chapitre 1. Création d’un cluster ROSA avec STS en utilisant les options par défaut Copier lienLien copié sur presse-papiers!
Consultez le guide de démarrage rapide de Red Hat OpenShift Service sur AWS.
Créez rapidement un cluster Red Hat OpenShift Service sur AWS (ROSA) en utilisant les options par défaut et la création automatique de ressources AWS Identity and Access Management (IAM). Déployez votre cluster en utilisant Red Hat OpenShift Cluster Manager ou ROSA CLI (rosa).
Les procédures de ce document utilisent les modes automatiques de ROSA CLI (rosa) et OpenShift Cluster Manager pour créer immédiatement les ressources IAM requises à l’aide du compte AWS actuel. Les ressources requises comprennent les rôles et les politiques IAM à l’échelle du compte, les rôles et politiques d’opérateur spécifiques à chaque groupe, et le fournisseur d’identité OpenID Connect (OIDC).
Alternativement, vous pouvez utiliser le mode manuel, qui affiche les commandes aws nécessaires pour créer les ressources IAM au lieu de les déployer automatiquement. En ce qui concerne les étapes de déploiement d’un cluster ROSA en mode manuel ou avec des personnalisations, voir Créer un cluster à l’aide de personnalisations.
Les prochaines étapes
- Assurez-vous que vous avez rempli les prérequis AWS.
La ROSA CLI 1.2.7 introduit des modifications au format d’URL du fournisseur OIDC pour les nouveaux clusters. Les URL des fournisseurs OIDC de cluster AWS ne sont plus régionales. L’implémentation AWS CloudFront permet d’améliorer la vitesse d’accès et la résilience et réduit la latence.
Étant donné que cette modification n’est disponible que pour les nouveaux clusters créés en utilisant ROSA CLI 1.2.7 ou version ultérieure, les configurations existantes de fournisseur OIDC n’ont pas de chemins de migration pris en charge.
1.1. Aperçu des spécifications du cluster par défaut Copier lienLien copié sur presse-papiers!
Grâce aux options d’installation par défaut, vous pouvez créer rapidement un Red Hat OpenShift Service sur AWS (ROSA) avec le Security Token Service (STS). Le résumé suivant décrit les spécifications du cluster par défaut.
| Composante | Caractéristiques par défaut |
|---|---|
| Comptes et rôles |
|
| Configurations du cluster |
|
| Chiffrement |
|
| Configuration des nœuds de plan de contrôle |
|
| Configuration des nœuds d’infrastructure |
|
| Calculez la piscine de la machine de nœud |
|
| Configuration du réseau |
|
| Gammes de routage interdomain sans classe (CIDR) |
|
| Les rôles et les politiques des clusters |
|
| La stratégie de mise à jour des clusters |
|
1.2. Comprendre l’association de compte AWS Copier lienLien copié sur presse-papiers!
Avant de pouvoir utiliser Red Hat OpenShift Cluster Manager sur la console de cloud hybride Red Hat pour créer des clusters Red Hat OpenShift sur AWS (ROSA) qui utilisent le Service de jetons de sécurité AWS (STS), vous devez associer votre compte AWS à votre organisation Red Hat. Il est possible d’associer votre compte en créant et en liant les rôles IAM suivants.
- Le rôle de gestionnaire de cluster OpenShift
Créez un rôle OpenShift Cluster Manager IAM et liez-le à votre organisation Red Hat.
Il est possible d’appliquer des autorisations de base ou administratives au rôle OpenShift Cluster Manager. Les autorisations de base permettent la maintenance des clusters à l’aide d’OpenShift Cluster Manager. Les autorisations administratives permettent le déploiement automatique des rôles d’opérateur spécifiques au cluster et du fournisseur OpenID Connect (OIDC) à l’aide d’OpenShift Cluster Manager.
Il est possible d’utiliser les autorisations administratives avec le rôle OpenShift Cluster Manager pour déployer rapidement un cluster.
- Le rôle de l’utilisateur
Créez un rôle IAM utilisateur et liez-le à votre compte d’utilisateur Red Hat. Le compte d’utilisateur Red Hat doit exister dans l’organisation Red Hat qui est liée à votre rôle OpenShift Cluster Manager.
Le rôle d’utilisateur est utilisé par Red Hat pour vérifier votre identité AWS lorsque vous utilisez la console cloud hybride OpenShift Cluster Manager pour installer un cluster et les ressources STS requises.
1.3. Amazon VPC Exigences pour les clusters ROSA non-PrivateLink Copier lienLien copié sur presse-papiers!
Afin de créer un VPC Amazon, vous devez avoir ce qui suit:
- D’une passerelle Internet,
- La passerelle NAT,
- Les sous-réseaux privés et publics qui ont une connectivité Internet fournie pour installer les composants requis.
Il vous faut au moins un sous-réseau privé et public pour les clusters Single-AZ, et vous avez besoin d’au moins trois sous-réseaux privés et publics pour les clusters Multi-AZ.
1.4. Créer un cluster rapidement à l’aide d’OpenShift Cluster Manager Copier lienLien copié sur presse-papiers!
Lorsque vous utilisez Red Hat OpenShift Cluster Manager pour créer un cluster Red Hat OpenShift Service sur AWS (ROSA) qui utilise le service de jetons de sécurité AWS (STS), vous pouvez sélectionner les options par défaut pour créer le cluster rapidement.
Avant de pouvoir utiliser OpenShift Cluster Manager pour déployer ROSA avec des clusters STS, vous devez associer votre compte AWS à votre organisation Red Hat et créer les rôles et politiques STS nécessaires à l’échelle du compte.
1.4.1. Associer votre compte AWS à votre organisation Red Hat Copier lienLien copié sur presse-papiers!
Avant d’utiliser Red Hat OpenShift Cluster Manager sur la console de cloud hybride Red Hat pour créer des clusters Red Hat OpenShift sur AWS (ROSA) qui utilisent le service de jetons de sécurité AWS (STS), créer un rôle OpenShift Cluster Manager IAM et le lier à votre organisation Red Hat. Ensuite, créez un rôle IAM utilisateur et liez-le à votre compte d’utilisateur Red Hat dans la même organisation Red Hat.
Conditions préalables
- Avec STS, vous avez complété les prérequis AWS pour ROSA.
- Des quotas de service AWS sont disponibles.
- Le service ROSA est activé dans la console AWS.
L’installation et la configuration de la dernière ROSA CLI (rosa) sur votre hôte d’installation.
NoteAfin d’installer avec succès les clusters ROSA, utilisez la dernière version de la ROSA CLI.
- En utilisant le ROSA CLI, vous vous êtes connecté à votre compte Red Hat.
- Il y a des privilèges d’administrateur d’organisation dans votre organisation Red Hat.
Procédure
Créez un rôle OpenShift Cluster Manager et liez-le à votre organisation Red Hat:
NoteAfin d’activer le déploiement automatique des rôles d’opérateur spécifiques au cluster et du fournisseur OpenID Connect (OIDC) à l’aide de la console de cloud hybride OpenShift Cluster Manager, vous devez appliquer les privilèges administratifs au rôle en choisissant la commande de rôle OCM Admin dans l’étape Comptes et rôles de la création d’un cluster ROSA. En savoir plus sur les privilèges de base et administratifs pour le rôle de gestionnaire de cluster OpenShift, voir Comprendre l’association de compte AWS.
NoteLorsque vous choisissez la commande de rôle OCM de base dans l’étape Comptes et rôles de la création d’un cluster ROSA dans la console de cloud hybride OpenShift Cluster Manager, vous devez déployer un cluster ROSA en mode manuel. Dans une étape ultérieure, vous serez invité à configurer les rôles d’opérateur spécifiques au cluster et le fournisseur OpenID Connect (OIDC).
rosa create ocm-role
$ rosa create ocm-roleCopy to Clipboard Copied! Toggle word wrap Toggle overflow Choisissez les valeurs par défaut dans les instructions pour créer rapidement et lier le rôle.
Créez un rôle d’utilisateur et liez-le à votre compte d’utilisateur Red Hat:
rosa create user-role
$ rosa create user-roleCopy to Clipboard Copied! Toggle word wrap Toggle overflow Choisissez les valeurs par défaut dans les instructions pour créer rapidement et lier le rôle.
NoteLe compte d’utilisateur Red Hat doit exister dans l’organisation Red Hat qui est liée à votre rôle OpenShift Cluster Manager.
1.4.2. Créer les rôles et politiques STS à l’échelle du compte Copier lienLien copié sur presse-papiers!
Avant d’utiliser le Red Hat OpenShift Cluster Manager Hybrid Cloud Console pour créer Red Hat OpenShift Service sur AWS (ROSA) clusters qui utilisent AWS Security Token Service (STS), créer les rôles et politiques STS nécessaires à l’échelle du compte, y compris les politiques d’opérateur.
Conditions préalables
- Avec STS, vous avez complété les prérequis AWS pour ROSA.
- Des quotas de service AWS sont disponibles.
- Le service ROSA est activé dans la console AWS.
- L’installation et la configuration de la dernière ROSA CLI (rosa) sur votre hôte d’installation. Exécutez la version rosa pour voir votre version actuellement installée de la ROSA CLI. Lorsqu’une version plus récente est disponible, le CLI fournit un lien pour télécharger cette mise à jour.
- En utilisant le ROSA CLI, vous vous êtes connecté à votre compte Red Hat.
Procédure
Consultez votre compte AWS pour connaître les rôles et les politiques existants:
rosa list account-roles
$ rosa list account-rolesCopy to Clipboard Copied! Toggle word wrap Toggle overflow Dans le cas où ils n’existent pas dans votre compte AWS, créez les rôles et politiques STS requis à l’échelle du compte:
rosa create account-roles
$ rosa create account-rolesCopy to Clipboard Copied! Toggle word wrap Toggle overflow Choisissez les valeurs par défaut dans les instructions pour créer rapidement les rôles et les stratégies.
1.4.3. Création d’une configuration OpenID Connect Copier lienLien copié sur presse-papiers!
Lorsque vous utilisez un Red Hat OpenShift Service sur AWS cluster, vous pouvez créer la configuration OpenID Connect (OIDC) avant de créer votre cluster. Cette configuration est enregistrée pour être utilisée avec OpenShift Cluster Manager.
Conditions préalables
- Les prérequis AWS pour le service OpenShift Red Hat sont complétés sur AWS.
- Dans votre installation, vous avez installé et configuré le dernier service Red Hat OpenShift sur AWS (ROSA) CLI, rosa.
Procédure
Afin de créer votre configuration OIDC à côté des ressources AWS, exécutez la commande suivante:
rosa create oidc-config --mode=auto --yes
$ rosa create oidc-config --mode=auto --yesCopy to Clipboard Copied! Toggle word wrap Toggle overflow Cette commande renvoie les informations suivantes.
Exemple de sortie
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Lors de la création de votre cluster, vous devez fournir l’identifiant de configuration OIDC. La sortie CLI fournit cette valeur pour --mode auto, sinon vous devez déterminer ces valeurs en fonction de la sortie CLI aws pour --mode manuel.
Facultatif : vous pouvez enregistrer l’identifiant de configuration OIDC en tant que variable à utiliser ultérieurement. Exécutez la commande suivante pour enregistrer la variable:
export OIDC_ID=<oidc_config_id>
$ export OIDC_ID=<oidc_config_id>1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Dans l’exemple de sortie ci-dessus, l’IDC de configuration ID est 13cdr6b.
Afficher la valeur de la variable en exécutant la commande suivante:
echo $OIDC_ID
$ echo $OIDC_IDCopy to Clipboard Copied! Toggle word wrap Toggle overflow Exemple de sortie
13cdr6b
13cdr6bCopy to Clipboard Copied! Toggle word wrap Toggle overflow
La vérification
Il est possible de répertorier les configurations OIDC possibles pour vos clusters associés à votre organisation utilisateur. Exécutez la commande suivante:
rosa list oidc-config
$ rosa list oidc-configCopy to Clipboard Copied! Toggle word wrap Toggle overflow Exemple de sortie
ID MANAGED ISSUER URL SECRET ARN 2330dbs0n8m3chkkr25gkkcd8pnj3lk2 true https://dvbwgdztaeq9o.cloudfront.net/2330dbs0n8m3chkkr25gkkcd8pnj3lk2 233hvnrjoqu14jltk6lhbhf2tj11f8un false https://oidc-r7u1.s3.us-east-1.amazonaws.com aws:secretsmanager:us-east-1:242819244:secret:rosa-private-key-oidc-r7u1-tM3MDN
ID MANAGED ISSUER URL SECRET ARN 2330dbs0n8m3chkkr25gkkcd8pnj3lk2 true https://dvbwgdztaeq9o.cloudfront.net/2330dbs0n8m3chkkr25gkkcd8pnj3lk2 233hvnrjoqu14jltk6lhbhf2tj11f8un false https://oidc-r7u1.s3.us-east-1.amazonaws.com aws:secretsmanager:us-east-1:242819244:secret:rosa-private-key-oidc-r7u1-tM3MDNCopy to Clipboard Copied! Toggle word wrap Toggle overflow
1.4.4. Créer un cluster avec les options par défaut à l’aide d’OpenShift Cluster Manager Copier lienLien copié sur presse-papiers!
Lorsque vous utilisez Red Hat OpenShift Cluster Manager sur la console de cloud hybride Red Hat pour créer un cluster Red Hat OpenShift Service sur AWS (ROSA) qui utilise le service de jetons de sécurité AWS (STS), vous pouvez sélectionner les options par défaut pour créer le cluster rapidement. Il est également possible d’utiliser le rôle d’administrateur OpenShift Cluster Manager IAM pour permettre le déploiement automatique des rôles d’opérateur spécifiques au cluster et du fournisseur OpenID Connect (OIDC).
Conditions préalables
- Avec STS, vous avez complété les prérequis AWS pour ROSA.
- Des quotas de service AWS sont disponibles.
- Le service ROSA est activé dans la console AWS.
- L’installation et la configuration de la dernière ROSA CLI (rosa) sur votre hôte d’installation. Exécutez la version rosa pour voir votre version actuellement installée de la ROSA CLI. Lorsqu’une version plus récente est disponible, le CLI fournit un lien pour télécharger cette mise à jour.
- Le rôle de service AWS Elastic Load Balancing (ELB) existe dans votre compte AWS.
- De plus, vous avez associé votre compte AWS à votre organisation Red Hat. Lorsque vous avez associé votre compte, vous avez appliqué les autorisations administratives au rôle OpenShift Cluster Manager. Consultez l’association de votre compte AWS avec votre organisation Red Hat.
- Les rôles et les politiques STS à l’échelle du compte ont été créés. En ce qui concerne les étapes détaillées, voir Créer les rôles et les politiques STS à l’échelle du compte.
Procédure
- Accédez à OpenShift Cluster Manager et sélectionnez Créer un cluster.
- Dans la page Créer un cluster OpenShift, sélectionnez Créer un cluster dans la ligne Red Hat OpenShift sur AWS (ROSA).
Assurez-vous que votre identifiant de compte AWS est listé dans le menu déroulant des comptes AWS associés et que l’installateur, le support, le travail et le rôle de compte de plan de contrôle Amazon Resource Names (ARN) sont listés sur la page Comptes et rôles.
NoteDans le cas où votre identifiant de compte AWS n’est pas listé, vérifiez que vous avez associé avec succès votre compte AWS à votre organisation Red Hat. Dans le cas où les ARN de votre rôle de compte ne sont pas listés, vérifiez que les rôles STS requis à l’échelle du compte existent dans votre compte AWS.
- Cliquez sur Next.
Dans la page Détails du cluster, fournissez un nom pour votre cluster dans le champ Nom du cluster. Laissez les valeurs par défaut dans les champs restants et cliquez sur Suivant.
NoteCréation de cluster génère un préfixe de domaine en tant que sous-domaine pour votre cluster provisionné sur openshiftapps.com. Lorsque le nom du cluster est inférieur ou égal à 15 caractères, ce nom est utilisé pour le préfixe de domaine. Lorsque le nom du cluster est supérieur à 15 caractères, le préfixe de domaine est généré au hasard en tant que chaîne de 15 caractères. Afin de personnaliser le sous-domaine, sélectionnez la case à cocher Créer un préfixe de domaine personnalisé et entrez le nom de préfixe de domaine dans le champ Préfixe de domaine.
- Afin de déployer rapidement un cluster, laissez les options par défaut dans les paramètres Cluster, Networking, Cluster rôles et stratégies, et Cluster met à jour les pages et cliquez sur Suivant sur chaque page.
- Dans la page Révisez votre cluster ROSA, consultez le résumé de vos sélections et cliquez sur Créer un cluster pour démarrer l’installation.
Facultatif: Dans l’onglet Aperçu, vous pouvez activer la fonction de protection de suppression en sélectionnant Activer, qui est situé directement sous Supprimer Protection: Désactiver. Cela empêchera votre cluster d’être supprimé. Afin de désactiver la protection, sélectionnez Désactiver. Les clusters sont créés par défaut avec la fonction de protection de suppression désactivée.
La vérification
Consultez l’état d’avancement de l’installation dans la page Aperçu de votre cluster. Les journaux d’installation sont affichés sur la même page. Le cluster est prêt lorsque l’état dans la section Détails de la page est listé comme prêt.
NoteEn cas d’échec de l’installation ou que l’état du cluster ne change pas pour Ready après environ 40 minutes, vérifiez la documentation de dépannage de l’installation pour plus de détails. De plus amples informations sont disponibles sur les installations de dépannage. Les étapes à suivre pour contacter Red Hat Support pour obtenir de l’aide sont disponibles sur AWS.
1.5. Créer un cluster rapidement à l’aide du CLI Copier lienLien copié sur presse-papiers!
Lorsque vous utilisez le Red Hat OpenShift Service sur AWS (ROSA) CLI, rosa, pour créer un cluster qui utilise AWS Security Token Service (STS), vous pouvez sélectionner les options par défaut pour créer le cluster rapidement.
Conditions préalables
- Avec STS, vous avez complété les prérequis AWS pour ROSA.
- Des quotas de service AWS sont disponibles.
- Le service ROSA est activé dans la console AWS.
- L’installation et la configuration de la dernière ROSA CLI (rosa) sur votre hôte d’installation. Exécutez la version rosa pour voir votre version actuellement installée de la ROSA CLI. Lorsqu’une version plus récente est disponible, le CLI fournit un lien pour télécharger cette mise à jour.
- En utilisant le ROSA CLI, vous vous êtes connecté à votre compte Red Hat.
- Le rôle de service AWS Elastic Load Balancing (ELB) existe dans votre compte AWS.
Procédure
Créer les rôles et politiques nécessaires à l’échelle du compte, y compris les politiques de l’opérateur:
rosa create account-roles --mode auto
$ rosa create account-roles --mode autoCopy to Clipboard Copied! Toggle word wrap Toggle overflow NoteLorsque vous utilisez le mode automatique, vous pouvez éventuellement spécifier l’argument -y pour contourner les instructions interactives et confirmer automatiquement les opérations.
Créez un cluster avec STS en utilisant les valeurs par défaut. Lorsque vous utilisez les valeurs par défaut, la dernière version stable d’OpenShift est installée:
rosa create cluster --cluster-name <cluster_name> \ --sts --mode auto
$ rosa create cluster --cluster-name <cluster_name> \1 --sts --mode auto2 Copy to Clipboard Copied! Toggle word wrap Toggle overflow NoteLorsque le nom de votre cluster est supérieur à 15 caractères, il contiendra un préfixe de domaine généré automatiquement en tant que sous-domaine pour votre cluster fourni sur *.openshiftapps.com.
Afin de personnaliser le sous-domaine, utilisez l’indicateur --domain-prefix. Le préfixe de domaine ne peut pas dépasser 15 caractères, doit être unique et ne peut pas être modifié après la création de clusters.
Consultez l’état de votre cluster:
rosa describe cluster --cluster <cluster_name|cluster_id>
$ rosa describe cluster --cluster <cluster_name|cluster_id>Copy to Clipboard Copied! Toggle word wrap Toggle overflow Les changements de champ de l’État ci-après sont énumérés dans la sortie au fur et à mesure que l’installation du cluster progresse:
-
attente (Attendre la configuration OIDC) -
en attente (Préparer le compte) -
installation (configurationDNS en cours) -
installation ♪ prêt ♪NoteEn cas d’échec de l’installation ou que le champ État ne change pas pour être prêt après environ 40 minutes, vérifiez la documentation de dépannage de l’installation pour plus de détails. De plus amples informations sont disponibles sur les installations de dépannage. Les étapes à suivre pour contacter Red Hat Support pour obtenir de l’aide sont disponibles sur AWS.
-
Faites le suivi de la progression de la création de cluster en regardant les journaux d’installateur OpenShift:
rosa logs install --cluster <cluster_name|cluster_id> --watch
$ rosa logs install --cluster <cluster_name|cluster_id> --watch1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Indiquez le drapeau --watch pour regarder les nouveaux messages de journal au fur et à mesure que l’installation progresse. Cet argument est facultatif.
1.6. Les prochaines étapes Copier lienLien copié sur presse-papiers!
Chapitre 2. Création d’un cluster ROSA avec STS à l’aide de personnalisations Copier lienLien copié sur presse-papiers!
Créez un Red Hat OpenShift Service sur AWS (ROSA) cluster avec AWS Security Token Service (STS) à l’aide de personnalisations. Déployez votre cluster en utilisant Red Hat OpenShift Cluster Manager ou ROSA CLI (rosa).
Avec les procédures de ce document, vous pouvez également choisir entre les modes automatique et manuel lors de la création des ressources AWS Identity and Access Management (IAM) requises.
2.1. Comprendre les modes de déploiement automatique et manuel Copier lienLien copié sur presse-papiers!
Lors de l’installation d’un Red Hat OpenShift Service sur AWS (ROSA) cluster qui utilise AWS Security Token Service (STS), vous pouvez choisir entre les modes automatique et manuel pour créer les ressources AWS Identity and Access Management (IAM) requises.
- le mode automatique
- Avec ce mode, le ROSA CLI (rosa) crée immédiatement les rôles et politiques IAM requis, et un fournisseur OpenID Connect (OIDC) dans votre compte AWS.
- le mode manuel
- Avec ce mode, rosa sort les commandes aws nécessaires pour créer les ressources IAM. Les fichiers JSON de stratégie correspondant sont également enregistrés dans le répertoire actuel. En utilisant le mode manuel, vous pouvez consulter les commandes aws générées avant de les exécuter manuellement. le mode manuel vous permet également de transmettre les commandes à un autre administrateur ou groupe de votre organisation afin qu’ils puissent créer les ressources.
Lorsque vous choisissez d’utiliser le mode manuel, l’installation du cluster attend jusqu’à ce que vous créiez manuellement les rôles d’opérateur spécifiques au cluster et le fournisseur OIDC. Après avoir créé les ressources, l’installation procède. Consultez Créer les rôles d’opérateur et le fournisseur OIDC à l’aide d’OpenShift Cluster Manager.
En savoir plus sur les ressources AWS IAM nécessaires à l’installation de ROSA avec STS, voir À propos des ressources IAM pour les clusters utilisant STS.
2.1.1. Créer les rôles d’opérateur et le fournisseur OIDC à l’aide d’OpenShift Cluster Manager Copier lienLien copié sur presse-papiers!
Lorsque vous utilisez Red Hat OpenShift Cluster Manager pour installer votre cluster et choisir de créer les rôles AWS IAM Operator requis et le fournisseur OIDC en mode manuel, vous êtes invité à sélectionner l’une des méthodes suivantes pour installer les ressources. Les options sont fournies pour vous permettre de choisir une méthode de création de ressources qui répond aux besoins de votre organisation:
- AWS CLI (aws)
- Avec cette méthode, vous pouvez télécharger et extraire un fichier d’archive qui contient les commandes aws et les fichiers de stratégie nécessaires pour créer les ressources IAM. Exécutez les commandes CLI fournies à partir du répertoire qui contient les fichiers de stratégie pour créer les rôles d’opérateur et le fournisseur OIDC.
- Le Red Hat OpenShift Service sur AWS (ROSA) CLI, rosa
- Il est possible d’exécuter les commandes fournies par cette méthode pour créer les rôles Opérateur et le fournisseur OIDC pour votre cluster à l’aide de rosa.
En utilisant le mode automatique, OpenShift Cluster Manager crée automatiquement les rôles de l’opérateur et le fournisseur OIDC, en utilisant les autorisations fournies via le rôle IAM OpenShift Cluster Manager. Afin d’utiliser cette fonctionnalité, vous devez appliquer les privilèges d’administration au rôle.
2.2. Comprendre l’association de compte AWS Copier lienLien copié sur presse-papiers!
Avant de pouvoir utiliser Red Hat OpenShift Cluster Manager sur la console de cloud hybride Red Hat pour créer des clusters Red Hat OpenShift sur AWS (ROSA) qui utilisent le Service de jetons de sécurité AWS (STS), vous devez associer votre compte AWS à votre organisation Red Hat. Il est possible d’associer votre compte en créant et en liant les rôles IAM suivants.
- Le rôle de gestionnaire de cluster OpenShift
Créez un rôle OpenShift Cluster Manager IAM et liez-le à votre organisation Red Hat.
Il est possible d’appliquer des autorisations de base ou administratives au rôle OpenShift Cluster Manager. Les autorisations de base permettent la maintenance des clusters à l’aide d’OpenShift Cluster Manager. Les autorisations administratives permettent le déploiement automatique des rôles d’opérateur spécifiques au cluster et du fournisseur OpenID Connect (OIDC) à l’aide d’OpenShift Cluster Manager.
Il est possible d’utiliser les autorisations administratives avec le rôle OpenShift Cluster Manager pour déployer rapidement un cluster.
- Le rôle de l’utilisateur
Créez un rôle IAM utilisateur et liez-le à votre compte d’utilisateur Red Hat. Le compte d’utilisateur Red Hat doit exister dans l’organisation Red Hat qui est liée à votre rôle OpenShift Cluster Manager.
Le rôle d’utilisateur est utilisé par Red Hat pour vérifier votre identité AWS lorsque vous utilisez la console cloud hybride OpenShift Cluster Manager pour installer un cluster et les ressources STS requises.
2.3. ARN personnalisation du chemin pour les rôles et les politiques IAM Copier lienLien copié sur presse-papiers!
Lorsque vous créez les rôles et les politiques AWS IAM requis pour Red Hat OpenShift Service sur les clusters AWS (ROSA) qui utilisent le Service de jetons de sécurité AWS (STS), vous pouvez spécifier des chemins Amazon Resource Name (ARN) personnalisés. Cela vous permet d’utiliser des chemins ARN de rôle et de stratégie qui répondent aux exigences de sécurité de votre organisation.
Les chemins ARN personnalisés peuvent être spécifiés lorsque vous créez votre rôle OCM, votre rôle utilisateur et vos rôles et stratégies à l’échelle du compte.
Lorsque vous définissez un chemin ARN personnalisé lorsque vous créez un ensemble de rôles et de stratégies à l’échelle du compte, le même chemin est appliqué à tous les rôles et stratégies de l’ensemble. L’exemple suivant montre les ARN pour un ensemble de rôles et de politiques à l’échelle du compte. Dans l’exemple, les ARN utilisent le chemin personnalisé /test/path/dev/ et le préfixe de rôle personnalisé test-env:
-
ARN:aws:iam:<account_id>:role/test/path/dev/test-env-Worker-Role -
ARN:aws:iam:<account_id>:role/test/path/dev/test-env-Support-Role -
ARN:aws:iam:<account_id>:role/test/path/dev/test-env-Installer-Role -
ARN:aws:iam:<account_id>:role/test/path/dev/test-env-ControlPlane-Role -
ARN:aws:iam:<account_id>:policy/test/path/dev/test-env-Worker-Role-Policy -
ARN:aws:iam:<account_id>:policy/test/path/dev/test-env-Support-Role-Policy -
ARN:aws:iam:<account_id>:policy/test/path/dev/test-env-Installer-Role-Policy -
ARN:aws:iam:<account_id>:policy/test/path/dev/test-env-ControlPlane-Role-Policy
Lorsque vous créez les rôles d’opérateur spécifiques au cluster, le chemin ARN pour le rôle d’installation pertinent à l’échelle du compte est automatiquement détecté et appliqué aux rôles d’opérateur.
Consultez Amazon Resource Names (ARN) dans la documentation AWS pour plus d’informations sur les chemins ARN.
2.4. Considérations d’appui pour les clusters ROSA avec STS Copier lienLien copié sur presse-papiers!
La façon prise en charge de créer un Red Hat OpenShift Service sur AWS (ROSA) cluster qui utilise AWS Security Token Service (STS) est en utilisant les étapes décrites dans cette documentation produit.
Avec ROSA CLI (rosa), vous pouvez utiliser le mode manuel pour générer les fichiers de stratégie AWS Identity and Access Management (IAM) et les commandes aws nécessaires à l’installation des ressources STS.
Les fichiers et les commandes aws sont générés uniquement à des fins de révision et ne doivent en aucun cas être modifiés. Le Red Hat ne peut pas fournir de support pour les clusters ROSA qui ont été déployés en utilisant des versions modifiées des fichiers de stratégie ou des commandes aws.
2.5. Amazon VPC Exigences pour les clusters ROSA non-PrivateLink Copier lienLien copié sur presse-papiers!
Afin de créer un VPC Amazon, vous devez avoir ce qui suit:
- D’une passerelle Internet,
- La passerelle NAT,
- Les sous-réseaux privés et publics qui ont une connectivité Internet fournie pour installer les composants requis.
Il vous faut au moins un sous-réseau privé et public pour les clusters Single-AZ, et vous avez besoin d’au moins trois sous-réseaux privés et publics pour les clusters Multi-AZ.
2.6. Création d’une configuration OpenID Connect Copier lienLien copié sur presse-papiers!
Lorsque vous utilisez un Red Hat OpenShift Service sur AWS cluster, vous pouvez créer la configuration OpenID Connect (OIDC) avant de créer votre cluster. Cette configuration est enregistrée pour être utilisée avec OpenShift Cluster Manager.
Conditions préalables
- Les prérequis AWS pour le service OpenShift Red Hat sont complétés sur AWS.
- Dans votre installation, vous avez installé et configuré le dernier service Red Hat OpenShift sur AWS (ROSA) CLI, rosa.
Procédure
Afin de créer votre configuration OIDC à côté des ressources AWS, exécutez la commande suivante:
rosa create oidc-config --mode=auto --yes
$ rosa create oidc-config --mode=auto --yesCopy to Clipboard Copied! Toggle word wrap Toggle overflow Cette commande renvoie les informations suivantes.
Exemple de sortie
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Lors de la création de votre cluster, vous devez fournir l’identifiant de configuration OIDC. La sortie CLI fournit cette valeur pour --mode auto, sinon vous devez déterminer ces valeurs en fonction de la sortie CLI aws pour --mode manuel.
Facultatif : vous pouvez enregistrer l’identifiant de configuration OIDC en tant que variable à utiliser ultérieurement. Exécutez la commande suivante pour enregistrer la variable:
export OIDC_ID=<oidc_config_id>
$ export OIDC_ID=<oidc_config_id>1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Dans l’exemple de sortie ci-dessus, l’IDC de configuration ID est 13cdr6b.
Afficher la valeur de la variable en exécutant la commande suivante:
echo $OIDC_ID
$ echo $OIDC_IDCopy to Clipboard Copied! Toggle word wrap Toggle overflow Exemple de sortie
13cdr6b
13cdr6bCopy to Clipboard Copied! Toggle word wrap Toggle overflow
La vérification
Il est possible de répertorier les configurations OIDC possibles pour vos clusters associés à votre organisation utilisateur. Exécutez la commande suivante:
rosa list oidc-config
$ rosa list oidc-configCopy to Clipboard Copied! Toggle word wrap Toggle overflow Exemple de sortie
ID MANAGED ISSUER URL SECRET ARN 2330dbs0n8m3chkkr25gkkcd8pnj3lk2 true https://dvbwgdztaeq9o.cloudfront.net/2330dbs0n8m3chkkr25gkkcd8pnj3lk2 233hvnrjoqu14jltk6lhbhf2tj11f8un false https://oidc-r7u1.s3.us-east-1.amazonaws.com aws:secretsmanager:us-east-1:242819244:secret:rosa-private-key-oidc-r7u1-tM3MDN
ID MANAGED ISSUER URL SECRET ARN 2330dbs0n8m3chkkr25gkkcd8pnj3lk2 true https://dvbwgdztaeq9o.cloudfront.net/2330dbs0n8m3chkkr25gkkcd8pnj3lk2 233hvnrjoqu14jltk6lhbhf2tj11f8un false https://oidc-r7u1.s3.us-east-1.amazonaws.com aws:secretsmanager:us-east-1:242819244:secret:rosa-private-key-oidc-r7u1-tM3MDNCopy to Clipboard Copied! Toggle word wrap Toggle overflow
2.7. Créer un cluster à l’aide de personnalisations Copier lienLien copié sur presse-papiers!
Déployez un service Red Hat OpenShift sur AWS (ROSA) avec le cluster AWS Security Token Service (STS) avec une configuration adaptée aux besoins de votre environnement. Déployez votre cluster avec des personnalisations en utilisant Red Hat OpenShift Cluster Manager ou ROSA CLI (rosa).
2.7.1. Créer un cluster avec des personnalisations à l’aide d’OpenShift Cluster Manager Copier lienLien copié sur presse-papiers!
Lorsque vous créez un cluster Red Hat OpenShift Service sur AWS (ROSA) qui utilise AWS Security Token Service (STS), vous pouvez personnaliser votre installation de manière interactive en utilisant Red Hat OpenShift Cluster Manager.
Les clusters PrivateLink publics et AWS ne sont pris en charge que par STS. Les clusters privés réguliers (non-PrivateLink) ne sont pas disponibles pour une utilisation avec STS.
Conditions préalables
- Avec STS, vous avez complété les prérequis AWS pour ROSA.
- Des quotas de service AWS sont disponibles.
- Le service ROSA est activé dans la console AWS.
- L’installation et la configuration de la dernière ROSA CLI (rosa) sur votre hôte d’installation. Exécutez la version rosa pour voir votre version actuellement installée de la ROSA CLI. Lorsqu’une version plus récente est disponible, le CLI fournit un lien pour télécharger cette mise à jour.
- Le rôle de service AWS Elastic Load Balancing (ELB) existe dans votre compte AWS.
- Lorsque vous configurez un proxy à l’échelle du cluster, vous avez vérifié que le proxy est accessible depuis le VPC dans lequel le cluster est installé. Le proxy doit également être accessible depuis les sous-réseaux privés du VPC.
Procédure
- Accédez à OpenShift Cluster Manager et sélectionnez Créer un cluster.
- Dans la page Créer un cluster OpenShift, sélectionnez Créer un cluster dans la ligne Red Hat OpenShift sur AWS (ROSA).
Lorsqu’un compte AWS est automatiquement détecté, l’ID de compte est listé dans le menu déroulant des comptes AWS associés. Dans le cas où aucun compte AWS n’est détecté automatiquement, cliquez sur Sélectionner un compte → Associer un compte AWS et suivez ces étapes:
Dans la page Authenticate, cliquez sur le bouton copier à côté de la commande de connexion rosa. La commande inclut votre jeton de connexion OpenShift Cluster Manager API.
NoteIl est également possible de charger votre jeton API sur la page OpenShift Cluster Manager API Token sur OpenShift Cluster Manager.
Exécutez la commande copiée dans le CLI pour vous connecter à votre compte ROSA.
rosa login --token=<api_login_token>
$ rosa login --token=<api_login_token>1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- <api_login_token> par le jeton fourni dans la commande copiée.
Exemple de sortie
I: Logged in as '<username>' on 'https://api.openshift.com'
I: Logged in as '<username>' on 'https://api.openshift.com'Copy to Clipboard Copied! Toggle word wrap Toggle overflow - Dans la page Authenticate dans OpenShift Cluster Manager, cliquez sur Suivant.
Dans la page des rôles OCM, cliquez sur le bouton de copie à côté du rôle OCM de base ou des commandes de rôle OCM d’administration.
Le rôle de base permet à OpenShift Cluster Manager de détecter les rôles et politiques AWS IAM requis par ROSA. Le rôle d’administrateur permet également de détecter les rôles et les politiques. En outre, le rôle d’administrateur permet le déploiement automatique des rôles d’opérateur spécifiques au cluster et du fournisseur OpenID Connect (OIDC) en utilisant OpenShift Cluster Manager.
Exécutez la commande copiée dans le CLI et suivez les instructions pour créer le rôle OpenShift Cluster Manager IAM. L’exemple suivant crée un rôle de base OpenShift Cluster Manager IAM en utilisant les options par défaut:
rosa create ocm-role
$ rosa create ocm-roleCopy to Clipboard Copied! Toggle word wrap Toggle overflow Exemple de sortie
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Indiquez le préfixe à inclure dans le nom de rôle OCM IAM. La valeur par défaut est ManagedOpenShift. Il est possible de créer un seul rôle OCM par compte AWS pour votre organisation Red Hat.
- 2
- Activer le rôle d’administration OpenShift Cluster Manager IAM, ce qui équivaut à spécifier l’argument --admin. Le rôle d’administrateur est requis si vous souhaitez utiliser le mode Auto pour fournir automatiquement les rôles d’opérateur spécifiques au cluster et le fournisseur OIDC en utilisant OpenShift Cluster Manager.
- 3
- Facultatif : Spécifiez une limite d’autorisations avec Amazon Resource Name (ARN) pour le rôle. Consultez les limites des autorisations pour les entités IAM dans la documentation AWS.
- 4
- Indiquez un chemin ARN personnalisé pour votre rôle OCM. Le chemin doit contenir uniquement des caractères alphanumériques et commencer et se terminer par /, par exemple /test/path/dev/. Consultez la personnalisation du chemin ARN pour les rôles et les politiques IAM.
- 5
- Choisissez le mode de création de rôles. Le mode automatique permet de créer automatiquement le rôle OpenShift Cluster Manager IAM et de le lier à votre compte d’organisation Red Hat. En mode manuel, le ROSA CLI génère les commandes aws nécessaires pour créer et relier le rôle. En mode manuel, les fichiers JSON de stratégie correspondant sont également enregistrés dans le répertoire actuel. le mode manuel vous permet d’examiner les détails avant d’exécuter manuellement les commandes aws.
- 6
- Liez le rôle de gestionnaire de cluster OpenShift à votre compte d’organisation Red Hat.
Lorsque vous avez choisi de ne pas lier le rôle IAM OpenShift Cluster Manager à votre compte d’organisation Red Hat dans la commande précédente, copiez la commande de lien de rosa à partir de la page de rôle OCM OpenShift Cluster Manager OCM et exécutez-le:
rosa link ocm-role <arn>
$ rosa link ocm-role <arn>1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- <arn> par l’ARN du rôle OpenShift Cluster Manager IAM qui est inclus dans la sortie de la commande précédente.
- Cliquez sur Suivant sur la page des rôles OpenShift Cluster Manager OCM.
Dans la page des rôles de l’utilisateur, cliquez sur le bouton de copie de la commande de rôle utilisateur et exécutez la commande dans le CLI. Le Red Hat utilise le rôle d’utilisateur pour vérifier votre identité AWS lorsque vous installez un cluster et les ressources requises avec OpenShift Cluster Manager.
Consultez les instructions pour créer le rôle de l’utilisateur:
rosa create user-role
$ rosa create user-roleCopy to Clipboard Copied! Toggle word wrap Toggle overflow Exemple de sortie
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Indiquez le préfixe à inclure dans le nom du rôle utilisateur. La valeur par défaut est ManagedOpenShift.
- 2
- Facultatif : Spécifiez une limite d’autorisations avec Amazon Resource Name (ARN) pour le rôle. Consultez les limites des autorisations pour les entités IAM dans la documentation AWS.
- 3
- Indiquez un chemin ARN personnalisé pour votre rôle d’utilisateur. Le chemin doit contenir uniquement des caractères alphanumériques et commencer et se terminer par /, par exemple /test/path/dev/. Consultez la personnalisation du chemin ARN pour les rôles et les politiques IAM.
- 4
- Choisissez le mode de création de rôles. Le mode automatique permet de créer automatiquement le rôle de l’utilisateur et de le lier à votre compte d’utilisateur OpenShift Cluster Manager. En mode manuel, le ROSA CLI génère les commandes aws nécessaires pour créer et relier le rôle. En mode manuel, les fichiers JSON de stratégie correspondant sont également enregistrés dans le répertoire actuel. le mode manuel vous permet d’examiner les détails avant d’exécuter manuellement les commandes aws.
- 5
- Liez le rôle d’utilisateur à votre compte d’utilisateur OpenShift Cluster Manager.
Lorsque vous avez choisi de ne pas lier le rôle de l’utilisateur à votre compte d’utilisateur OpenShift Cluster Manager dans la commande précédente, copiez la commande de lien rosa à partir de la page de rôle utilisateur OpenShift Cluster Manager et exécutez-le:
rosa link user-role <arn>
$ rosa link user-role <arn>1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- <arn> par l’ARN du rôle utilisateur qui est inclus dans la sortie de la commande précédente.
- Dans la page des rôles d’utilisateur OpenShift Cluster Manager, cliquez sur OK.
- Assurez-vous que l’ID de compte AWS est listé dans le menu déroulant des comptes AWS associés sur la page Comptes et rôles.
Lorsque les rôles de compte requis n’existent pas, une notification est fournie indiquant que certains rôles de compte ARN n’ont pas été détectés. Il est possible de créer les rôles et stratégies AWS, y compris les stratégies d’opérateur, en cliquant sur le tampon de copie à côté de la commande rosa créer des rôles de compte et exécuter la commande dans le CLI:
rosa create account-roles
$ rosa create account-rolesCopy to Clipboard Copied! Toggle word wrap Toggle overflow Exemple de sortie
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Indiquez le préfixe à inclure dans le nom de rôle OpenShift Cluster Manager IAM. La valeur par défaut est ManagedOpenShift.Important
Il faut spécifier un préfixe de rôle à l’échelle du compte qui est unique sur votre compte AWS, même si vous utilisez un chemin ARN personnalisé pour les rôles de votre compte.
- 2
- Facultatif : Spécifiez une limite d’autorisations avec Amazon Resource Name (ARN) pour le rôle. Consultez les limites des autorisations pour les entités IAM dans la documentation AWS.
- 3
- Indiquez un chemin ARN personnalisé pour les rôles à l’échelle de votre compte. Le chemin doit contenir uniquement des caractères alphanumériques et commencer et se terminer par /, par exemple /test/path/dev/. Consultez la personnalisation du chemin ARN pour les rôles et les politiques IAM.
- 4
- Choisissez le mode de création de rôles. Il est possible d’utiliser le mode automatique pour créer automatiquement les rôles et les stratégies du compte. En mode manuel, le ROSA CLI génère les commandes aws nécessaires pour créer les rôles et les politiques. En mode manuel, les fichiers JSON de stratégie correspondant sont également enregistrés dans le répertoire actuel. le mode manuel vous permet d’examiner les détails avant d’exécuter manuellement les commandes aws.
- 5 6 7 8
- Crée l’installateur à l’échelle du compte, le plan de contrôle, les rôles de travail et de support et les politiques IAM correspondantes. Consultez pour plus d’informations le rôle et la référence des politiques et du rôle de l’IAM à l’échelle du compte.Note
Dans cette étape, le ROSA CLI crée également automatiquement les politiques IAM de l’opérateur à l’échelle du compte qui sont utilisées par les politiques d’opérateur spécifiques au cluster pour permettre aux opérateurs de cluster ROSA d’exécuter la fonctionnalité principale d’OpenShift. Consultez pour plus d’informations le rôle et la référence des politiques et du rôle de l’IAM à l’échelle du compte.
Dans la page Comptes et rôles, cliquez sur Refresh ARNs et vérifiez que l’installateur, le support, le travailleur et le rôle de compte de contrôle sont listés.
Lorsque vous avez plus d’un ensemble de rôles de compte dans votre compte AWS pour la version de votre cluster, une liste déroulante des ARN de rôle d’installateur est fournie. Choisissez l’ARN pour le rôle d’installateur que vous souhaitez utiliser avec votre cluster. Le cluster utilise les rôles et les politiques à l’échelle du compte qui se rapportent au rôle d’installateur sélectionné.
Cliquez sur Next.
NoteLorsque la page Comptes et rôles a été actualisée, vous devrez peut-être sélectionner la case à cocher pour reconnaître que vous avez lu et rempli toutes les conditions préalables.
Dans la page Détails du cluster, fournissez un nom pour votre cluster et spécifiez les détails du cluster:
- Ajoutez un nom de cluster.
Facultatif: Création de cluster génère un préfixe de domaine en tant que sous-domaine pour votre cluster provisionné sur openshiftapps.com. Lorsque le nom du cluster est inférieur ou égal à 15 caractères, ce nom est utilisé pour le préfixe de domaine. Lorsque le nom du cluster est supérieur à 15 caractères, le préfixe de domaine est généré au hasard sur une chaîne de 15 caractères.
Afin de personnaliser le sous-domaine, sélectionnez la case à cocher Créer un préfixe de domaine personnalisé et entrez le nom de préfixe de domaine dans le champ Préfixe de domaine. Le préfixe de domaine ne peut pas dépasser 15 caractères, doit être unique au sein de votre organisation et ne peut pas être modifié après la création de clusters.
- Choisissez une version de cluster dans le menu déroulant Version.
- Choisissez une région fournisseur de cloud dans le menu déroulant Région.
- Choisissez une configuration de zone unique ou multi-zone.
- Laissez activer la surveillance de la charge de travail de l’utilisateur sélectionnée pour surveiller vos propres projets indépendamment des métriques de la plate-forme Red Hat Site Reliability Engineer (SRE). Cette option est activée par défaut.
Facultatif: Expandez le chiffrement avancé pour apporter des modifications aux paramètres de chiffrement.
Acceptez le paramètre par défaut Utilisez les clés KMS par défaut pour utiliser votre clé AWS KMS par défaut, ou sélectionnez Utilisez les touches KMS personnalisées pour utiliser une clé KMS personnalisée.
- Avec les touches KMS personnalisées sélectionnées, saisissez l’ARN ARN de la clé personnalisée Amazon Resource Name (ARN) d’AWS Key Management Service (KMS) dans le champ Key ARN. La clé est utilisée pour chiffrer tous les plans de contrôle, l’infrastructure, les volumes racine des nœuds de travail et les volumes persistants de votre cluster.
Facultatif: Pour créer une clé KMS gérée par le client, suivez la procédure de création de clés KMS de chiffrement symétrique.
ImportantLe rôle d’opérateur EBS est requis en plus des rôles de compte pour créer avec succès votre cluster.
Ce rôle doit être associé à la stratégie ManagedOpenShift-openshift-cluster-csi-drivers-ebs-cloud-credentials, une politique IAM requise par ROSA pour gérer le stockage back-end via l’interface de stockage de conteneurs (CSI).
Consultez les méthodes de création de rôles à l’échelle du compte pour obtenir de plus amples renseignements sur les politiques et les autorisations requises par les opérateurs de cluster.
Exemple de rôle d’opérateur EBS
"ARN:aws:iam::<aws_account_id>:role/<cluster_name>-xxxx-openshift-cluster-csi-drivers-ebs-cloud-credent"Après avoir créé vos rôles d’opérateur, vous devez modifier la stratégie clé dans la page Services de gestion des clés (KMS) de la console AWS pour ajouter les rôles.
Facultatif: Sélectionnez Activer la cryptographie FIPS si vous exigez que votre cluster soit validé FIPS.
NoteLorsque la cryptographie FIPS est sélectionnée, Activer le chiffrement etcd supplémentaire est activé par défaut et ne peut pas être désactivé. Activez le chiffrement supplémentaire etcd sans sélectionner Activer la cryptographie FIPS.
Facultatif: Sélectionnez Activer le chiffrement supplémentaire etcd si vous avez besoin d’un cryptage de valeur clé etcd. Avec cette option, les valeurs de clé etcd sont cryptées, mais les clés ne le sont pas. Cette option s’ajoute au chiffrement de stockage de plan de contrôle qui chiffre les volumes etcd dans Red Hat OpenShift Service sur les clusters AWS par défaut.
NoteEn activant le chiffrement etcd pour les valeurs clés dans etcd, vous subirez un surcharge de performance d’environ 20%. Les frais généraux sont le résultat de l’introduction de cette deuxième couche de chiffrement, en plus du chiffrement de stockage de plan de contrôle par défaut qui crypte les volumes etcd. Envisagez d’activer le chiffrement etcd seulement si vous en avez spécifiquement besoin pour votre cas d’utilisation.
- Cliquez sur Next.
Dans la page de pool de machines par défaut, sélectionnez un type d’instance de nœud de calcul.
NoteAprès la création de votre cluster, vous pouvez modifier le nombre de nœuds de calcul dans votre cluster, mais vous ne pouvez pas modifier le type d’instance de nœud de calcul dans le pool de machines par défaut. Le nombre et les types de nœuds à votre disposition dépendent de l’utilisation de zones de disponibilité uniques ou multiples. Ils dépendent également de ce qui est activé et disponible dans votre compte AWS et la région sélectionnée.
Facultatif: Configurer l’autoscaling pour le pool de machines par défaut:
- Activez la mise à l’échelle automatique pour mettre automatiquement à l’échelle le nombre de machines de votre pool de machines par défaut pour répondre aux besoins de déploiement.
Définissez les limites minimales et maximales de comptage des nœuds pour l’autoscaling. Le cluster autoscaler ne réduit pas ou n’augmente pas le nombre de nœuds de pool machine par défaut au-delà des limites que vous spécifiez.
- Lorsque vous avez déployé votre cluster à l’aide d’une seule zone de disponibilité, définissez le nombre minimum de nœuds et le nombre maximal de nœuds. Cela définit les limites minimales et maximales des nœuds de calcul dans la zone de disponibilité.
- Lorsque vous avez déployé votre cluster à l’aide de plusieurs zones de disponibilité, définissez les nœuds minimum par zone et les nœuds maximaux par zone. Cela définit les limites minimales et maximales des nœuds de calcul par zone.
NoteAlternativement, vous pouvez définir vos préférences de mise à l’échelle automatique pour le pool de machines par défaut après la création du pool de machines.
Dans le cas où vous n’avez pas activé la mise à l’échelle automatique, sélectionnez un nombre de nœuds de calcul pour votre pool de machines par défaut:
- Lorsque vous avez déployé votre cluster à l’aide d’une seule zone de disponibilité, sélectionnez un compte de nœuds de calcul dans le menu déroulant. Cela définit le nombre de nœuds de calcul à fournir au pool de machines pour la zone.
- Lorsque vous avez déployé votre cluster à l’aide de plusieurs zones de disponibilité, sélectionnez le nombre de nœuds de calcul (par zone) dans le menu déroulant. Cela définit le nombre de nœuds de calcul à fournir au pool de machine par zone.
Facultatif: Sélectionnez une configuration EC2 Instance Metadata Service (IMDS) - optionnelle (par défaut) ou requise - pour appliquer l’utilisation de IMDSv2. Consultez les métadonnées de l’instance et les données de l’utilisateur dans la documentation AWS.
ImportantLes paramètres du service de métadonnées d’instance ne peuvent pas être modifiés après la création de votre cluster.
- En option: Expandez les étiquettes de nœuds pour ajouter des étiquettes à vos nœuds. Cliquez sur Ajouter une étiquette pour ajouter d’autres étiquettes de nœuds et sélectionnez Suivant.
Dans la section Confidentialité du cluster de la page de configuration du réseau, sélectionnez Public ou Privé pour utiliser les points de terminaison des API publiques ou privées et les itinéraires d’application pour votre cluster.
ImportantLe point de terminaison API ne peut pas être modifié entre public et privé après la création de votre cluster.
- Fin de l’API publique
- Choisissez Public si vous ne voulez pas restreindre l’accès à votre cluster. Depuis Internet, vous pouvez accéder au point de terminaison de l’API Kubernetes et aux itinéraires d’application.
- Fin de l’API privée
Choisissez Privé si vous souhaitez restreindre l’accès au réseau à votre cluster. Le point de terminaison de l’API Kubernetes et les itinéraires d’application sont accessibles uniquement à partir de connexions privées directes.
ImportantLorsque vous utilisez des points de terminaison d’API privés, vous ne pouvez pas accéder à votre cluster tant que vous n’avez pas mis à jour les paramètres réseau de votre compte fournisseur de cloud.
Facultatif : Si vous avez choisi d’utiliser des points de terminaison d’API publics, un nouveau VPC est créé par défaut pour votre cluster. Dans le cas où vous souhaitez installer votre cluster dans un VPC existant, sélectionnez Installer dans un VPC existant.
AvertissementIl est impossible d’installer un cluster ROSA dans un VPC existant créé par l’installateur OpenShift. Ces VPC sont créés au cours du processus de déploiement de clusters et ne doivent être associés qu’à un seul cluster pour s’assurer que les opérations de provisionnement et de suppression des clusters fonctionnent correctement.
Afin de vérifier si un VPC a été créé par l’installateur OpenShift, vérifiez la valeur détenue sur la balise kubernetes.io/cluster/<infra-id>. Lors de l’affichage des balises pour le VPC nommée mycluster-12abc-34def, la balise kubernetes.io/cluster/mycluster-12abc-34def a une valeur de propriété. Le VPC a donc été créé par l’installateur et ne doit pas être modifié par l’administrateur.
NoteLorsque vous avez choisi d’utiliser des points de terminaison d’API privés, vous devez utiliser un VPC existant et PrivateLink et l’installation dans un VPC existant et utiliser une option PrivateLink sont automatiquement sélectionnées. Grâce à ces options, l’équipe de Red Hat Site Reliability Engineering (SRE) peut se connecter au cluster pour vous aider avec le support en utilisant uniquement les points de terminaison AWS PrivateLink.
- Facultatif: Si vous installez votre cluster dans un VPC existant, sélectionnez Configurer un proxy à l’échelle du cluster pour activer un proxy HTTP ou HTTPS pour refuser l’accès direct à Internet à partir de votre cluster.
- Cliquez sur Next.
Lorsque vous avez choisi d’installer le cluster dans un VPC AWS existant, fournissez vos paramètres de sous-réseau Virtual Private Cloud (VPC).
NoteAssurez-vous que votre VPC est configuré avec un sous-réseau public et privé pour chaque zone de disponibilité dans laquelle vous souhaitez installer le cluster. Lorsque vous avez choisi d’utiliser PrivateLink, seuls les sous-réseaux privés sont requis.
En option: étendez les groupes de sécurité supplémentaires et sélectionnez des groupes de sécurité personnalisés supplémentaires à appliquer aux nœuds dans les pools de machines créés par défaut. Il faut déjà avoir créé les groupes de sécurité et les associer au VPC que vous avez sélectionné pour ce cluster. Après avoir créé le cluster, vous ne pouvez pas ajouter ou modifier des groupes de sécurité dans les pools de machines par défaut.
Les groupes de sécurité que vous spécifiez seront ajoutés par défaut pour tous les types de nœuds. Décochez la case Appliquer les mêmes groupes de sécurité à tous les types de nœuds (plan de contrôle, infrastructure et travail) pour sélectionner différents groupes de sécurité pour chaque type de nœud.
Consultez les exigences relatives aux groupes de sécurité au titre des ressources supplémentaires.
Lorsque vous avez choisi de configurer un proxy à l’échelle du cluster, fournissez les détails de la configuration de votre proxy sur la page proxy à l’échelle du cluster:
Entrez une valeur dans au moins un des champs suivants:
- Indiquez une URL proxy HTTP valide.
- Indiquez une URL proxy HTTPS valide.
- Dans le champ Autres paquets de confiance, fournissez un paquet de certificats X.509 codé PEM. Le paquet est ajouté au magasin de certificats de confiance pour les nœuds de cluster. Il est nécessaire d’obtenir un fichier de groupe de confiance supplémentaire si vous utilisez un proxy d’inspection TLS à moins que le certificat d’identité du proxy ne soit signé par une autorité du groupe de confiance Red Hat Enterprise Linux CoreOS (RHCOS). Cette exigence s’applique indépendamment du fait que le proxy soit transparent ou nécessite une configuration explicite en utilisant les arguments http-proxy et https-proxy.
Cliquez sur Next.
Afin d’obtenir plus d’informations sur la configuration d’un proxy avec Red Hat OpenShift Service sur AWS, consultez Configurer un proxy à l’échelle du cluster.
Dans la boîte de dialogue des plages CIDR, configurez des gammes de routage interdomaine sans classe (CIDR) ou utilisez les valeurs par défaut qui sont fournies et cliquez sur Suivant.
NoteLorsque vous installez dans un VPC, la gamme Machine CIDR doit correspondre aux sous-réseaux VPC.
ImportantLes configurations CIDR ne peuvent pas être modifiées ultérieurement. Confirmez vos sélections avec votre administrateur réseau avant de procéder.
Dans la page Rôles et stratégies de cluster, sélectionnez le rôle IAM de votre cluster préféré et le mode de création de fournisseurs OIDC.
Avec le mode Manuel, vous pouvez utiliser soit les commandes rosa CLI soit les commandes aws CLI pour générer les rôles d’opérateur requis et le fournisseur OIDC pour votre cluster. Le mode manuel vous permet d’examiner les détails avant d’utiliser votre option préférée pour créer les ressources IAM manuellement et terminer l’installation de votre cluster.
Alternativement, vous pouvez utiliser le mode Auto pour créer automatiquement les rôles d’opérateur et le fournisseur OIDC. Afin d’activer le mode Auto, le rôle OpenShift Cluster Manager IAM doit avoir des capacités d’administrateur.
NoteLorsque vous avez spécifié des chemins ARN personnalisés lorsque vous avez créé les rôles associés à l’ensemble du compte, le chemin personnalisé est automatiquement détecté et appliqué aux rôles d’opérateur. Le chemin ARN personnalisé est appliqué lorsque les rôles Opérateur sont créés en utilisant le mode Manuel ou Auto.
Facultatif : Spécifiez un préfixe de rôles d’opérateur personnalisé pour les rôles IAM d’opérateur spécifiques à votre cluster.
NoteLes noms de rôles de l’opérateur spécifique au cluster sont préfixés avec le nom du cluster et le hachage aléatoire à 4 chiffres. En option, vous pouvez spécifier un préfixe personnalisé pour remplacer <cluster_name>-<hash> dans les noms de rôles. Le préfixe est appliqué lorsque vous créez les rôles IAM d’opérateur spécifiques au cluster. Afin d’obtenir des informations sur le préfixe, consultez À propos des préfixes de rôle de l’opérateur IAM personnalisés.
- Choisissez Suivant.
Dans la page Stratégie de mise à jour Cluster, configurez vos préférences de mise à jour:
Choisissez une méthode de mise à jour de cluster:
- Choisissez des mises à jour individuelles si vous souhaitez planifier chaque mise à jour individuellement. C’est l’option par défaut.
Choisissez les mises à jour récurrentes pour mettre à jour votre cluster le jour de votre choix et l’heure de début, lorsque des mises à jour sont disponibles.
ImportantLorsque vous optez pour des mises à jour récurrentes, vous devez mettre à jour les ressources IAM à l’échelle du compte et spécifiques au cluster avant de mettre à jour votre cluster entre les versions mineures.
NoteConsultez les dates de fin de vie dans la documentation sur le cycle de vie de Red Hat OpenShift Service sur AWS. Consultez Red Hat OpenShift Service sur le cycle de vie de la mise à jour AWS.
- Lorsque vous avez opté pour des mises à jour récurrentes, sélectionnez un jour préféré de la semaine et mettez à niveau l’heure de début en UTC dans les menus déroulants.
- Facultatif: Vous pouvez définir un délai de grâce pour le drainage des nœuds pendant les mises à niveau de cluster. Le délai de grâce d’une heure est fixé par défaut.
Cliquez sur Next.
NoteEn cas de problèmes de sécurité critiques qui ont un impact significatif sur la sécurité ou la stabilité d’un cluster, Red Hat Site Reliability Engineering (SRE) pourrait programmer des mises à jour automatiques de la dernière version z-stream qui n’est pas affectée. Les mises à jour sont appliquées dans les 48 heures suivant la notification des clients. La description de la cote de sécurité d’impact critique, voir Comprendre les cotes de sécurité Red Hat.
- Examinez le résumé de vos sélections et cliquez sur Créer un cluster pour démarrer l’installation du cluster.
Lorsque vous avez choisi d’utiliser le mode Manuel, créez manuellement les rôles d’opérateur spécifiques au cluster et le fournisseur OIDC pour continuer l’installation:
Dans la boîte de dialogue Action nécessaire pour continuer l’installation, sélectionnez soit l’onglet AWS CLI ou l’onglet ROSA CLI et créez manuellement les ressources:
Lorsque vous avez choisi d’utiliser la méthode AWS CLI, cliquez sur Télécharger .zip, enregistrez le fichier, puis extrayez les fichiers de commande et de stratégie AWS CLI. Ensuite, exécutez les commandes aws fournies dans le CLI.
NoteIl faut exécuter les commandes aws dans le répertoire qui contient les fichiers de stratégie.
Lorsque vous avez choisi d’utiliser la méthode ROSA CLI, cliquez sur le bouton copier à côté de la rosa créer des commandes et les exécuter dans le CLI.
NoteLorsque vous avez spécifié des chemins ARN personnalisés lorsque vous avez créé les rôles associés à l’ensemble du compte, le chemin personnalisé est automatiquement détecté et appliqué aux rôles d’opérateur lorsque vous les créez en utilisant ces méthodes manuelles.
- Dans la boîte de dialogue Action requise pour continuer l’installation, cliquez sur x pour retourner à la page Aperçu de votre cluster.
- Assurez-vous que l’état du cluster dans la section Détails de la page Aperçu de votre cluster a changé de l’attente à l’installation. Il peut y avoir un court délai d’environ deux minutes avant que le statut ne change.
NoteLorsque vous avez choisi d’utiliser le mode Auto, OpenShift Cluster Manager crée automatiquement les rôles Opérateur et le fournisseur OIDC.
ImportantLe rôle d’opérateur EBS est requis en plus des rôles de compte pour créer avec succès votre cluster.
Ce rôle doit être associé à la stratégie ManagedOpenShift-openshift-cluster-csi-drivers-ebs-cloud-credentials, une politique IAM requise par ROSA pour gérer le stockage back-end via l’interface de stockage de conteneurs (CSI).
Consultez les méthodes de création de rôles à l’échelle du compte pour obtenir de plus amples renseignements sur les politiques et les autorisations requises par les opérateurs de cluster.
Exemple de rôle d’opérateur EBS
"ARN:aws:iam::<aws_account_id>:role/<cluster_name>-xxxx-openshift-cluster-csi-drivers-ebs-cloud-credent"Après avoir créé vos rôles d’opérateur, vous devez modifier la stratégie clé dans la page Services de gestion des clés (KMS) de la console AWS pour ajouter les rôles.
La vérification
Dans la page Aperçu de votre cluster, vous pouvez suivre l’avancement de l’installation. Les journaux d’installation sont affichés sur la même page. Le cluster est prêt lorsque l’état dans la section Détails de la page est listé comme prêt.
NoteEn cas d’échec de l’installation ou que l’état du cluster ne change pas pour Ready après environ 40 minutes, vérifiez la documentation de dépannage de l’installation pour plus de détails. De plus amples informations sont disponibles sur les installations de dépannage. Les étapes à suivre pour contacter Red Hat Support pour obtenir de l’aide sont disponibles sur AWS.
2.7.2. Créer un cluster avec des personnalisations à l’aide du CLI Copier lienLien copié sur presse-papiers!
Lorsque vous créez un Red Hat OpenShift Service sur AWS (ROSA) cluster qui utilise AWS Security Token Service (STS), vous pouvez personnaliser votre installation de manière interactive.
Lorsque vous exécutez la commande rosa create cluster --interactive au moment de la création de cluster, vous êtes présenté avec une série d’invites interactives qui vous permettent de personnaliser votre déploiement. Consultez la référence du mode de création de clusters interactifs pour plus d’informations.
Après l’installation d’un cluster utilisant le mode interactif, une seule commande est fournie dans la sortie qui vous permet de déployer d’autres clusters en utilisant la même configuration personnalisée.
Les clusters PrivateLink publics et AWS ne sont pris en charge que par STS. Les clusters privés réguliers (non-PrivateLink) ne sont pas disponibles pour une utilisation avec STS.
Conditions préalables
- Avec STS, vous avez complété les prérequis AWS pour ROSA.
- Des quotas de service AWS sont disponibles.
- Le service ROSA est activé dans la console AWS.
- L’installation et la configuration de la dernière ROSA CLI, rosa, sur votre hôte d’installation. Exécutez la version rosa pour voir votre version actuellement installée de la ROSA CLI. Lorsqu’une version plus récente est disponible, le CLI fournit un lien pour télécharger cette mise à jour.
Lorsque vous souhaitez utiliser une clé AWS Key Management Service (KMS) gérée par le client pour le chiffrement, vous devez créer une clé KMS symétrique. Lors de la création de votre cluster, vous devez fournir le nom de ressource Amazon (ARN). Afin de créer une clé KMS gérée par le client, suivez la procédure de création de clés KMS de chiffrement symétrique.
ImportantLe rôle d’opérateur EBS est requis en plus des rôles de compte pour créer avec succès votre cluster.
Ce rôle doit être associé à la stratégie ManagedOpenShift-openshift-cluster-csi-drivers-ebs-cloud-credentials, une politique IAM requise par ROSA pour gérer le stockage back-end via l’interface de stockage de conteneurs (CSI).
Consultez les méthodes de création de rôles à l’échelle du compte pour obtenir de plus amples renseignements sur les politiques et les autorisations requises par les opérateurs de cluster.
Exemple de rôle d’opérateur EBS
"ARN:aws:iam::<aws_account_id>:role/<cluster_name>-xxxx-openshift-cluster-csi-drivers-ebs-cloud-credent"Après avoir créé vos rôles d’opérateur, vous devez modifier la stratégie clé dans la page Services de gestion des clés (KMS) de la console AWS pour ajouter les rôles.
Procédure
Créer les rôles et politiques nécessaires à l’échelle du compte, y compris les politiques de l’opérateur:
Générer les fichiers JSON de stratégie IAM dans le répertoire de travail actuel et afficher les commandes aws CLI pour examen:
rosa create account-roles --interactive \ --mode manual$ rosa create account-roles --interactive \1 --mode manual2 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- le mode interactif vous permet de spécifier les options de configuration dans les instructions interactives. Consultez la référence du mode de création de clusters interactifs pour plus d’informations.
- 2
- le mode manuel génère les commandes aws CLI et les fichiers JSON nécessaires pour créer les rôles et les politiques à l’échelle du compte. Après examen, vous devez exécuter les commandes manuellement pour créer les ressources.
Exemple de sortie
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Indiquez le préfixe à inclure dans le nom de rôle OpenShift Cluster Manager IAM. La valeur par défaut est ManagedOpenShift.Important
Il faut spécifier un préfixe de rôle à l’échelle du compte qui est unique sur votre compte AWS, même si vous utilisez un chemin ARN personnalisé pour les rôles de votre compte.
- 2
- Facultatif : Spécifie une limite d’autorisations à Amazon Resource Name (ARN) pour le rôle. Consultez les limites des autorisations pour les entités IAM dans la documentation AWS.
- 3
- Indiquez un chemin ARN personnalisé pour les rôles à l’échelle de votre compte. Le chemin doit contenir uniquement des caractères alphanumériques et commencer et se terminer par /, par exemple /test/path/dev/. Consultez la personnalisation du chemin ARN pour les rôles et les politiques IAM.
- 4
- Choisissez le mode de création de rôles. Il est possible d’utiliser le mode automatique pour créer automatiquement les rôles et les stratégies du compte. En mode manuel, la rosa CLI génère les commandes aws nécessaires pour créer les rôles et les politiques. En mode manuel, les fichiers JSON de stratégie correspondant sont également enregistrés dans le répertoire actuel. le mode manuel vous permet d’examiner les détails avant d’exécuter manuellement les commandes aws.
- 5 6 7 8
- Crée l’installateur à l’échelle du compte, le plan de contrôle, les rôles de travail et de support et les politiques IAM correspondantes. Consultez pour plus d’informations le rôle et la référence des politiques et du rôle de l’IAM à l’échelle du compte.Note
Dans cette étape, le ROSA CLI crée également automatiquement les politiques IAM de l’opérateur à l’échelle du compte qui sont utilisées par les politiques d’opérateur spécifiques au cluster pour permettre aux opérateurs de cluster ROSA d’exécuter la fonctionnalité principale d’OpenShift. Consultez pour plus d’informations le rôle et la référence des politiques et du rôle de l’IAM à l’échelle du compte.
- Après examen, exécutez les commandes aws manuellement pour créer les rôles et les stratégies. Alternativement, vous pouvez exécuter la commande précédente en utilisant --mode auto pour exécuter immédiatement les commandes aws.
Facultatif: Si vous utilisez votre propre clé AWS KMS pour chiffrer le plan de contrôle, l’infrastructure, les volumes racine des nœuds de travail et les volumes persistants (PV), ajoutez l’ARN pour le rôle d’installateur à l’échelle du compte à votre politique de clé KMS.
ImportantLes volumes persistants (PV) créés à partir de la classe de stockage par défaut sont chiffrés avec cette clé spécifique.
Les PVS créés en utilisant n’importe quelle autre classe de stockage sont toujours cryptés, mais les PV ne sont pas cryptés avec cette clé, sauf si la classe de stockage est spécifiquement configurée pour utiliser cette clé.
Enregistrez la stratégie clé de votre clé KMS dans un fichier sur votre machine locale. L’exemple suivant permet d’économiser la sortie sur kms-key-policy.json dans le répertoire de travail actuel:
aws kms get-key-policy --key-id <key_id_or_arn> --policy-name default --output text > kms-key-policy.json
$ aws kms get-key-policy --key-id <key_id_or_arn> --policy-name default --output text > kms-key-policy.json1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- <key_id_or_arn> par l’ID ou l’ARN de votre clé KMS.
Ajoutez l’ARN pour le rôle d’installation à l’échelle du compte que vous avez créé dans l’étape précédente à la section Statement.Principal.AWS dans le fichier. Dans l’exemple suivant, le rôle ARN pour le rôle par défaut ManagedOpenShift-Installer-Role est ajouté:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1 3
- Il faut spécifier l’ARN pour le rôle à l’échelle du compte qui sera utilisé lors de la création du cluster ROSA. Les ARN énumérés dans la section doivent être séparés par des virgules.
- 2 4
- Il faut spécifier l’ARN pour le rôle de l’opérateur qui sera utilisé lors de la création du cluster ROSA. Les ARN énumérés dans la section doivent être séparés par des virgules.
Appliquez les modifications à votre politique clé KMS:
aws kms put-key-policy --key-id <key_id_or_arn> \ --policy file://kms-key-policy.json \ --policy-name default$ aws kms put-key-policy --key-id <key_id_or_arn> \1 --policy file://kms-key-policy.json \2 --policy-name defaultCopy to Clipboard Copied! Toggle word wrap Toggle overflow Lorsque vous créez le cluster à l’étape suivante, vous pouvez faire référence à l’ARN de votre clé KMS.
Créez un cluster avec STS en utilisant des options d’installation personnalisées. Il est possible d’utiliser le mode --interactive pour spécifier de manière interactive les paramètres personnalisés:
AvertissementIl est impossible d’installer un cluster ROSA dans un VPC existant créé par l’installateur OpenShift. Ces VPC sont créés au cours du processus de déploiement de clusters et ne doivent être associés qu’à un seul cluster pour s’assurer que les opérations de provisionnement et de suppression des clusters fonctionnent correctement.
Afin de vérifier si un VPC a été créé par l’installateur OpenShift, vérifiez la valeur détenue sur la balise kubernetes.io/cluster/<infra-id>. Lors de l’affichage des balises pour le VPC nommée mycluster-12abc-34def, la balise kubernetes.io/cluster/mycluster-12abc-34def a une valeur de propriété. Le VPC a donc été créé par l’installateur et ne doit pas être modifié par l’administrateur.
rosa create cluster --interactive --sts
$ rosa create cluster --interactive --stsCopy to Clipboard Copied! Toggle word wrap Toggle overflow Exemple de sortie
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- En option. Lors de la création de votre cluster, vous pouvez personnaliser le sous-domaine de votre cluster sur *.openshiftapps.com à l’aide du drapeau --domain-prefix. La valeur de ce drapeau doit être unique au sein de votre organisation, ne peut pas dépasser 15 caractères et ne peut pas être modifiée après la création de clusters. Lorsque le drapeau n’est pas fourni, une valeur générée automatiquement est créée qui dépend de la longueur du nom du cluster. Lorsque le nom du cluster est inférieur ou égal à 15 caractères, ce nom est utilisé pour le préfixe de domaine. Lorsque le nom du cluster est supérieur à 15 caractères, le préfixe de domaine est généré au hasard sur une chaîne de 15 caractères.
- 2
- Lors de la création de votre cluster, vous pouvez créer un utilisateur administrateur local (cluster-admin) pour votre cluster. Cela configure automatiquement un fournisseur d’identité htpasswd pour l’utilisateur cluster-admin.
- 3
- Il est possible de créer un mot de passe personnalisé pour l’utilisateur cluster-admin ou de demander au système de générer un mot de passe. Dans le cas où vous ne créez pas de mot de passe personnalisé, le mot de passe généré s’affiche dans la sortie de la ligne de commande. Lorsque vous spécifiez un mot de passe personnalisé, le mot de passe doit être d’au moins 14 caractères (norme CSAII) sans espace blanc. Lorsqu’il est défini, le mot de passe est haché et transporté en toute sécurité.
- 4
- Lors de la création du cluster, les options de version OpenShift listées incluent les versions majeures, mineures et patchées, par exemple 4.18.0.
- 5
- Facultatif: Spécifiez en option pour configurer toutes les instances EC2 pour utiliser à la fois les points de terminaison v1 et v2 du service de métadonnées d’instance EC2 (IMDS). C’est la valeur par défaut. Indiquez nécessaire pour configurer toutes les instances EC2 pour utiliser IMDSv2 uniquement.Important
Les paramètres du service de métadonnées d’instance ne peuvent pas être modifiés après la création de votre cluster.
- 6
- Lorsque vous avez plus d’un ensemble de rôles de compte pour la version de votre cluster dans votre compte Amazon Web Services (AWS), une liste interactive d’options est fournie.
- 7
- Facultatif : Spécifiez un identifiant unique qui est passé par Red Hat OpenShift Service sur AWS et l’installateur OpenShift lorsqu’un rôle de compte est assumé. Cette option n’est requise que pour les rôles de compte personnalisés qui s’attendent à un identifiant externe.
- 8
- Les noms de rôles de l’opérateur spécifique au cluster sont préfixés avec le nom du cluster et un hachage aléatoire à 4 chiffres. En option, vous pouvez spécifier un préfixe personnalisé pour remplacer <cluster_name>-<hash> dans les noms de rôles. Le préfixe est appliqué lorsque vous créez les rôles IAM d’opérateur spécifiques au cluster. Afin d’obtenir des informations sur le préfixe, consultez À propos des préfixes de rôle de l’opérateur IAM personnalisés.Note
Lorsque vous avez spécifié des chemins ARN personnalisés lorsque vous avez créé les rôles associés à l’ensemble du compte, le chemin personnalisé est automatiquement détecté. Le chemin personnalisé est appliqué aux rôles d’opérateur spécifiques au cluster lorsque vous les créez dans une étape ultérieure.
- 9
- Facultatif : Spécifiez une balise utilisée sur toutes les ressources créées par Red Hat OpenShift Service sur AWS. Les balises peuvent vous aider à gérer, identifier, organiser, rechercher et filtrer les ressources au sein d’AWS. Les balises sont séparées par virgule, par exemple: valeur clé, entrée de données.Important
Le service Red Hat OpenShift sur AWS ne prend en charge que les balises personnalisées des ressources Red Hat OpenShift lors de la création de clusters. Lorsqu’ils ont été ajoutés, les balises ne peuvent pas être supprimées ou modifiées. Les balises ajoutées par Red Hat sont nécessaires pour que les clusters restent en conformité avec les accords de niveau de production de Red Hat (SLA). Ces balises ne doivent pas être supprimées.
Le service OpenShift Red Hat sur AWS ne prend pas en charge l’ajout de balises supplémentaires en dehors des ressources gérées par le cluster ROSA. Ces balises peuvent être perdues lorsque les ressources AWS sont gérées par le cluster ROSA. Dans ces cas, vous pourriez avoir besoin de solutions ou d’outils personnalisés pour réconcilier les balises et les garder intactes.
- 10
- Facultatif: plusieurs zones de disponibilité sont recommandées pour les charges de travail de production. La valeur par défaut est une seule zone de disponibilité.
- 11
- Facultatif: Vous pouvez créer un cluster dans un VPC existant, ou ROSA peut créer un nouveau VPC à utiliser.Avertissement
Il est impossible d’installer un cluster ROSA dans un VPC existant créé par l’installateur OpenShift. Ces VPC sont créés au cours du processus de déploiement de clusters et ne doivent être associés qu’à un seul cluster pour s’assurer que les opérations de provisionnement et de suppression des clusters fonctionnent correctement.
Afin de vérifier si un VPC a été créé par l’installateur OpenShift, vérifiez la valeur détenue sur la balise kubernetes.io/cluster/<infra-id>. Lors de l’affichage des balises pour le VPC nommée mycluster-12abc-34def, la balise kubernetes.io/cluster/mycluster-12abc-34def a une valeur de propriété. Le VPC a donc été créé par l’installateur et ne doit pas être modifié par l’administrateur.
- 12
- Facultatif : Activez cette option si vous utilisez votre propre clé AWS KMS pour chiffrer le plan de contrôle, l’infrastructure, les volumes racine des nœuds de travail et les PV. Indiquez l’ARN pour la clé KMS que vous avez ajoutée au rôle ARN à l’échelle du compte dans l’étape précédente.Important
Les volumes persistants (PV) créés à partir de la classe de stockage par défaut sont chiffrés avec cette clé spécifique.
Les PVS créés en utilisant n’importe quelle autre classe de stockage sont toujours cryptés, mais les PV ne sont pas cryptés avec cette clé, sauf si la classe de stockage est spécifiquement configurée pour utiliser cette clé.
- 13
- Facultatif: Vous pouvez sélectionner des groupes de sécurité personnalisés supplémentaires à utiliser dans votre cluster. Il faut déjà avoir créé les groupes de sécurité et les associer au VPC que vous avez sélectionné pour ce cluster. Après avoir créé le pool de machines, vous ne pouvez pas ajouter ou modifier des groupes de sécurité pour les pools de machines par défaut. Consultez les exigences relatives aux groupes de sécurité au titre des ressources supplémentaires.
- 14
- Facultatif : Activez cette option si vous exigez que votre cluster soit validé FIPS. La sélection de cette option signifie que l’option de chiffrement des données etcd est activée par défaut et ne peut pas être désactivée. Il est possible de chiffrer les données etc. sans activer le support FIPS.
- 15
- Facultatif: Activez cette option si votre cas d’utilisation nécessite seulement un cryptage de valeur clé etcd en plus du chiffrement de stockage de plan de contrôle qui chiffre les volumes etcd par défaut. Avec cette option, les valeurs de clé etcd sont cryptées mais pas les clés.Important
En activant le chiffrement etcd pour les valeurs clés dans etcd, vous subirez un surcharge de performance d’environ 20%. Les frais généraux sont le résultat de l’introduction de cette deuxième couche de chiffrement, en plus du chiffrement de stockage de plan de contrôle par défaut qui crypte les volumes etcd. Le Red Hat vous recommande d’activer le chiffrement etc. uniquement si vous en avez spécifiquement besoin pour votre cas d’utilisation.
- 16
- La sortie comprend une commande personnalisée que vous pouvez exécuter pour créer un autre cluster avec la même configuration.
Comme alternative à l’utilisation du mode --interactive, vous pouvez spécifier les options de personnalisation directement lorsque vous exécutez la commande rosa create cluster. Exécutez la commande rosa create cluster --help pour afficher une liste d’options CLI disponibles, ou voir créer un cluster dans Gérer des objets avec le ROSA CLI.
ImportantIl faut remplir les étapes suivantes pour créer les rôles de l’opérateur IAM et le fournisseur OpenID Connect (OIDC) pour déplacer l’état du cluster.
Créer les rôles IAM d’opérateur spécifiques au cluster:
Générez les fichiers JSON de stratégie de l’opérateur IAM dans le répertoire de travail actuel et publiez les commandes aws CLI pour examen:
rosa create operator-roles --mode manual --cluster <cluster_name|cluster_id>
$ rosa create operator-roles --mode manual --cluster <cluster_name|cluster_id>1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- le mode manuel génère les commandes aws CLI et les fichiers JSON nécessaires pour créer les rôles d’opérateur. Après examen, vous devez exécuter les commandes manuellement pour créer les ressources.
Après examen, exécutez les commandes aws manuellement pour créer les rôles IAM de l’opérateur et joindre les stratégies d’opérateur géré. Alternativement, vous pouvez exécuter à nouveau la commande précédente en utilisant --mode auto pour exécuter immédiatement les commandes aws.
NoteLe préfixe personnalisé est appliqué aux noms de rôles de l’opérateur si vous avez spécifié le préfixe à l’étape précédente.
Lorsque vous avez spécifié des chemins ARN personnalisés lorsque vous avez créé les rôles associés à l’ensemble du compte, le chemin personnalisé est automatiquement détecté et appliqué aux rôles d’opérateur.
ImportantLe rôle d’opérateur EBS est requis en plus des rôles de compte pour créer avec succès votre cluster.
Ce rôle doit être associé à la stratégie ManagedOpenShift-openshift-cluster-csi-drivers-ebs-cloud-credentials, une politique IAM requise par ROSA pour gérer le stockage back-end via l’interface de stockage de conteneurs (CSI).
.Exemple rôle d’opérateur EBS "arn:aws:iam::<aws_account_id>:role/<cluster_name>-xxxx-openshift-cluster-csi-drivers-ebs-cloud-credent"
Après avoir créé vos rôles d’opérateur, vous devez modifier la stratégie clé dans la page Services de gestion des clés (KMS) de la console AWS pour ajouter les rôles.
Créer le fournisseur OpenID Connect (OIDC) que les opérateurs de cluster utilisent pour authentifier:
rosa create oidc-provider --mode auto --cluster <cluster_name|cluster_id>
$ rosa create oidc-provider --mode auto --cluster <cluster_name|cluster_id>1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- le mode automatique exécute immédiatement la commande aws CLI qui crée le fournisseur OIDC.
Consultez l’état de votre cluster:
rosa describe cluster --cluster <cluster_name|cluster_id>
$ rosa describe cluster --cluster <cluster_name|cluster_id>Copy to Clipboard Copied! Toggle word wrap Toggle overflow Exemple de sortie
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - L’URL du point de terminaison dépend de la configuration BYO OIDC. Lorsque vous précréez la configuration OIDC, l’URL se termine par la valeur <oidc_config_id>; sinon, l’URL se termine par la valeur <cluster-ID>.
Les changements de champ de l’État ci-après sont énumérés dans la sortie au fur et à mesure que l’installation du cluster progresse:
-
attente (Attendre la configuration OIDC) -
en attente (Préparer le compte) -
installation (configurationDNS en cours) -
installation ♪ prêt ♪NoteEn cas d’échec de l’installation ou que le champ État ne change pas pour être prêt après environ 40 minutes, vérifiez la documentation de dépannage de l’installation pour plus de détails. De plus amples informations sont disponibles sur les installations de dépannage. Les étapes à suivre pour contacter Red Hat Support pour obtenir de l’aide sont disponibles sur AWS.
Faites le suivi de la progression de la création de cluster en regardant les journaux d’installateur OpenShift:
rosa logs install --cluster <cluster_name|cluster_id> --watch
$ rosa logs install --cluster <cluster_name|cluster_id> --watch1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow
2.8. Les prochaines étapes Copier lienLien copié sur presse-papiers!
Chapitre 3. Création d’un cluster ROSA (architecture classique) à l’aide de Terraform Copier lienLien copié sur presse-papiers!
3.1. Création d’un cluster ROSA (architecture classique) par défaut à l’aide de Terraform Copier lienLien copié sur presse-papiers!
Créez rapidement un cluster Red Hat OpenShift Service sur AWS (ROSA) (architecture classique) en utilisant un modèle de cluster Terraform configuré avec les options de cluster par défaut.
Le processus de création de cluster décrit ci-dessous utilise une configuration Terraform qui prépare un cluster ROSA (architecture classique) AWS Security Token Service (STS) avec les ressources suivantes:
- Fournisseur OIDC avec une configuration oidc-config gérée
- Les rôles d’opérateur IAM avec les politiques associées à AWS Managed ROSA
- Les rôles de compte IAM avec AWS Managed ROSA Policys associés
- Les autres ressources AWS nécessaires pour créer un ROSA avec le cluster STS
3.1.1. Aperçu de Terraform Copier lienLien copié sur presse-papiers!
Le terraform est un outil d’infrastructure sous forme de code qui fournit un moyen de configurer vos ressources une fois et de les reproduire au besoin. Le terraform accomplit les tâches de création en utilisant un langage déclaratif. Indiquez ce que vous voulez que l’état final de la ressource d’infrastructure soit, et Terraform crée ces ressources selon vos spécifications.
Conditions préalables
Afin d’utiliser le fournisseur Red Hat Cloud Services dans votre configuration Terraform, vous devez répondre aux conditions préalables suivantes:
- L’outil d’interface de ligne de commande (CLI) de Red Hat OpenShift Service (ROSA) a été installé.
- Il y a votre jeton Red Hat OpenShift Cluster Manager hors ligne.
- La version 1.4.6 ou plus récente de Terraform est installée.
« vous avez créé vos rôles IAM à l’échelle du compte AWS.
Les rôles et politiques IAM spécifiques à l’ensemble du compte fournissent les autorisations STS requises pour le support ROSA, l’installation, le plan de contrôle et la fonctionnalité de calcul. Cela inclut les politiques de l’opérateur à l’échelle du compte. Consultez les ressources supplémentaires pour plus d’informations sur les rôles de compte AWS.
- Il existe un compte AWS et des informations d’identification associées qui vous permettent de créer des ressources. Les informations d’identification sont configurées pour le fournisseur AWS. Consultez la section Authentification et configuration dans la documentation du fournisseur AWS Terraform.
Au minimum, vous disposez des autorisations suivantes dans votre politique de rôle AWS IAM qui exploite Terraform. Consultez ces autorisations dans la console AWS.
Exemple 3.1. Autorisations AWS minimales pour Terraform
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Considérations lors de l’utilisation de Terraform
En général, utiliser Terraform pour gérer les ressources cloud devrait être fait avec l’espoir que tout changement devrait être effectué à l’aide de la méthodologie Terraform. Faites preuve de prudence lors de l’utilisation d’outils en dehors de Terraform, tels que la console AWS ou la console Red Hat, pour modifier les ressources cloud créées par Terraform. En utilisant des outils en dehors de Terraform pour gérer les ressources cloud qui sont déjà gérées par Terraform introduit la dérive de configuration de votre configuration Terraform déclarée.
Ainsi, si vous mettez à niveau votre cluster créé par Terraform en utilisant la console de cloud hybride Red Hat, vous devez réconcilier votre état Terraform avant d’appliquer les modifications de configuration à venir. Consultez Gérer les ressources dans l’état Terraform dans la documentation HashiCorp Developer.
3.1.2. Aperçu des spécifications du cluster par défaut Copier lienLien copié sur presse-papiers!
| Composante | Caractéristiques par défaut |
|---|---|
| Comptes et rôles |
|
| Configurations du cluster |
|
| Chiffrement |
|
| Configuration des nœuds de plan de contrôle |
|
| Configuration des nœuds d’infrastructure |
|
| Calculez la piscine de la machine de nœud |
|
| Configuration du réseau |
|
| Gammes de routage interdomain sans classe (CIDR) |
|
| Les rôles et les politiques des clusters |
|
| La stratégie de mise à jour des clusters |
|
3.1.3. Création d’un cluster ROSA (architecture classique) par défaut à l’aide de Terraform Copier lienLien copié sur presse-papiers!
Le processus de création de cluster décrit ci-dessous montre comment utiliser Terraform pour créer vos rôles IAM à l’échelle du compte et un cluster ROSA (architecture classique) avec une configuration OIDC gérée.
3.1.3.1. La préparation de votre environnement pour Terraform Copier lienLien copié sur presse-papiers!
Avant de pouvoir créer votre service Red Hat OpenShift sur AWS cluster en utilisant Terraform, vous devez exporter votre jeton Red Hat OpenShift Cluster Manager hors ligne.
Procédure
Facultatif: Parce que les fichiers Terraform sont créés dans votre répertoire actuel au cours de cette procédure, vous pouvez créer un nouveau répertoire pour stocker ces fichiers et y naviguer en exécutant la commande suivante:
mkdir terraform-cluster && cd terraform-cluster
$ mkdir terraform-cluster && cd terraform-clusterCopy to Clipboard Copied! Toggle word wrap Toggle overflow - Accordez des autorisations à votre compte en utilisant un jeton Red Hat OpenShift Cluster Manager hors ligne.
Copiez votre jeton hors ligne et définissez le jeton comme variable environnementale en exécutant la commande suivante:
export RHCS_TOKEN=<your_offline_token>
$ export RHCS_TOKEN=<your_offline_token>Copy to Clipboard Copied! Toggle word wrap Toggle overflow NoteCette variable environnementale réinitialise à la fin de chaque session, comme le redémarrage de votre machine ou la fermeture du terminal.
La vérification
Après avoir exporté votre jeton, vérifiez la valeur en exécutant la commande suivante:
echo $RHCS_TOKEN
$ echo $RHCS_TOKENCopy to Clipboard Copied! Toggle word wrap Toggle overflow
3.1.3.2. Créer vos fichiers Terraform localement Copier lienLien copié sur presse-papiers!
Après avoir configuré votre jeton Red Hat OpenShift Cluster Manager hors ligne, vous devez créer les fichiers Terraform localement pour construire votre cluster. Il est possible de créer ces fichiers en utilisant les modèles de code suivants.
Procédure
Créez le fichier main.tf en exécutant la commande suivante:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ≪.> facultatif: Créez un utilisateur administrateur lors de la création de cluster en décommentant les paramètres appropriés et en modifiant leurs valeurs.
Créez le fichier variables.tf en exécutant la commande suivante:
NoteCopiez et modifiez ce fichier avant d’exécuter la commande pour construire votre cluster.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Créez le fichier vpc.tf en exécutant la commande suivante:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow « vous êtes prêt à initier Terraform.
3.1.3.3. En utilisant Terraform pour créer votre cluster ROSA Copier lienLien copié sur presse-papiers!
Après avoir créé les fichiers Terraform, vous devez initier Terraform pour fournir toutes les dépendances requises. Ensuite, appliquez le plan Terraform.
Il ne faut pas modifier les fichiers d’état Terraform. Consultez Considérations lors de l’utilisation de Terraform
Procédure
Configurez Terraform pour créer vos ressources en fonction de vos fichiers Terraform, exécutez la commande suivante:
terraform init
$ terraform initCopy to Clipboard Copied! Toggle word wrap Toggle overflow Facultatif : Vérifiez que le Terraform que vous avez copié est correct en exécutant la commande suivante:
terraform validate
$ terraform validateCopy to Clipboard Copied! Toggle word wrap Toggle overflow Exemple de sortie
Success! The configuration is valid.
Success! The configuration is valid.Copy to Clipboard Copied! Toggle word wrap Toggle overflow Créez votre cluster avec Terraform en exécutant la commande suivante:
terraform apply
$ terraform applyCopy to Clipboard Copied! Toggle word wrap Toggle overflow L’interface Terraform pose deux questions pour créer votre cluster, similaire à ce qui suit:
Exemple de sortie
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Entrez oui pour procéder ou non pour annuler lorsque l’interface Terraform répertorie les ressources à créer ou à modifier et invite à la confirmation:
Exemple de sortie
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Dans l’affirmative, votre plan Terraform démarre, créant vos rôles de compte AWS, vos rôles d’opérateur et votre cluster ROSA Classic.
La vérification
Assurez-vous que votre cluster a été créé en exécutant la commande suivante:
rosa list clusters
$ rosa list clustersCopy to Clipboard Copied! Toggle word wrap Toggle overflow Exemple de sortie montrant l’ID, le nom et l’état d’un cluster
ID NAME STATE TOPOLOGY 27c3snjsupa9obua74ba8se5kcj11269 rosa-tf-demo ready Classic (STS)
ID NAME STATE TOPOLOGY 27c3snjsupa9obua74ba8se5kcj11269 rosa-tf-demo ready Classic (STS)Copy to Clipboard Copied! Toggle word wrap Toggle overflow Assurez-vous que vos rôles de compte ont été créés en exécutant la commande suivante:
rosa list account-roles
$ rosa list account-rolesCopy to Clipboard Copied! Toggle word wrap Toggle overflow Exemple de sortie
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Assurez-vous que vos rôles d’opérateur ont été créés en exécutant la commande suivante:
rosa list operator-roles
$ rosa list operator-rolesCopy to Clipboard Copied! Toggle word wrap Toggle overflow Exemple de sortie montrant les rôles d’opérateur créés par Terraform
I: Fetching operator roles ROLE PREFIX AMOUNT IN BUNDLE rosa-demo 6
I: Fetching operator roles ROLE PREFIX AMOUNT IN BUNDLE rosa-demo 6Copy to Clipboard Copied! Toggle word wrap Toggle overflow
3.1.3.4. La suppression de votre cluster ROSA avec Terraform Copier lienLien copié sur presse-papiers!
La commande terraform destroy permet de supprimer toutes les ressources créées avec la commande terraform application.
Il ne faut pas modifier vos fichiers Terraform .tf avant de détruire vos ressources. Ces variables sont appariées aux ressources à supprimer.
Procédure
Dans le répertoire où vous avez exécuté la commande d’application terraform pour créer votre cluster, exécutez la commande suivante pour supprimer le cluster:
terraform destroy
$ terraform destroyCopy to Clipboard Copied! Toggle word wrap Toggle overflow L’interface Terraform vous invite pour deux variables. Celles-ci doivent correspondre aux réponses que vous avez fournies lors de la création d’un cluster:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Entrez oui pour démarrer la suppression du rôle et du cluster:
Exemple de sortie
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
La vérification
Assurez-vous que votre cluster a été détruit en exécutant la commande suivante:
rosa list clusters
$ rosa list clustersCopy to Clipboard Copied! Toggle word wrap Toggle overflow Exemple de sortie montrant aucun cluster
I: No clusters available
I: No clusters availableCopy to Clipboard Copied! Toggle word wrap Toggle overflow Assurez-vous que les rôles de compte ont été détruits en exécutant la commande suivante:
rosa list account-roles
$ rosa list account-rolesCopy to Clipboard Copied! Toggle word wrap Toggle overflow Exemple de sortie montrant aucun rôle de compte créé par Terraform
I: Fetching account roles I: No account roles available
I: Fetching account roles I: No account roles availableCopy to Clipboard Copied! Toggle word wrap Toggle overflow Assurez-vous que les rôles de l’opérateur ont été détruits en exécutant la commande suivante:
rosa list operator-roles
$ rosa list operator-rolesCopy to Clipboard Copied! Toggle word wrap Toggle overflow Exemple de sortie montrant aucun rôle d’opérateur créé par Terraform
I: Fetching operator roles I: No operator roles available
I: Fetching operator roles I: No operator roles availableCopy to Clipboard Copied! Toggle word wrap Toggle overflow
Chapitre 4. Création de cluster interactif en mode référence Copier lienLien copié sur presse-papiers!
Cette section fournit un aperçu des options qui sont présentées lorsque vous utilisez le mode interactif pour créer le rôle OCM, le rôle utilisateur et Red Hat OpenShift Service sur les clusters AWS (ROSA) en utilisant le ROSA CLI (rosa).
4.1. Des options interactives OCM et de création de rôles d’utilisateur Copier lienLien copié sur presse-papiers!
Avant de pouvoir utiliser Red Hat OpenShift Cluster Manager pour créer Red Hat OpenShift Service sur AWS (ROSA) clusters qui utilisent AWS Security Token Service (STS), vous devez associer votre compte AWS à votre organisation Red Hat en créant et en reliant les rôles OCM et utilisateurs. Activer le mode interactif en spécifiant l’option --interactive lorsque vous exécutez la commande rosa create ocm-role ou la commande rosa Créer un rôle utilisateur.
Les tableaux suivants décrivent les options interactives de création de rôles OCM:
| Le champ | Description |
|---|---|
|
| Indiquez le préfixe à inclure dans le nom de rôle OCM IAM. La valeur par défaut est ManagedOpenShift. Il est possible de créer un seul rôle OCM par compte AWS pour votre organisation Red Hat. |
|
| Activer le rôle OCM IAM admin, ce qui équivaut à spécifier l’argument --admin. Le rôle d’administrateur est requis si vous souhaitez utiliser le mode automatique pour fournir automatiquement les rôles d’opérateur spécifiques au cluster et le fournisseur OIDC en utilisant OpenShift Cluster Manager. |
|
| Indiquez une limite d’autorisations avec Amazon Resource Name (ARN) pour le rôle OCM. Consultez les limites des autorisations pour les entités IAM dans la documentation AWS. |
|
| Indiquez un chemin ARN personnalisé pour votre rôle OCM. Le chemin doit contenir uniquement des caractères alphanumériques et commencer et se terminer par /, par exemple /test/path/dev/. Consultez la personnalisation du chemin ARN pour les rôles et les politiques IAM. |
|
| Choisissez le mode de création de rôles. Le mode automatique permet de créer automatiquement le rôle OCM et de le lier à votre compte d’organisation Red Hat. En mode manuel, le ROSA CLI (rosa) génère les commandes aws nécessaires pour créer et relier le rôle. En mode manuel, les fichiers JSON de stratégie correspondant sont également enregistrés dans le répertoire actuel. le mode manuel vous permet d’examiner les détails avant d’exécuter manuellement les commandes aws. |
|
| Confirmez si vous voulez créer le rôle OCM. |
|
| Confirmez si vous souhaitez lier le rôle d’OCM à votre organisation Red Hat. |
Les tableaux suivants décrivent les options interactives de création de rôles d’utilisateur:
| Le champ | Description |
|---|---|
|
| Indiquez le préfixe à inclure dans le nom du rôle utilisateur. La valeur par défaut est ManagedOpenShift. |
|
| Indiquez une limite d’autorisations pour Amazon Resource Name (ARN) pour le rôle de l’utilisateur. Consultez les limites des autorisations pour les entités IAM dans la documentation AWS. |
|
| Indiquez un chemin ARN personnalisé pour votre rôle d’utilisateur. Le chemin doit contenir uniquement des caractères alphanumériques et commencer et se terminer par /, par exemple /test/path/dev/. Consultez la personnalisation du chemin ARN pour les rôles et les politiques IAM. |
|
| Sélectionne le mode de création de rôles. Le mode automatique permet de créer automatiquement le rôle de l’utilisateur et de le lier à votre compte d’utilisateur OpenShift Cluster Manager. En mode manuel, le ROSA CLI génère les commandes aws nécessaires pour créer et relier le rôle. En mode manuel, les fichiers JSON de stratégie correspondant sont également enregistrés dans le répertoire actuel. le mode manuel vous permet d’examiner les détails avant d’exécuter manuellement les commandes aws. |
|
| Confirmez si vous souhaitez créer le rôle d’utilisateur. |
|
| Confirmez si vous souhaitez lier le rôle d’utilisateur à votre compte d’utilisateur Red Hat. |
4.2. Des options de mode de création de clusters interactifs Copier lienLien copié sur presse-papiers!
En utilisant le mode interactif, vous pouvez créer un service Red Hat OpenShift sur AWS cluster avec AWS Security Token Service (STS). Activez le mode en spécifiant l’option --interactive lorsque vous exécutez la commande rosa create cluster.
Le tableau suivant décrit les options de mode de création de clusters interactifs:
| Le champ | Description |
|---|---|
|
| Entrez un nom pour votre cluster, par exemple my-rosa-cluster. |
|
| Entrez un nom pour le préfixe de domaine pour le sous-domaine de votre cluster, par exemple my-rosa-cluster. |
|
| Activer l’utilisation de plans de contrôle hébergés. |
|
| Créez un utilisateur administrateur local (cluster-admin) pour votre cluster. Cela configure automatiquement un fournisseur d’identité htpasswd pour l’utilisateur cluster-admin. |
|
| Créez un mot de passe personnalisé pour l’utilisateur de cluster-admin, ou utilisez un mot de passe généré par le système. Lorsque vous créez un mot de passe personnalisé, le mot de passe doit être d’au moins 14 caractères (norme CSAII) et ne contient aucun caractère d’espace blanc. Dans le cas où vous ne créez pas de mot de passe personnalisé, le système génère un mot de passe et l’affiche dans la sortie de la ligne de commande. |
|
| Créez un cluster OpenShift qui utilise le service de jetons de sécurité AWS (STS) pour allouer des informations d’identification temporaires et à privilèges limités pour les rôles AWS Identity and Access Management (IAM) spécifiques aux composants. Le service permet aux composants de cluster de faire des appels API AWS en utilisant des pratiques sécurisées de gestion des ressources dans le cloud. La valeur par défaut est Oui. |
|
| Choisissez la version d’OpenShift à installer, par exemple 4. La version par défaut est la dernière version. |
|
| Indiquez si toutes les instances EC2 utiliseront à la fois les points de terminaison v1 et v2 de EC2 Instance Metadata Service (IMDS) (facultatif) ou seulement IMDSv2 (requis). |
|
| Lorsque vous avez plus d’un ensemble de rôles de compte dans votre compte AWS pour la version de votre cluster, une liste de rôles d’installation ARNs sont fournies. Choisissez l’ARN pour le rôle d’installateur que vous souhaitez utiliser avec votre cluster. Le cluster utilise les rôles et les politiques à l’échelle du compte qui se rapportent au rôle d’installateur sélectionné. |
|
| Indiquez un identifiant unique qui est passé par OpenShift Cluster Manager et l’installateur OpenShift lorsqu’un rôle de compte est assumé. Cette option n’est requise que pour les rôles de compte personnalisés qui s’attendent à un identifiant externe. |
|
| Entrez un préfixe à attribuer aux rôles IAM d’opérateur spécifiques au cluster. La valeur par défaut est le nom du cluster et une chaîne aléatoire à 4 chiffres, par exemple my-rosa-cluster-a0b1. |
|
| Indiquez si vous souhaitez utiliser une configuration OIDC préconfigurée ou si vous souhaitez créer une nouvelle configuration OIDC dans le cadre du processus de création de cluster. |
|
| Indiquez une balise utilisée sur toutes les ressources créées par Red Hat OpenShift Service sur AWS dans AWS. Les balises peuvent vous aider à gérer, identifier, organiser, rechercher et filtrer les ressources au sein d’AWS. Les étiquettes sont séparées par virgule, par exemple: "valeur clé, foo bar". Important Le service Red Hat OpenShift sur AWS ne prend en charge que les balises personnalisées des ressources Red Hat OpenShift lors de la création de clusters. Lorsqu’ils ont été ajoutés, les balises ne peuvent pas être supprimées ou modifiées. Les balises ajoutées par Red Hat sont nécessaires pour que les clusters restent en conformité avec les accords de niveau de production de Red Hat (SLA). Ces balises ne doivent pas être supprimées. Le service OpenShift Red Hat sur AWS ne prend pas en charge l’ajout de balises supplémentaires en dehors des ressources gérées par le cluster ROSA. Ces balises peuvent être perdues lorsque les ressources AWS sont gérées par le cluster ROSA. Dans ces cas, vous pourriez avoir besoin de solutions ou d’outils personnalisés pour réconcilier les balises et les garder intactes. |
|
| Déployez le cluster dans plusieurs zones de disponibilité dans la région AWS. La valeur par défaut est Non, ce qui entraîne le déploiement d’un cluster sur une seule zone de disponibilité. Lorsque vous déployez un cluster dans plusieurs zones de disponibilité, la région AWS doit disposer d’au moins 3 zones de disponibilité. Des zones de disponibilité multiples sont recommandées pour les charges de travail de production. |
|
| Indiquez la région AWS pour déployer le cluster. Cela remplace la variable d’environnement AWS_REGION. |
|
| Créez un cluster à l’aide d’AWS PrivateLink. Cette option offre une connectivité privée entre les clouds privés virtuels (VPC), les services AWS et vos réseaux locaux, sans exposer votre trafic à Internet public. Afin de fournir un support, Red Hat Site Reliability Engineering (SRE) peut se connecter au cluster en utilisant les points de terminaison AWS PrivateLink Virtual Private Cloud (VPC). Cette option ne peut pas être modifiée après la création d’un cluster. La valeur par défaut est Non. |
|
| Indiquez la plage d’adresses IP pour les machines (nœuds de cluster), qui doit englober toutes les gammes d’adresses CIDR pour vos sous-réseaux VPC. Les sous-réseaux doivent être contigus. La plage d’adresses IP minimale de 128 adresses, utilisant le préfixe de sous-réseau /25, est prise en charge pour les déploiements de zones de disponibilité uniques. La plage d’adresse minimale de 256 adresses, à l’aide du préfixe de sous-réseau /24, est prise en charge pour les déploiements utilisant plusieurs zones de disponibilité. La valeur par défaut est 10.0.0.0/16. Cette gamme ne doit pas entrer en conflit avec les réseaux connectés. |
|
| Indiquez la plage d’adresses IP pour les services. Il est recommandé, mais pas nécessaire, que le bloc d’adresse soit le même entre les clusters. Cela ne créera pas de conflits d’adresse IP. La gamme doit être suffisamment grande pour s’adapter à votre charge de travail. Le bloc d’adresse ne doit pas se chevaucher avec un service externe accessible depuis le cluster. La valeur par défaut est 172.30.0.0/16. |
|
| Indiquez la plage d’adresse IP pour les pods. Il est recommandé, mais pas nécessaire, que le bloc d’adresse soit le même entre les clusters. Cela ne créera pas de conflits d’adresse IP. La gamme doit être suffisamment grande pour s’adapter à votre charge de travail. Le bloc d’adresse ne doit pas se chevaucher avec un service externe accessible depuis le cluster. La valeur par défaut est 10.128.0.0/14. |
|
| Installez un cluster dans un VPC AWS existant. Afin d’utiliser cette option, votre VPC doit avoir 2 sous-réseaux pour chaque zone de disponibilité dans laquelle vous installez le cluster. La valeur par défaut est Non. |
|
| Indiquez les zones de disponibilité utilisées lors de l’installation dans un VPC AWS existant. Faites appel à une liste séparée par des virgules pour fournir les zones de disponibilité. Dans le cas où vous spécifiez Non, l’installateur sélectionne automatiquement les zones de disponibilité. |
|
| Activer cette option pour utiliser une clé AWS Key Management Service (KMS) spécifique comme clé de chiffrement pour les données persistantes. Cette clé fonctionne comme la clé de chiffrement pour le plan de contrôle, l’infrastructure et les volumes racine des nœuds de travail. La clé est également configurée sur la classe de stockage par défaut pour s’assurer que les volumes persistants créés avec la classe de stockage par défaut seront chiffrés avec la clé KMS spécifique. Lorsqu’elle est désactivée, la clé KMS du compte pour la région spécifiée est utilisée par défaut pour s’assurer que les données persistantes sont toujours cryptées. La valeur par défaut est Non. |
|
| Choisissez un type d’instance de nœud de calcul. La valeur par défaut est m5.xlarge. |
|
| Activer le calcul automatique du nœud. L’autoscaler ajuste la taille du cluster pour répondre à vos demandes de déploiement. La valeur par défaut est Non. |
|
| Choisissez les identifiants de groupe de sécurité personnalisés supplémentaires qui sont utilisés avec le pool de machines standard créé le long du cluster. La valeur par défaut n’est pas sélectionnée. Les groupes de sécurité associés au VPC sélectionné sont affichés. Il est possible de sélectionner un maximum de 5 groupes de sécurité supplémentaires. |
|
| Choisissez les identifiants de groupe de sécurité personnalisés supplémentaires qui sont utilisés avec les nœuds infra créés le long du cluster. La valeur par défaut n’est pas sélectionnée. Les groupes de sécurité associés au VPC sélectionné sont affichés. Il est possible de sélectionner un maximum de 5 groupes de sécurité supplémentaires. |
|
| Choisissez les identifiants de groupe de sécurité personnalisés supplémentaires qui sont utilisés avec les nœuds de plan de contrôle créés le long du cluster. La valeur par défaut n’est pas sélectionnée. Les groupes de sécurité associés au VPC sélectionné sont affichés. Il est possible de sélectionner un maximum de 5 groupes de sécurité supplémentaires. |
|
| Indiquez le nombre de nœuds de calcul à fournir dans chaque zone de disponibilité. Les clusters déployés dans une seule zone de disponibilité nécessitent au moins 2 nœuds. Les clusters déployés dans plusieurs zones doivent avoir au moins 3 nœuds. Le nombre maximum de nœuds ouvriers est de 249 nœuds. La valeur par défaut est 2. |
|
| Indiquez les étiquettes du pool de machines par défaut. Le format de l’étiquette doit être une liste séparée par virgule de paires clés-valeur. Cette liste écrasera les modifications apportées aux étiquettes des nœuds sur une base continue. |
|
| Indiquez la longueur de préfixe du sous-réseau assignée aux pods programmés aux machines individuelles. Le préfixe hôte détermine le pool d’adresses IP pod pour chaque machine. Ainsi, si le préfixe hôte est réglé sur /23, chaque machine se voit attribuer un sous-réseau /23 à partir de la plage d’adresses CIDR pod. La valeur par défaut est /23, permettant 512 nœuds de cluster et 512 pods par nœud, qui sont tous deux au-delà de nos maximums pris en charge. Afin d’obtenir de l’information sur les maximums pris en charge, consultez la section Ressources supplémentaires ci-dessous. |
|
| Indiquez la taille du disque racine du pool machine. Cette valeur doit inclure un suffixe unitaire comme GiB ou TiB, par exemple la valeur par défaut de 300GiB. |
|
| Activer ou désactiver le mode FIPS. La valeur par défaut est fausse (désactivée). Lorsque le mode FIPS est activé, les machines Red Hat Enterprise Linux CoreOS (RHCOS) que Red Hat OpenShift Service sur AWS exécute sur contournent la suite de cryptographie Kubernetes par défaut et utilisent les modules de cryptographie fournis avec RHCOS. Important Afin d’activer le mode FIPS pour votre cluster, vous devez exécuter le programme d’installation à partir d’un ordinateur {op-system-base-full} configuré pour fonctionner en mode FIPS. Afin de plus d’informations sur la configuration du mode FIPS sur {op-system-base}, consultez Switching {op-system-base} en mode FIPS. Lors de l’exécution {op-system-base-full} ou Red Hat Enterprise Linux CoreOS (RHCOS) démarré en mode FIPS, Red Hat OpenShift Service sur les composants de base AWS utilisent les bibliothèques cryptographiques {op-system-base} qui ont été soumises au NIST pour FIPS 140-2/140-3 Validation sur seulement les architectures x86_64, ppc64le et s390x. |
|
| Dans Red Hat OpenShift Service sur AWS, le stockage du plan de contrôle est crypté au repos par défaut et cela inclut le cryptage des volumes etcd. En outre, vous pouvez activer l’option de données cryptées etcd pour chiffrer les valeurs clés de certaines ressources en etcd, mais pas les clés. Important En activant le chiffrement etcd pour les valeurs clés dans etcd, vous subirez un surcharge de performance d’environ 20%. Les frais généraux sont le résultat de l’introduction de cette deuxième couche de chiffrement, en plus du chiffrement de stockage de plan de contrôle par défaut qui crypte les volumes etcd. Le Red Hat vous recommande d’activer le chiffrement etc. uniquement si vous en avez spécifiquement besoin pour votre cas d’utilisation. |
|
| Désactiver la surveillance des projets définis par l’utilisateur. La surveillance des projets définis par l’utilisateur est activée par défaut. |
|
| Indiquez le sélecteur d’itinéraire pour votre entrée. Le format doit être une liste séparée par les virgules de paires clé-valeur. Dans le cas où vous ne spécifiez pas une étiquette, tous les itinéraires seront exposés sur les deux routeurs. Ces étiquettes sont des étiquettes d’inclusion; sinon, elles sont traitées comme des étiquettes d’exclusion. |
|
| Indiquez les espaces de noms exclus pour votre entrée. Le format devrait être une valeur de liste séparée par des virgules1, valeur2…. Dans le cas où vous ne spécifiez pas de valeurs, tous les espaces de noms seront exposés. |
|
| Choisissez la politique de wildcard pour votre entrée. Les options sont WildcardsDisallowed et WildcardsAllowed. La valeur par défaut est WildcardsDisallowed. |
|
| Choisissez la politique de propriété de l’espace de noms pour votre entrée. Les options sont Strict et InterNamespaceAllowed. La valeur par défaut est Strict. |
Chapitre 5. Création d’un cluster AWS PrivateLink sur ROSA Copier lienLien copié sur presse-papiers!
Ce document décrit comment créer un cluster ROSA à l’aide d’AWS PrivateLink.
5.1. Comprendre AWS PrivateLink Copier lienLien copié sur presse-papiers!
Le service OpenShift Red Hat sur AWS peut être créé sans aucune exigence sur les sous-réseaux publics, les passerelles Internet ou les passerelles de traduction d’adresse réseau (NAT). Dans cette configuration, Red Hat utilise AWS PrivateLink pour gérer et surveiller un cluster afin d’éviter tout trafic réseau public. En l’absence d’un sous-réseau public, il n’est pas possible de configurer un routeur d’application comme public. La configuration des routeurs d’application privés est la seule option.
Consultez AWS PrivateLink sur le site AWS pour plus d’informations.
Il n’est possible de créer un cluster PrivateLink qu’au moment de l’installation. Après l’installation, vous ne pouvez pas modifier un cluster en PrivateLink.
5.2. Exigences pour l’utilisation des clusters AWS PrivateLink Copier lienLien copié sur presse-papiers!
Les clusters AWS PrivateLink, les passerelles Internet, les passerelles NAT et les sous-réseaux publics ne sont pas nécessaires, mais les sous-réseaux privés doivent disposer d’une connectivité Internet pour installer les composants requis. Au moins un sous-réseau privé unique est requis pour les clusters Single-AZ et au moins 3 sous-réseaux privés sont requis pour les clusters Multi-AZ. Le tableau suivant montre les ressources AWS nécessaires pour une installation réussie:
| Composante | Le type AWS | Description | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| LE VPC |
| Il faut fournir un VPC pour que le cluster puisse l’utiliser. | ||||||||||||
| Contrôle d’accès réseau |
| Il faut autoriser l’accès aux ports suivants:
| ||||||||||||
| Les sous-réseaux privés |
| Le VPC doit avoir des sous-réseaux privés dans 1 zone de disponibilité pour les déploiements Single-AZ ou 3 zones de disponibilité pour les déploiements Multi-AZ. Il faut fournir des itinéraires et des tableaux d’itinéraires appropriés. |
5.3. Création d’un cluster AWS PrivateLink Copier lienLien copié sur presse-papiers!
Il est possible de créer un cluster AWS PrivateLink à l’aide du service Red Hat OpenShift sur AWS (ROSA) CLI, rosa.
AWS PrivateLink est pris en charge uniquement sur les VPC existants.
Conditions préalables
- Des quotas de service AWS sont disponibles.
- Le service ROSA est activé dans la console AWS.
- Dans votre installation, vous avez installé et configuré le dernier service Red Hat OpenShift sur AWS (ROSA) CLI, rosa.
Procédure
La création d’un cluster peut prendre jusqu’à 40 minutes.
Avec AWS PrivateLink, vous pouvez créer un cluster avec une seule zone de disponibilité (Single-AZ) ou plusieurs zones de disponibilité (Multi-AZ). Dans les deux cas, le routage interdomaine sans classe de votre machine (CIDR) doit correspondre au CIDR de votre cloud privé virtuel. Consultez Exigences pour l’utilisation de votre propre VPC et VPC Validation pour plus d’informations.
ImportantLorsque vous utilisez un pare-feu, vous devez le configurer afin que Red Hat OpenShift Service sur AWS puisse accéder aux sites dont il a besoin pour fonctionner.
Consultez le pare-feu AWS PrivateLink pour plus d’informations.
NoteLorsque le nom de votre cluster est supérieur à 15 caractères, il contiendra un préfixe de domaine généré automatiquement en tant que sous-domaine pour votre cluster fourni sur *.openshiftapps.com.
Afin de personnaliser le sous-domaine, utilisez l’indicateur --domain-prefix. Le préfixe de domaine ne peut pas dépasser 15 caractères, doit être unique et ne peut pas être modifié après la création de clusters.
Créer un cluster Single-AZ:
rosa create cluster --private-link --cluster-name=<cluster-name> [--machine-cidr=<VPC CIDR>/16] --subnet-ids=<private-subnet-id>
$ rosa create cluster --private-link --cluster-name=<cluster-name> [--machine-cidr=<VPC CIDR>/16] --subnet-ids=<private-subnet-id>Copy to Clipboard Copied! Toggle word wrap Toggle overflow Créer un cluster Multi-AZ:
rosa create cluster --private-link --multi-az --cluster-name=<cluster-name> [--machine-cidr=<VPC CIDR>/16] --subnet-ids=<private-subnet-id1>,<private-subnet-id2>,<private-subnet-id3>
$ rosa create cluster --private-link --multi-az --cluster-name=<cluster-name> [--machine-cidr=<VPC CIDR>/16] --subnet-ids=<private-subnet-id1>,<private-subnet-id2>,<private-subnet-id3>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Entrez la commande suivante pour vérifier l’état de votre cluster. Lors de la création de clusters, le champ de l’État à partir de la sortie passera de l’attente à l’installation, et enfin à la préparation.
rosa describe cluster --cluster=<cluster_name>
$ rosa describe cluster --cluster=<cluster_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow NoteEn cas d’échec de l’installation ou que le champ État ne change pas pour être prêt après 40 minutes, vérifiez la documentation de dépannage de l’installation pour plus de détails.
Entrez la commande suivante pour suivre les journaux d’installation OpenShift pour suivre la progression de votre cluster:
rosa logs install --cluster=<cluster_name> --watch
$ rosa logs install --cluster=<cluster_name> --watchCopy to Clipboard Copied! Toggle word wrap Toggle overflow
5.4. Configuration du transfert DNS PrivateLink d’AWS Copier lienLien copié sur presse-papiers!
Avec les clusters AWS PrivateLink, une zone hébergée publique et une zone hébergée privée sont créées dans la Route 53. Avec la zone privée hébergée, les enregistrements à l’intérieur de la zone ne peuvent être résolus qu’à partir du VPC auquel elle est attribuée.
La validation Let's Encrypt DNS-01 nécessite une zone publique afin que des certificats valides et de confiance publique puissent être délivrés pour le domaine. Les enregistrements de validation sont supprimés une fois que la validation Let's Encrypt est terminée; cependant, la zone est toujours nécessaire pour la délivrance et le renouvellement de ces certificats, qui sont généralement requis tous les 60 jours. Bien que ces zones semblent généralement vides, elles jouent un rôle essentiel dans le processus de validation.
Consultez la documentation des zones privées hébergées pour plus d’informations sur les zones hébergées privées. Consultez la documentation des zones hébergées par AWS pour plus d’informations sur les zones hébergées par le public.
Conditions préalables
- Le réseau d’entreprise ou autre VPC dispose d’une connectivité
- Le port UDP 53 et le port TCP 53 ARE activés sur vos réseaux pour permettre des requêtes DNS
- Création d’un cluster AWS PrivateLink à l’aide du service Red Hat OpenShift sur AWS
Procédure
- Afin d’autoriser les enregistrements tels que api.<cluster_domain> et *.apps.<cluster_domain> à résoudre en dehors du VPC, configurez un point d’arrivée de Route 53 Resolver.
- Lorsque vous configurez le point d’extrémité entrant, sélectionnez les sous-réseaux VPC et privés qui ont été utilisés lors de la création du cluster.
- Après que les points de terminaison soient opérationnels et associés, configurez votre réseau d’entreprise pour transférer les requêtes DNS vers ces adresses IP pour le domaine du cluster de premier niveau, tels que drow-pl-01.htno.p1.openshiftapps.com.
- Lorsque vous transmettez des requêtes DNS d’un VPC vers un autre VPC, configurez les règles de transfert.
- Lorsque vous configurez votre serveur DNS réseau distant, consultez la documentation spécifique du serveur DNS pour configurer le transfert DNS sélectif pour le domaine du cluster installé.
5.5. Les prochaines étapes Copier lienLien copié sur presse-papiers!
Chapitre 7. Accéder à un cluster ROSA Copier lienLien copié sur presse-papiers!
Il est recommandé d’accéder à votre cluster Red Hat OpenShift Service sur AWS (ROSA) à l’aide d’un compte de fournisseur d’identité (IDP). Cependant, l’administrateur du cluster qui a créé le cluster peut y accéder en utilisant la procédure d’accès rapide.
Ce document décrit comment accéder à un cluster et configurer un PDI à l’aide du ROSA CLI (rosa). Alternativement, vous pouvez créer un compte IDP à l’aide de la console OpenShift Cluster Manager.
7.1. Accéder à votre cluster rapidement Copier lienLien copié sur presse-papiers!
Cette procédure d’accès rapide vous permet de vous connecter à votre cluster.
En tant que meilleure pratique, accédez à votre cluster avec un compte IDP à la place.
Procédure
Entrez la commande suivante:
rosa create admin --cluster=<cluster_name>
$ rosa create admin --cluster=<cluster_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow Exemple de sortie
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Dans le cas d’un Red Hat OpenShift Service sur AWS (ROSA) doté d’un cluster de plans de contrôle hébergés (HCP), le numéro de port devrait être de 443.
Entrez la commande oc login, nom d’utilisateur et mot de passe à partir de la sortie de la commande précédente:
Exemple de sortie
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Dans le cas d’un ROSA doté d’un cluster HCP, le numéro de port devrait être de 443.
À l’aide du projet par défaut, entrez cette commande oc pour vérifier que l’accès administrateur de cluster est créé:
oc whoami
$ oc whoamiCopy to Clipboard Copied! Toggle word wrap Toggle overflow Exemple de sortie
cluster-admin
cluster-adminCopy to Clipboard Copied! Toggle word wrap Toggle overflow
7.2. Accéder à votre cluster avec un compte IDP Copier lienLien copié sur presse-papiers!
Afin de vous connecter à votre cluster, vous pouvez configurer un fournisseur d’identité (IDP). Cette procédure utilise GitHub comme exemple de PDI. Afin d’afficher d’autres IDP pris en charge, exécutez la commande rosa create idp --help.
Alternativement, en tant qu’utilisateur qui a créé le cluster, vous pouvez utiliser la procédure d’accès rapide.
Procédure
Accéder à votre cluster à l’aide d’un compte IDP:
Ajoutez une PDI.
La commande suivante crée un IDP soutenu par GitHub. Après avoir exécuté la commande, suivez les instructions interactives de la sortie pour accéder aux paramètres de votre développeur GitHub et configurer une nouvelle application OAuth.
rosa create idp --cluster=<cluster_name> --interactive
$ rosa create idp --cluster=<cluster_name> --interactiveCopy to Clipboard Copied! Toggle word wrap Toggle overflow Entrez les valeurs suivantes:
- Le type de fournisseur d’identité: github
- Limiter les membres des organisations (si vous n’avez pas d’organisation GitHub, vous pouvez en créer une maintenant)
- GitHub organisations: rh-test-org (entrer le nom de votre organisation)
Exemple de sortie
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Suivez l’URL dans la sortie et sélectionnez Enregistrer l’application pour enregistrer une nouvelle application OAuth dans votre organisation GitHub. En enregistrant l’application, vous activez le serveur OAuth intégré dans ROSA pour authentifier les membres de votre organisation GitHub dans votre cluster.
NoteLes champs du formulaire Enregistrer une nouvelle application OAuth GitHub sont automatiquement remplis avec les valeurs requises via l’URL définie par le service Red Hat OpenShift sur AWS (ROSA) CLI, rosa.
Consultez les informations de l’application GitHub que vous avez créée et continuez les instructions. Entrez les valeurs suivantes:
- Identifiant client: <my_github_client_id>
- Client Secret: [? pour l’aide] <my_github_client_secret>
- Hostname: (facultatif, vous pouvez le laisser vide pour l’instant)
- La méthode de cartographie: revendication
Exemple continu de sortie
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Le PDI peut prendre 1-2 minutes pour être configuré dans votre cluster.
Entrez la commande suivante pour vérifier que votre PDI a été configuré correctement:
rosa list idps --cluster=<cluster_name>
$ rosa list idps --cluster=<cluster_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow Exemple de sortie
NAME TYPE AUTH URL github-1 GitHub https://oauth-openshift.apps.rh-rosa-test-cluster1.j9n4.s1.devshift.org/oauth2callback/github-1
NAME TYPE AUTH URL github-1 GitHub https://oauth-openshift.apps.rh-rosa-test-cluster1.j9n4.s1.devshift.org/oauth2callback/github-1Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Connectez-vous à votre cluster.
Entrez la commande suivante pour obtenir l’URL de la console de votre cluster:
rosa describe cluster --cluster=<cluster_name>
$ rosa describe cluster --cluster=<cluster_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow Exemple de sortie
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Dans le cas d’un Red Hat OpenShift Service sur AWS (ROSA) doté d’un cluster de plans de contrôle hébergés (HCP), le numéro de port devrait être de 443.
- Accédez à l’URL de la console et connectez-vous à l’aide de vos identifiants Github.
- En haut à droite de la console OpenShift, cliquez sur votre nom et cliquez sur Copier la commande de connexion.
- Choisissez le nom du PDI que vous avez ajouté (dans notre cas github-1), puis cliquez sur Affichage du jeton.
Copiez et collez la commande oc login dans votre terminal.
oc login --token=z3sgOGVDk0k4vbqo_wFqBQQTnT-nA-nQLb8XEmWnw4X --server=https://api.rh-rosa-test-cluster1.j9n4.s1.devshift.org:6443
$ oc login --token=z3sgOGVDk0k4vbqo_wFqBQQTnT-nA-nQLb8XEmWnw4X --server=https://api.rh-rosa-test-cluster1.j9n4.s1.devshift.org:64431 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Dans le cas d’un ROSA avec cluster HCP, utilisez le numéro de port 443.
Exemple de sortie
Logged into "https://api.rh-rosa-cluster1.j9n4.s1.devshift.org:6443" as "rh-rosa-test-user" using the token provided. You have access to 67 projects, the list has been suppressed. You can list all projects with 'oc projects' Using project "default".
Logged into "https://api.rh-rosa-cluster1.j9n4.s1.devshift.org:6443" as "rh-rosa-test-user" using the token provided.1 You have access to 67 projects, the list has been suppressed. You can list all projects with 'oc projects' Using project "default".Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Dans le cas d’un ROSA doté d’un cluster HCP, le numéro de port devrait être de 443.
Entrez une commande oc simple pour vérifier que tout est configuré correctement et que vous êtes connecté.
oc version
$ oc versionCopy to Clipboard Copied! Toggle word wrap Toggle overflow Exemple de sortie
Client Version: 4.4.0-202005231254-4a4cd75 Server Version: 4.3.18 Kubernetes Version: v1.16.2
Client Version: 4.4.0-202005231254-4a4cd75 Server Version: 4.3.18 Kubernetes Version: v1.16.2Copy to Clipboard Copied! Toggle word wrap Toggle overflow
7.3. Octroi d’un accès cluster-admin Copier lienLien copié sur presse-papiers!
En tant qu’utilisateur qui a créé le cluster, ajoutez le rôle d’utilisateur cluster-admin à votre compte pour obtenir le maximum de privilèges d’administrateur. Ces privilèges ne sont pas automatiquement attribués à votre compte utilisateur lorsque vous créez le cluster.
En outre, seul l’utilisateur qui a créé le cluster peut accorder un accès en cluster à d’autres utilisateurs de cluster-admin ou dédié-admin. Les utilisateurs disposant d’un accès admin dédié ont moins de privilèges. En tant que meilleure pratique, limiter le nombre d’utilisateurs de cluster-admin au plus petit nombre possible.
Conditions préalables
- Dans votre cluster, vous avez ajouté un fournisseur d’identité (IDP).
- Il y a le nom d’utilisateur IDP pour l’utilisateur que vous créez.
- Il est connecté au cluster.
Procédure
Donnez à votre utilisateur cluster-admin privilèges:
rosa grant user cluster-admin --user=<idp_user_name> --cluster=<cluster_name>
$ rosa grant user cluster-admin --user=<idp_user_name> --cluster=<cluster_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow Assurez-vous que votre utilisateur est listé en tant qu’administrateur de cluster:
rosa list users --cluster=<cluster_name>
$ rosa list users --cluster=<cluster_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow Exemple de sortie
GROUP NAME cluster-admins rh-rosa-test-user dedicated-admins rh-rosa-test-user
GROUP NAME cluster-admins rh-rosa-test-user dedicated-admins rh-rosa-test-userCopy to Clipboard Copied! Toggle word wrap Toggle overflow Entrez la commande suivante pour vérifier que votre utilisateur dispose désormais d’un accès cluster-admin. L’administrateur de cluster peut exécuter cette commande sans erreurs, mais un administrateur dédié ne peut pas exécuter cette commande.
oc get all -n openshift-apiserver
$ oc get all -n openshift-apiserverCopy to Clipboard Copied! Toggle word wrap Toggle overflow Exemple de sortie
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
7.4. Octroi d’un accès admin dédié Copier lienLien copié sur presse-papiers!
Il n’y a que l’utilisateur qui a créé le cluster qui peut accorder l’accès au cluster à d’autres utilisateurs de cluster-admin ou dédié-admin. Les utilisateurs disposant d’un accès admin dédié ont moins de privilèges. En tant que meilleure pratique, accordez un accès administrateur dédié à la plupart de vos administrateurs.
Conditions préalables
- Dans votre cluster, vous avez ajouté un fournisseur d’identité (IDP).
- Il y a le nom d’utilisateur IDP pour l’utilisateur que vous créez.
- Il est connecté au cluster.
Procédure
Entrez la commande suivante pour promouvoir votre utilisateur à un administrateur dédié:
rosa grant user dedicated-admin --user=<idp_user_name> --cluster=<cluster_name>
$ rosa grant user dedicated-admin --user=<idp_user_name> --cluster=<cluster_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow Entrez la commande suivante pour vérifier que votre utilisateur dispose désormais d’un accès admin dédié:
oc get groups dedicated-admins
$ oc get groups dedicated-adminsCopy to Clipboard Copied! Toggle word wrap Toggle overflow Exemple de sortie
NAME USERS dedicated-admins rh-rosa-test-user
NAME USERS dedicated-admins rh-rosa-test-userCopy to Clipboard Copied! Toggle word wrap Toggle overflow NoteL’erreur interdite s’affiche si l’utilisateur sans privilèges d’administration dédié exécute cette commande.
Chapitre 8. Configuration des fournisseurs d’identité pour STS Copier lienLien copié sur presse-papiers!
Après la création de votre cluster Red Hat OpenShift Service sur AWS (ROSA), vous devez configurer les fournisseurs d’identité pour déterminer comment les utilisateurs se connectent pour accéder au cluster.
Les sujets suivants décrivent comment configurer un fournisseur d’identité à l’aide de la console OpenShift Cluster Manager. Alternativement, vous pouvez utiliser le ROSA CLI (rosa) pour configurer un fournisseur d’identité et accéder au cluster.
8.1. Comprendre les fournisseurs d’identité Copier lienLien copié sur presse-papiers!
Le service Red Hat OpenShift sur AWS inclut un serveur OAuth intégré. Les développeurs et les administrateurs obtiennent des jetons d’accès OAuth pour s’authentifier à l’API. En tant qu’administrateur, vous pouvez configurer OAuth pour spécifier un fournisseur d’identité après avoir installé votre cluster. La configuration des fournisseurs d’identité permet aux utilisateurs de se connecter et d’accéder au cluster.
8.1.1. Fournisseurs d’identité pris en charge Copier lienLien copié sur presse-papiers!
Les types de fournisseurs d’identité suivants peuvent être configurés:
| Fournisseur d’identité | Description |
|---|---|
| GitHub ou GitHub Enterprise | Configurez un fournisseur d’identité GitHub pour valider les noms d’utilisateur et les mots de passe contre le serveur d’authentification OAuth de GitHub ou GitHub Enterprise. |
| GitLab | Configurez un fournisseur d’identité GitLab pour utiliser GitLab.com ou toute autre instance GitLab en tant que fournisseur d’identité. |
| | Configurez un fournisseur d’identité Google en utilisant l’intégration OpenID Connect de Google. |
| LDAP | Configurez un fournisseur d’identité LDAP pour valider les noms d’utilisateur et les mots de passe contre un serveur LDAPv3, en utilisant une simple authentification de liaison. |
| Connexion d’OpenID | Configurez un fournisseur d’identité OpenID Connect (OIDC) pour s’intégrer à un fournisseur d’identité OIDC à l’aide d’un flux de code d’autorisation. |
| htpasswd | Configurez un fournisseur d’identité htpasswd pour un seul utilisateur d’administration statique. En tant qu’utilisateur, vous pouvez vous connecter au cluster pour résoudre les problèmes. Important L’option fournisseur d’identité htpasswd n’est incluse que pour activer la création d’un seul utilisateur d’administration statique. htpasswd n’est pas pris en charge en tant que fournisseur d’identité à usage général pour Red Hat OpenShift Service sur AWS. Les étapes pour configurer l’utilisateur unique, voir Configuration d’un fournisseur d’identité htpasswd. |
8.1.2. Les paramètres du fournisseur d’identité Copier lienLien copié sur presse-papiers!
Les paramètres suivants sont communs à tous les fournisseurs d’identité:
| Le paramètre | Description |
|---|---|
|
| Le nom du fournisseur est préfixé aux noms d’utilisateur du fournisseur pour former un nom d’identité. |
|
| Définit comment les nouvelles identités sont cartographiées aux utilisateurs lorsqu’ils se connectent. Entrez l’une des valeurs suivantes:
|
Lorsque vous ajoutez ou modifiez des fournisseurs d’identité, vous pouvez cartographier les identités du nouveau fournisseur aux utilisateurs existants en définissant le paramètre mappingMethod à ajouter.
8.2. Configuration d’un fournisseur d’identité GitHub Copier lienLien copié sur presse-papiers!
Configurez un fournisseur d’identité GitHub pour valider les noms d’utilisateur et les mots de passe contre le serveur d’authentification OAuth de GitHub ou GitHub Enterprise et accédez à votre service Red Hat OpenShift sur le cluster AWS. Il facilite un flux d’échange de jetons entre Red Hat OpenShift Service sur AWS et GitHub ou GitHub Enterprise.
La configuration de l’authentification GitHub permet aux utilisateurs de se connecter à Red Hat OpenShift Service sur AWS avec leurs identifiants GitHub. Afin d’empêcher toute personne disposant d’un identifiant utilisateur GitHub de se connecter à votre Red Hat OpenShift Service sur le cluster AWS, vous devez restreindre l’accès à ceux qui se trouvent dans des organisations ou des équipes GitHub spécifiques.
Conditions préalables
- L’application OAuth doit être créée directement dans les paramètres d’organisation GitHub par l’administrateur de l’organisation GitHub.
- Les organisations ou les équipes GitHub sont configurées dans votre compte GitHub.
Procédure
- À partir d’OpenShift Cluster Manager, accédez à la page Liste des clusters et sélectionnez le cluster pour lequel vous devez configurer les fournisseurs d’identité.
- Cliquez sur l’onglet Contrôle d’accès.
Cliquez sur Ajouter un fournisseur d’identité.
NoteIl est également possible de cliquer sur le lien de configuration Ajouter Oauth dans le message d’avertissement affiché après la création du cluster pour configurer vos fournisseurs d’identité.
- Choisissez GitHub dans le menu déroulant.
Entrez un nom unique pour le fournisseur d’identité. Ce nom ne peut pas être changé plus tard.
L’URL de rappel OAuth est automatiquement générée dans le champ fourni. Ceci vous permettra d’enregistrer l’application GitHub.
https://oauth-openshift.apps.<cluster_name>.<cluster_domain>/oauth2callback/<idp_provider_name>
https://oauth-openshift.apps.<cluster_name>.<cluster_domain>/oauth2callback/<idp_provider_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow À titre d’exemple:
https://oauth-openshift.apps.openshift-cluster.example.com/oauth2callback/github
https://oauth-openshift.apps.openshift-cluster.example.com/oauth2callback/githubCopy to Clipboard Copied! Toggle word wrap Toggle overflow
- Enregistrez une demande sur GitHub.
- De retour à Red Hat OpenShift Service sur AWS et sélectionnez une méthode de cartographie dans le menu déroulant. La réclamation est recommandée dans la plupart des cas.
- Entrez l’ID Client et le secret du client fournis par GitHub.
- Entrez un nom d’hôte. Le nom d’hôte doit être saisi lors de l’utilisation d’une instance hébergée de GitHub Enterprise.
- Facultatif : Vous pouvez utiliser un fichier d’autorité de certification (CA) pour valider les certificats de serveur pour l’URL GitHub Enterprise configurée. Cliquez sur Parcourir pour localiser et joindre un fichier CA au fournisseur d’identité.
- Choisissez Utilisez des organisations ou Utilisez les équipes pour restreindre l’accès à une organisation GitHub particulière ou à une équipe GitHub.
- Entrez le nom de l’organisation ou de l’équipe à laquelle vous souhaitez restreindre l’accès. Cliquez sur Ajouter plus pour spécifier plusieurs organisations ou équipes dont les utilisateurs peuvent être membres.
- Cliquez sur Confirmer.
La vérification
- Le fournisseur d’identité configuré est maintenant visible dans l’onglet Contrôle d’accès de la page Liste des clusters.
8.3. Configuration d’un fournisseur d’identité GitLab Copier lienLien copié sur presse-papiers!
Configurez un fournisseur d’identité GitLab pour utiliser GitLab.com ou toute autre instance GitLab en tant que fournisseur d’identité.
Conditions préalables
- Lorsque vous utilisez la version 7.7.0 à 11.0 de GitLab, vous vous connectez à l’intégration OAuth. En utilisant la version 11.1 ou ultérieure de GitLab, vous pouvez utiliser OpenID Connect (OIDC) pour vous connecter au lieu d’OAuth.
Procédure
- À partir d’OpenShift Cluster Manager, accédez à la page Liste des clusters et sélectionnez le cluster pour lequel vous devez configurer les fournisseurs d’identité.
- Cliquez sur l’onglet Contrôle d’accès.
Cliquez sur Ajouter un fournisseur d’identité.
NoteIl est également possible de cliquer sur le lien de configuration Ajouter Oauth dans le message d’avertissement affiché après la création du cluster pour configurer vos fournisseurs d’identité.
- Choisissez GitLab dans le menu déroulant.
Entrez un nom unique pour le fournisseur d’identité. Ce nom ne peut pas être changé plus tard.
L’URL de rappel OAuth est automatiquement générée dans le champ fourni. Cette URL est fournie à GitLab.
https://oauth-openshift.apps.<cluster_name>.<cluster_domain>/oauth2callback/<idp_provider_name>
https://oauth-openshift.apps.<cluster_name>.<cluster_domain>/oauth2callback/<idp_provider_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow À titre d’exemple:
https://oauth-openshift.apps.openshift-cluster.example.com/oauth2callback/gitlab
https://oauth-openshift.apps.openshift-cluster.example.com/oauth2callback/gitlabCopy to Clipboard Copied! Toggle word wrap Toggle overflow
- Ajouter une nouvelle application dans GitLab.
- De retour à Red Hat OpenShift Service sur AWS et sélectionnez une méthode de cartographie dans le menu déroulant. La réclamation est recommandée dans la plupart des cas.
- Entrez l’ID Client et le secret client fournis par GitLab.
- Entrez l’URL de votre fournisseur GitLab.
- Facultatif : Vous pouvez utiliser un fichier d’autorité de certification (CA) pour valider les certificats de serveur pour l’URL GitLab configurée. Cliquez sur Parcourir pour localiser et joindre un fichier CA au fournisseur d’identité.
- Cliquez sur Confirmer.
La vérification
- Le fournisseur d’identité configuré est maintenant visible dans l’onglet Contrôle d’accès de la page Liste des clusters.
8.4. Configuration d’un fournisseur d’identité Google Copier lienLien copié sur presse-papiers!
Configurez un fournisseur d’identité Google pour permettre aux utilisateurs de s’authentifier avec leurs identifiants Google.
L’utilisation de Google comme fournisseur d’identité permet à tout utilisateur de Google de s’authentifier auprès de votre serveur. Il est possible de limiter l’authentification aux membres d’un domaine hébergé spécifique avec l’attribut de configuration hostDomain.
Procédure
- À partir d’OpenShift Cluster Manager, accédez à la page Liste des clusters et sélectionnez le cluster pour lequel vous devez configurer les fournisseurs d’identité.
- Cliquez sur l’onglet Contrôle d’accès.
Cliquez sur Ajouter un fournisseur d’identité.
NoteIl est également possible de cliquer sur le lien de configuration Ajouter Oauth dans le message d’avertissement affiché après la création du cluster pour configurer vos fournisseurs d’identité.
- Choisissez Google dans le menu déroulant.
Entrez un nom unique pour le fournisseur d’identité. Ce nom ne peut pas être changé plus tard.
L’URL de rappel OAuth est automatiquement générée dans le champ fourni. Cette URL sera fournie à Google.
https://oauth-openshift.apps.<cluster_name>.<cluster_domain>/oauth2callback/<idp_provider_name>
https://oauth-openshift.apps.<cluster_name>.<cluster_domain>/oauth2callback/<idp_provider_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow À titre d’exemple:
https://oauth-openshift.apps.openshift-cluster.example.com/oauth2callback/google
https://oauth-openshift.apps.openshift-cluster.example.com/oauth2callback/googleCopy to Clipboard Copied! Toggle word wrap Toggle overflow
- Configurez un fournisseur d’identité Google en utilisant l’intégration OpenID Connect de Google.
- De retour à Red Hat OpenShift Service sur AWS et sélectionnez une méthode de cartographie dans le menu déroulant. La réclamation est recommandée dans la plupart des cas.
- Entrez l’ID Client d’un projet Google enregistré et le secret client émis par Google.
- Entrez un domaine hébergé pour restreindre les utilisateurs à un domaine Google Apps.
- Cliquez sur Confirmer.
La vérification
- Le fournisseur d’identité configuré est maintenant visible dans l’onglet Contrôle d’accès de la page Liste des clusters.
8.5. Configuration d’un fournisseur d’identité LDAP Copier lienLien copié sur presse-papiers!
Configurez le fournisseur d’identité LDAP pour valider les noms d’utilisateur et les mots de passe contre un serveur LDAPv3, en utilisant une simple authentification de liaison.
Conditions préalables
Lorsque vous configurez un fournisseur d’identité LDAP, vous devrez entrer une URL LDAP configurée. L’URL configurée est une URL RFC 2255, qui spécifie l’hôte LDAP et les paramètres de recherche à utiliser. La syntaxe de l’URL est:
ldap://host:port/basedn?attribute?scope?filter
ldap://host:port/basedn?attribute?scope?filterCopy to Clipboard Copied! Toggle word wrap Toggle overflow Expand Composant URL Description LDAPDans le cas d’un LDAP régulier, utilisez la corde ldap. Dans le cas d’un LDAP sécurisé (LDAPS), utilisez plutôt ldaps.
hôte:portLe nom et le port du serveur LDAP. Défaut à localhost:389 pour ldap et localhost:636 pour LDAPS.
baseDNLe DN de la branche du répertoire où toutes les recherches devraient commencer. À tout le moins, cela doit être le haut de votre arbre de répertoire, mais il pourrait également spécifier un sous-arbre dans le répertoire.
attributL’attribut à rechercher. Bien que la RFC 2255 autorise une liste d’attributs séparés par des virgules, seul le premier attribut sera utilisé, peu importe le nombre d’attributs fournis. En l’absence d’attributs, la valeur par défaut est d’utiliser uid. Il est recommandé de choisir un attribut qui sera unique dans toutes les entrées dans le sous-arbre que vous utiliserez.
champ d’applicationLa portée de la recherche. Il peut être un ou sous. Dans le cas où la portée n’est pas fournie, la valeur par défaut est d’utiliser une portée de sub.
filtrerFiltre de recherche LDAP valide. Dans le cas contraire, par défaut (objectClass=*)
Lorsque vous effectuez des recherches, l’attribut, le filtre et le nom d’utilisateur fourni sont combinés pour créer un filtre de recherche qui ressemble à:
(&(<filter>)(<attribute>=<username>))
(&(<filter>)(<attribute>=<username>))Copy to Clipboard Copied! Toggle word wrap Toggle overflow ImportantLorsque le répertoire LDAP nécessite une authentification pour rechercher, spécifiez un bindDN et bindPassword à utiliser pour effectuer la recherche d’entrée.
Procédure
- À partir d’OpenShift Cluster Manager, accédez à la page Liste des clusters et sélectionnez le cluster pour lequel vous devez configurer les fournisseurs d’identité.
- Cliquez sur l’onglet Contrôle d’accès.
Cliquez sur Ajouter un fournisseur d’identité.
NoteIl est également possible de cliquer sur le lien de configuration Ajouter Oauth dans le message d’avertissement affiché après la création du cluster pour configurer vos fournisseurs d’identité.
- Choisissez LDAP dans le menu déroulant.
- Entrez un nom unique pour le fournisseur d’identité. Ce nom ne peut pas être changé plus tard.
- Choisissez une méthode de cartographie dans le menu déroulant. La réclamation est recommandée dans la plupart des cas.
- Entrez une URL LDAP pour spécifier les paramètres de recherche LDAP à utiliser.
- Facultatif: Entrez un mot de passe Bind DN et Bind.
Entrez les attributs qui mapperont les attributs LDAP aux identités.
- Entrez un attribut ID dont la valeur doit être utilisée comme ID utilisateur. Cliquez sur Ajouter plus pour ajouter plusieurs attributs d’identification.
- Facultatif: Entrez un attribut de nom d’utilisateur préféré dont la valeur doit être utilisée comme nom d’affichage. Cliquez sur Ajouter plus pour ajouter plusieurs attributs de nom d’utilisateur préférés.
- Facultatif: Entrez un attribut Email dont la valeur doit être utilisée comme adresse e-mail. Cliquez sur Ajouter plus pour ajouter plusieurs attributs de messagerie.
- Facultatif: Cliquez sur Afficher les options avancées pour ajouter un fichier d’autorité de certificat (CA) à votre fournisseur d’identité LDAP pour valider les certificats de serveur pour l’URL configurée. Cliquez sur Parcourir pour localiser et joindre un fichier CA au fournisseur d’identité.
Facultatif: Dans le cadre des options avancées, vous pouvez choisir de rendre le fournisseur LDAP non sécurisé. Dans le cas où vous sélectionnez cette option, un fichier CA ne peut pas être utilisé.
ImportantLorsque vous utilisez une connexion LDAP non sécurisée (ldap:/ ou port 389), vous devez vérifier l’option Insecure dans l’assistant de configuration.
- Cliquez sur Confirmer.
La vérification
- Le fournisseur d’identité configuré est maintenant visible dans l’onglet Contrôle d’accès de la page Liste des clusters.
8.6. Configuration d’un fournisseur d’identité OpenID Copier lienLien copié sur presse-papiers!
Configurez un fournisseur d’identité OpenID pour s’intégrer à un fournisseur d’identité OpenID Connect à l’aide d’un flux de code d’autorisation.
L’opérateur d’authentification dans Red Hat OpenShift Service sur AWS nécessite que le fournisseur d’identité OpenID Connect configuré implémente la spécification OpenID Connect Discovery.
Les réclamations sont lues à partir du JWT id_token retourné par le fournisseur d’identité OpenID et, si spécifié, à partir du JSON retourné par l’URL de l’émetteur.
Au moins une revendication doit être configurée pour être utilisée comme identité de l’utilisateur.
Il est également possible d’indiquer les revendications à utiliser comme nom d’utilisateur, nom d’affichage et adresse e-mail préférés de l’utilisateur. Lorsque plusieurs revendications sont spécifiées, la première avec une valeur non vide est utilisée. Les revendications standard sont les suivantes:
| Demande d ' indemnisation | Description |
|---|---|
|
| Le nom d’utilisateur préféré lors du provisionnement d’un utilisateur. C’est un nom abrégé que l’utilisateur veut appeler, tel que janedoe. Généralement une valeur correspondant au nom d’utilisateur ou au nom d’utilisateur dans le système d’authentification, tel que le nom d’utilisateur ou l’email. |
|
| Adresse e-mail. |
|
| Afficher le nom. |
Consultez la documentation sur les demandes OpenID pour plus d’informations.
Conditions préalables
- Avant de configurer OpenID Connect, vérifiez les prérequis d’installation pour tout produit ou service Red Hat que vous souhaitez utiliser avec votre service Red Hat OpenShift sur AWS cluster.
Procédure
- À partir d’OpenShift Cluster Manager, accédez à la page Liste des clusters et sélectionnez le cluster pour lequel vous devez configurer les fournisseurs d’identité.
- Cliquez sur l’onglet Contrôle d’accès.
Cliquez sur Ajouter un fournisseur d’identité.
NoteIl est également possible de cliquer sur le lien de configuration Ajouter Oauth dans le message d’avertissement affiché après la création du cluster pour configurer vos fournisseurs d’identité.
- Choisissez OpenID dans le menu déroulant.
Entrez un nom unique pour le fournisseur d’identité. Ce nom ne peut pas être changé plus tard.
L’URL de rappel OAuth est automatiquement générée dans le champ fourni.
https://oauth-openshift.apps.<cluster_name>.<cluster_domain>/oauth2callback/<idp_provider_name>
https://oauth-openshift.apps.<cluster_name>.<cluster_domain>/oauth2callback/<idp_provider_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow À titre d’exemple:
https://oauth-openshift.apps.openshift-cluster.example.com/oauth2callback/openid
https://oauth-openshift.apps.openshift-cluster.example.com/oauth2callback/openidCopy to Clipboard Copied! Toggle word wrap Toggle overflow
- Enregistrez un nouveau client OpenID Connect dans le fournisseur d’identité OpenID en suivant les étapes pour créer une demande d’autorisation.
- De retour à Red Hat OpenShift Service sur AWS et sélectionnez une méthode de cartographie dans le menu déroulant. La réclamation est recommandée dans la plupart des cas.
- Entrez un identifiant client et un secret client fourni à partir d’OpenID.
- Entrez une URL de l’émetteur. C’est l’URL que le fournisseur OpenID affirme comme l’identifiant de l’émetteur. Il doit utiliser le schéma https sans paramètres de requête d’URL ou fragments.
- Entrez un attribut Email dont la valeur doit être utilisée comme adresse e-mail. Cliquez sur Ajouter plus pour ajouter plusieurs attributs de messagerie.
- Entrez un attribut Nom dont la valeur doit être utilisée comme nom d’utilisateur préféré. Cliquez sur Ajouter plus pour ajouter plusieurs noms d’utilisateur préférés.
- Entrez un attribut de nom d’utilisateur préféré dont la valeur doit être utilisée comme nom d’affichage. Cliquez sur Ajouter plus pour ajouter plusieurs noms d’affichage.
- Facultatif: Cliquez sur Afficher les options avancées pour ajouter un fichier d’autorité de certificat (CA) à votre fournisseur d’identité OpenID.
- Facultatif: Sous les options avancées, vous pouvez ajouter des zones supplémentaires. La portée OpenID est demandée par défaut.
- Cliquez sur Confirmer.
La vérification
- Le fournisseur d’identité configuré est maintenant visible dans l’onglet Contrôle d’accès de la page Liste des clusters.
8.7. Configuration d’un fournisseur d’identité htpasswd Copier lienLien copié sur presse-papiers!
Configurez un fournisseur d’identité htpasswd pour créer un seul utilisateur statique avec des privilèges d’administration de clusters. Connectez-vous à votre cluster en tant qu’utilisateur pour résoudre les problèmes.
L’option fournisseur d’identité htpasswd n’est incluse que pour activer la création d’un seul utilisateur d’administration statique. htpasswd n’est pas pris en charge en tant que fournisseur d’identité à usage général pour Red Hat OpenShift Service sur AWS.
Procédure
- À partir d’OpenShift Cluster Manager, accédez à la page Liste des clusters et sélectionnez votre cluster.
- Choisissez Contrôle d’accès → Fournisseurs d’identité.
- Cliquez sur Ajouter un fournisseur d’identité.
- Choisissez HTPasswd dans le menu déroulant fournisseur d’identité.
- Ajoutez un nom unique dans le champ Nom du fournisseur d’identité.
Utilisez le nom d’utilisateur et le mot de passe suggérés pour l’utilisateur statique, ou créez le vôtre.
NoteLes informations d’identification définies dans cette étape ne sont pas visibles après avoir sélectionné Ajouter à l’étape suivante. Lorsque vous perdez les informations d’identification, vous devez recréer le fournisseur d’identité et définir à nouveau les informations d’identification.
- Cliquez sur Ajouter pour créer le fournisseur d’identité htpasswd et l’utilisateur unique et statique.
Accordez l’autorisation de l’utilisateur statique pour gérer le cluster:
- Dans Contrôle d’accès → Rôles de cluster et Accès, sélectionnez Ajouter un utilisateur.
- Entrez l’identifiant utilisateur de l’utilisateur statique que vous avez créé à l’étape précédente.
- Choisissez un groupe. Les utilisateurs du groupe admins dédiés ont des privilèges administratifs standard pour Red Hat OpenShift Service sur AWS. Les utilisateurs du groupe cluster-administrations ont un accès administratif complet au cluster.
- Choisissez Ajouter un utilisateur pour accorder les privilèges d’administration à l’utilisateur.
La vérification
Le fournisseur d’identité htpasswd configuré est visible sur la page Contrôle d’accès → Fournisseurs d’identité.
NoteAprès avoir créé le fournisseur d’identité, la synchronisation se termine généralement en deux minutes. Lorsque le fournisseur d’identité htpasswd est disponible, vous pouvez vous connecter au cluster en tant qu’utilisateur.
- Le seul utilisateur administratif est visible sur la page Access Control → Cluster Roles and Access. L’adhésion du groupe d’administration de l’utilisateur est également affichée.
Chapitre 9. La révocation de l’accès à un cluster ROSA Copier lienLien copié sur presse-papiers!
Le fournisseur d’identité (IDP) contrôle l’accès à un cluster Red Hat OpenShift Service sur AWS (ROSA). Afin de révoquer l’accès d’un utilisateur à un cluster, vous devez configurer cela dans le PID qui a été configuré pour l’authentification.
9.1. Annuler l’accès administrateur à l’aide de la ROSA CLI Copier lienLien copié sur presse-papiers!
Il est possible de révoquer l’accès administrateur des utilisateurs afin qu’ils puissent accéder au cluster sans privilèges d’administrateur. Afin de supprimer l’accès administrateur pour un utilisateur, vous devez révoquer les privilèges dédiés-admin ou cluster-admin. Il est possible de révoquer les privilèges d’administrateur à l’aide du service Red Hat OpenShift sur AWS (ROSA) CLI, rosa ou en utilisant la console OpenShift Cluster Manager.
9.1.1. La révocation de l’accès dédié-admin à l’aide de la ROSA CLI Copier lienLien copié sur presse-papiers!
Il est possible de révoquer l’accès pour un utilisateur administrateur dédié si vous êtes l’utilisateur qui a créé le cluster, l’utilisateur administrateur de l’organisation ou l’utilisateur super administrateur.
Conditions préalables
- Dans votre cluster, vous avez ajouté un fournisseur d’identité (IDP).
- Il y a le nom d’utilisateur IDP pour l’utilisateur dont vous révoquez les privilèges.
- Il est connecté au cluster.
Procédure
Entrez la commande suivante pour révoquer l’accès admin dédié d’un utilisateur:
rosa revoke user dedicated-admin --user=<idp_user_name> --cluster=<cluster_name>
$ rosa revoke user dedicated-admin --user=<idp_user_name> --cluster=<cluster_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow Entrez la commande suivante pour vérifier que votre utilisateur n’a plus d’accès admin dédié. La sortie ne répertorie pas l’utilisateur révoqué.
oc get groups dedicated-admins
$ oc get groups dedicated-adminsCopy to Clipboard Copied! Toggle word wrap Toggle overflow
9.1.2. La révocation de l’accès cluster-admin à l’aide de la ROSA CLI Copier lienLien copié sur presse-papiers!
Il n’y a que l’utilisateur qui a créé le cluster qui peut révoquer l’accès pour les utilisateurs de cluster-admin.
Conditions préalables
- Dans votre cluster, vous avez ajouté un fournisseur d’identité (IDP).
- Il y a le nom d’utilisateur IDP pour l’utilisateur dont vous révoquez les privilèges.
- Il est connecté au cluster.
Procédure
Entrez la commande suivante pour révoquer l’accès cluster-admin d’un utilisateur:
rosa revoke user cluster-admins --user=myusername --cluster=mycluster
$ rosa revoke user cluster-admins --user=myusername --cluster=myclusterCopy to Clipboard Copied! Toggle word wrap Toggle overflow Entrez la commande suivante pour vérifier que l’utilisateur n’a plus accès cluster-admin. La sortie ne répertorie pas l’utilisateur révoqué.
oc get groups cluster-admins
$ oc get groups cluster-adminsCopy to Clipboard Copied! Toggle word wrap Toggle overflow
9.2. Annuler l’accès de l’administrateur à l’aide de la console OpenShift Cluster Manager Copier lienLien copié sur presse-papiers!
Il est possible de révoquer l’accès dédié-admin ou cluster-admin des utilisateurs via la console OpenShift Cluster Manager. Les utilisateurs pourront accéder au cluster sans privilèges d’administrateur.
Conditions préalables
- Dans votre cluster, vous avez ajouté un fournisseur d’identité (IDP).
- Il y a le nom d’utilisateur IDP pour l’utilisateur dont vous révoquez les privilèges.
- Connectez-vous à la console OpenShift Cluster Manager à l’aide d’un compte OpenShift Cluster Manager que vous avez utilisé pour créer le cluster, l’utilisateur administrateur de l’organisation ou l’utilisateur super administrateur.
Procédure
- Dans l’onglet Liste des clusters d’OpenShift Cluster Manager, sélectionnez le nom de votre cluster pour afficher les détails du cluster.
- Choisissez Contrôle d’accès > Rôles de cluster et Accès.
- Dans le cas de l’utilisateur que vous souhaitez supprimer, cliquez sur le menu Options à droite de la combinaison utilisateur et groupe et cliquez sur Supprimer.
Chapitre 10. La suppression d’un cluster ROSA Copier lienLien copié sur presse-papiers!
Ce document fournit des étapes pour supprimer un Red Hat OpenShift Service sur AWS (ROSA) cluster qui utilise AWS Security Token Service (STS). Après la suppression de votre cluster, vous pouvez également supprimer les ressources AWS Identity and Access Management (IAM) qui sont utilisées par le cluster.
10.1. Conditions préalables Copier lienLien copié sur presse-papiers!
Lorsque Red Hat OpenShift Service sur AWS a créé un VPC, vous devez supprimer les éléments suivants de votre cluster avant de pouvoir supprimer votre cluster avec succès:
- Configurations réseau, telles que les configurations VPN et les connexions de peering VPC
- Les services supplémentaires qui ont été ajoutés au VPC
Lorsque ces configurations et services restent, le cluster ne supprime pas correctement.
10.2. La suppression d’un cluster ROSA et des ressources spécifiques au groupe IAM Copier lienLien copié sur presse-papiers!
Il est possible de supprimer un service Red Hat OpenShift sur AWS (ROSA) avec le cluster AWS Security Token Service (STS) en utilisant le ROSA CLI (rosa) ou Red Hat OpenShift Cluster Manager.
Après avoir supprimé le cluster, vous pouvez nettoyer les ressources de gestion des identités et des accès (IAM) spécifiques au cluster dans votre compte AWS en utilisant le ROSA CLI (rosa). Les ressources spécifiques au cluster comprennent les rôles d’opérateur et le fournisseur OpenID Connect (OIDC).
La suppression de cluster doit être terminée avant de supprimer les ressources IAM, car les ressources sont utilisées dans les processus de suppression et de nettoyage du cluster.
Lorsque des add-ons sont installés, la suppression du cluster prend plus de temps car les add-ons sont désinstallés avant que le cluster ne soit supprimé. Le temps dépend du nombre et de la taille des add-ons.
Lorsque le cluster qui a créé le VPC pendant l’installation est supprimé, le VPC créé par le programme d’installation associé sera également supprimé, entraînant la défaillance de tous les clusters qui utilisent le même VPC. De plus, toutes les ressources créées avec la même paire de clés-valeur tagSet des ressources créées par le programme d’installation et étiquetées avec une valeur de propriété seront également supprimées.
Conditions préalables
- « vous avez installé un cluster ROSA.
- L’installation et la configuration de la dernière ROSA CLI (rosa) sur votre hôte d’installation.
Procédure
Demandez l’ID de cluster, les noms de ressource Amazon (ARN) pour les rôles d’opérateur spécifiques au cluster et l’URL du point de terminaison pour le fournisseur OIDC:
rosa describe cluster --cluster=<cluster_name>
$ rosa describe cluster --cluster=<cluster_name>1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- <cluster_name> par le nom de votre cluster.
Exemple de sortie
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Liste l’identifiant du cluster.
- 2
- Indique les ARN pour les rôles d’opérateur spécifiques au cluster. Dans la sortie de l’échantillon, par exemple, l’ARN pour le rôle requis par l’opérateur de configuration de machine est arn:aws:iam::<aws_account_id>:role/mycluster-x4q9-openshift-machine-api-aws-cloud-credentials.
- 3
- Affiche l’URL du point de terminaison pour le fournisseur OIDC spécifique au cluster.
ImportantL’ID de cluster doit supprimer les ressources STS spécifiques au cluster en utilisant le ROSA CLI (rosa) une fois le cluster supprimé.
Effacer le cluster:
De supprimer le cluster en utilisant Red Hat OpenShift Cluster Manager:
- Accédez à OpenShift Cluster Manager.
- Cliquez sur le menu Options à côté de votre cluster et sélectionnez Supprimer le cluster.
- Entrez le nom de votre cluster à l’invite et cliquez sur Supprimer.
De supprimer le cluster à l’aide de la ROSA CLI (rosa):
Entrez la commande suivante pour supprimer le cluster et regarder les journaux, en remplaçant <cluster_name> par le nom ou l’ID de votre cluster:
rosa delete cluster --cluster=<cluster_name> --watch
$ rosa delete cluster --cluster=<cluster_name> --watchCopy to Clipboard Copied! Toggle word wrap Toggle overflow ImportantIl faut attendre que la suppression du cluster soit terminée avant de supprimer les rôles Opérateur et le fournisseur OIDC. Les rôles d’opérateur spécifiques au cluster sont nécessaires pour nettoyer les ressources créées par les opérateurs OpenShift. Les opérateurs utilisent le fournisseur OIDC pour s’authentifier.
Effacer le fournisseur OIDC que les opérateurs de cluster utilisent pour authentifier:
rosa delete oidc-provider -c <cluster_id> --mode auto
$ rosa delete oidc-provider -c <cluster_id> --mode auto1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- <cluster_id> par l’ID du cluster.
NoteL’option -y vous permet de répondre automatiquement oui aux invitations.
En option. Effacer les rôles IAM d’opérateur spécifiques au cluster:
ImportantLes rôles IAM à l’échelle du compte peuvent être utilisés par d’autres clusters ROSA dans le même compte AWS. Les rôles ne sont supprimés que s’ils ne sont pas requis par d’autres clusters.
rosa delete operator-roles -c <cluster_id> --mode auto
$ rosa delete operator-roles -c <cluster_id> --mode auto1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- <cluster_id> par l’ID du cluster.
Résolution de problèmes
- Lorsque le cluster ne peut pas être supprimé en raison des rôles IAM manquants, voir Réparation supplémentaire d’un cluster qui ne peut pas être supprimé.
Lorsque le cluster ne peut pas être supprimé pour d’autres raisons:
- Assurez-vous qu’il n’y a pas d’ajouts pour votre cluster en attente dans la console hybride Cloud.
- Assurez-vous que toutes les ressources et dépendances AWS ont été supprimées dans la console Web Amazon.
10.3. La suppression des ressources de l’IAM à l’échelle du compte Copier lienLien copié sur presse-papiers!
Après avoir supprimé tous les services Red Hat OpenShift sur AWS (ROSA) avec des clusters de plans de contrôle hébergés (HCP) qui dépendent des ressources AWS Identity and Access Management (IAM) à l’échelle du compte, vous pouvez supprimer les ressources à l’échelle du compte.
Lorsque vous n’avez plus besoin d’installer un ROSA avec le cluster HCP en utilisant Red Hat OpenShift Cluster Manager, vous pouvez également supprimer le gestionnaire de cluster OpenShift et les rôles IAM utilisateur.
Les rôles et les politiques IAM à l’échelle du compte pourraient être utilisés par d’autres ROSA avec des clusters HCP dans le même compte AWS. Il suffit de supprimer les ressources si elles ne sont pas requises par d’autres clusters.
Les rôles OpenShift Cluster Manager et IAM d’utilisateur sont nécessaires si vous souhaitez installer, gérer et supprimer d’autres services Red Hat OpenShift sur les clusters AWS dans le même compte AWS en utilisant OpenShift Cluster Manager. Supprimez uniquement les rôles si vous n’avez plus besoin d’installer Red Hat OpenShift Service sur les clusters AWS dans votre compte en utilisant OpenShift Cluster Manager. De plus amples informations sur la réparation de votre cluster si ces rôles sont supprimés avant la suppression, voir « Réparation d’un cluster qui ne peut pas être supprimé » dans Dépannage des déploiements de clusters.
10.3.1. La suppression des rôles et des politiques de l’IAM à l’échelle du compte Copier lienLien copié sur presse-papiers!
Cette section fournit des étapes pour supprimer les rôles et les politiques IAM à l’échelle du compte que vous avez créés pour ROSA avec STS ROSA avec les déploiements HCP, ainsi que les politiques d’opérateur à l’échelle du compte. Il est possible de supprimer les rôles et les politiques AWS Identity and Access Management (IAM) à l’échelle du compte seulement après avoir supprimé tous les services Red Hat OpenShift sur AWS (ROSA) avec AWS Security Token Services (STS) ROSA avec des clusters HCP qui en dépendent.
Les rôles et politiques IAM à l’échelle du compte pourraient être utilisés par d’autres clusters ROSA Red Hat OpenShift Service sur AWS dans le même compte AWS. Les rôles ne sont supprimés que s’ils ne sont pas requis par d’autres clusters.
Conditions préalables
- Il y a des rôles IAM à l’échelle du compte que vous souhaitez supprimer.
- L’installation et la configuration de la dernière ROSA CLI (rosa) sur votre hôte d’installation.
Procédure
Effacer les rôles à l’échelle du compte:
Énumérez les rôles à l’échelle du compte dans votre compte AWS en utilisant le ROSA CLI (rosa):
rosa list account-roles
$ rosa list account-rolesCopy to Clipboard Copied! Toggle word wrap Toggle overflow Exemple de sortie
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
I: Fetching account roles ROLE NAME ROLE TYPE ROLE ARN OPENSHIFT VERSION AWS Managed ManagedOpenShift-HCP-ROSA-Installer-Role Installer arn:aws:iam::<aws_account_id>:role/ManagedOpenShift-HCP-ROSA-Installer-Role 4.18 Yes ManagedOpenShift-HCP-ROSA-Support-Role Support arn:aws:iam::<aws_account_id>:role/ManagedOpenShift-HCP-ROSA-Support-Role 4.18 Yes ManagedOpenShift-HCP-ROSA-Worker-Role Worker arn:aws:iam::<aws_account_id>:role/ManagedOpenShift-HCP-ROSA-Worker-Role 4.18 Yes
I: Fetching account roles
ROLE NAME ROLE TYPE ROLE ARN OPENSHIFT VERSION AWS Managed
ManagedOpenShift-HCP-ROSA-Installer-Role Installer arn:aws:iam::<aws_account_id>:role/ManagedOpenShift-HCP-ROSA-Installer-Role 4.18 Yes
ManagedOpenShift-HCP-ROSA-Support-Role Support arn:aws:iam::<aws_account_id>:role/ManagedOpenShift-HCP-ROSA-Support-Role 4.18 Yes
ManagedOpenShift-HCP-ROSA-Worker-Role Worker arn:aws:iam::<aws_account_id>:role/ManagedOpenShift-HCP-ROSA-Worker-Role 4.18 Yes
Effacer les rôles à l’échelle du compte:
rosa delete account-roles --prefix <prefix> --mode auto
$ rosa delete account-roles --prefix <prefix> --mode auto1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Il faut inclure l’argument --<prefix>. <prefix> par le préfixe des rôles à supprimer à l’échelle du compte. Lorsque vous n’avez pas spécifié un préfixe personnalisé lorsque vous avez créé les rôles à l’échelle du compte, spécifiez le préfixe par défaut, ManagedOpenShift.
ImportantLes rôles IAM à l’échelle du compte pourraient être utilisés par d’autres clusters ROSA dans le même compte AWS. Les rôles ne sont supprimés que s’ils ne sont pas requis par d’autres clusters.
Exemple de sortie
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - Effacer les politiques en ligne à l’échelle du compte et de l’opérateur:
Dans la page Politiques de la console AWS IAM, filtrez la liste des stratégies par le préfixe que vous avez spécifié lorsque vous avez créé les rôles et stratégies à l’échelle du compte.
NoteLorsque vous n’avez pas spécifié un préfixe personnalisé lorsque vous avez créé les rôles à l’échelle du compte, recherchez le préfixe par défaut, ManagedOpenShift.
Supprimez les politiques en ligne à l’échelle du compte et les politiques d’opérateur en utilisant la console AWS IAM. Afin d’obtenir de plus amples informations sur la suppression des politiques IAM en utilisant la console AWS IAM, voir Supprimer les politiques IAM dans la documentation AWS.
ImportantLes politiques IAM à l’échelle du compte et de l’opérateur pourraient être utilisées par d’autres clusters ROSA ROSA avec HCP dans le même compte AWS. Les rôles ne sont supprimés que s’ils ne sont pas requis par d’autres clusters.
10.3.2. Déconnecter et supprimer les rôles OpenShift Cluster Manager et utilisateur IAM Copier lienLien copié sur presse-papiers!
Lorsque vous installez un ROSA avec le cluster HCP à l’aide de Red Hat OpenShift Cluster Manager, vous créez également des rôles OpenShift Cluster Manager et User Identity and Access Management (IAM) qui se lient à votre organisation Red Hat. Après avoir supprimé votre cluster, vous pouvez déconnecter et supprimer les rôles en utilisant le ROSA CLI (rosa).
Le gestionnaire de cluster OpenShift et les rôles IAM d’utilisateur sont nécessaires si vous souhaitez utiliser OpenShift Cluster Manager pour installer et gérer d’autres ROSA avec HCP dans le même compte AWS. Supprimez uniquement les rôles si vous n’avez plus besoin d’utiliser OpenShift Cluster Manager pour installer ROSA avec des clusters HCP.
Conditions préalables
- Il a créé OpenShift Cluster Manager et les rôles d’utilisateur IAM et les a reliés à votre organisation Red Hat.
- L’installation et la configuration de la dernière ROSA CLI (rosa) sur votre hôte d’installation.
- Il y a des privilèges d’administrateur d’organisation dans votre organisation Red Hat.
Procédure
Déconnectez le rôle de gestionnaire de cluster OpenShift de votre organisation Red Hat et supprimez le rôle:
Liste des rôles OpenShift Cluster Manager IAM dans votre compte AWS:
rosa list ocm-roles
$ rosa list ocm-rolesCopy to Clipboard Copied! Toggle word wrap Toggle overflow Exemple de sortie
I: Fetching ocm roles ROLE NAME ROLE ARN LINKED ADMIN AWS Managed ManagedOpenShift-OCM-Role-<red_hat_organization_external_id> arn:aws:iam::<aws_account_id>:role/ManagedOpenShift-OCM-Role-<red_hat_organization_external_id> Yes Yes Yes
I: Fetching ocm roles ROLE NAME ROLE ARN LINKED ADMIN AWS Managed ManagedOpenShift-OCM-Role-<red_hat_organization_external_id> arn:aws:iam::<aws_account_id>:role/ManagedOpenShift-OCM-Role-<red_hat_organization_external_id> Yes Yes YesCopy to Clipboard Copied! Toggle word wrap Toggle overflow Lorsque votre rôle OpenShift Cluster Manager IAM est listé comme lié dans la sortie de la commande précédente, déconnectez le rôle de votre organisation Red Hat en exécutant la commande suivante:
rosa unlink ocm-role --role-arn <arn>
$ rosa unlink ocm-role --role-arn <arn>1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- <arn> par le nom de ressource Amazon (ARN) pour votre rôle OpenShift Cluster Manager IAM. L’ARN est spécifié dans la sortie de la commande précédente. Dans l’exemple précédent, l’ARN est au format arn:aws:iam::<aws_account_id>:role/ManagedOpenShift-OCM-Role-<red_hat_organization_external_id>.
Exemple de sortie
I: Unlinking OCM role ? Unlink the 'arn:aws:iam::<aws_account_id>:role/ManagedOpenShift-OCM-Role-<red_hat_organization_external_id>' role from organization '<red_hat_organization_id>'? Yes I: Successfully unlinked role-arn 'arn:aws:iam::<aws_account_id>:role/ManagedOpenShift-OCM-Role-<red_hat_organization_external_id>' from organization account '<red_hat_organization_id>'
I: Unlinking OCM role ? Unlink the 'arn:aws:iam::<aws_account_id>:role/ManagedOpenShift-OCM-Role-<red_hat_organization_external_id>' role from organization '<red_hat_organization_id>'? Yes I: Successfully unlinked role-arn 'arn:aws:iam::<aws_account_id>:role/ManagedOpenShift-OCM-Role-<red_hat_organization_external_id>' from organization account '<red_hat_organization_id>'Copy to Clipboard Copied! Toggle word wrap Toggle overflow Effacer le rôle et les politiques du gestionnaire de cluster OpenShift:
rosa delete ocm-role --role-arn <arn>
$ rosa delete ocm-role --role-arn <arn>Copy to Clipboard Copied! Toggle word wrap Toggle overflow Exemple de sortie
I: Deleting OCM role ? OCM Role ARN: arn:aws:iam::<aws_account_id>:role/ManagedOpenShift-OCM-Role-<red_hat_organization_external_id> ? Delete 'arn:aws:iam::<aws_account_id>:role/ManagedOpenShift-OCM-Role-<red_hat_organization_external_id>' ocm role? Yes ? OCM role deletion mode: auto I: Successfully deleted the OCM role
I: Deleting OCM role ? OCM Role ARN: arn:aws:iam::<aws_account_id>:role/ManagedOpenShift-OCM-Role-<red_hat_organization_external_id> ? Delete 'arn:aws:iam::<aws_account_id>:role/ManagedOpenShift-OCM-Role-<red_hat_organization_external_id>' ocm role? Yes ? OCM role deletion mode: auto1 I: Successfully deleted the OCM roleCopy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Indique le mode de suppression. Le mode automatique permet de supprimer automatiquement le rôle et les stratégies d’OpenShift Cluster Manager IAM. En mode manuel, le ROSA CLI génère les commandes aws nécessaires pour supprimer le rôle et les politiques. le mode manuel vous permet d’examiner les détails avant d’exécuter manuellement les commandes aws.
Déconnectez le rôle de l’utilisateur IAM de votre organisation Red Hat et supprimez le rôle:
Énumérez les rôles IAM d’utilisateur dans votre compte AWS:
rosa list user-roles
$ rosa list user-rolesCopy to Clipboard Copied! Toggle word wrap Toggle overflow Exemple de sortie
I: Fetching user roles ROLE NAME ROLE ARN LINKED ManagedOpenShift-User-<ocm_user_name>-Role arn:aws:iam::<aws_account_id>:role/ManagedOpenShift-User-<ocm_user_name>-Role Yes
I: Fetching user roles ROLE NAME ROLE ARN LINKED ManagedOpenShift-User-<ocm_user_name>-Role arn:aws:iam::<aws_account_id>:role/ManagedOpenShift-User-<ocm_user_name>-Role YesCopy to Clipboard Copied! Toggle word wrap Toggle overflow Lorsque votre rôle IAM utilisateur est listé comme lié dans la sortie de la commande précédente, déconnectez le rôle de votre organisation Red Hat:
rosa unlink user-role --role-arn <arn>
$ rosa unlink user-role --role-arn <arn>1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- <arn> par le nom de ressource Amazon (ARN) pour votre rôle IAM utilisateur. L’ARN est spécifié dans la sortie de la commande précédente. Dans l’exemple précédent, l’ARN est au format arn:aws:iam::<aws_account_id>:role/ManagedOpenShift-User-<ocm_user_name>-Role.
Exemple de sortie
I: Unlinking user role ? Unlink the 'arn:aws:iam::<aws_account_id>:role/ManagedOpenShift-User-<ocm_user_name>-Role' role from the current account '<ocm_user_account_id>'? Yes I: Successfully unlinked role ARN 'arn:aws:iam::<aws_account_id>:role/ManagedOpenShift-User-<ocm_user_name>-Role' from account '<ocm_user_account_id>'
I: Unlinking user role ? Unlink the 'arn:aws:iam::<aws_account_id>:role/ManagedOpenShift-User-<ocm_user_name>-Role' role from the current account '<ocm_user_account_id>'? Yes I: Successfully unlinked role ARN 'arn:aws:iam::<aws_account_id>:role/ManagedOpenShift-User-<ocm_user_name>-Role' from account '<ocm_user_account_id>'Copy to Clipboard Copied! Toggle word wrap Toggle overflow Effacer le rôle de l’utilisateur IAM:
rosa delete user-role --role-arn <arn>
$ rosa delete user-role --role-arn <arn>Copy to Clipboard Copied! Toggle word wrap Toggle overflow Exemple de sortie
I: Deleting user role ? User Role ARN: arn:aws:iam::<aws_account_id>:role/ManagedOpenShift-User-<ocm_user_name>-Role ? Delete the 'arn:aws:iam::<aws_account_id>:role/ManagedOpenShift-User-<ocm_user_name>-Role' role from the AWS account? Yes ? User role deletion mode: auto I: Successfully deleted the user role
I: Deleting user role ? User Role ARN: arn:aws:iam::<aws_account_id>:role/ManagedOpenShift-User-<ocm_user_name>-Role ? Delete the 'arn:aws:iam::<aws_account_id>:role/ManagedOpenShift-User-<ocm_user_name>-Role' role from the AWS account? Yes ? User role deletion mode: auto1 I: Successfully deleted the user roleCopy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Indique le mode de suppression. Il est possible d’utiliser le mode automatique pour supprimer automatiquement le rôle de l’utilisateur IAM. En mode manuel, le ROSA CLI génère la commande aws nécessaire pour supprimer le rôle. le mode manuel vous permet d’examiner les détails avant d’exécuter manuellement la commande aws.
Chapitre 11. Déploiement de ROSA sans AWS STS Copier lienLien copié sur presse-papiers!
11.1. AWS prérequis pour ROSA Copier lienLien copié sur presse-papiers!
Le Red Hat OpenShift Service sur AWS (ROSA) fournit un modèle qui permet à Red Hat de déployer des clusters dans le compte Amazon Web Service (AWS) existant d’un client.
Avant d’installer ROSA, vous devez vous assurer que les conditions préalables sont remplies. Ce document d’exigences ne s’applique pas à AWS Security Token Service (STS). Lorsque vous utilisez STS, consultez les exigences spécifiques au STS.
AWS Security Token Service (STS) est le mode d’identification recommandé pour l’installation et l’interaction avec les clusters sur Red Hat OpenShift Service sur AWS car il offre une sécurité accrue.
11.1.1. Exigences du client Copier lienLien copié sur presse-papiers!
Les clusters Red Hat OpenShift Service sur AWS (ROSA) doivent répondre à plusieurs prérequis avant de pouvoir être déployés.
Afin de créer le cluster, l’utilisateur doit être connecté en tant qu’utilisateur IAM et non pas un rôle assumé ou un utilisateur STS.
11.1.1.1. Compte Copier lienLien copié sur presse-papiers!
- Le client veille à ce que les limites AWS soient suffisantes pour prendre en charge le service Red Hat OpenShift sur AWS fourni dans le compte AWS du client.
Le compte AWS du client doit être dans les organisations AWS du client avec la politique de contrôle du service (SCP) applicable.
NoteIl n’est pas nécessaire que le compte du client soit dans les organisations AWS ou que le SCP soit appliqué, mais Red Hat doit être en mesure d’effectuer toutes les actions énumérées dans le SCP sans restriction.
- Le compte AWS du client ne devrait pas être transférable à Red Hat.
- Le client ne peut pas imposer de restrictions d’utilisation AWS aux activités Red Hat. Imposer des restrictions entravera gravement la capacité de Red Hat à réagir aux incidents.
Le client peut déployer des services AWS natifs au sein du même compte AWS.
NoteLes clients sont encouragés, mais non mandatés, à déployer des ressources dans un Cloud privé virtuel (VPC) distinct du VPC hébergeant Red Hat OpenShift Service sur AWS et d’autres services pris en charge par Red Hat.
11.1.1.2. Exigences d’accès Copier lienLien copié sur presse-papiers!
Afin de gérer correctement le service Red Hat OpenShift sur le service AWS, Red Hat doit faire appliquer la politique AdministratorAccess au rôle d’administrateur en tout temps. Cette exigence ne s’applique pas si vous utilisez AWS Security Token Service (STS).
NoteCette politique fournit uniquement à Red Hat des autorisations et des capacités pour modifier les ressources du compte AWS fourni par le client.
- Le Red Hat doit avoir accès à la console AWS au compte AWS fourni par le client. Cet accès est protégé et géré par Red Hat.
- Le client ne doit pas utiliser le compte AWS pour augmenter ses autorisations au sein du service Red Hat OpenShift sur le cluster AWS.
- Les actions disponibles dans le service OpenShift Red Hat sur AWS (ROSA) CLI, rosa ou OpenShift Cluster Manager ne doivent pas être effectuées directement sur le compte AWS du client.
11.1.1.3. Besoins de soutien Copier lienLien copié sur presse-papiers!
- Le Red Hat recommande que le client dispose au moins d’un support professionnel d’AWS.
- Le client a l’autorité de Red Hat pour demander un support AWS en son nom.
- Le Red Hat a le pouvoir du client de demander des augmentations de limite de ressources AWS sur le compte du client.
- Le Red Hat gère les restrictions, limitations, attentes et défaut pour tous les services OpenShift Red Hat sur les clusters AWS de la même manière, sauf indication contraire dans cette section d’exigences.
11.1.1.4. Exigences de sécurité Copier lienLien copié sur presse-papiers!
- Les instantanés de volume resteront dans le compte AWS du client et dans la région spécifiée par le client.
- Le Red Hat doit avoir accès aux hôtes EC2 et au serveur API à partir d’adresses IP autorisées.
- Le Red Hat doit avoir le droit d’envoyer le système et les journaux d’audit vers une pile de journalisation centrale gérée par Red Hat.
11.1.2. La procédure client requise Copier lienLien copié sur presse-papiers!
Complétez ces étapes avant de déployer Red Hat OpenShift Service sur AWS (ROSA).
Procédure
- En tant que client, si vous utilisez AWS Organizations, vous devez utiliser un compte AWS au sein de votre organisation ou en créer un nouveau.
- Afin de vous assurer que Red Hat peut effectuer les actions nécessaires, vous devez soit créer une stratégie de contrôle du service (SCP) soit s’assurer qu’aucune n’est appliquée au compte AWS.
- Attachez le SCP au compte AWS.
- Suivre les procédures ROSA pour la mise en place de l’environnement.
11.1.2.1. Ensemble minimum d’autorisations efficaces pour les politiques de contrôle du service (SCP) Copier lienLien copié sur presse-papiers!
Les stratégies de contrôle des services (SCP) sont un type de stratégie d’organisation qui gère les autorisations au sein de votre organisation. Les SCP s’assurent que les comptes au sein de votre organisation restent dans le respect de vos directives de contrôle d’accès définies. Ces politiques sont maintenues dans AWS Organizations et contrôlent les services disponibles dans les comptes AWS ci-joints. La gestion de SCP relève de la responsabilité du client.
L’exigence minimale de SCP ne s’applique pas lorsque vous utilisez AWS Security Token Service (STS). Consultez les prérequis AWS pour ROSA avec STS pour plus d’informations sur STS.
Assurez-vous que votre politique de contrôle de service (SCP) ne limite aucune de ces autorisations requises.
| Le service | Actions | Effet | |
|---|---|---|---|
| A) requis | Amazon EC2 | Le tout | Autoriser |
| Amazon EC2 Auto Scaling | Le tout | Autoriser | |
| Amazon S3 | Le tout | Autoriser | |
| Gestion de l’identité et de l’accès | Le tout | Autoriser | |
| Équilibrage de charge élastique | Le tout | Autoriser | |
| Équilibrage de charge élastique V2 | Le tout | Autoriser | |
| Amazon CloudWatch | Le tout | Autoriser | |
| Événements Amazon CloudWatch | Le tout | Autoriser | |
| Journaux Amazon CloudWatch | Le tout | Autoriser | |
| AWS EC2 Instance Connect | SendSerialConsoleSSHPublicKey | Autoriser | |
| Le support AWS | Le tout | Autoriser | |
| AWS Key Management Service | Le tout | Autoriser | |
| AWS Security Token Service | Le tout | Autoriser | |
| AWS Tiro | CréerQuery GetQueryAnswer GetQueryExplanation | Autoriser | |
| AWS Marketplace | Abonnez-vous Désabonnement Afficher les abonnements | Autoriser | |
| Étiquettes des ressources AWS | Le tout | Autoriser | |
| AWS Route53 DNS | Le tout | Autoriser | |
| Quotas de service AWS | Liste des services GetRequestedServiceQuotaChange GetServiceQuota DemandeServiceQuotaaugmentation ListeServiceQuotas | Autoriser | |
| Facultatif | Facturation AWS | AfficherAccount Affichage de la facturation AffichageUsage | Autoriser |
| AWS Rapport sur les coûts et l’utilisation | Le tout | Autoriser | |
| AWS Cost Explorer Services | Le tout | Autoriser |
11.1.3. Les références de Red Hat gérées par IAM pour AWS Copier lienLien copié sur presse-papiers!
Il est responsable de la création et de la gestion des ressources Amazon Web Services (AWS) suivantes : les politiques IAM, les utilisateurs de l’IAM et les rôles de l’IAM.
11.1.3.1. IAM Politiques Copier lienLien copié sur presse-papiers!
Les politiques IAM sont sujettes à modification à mesure que les capacités de Red Hat OpenShift Service sur AWS changent.
La politique AdministratorAccess est utilisée par le rôle d’administration. Cette politique fournit à Red Hat l’accès nécessaire pour administrer le cluster Red Hat OpenShift Service sur AWS (ROSA) dans le compte AWS du client.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
11.1.3.2. Les utilisateurs de l’IAM Copier lienLien copié sur presse-papiers!
L’utilisateur osdManagedAdmin est créé immédiatement après l’installation de ROSA dans le compte AWS du client.
11.1.4. Infrastructure AWS provisionnée Copier lienLien copié sur presse-papiers!
Il s’agit d’un aperçu des composants Amazon Web Services (AWS) fournis sur un cluster Red Hat OpenShift Service sur AWS (ROSA) déployé.
11.1.4.1. Instances EC2 Copier lienLien copié sur presse-papiers!
Les instances AWS EC2 sont nécessaires pour déployer les fonctions de plan de contrôle et de plan de données pour Red Hat OpenShift Service sur AWS.
Les types d’instances peuvent varier pour les nœuds de plan de contrôle et d’infrastructure, en fonction du nombre de nœuds de travail.
Au minimum, les instances EC2 suivantes sont déployées:
- 3 m5.2x grands nœuds de plan de commande
- Deux nœuds d’infrastructure r5.xlarge
- Deux nœuds de travail m5.xlarge
Le type d’instance affiché pour les nœuds de travail est la valeur par défaut, mais vous pouvez personnaliser le type d’instance pour les nœuds de travail en fonction des besoins de votre charge de travail.
Afin d’obtenir de plus amples conseils sur le comptage des nœuds des travailleurs, consultez les informations sur les considérations de planification initiales dans le sujet « Limites et évolutivité » figurant dans la section « Ressources supplémentaires » de cette page.
11.1.4.2. Amazon Elastic Block Store stockage Copier lienLien copié sur presse-papiers!
Le stockage de blocs Amazon Elastic Block Store (Amazon EBS) est utilisé à la fois pour le stockage des nœuds locaux et le stockage en volume persistant. Les valeurs suivantes sont la taille par défaut du stockage éphémère local prévu pour chaque instance EC2.
Exigences en volume pour chaque instance EC2:
Contrôle du volume du plan
- Format: 350 Go
- Catégorie: gp3
- Entrée/sortie Opérations par seconde: 1000
Le volume de l’infrastructure
- Dimensions: 300 Go
- Catégorie: gp3
- Entrées/sorties par seconde : 900
Le volume des travailleurs
- Taille par défaut: 300 Go
- Format minimum: 128 Go
- Format minimum: 75 Go
- Catégorie: gp3
- Entrées/sorties par seconde : 900
Les clusters déployés avant la sortie d’OpenShift Container Platform 4.11 utilisent le stockage de type gp2 par défaut.
11.1.4.3. Équilibrage de charge élastique Copier lienLien copié sur presse-papiers!
Chaque cluster peut utiliser jusqu’à deux balanceurs de charge classiques pour le routeur d’application et jusqu’à deux balanceurs de charge réseau pour API.
Consultez la documentation ELB pour AWS.
11.1.4.4. Le stockage S3 Copier lienLien copié sur presse-papiers!
Le registre des images est soutenu par le stockage AWS S3. La valorisation des ressources est effectuée régulièrement afin d’optimiser l’utilisation de S3 et la performance des clusters.
Deux seaux sont nécessaires avec une taille typique de 2 To chacun.
11.1.4.5. LE VPC Copier lienLien copié sur presse-papiers!
Configurez votre VPC selon les exigences suivantes:
Deux sous-réseaux pour un cluster avec une seule zone de disponibilité, ou six sous-réseaux pour un cluster avec plusieurs zones de disponibilité.
Le Red Hat recommande fortement d’utiliser des sous-réseaux uniques pour chaque cluster. Le partage de sous-réseaux entre plusieurs clusters n’est pas recommandé.
NoteLe sous-réseau public se connecte directement à Internet via une passerelle Internet. Le sous-réseau privé se connecte à Internet via une passerelle de traduction d’adresse réseau (NAT).
- Les tables d’itinéraire: une table de route par sous-réseau privé, et une table supplémentaire par cluster.
- Passerelles Internet: une passerelle Internet par cluster.
- Passerelles NAT: Une passerelle NAT par sous-réseau public.
Figure 11.1. Exemple d’architecture VPC
11.1.4.6. Groupes de sécurité Copier lienLien copié sur presse-papiers!
Les groupes de sécurité AWS assurent la sécurité au niveau du protocole et de l’accès au port; ils sont associés aux instances EC2 et aux balanceurs de charge Elastic Load Balancing (ELB). Chaque groupe de sécurité contient un ensemble de règles qui filtrent le trafic entrant et sortant d’une ou de plusieurs instances EC2.
Assurez-vous que les ports requis pour l’installation et le fonctionnement du cluster sont ouverts sur votre réseau et configurés pour permettre l’accès entre les hôtes. Les exigences pour les groupes de sécurité par défaut sont listées dans les ports requis pour les groupes de sécurité par défaut.
| Groupe de travail | Le type | Le protocole de propriété intellectuelle | Gamme de ports |
|---|---|---|---|
| Groupe MasterSecurity |
|
|
|
|
|
| ||
|
|
| ||
|
|
| ||
| Groupe WorkerSecurity |
|
|
|
|
|
| ||
| BootstrapSecurityGroup |
|
|
|
|
|
|
11.1.4.6.1. Groupes de sécurité personnalisés supplémentaires Copier lienLien copié sur presse-papiers!
Lorsque vous créez un cluster à l’aide d’un VPC existant non géré, vous pouvez ajouter des groupes de sécurité personnalisés supplémentaires lors de la création de clusters. Les groupes de sécurité personnalisés sont soumis aux limitations suivantes:
- Il faut créer les groupes de sécurité personnalisés dans AWS avant de créer le cluster. Consultez les groupes de sécurité Amazon EC2 pour les instances Linux.
- Il faut associer les groupes de sécurité personnalisés au VPC dans lequel le cluster sera installé. Les groupes de sécurité personnalisés ne peuvent pas être associés à un autre VPC.
- Il vous faudra peut-être demander un quota supplémentaire pour votre VPC si vous ajoutez des groupes de sécurité personnalisés supplémentaires. Afin d’obtenir des informations sur les exigences de quotas AWS pour ROSA, consultez les quotas de service AWS requis dans Préparez votre environnement. Afin d’obtenir des informations sur la demande d’augmentation du quota AWS, consultez Demander une augmentation de quota.
11.1.5. Conditions préalables à la mise en réseau Copier lienLien copié sur presse-papiers!
11.1.5.1. Bande passante minimale Copier lienLien copié sur presse-papiers!
Lors du déploiement de clusters, Red Hat OpenShift Service sur AWS nécessite une bande passante minimale de 120 Mbps entre les ressources de cluster et les ressources Internet publiques. Lorsque la connectivité réseau est plus lente que 120 Mbps (par exemple, lors de la connexion via un proxy), le processus d’installation du cluster est terminé et le déploiement échoue.
Après le déploiement, les besoins du réseau sont déterminés par votre charge de travail. Cependant, une bande passante minimale de 120 Mbps permet d’assurer des mises à niveau opportunes des clusters et des opérateurs.
11.1.5.2. Conditions préalables du pare-feu AWS Copier lienLien copié sur presse-papiers!
Lorsque vous utilisez un pare-feu pour contrôler le trafic sortant de Red Hat OpenShift Service sur AWS, vous devez configurer votre pare-feu pour permettre l’accès à certaines combinaisons de domaines et de ports ci-dessous. Le service Red Hat OpenShift sur AWS nécessite cet accès pour fournir un service OpenShift entièrement géré.
Les clusters ROSA déployés avec PrivateLink peuvent utiliser un pare-feu pour contrôler le trafic sortant.
Conditions préalables
- Dans votre AWS Virtual Private Cloud (VPC), vous avez configuré un point de terminaison Amazon S3 Gateway. Ce point de terminaison est nécessaire pour compléter les demandes du cluster vers le service Amazon S3.
Procédure
Autoriser les URL suivantes qui sont utilisées pour installer et télécharger des paquets et des outils:
Expand Domaine Le port Fonction Greffe.redhat.io443
Fournit des images de conteneur de base.
à propos de Quay.io443
Fournit des images de conteneur de base.
cdn01.quay.io443
Fournit des images de conteneur de base.
cdn02.quay.io443
Fournit des images de conteneur de base.
cdn03.quay.io443
Fournit des images de conteneur de base.
cdn04.quay.io443
Fournit des images de conteneur de base.
cdn05.quay.io443
Fournit des images de conteneur de base.
cdn06.quay.io443
Fournit des images de conteneur de base.
à propos de SSO.redhat.com443
C’est nécessaire. Le site https://console.redhat.com/openshift utilise l’authentification de sso.redhat.com pour télécharger le secret de traction et utiliser les solutions Red Hat SaaS pour faciliter la surveillance de vos abonnements, de l’inventaire des clusters, des rapports de rétrofacturation, etc.
bienvenue sur Quay-registry.s3.amazonaws.com443
Fournit des images de conteneur de base.
ajouter au panier Quayio-production-s3.s3.amazonaws.com443
Fournit des images de conteneur de base.
Registry.access.redhat.com443
Héberge toutes les images du conteneur qui sont stockées sur le catalogue Ecosytem Red Hat. De plus, le registre donne accès à l’outil odo CLI qui aide les développeurs à s’appuyer sur OpenShift et Kubernetes.
Access.redhat.com443
C’est nécessaire. Héberge un magasin de signature dont un client conteneur a besoin pour vérifier les images lors de leur retrait de register.access.redhat.com.
Registry.connect.redhat.com443
Requis pour toutes les images tierces et les opérateurs certifiés.
console.redhat.com443
C’est nécessaire. Autorise les interactions entre le cluster et OpenShift Console Manager pour activer les fonctionnalités, telles que la planification des mises à niveau.
à propos de SSO.redhat.com443
Le site https://console.redhat.com/openshift utilise l’authentification de sso.redhat.com.
le site pull.q1w2.quay.rhcloud.com443
Fournit des images de conteneur de base en tant que repli lorsque quay.io n’est pas disponible.
catalogue.redhat.com443
Les sites Registry.access.redhat.com et https://registry.redhat.io redirigent vers catalog.redhat.com.
le site OIDC.op1.openshiftapps.com443
Utilisé par ROSA pour l’implémentation STS avec la configuration OIDC gérée.
Autoriser les URL de télémétrie suivantes:
Expand Domaine Le port Fonction CERT-api.access.redhat.com443
Requis pour la télémétrie.
API.access.redhat.com443
Requis pour la télémétrie.
infogw.api.openshift.com443
Requis pour la télémétrie.
console.redhat.com443
Requis pour la télémétrie et Red Hat Insights.
le site Observatorium-mst.api.openshift.com443
Requis pour la télémétrie spécifique à OpenShift gérée.
bienvenue sur Observatorium.api.openshift.com443
Requis pour la télémétrie spécifique à OpenShift gérée.
Les clusters gérés nécessitent d’activer la télémétrie pour permettre à Red Hat de réagir plus rapidement aux problèmes, de mieux soutenir les clients et de mieux comprendre l’impact des mises à niveau des produits sur les clusters. De plus amples renseignements sur la façon dont les données de surveillance de la santé à distance sont utilisées par Red Hat, voir À propos de la surveillance de la santé à distance dans la section Ressources supplémentaires.
Autoriser les URls d’API Amazon Web Services (AWS) suivantes:
Expand Domaine Le port Fonction .amazonaws.com443
Besoin d’accéder aux services et aux ressources AWS.
Alternativement, si vous choisissez de ne pas utiliser de wildcard pour les API Amazon Web Services (AWS), vous devez autoriser la liste des URL suivantes:
Expand Domaine Le port Fonction ec2.amazonaws.com443
Il est utilisé pour installer et gérer des clusters dans un environnement AWS.
événements.<aws_region>.amazonaws.com443
Il est utilisé pour installer et gérer des clusters dans un environnement AWS.
IAM.amazonaws.com443
Il est utilisé pour installer et gérer des clusters dans un environnement AWS.
itinéraire53.amazonaws.com443
Il est utilisé pour installer et gérer des clusters dans un environnement AWS.
à propos de STS.amazonaws.com443
Il est utilisé pour installer et gérer des clusters dans un environnement AWS, pour les clusters configurés pour utiliser le point de terminaison global d’AWS STS.
le site STS.<aws_region>.amazonaws.com443
Il est utilisé pour installer et gérer des clusters dans un environnement AWS, pour les clusters configurés pour utiliser des points de terminaison régionalisés pour AWS STS. Consultez les points de terminaison régionalisés AWS STS pour plus d’informations.
étiquettes.us-east-1.amazonaws.com443
Il est utilisé pour installer et gérer des clusters dans un environnement AWS. Ce point de terminaison est toujours nous-Est-1, quelle que soit la région dans laquelle le cluster est déployé.
ec2.<aws_region>.amazonaws.com443
Il est utilisé pour installer et gérer des clusters dans un environnement AWS.
élastique d’équilibrage.<aws_region>.amazonaws.com443
Il est utilisé pour installer et gérer des clusters dans un environnement AWS.
étiquettes.<aws_region>.amazonaws.com443
Autorise l’attribution de métadonnées sur les ressources AWS sous forme de balises.
Autoriser les URL OpenShift suivantes:
Expand Domaine Le port Fonction le site Mirror.openshift.com443
Il est utilisé pour accéder au contenu et aux images d’installation en miroir. Ce site est également une source de signatures d’images de libération.
API.openshift.com443
Il est utilisé pour vérifier si des mises à jour sont disponibles pour le cluster.
Autoriser l’ingénierie de la fiabilité du site (SRE) et les URL de gestion suivantes:
Expand Domaine Le port Fonction API.pagerduty.com443
Ce service d’alerte est utilisé par le gestionnaire d’alertes inclus pour envoyer des alertes notifiant Red Hat SRE d’un événement pour agir.
événements.pagerduty.com443
Ce service d’alerte est utilisé par le gestionnaire d’alertes inclus pour envoyer des alertes notifiant Red Hat SRE d’un événement pour agir.
API.deadmanssnitch.com443
Le service d’alerte utilisé par Red Hat OpenShift Service sur AWS pour envoyer des pings périodiques indiquant si le cluster est disponible et en cours d’exécution.
à propos de nosnch.in443
Le service d’alerte utilisé par Red Hat OpenShift Service sur AWS pour envoyer des pings périodiques indiquant si le cluster est disponible et en cours d’exécution.
HTTP-inputs-osdsecuritylogs.splunkcloud.com443
C’est nécessaire. Utilisé par le splunk-forwarder-operator comme point de terminaison de journalisation à utiliser par Red Hat SRE pour l’alerte log-based.
le site SFTP.access.redhat.com (recommandé)
22
Le serveur SFTP utilisé par l’opérateur must-collectther pour télécharger des journaux de diagnostic pour aider à résoudre les problèmes avec le cluster.
11.1.6. Les prochaines étapes Copier lienLien copié sur presse-papiers!
11.2. Comprendre le flux de travail de déploiement ROSA Copier lienLien copié sur presse-papiers!
Avant de créer un cluster Red Hat OpenShift Service sur AWS (ROSA), vous devez remplir les prérequis AWS, vérifier que les quotas de service AWS requis sont disponibles et configurer votre environnement.
Ce document donne un aperçu des étapes du flux de travail ROSA et fait référence à des ressources détaillées pour chaque étape.
AWS Security Token Service (STS) est le mode d’identification recommandé pour l’installation et l’interaction avec les clusters sur Red Hat OpenShift Service sur AWS car il offre une sécurité accrue.
11.2.1. Aperçu du flux de travail de déploiement ROSA Copier lienLien copié sur presse-papiers!
Il est possible de suivre les étapes de flux de travail décrites dans cette section pour configurer et accéder à un cluster Red Hat OpenShift Service sur AWS (ROSA).
- Effectuez les prérequis AWS. Afin de déployer un cluster ROSA, votre compte AWS doit répondre aux exigences préalables.
- Examinez les quotas de service AWS requis. Afin de vous préparer au déploiement de votre cluster, examinez les quotas de service AWS nécessaires à l’exécution d’un cluster ROSA.
- Configurez votre compte AWS. Avant de créer un cluster ROSA, vous devez activer ROSA dans votre compte AWS, installer et configurer l’outil AWS CLI (aws) et vérifier la configuration de l’outil AWS CLI.
- Installez les outils ROSA et OpenShift CLI et vérifiez les quotas de service AWS. Installez et configurez le ROSA CLI (rosa) et l’OpenShift CLI (oc). Il est possible de vérifier si les quotas de ressources AWS requis sont disponibles à l’aide de l’ILC ROSA.
- Créez un cluster ROSA ou Créez un cluster ROSA à l’aide d’AWS PrivateLink. Le ROSA CLI (rosa) permet de créer un cluster. En option, vous pouvez créer un cluster ROSA avec AWS PrivateLink.
- Accédez à un cluster. Au besoin, vous pouvez configurer un fournisseur d’identité et accorder des privilèges d’administrateur de cluster aux utilisateurs du fournisseur d’identité. Il est également possible d’accéder rapidement à un cluster nouvellement déployé en configurant un utilisateur cluster-admin.
- Annuler l’accès à un cluster ROSA pour un utilisateur. Il est possible de révoquer l’accès à un cluster ROSA d’un utilisateur en utilisant le ROSA CLI ou la console web.
- Supprimez un cluster ROSA. Il est possible de supprimer un cluster ROSA en utilisant le ROSA CLI (rosa).
11.3. Quotas de service AWS requis Copier lienLien copié sur presse-papiers!
Consultez cette liste des quotas de service Amazon Web Service (AWS) requis pour exécuter un service Red Hat OpenShift sur AWS cluster.
AWS Security Token Service (STS) est le mode d’identification recommandé pour l’installation et l’interaction avec les clusters sur Red Hat OpenShift Service sur AWS car il offre une sécurité accrue.
11.3.1. Quotas de service AWS requis Copier lienLien copié sur presse-papiers!
Le tableau ci-dessous décrit les quotas de service AWS et les niveaux requis pour créer et exécuter un service Red Hat OpenShift sur le cluster AWS. Bien que la plupart des valeurs par défaut conviennent à la plupart des charges de travail, vous devrez peut-être demander un quota supplémentaire pour les cas suivants:
- Les clusters ROSA nécessitent un quota minimum de service AWS EC2 de 100 vCPU pour assurer la création, la disponibilité et les mises à niveau de clusters. La valeur maximale par défaut pour les vCPU assignés aux instances Amazon EC2 d’exécution à la demande standard est 5. Donc, si vous n’avez pas créé un cluster ROSA en utilisant le même compte AWS précédemment, vous devez demander un quota EC2 supplémentaire pour les instances de Running On-Demand Standard (A, C, D, H, I, M, R, T, Z).
- Certaines fonctionnalités de configuration de cluster optionnelles, telles que des groupes de sécurité personnalisés, peuvent vous obliger à demander un quota supplémentaire. Ainsi, parce que ROSA associe 1 groupe de sécurité à des interfaces réseau dans les pools de machines de travail par défaut, et que le quota par défaut pour les groupes de sécurité par interface réseau est de 5, si vous souhaitez ajouter 5 groupes de sécurité personnalisés, vous devez demander un quota supplémentaire, car cela porterait le nombre total de groupes de sécurité sur les interfaces réseau des travailleurs à 6.
Le SDK AWS permet à ROSA de vérifier les quotas, mais le calcul AWS SDK ne tient pas compte de votre utilisation existante. Il est donc possible que le contrôle des quotas puisse passer dans le SDK AWS, mais la création de cluster peut échouer. Afin de résoudre ce problème, augmentez votre quota.
Lorsque vous devez modifier ou augmenter un quota spécifique, consultez la documentation d’Amazon sur la demande d’augmentation de quota. Les demandes de quotas importantes sont soumises à Amazon Support pour examen, et prennent un certain temps pour être approuvées. En cas d’urgence, contactez AWS Support.
| Le nom du quota | Code de service | Code de quota | AWS par défaut | Le minimum requis | Description |
|---|---|---|---|---|---|
| Instances en cours d’exécution (A, C, D, H, I, M, R, T, Z) | ec2 | L-1216C47A | 5 | 100 | Le nombre maximal de vCPU assignés aux instances Running On-Demand Standard (A, C, D, H, I, M, R, T, Z). La valeur par défaut de 5 vCPUs n’est pas suffisante pour créer des clusters ROSA. |
| Stockage pour stockage de volume SSD à usage général (gp2) dans TiB | EBS | L-D18FCD1D | 50 | 300 | La quantité de stockage agrégée maximale, en TiB, qui peut être fournie sur des volumes SSD à usage général (gp2) dans cette région. |
| Stockage pour stockage de volume SSD à usage général (gp3) dans TiB | EBS | L-7A658B76 | 50 | 300 | La quantité de stockage agrégée maximale, en TiB, qui peut être fournie sur des volumes SSD à usage général (gp3) dans cette région. 300 TIB de stockage est le minimum requis pour une performance optimale. |
| Entreposage pour les volumes IOPS SSD (io1) provisoires en TiB | EBS | L-FD252861 | 50 | 300 | La quantité de stockage agrégée maximale, en TiB, qui peut être approvisionnée sur les volumes de SSD IOPS provisoires (io1) dans cette région. 300 TIB de stockage est le minimum requis pour une performance optimale. |
| Le nom du quota | Code de service | Code de quota | AWS par défaut | Le minimum requis | Description |
|---|---|---|---|---|---|
| EC2-VPC Elastic IPs | ec2 | L-0263D0A3 | 5 | 5 | Le nombre maximal d’adresses IP élastiques que vous pouvez allouer pour EC2-VPC dans cette région. |
| Le VPCS par région | le VPC | L-F678F1CE | 5 | 5 | Le nombre maximal de VPC par région. Ce quota est directement lié au nombre maximal de passerelles Internet par région. |
| Passerelles Internet par région | le VPC | L-A4707A72 | 5 | 5 | Le nombre maximal de passerelles Internet par région. Ce quota est directement lié au nombre maximal de VPC par région. Afin d’augmenter ce quota, augmenter le nombre de VPC par région. |
| Interfaces réseau par région | le VPC | L-DF5E4CA3 | 5 000 | 5 000 | Le nombre maximal d’interfaces réseau par région. |
| Groupes de sécurité par interface réseau | le VPC | L-2AFB9258 | 5 | 5 | Le nombre maximum de groupes de sécurité par interface réseau. Ce quota, multiplié par le quota pour les règles par groupe de sécurité, ne peut excéder 1000. |
| Instantanés par région | EBS | L-309BACF6 | 10 000 | 10 000 | Le nombre maximal d’instantanés par région |
| IOPS for Provisioned IOPS SSD (Io1) volumes | EBS | L-B3A130E6 | 300 000 | 300 000 | Le nombre total maximal d’IOPS pouvant être approvisionné entre les volumes prévus de DDD (io1) de l’IOPS dans cette région. |
| Balanceurs de charge d’application par région | élasticité de charge | L-53DA6B97 | 50 | 50 | Le nombre maximal d’équilibreurs de charge d’application pouvant exister dans chaque région. |
| Balanceurs de charge classiques par région | élasticité de charge | L-E9E9831D | 20 | 20 | Le nombre maximal d’équilibreurs de charge classiques pouvant exister dans chaque région. |
11.3.2. Les prochaines étapes Copier lienLien copié sur presse-papiers!
11.4. Configuration de votre compte AWS Copier lienLien copié sur presse-papiers!
Après avoir rempli les conditions préalables AWS, configurez votre compte AWS et activez le service Red Hat OpenShift sur AWS (ROSA).
AWS Security Token Service (STS) est le mode d’identification recommandé pour l’installation et l’interaction avec les clusters sur Red Hat OpenShift Service sur AWS car il offre une sécurité accrue.
11.4.1. Configuration de votre compte AWS Copier lienLien copié sur presse-papiers!
Afin de configurer votre compte AWS pour utiliser le service ROSA, remplissez les étapes suivantes.
Conditions préalables
- Examiner et compléter les prérequis et les politiques de déploiement.
- Créez un compte Red Hat, si vous n’en avez pas déjà un. Ensuite, vérifiez votre email pour obtenir un lien de vérification. Il vous faudra ces informations d’identification pour installer ROSA.
Procédure
Connectez-vous au compte Amazon Web Services (AWS) que vous souhaitez utiliser.
Il est recommandé d’exécuter un compte AWS dédié pour exécuter des clusters de production. Lorsque vous utilisez AWS Organizations, vous pouvez utiliser un compte AWS au sein de votre organisation ou en créer un nouveau.
Lorsque vous utilisez AWS Organizations et que vous devez faire appliquer une stratégie de contrôle des services (SCP) au compte AWS que vous envisagez d’utiliser, consultez AWS Prérequis pour plus de détails sur le SCP minimum requis.
Dans le cadre du processus de création de clusters, rosa établit un utilisateur de l’IAM osdCcsAdmin. Cet utilisateur utilise les informations d’identification IAM que vous fournissez lors de la configuration du CLI AWS.
NoteCet utilisateur dispose d’un accès programmatique activé et de la politique AdministratorAccess qui lui est associée.
Activer le service ROSA dans la console AWS.
- Connectez-vous à votre compte AWS.
- Afin d’activer ROSA, accédez au service ROSA et sélectionnez Activer OpenShift.
Installez et configurez le CLI AWS.
Consultez la documentation de l’interface de ligne de commande AWS pour installer et configurer le CLI AWS pour votre système d’exploitation.
Indiquez les corrects aws_access_key_id et aws_secret_access_key dans le fichier .aws/credentials. Consultez les bases de configuration AWS dans la documentation AWS.
Définissez une région AWS par défaut.
NoteIl est recommandé de définir la région AWS par défaut en utilisant la variable d’environnement.
Le service ROSA évalue les régions dans l’ordre de priorité suivant:
- La région spécifiée lors de l’exécution de la commande rosa avec le drapeau --région.
- La région définie dans la variable d’environnement AWS_DEFAULT_REGION. Consultez les variables Environnement pour configurer le CLI AWS dans la documentation AWS.
- La région par défaut définie dans votre fichier de configuration AWS. Consultez la configuration rapide avec aws configuré dans la documentation AWS.
En option : Configurez vos paramètres et informations d’identification AWS CLI à l’aide d’un profil AWS nommé. dans l’ordre de priorité suivant, Rosa évalue les profils nommés AWS:
- Le profil spécifié lors de l’exécution de la commande rosa avec le drapeau --profile.
- Le profil défini dans la variable d’environnement AWS_PROFILE. Consultez les profils nommés dans la documentation AWS.
Assurez-vous que le CLI AWS est installé et configuré correctement en exécutant la commande suivante pour interroger l’API AWS:
aws sts get-caller-identity --output text
$ aws sts get-caller-identity --output textCopy to Clipboard Copied! Toggle word wrap Toggle overflow Exemple de sortie
<aws_account_id> arn:aws:iam::<aws_account_id>:user/<username> <aws_user_id>
<aws_account_id> arn:aws:iam::<aws_account_id>:user/<username> <aws_user_id>Copy to Clipboard Copied! Toggle word wrap Toggle overflow Après avoir terminé ces étapes, installez ROSA.
11.4.2. Les prochaines étapes Copier lienLien copié sur presse-papiers!
11.5. Installation du service Red Hat OpenShift sur AWS (ROSA) CLI, rosa Copier lienLien copié sur presse-papiers!
Après avoir configuré votre compte AWS, installez et configurez le Red Hat OpenShift Service sur AWS (ROSA) CLI, rosa.
AWS Security Token Service (STS) est le mode d’identification recommandé pour l’installation et l’interaction avec les clusters sur Red Hat OpenShift Service sur AWS car il offre une sécurité accrue.
11.5.1. Installation et configuration du ROSA CLI Copier lienLien copié sur presse-papiers!
Installez et configurez le service Red Hat OpenShift sur AWS (ROSA) CLI, rosa. Il est également possible d’installer le CLI OpenShift (oc) et de vérifier si les quotas de ressources AWS requis sont disponibles à l’aide du ROSA CLI (rosa).
Conditions préalables
- Examinez et complétez les prérequis AWS et les politiques ROSA.
- Créez un compte Red Hat, si vous n’en avez pas déjà un. Ensuite, vérifiez votre email pour obtenir un lien de vérification. Il vous faudra ces informations d’identification pour installer ROSA.
- Configurez votre compte AWS et activez le service ROSA dans votre compte AWS.
Procédure
Installez rosa, le service Red Hat OpenShift sur l’interface de ligne de commande AWS (CLI).
- Cliquez ici pour télécharger la dernière version de la ROSA CLI pour votre système d’exploitation.
- Facultatif: Renommer le fichier exécutable que vous avez téléchargé sur rosa. Cette documentation utilise rosa pour se référer au fichier exécutable.
En option: Ajoutez rosa à votre chemin.
Exemple :
mv rosa /usr/local/bin/rosa
$ mv rosa /usr/local/bin/rosaCopy to Clipboard Copied! Toggle word wrap Toggle overflow Entrez la commande suivante pour vérifier votre installation:
rosa
$ rosaCopy to Clipboard Copied! Toggle word wrap Toggle overflow Exemple de sortie
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Facultatif: Générer les scripts d’achèvement de la commande pour le ROSA CLI. L’exemple suivant génère les scripts d’achèvement Bash pour une machine Linux:
rosa completion bash | sudo tee /etc/bash_completion.d/rosa
$ rosa completion bash | sudo tee /etc/bash_completion.d/rosaCopy to Clipboard Copied! Toggle word wrap Toggle overflow Facultatif: Activer l’achèvement de la commande pour le ROSA CLI à partir de votre terminal existant. L’exemple suivant permet l’achèvement de Bash pour rosa dans un terminal existant sur une machine Linux:
source /etc/bash_completion.d/rosa
$ source /etc/bash_completion.d/rosaCopy to Clipboard Copied! Toggle word wrap Toggle overflow
Connectez-vous à votre compte Red Hat avec rosa.
Entrez la commande suivante.
rosa login
$ rosa loginCopy to Clipboard Copied! Toggle word wrap Toggle overflow <my_offline_access_token> par votre jeton.
Exemple de sortie
To login to your Red Hat account, get an offline access token at https://console.redhat.com/openshift/token/rosa ? Copy the token and paste it here: <my-offline-access-token>
To login to your Red Hat account, get an offline access token at https://console.redhat.com/openshift/token/rosa ? Copy the token and paste it here: <my-offline-access-token>Copy to Clipboard Copied! Toggle word wrap Toggle overflow Exemple de sortie continue
I: Logged in as 'rh-rosa-user' on 'https://api.openshift.com'
I: Logged in as 'rh-rosa-user' on 'https://api.openshift.com'Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Entrez la commande suivante pour vérifier que votre compte AWS dispose des autorisations nécessaires.
rosa verify permissions
$ rosa verify permissionsCopy to Clipboard Copied! Toggle word wrap Toggle overflow Exemple de sortie
I: Validating SCP policies... I: AWS SCP policies ok
I: Validating SCP policies... I: AWS SCP policies okCopy to Clipboard Copied! Toggle word wrap Toggle overflow NoteCette commande vérifie les autorisations uniquement pour les clusters ROSA qui n’utilisent pas AWS Security Token Service (STS).
Assurez-vous que votre compte AWS dispose du quota nécessaire pour déployer un service Red Hat OpenShift sur le cluster AWS.
rosa verify quota --region=us-west-2
$ rosa verify quota --region=us-west-2Copy to Clipboard Copied! Toggle word wrap Toggle overflow Exemple de sortie
I: Validating AWS quota... I: AWS quota ok
I: Validating AWS quota... I: AWS quota okCopy to Clipboard Copied! Toggle word wrap Toggle overflow NoteIl arrive que votre quota AWS varie selon les régions. En cas d’erreur, essayez une autre région.
Lorsque vous devez augmenter votre quota, accédez à votre console AWS et demandez une augmentation de quota pour le service qui a échoué.
Après le passage des autorisations et des contrôles des quotas, passez à l’étape suivante.
Créez votre compte AWS pour le déploiement de clusters:
Exécutez la commande suivante pour vérifier que vos identifiants Red Hat et AWS sont configurés correctement. Assurez-vous que votre ID de compte AWS, votre région par défaut et votre ARN correspondent à ce que vous attendez. En toute sécurité, vous pouvez ignorer les lignes commençant par OCM pour l’instant.
rosa whoami
$ rosa whoamiCopy to Clipboard Copied! Toggle word wrap Toggle overflow Exemple de sortie
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Initialisez votre compte AWS. Cette étape exécute un modèle CloudFormation qui prépare votre compte AWS pour le déploiement et la gestion de clusters. Cette étape prend généralement 1-2 minutes à compléter.
rosa init
$ rosa initCopy to Clipboard Copied! Toggle word wrap Toggle overflow Exemple de sortie
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Installez l’OpenShift CLI (oc) à partir du ROSA CLI.
Entrez cette commande pour télécharger la dernière version du CLI oc:
rosa download oc
$ rosa download ocCopy to Clipboard Copied! Toggle word wrap Toggle overflow - Après avoir téléchargé le CLI oc, décompressez-le et ajoutez-le à votre chemin.
Entrez cette commande pour vérifier que le CLI oc est installé correctement:
rosa verify oc
$ rosa verify ocCopy to Clipboard Copied! Toggle word wrap Toggle overflow
Après avoir installé ROSA, vous êtes prêt à créer un cluster.
11.5.2. Les prochaines étapes Copier lienLien copié sur presse-papiers!
- Créez un cluster ROSA ou créez un cluster AWS PrivateLink sur ROSA.
11.6. Créer un cluster ROSA sans AWS STS Copier lienLien copié sur presse-papiers!
Après avoir configuré votre environnement et installé Red Hat OpenShift Service sur AWS (ROSA), créez un cluster.
Ce document décrit comment configurer un cluster ROSA. Alternativement, vous pouvez créer un cluster ROSA avec AWS PrivateLink.
AWS Security Token Service (STS) est le mode d’identification recommandé pour l’installation et l’interaction avec les clusters sur Red Hat OpenShift Service sur AWS car il offre une sécurité accrue.
11.6.1. Créer votre cluster Copier lienLien copié sur presse-papiers!
Il est possible de créer un Red Hat OpenShift Service sur AWS (ROSA) à l’aide du ROSA CLI (rosa).
Conditions préalables
« vous avez installé Red Hat OpenShift Service sur AWS.
Les PCV AWS partagés ne sont pas actuellement pris en charge pour les installations ROSA.
Procédure
Il est possible de créer un cluster en utilisant les paramètres par défaut ou en spécifiant des paramètres personnalisés en utilisant le mode interactif. Afin d’afficher d’autres options lors de la création d’un cluster, entrez la commande rosa create cluster --help.
La création d’un cluster peut prendre jusqu’à 40 minutes.
NoteDes zones de disponibilité multiples (AZ) sont recommandées pour les charges de travail de production. La valeur par défaut est une seule zone de disponibilité. Utilisez --aide pour un exemple de la façon de configurer cette option manuellement ou utilisez le mode interactif pour être invité pour ce paramètre.
Créer votre cluster avec les paramètres du cluster par défaut:
rosa create cluster --cluster-name=<cluster_name>
$ rosa create cluster --cluster-name=<cluster_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow Exemple de sortie
I: Creating cluster with identifier '1de87g7c30g75qechgh7l5b2bha6r04e' and name 'rh-rosa-test-cluster1' I: To view list of clusters and their status, run `rosa list clusters` I: Cluster 'rh-rosa-test-cluster1' has been created. I: Once the cluster is 'Ready' you will need to add an Identity Provider and define the list of cluster administrators. See `rosa create idp --help` and `rosa create user --help` for more information. I: To determine when your cluster is Ready, run `rosa describe cluster rh-rosa-test-cluster1`.
I: Creating cluster with identifier '1de87g7c30g75qechgh7l5b2bha6r04e' and name 'rh-rosa-test-cluster1' I: To view list of clusters and their status, run `rosa list clusters` I: Cluster 'rh-rosa-test-cluster1' has been created. I: Once the cluster is 'Ready' you will need to add an Identity Provider and define the list of cluster administrators. See `rosa create idp --help` and `rosa create user --help` for more information. I: To determine when your cluster is Ready, run `rosa describe cluster rh-rosa-test-cluster1`.Copy to Clipboard Copied! Toggle word wrap Toggle overflow Créer un cluster à l’aide d’invites interactives:
rosa create cluster --interactive
$ rosa create cluster --interactiveCopy to Clipboard Copied! Toggle word wrap Toggle overflow Afin de configurer vos plages IP réseau, vous pouvez utiliser les plages par défaut suivantes. Lorsque vous utilisez le mode manuel, utilisez la commande rosa create cluster --help | grep cidr. En mode interactif, vous êtes invité pour les paramètres.
- Nœud CIDR: 10.0.0.0/16
- CIDR de service: 172.30.0.0/16
- Dose CIDR: 10.128.0.0/14
Entrez la commande suivante pour vérifier l’état de votre cluster. Lors de la création de clusters, le champ de l’État à partir de la sortie passera de l’attente à l’installation, et enfin à la préparation.
rosa describe cluster --cluster=<cluster_name>
$ rosa describe cluster --cluster=<cluster_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow Exemple de sortie
Copy to Clipboard Copied! Toggle word wrap Toggle overflow NoteEn cas d’échec de l’installation ou que le champ État ne change pas pour être prêt après 40 minutes, vérifiez la documentation de dépannage de l’installation pour plus de détails.
Faites le suivi de la progression de la création de cluster en regardant les journaux d’installateur OpenShift:
rosa logs install --cluster=<cluster_name> --watch
$ rosa logs install --cluster=<cluster_name> --watchCopy to Clipboard Copied! Toggle word wrap Toggle overflow
11.6.2. Les prochaines étapes Copier lienLien copié sur presse-papiers!
11.7. Configuration d’un cluster privé Copier lienLien copié sur presse-papiers!
Le Red Hat OpenShift Service sur AWS cluster peut être privé afin que les applications internes puissent être hébergées à l’intérieur d’un réseau d’entreprise. En outre, les clusters privés peuvent être configurés pour n’avoir que des points de terminaison internes d’API pour une sécurité accrue.
Les paramètres de confidentialité peuvent être configurés pendant la création de cluster ou après la création d’un cluster.
11.7.1. Activer le cluster privé sur un nouveau cluster Copier lienLien copié sur presse-papiers!
Lors de la création d’un nouveau service Red Hat OpenShift sur AWS, vous pouvez activer le paramètre cluster privé.
Les clusters privés ne peuvent pas être utilisés avec le service de jetons de sécurité AWS (STS). Cependant, STS prend en charge les clusters AWS PrivateLink.
Conditions préalables
AWS VPC Peering, VPN, DirectConnect ou TransitGateway a été configuré pour permettre un accès privé.
Procédure
Entrez la commande suivante pour créer un nouveau cluster privé.
rosa create cluster --cluster-name=<cluster_name> --private
$ rosa create cluster --cluster-name=<cluster_name> --private
Alternativement, utilisez --interactive pour être invité pour chaque option de cluster.
11.7.2. Activer un cluster privé sur un cluster existant Copier lienLien copié sur presse-papiers!
Après la création d’un cluster, vous pouvez plus tard activer le cluster pour être privé.
Les clusters privés ne peuvent pas être utilisés avec le service de jetons de sécurité AWS (STS). Cependant, STS prend en charge les clusters AWS PrivateLink.
Conditions préalables
AWS VPC Peering, VPN, DirectConnect ou TransitGateway a été configuré pour permettre un accès privé.
Procédure
Entrez la commande suivante pour activer l’option --privée sur un cluster existant.
rosa edit cluster --cluster=<cluster_name> --private
$ rosa edit cluster --cluster=<cluster_name> --private
La transition de votre cluster entre privé et public peut prendre plusieurs minutes.
11.8. La suppression de l’accès à un cluster ROSA Copier lienLien copié sur presse-papiers!
Effacer l’accès à un Red Hat OpenShift Service sur AWS (ROSA) cluster en utilisant la ligne de commande rosa.
AWS Security Token Service (STS) est le mode d’identification recommandé pour l’installation et l’interaction avec les clusters sur Red Hat OpenShift Service sur AWS car il offre une sécurité accrue.
11.8.1. La révocation de l’accès dédié-admin à l’aide de la ROSA CLI Copier lienLien copié sur presse-papiers!
Il est possible de révoquer l’accès pour un utilisateur administrateur dédié si vous êtes l’utilisateur qui a créé le cluster, l’utilisateur administrateur de l’organisation ou l’utilisateur super administrateur.
Conditions préalables
- Dans votre cluster, vous avez ajouté un fournisseur d’identité (IDP).
- Il y a le nom d’utilisateur IDP pour l’utilisateur dont vous révoquez les privilèges.
- Il est connecté au cluster.
Procédure
Entrez la commande suivante pour révoquer l’accès admin dédié d’un utilisateur:
rosa revoke user dedicated-admin --user=<idp_user_name> --cluster=<cluster_name>
$ rosa revoke user dedicated-admin --user=<idp_user_name> --cluster=<cluster_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow Entrez la commande suivante pour vérifier que votre utilisateur n’a plus d’accès admin dédié. La sortie ne répertorie pas l’utilisateur révoqué.
oc get groups dedicated-admins
$ oc get groups dedicated-adminsCopy to Clipboard Copied! Toggle word wrap Toggle overflow
11.8.2. La révocation de l’accès cluster-admin à l’aide de la ROSA CLI Copier lienLien copié sur presse-papiers!
Il n’y a que l’utilisateur qui a créé le cluster qui peut révoquer l’accès pour les utilisateurs de cluster-admin.
Conditions préalables
- Dans votre cluster, vous avez ajouté un fournisseur d’identité (IDP).
- Il y a le nom d’utilisateur IDP pour l’utilisateur dont vous révoquez les privilèges.
- Il est connecté au cluster.
Procédure
Entrez la commande suivante pour révoquer l’accès cluster-admin d’un utilisateur:
rosa revoke user cluster-admins --user=myusername --cluster=mycluster
$ rosa revoke user cluster-admins --user=myusername --cluster=myclusterCopy to Clipboard Copied! Toggle word wrap Toggle overflow Entrez la commande suivante pour vérifier que l’utilisateur n’a plus accès cluster-admin. La sortie ne répertorie pas l’utilisateur révoqué.
oc get groups cluster-admins
$ oc get groups cluster-adminsCopy to Clipboard Copied! Toggle word wrap Toggle overflow
11.9. La suppression d’un cluster ROSA Copier lienLien copié sur presse-papiers!
Effacer un Red Hat OpenShift Service sur AWS (ROSA) cluster en utilisant la ligne de commande rosa.
AWS Security Token Service (STS) est le mode d’identification recommandé pour l’installation et l’interaction avec les clusters sur Red Hat OpenShift Service sur AWS car il offre une sécurité accrue.
11.9.1. Conditions préalables Copier lienLien copié sur presse-papiers!
Lorsque Red Hat OpenShift Service sur AWS a créé un VPC, vous devez supprimer les éléments suivants de votre cluster avant de pouvoir supprimer votre cluster avec succès:
- Configurations réseau, telles que les configurations VPN et les connexions de peering VPC
- Les services supplémentaires qui ont été ajoutés au VPC
Lorsque ces configurations et services restent, le cluster ne supprime pas correctement.
11.9.2. La suppression d’un cluster ROSA et des ressources spécifiques au groupe IAM Copier lienLien copié sur presse-papiers!
Il est possible de supprimer un service Red Hat OpenShift sur AWS (ROSA) avec le cluster AWS Security Token Service (STS) en utilisant le ROSA CLI (rosa) ou Red Hat OpenShift Cluster Manager.
Après avoir supprimé le cluster, vous pouvez nettoyer les ressources de gestion des identités et des accès (IAM) spécifiques au cluster dans votre compte AWS en utilisant le ROSA CLI (rosa). Les ressources spécifiques au cluster comprennent les rôles d’opérateur et le fournisseur OpenID Connect (OIDC).
La suppression de cluster doit être terminée avant de supprimer les ressources IAM, car les ressources sont utilisées dans les processus de suppression et de nettoyage du cluster.
Lorsque des add-ons sont installés, la suppression du cluster prend plus de temps car les add-ons sont désinstallés avant que le cluster ne soit supprimé. Le temps dépend du nombre et de la taille des add-ons.
Lorsque le cluster qui a créé le VPC pendant l’installation est supprimé, le VPC créé par le programme d’installation associé sera également supprimé, entraînant la défaillance de tous les clusters qui utilisent le même VPC. De plus, toutes les ressources créées avec la même paire de clés-valeur tagSet des ressources créées par le programme d’installation et étiquetées avec une valeur de propriété seront également supprimées.
Conditions préalables
- « vous avez installé un cluster ROSA.
- L’installation et la configuration de la dernière ROSA CLI (rosa) sur votre hôte d’installation.
Procédure
Demandez l’ID de cluster, les noms de ressource Amazon (ARN) pour les rôles d’opérateur spécifiques au cluster et l’URL du point de terminaison pour le fournisseur OIDC:
rosa describe cluster --cluster=<cluster_name>
$ rosa describe cluster --cluster=<cluster_name>1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- <cluster_name> par le nom de votre cluster.
Exemple de sortie
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Liste l’identifiant du cluster.
- 2
- Indique les ARN pour les rôles d’opérateur spécifiques au cluster. Dans la sortie de l’échantillon, par exemple, l’ARN pour le rôle requis par l’opérateur de configuration de machine est arn:aws:iam::<aws_account_id>:role/mycluster-x4q9-openshift-machine-api-aws-cloud-credentials.
- 3
- Affiche l’URL du point de terminaison pour le fournisseur OIDC spécifique au cluster.
ImportantL’ID de cluster doit supprimer les ressources STS spécifiques au cluster en utilisant le ROSA CLI (rosa) une fois le cluster supprimé.
Effacer le cluster:
De supprimer le cluster en utilisant Red Hat OpenShift Cluster Manager:
- Accédez à OpenShift Cluster Manager.
- Cliquez sur le menu Options à côté de votre cluster et sélectionnez Supprimer le cluster.
- Entrez le nom de votre cluster à l’invite et cliquez sur Supprimer.
De supprimer le cluster à l’aide de la ROSA CLI (rosa):
Entrez la commande suivante pour supprimer le cluster et regarder les journaux, en remplaçant <cluster_name> par le nom ou l’ID de votre cluster:
rosa delete cluster --cluster=<cluster_name> --watch
$ rosa delete cluster --cluster=<cluster_name> --watchCopy to Clipboard Copied! Toggle word wrap Toggle overflow ImportantIl faut attendre que la suppression du cluster soit terminée avant de supprimer les rôles Opérateur et le fournisseur OIDC. Les rôles d’opérateur spécifiques au cluster sont nécessaires pour nettoyer les ressources créées par les opérateurs OpenShift. Les opérateurs utilisent le fournisseur OIDC pour s’authentifier.
Effacer le fournisseur OIDC que les opérateurs de cluster utilisent pour authentifier:
rosa delete oidc-provider -c <cluster_id> --mode auto
$ rosa delete oidc-provider -c <cluster_id> --mode auto1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- <cluster_id> par l’ID du cluster.
NoteL’option -y vous permet de répondre automatiquement oui aux invitations.
En option. Effacer les rôles IAM d’opérateur spécifiques au cluster:
ImportantLes rôles IAM à l’échelle du compte peuvent être utilisés par d’autres clusters ROSA dans le même compte AWS. Les rôles ne sont supprimés que s’ils ne sont pas requis par d’autres clusters.
rosa delete operator-roles -c <cluster_id> --mode auto
$ rosa delete operator-roles -c <cluster_id> --mode auto1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- <cluster_id> par l’ID du cluster.
Résolution de problèmes
- Lorsque le cluster ne peut pas être supprimé en raison des rôles IAM manquants, voir Réparation supplémentaire d’un cluster qui ne peut pas être supprimé.
Lorsque le cluster ne peut pas être supprimé pour d’autres raisons:
- Assurez-vous qu’il n’y a pas d’ajouts pour votre cluster en attente dans la console hybride Cloud.
- Assurez-vous que toutes les ressources et dépendances AWS ont été supprimées dans la console Web Amazon.
11.10. Commande de référence rapide pour la création de clusters et d’utilisateurs Copier lienLien copié sur presse-papiers!
AWS Security Token Service (STS) est le mode d’identification recommandé pour l’installation et l’interaction avec les clusters sur Red Hat OpenShift Service sur AWS car il offre une sécurité accrue.
11.10.1. Liste de référence rapide de commande Copier lienLien copié sur presse-papiers!
Lorsque vous avez déjà créé votre premier cluster et vos utilisateurs, cette liste peut servir de liste de référence rapide lors de la création de clusters et d’utilisateurs supplémentaires.
Legal Notice
Copier lienLien copié sur presse-papiers!
Copyright © 2025 Red Hat
OpenShift documentation is licensed under the Apache License 2.0 (https://www.apache.org/licenses/LICENSE-2.0).
Modified versions must remove all Red Hat trademarks.
Portions adapted from https://github.com/kubernetes-incubator/service-catalog/ with modifications by Red Hat.
Red Hat, Red Hat Enterprise Linux, the Red Hat logo, the Shadowman logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat Software Collections is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation’s permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.