Installer des clusters ROSA Classic


Red Hat OpenShift Service on AWS 4

Installation, accès et suppression du service OpenShift Red Hat sur les clusters AWS (ROSA).

Red Hat OpenShift Documentation Team

Résumé

Ce document fournit des informations sur la façon d’installer Red Hat OpenShift Service sur les clusters AWS (ROSA). Le document fournit également des détails sur la façon d’accéder à un cluster, de configurer les fournisseurs d’identité, de révoquer l’accès au cluster et de supprimer un cluster.

Note

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.
Note

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

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.

Expand
Tableau 1.1. Défaut ROSA avec les spécifications du cluster STS
ComposanteCaractéristiques par défaut

Comptes et rôles

  • Le préfixe de rôle IAM par défaut: ManagedOpenShift
  • Aucun rôle d’administrateur de cluster créé

Configurations du cluster

  • La version par défaut du cluster: Dernières
  • La région AWS par défaut pour les installations utilisant le Red Hat OpenShift Cluster Manager Hybrid Cloud Console: us-east-1 (États-Unis, Virginie du Nord)
  • Disponibilité: Zone unique pour le plan de données
  • EC2 Instance Metadata Service (IMDS) est activé et permet l’utilisation de IMDSv1 ou IMDSv2 (jeton facultatif)
  • Contrôle pour les projets définis par l’utilisateur: activé

Chiffrement

  • Le stockage en nuage est crypté au repos
  • Le chiffrement supplémentaire etcd n’est pas activé
  • La clé AWS Key Management Service (KMS) par défaut est utilisée comme clé de chiffrement pour les données persistantes

Configuration des nœuds de plan de contrôle

  • Contrôle type d’instance de nœud de plan: m5.2xlarge (8 vCPU, 32 GAB RAM)
  • Comptage des nœuds de plan de contrôle: 3

Configuration des nœuds d’infrastructure

  • Infrastructure Node type d’instance: r5.xlarge (4 vCPU, 32 GAB RAM)
  • Comptage des nœuds d’infrastructure: 2

Calculez la piscine de la machine de nœud

  • Calculer le type d’instance du nœud: m5.xlarge (4 vCPU 16, RAM GiB)
  • Calcul du nombre de nœuds: 2
  • Autoscaling: Non activé
  • Aucune étiquette de nœud supplémentaire

Configuration du réseau

  • Confidentialité des clusters: Public
  • Il faut avoir configuré votre propre Cloud privé virtuel (VPC)
  • Aucun proxy à l’échelle du cluster n’est configuré

Gammes de routage interdomain sans classe (CIDR)

  • CIDR machine: 10.0.0.0/16
  • CIDR de service: 172.30.0.0/16
  • Dose CIDR: 10.128.0.0/14
  • Hôte préfixe: /23

Les rôles et les politiques des clusters

  • Le mode utilisé pour créer les rôles d’opérateur et le fournisseur OpenID Connect (OIDC) : auto

    Note

    Dans le cas des installations utilisant OpenShift Cluster Manager sur la console hybride Cloud, le mode automatique nécessite un rôle de gestionnaire de cluster OpenShift privilégié par l’administrateur.

  • Fonction par défaut: <cluster_name>-<4_digit_random_string>

La stratégie de mise à jour des clusters

  • Des mises à jour individuelles
  • Délai de grâce de 1 heure pour drainer les nœuds

1.2. Comprendre l’association de compte AWS

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.

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.

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

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.

    Note

    Afin 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

  1. Créez un rôle OpenShift Cluster Manager et liez-le à votre organisation Red Hat:

    Note

    Afin 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.

    Note

    Lorsque 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
    Copy to Clipboard Toggle word wrap

    Choisissez les valeurs par défaut dans les instructions pour créer rapidement et lier le rôle.

  2. Créez un rôle d’utilisateur et liez-le à votre compte d’utilisateur Red Hat:

    $ rosa create user-role
    Copy to Clipboard Toggle word wrap

    Choisissez les valeurs par défaut dans les instructions pour créer rapidement et lier le rôle.

    Note

    Le compte d’utilisateur Red Hat doit exister dans l’organisation Red Hat qui est liée à votre rôle OpenShift Cluster Manager.

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

  1. Consultez votre compte AWS pour connaître les rôles et les politiques existants:

    $ rosa list account-roles
    Copy to Clipboard Toggle word wrap
  2. 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
    Copy to Clipboard Toggle word wrap

    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

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

  1. Afin de créer votre configuration OIDC à côté des ressources AWS, exécutez la commande suivante:

    $ rosa create oidc-config --mode=auto --yes
    Copy to Clipboard Toggle word wrap

    Cette commande renvoie les informations suivantes.

    Exemple de sortie

    ? Would you like to create a Managed (Red Hat hosted) OIDC Configuration Yes
    I: Setting up managed OIDC configuration
    I: To create Operator Roles for this OIDC Configuration, run the following command and remember to replace <user-defined> with a prefix of your choice:
    	rosa create operator-roles --prefix <user-defined> --oidc-config-id 13cdr6b
    If you are going to create a Hosted Control Plane cluster please include '--hosted-cp'
    I: Creating OIDC provider using 'arn:aws:iam::4540112244:user/userName'
    ? Create the OIDC provider? Yes
    I: Created OIDC provider with ARN 'arn:aws:iam::4540112244:oidc-provider/dvbwgdztaeq9o.cloudfront.net/13cdr6b'
    Copy to Clipboard Toggle word wrap

    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.

  2. 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>
    1
    Copy to Clipboard Toggle word wrap
    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
      Copy to Clipboard Toggle word wrap

      Exemple de sortie

      13cdr6b
      Copy to Clipboard Toggle word wrap

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
    Copy to Clipboard Toggle word wrap

    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
    Copy to Clipboard Toggle word wrap

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

  1. Accédez à OpenShift Cluster Manager et sélectionnez Créer un cluster.
  2. Dans la page Créer un cluster OpenShift, sélectionnez Créer un cluster dans la ligne Red Hat OpenShift sur AWS (ROSA).
  3. 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.

    Note

    Dans 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.

  4. Cliquez sur Next.
  5. 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.

    Note

    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 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.

  6. 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.
  7. 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.
  8. 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.

      Note

      En 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

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

  1. 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
    Copy to Clipboard Toggle word wrap
    Note

    Lorsque vous utilisez le mode automatique, vous pouvez éventuellement spécifier l’argument -y pour contourner les instructions interactives et confirmer automatiquement les opérations.

  2. 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> \ 
    1
    
    --sts --mode auto 
    2
    Copy to Clipboard Toggle word wrap
    1
    &lt;cluster_name&gt; par le nom de votre cluster.
    2
    Lorsque vous spécifiez --mode auto, la commande rosa create cluster crée automatiquement les rôles IAM d’opérateur spécifiques au cluster et le fournisseur OIDC. Les opérateurs utilisent le fournisseur OIDC pour s’authentifier.
    Note

    Lorsque 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.

  3. Consultez l’état de votre cluster:

    $ rosa describe cluster --cluster <cluster_name|cluster_id>
    Copy to Clipboard Toggle word wrap

    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 ♪

      Note

      En 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.

  4. 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 
    1
    Copy to Clipboard Toggle word wrap
    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

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.

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.
Important

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.

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

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.

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:&lt;account_id&gt;:role/test/path/dev/test-env-Worker-Role
  • ARN:aws:iam:&lt;account_id&gt;:role/test/path/dev/test-env-Support-Role
  • ARN:aws:iam:&lt;account_id&gt;:role/test/path/dev/test-env-Installer-Role
  • ARN:aws:iam:&lt;account_id&gt;:role/test/path/dev/test-env-ControlPlane-Role
  • ARN:aws:iam:&lt;account_id&gt;:policy/test/path/dev/test-env-Worker-Role-Policy
  • ARN:aws:iam:&lt;account_id&gt;:policy/test/path/dev/test-env-Support-Role-Policy
  • ARN:aws:iam:&lt;account_id&gt;:policy/test/path/dev/test-env-Installer-Role-Policy
  • ARN:aws:iam:&lt;account_id&gt;: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

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.

Important

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.

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

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

  1. Afin de créer votre configuration OIDC à côté des ressources AWS, exécutez la commande suivante:

    $ rosa create oidc-config --mode=auto --yes
    Copy to Clipboard Toggle word wrap

    Cette commande renvoie les informations suivantes.

    Exemple de sortie

    ? Would you like to create a Managed (Red Hat hosted) OIDC Configuration Yes
    I: Setting up managed OIDC configuration
    I: To create Operator Roles for this OIDC Configuration, run the following command and remember to replace <user-defined> with a prefix of your choice:
    	rosa create operator-roles --prefix <user-defined> --oidc-config-id 13cdr6b
    If you are going to create a Hosted Control Plane cluster please include '--hosted-cp'
    I: Creating OIDC provider using 'arn:aws:iam::4540112244:user/userName'
    ? Create the OIDC provider? Yes
    I: Created OIDC provider with ARN 'arn:aws:iam::4540112244:oidc-provider/dvbwgdztaeq9o.cloudfront.net/13cdr6b'
    Copy to Clipboard Toggle word wrap

    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.

  2. 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>
    1
    Copy to Clipboard Toggle word wrap
    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
      Copy to Clipboard Toggle word wrap

      Exemple de sortie

      13cdr6b
      Copy to Clipboard Toggle word wrap

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
    Copy to Clipboard Toggle word wrap

    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
    Copy to Clipboard Toggle word wrap

2.7. Créer un cluster à l’aide de personnalisations

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).

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.

Important

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

  1. Accédez à OpenShift Cluster Manager et sélectionnez Créer un cluster.
  2. Dans la page Créer un cluster OpenShift, sélectionnez Créer un cluster dans la ligne Red Hat OpenShift sur AWS (ROSA).
  3. 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:

    1. 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.

      Note

      Il est également possible de charger votre jeton API sur la page OpenShift Cluster Manager API Token sur OpenShift Cluster Manager.

    2. Exécutez la commande copiée dans le CLI pour vous connecter à votre compte ROSA.

      $ rosa login --token=<api_login_token> 
      1
      Copy to Clipboard Toggle word wrap
      1
      &lt;api_login_token&gt; par le jeton fourni dans la commande copiée.

      Exemple de sortie

      I: Logged in as '<username>' on 'https://api.openshift.com'
      Copy to Clipboard Toggle word wrap

    3. Dans la page Authenticate dans OpenShift Cluster Manager, cliquez sur Suivant.
    4. 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.

    5. 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
      Copy to Clipboard Toggle word wrap

      Exemple de sortie

      I: Creating ocm role
      ? Role prefix: ManagedOpenShift 
      1
      
      ? Enable admin capabilities for the OCM role (optional): No 
      2
      
      ? Permissions boundary ARN (optional):  
      3
      
      ? Role Path (optional): 
      4
      
      ? Role creation mode: auto 
      5
      
      I: Creating role using 'arn:aws:iam::<aws_account_id>:user/<aws_username>'
      ? Create the 'ManagedOpenShift-OCM-Role-<red_hat_organization_external_id>' role? Yes
      I: Created role 'ManagedOpenShift-OCM-Role-<red_hat_organization_external_id>' with ARN 'arn:aws:iam::<aws_account_id>:role/ManagedOpenShift-OCM-Role-<red_hat_organization_external_id>'
      I: Linking OCM role
      ? OCM Role ARN: arn:aws:iam::<aws_account_id>:role/ManagedOpenShift-OCM-Role-<red_hat_organization_external_id>
      ? Link the 'arn:aws:iam::<aws_account_id>:role/ManagedOpenShift-OCM-Role-<red_hat_organization_external_id>' role with organization '<red_hat_organization_id>'? Yes 
      6
      
      I: Successfully linked role-arn 'arn:aws:iam::<aws_account_id>:role/ManagedOpenShift-OCM-Role-<red_hat_organization_external_id>' with organization account '<red_hat_organization_id>'
      Copy to Clipboard Toggle word wrap

      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.
    6. 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> 
      1
      Copy to Clipboard Toggle word wrap
      1
      &lt;arn&gt; par l’ARN du rôle OpenShift Cluster Manager IAM qui est inclus dans la sortie de la commande précédente.
    7. Cliquez sur Suivant sur la page des rôles OpenShift Cluster Manager OCM.
    8. 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
      Copy to Clipboard Toggle word wrap

      Exemple de sortie

      I: Creating User role
      ? Role prefix: ManagedOpenShift 
      1
      
      ? Permissions boundary ARN (optional): 
      2
      
      ? Role Path (optional): [? for help] 
      3
      
      ? Role creation mode: auto 
      4
      
      I: Creating ocm user role using 'arn:aws:iam::<aws_account_id>:user/<aws_username>'
      ? Create the 'ManagedOpenShift-User-<red_hat_username>-Role' role? Yes
      I: Created role 'ManagedOpenShift-User-<red_hat_username>-Role' with ARN 'arn:aws:iam::<aws_account_id>:role/ManagedOpenShift-User-<red_hat_username>-Role'
      I: Linking User role
      ? User Role ARN: arn:aws:iam::<aws_account_id>:role/ManagedOpenShift-User-<red_hat_username>-Role
      ? Link the 'arn:aws:iam::<aws_account_id>:role/ManagedOpenShift-User-<red_hat_username>-Role' role with account '<red_hat_user_account_id>'? Yes 
      5
      
      I: Successfully linked role ARN 'arn:aws:iam::<aws_account_id>:role/ManagedOpenShift-User-<red_hat_username>-Role' with account '<red_hat_user_account_id>'
      Copy to Clipboard Toggle word wrap

      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.
    9. 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> 
      1
      Copy to Clipboard Toggle word wrap
      1
      &lt;arn&gt; par l’ARN du rôle utilisateur qui est inclus dans la sortie de la commande précédente.
    10. Dans la page des rôles d’utilisateur OpenShift Cluster Manager, cliquez sur OK.
    11. 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.
    12. 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
      Copy to Clipboard Toggle word wrap

      Exemple de sortie

      I: Logged in as '<red_hat_username>' on 'https://api.openshift.com'
      I: Validating AWS credentials...
      I: AWS credentials are valid!
      I: Validating AWS quota...
      I: AWS quota ok. If cluster installation fails, validate actual AWS resource usage against https://docs.openshift.com/rosa/rosa_getting_started/rosa-required-aws-service-quotas.html
      I: Verifying whether OpenShift command-line tool is available...
      I: Current OpenShift Client Version: 4.0
      I: Creating account roles
      ? Role prefix: ManagedOpenShift 
      1
      
      ? Permissions boundary ARN (optional): 
      2
      
      ? Path (optional): [? for help] 
      3
      
      ? Role creation mode: auto 
      4
      
      I: Creating roles using 'arn:aws:iam::<aws_account_number>:user/<aws_username>'
      ? Create the 'ManagedOpenShift-Installer-Role' role? Yes 
      5
      
      I: Created role 'ManagedOpenShift-Installer-Role' with ARN 'arn:aws:iam::<aws_account_number>:role/ManagedOpenShift-Installer-Role'
      ? Create the 'ManagedOpenShift-ControlPlane-Role' role? Yes 
      6
      
      I: Created role 'ManagedOpenShift-ControlPlane-Role' with ARN 'arn:aws:iam::<aws_account_number>:role/ManagedOpenShift-ControlPlane-Role'
      ? Create the 'ManagedOpenShift-Worker-Role' role? Yes 
      7
      
      I: Created role 'ManagedOpenShift-Worker-Role' with ARN 'arn:aws:iam::<aws_account_number>:role/ManagedOpenShift-Worker-Role'
      ? Create the 'ManagedOpenShift-Support-Role' role? Yes 
      8
      
      I: Created role 'ManagedOpenShift-Support-Role' with ARN 'arn:aws:iam::<aws_account_number>:role/ManagedOpenShift-Support-Role'
      I: To create a cluster with these roles, run the following command:
      rosa create cluster --sts
      Copy to Clipboard Toggle word wrap

      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.

    13. 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é.

  4. Cliquez sur Next.

    Note

    Lorsque 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.

  5. Dans la page Détails du cluster, fournissez un nom pour votre cluster et spécifiez les détails du cluster:

    1. Ajoutez un nom de cluster.
    2. 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.

    3. Choisissez une version de cluster dans le menu déroulant Version.
    4. Choisissez une région fournisseur de cloud dans le menu déroulant Région.
    5. Choisissez une configuration de zone unique ou multi-zone.
    6. 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.
    7. Facultatif: Expandez le chiffrement avancé pour apporter des modifications aux paramètres de chiffrement.

      1. 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.

        1. 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.
        2. 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.

          Important

          Le 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::&lt;aws_account_id&gt;:role/&lt;cluster_name&gt;-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.

      2. Facultatif: Sélectionnez Activer la cryptographie FIPS si vous exigez que votre cluster soit validé FIPS.

        Note

        Lorsque 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.

      3. 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.

        Note

        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. Envisagez d’activer le chiffrement etcd seulement si vous en avez spécifiquement besoin pour votre cas d’utilisation.

    8. Cliquez sur Next.
  6. Dans la page de pool de machines par défaut, sélectionnez un type d’instance de nœud de calcul.

    Note

    Aprè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.

  7. Facultatif: Configurer l’autoscaling pour le pool de machines par défaut:

    1. 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.
    2. 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.
      Note

      Alternativement, 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.

  8. 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.
  9. 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.

    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.

  10. 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.
  11. 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.

    Important

    Le 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.

    Important

    Lorsque 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.

  12. 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.

    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/&lt;infra-id&gt;. 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.

    Note

    Lorsque 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.

  13. 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.
  14. Cliquez sur Next.
  15. 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).

    Note

    Assurez-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.

    1. 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.

  16. 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:

    1. 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.
    2. 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.

  17. 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.

    Note

    Lorsque vous installez dans un VPC, la gamme Machine CIDR doit correspondre aux sous-réseaux VPC.

    Important

    Les configurations CIDR ne peuvent pas être modifiées ultérieurement. Confirmez vos sélections avec votre administrateur réseau avant de procéder.

  18. 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.

    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é 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.

  19. 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.

    Note

    Les 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 &lt;cluster_name&gt;-&lt;hash&gt; 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.

  20. Choisissez Suivant.
  21. Dans la page Stratégie de mise à jour Cluster, configurez vos préférences de mise à jour:

    1. 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.

        Important

        Lorsque 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.

        Note

        Consultez 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.

    2. 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.
    3. 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.
    4. Cliquez sur Next.

      Note

      En 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.

  22. Examinez le résumé de vos sélections et cliquez sur Créer un cluster pour démarrer l’installation du cluster.
  23. 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:

    1. 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.

        Note

        Il 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.

        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é et appliqué aux rôles d’opérateur lorsque vous les créez en utilisant ces méthodes manuelles.

    2. Dans la boîte de dialogue Action requise pour continuer l’installation, cliquez sur x pour retourner à la page Aperçu de votre cluster.
    3. 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.
    Note

    Lorsque vous avez choisi d’utiliser le mode Auto, OpenShift Cluster Manager crée automatiquement les rôles Opérateur et le fournisseur OIDC.

    Important

    Le 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::&lt;aws_account_id&gt;:role/&lt;cluster_name&gt;-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.

    Note

    En 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.

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.

Important

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.

    Important

    Le 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::&lt;aws_account_id&gt;:role/&lt;cluster_name&gt;-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

  1. Créer les rôles et politiques nécessaires à l’échelle du compte, y compris les politiques de l’opérateur:

    1. 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 \ 
      1
      
                                  --mode manual 
      2
      Copy to Clipboard Toggle word wrap
      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

      I: Logged in as '<red_hat_username>' on 'https://api.openshift.com'
      I: Validating AWS credentials...
      I: AWS credentials are valid!
      I: Validating AWS quota...
      I: AWS quota ok. If cluster installation fails, validate actual AWS resource usage against https://docs.openshift.com/rosa/rosa_getting_started/rosa-required-aws-service-quotas.html
      I: Verifying whether OpenShift command-line tool is available...
      I: Current OpenShift Client Version: 4.0
      I: Creating account roles
      ? Role prefix: ManagedOpenShift 
      1
      
      ? Permissions boundary ARN (optional): 
      2
      
      ? Path (optional): [? for help] 
      3
      
      ? Role creation mode: auto 
      4
      
      I: Creating roles using 'arn:aws:iam::<aws_account_number>:user/<aws_username>'
      ? Create the 'ManagedOpenShift-Installer-Role' role? Yes 
      5
      
      I: Created role 'ManagedOpenShift-Installer-Role' with ARN 'arn:aws:iam::<aws_account_number>:role/ManagedOpenShift-Installer-Role'
      ? Create the 'ManagedOpenShift-ControlPlane-Role' role? Yes 
      6
      
      I: Created role 'ManagedOpenShift-ControlPlane-Role' with ARN 'arn:aws:iam::<aws_account_number>:role/ManagedOpenShift-ControlPlane-Role'
      ? Create the 'ManagedOpenShift-Worker-Role' role? Yes 
      7
      
      I: Created role 'ManagedOpenShift-Worker-Role' with ARN 'arn:aws:iam::<aws_account_number>:role/ManagedOpenShift-Worker-Role'
      ? Create the 'ManagedOpenShift-Support-Role' role? Yes 
      8
      
      I: Created role 'ManagedOpenShift-Support-Role' with ARN 'arn:aws:iam::<aws_account_number>:role/ManagedOpenShift-Support-Role'
      I: To create a cluster with these roles, run the following command:
      rosa create cluster --sts
      Copy to Clipboard Toggle word wrap

      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.

      1. 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.
  2. 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.

    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é.

    1. 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 
      1
      Copy to Clipboard Toggle word wrap
      1
      &lt;key_id_or_arn&gt; par l’ID ou l’ARN de votre clé KMS.
    2. 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é:

      {
          "Version": "2012-10-17",
          "Id": "key-rosa-policy-1",
          "Statement": [
              {
                  "Sid": "Enable IAM User Permissions",
                  "Effect": "Allow",
                  "Principal": {
                      "AWS": "arn:aws:iam::<aws_account_id>:root"
                  },
                  "Action": "kms:*",
                  "Resource": "*"
              },
              {
                  "Sid": "Allow ROSA use of the key",
                  "Effect": "Allow",
                  "Principal": {
                      "AWS": [
                          "arn:aws:iam::<aws_account_id>:role/ManagedOpenShift-Support-Role", 
      1
      
                          "arn:aws:iam::<aws_account_id>:role/ManagedOpenShift-Installer-Role",
                          "arn:aws:iam::<aws_account_id>:role/ManagedOpenShift-Worker-Role",
                          "arn:aws:iam::<aws_account_id>:role/ManagedOpenShift-ControlPlane-Role",
                          "arn:aws:iam::<aws_account_id>:role/<cluster_name>-xxxx-openshift-cluster-csi-drivers-ebs-cloud-credent" 
      2
      
                      ]
                  },
                  "Action": [
                      "kms:Encrypt",
                      "kms:Decrypt",
                      "kms:ReEncrypt*",
                      "kms:GenerateDataKey*",
                      "kms:DescribeKey"
                  ],
                  "Resource": "*"
              },
              {
                  "Sid": "Allow attachment of persistent resources",
                  "Effect": "Allow",
                  "Principal": {
                      "AWS": [
                          "arn:aws:iam::<aws_account_id>:role/ManagedOpenShift-Support-Role", 
      3
      
                          "arn:aws:iam::<aws_account_id>:role/ManagedOpenShift-Installer-Role",
                          "arn:aws:iam::<aws_account_id>:role/ManagedOpenShift-Worker-Role",
                          "arn:aws:iam::<aws_account_id>:role/ManagedOpenShift-ControlPlane-Role",
                          "arn:aws:iam::<aws_account_id>:role/<cluster_name>-xxxx-openshift-cluster-csi-drivers-ebs-cloud-credent" 
      4
      
                      ]
                  },
                  "Action": [
                      "kms:CreateGrant",
                      "kms:ListGrants",
                      "kms:RevokeGrant"
                  ],
                  "Resource": "*",
                  "Condition": {
                      "Bool": {
                          "kms:GrantIsForAWSResource": "true"
                      }
                  }
              }
          ]
      }
      Copy to Clipboard Toggle word wrap
      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.
    3. Appliquez les modifications à votre politique clé KMS:

      $ aws kms put-key-policy --key-id <key_id_or_arn> \ 
      1
      
          --policy file://kms-key-policy.json \ 
      2
      
          --policy-name default
      Copy to Clipboard Toggle word wrap
      1
      &lt;key_id_or_arn&gt; par l’ID ou l’ARN de votre clé KMS.
      2
      Le préfixe du fichier:// doit être inclus lors du référencement d’une stratégie clé dans un fichier local.

      Lorsque vous créez le cluster à l’étape suivante, vous pouvez faire référence à l’ARN de votre clé KMS.

  3. 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:

    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/&lt;infra-id&gt;. 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
    Copy to Clipboard Toggle word wrap

    Exemple de sortie

    I: Interactive mode enabled.
    Any optional fields can be left empty and a default will be selected.
    ? Cluster name: <cluster_name>
    ? Domain prefix: <domain_prefix> 
    1
    
    ? Deploy cluster with Hosted Control Plane (optional): No
    ? Create cluster admin user: Yes 
    2
    
    ? Create custom password for cluster admin: No 
    3
    
    I: cluster admin user is cluster-admin
    I: cluster admin password is password
    ? OpenShift version: <openshift_version> 
    4
    
    ? Configure the use of IMDSv2 for ec2 instances optional/required (optional): 
    5
    
    I: Using arn:aws:iam::<aws_account_id>:role/ManagedOpenShift-Installer-Role for the Installer role 
    6
    
    I: Using arn:aws:iam::<aws_account_id>:role/ManagedOpenShift-ControlPlane-Role for the ControlPlane role
    I: Using arn:aws:iam::<aws_account_id>:role/ManagedOpenShift-Worker-Role for the Worker role
    I: Using arn:aws:iam::<aws_account_id>:role/ManagedOpenShift-Support-Role for the Support role
    ? External ID (optional): 
    7
    
    ? Operator roles prefix: <cluster_name>-<random_string> 
    8
    
    ? Deploy cluster using pre registered OIDC Configuration ID:
    ? Tags (optional) 
    9
    
    ? Multiple availability zones (optional): No 
    10
    
    ? AWS region: us-east-1
    ? PrivateLink cluster (optional): No
    ? Machine CIDR: 10.0.0.0/16
    ? Service CIDR: 172.30.0.0/16
    ? Pod CIDR: 10.128.0.0/14
    ? Install into an existing VPC (optional): Yes 
    11
    
    ? Subnet IDs (optional):
    ? Select availability zones (optional): No
    ? Enable Customer Managed key (optional): No 
    12
    
    ? Compute nodes instance type (optional):
    ? Enable autoscaling (optional): No
    ? Compute nodes: 2
    ? Worker machine pool labels (optional):
    ? Host prefix: 23
    ? Additional Security Group IDs (optional): 
    13
    
    ? > [*]  sg-0e375ff0ec4a6cfa2 ('sg-1')
    ? > [ ]  sg-0e525ef0ec4b2ada7 ('sg-2')
    ? Enable FIPS support: No 
    14
    
    ? Encrypt etcd data: No 
    15
    
    ? Disable Workload monitoring (optional): No
    I: Creating cluster '<cluster_name>'
    I: To create this cluster again in the future, you can run:
       rosa create cluster --cluster-name <cluster_name> --role-arn arn:aws:iam::<aws_account_id>:role/ManagedOpenShift-Installer-Role --support-role-arn arn:aws:iam::<aws_account_id>:role/ManagedOpenShift-Support-Role --master-iam-role arn:aws:iam::<aws_account_id>:role/ManagedOpenShift-ControlPlane-Role --worker-iam-role arn:aws:iam::<aws_account_id>:role/ManagedOpenShift-Worker-Role --operator-roles-prefix <cluster_name>-<random_string> --region us-east-1 --version 4.18.0 --additional-compute-security-group-ids sg-0e375ff0ec4a6cfa2 --additional-infra-security-group-ids sg-0e375ff0ec4a6cfa2 --additional-control-plane-security-group-ids sg-0e375ff0ec4a6cfa2 --replicas 2 --machine-cidr 10.0.0.0/16 --service-cidr 172.30.0.0/16 --pod-cidr 10.128.0.0/14 --host-prefix 23 
    16
    
    I: To view a list of clusters and their status, run 'rosa list clusters'
    I: Cluster '<cluster_name>' has been created.
    I: Once the cluster is installed you will need to add an Identity Provider before you can login into the cluster. See 'rosa create idp --help' for more information.
    ...
    Copy to Clipboard Toggle word wrap

    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 &lt;cluster_name&gt;-&lt;hash&gt; 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/&lt;infra-id&gt;. 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.

    Important

    Il 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.

  4. Créer les rôles IAM d’opérateur spécifiques au cluster:

    1. 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> 
      1
      Copy to Clipboard Toggle word wrap
      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.
    2. 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.

      Note

      Le 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.

      Important

      Le 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::&lt;aws_account_id&gt;:role/&lt;cluster_name&gt;-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.

  5. 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> 
    1
    Copy to Clipboard Toggle word wrap
    1
    le mode automatique exécute immédiatement la commande aws CLI qui crée le fournisseur OIDC.
  6. Consultez l’état de votre cluster:

    $ rosa describe cluster --cluster <cluster_name|cluster_id>
    Copy to Clipboard Toggle word wrap

    Exemple de sortie

    Name:                       <cluster_name>
    ID:                         <cluster_id>
    External ID:                <external_id>
    OpenShift Version:          <version>
    Channel Group:              stable
    DNS:                        <cluster_name>.xxxx.p1.openshiftapps.com
    AWS Account:                <aws_account_id>
    API URL:                    https://api.<cluster_name>.xxxx.p1.openshiftapps.com:6443
    Console URL:                https://console-openshift-console.apps.<cluster_name>.xxxx.p1.openshiftapps.com
    Region:                     <aws_region>
    Multi-AZ:                   false
    Nodes:
     - Master:                  3
     - Infra:                   2
     - Compute:                 2
    Network:
     - Service CIDR:            172.30.0.0/16
     - Machine CIDR:            10.0.0.0/16
     - Pod CIDR:                10.128.0.0/14
     - Host Prefix:             /23
    STS Role ARN:               arn:aws:iam::<aws_account_id>:role/ManagedOpenShift-Installer-Role
    Support Role ARN:           arn:aws:iam::<aws_account_id>:role/ManagedOpenShift-Support-Role
    Instance IAM Roles:
     - Master:                  arn:aws:iam::<aws_account_id>:role/ManagedOpenShift-ControlPlane-Role
     - Worker:                  arn:aws:iam::<aws_account_id>:role/ManagedOpenShift-Worker-Role
    Operator IAM Roles:
     - arn:aws:iam::<aws_account_id>:role/<cluster_name>-xxxx-openshift-ingress-operator-cloud-credentials
     - arn:aws:iam::<aws_account_id>:role/<cluster_name>-xxxx-openshift-cluster-csi-drivers-ebs-cloud-credent
     - arn:aws:iam::<aws_account_id>:role/<cluster_name>-xxxx-openshift-machine-api-aws-cloud-credentials
     - arn:aws:iam::<aws_account_id>:role/<cluster_name>-xxxx-openshift-cloud-credential-operator-cloud-crede
     - arn:aws:iam::<aws_account_id>:role/<cluster_name>-xxxx-openshift-image-registry-installer-cloud-creden
    Ec2 Metadata Http Tokens:   optional
    State:                      ready
    Private:                    No
    Created:                    Oct  1 2021 08:12:25 UTC
    Details Page:               https://console.redhat.com/openshift/details/s/<subscription_id>
    OIDC Endpoint URL:          https://oidc.op1.openshiftapps.com/<cluster_id>|<oidc_config_id> \ 
    1
    Copy to Clipboard Toggle word wrap

    1. 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 &lt;oidc_config_id&gt;; sinon, l’URL se termine par la valeur &lt;cluster-ID&gt;.

    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 ♪

      Note

      En 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.

  7. 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 
    1
    Copy to Clipboard Toggle word wrap
    1 1
    Indiquez le drapeau --watch pour regarder les nouveaux messages de journal au fur et à mesure que l’installation progresse. Cet argument est facultatif.

2.8. Les prochaines étapes

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

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

    {
      "Version": "2012-10-17",
      "Statement": [
        {
          "Sid": "VisualEditor0",
          "Effect": "Allow",
          "Action": [
            "iam:GetPolicyVersion",
            "iam:DeletePolicyVersion",
            "iam:CreatePolicyVersion",
            "iam:UpdateAssumeRolePolicy",
            "secretsmanager:DescribeSecret",
            "iam:ListRoleTags",
            "secretsmanager:PutSecretValue",
            "secretsmanager:CreateSecret",
            "iam:TagRole",
            "secretsmanager:DeleteSecret",
            "iam:UpdateOpenIDConnectProviderThumbprint",
            "iam:DeletePolicy",
            "iam:CreateRole",
            "iam:AttachRolePolicy",
            "iam:ListInstanceProfilesForRole",
            "secretsmanager:GetSecretValue",
            "iam:DetachRolePolicy",
            "iam:ListAttachedRolePolicies",
            "iam:ListPolicyTags",
            "iam:ListRolePolicies",
            "iam:DeleteOpenIDConnectProvider",
            "iam:DeleteInstanceProfile",
            "iam:GetRole",
            "iam:GetPolicy",
            "iam:ListEntitiesForPolicy",
            "iam:DeleteRole",
            "iam:TagPolicy",
            "iam:CreateOpenIDConnectProvider",
            "iam:CreatePolicy",
            "secretsmanager:GetResourcePolicy",
            "iam:ListPolicyVersions",
            "iam:UpdateRole",
            "iam:GetOpenIDConnectProvider",
            "iam:TagOpenIDConnectProvider",
            "secretsmanager:TagResource",
            "sts:AssumeRoleWithWebIdentity",
            "iam:ListRoles"
          ],
          "Resource": [
            "arn:aws:secretsmanager:*:<ACCOUNT_ID>:secret:*",
            "arn:aws:iam::<ACCOUNT_ID>:instance-profile/*",
            "arn:aws:iam::<ACCOUNT_ID>:role/*",
            "arn:aws:iam::<ACCOUNT_ID>:oidc-provider/*",
            "arn:aws:iam::<ACCOUNT_ID>:policy/*"
          ]
        },
        {
          "Sid": "VisualEditor1",
          "Effect": "Allow",
          "Action": [
            "s3:*"
            ],
          "Resource": "*"
        }
      ]
    }
    Copy to Clipboard Toggle word wrap
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

Expand
Tableau 3.1. Défaut ROSA avec les spécifications du cluster STS
ComposanteCaractéristiques par défaut

Comptes et rôles

  • IAM préfixe par défaut: rosa-&lt;6-digit-alphanumeric-string&gt;
  • Aucun rôle d’administrateur de cluster créé

Configurations du cluster

  • La version par défaut du cluster: 4.14
  • Cluster name: rosa-&lt;6-digit-alphanumeric-string&gt;
  • La région AWS par défaut pour les installations utilisant le Red Hat OpenShift Cluster Manager Hybrid Cloud Console: us-east-2 (US East, Ohio)
  • Disponibilité: Multizone pour le plan de données
  • EC2 Instance Metadata Service (IMDS) est activé et permet l’utilisation de IMDSv1 ou IMDSv2 (jeton facultatif)
  • EC2 Instance Metadata Service (IMDS) est activé et permet l’utilisation de IMDSv1 ou IMDSv2 (jeton facultatif)
  • Contrôle pour les projets définis par l’utilisateur: activé

Chiffrement

  • Le stockage en nuage est crypté au repos
  • Le chiffrement supplémentaire etcd n’est pas activé
  • La clé AWS Key Management Service (KMS) par défaut est utilisée comme clé de chiffrement pour les données persistantes

Configuration des nœuds de plan de contrôle

  • Contrôle type d’instance de nœud de plan: m5.2xlarge (8 vCPU, 32 GAB RAM)
  • Comptage des nœuds de plan de contrôle: 3

Configuration des nœuds d’infrastructure

  • Infrastructure Node type d’instance: r5.xlarge (4 vCPU, 32 GAB RAM)
  • Comptage des nœuds d’infrastructure: 2

Calculez la piscine de la machine de nœud

  • Calculer le type d’instance du nœud: m5.xlarge (4 vCPU 16, RAM GiB)
  • Calcul du nombre de nœuds: 3
  • Autoscaling: Non activé
  • Aucune étiquette de nœud supplémentaire

Configuration du réseau

  • La confidentialité des clusters : publique ou privée
  • Lors du processus de création du cluster Terraform, vous pouvez choisir de créer un nouveau VPC.
  • Il faut avoir configuré votre propre Cloud privé virtuel (VPC)
  • Aucun proxy à l’échelle du cluster n’est configuré

Gammes de routage interdomain sans classe (CIDR)

  • CIDR machine: 10.0.0.0/16
  • CIDR de service: 172.30.0.0/16
  • Dose CIDR: 10.128.0.0/14
  • Hôte préfixe: /23

Les rôles et les politiques des clusters

  • Le mode utilisé pour créer les rôles d’opérateur et le fournisseur OpenID Connect (OIDC) : auto

    Note

    Dans le cas des installations utilisant OpenShift Cluster Manager sur la console hybride Cloud, le mode automatique nécessite un rôle de gestionnaire de cluster OpenShift privilégié par l’administrateur.

  • Défaut de préfixe de rôle opérateur: rosa-&lt;6-digit-alphanumeric-string&gt;

La stratégie de mise à jour des clusters

  • Des mises à jour individuelles
  • Délai de grâce de 1 heure pour drainer les nœuds

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

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

  1. 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
    Copy to Clipboard Toggle word wrap
  2. Accordez des autorisations à votre compte en utilisant un jeton Red Hat OpenShift Cluster Manager hors ligne.
  3. 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>
    Copy to Clipboard Toggle word wrap
    Note

    Cette 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
    Copy to Clipboard Toggle word wrap
3.1.3.2. Créer vos fichiers Terraform localement

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

  1. Créez le fichier main.tf en exécutant la commande suivante:

    $ cat<<-EOF>main.tf
    #
    # Copyright (c) 2023 Red Hat, Inc.
    #
    # Licensed under the Apache License, Version 2.0 (the "License");
    # you may not use this file except in compliance with the License.
    # You may obtain a copy of the License at
    #
    #   http://www.apache.org/licenses/LICENSE-2.0
    #
    # Unless required by applicable law or agreed to in writing, software
    # distributed under the License is distributed on an "AS IS" BASIS,
    # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
    # See the License for the specific language governing permissions and
    # limitations under the License.
    #
    
    terraform {
      required_providers {
        aws = {
          source  = "hashicorp/aws"
          version = ">= 4.20.0"
        }
        rhcs = {
          version = ">= 1.6.2"
          source  = "terraform-redhat/rhcs"
        }
      }
    }
    
    # Export token using the RHCS_TOKEN environment variable
    provider "rhcs" {}
    
    provider "aws" {
      region = var.aws_region
      ignore_tags {
        key_prefixes = ["kubernetes.io/"]
      }
      default_tags {
        tags = var.default_aws_tags
      }
    }
    
    data "aws_availability_zones" "available" {}
    
    locals {
      # The default setting creates 3 availability zones. Set to "false" to create a single availability zones.
      region_azs = var.multi_az ? slice([for zone in data.aws_availability_zones.available.names : format("%s", zone)], 0, 3) : slice([for zone in data.aws_availability_zones.available.names : format("%s", zone)], 0, 1)
    }
    
    resource "random_string" "random_name" {
      length  = 6
      special = false
      upper   = false
    }
    
    locals {
      path                 = coalesce(var.path, "/")
      worker_node_replicas = try(var.worker_node_replicas, var.multi_az ? 3 : 2)
      # If cluster_name is not null, use that, otherwise generate a random cluster name
      cluster_name = coalesce(var.cluster_name, "rosa-\${random_string.random_name.result}")
    }
    
    # The network validator requires an additional 60 seconds to validate Terraform clusters.
    resource "time_sleep" "wait_60_seconds" {
      count = var.create_vpc ? 1 : 0
      depends_on = [module.vpc]
      create_duration = "60s"
    }
    
    module "rosa-classic" {
      source                 = "terraform-redhat/rosa-classic/rhcs"
      version                = "1.5.0"
      cluster_name           = local.cluster_name
      openshift_version      = var.openshift_version
      account_role_prefix    = local.cluster_name
      operator_role_prefix   = local.cluster_name
      replicas               = local.worker_node_replicas
      aws_availability_zones = local.region_azs
      create_oidc            = true
      private                = var.private_cluster
      aws_private_link       = var.private_cluster
      aws_subnet_ids         = var.create_vpc ? var.private_cluster ? module.vpc[0].private_subnets : concat(module.vpc[0].public_subnets, module.vpc[0].private_subnets) : var.aws_subnet_ids
      multi_az               = var.multi_az
      create_account_roles   = true
      create_operator_roles  = true
    # Optional: Configure a cluster administrator user <.>
    #
    # Option 1: Default cluster-admin user
    # Create an administrator user (cluster-admin) and automatically
    # generate a password by uncommenting the following parameter:
    #  create_admin_user = true
    # Generated administrator credentials are displayed in terminal output.
    #
    # Option 2: Specify administrator username and password
    # Create an administrator user and define your own password
    # by uncommenting and editing the values of the following parameters:
    #  admin_credentials_username = <username>
    #  admin_credentials_password = <password>
    
      depends_on = [time_sleep.wait_60_seconds]
    }
    EOF
    Copy to Clipboard Toggle word wrap

    &Lt;.&gt; 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.

  2. Créez le fichier variables.tf en exécutant la commande suivante:

    Note

    Copiez et modifiez ce fichier avant d’exécuter la commande pour construire votre cluster.

    $ cat<<-EOF>variables.tf
    #
    # Copyright (c) 2023 Red Hat, Inc.
    #
    # Licensed under the Apache License, Version 2.0 (the "License");
    # you may not use this file except in compliance with the License.
    # You may obtain a copy of the License at
    #
    #   http://www.apache.org/licenses/LICENSE-2.0
    #
    # Unless required by applicable law or agreed to in writing, software
    # distributed under the License is distributed on an "AS IS" BASIS,
    # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
    # See the License for the specific language governing permissions and
    # limitations under the License.
    #
    variable "openshift_version" {
      type        = string
      default     = "4.14.20"
      description = "Desired version of OpenShift for the cluster, for example '4.14.20'. If version is greater than the currently running version, an upgrade will be scheduled."
    }
    
    variable "create_vpc" {
      type        = bool
      description = "If you would like to create a new VPC, set this value to 'true'. If you do not want to create a new VPC, set this value to 'false'."
    }
    
    # ROSA Cluster info
    variable "cluster_name" {
      default     = null
      type        = string
      description = "The name of the ROSA cluster to create"
    }
    
    variable "additional_tags" {
      default = {
        Terraform   = "true"
        Environment = "dev"
      }
      description = "Additional AWS resource tags"
      type        = map(string)
    }
    
    variable "path" {
      description = "(Optional) The arn path for the account/operator roles as well as their policies."
      type        = string
      default     = null
    }
    
    variable "multi_az" {
      type        = bool
      description = "Multi AZ Cluster for High Availability"
      default     = true
    }
    
    variable "worker_node_replicas" {
      default     = 3
      description = "Number of worker nodes to provision. Single zone clusters need at least 2 nodes, multizone clusters need at least 3 nodes"
      type        = number
    }
    
    variable "aws_subnet_ids" {
      type        = list(any)
      description = "A list of either the public or public + private subnet IDs to use for the cluster blocks to use for the cluster"
      default     = ["subnet-01234567890abcdef", "subnet-01234567890abcdef", "subnet-01234567890abcdef"]
    }
    
    variable "private_cluster" {
      type        = bool
      description = "If you want to create a private cluster, set this value to 'true'. If you want a publicly available cluster, set this value to 'false'."
    }
    
    #VPC Info
    variable "vpc_name" {
      type        = string
      description = "VPC Name"
      default     = "tf-qs-vpc"
    }
    
    variable "vpc_cidr_block" {
      type        = string
      description = "value of the CIDR block to use for the VPC"
      default     = "10.0.0.0/16"
    }
    
    variable "private_subnet_cidrs" {
      type        = list(any)
      description = "The CIDR blocks to use for the private subnets"
      default     = ["10.0.1.0/24", "10.0.2.0/24", "10.0.3.0/24"]
    }
    
    variable "public_subnet_cidrs" {
      type        = list(any)
      description = "The CIDR blocks to use for the public subnets"
      default     = ["10.0.101.0/24", "10.0.102.0/24", "10.0.103.0/24"]
    }
    
    variable "single_nat_gateway" {
      type        = bool
      description = "Single NAT or per NAT for subnet"
      default     = false
    }
    
    #AWS Info
    variable "aws_region" {
      type    = string
      default = "us-east-2"
    }
    
    variable "default_aws_tags" {
      type        = map(string)
      description = "Default tags for AWS"
      default     = {}
    }
    EOF
    Copy to Clipboard Toggle word wrap
  3. Créez le fichier vpc.tf en exécutant la commande suivante:

    $ cat<<-EOF>vpc.tf
    #
    # Copyright (c) 2023 Red Hat, Inc.
    #
    # Licensed under the Apache License, Version 2.0 (the "License");
    # you may not use this file except in compliance with the License.
    # You may obtain a copy of the License at
    #
    #   http://www.apache.org/licenses/LICENSE-2.0
    #
    # Unless required by applicable law or agreed to in writing, software
    # distributed under the License is distributed on an "AS IS" BASIS,
    # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
    # See the License for the specific language governing permissions and
    # limitations under the License.
    #
    module "vpc" {
      source  = "terraform-aws-modules/vpc/aws"
      version = "5.1.2"
    
      count = var.create_vpc ? 1 : 0
      name  = var.vpc_name
      cidr  = var.vpc_cidr_block
    
      azs             = local.region_azs
      private_subnets = var.private_subnet_cidrs
      public_subnets  = var.public_subnet_cidrs
    
      enable_nat_gateway   = true
      single_nat_gateway   = var.single_nat_gateway
      enable_dns_hostnames = true
      enable_dns_support   = true
    
      tags = var.additional_tags
    }
    EOF
    Copy to Clipboard Toggle word wrap

    « vous êtes prêt à initier Terraform.

3.1.3.3. En utilisant Terraform pour créer votre cluster ROSA

Après avoir créé les fichiers Terraform, vous devez initier Terraform pour fournir toutes les dépendances requises. Ensuite, appliquez le plan Terraform.

Important

Il ne faut pas modifier les fichiers d’état Terraform. Consultez Considérations lors de l’utilisation de Terraform

Procédure

  1. Configurez Terraform pour créer vos ressources en fonction de vos fichiers Terraform, exécutez la commande suivante:

    $ terraform init
    Copy to Clipboard Toggle word wrap
  2. Facultatif : Vérifiez que le Terraform que vous avez copié est correct en exécutant la commande suivante:

    $ terraform validate
    Copy to Clipboard Toggle word wrap

    Exemple de sortie

    Success! The configuration is valid.
    Copy to Clipboard Toggle word wrap

  3. Créez votre cluster avec Terraform en exécutant la commande suivante:

    $ terraform apply
    Copy to Clipboard Toggle word wrap

    L’interface Terraform pose deux questions pour créer votre cluster, similaire à ce qui suit:

    Exemple de sortie

    var.create_vpc
      If you would like to create a new VPC, set this value to 'true'. If you do not want to create a new VPC, set this value to 'false'.
    
      Enter a value:
    
    var.private_cluster
      If you want to create a private cluster, set this value to 'true'. If you want a publicly available cluster, set this value to 'false'.
    
      Enter a value:
    Copy to Clipboard Toggle word wrap

  4. 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

    Plan: 74 to add, 0 to change, 0 to destroy.
    
    Do you want to perform these actions?
      Terraform will perform the actions described above.
      Only 'yes' will be accepted to approve.
    
      Enter a value: yes
    Copy to Clipboard Toggle word wrap

    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

  1. Assurez-vous que votre cluster a été créé en exécutant la commande suivante:

    $ rosa list clusters
    Copy to Clipboard Toggle word wrap

    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)
    Copy to Clipboard Toggle word wrap

  2. Assurez-vous que vos rôles de compte ont été créés en exécutant la commande suivante:

    $ rosa list account-roles
    Copy to Clipboard Toggle word wrap

    Exemple de sortie

    I: Fetching account roles
    ROLE NAME                                   ROLE TYPE      ROLE ARN                                                           OPENSHIFT VERSION  AWS Managed
    ROSA-demo-ControlPlane-Role                 Control plane  arn:aws:iam::<ID>:role/ROSA-demo-ControlPlane-Role                 4.14               No
    ROSA-demo-Installer-Role                    Installer      arn:aws:iam::<ID>:role/ROSA-demo-Installer-Role                    4.14               No
    ROSA-demo-Support-Role                      Support        arn:aws:iam::<ID>:role/ROSA-demo-Support-Role                      4.14               No
    ROSA-demo-Worker-Role                       Worker         arn:aws:iam::<ID>:role/ROSA-demo-Worker-Role                       4.14               No
    Copy to Clipboard Toggle word wrap

  3. Assurez-vous que vos rôles d’opérateur ont été créés en exécutant la commande suivante:

    $ rosa list operator-roles
    Copy to Clipboard Toggle word wrap

    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
    Copy to Clipboard Toggle word wrap

3.1.3.4. La suppression de votre cluster ROSA avec Terraform

La commande terraform destroy permet de supprimer toutes les ressources créées avec la commande terraform application.

Note

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

  1. 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
    Copy to Clipboard Toggle word wrap

    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:

    var.create_vpc
      If you would like to create a new VPC, set this value to 'true.' If you do not want to create a new VPC, set this value to 'false.'
    
      Enter a value:
    
    var.private_cluster
      If you want to create a private cluster, set this value to 'true.' If you want a publicly available cluster, set this value to 'false.'
    
      Enter a value:
    Copy to Clipboard Toggle word wrap
  2. Entrez oui pour démarrer la suppression du rôle et du cluster:

    Exemple de sortie

    Plan: 0 to add, 0 to change, 74 to destroy.
    
    Do you really want to destroy all resources?
      Terraform will destroy all your managed infrastructure, as shown above.
      There is no undo. Only 'yes' will be accepted to confirm.
    
      Enter a value: yes
    Copy to Clipboard Toggle word wrap

La vérification

  1. Assurez-vous que votre cluster a été détruit en exécutant la commande suivante:

    $ rosa list clusters
    Copy to Clipboard Toggle word wrap

    Exemple de sortie montrant aucun cluster

    I: No clusters available
    Copy to Clipboard Toggle word wrap

  2. Assurez-vous que les rôles de compte ont été détruits en exécutant la commande suivante:

    $ rosa list account-roles
    Copy to Clipboard Toggle word wrap

    Exemple de sortie montrant aucun rôle de compte créé par Terraform

    I: Fetching account roles
    I: No account roles available
    Copy to Clipboard Toggle word wrap

  3. Assurez-vous que les rôles de l’opérateur ont été détruits en exécutant la commande suivante:

    $ rosa list operator-roles
    Copy to Clipboard Toggle word wrap

    Exemple de sortie montrant aucun rôle d’opérateur créé par Terraform

    I: Fetching operator roles
    I: No operator roles available
    Copy to Clipboard Toggle word wrap

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).

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:

Expand
Tableau 4.1. --options interactives de création de rôles OCM
Le champDescription

Le préfixe de rôle

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 les capacités d’administration pour le rôle OCM (facultatif)

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.

Autorisations limite ARN (facultatif)

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.

Chemin de rôle (facultatif)

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.

Le mode de création de rôles

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.

Créer le rôle '&lt;ocm_role_name&gt;'?

Confirmez si vous voulez créer le rôle OCM.

Lier le rôle '&lt;ocm_role_arn&gt;' à l’organisation '&lt;red_hat_organization_id&gt;'?

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:

Expand
Tableau 4.2. --options de création de rôles d’utilisateur interactifs
Le champDescription

Le préfixe de rôle

Indiquez le préfixe à inclure dans le nom du rôle utilisateur. La valeur par défaut est ManagedOpenShift.

Autorisations limite ARN (facultatif)

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.

Chemin de rôle (facultatif)

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.

Le mode de création de rôles

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.

Créer le rôle '&lt;user_role_name&gt;'?

Confirmez si vous souhaitez créer le rôle d’utilisateur.

Lier le rôle '&lt;user_role_arn&gt;' avec le compte '&lt;red_hat_user_account_id&gt;'?

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

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:

Expand
Tableau 4.3. --options de création de cluster interactifs
Le champDescription

Le nom du cluster

Entrez un nom pour votre cluster, par exemple my-rosa-cluster.

Domaine préfixe

Entrez un nom pour le préfixe de domaine pour le sous-domaine de votre cluster, par exemple my-rosa-cluster.

Déployez le cluster avec le plan de contrôle hébergé (facultatif)

Activer l’utilisation de plans de contrôle hébergés.

Créer un utilisateur admin cluster

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éer un mot de passe personnalisé pour l’administrateur du cluster

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.

Déployez le cluster à l’aide d’AWS STS

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.

La version OpenShift

Choisissez la version d’OpenShift à installer, par exemple 4. La version par défaut est la dernière version.

Configurer l’utilisation d’IMDSv2 pour les instances ec2 optionnelles/nécessaires (facultatif)

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).

Le rôle d’installateur ARN

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é.

ID externe (facultatif)

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.

Le préfixe des rôles d’opérateur

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.

Déployez le cluster à l’aide d’un identifiant de configuration OIDC pré-enregistré

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.

Étiquettes (facultatif)

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.

Différentes zones de disponibilité (facultatif)

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.

La région AWS

Indiquez la région AWS pour déployer le cluster. Cela remplace la variable d’environnement AWS_REGION.

Cluster PrivateLink (facultatif)

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.

CIDR machine

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.

CIDR de service

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.

Gousse CIDR

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.

Installer dans un VPC existant (facultatif)

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.

Choisissez les zones de disponibilité (facultatif)

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 la clé gérée par le client (facultatif)

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.

Calculer le type d’instance de nœuds

Choisissez un type d’instance de nœud de calcul. La valeur par défaut est m5.xlarge.

Activer l’autoscaling (facultatif)

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.

Identifiants supplémentaires de groupe de sécurité de calcul (facultatif)

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.

Identifiants supplémentaires du groupe de sécurité Infra (facultatif)

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.

Identifiants supplémentaires du groupe de sécurité des plans de contrôle (facultatif)

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.

Calculer les nœuds

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.

Étiquettes par défaut de pool de machines (facultatif)

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.

Hôte préfixe

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.

Dimension du disque racine de pool machine (GiB ou TiB)

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 le support FIPS (facultatif)

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.

Chiffrer les données etcd (facultatif)

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 de la charge de travail (facultatif)

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.

Choix d’itinéraire pour entrée (facultatif)

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.

Espaces de noms exclus pour entrée (facultatif)

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.

Wildcard Policy (facultatif, choisissez 'Skip' pour sauter la sélection. La valeur par défaut sera fournie.)

Choisissez la politique de wildcard pour votre entrée. Les options sont WildcardsDisallowed et WildcardsAllowed. La valeur par défaut est WildcardsDisallowed.

La politique de propriété de l’espace de noms (facultatif, choisissez 'Skip' pour sauter la sélection. La valeur par défaut sera fournie.)

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.

Il est possible de créer Red Hat OpenShift Service sur des clusters AWS (ROSA) dans des clouds privés virtuels (VPC) gérés de manière centralisée.

Important

Le partage de VPC sur plusieurs comptes AWS n’est actuellement pris en charge que pour les clusters ROSA Classic utilisant STS pour l’authentification.

Note

Ce processus nécessite deux comptes AWS distincts qui appartiennent à la même organisation AWS. D’un compte fonctionne comme le compte AWS propriétaire de VPC (VPC Owner), tandis que l’autre compte crée le cluster dans le compte AWS créateur de cluster (Cluster Creator).

Conditions préalables pour le propriétaire de VPC

  • Il y a un compte AWS avec les autorisations appropriées pour créer des rôles et partager des ressources.
  • Le compte AWS du Cluster Creator est séparé du compte AWS du propriétaire VPC.
  • Les deux comptes AWS appartiennent à la même organisation AWS.
  • Le partage des ressources a été activé à partir du compte de gestion de votre organisation.
  • Accès à la console AWS.

Conditions préalables pour le Créateur du cluster

  • Installation de la ROSA CLI (rosa) 1.2.26 ou ultérieure.
  • Il a créé tous les rôles et politiques nécessaires à l’échelle du compte pour créer un cluster.
  • Le compte AWS du Cluster Creator est séparé du compte AWS du propriétaire VPC.
  • Les deux comptes AWS appartiennent à la même organisation AWS.
Note

L’installation d’un cluster dans un VPC partagé n’est prise en charge que pour OpenShift 4.12.34 et versions ultérieures, 4.13.10 et ultérieures, et tous les futurs flux 4.y.

Dans un VPC configuré, vous pouvez partager des sous-réseaux avec un autre compte d’utilisateur AWS si ce compte se trouve dans votre organisation AWS actuelle.

Procédure

  1. Créez ou modifiez un VPC à vos spécifications dans la section VPC de la console AWS.
  2. Créez un fichier de stratégie personnalisé pour permettre les autorisations VPC partagées nécessaires qui utilisent le nom SharedVPCPolicy:

    $ cat <<EOF > /tmp/shared-vpc-policy.json
    {
        "Version": "2012-10-17",
        "Statement": [
            {
                "Effect": "Allow",
                "Action": [
                    "route53:ChangeResourceRecordSets",
                    "route53:ListHostedZones",
                    "route53:ListHostedZonesByName",
                    "route53:ListResourceRecordSets",
                    "route53:ChangeTagsForResource",
                    "route53:GetAccountLimit",
                    "route53:GetChange",
                    "route53:GetHostedZone",
                    "route53:ListTagsForResource",
                    "route53:UpdateHostedZoneComment",
                    "tag:GetResources",
                    "tag:UntagResources"
                ],
                "Resource": "*"
            }
        ]
    }
    EOF
    Copy to Clipboard Toggle word wrap
  3. Créer la stratégie dans AWS:

    $ aws iam create-policy \
        --policy-name SharedVPCPolicy \
        --policy-document file:///tmp/shared-vpc-policy.json
    Copy to Clipboard Toggle word wrap

    Cette politique sera jointe à un rôle nécessaire pour les autorisations VPC partagées.

  4. Créer un fichier de politique de confiance personnalisé qui accorde la permission d’assumer des rôles:

    $ cat <<EOF > /tmp/shared-vpc-role.json
    {
        "Version": "2012-10-17",
        "Statement": [
            {
                "Effect": "Allow",
                "Principal": {
                    "AWS": "arn:aws:iam::<Account-ID>:root"  
    1
    
                },
                "Action": "sts:AssumeRole"
            }
        ]
    }
    EOF
    Copy to Clipboard Toggle word wrap
    1
    Le principal sera réduit après que le Cluster Creator aura créé les rôles de cluster nécessaires. Lors de la création, vous devez créer un espace d’utilisateur root en utilisant l’ID de compte AWS de Cluster Creator comme arn:aws:iam::{Account}:root.
  5. Créer le rôle de l’IAM:

    $ aws iam create-role --role-name <role_name> \  
    1
    
        --assume-role-policy-document file:///tmp/shared-vpc-role.json
    Copy to Clipboard Toggle word wrap
    1
    &lt;role_name&gt; par le nom du rôle que vous souhaitez créer.
  6. Joindre la politique de permissions SharedVPCPolicy personnalisée:

    $ aws iam attach-role-policy --role-name <role_name> --policy-arn \  
    1
    
        arn:aws:iam::<AWS_account_ID>:policy/SharedVPCPolicy  
    2
    Copy to Clipboard Toggle word wrap
    1
    &lt;role_name&gt; par le nom du rôle que vous avez créé.
    2
    &lt;AWS_account_ID&gt; par l’ID du compte AWS du propriétaire de VPC.
  7. Fournissez l’ARN SharedVPCRole au Cluster Creator pour continuer la configuration.
Ressources supplémentaires
  • Consultez la documentation AWS pour partager vos ressources AWS.

Après que le propriétaire VPC crée un cloud privé virtuel, des sous-réseaux et un rôle IAM pour partager les ressources VPC, réserver un domaine DNS openshiftapps.com et créer des rôles d’opérateur pour communiquer avec le propriétaire VPC.

Note

Dans le cas des clusters VPC partagés, vous pouvez choisir de créer les rôles Opérateur après les étapes de création du cluster. Le cluster sera dans un état d’attente jusqu’à ce que le rôle ARN de l’opérateur Ingress soit ajouté aux relations de confiance du rôle VPC partagés.

Conditions préalables

  • Il y a le SharedVPCRole ARN pour le rôle IAM du propriétaire du VPC.

Procédure

  1. Créez un domaine DNS openshiftapps.com avec la commande suivante:

    $ rosa create dns-domain
    Copy to Clipboard Toggle word wrap

    La commande crée un domaine DNS openshiftapps.com réservé.

    I: DNS domain '14eo.p1.openshiftapps.com' has been created.
    I: To view all DNS domains, run 'rosa list dns-domains'
    Copy to Clipboard Toggle word wrap
  2. Créez une configuration OIDC.

    Consultez cet article pour plus d’informations sur le processus de configuration OIDC. La commande suivante produit l’identifiant de configuration OIDC dont vous avez besoin:

    $ rosa create oidc-config
    Copy to Clipboard Toggle word wrap

    La commande a créé une configuration OIDC:

    I: To create Operator Roles for this OIDC Configuration, run the following command and remember to replace <user-defined> with a prefix of your choice:
    	rosa create operator-roles --prefix <user-defined> --oidc-config-id 25tu67hq45rto1am3slpf5lq6jargg
    Copy to Clipboard Toggle word wrap
  3. Créez les rôles d’opérateur en entrant la commande suivante:

    $ rosa create operator-roles --oidc-config-id <oidc-config-ID> 
    1
    
        --installer-role-arn <Installer_Role> 
    2
    
        --shared-vpc-role-arn <Created_VPC_Role_Arn> 
    3
    
        --prefix <operator-prefix> 
    4
    Copy to Clipboard Toggle word wrap
    1
    Fournissez l’identifiant de configuration OIDC que vous avez créé à l’étape précédente.
    2
    Fournissez à votre installateur ARN qui a été créé dans le cadre du processus rosa créer des rôles de compte.
    3
    Fournissez l’ARN pour le rôle que le propriétaire de VPC a créé.
    4
    Fournir un préfixe pour les rôles d’opérateur.
    Note

    Le rôle de compte d’installateur et le rôle de VPC partagé doivent avoir une relation individuelle. Lorsque vous souhaitez créer plusieurs rôles VPC partagés, vous devez créer un ensemble de rôles de compte par rôle VPC partagé.

  4. Après avoir créé les rôles d’opérateur, partagez le nom de domaine complet, qui est créé avec &lt;intended_cluster_domain_prefix&gt;.&lt;reserved_dns_domain&gt;, votre ARN du rôle Ingress Operator Cloud Credentials et l’ARN du rôle Installer avec le propriétaire VPC pour continuer la configuration.

    L’information partagée ressemble à ces exemples:

    • ajoutez des tags pour my-rosa-cluster.14eo.p1.openshiftapps.com
    • ARN:aws:iam::111122223333:rôle/ManagedOpenShift-Installer-Role
    • ARN:aws:iam::111122223333:rôle/my-rosa-cluster-openshift-ingress-operator-cloud-credentials

Après que le Cluster Creator fournit le domaine DNS et les rôles IAM, créez une zone hébergée privée et mettez à jour la politique de confiance sur le rôle IAM qui a été créé pour partager le VPC.

Conditions préalables

  • Le nom de domaine complet du Cluster Creator est disponible.
  • Le rôle ARN de l’opérateur Ingress Cloud Credentials vient du créateur du cluster.
  • L’ARN du rôle d’installateur vient du Créateur du cluster.

Procédure

  1. Dans le gestionnaire d’accès aux ressources de la console AWS, créez une part de ressources qui partage les sous-réseaux publics et privés précédemment créés avec l’ID de compte AWS de Cluster Creator.
  2. Actualisez le rôle de partage de VPC et ajoutez les rôles d’Installer et Ingress Operator Cloud Credentials à la section principale de la politique de confiance.

    {
      "Version": "2012-10-17",
      "Statement": [
        {
    	  "Sid": "Statement1",
    	  "Effect": "Allow",
    	  "Principal": {
    	  	"AWS": [
              "arn:aws:iam::<Cluster-Creator's-AWS-Account-ID>:role/<prefix>-ingress-operator-cloud-credentials",
              "arn:aws:iam::<Cluster-Creator's-AWS-Account-ID>:role/<prefix>-Installer-Role"
            ]
    	  },
    	  "Action": "sts:AssumeRole"
    	}
      ]
    }
    Copy to Clipboard Toggle word wrap
  3. Créez une zone hébergée privée dans la section Route 53 de la console AWS. Dans la configuration de la zone hébergée, le nom de domaine est &lt;cluster_domain_prefix&gt;.&lt;reserved_dns_domain&gt;. La zone privée hébergée doit être associée au VPC créé.
  4. Après la création de la zone hébergée et associée au VPC, fournissez ce qui suit au Cluster Creator pour continuer la configuration:

    • ID de zone hébergée
    • La région AWS
    • ID de sous-réseau

Afin de créer un cluster dans un VPC partagé, complétez les étapes suivantes.

Note

L’installation d’un cluster dans un VPC partagé n’est prise en charge que pour OpenShift 4.12.34 et versions ultérieures, 4.13.10 et ultérieures, et tous les futurs flux 4.y.

Conditions préalables

  • L’identifiant de zone hébergé vous est fourni par le propriétaire de VPC.
  • Il y a la région AWS du propriétaire de VPC.
  • Les identifiants de sous-réseau du propriétaire de VPC sont disponibles.
  • Il y a le SharedVPCRole ARN du propriétaire du VPC.

Procédure

  • Dans un terminal, entrez la commande suivante pour créer le VPC partagé:

    rosa create cluster --cluster-name <cluster_name> --sts --operator-roles-prefix <prefix> --oidc-config-id <oidc_config_id> --region us-east-1 --subnet-ids <subnet_ids> --private-hosted-zone-id <hosted_zone_ID> --shared-vpc-role-arn <vpc-role-arn> --base-domain <dns-domain>
    Copy to Clipboard Toggle word wrap
Note

Lorsque 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.

Chapitre 7. Accéder à un cluster ROSA

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

Cette procédure d’accès rapide vous permet de vous connecter à votre cluster.

Note

En tant que meilleure pratique, accédez à votre cluster avec un compte IDP à la place.

Procédure

  1. Entrez la commande suivante:

    $ rosa create admin --cluster=<cluster_name>
    Copy to Clipboard Toggle word wrap

    Exemple de sortie

    W: It is recommended to add an identity provider to login to this cluster. See 'rosa create idp --help' for more information.
    I: Admin account has been added to cluster 'cluster_name'. It may take up to a minute for the account to become active.
    I: To login, run the following command:
    oc login https://api.cluster-name.t6k4.i1.organization.org:6443 \
    1
    
    --username cluster-admin \
    --password FWGYL-2mkJI-3ZTTZ-rINns
    Copy to Clipboard Toggle word wrap

    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.
  2. 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

    $ oc login https://api.cluster_name.t6k4.i1.organization.org:6443 \
    1
    
    >  --username cluster-admin \
    >  --password FWGYL-2mkJI-3ZTTZ-rINns
    Login successful.
    
    You have access to 77 projects, the list has been suppressed. You can list all projects with 'projects'
    Copy to Clipboard Toggle word wrap

    1
    Dans le cas d’un ROSA doté d’un cluster HCP, le numéro de port devrait être de 443.
  3. À 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
    Copy to Clipboard Toggle word wrap

    Exemple de sortie

    cluster-admin
    Copy to Clipboard Toggle word wrap

7.2. Accéder à votre cluster avec un compte IDP

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.

Note

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:

  1. Ajoutez une PDI.

    1. 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
      Copy to Clipboard Toggle word wrap
    2. 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

      I: Interactive mode enabled.
      Any optional fields can be left empty and a default will be selected.
      ? Type of identity provider: github
      ? Restrict to members of: organizations
      ? GitHub organizations: rh-test-org
      ? To use GitHub as an identity provider, you must first register the application:
        - Open the following URL:
          https://github.com/organizations/rh-rosa-test-cluster/settings/applications/new?oauth_application%5Bcallback_url%5D=https%3A%2F%2Foauth-openshift.apps.rh-rosa-test-cluster.z7v0.s1.devshift.org%2Foauth2callback%2Fgithub-1&oauth_application%5Bname%5D=rh-rosa-test-cluster-stage&oauth_application%5Burl%5D=https%3A%2F%2Fconsole-openshift-console.apps.rh-rosa-test-cluster.z7v0.s1.devshift.org
        - Click on 'Register application'
      ...
      Copy to Clipboard Toggle word wrap

    3. 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.

      Note

      Les 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.

    4. Consultez les informations de l’application GitHub que vous avez créée et continuez les instructions. Entrez les valeurs suivantes:

      • Identifiant client: &lt;my_github_client_id&gt;
      • Client Secret: [? pour l’aide] &lt;my_github_client_secret&gt;
      • Hostname: (facultatif, vous pouvez le laisser vide pour l’instant)
      • La méthode de cartographie: revendication

      Exemple continu de sortie

      ...
      ? Client ID: <my_github_client_id>
      ? Client Secret: [? for help] <my_github_client_secret>
      ? Hostname:
      ? Mapping method: claim
      I: Configuring IDP for cluster 'rh_rosa_test_cluster'
      I: Identity Provider 'github-1' has been created. You need to ensure that there is a list of cluster administrators defined. See 'rosa create user --help' for more information. To login into the console, open https://console-openshift-console.apps.rh-test-org.z7v0.s1.devshift.org and click on github-1
      Copy to Clipboard Toggle word wrap

      Le PDI peut prendre 1-2 minutes pour être configuré dans votre cluster.

    5. Entrez la commande suivante pour vérifier que votre PDI a été configuré correctement:

      $ rosa list idps --cluster=<cluster_name>
      Copy to Clipboard Toggle word wrap

      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
      Copy to Clipboard Toggle word wrap

  2. Connectez-vous à votre cluster.

    1. Entrez la commande suivante pour obtenir l’URL de la console de votre cluster:

      $ rosa describe cluster --cluster=<cluster_name>
      Copy to Clipboard Toggle word wrap

      Exemple de sortie

      Name:        rh-rosa-test-cluster1
      ID:          1de87g7c30g75qechgh7l5b2bha6r04e
      External ID: 34322be7-b2a7-45c2-af39-2c684ce624e1
      API URL:     https://api.rh-rosa-test-cluster1.j9n4.s1.devshift.org:6443 
      1
      
      Console URL: https://console-openshift-console.apps.rh-rosa-test-cluster1.j9n4.s1.devshift.org
      Nodes:       Master: 3, Infra: 3, Compute: 4
      Region:      us-east-2
      State:       ready
      Created:     May 27, 2020
      Copy to Clipboard Toggle word wrap

      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.
    2. Accédez à l’URL de la console et connectez-vous à l’aide de vos identifiants Github.
    3. En haut à droite de la console OpenShift, cliquez sur votre nom et cliquez sur Copier la commande de connexion.
    4. Choisissez le nom du PDI que vous avez ajouté (dans notre cas github-1), puis cliquez sur Affichage du jeton.
    5. 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 
      1
      Copy to Clipboard Toggle word wrap
      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. 
      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 Toggle word wrap

      1
      Dans le cas d’un ROSA doté d’un cluster HCP, le numéro de port devrait être de 443.
    6. Entrez une commande oc simple pour vérifier que tout est configuré correctement et que vous êtes connecté.

      $ oc version
      Copy to Clipboard Toggle word wrap

      Exemple de sortie

      Client Version: 4.4.0-202005231254-4a4cd75
      Server Version: 4.3.18
      Kubernetes Version: v1.16.2
      Copy to Clipboard Toggle word wrap

7.3. Octroi d’un accès cluster-admin

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

  1. Donnez à votre utilisateur cluster-admin privilèges:

    $ rosa grant user cluster-admin --user=<idp_user_name> --cluster=<cluster_name>
    Copy to Clipboard Toggle word wrap
  2. Assurez-vous que votre utilisateur est listé en tant qu’administrateur de cluster:

    $ rosa list users --cluster=<cluster_name>
    Copy to Clipboard Toggle word wrap

    Exemple de sortie

    GROUP             NAME
    cluster-admins    rh-rosa-test-user
    dedicated-admins  rh-rosa-test-user
    Copy to Clipboard Toggle word wrap

  3. 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
    Copy to Clipboard Toggle word wrap

    Exemple de sortie

    NAME                  READY   STATUS    RESTARTS   AGE
    pod/apiserver-6ndg2   1/1     Running   0          17h
    pod/apiserver-lrmxs   1/1     Running   0          17h
    pod/apiserver-tsqhz   1/1     Running   0          17h
    NAME          TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)   AGE
    service/api   ClusterIP   172.30.23.241   <none>        443/TCP   18h
    NAME                       DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR                     AGE
    daemonset.apps/apiserver   3         3         3       3            3           node-role.kubernetes.io/master=   18h
    Copy to Clipboard Toggle word wrap

7.4. Octroi d’un accès admin dédié

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

  1. Entrez la commande suivante pour promouvoir votre utilisateur à un administrateur dédié:

    $ rosa grant user dedicated-admin --user=<idp_user_name> --cluster=<cluster_name>
    Copy to Clipboard Toggle word wrap
  2. 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
    Copy to Clipboard Toggle word wrap

    Exemple de sortie

    NAME               USERS
    dedicated-admins   rh-rosa-test-user
    Copy to Clipboard Toggle word wrap

    Note

    L’erreur interdite s’affiche si l’utilisateur sans privilèges d’administration dédié exécute cette commande.

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é

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

Les types de fournisseurs d’identité suivants peuvent être configurés:

Expand
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é.

Google

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é

Les paramètres suivants sont communs à tous les fournisseurs d’identité:

Expand
Le paramètreDescription

le nom

Le nom du fournisseur est préfixé aux noms d’utilisateur du fournisseur pour former un nom d’identité.

CartographieMéthode

Définit comment les nouvelles identités sont cartographiées aux utilisateurs lorsqu’ils se connectent. Entrez l’une des valeurs suivantes:

demande d ' indemnisation
La valeur par défaut. Fournit un utilisateur avec le nom d’utilisateur préféré de l’identité. Échoue si un utilisateur avec ce nom d’utilisateur est déjà mappé vers une autre identité.
la recherche
Cherche une identité existante, la cartographie de l’identité utilisateur et l’utilisateur, mais ne fournit pas automatiquement les utilisateurs ou les identités. Cela permet aux administrateurs de cluster de configurer manuellement les identités et les utilisateurs, ou d’utiliser un processus externe. En utilisant cette méthode, vous devez fournir manuellement les utilisateurs.
ajouter
Fournit un utilisateur avec le nom d’utilisateur préféré de l’identité. Lorsqu’un utilisateur avec ce nom d’utilisateur existe déjà, l’identité est cartographiée à l’utilisateur existant, ajoutant à tout mappage d’identité existant pour l’utilisateur. Requis lorsque plusieurs fournisseurs d’identité sont configurés qui identifient le même ensemble d’utilisateurs et cartographient les mêmes noms d’utilisateur.
Note

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

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.

Avertissement

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

  1. À 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é.
  2. Cliquez sur l’onglet Contrôle d’accès.
  3. Cliquez sur Ajouter un fournisseur d’identité.

    Note

    Il 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é.

  4. Choisissez GitHub dans le menu déroulant.
  5. 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>
      Copy to Clipboard Toggle word wrap

      À titre d’exemple:

      https://oauth-openshift.apps.openshift-cluster.example.com/oauth2callback/github
      Copy to Clipboard Toggle word wrap
  6. Enregistrez une demande sur GitHub.
  7. 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.
  8. Entrez l’ID Client et le secret du client fournis par GitHub.
  9. 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.
  10. 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é.
  11. Choisissez Utilisez des organisations ou Utilisez les équipes pour restreindre l’accès à une organisation GitHub particulière ou à une équipe GitHub.
  12. 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.
  13. 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

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

  1. À 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é.
  2. Cliquez sur l’onglet Contrôle d’accès.
  3. Cliquez sur Ajouter un fournisseur d’identité.

    Note

    Il 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é.

  4. Choisissez GitLab dans le menu déroulant.
  5. 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>
      Copy to Clipboard Toggle word wrap

      À titre d’exemple:

      https://oauth-openshift.apps.openshift-cluster.example.com/oauth2callback/gitlab
      Copy to Clipboard Toggle word wrap
  6. Ajouter une nouvelle application dans GitLab.
  7. 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.
  8. Entrez l’ID Client et le secret client fournis par GitLab.
  9. Entrez l’URL de votre fournisseur GitLab.
  10. 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é.
  11. 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

Configurez un fournisseur d’identité Google pour permettre aux utilisateurs de s’authentifier avec leurs identifiants Google.

Avertissement

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

  1. À 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é.
  2. Cliquez sur l’onglet Contrôle d’accès.
  3. Cliquez sur Ajouter un fournisseur d’identité.

    Note

    Il 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é.

  4. Choisissez Google dans le menu déroulant.
  5. 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>
      Copy to Clipboard Toggle word wrap

      À titre d’exemple:

      https://oauth-openshift.apps.openshift-cluster.example.com/oauth2callback/google
      Copy to Clipboard Toggle word wrap
  6. Configurez un fournisseur d’identité Google en utilisant l’intégration OpenID Connect de Google.
  7. 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.
  8. Entrez l’ID Client d’un projet Google enregistré et le secret client émis par Google.
  9. Entrez un domaine hébergé pour restreindre les utilisateurs à un domaine Google Apps.
  10. 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

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
    Copy to Clipboard Toggle word wrap
    Expand
    Composant URLDescription

    LDAP

    Dans 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:port

    Le nom et le port du serveur LDAP. Défaut à localhost:389 pour ldap et localhost:636 pour LDAPS.

    baseDN

    Le 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.

    attribut

    L’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’application

    La 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.

    filtrer

    Filtre 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>))
    Copy to Clipboard Toggle word wrap
    Important

    Lorsque 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

  1. À 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é.
  2. Cliquez sur l’onglet Contrôle d’accès.
  3. Cliquez sur Ajouter un fournisseur d’identité.

    Note

    Il 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é.

  4. Choisissez LDAP dans le menu déroulant.
  5. Entrez un nom unique pour le fournisseur d’identité. Ce nom ne peut pas être changé plus tard.
  6. Choisissez une méthode de cartographie dans le menu déroulant. La réclamation est recommandée dans la plupart des cas.
  7. Entrez une URL LDAP pour spécifier les paramètres de recherche LDAP à utiliser.
  8. Facultatif: Entrez un mot de passe Bind DN et Bind.
  9. 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.
  10. 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é.
  11. 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é.

    Important

    Lorsque 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.

  12. 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

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.

Important

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:

Expand
Demande d ' indemnisationDescription

favorite_nom d’utilisateur

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.

e-mail

Adresse e-mail.

le nom

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

  1. À 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é.
  2. Cliquez sur l’onglet Contrôle d’accès.
  3. Cliquez sur Ajouter un fournisseur d’identité.

    Note

    Il 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é.

  4. Choisissez OpenID dans le menu déroulant.
  5. 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>
      Copy to Clipboard Toggle word wrap

      À titre d’exemple:

      https://oauth-openshift.apps.openshift-cluster.example.com/oauth2callback/openid
      Copy to Clipboard Toggle word wrap
  6. Enregistrez un nouveau client OpenID Connect dans le fournisseur d’identité OpenID en suivant les étapes pour créer une demande d’autorisation.
  7. 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.
  8. Entrez un identifiant client et un secret client fourni à partir d’OpenID.
  9. 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.
  10. 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.
  11. 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.
  12. 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.
  13. Facultatif: Cliquez sur Afficher les options avancées pour ajouter un fichier d’autorité de certificat (CA) à votre fournisseur d’identité OpenID.
  14. Facultatif: Sous les options avancées, vous pouvez ajouter des zones supplémentaires. La portée OpenID est demandée par défaut.
  15. 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

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.

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.

Procédure

  1. À partir d’OpenShift Cluster Manager, accédez à la page Liste des clusters et sélectionnez votre cluster.
  2. Choisissez Contrôle d’accès → Fournisseurs d’identité.
  3. Cliquez sur Ajouter un fournisseur d’identité.
  4. Choisissez HTPasswd dans le menu déroulant fournisseur d’identité.
  5. Ajoutez un nom unique dans le champ Nom du fournisseur d’identité.
  6. Utilisez le nom d’utilisateur et le mot de passe suggérés pour l’utilisateur statique, ou créez le vôtre.

    Note

    Les 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.

  7. Cliquez sur Ajouter pour créer le fournisseur d’identité htpasswd et l’utilisateur unique et statique.
  8. Accordez l’autorisation de l’utilisateur statique pour gérer le cluster:

    1. Dans Contrôle d’accès → Rôles de cluster et Accès, sélectionnez Ajouter un utilisateur.
    2. Entrez l’identifiant utilisateur de l’utilisateur statique que vous avez créé à l’étape précédente.
    3. 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.
    4. 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é.

    Note

    Aprè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

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.

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.

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

  1. 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>
    Copy to Clipboard Toggle word wrap
  2. 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
    Copy to Clipboard Toggle word wrap

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

  1. Entrez la commande suivante pour révoquer l’accès cluster-admin d’un utilisateur:

    $ rosa revoke user cluster-admins --user=myusername --cluster=mycluster
    Copy to Clipboard Toggle word wrap
  2. 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
    Copy to Clipboard Toggle word wrap

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

  1. Dans l’onglet Liste des clusters d’OpenShift Cluster Manager, sélectionnez le nom de votre cluster pour afficher les détails du cluster.
  2. Choisissez Contrôle d’accès &gt; Rôles de cluster et Accès.
  3. 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

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

  • 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.

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).

Note

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.

Important

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

  1. 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> 
    1
    Copy to Clipboard Toggle word wrap
    1
    &lt;cluster_name&gt; par le nom de votre cluster.

    Exemple de sortie

    Name:                       mycluster
    ID:                         1s3v4x39lhs8sm49m90mi0822o34544a 
    1
    
    ...
    Operator IAM Roles: 
    2
    
     - arn:aws:iam::<aws_account_id>:role/mycluster-x4q9-openshift-machine-api-aws-cloud-credentials
     - arn:aws:iam::<aws_account_id>:role/mycluster-x4q9-openshift-cloud-credential-operator-cloud-crede
     - arn:aws:iam::<aws_account_id>:role/mycluster-x4q9-openshift-image-registry-installer-cloud-creden
     - arn:aws:iam::<aws_account_id>:role/mycluster-x4q9-openshift-ingress-operator-cloud-credentials
     - arn:aws:iam::<aws_account_id>:role/mycluster-x4q9-openshift-cluster-csi-drivers-ebs-cloud-credent
     - arn:aws:iam::<aws_account_id>:role/mycluster-x4q9-openshift-cloud-network-config-controller-cloud
    State:                      ready
    Private:                    No
    Created:                    May 13 2022 11:26:15 UTC
    Details Page:               https://console.redhat.com/openshift/details/s/296kyEFwzoy1CREQicFRdZybrc0
    OIDC Endpoint URL:          https://oidc.op1.openshiftapps.com/<oidc_config_id> 
    3
    Copy to Clipboard Toggle word wrap

    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::&lt;aws_account_id&gt;: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.
    Important

    L’ID de cluster doit supprimer les ressources STS spécifiques au cluster en utilisant le ROSA CLI (rosa) une fois le cluster supprimé.

  2. Effacer le cluster:

    • De supprimer le cluster en utilisant Red Hat OpenShift Cluster Manager:

      1. Accédez à OpenShift Cluster Manager.
      2. Cliquez sur le menu Options à côté de votre cluster et sélectionnez Supprimer le cluster.
      3. Entrez le nom de votre cluster à l’invite et cliquez sur Supprimer.
    • De supprimer le cluster à l’aide de la ROSA CLI (rosa):

      1. Entrez la commande suivante pour supprimer le cluster et regarder les journaux, en remplaçant &lt;cluster_name&gt; par le nom ou l’ID de votre cluster:

        $ rosa delete cluster --cluster=<cluster_name> --watch
        Copy to Clipboard Toggle word wrap
        Important

        Il 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.

  3. Effacer le fournisseur OIDC que les opérateurs de cluster utilisent pour authentifier:

    $ rosa delete oidc-provider -c <cluster_id> --mode auto 
    1
    Copy to Clipboard Toggle word wrap
    1
    &lt;cluster_id&gt; par l’ID du cluster.
    Note

    L’option -y vous permet de répondre automatiquement oui aux invitations.

  4. En option. Effacer les rôles IAM d’opérateur spécifiques au cluster:

    Important

    Les 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 
    1
    Copy to Clipboard Toggle word wrap
    1
    &lt;cluster_id&gt; 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.

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.

Important

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.

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.

Important

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

  1. Effacer les rôles à l’échelle du compte:

    1. Énumérez les rôles à l’échelle du compte dans votre compte AWS en utilisant le ROSA CLI (rosa):

      $ rosa list account-roles
      Copy to Clipboard Toggle word wrap

      Exemple de sortie

      I: Fetching account roles
      ROLE NAME                           ROLE TYPE      ROLE ARN                                                           OPENSHIFT VERSION
      ManagedOpenShift-ControlPlane-Role  Control plane  arn:aws:iam::<aws_account_id>:role/ManagedOpenShift-ControlPlane-Role  4.10
      ManagedOpenShift-Installer-Role     Installer      arn:aws:iam::<aws_account_id>:role/ManagedOpenShift-Installer-Role     4.10
      ManagedOpenShift-Support-Role       Support        arn:aws:iam::<aws_account_id>:role/ManagedOpenShift-Support-Role       4.10
      ManagedOpenShift-Worker-Role        Worker         arn:aws:iam::<aws_account_id>:role/ManagedOpenShift-Worker-Role        4.10
      Copy to Clipboard Toggle word wrap

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
Copy to Clipboard Toggle word wrap
  1. Effacer les rôles à l’échelle du compte:

    $ rosa delete account-roles --prefix <prefix> --mode auto 
    1
    Copy to Clipboard Toggle word wrap
    1
    Il faut inclure l’argument --&lt;prefix&gt;. &lt;prefix&gt; 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.
    Important

    Les 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

    W: There are no classic account roles to be deleted
    I: Deleting hosted CP account roles
    ? Delete the account role 'delete-rosa-HCP-ROSA-Installer-Role'? Yes
    I: Deleting account role 'delete-rosa-HCP-ROSA-Installer-Role'
    ? Delete the account role 'delete-rosa-HCP-ROSA-Support-Role'? Yes
    I: Deleting account role 'delete-rosa-HCP-ROSA-Support-Role'
    ? Delete the account role 'delete-rosa-HCP-ROSA-Worker-Role'? Yes
    I: Deleting account role 'delete-rosa-HCP-ROSA-Worker-Role'
    I: Successfully deleted the hosted CP account roles
    Copy to Clipboard Toggle word wrap

    1. Effacer les politiques en ligne à l’échelle du compte et de l’opérateur:
  2. 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.

    Note

    Lorsque 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.

  3. 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.

    Important

    Les 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.

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).

Important

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

  1. Déconnectez le rôle de gestionnaire de cluster OpenShift de votre organisation Red Hat et supprimez le rôle:

    1. Liste des rôles OpenShift Cluster Manager IAM dans votre compte AWS:

      $ rosa list ocm-roles
      Copy to Clipboard Toggle word wrap

      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
      Copy to Clipboard Toggle word wrap

    2. 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> 
      1
      Copy to Clipboard Toggle word wrap
      1
      &lt;arn&gt; 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::&lt;aws_account_id&gt;:role/ManagedOpenShift-OCM-Role-&lt;red_hat_organization_external_id&gt;.

      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>'
      Copy to Clipboard Toggle word wrap

    3. Effacer le rôle et les politiques du gestionnaire de cluster OpenShift:

      $ rosa delete ocm-role --role-arn <arn>
      Copy to Clipboard Toggle word wrap

      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 
      1
      
      I: Successfully deleted the OCM role
      Copy to Clipboard Toggle word wrap

      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.
  2. Déconnectez le rôle de l’utilisateur IAM de votre organisation Red Hat et supprimez le rôle:

    1. Énumérez les rôles IAM d’utilisateur dans votre compte AWS:

      $ rosa list user-roles
      Copy to Clipboard Toggle word wrap

      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
      Copy to Clipboard Toggle word wrap

    2. 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> 
      1
      Copy to Clipboard Toggle word wrap
      1
      &lt;arn&gt; 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::&lt;aws_account_id&gt;:role/ManagedOpenShift-User-&lt;ocm_user_name&gt;-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>'
      Copy to Clipboard Toggle word wrap

    3. Effacer le rôle de l’utilisateur IAM:

      $ rosa delete user-role --role-arn <arn>
      Copy to Clipboard Toggle word wrap

      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 
      1
      
      I: Successfully deleted the user role
      Copy to Clipboard Toggle word wrap

      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

11.1. AWS prérequis pour ROSA

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.

Astuce

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

Les clusters Red Hat OpenShift Service sur AWS (ROSA) doivent répondre à plusieurs prérequis avant de pouvoir être déployés.

Note

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
  • 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.

    Note

    Il 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.

    Note

    Les 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
  • 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).

    Note

    Cette 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
  • 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é
  • 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

Complétez ces étapes avant de déployer Red Hat OpenShift Service sur AWS (ROSA).

Procédure

  1. 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.
  2. 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.
  3. Attachez le SCP au compte AWS.
  4. Suivre les procédures ROSA pour la mise en place de l’environnement.

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.

Note

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.

Expand
 Le serviceActionsEffet

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

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
Note

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.

    {
        "Version": "2012-10-17",
        "Statement": [
            {
                "Action": "*",
                "Resource": "*",
                "Effect": "Allow"
            }
        ]
    }
    Copy to Clipboard Toggle word wrap
11.1.3.2. Les utilisateurs de l’IAM

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

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

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

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
Note

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

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

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.

Note

Deux seaux sont nécessaires avec une taille typique de 2 To chacun.

11.1.4.5. LE VPC

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é.

    Note

    Le 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é

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.

Expand
Tableau 11.1. Les ports requis pour les groupes de sécurité par défaut
Groupe de travailLe typeLe protocole de propriété intellectuelleGamme de ports

Groupe MasterSecurity

AWS :: EC2 ::SecurityGroup

ICMP

0

le TCP

22

le TCP

6443

le TCP

22623

Groupe WorkerSecurity

AWS :: EC2 ::SecurityGroup

ICMP

0

le TCP

22

BootstrapSecurityGroup

AWS :: EC2 ::SecurityGroup

le TCP

22

le TCP

19531

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

11.1.5.1. Bande passante minimale

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.6. Les prochaines étapes

11.2. Comprendre le flux de travail de déploiement ROSA

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.

Astuce

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

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).

  1. Effectuez les prérequis AWS. Afin de déployer un cluster ROSA, votre compte AWS doit répondre aux exigences préalables.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. 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.
  8. 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

Consultez cette liste des quotas de service Amazon Web Service (AWS) requis pour exécuter un service Red Hat OpenShift sur AWS cluster.

Astuce

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

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.
Note

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.

Expand
Tableau 11.2. Contingent de service requis par ROSA
Le nom du quotaCode de serviceCode de quotaAWS par défautLe minimum requisDescription

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.

Expand
Tableau 11.3. Quotas généraux de service AWS
Le nom du quotaCode de serviceCode de quotaAWS par défautLe minimum requisDescription

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

11.4. Configuration de votre compte AWS

Après avoir rempli les conditions préalables AWS, configurez votre compte AWS et activez le service Red Hat OpenShift sur AWS (ROSA).

Astuce

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

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

  1. 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.

    Note

    Cet utilisateur dispose d’un accès programmatique activé et de la politique AdministratorAccess qui lui est associée.

  2. Activer le service ROSA dans la console AWS.

    1. Connectez-vous à votre compte AWS.
    2. Afin d’activer ROSA, accédez au service ROSA et sélectionnez Activer OpenShift.
  3. Installez et configurez le CLI AWS.

    1. 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.

    2. Définissez une région AWS par défaut.

      Note

      Il 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:

      1. La région spécifiée lors de l’exécution de la commande rosa avec le drapeau --région.
      2. 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.
      3. 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.
    3. 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:

      1. Le profil spécifié lors de l’exécution de la commande rosa avec le drapeau --profile.
      2. Le profil défini dans la variable d’environnement AWS_PROFILE. Consultez les profils nommés dans la documentation AWS.
    4. 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
      Copy to Clipboard Toggle word wrap

      Exemple de sortie

      <aws_account_id>    arn:aws:iam::<aws_account_id>:user/<username>  <aws_user_id>
      Copy to Clipboard Toggle word wrap

      Après avoir terminé ces étapes, installez ROSA.

11.4.2. Les prochaines étapes

Après avoir configuré votre compte AWS, installez et configurez le Red Hat OpenShift Service sur AWS (ROSA) CLI, rosa.

Astuce

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

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

  1. Installez rosa, le service Red Hat OpenShift sur l’interface de ligne de commande AWS (CLI).

    1. Cliquez ici pour télécharger la dernière version de la ROSA CLI pour votre système d’exploitation.
    2. 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.
    3. En option: Ajoutez rosa à votre chemin.

      Exemple :

      $ mv rosa /usr/local/bin/rosa
      Copy to Clipboard Toggle word wrap

    4. Entrez la commande suivante pour vérifier votre installation:

      $ rosa
      Copy to Clipboard Toggle word wrap

      Exemple de sortie

      Command line tool for Red Hat OpenShift Service on AWS.
      For further documentation visit https://access.redhat.com/documentation/en-us/red_hat_openshift_service_on_aws
      
      Usage:
        rosa [command]
      
      Available Commands:
        completion  Generates completion scripts
        create      Create a resource from stdin
        delete      Delete a specific resource
        describe    Show details of a specific resource
        download    Download necessary tools for using your cluster
        edit        Edit a specific resource
        grant       Grant role to a specific resource
        help        Help about any command
        init        Applies templates to support Red Hat OpenShift Service on AWS
        install     Installs a resource into a cluster
        link        Link a ocm/user role from stdin
        list        List all resources of a specific type
        login       Log in to your Red Hat account
        logout      Log out
        logs        Show installation or uninstallation logs for a cluster
        revoke      Revoke role from a specific resource
        uninstall   Uninstalls a resource from a cluster
        unlink      UnLink a ocm/user role from stdin
        upgrade     Upgrade a resource
        verify      Verify resources are configured correctly for cluster install
        version     Prints the version of the tool
        whoami      Displays user account information
      
      Flags:
            --color string   Surround certain characters with escape sequences to display them in color on the terminal. Allowed options are [auto never always] (default "auto")
            --debug          Enable debug mode.
        -h, --help           help for rosa
      
      Use "rosa [command] --help" for more information about a command.
      Copy to Clipboard Toggle word wrap

    5. 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
      Copy to Clipboard Toggle word wrap
    6. 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
      Copy to Clipboard Toggle word wrap
  2. Connectez-vous à votre compte Red Hat avec rosa.

    1. Entrez la commande suivante.

      $ rosa login
      Copy to Clipboard Toggle word wrap
    2. &lt;my_offline_access_token&gt; 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>
      Copy to Clipboard Toggle word wrap

      Exemple de sortie continue

      I: Logged in as 'rh-rosa-user' on 'https://api.openshift.com'
      Copy to Clipboard Toggle word wrap

  3. Entrez la commande suivante pour vérifier que votre compte AWS dispose des autorisations nécessaires.

    $ rosa verify permissions
    Copy to Clipboard Toggle word wrap

    Exemple de sortie

    I: Validating SCP policies...
    I: AWS SCP policies ok
    Copy to Clipboard Toggle word wrap

    Note

    Cette commande vérifie les autorisations uniquement pour les clusters ROSA qui n’utilisent pas AWS Security Token Service (STS).

  4. 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
    Copy to Clipboard Toggle word wrap

    Exemple de sortie

    I: Validating AWS quota...
    I: AWS quota ok
    Copy to Clipboard Toggle word wrap

    Note

    Il 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.

  5. Créez votre compte AWS pour le déploiement de clusters:

    1. 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
      Copy to Clipboard Toggle word wrap

      Exemple de sortie

      AWS Account ID:               000000000000
      AWS Default Region:           us-east-2
      AWS ARN:                      arn:aws:iam::000000000000:user/hello
      OCM API:                      https://api.openshift.com
      OCM Account ID:               1DzGIdIhqEWyt8UUXQhSoWaaaaa
      OCM Account Name:             Your Name
      OCM Account Username:         you@domain.com
      OCM Account Email:            you@domain.com
      OCM Organization ID:          1HopHfA2hcmhup5gCr2uH5aaaaa
      OCM Organization Name:        Red Hat
      OCM Organization External ID: 0000000
      Copy to Clipboard Toggle word wrap

    2. 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
      Copy to Clipboard Toggle word wrap

      Exemple de sortie

      I: Logged in as 'rh-rosa-user' on 'https://api.openshift.com'
      I: Validating AWS credentials...
      I: AWS credentials are valid!
      I: Validating SCP policies...
      I: AWS SCP policies ok
      I: Validating AWS quota...
      I: AWS quota ok
      I: Ensuring cluster administrator user 'osdCcsAdmin'...
      I: Admin user 'osdCcsAdmin' created successfully!
      I: Verifying whether OpenShift command-line tool is available...
      E: OpenShift command-line tool is not installed.
      Run 'rosa download oc' to download the latest version, then add it to your PATH.
      Copy to Clipboard Toggle word wrap

  6. Installez l’OpenShift CLI (oc) à partir du ROSA CLI.

    1. Entrez cette commande pour télécharger la dernière version du CLI oc:

      $ rosa download oc
      Copy to Clipboard Toggle word wrap
    2. Après avoir téléchargé le CLI oc, décompressez-le et ajoutez-le à votre chemin.
    3. Entrez cette commande pour vérifier que le CLI oc est installé correctement:

      $ rosa verify oc
      Copy to Clipboard Toggle word wrap

Après avoir installé ROSA, vous êtes prêt à créer un cluster.

11.5.2. Les prochaines étapes

  • Créez un cluster ROSA ou créez un cluster AWS PrivateLink sur ROSA.

11.6. Créer un cluster ROSA sans AWS STS

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.

Astuce

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

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.

Note

Les PCV AWS partagés ne sont pas actuellement pris en charge pour les installations ROSA.

Procédure

  1. 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.

    Note

    Des 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>
      Copy to Clipboard Toggle word wrap

      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`.
      Copy to Clipboard Toggle word wrap

    • Créer un cluster à l’aide d’invites interactives:

      $ rosa create cluster --interactive
      Copy to Clipboard Toggle word wrap
    • 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
  2. 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>
    Copy to Clipboard Toggle word wrap

    Exemple de sortie

    Name: rh-rosa-test-cluster1
    OpenShift Version: 4.6.8
    DNS: *.example.com
    ID: uniqueidnumber
    External ID: uniqueexternalidnumber
    AWS Account: 123456789101
    API URL: https://api.rh-rosa-test-cluster1.example.org:6443
    Console URL: https://console-openshift-console.apps.rh-rosa-test-cluster1.example.or
    Nodes: Master: 3, Infra: 2, Compute: 2
    Region: us-west-2
    Multi-AZ: false
    State: ready
    Channel Group: stable
    Private: No
    Created: Jan 15 2021 16:30:55 UTC
    Details Page: https://console.redhat.com/examplename/details/idnumber
    Copy to Clipboard Toggle word wrap

    Note

    En 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.

  3. 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
    Copy to Clipboard Toggle word wrap

11.6.2. Les prochaines étapes

Configurer les fournisseurs d’identité

11.7. Configuration d’un cluster privé

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

Lors de la création d’un nouveau service Red Hat OpenShift sur AWS, vous pouvez activer le paramètre cluster privé.

Important

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
Copy to Clipboard Toggle word wrap
Note

Alternativement, utilisez --interactive pour être invité pour chaque option de cluster.

11.7.2. Activer un cluster privé sur un cluster existant

Après la création d’un cluster, vous pouvez plus tard activer le cluster pour être privé.

Important

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
Copy to Clipboard Toggle word wrap
Note

La transition de votre cluster entre privé et public peut prendre plusieurs minutes.

11.8. La suppression de l’accès à un cluster ROSA

Effacer l’accès à un Red Hat OpenShift Service sur AWS (ROSA) cluster en utilisant la ligne de commande rosa.

Astuce

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.

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

  1. 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>
    Copy to Clipboard Toggle word wrap
  2. 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
    Copy to Clipboard Toggle word wrap

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

  1. Entrez la commande suivante pour révoquer l’accès cluster-admin d’un utilisateur:

    $ rosa revoke user cluster-admins --user=myusername --cluster=mycluster
    Copy to Clipboard Toggle word wrap
  2. 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
    Copy to Clipboard Toggle word wrap

11.9. La suppression d’un cluster ROSA

Effacer un Red Hat OpenShift Service sur AWS (ROSA) cluster en utilisant la ligne de commande rosa.

Astuce

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

  • 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.

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).

Note

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.

Important

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

  1. 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> 
    1
    Copy to Clipboard Toggle word wrap
    1
    &lt;cluster_name&gt; par le nom de votre cluster.

    Exemple de sortie

    Name:                       mycluster
    ID:                         1s3v4x39lhs8sm49m90mi0822o34544a 
    1
    
    ...
    Operator IAM Roles: 
    2
    
     - arn:aws:iam::<aws_account_id>:role/mycluster-x4q9-openshift-machine-api-aws-cloud-credentials
     - arn:aws:iam::<aws_account_id>:role/mycluster-x4q9-openshift-cloud-credential-operator-cloud-crede
     - arn:aws:iam::<aws_account_id>:role/mycluster-x4q9-openshift-image-registry-installer-cloud-creden
     - arn:aws:iam::<aws_account_id>:role/mycluster-x4q9-openshift-ingress-operator-cloud-credentials
     - arn:aws:iam::<aws_account_id>:role/mycluster-x4q9-openshift-cluster-csi-drivers-ebs-cloud-credent
     - arn:aws:iam::<aws_account_id>:role/mycluster-x4q9-openshift-cloud-network-config-controller-cloud
    State:                      ready
    Private:                    No
    Created:                    May 13 2022 11:26:15 UTC
    Details Page:               https://console.redhat.com/openshift/details/s/296kyEFwzoy1CREQicFRdZybrc0
    OIDC Endpoint URL:          https://oidc.op1.openshiftapps.com/<oidc_config_id> 
    3
    Copy to Clipboard Toggle word wrap

    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::&lt;aws_account_id&gt;: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.
    Important

    L’ID de cluster doit supprimer les ressources STS spécifiques au cluster en utilisant le ROSA CLI (rosa) une fois le cluster supprimé.

  2. Effacer le cluster:

    • De supprimer le cluster en utilisant Red Hat OpenShift Cluster Manager:

      1. Accédez à OpenShift Cluster Manager.
      2. Cliquez sur le menu Options à côté de votre cluster et sélectionnez Supprimer le cluster.
      3. Entrez le nom de votre cluster à l’invite et cliquez sur Supprimer.
    • De supprimer le cluster à l’aide de la ROSA CLI (rosa):

      1. Entrez la commande suivante pour supprimer le cluster et regarder les journaux, en remplaçant &lt;cluster_name&gt; par le nom ou l’ID de votre cluster:

        $ rosa delete cluster --cluster=<cluster_name> --watch
        Copy to Clipboard Toggle word wrap
        Important

        Il 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.

  3. Effacer le fournisseur OIDC que les opérateurs de cluster utilisent pour authentifier:

    $ rosa delete oidc-provider -c <cluster_id> --mode auto 
    1
    Copy to Clipboard Toggle word wrap
    1
    &lt;cluster_id&gt; par l’ID du cluster.
    Note

    L’option -y vous permet de répondre automatiquement oui aux invitations.

  4. En option. Effacer les rôles IAM d’opérateur spécifiques au cluster:

    Important

    Les 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 
    1
    Copy to Clipboard Toggle word wrap
    1
    &lt;cluster_id&gt; 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.
Astuce

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

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.

## Configures your AWS account and ensures everything is setup correctly
$ rosa init

## Starts the cluster creation process (~30-40minutes)
$ rosa create cluster --cluster-name=<cluster_name>

## Connect your IDP to your cluster
$ rosa create idp --cluster=<cluster_name> --interactive

## Promotes a user from your IDP to dedicated-admin level
$ rosa grant user dedicated-admin --user=<idp_user_name> --cluster=<cluster_name>

## Checks if your install is ready (look for State: Ready),
## and provides your Console URL to login to the web console.
$ rosa describe cluster --cluster=<cluster_name>
Copy to Clipboard Toggle word wrap

Legal Notice

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.

Retour au début
Red Hat logoGithubredditYoutubeTwitter

Apprendre

Essayez, achetez et vendez

Communautés

À propos de la documentation Red Hat

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

Rendre l’open source plus inclusif

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

À propos de Red Hat

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

Theme

© 2025 Red Hat