Installer ROSA avec des clusters HCP


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) qui utilisent des plans de contrôle hébergés.

Note

Guide de démarrage rapide pour ROSA Classic Si vous recherchez un guide de démarrage rapide pour ROSA Classic, consultez le guide de démarrage rapide Red Hat OpenShift sur AWS.

Le service OpenShift Red Hat sur AWS (ROSA) avec des avions de contrôle hébergés (HCP) offre une architecture plus efficace et fiable pour créer des clusters Red Hat OpenShift sur AWS (ROSA). Avec ROSA avec HCP, chaque cluster dispose d’un plan de contrôle dédié qui est isolé dans un compte de service ROSA.

Créez rapidement un ROSA avec le cluster HCP 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 le ROSA CLI (rosa).

Important

Comme il n’est pas possible de mettre à niveau ou de convertir des clusters ROSA existants en architecture de plans de contrôle hébergés, vous devez créer un nouveau cluster pour utiliser ROSA avec la fonctionnalité HCP.

Important

Le partage de VPC sur plusieurs comptes AWS n’est actuellement pas pris en charge pour ROSA avec HCP. Il ne faut pas installer un ROSA avec le cluster HCP dans des sous-réseaux partagés à partir d’un autre compte AWS. Consultez « Multiples ROSA clusters dans un seul VPC pris en charge ? » pour plus d’informations.

Note

Le ROSA avec les clusters HCP ne prend en charge que l’authentification AWS Security Token Service (STS).

Autres lectures

  • En comparaison entre ROSA et HCP et ROSA Classic, consultez la documentation relative aux modèles d’architecture comparées.
  • Consultez la documentation AWS pour obtenir des informations sur le démarrage de ROSA avec HCP en utilisant le ROSA CLI en mode automatique.
Considérations concernant le mode de création automatique

Les procédures de ce document utilisent le mode automatique dans le ROSA CLI 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.

Les prochaines étapes

  • Assurez-vous que vous avez rempli les prérequis AWS.

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. La ROSA avec HCP Prérequis

Afin de créer un ROSA avec le cluster HCP, vous devez avoir les éléments suivants:

  • Cloud privé virtuel configuré (VPC)
  • Les rôles à l’échelle du compte
  • Configuration OIDC
  • Les rôles d’opérateur

Il faut disposer d’un cloud privé virtuel (VPC) pour créer ROSA avec le cluster HCP. Il est possible d’utiliser les méthodes suivantes pour créer un VPC:

  • Créer un VPC à l’aide d’un modèle Terraform
  • Créez manuellement les ressources VPC dans la console AWS
Note

Les instructions Terraform sont à des fins de test et de démonstration. L’installation de votre propre système nécessite quelques modifications au VPC pour votre propre usage. Assurez-vous également que lorsque vous utilisez ce script Terraform, c’est dans la même région que vous avez l’intention d’installer votre cluster. Dans ces exemples, utilisez nous-Est-2.

Création d’un cloud privé virtuel à l’aide de Terraform

Le terraform est un outil qui vous permet de créer diverses ressources à l’aide d’un modèle établi. Le processus suivant utilise les options par défaut au besoin pour créer un ROSA avec le cluster HCP. Consultez les ressources supplémentaires pour plus d’informations sur l’utilisation de Terraform.

Conditions préalables

  • La version 1.4.0 ou plus récente de Terraform est installée sur votre machine.
  • « vous avez installé Git sur votre machine.

Procédure

  1. Lancez une invite shell et clonez le dépôt Terraform VPC en exécutant la commande suivante:

    $ git clone https://github.com/openshift-cs/terraform-vpc-example
    Copy to Clipboard Toggle word wrap
  2. Accédez au répertoire créé en exécutant la commande suivante:

    $ cd terraform-vpc-example
    Copy to Clipboard Toggle word wrap
  3. Lancez le fichier Terraform en exécutant la commande suivante:

    $ terraform init
    Copy to Clipboard Toggle word wrap

    Le message confirmant l’initialisation apparaît lorsque ce processus se termine.

  4. Afin de construire votre plan VPC Terraform basé sur le modèle Terraform existant, exécutez la commande plan. Il faut inclure votre région AWS. Choisissez de spécifier un nom de cluster. Après la fin du plan terraform, un fichier rosa.tfplan est ajouté au répertoire hypershift-tf. Consultez le fichier README du dépôt Terraform VPC.

    $ terraform plan -out rosa.tfplan -var region=<region>
    Copy to Clipboard Toggle word wrap
  5. Appliquez ce fichier de plan pour construire votre VPC en exécutant la commande suivante:

    $ terraform apply rosa.tfplan
    Copy to Clipboard Toggle word wrap
    1. Facultatif: Vous pouvez capturer les valeurs des ID de sous-réseau privés, publics et de pool de machines fournis par Terraform en tant que variables d’environnement à utiliser lors de la création de votre ROSA avec le cluster HCP en exécutant les commandes suivantes:

      $ export SUBNET_IDS=$(terraform output -raw cluster-subnets-string)
      Copy to Clipboard Toggle word wrap
    2. Assurez-vous que les variables ont été correctement définies avec la commande suivante:

      $ echo $SUBNET_IDS
      Copy to Clipboard Toggle word wrap

      Exemple de sortie

      $ subnet-0a6a57e0f784171aa,subnet-078e84e5b10ecf5b0
      Copy to Clipboard Toggle word wrap

Création manuelle d’un Cloud privé virtuel

Lorsque vous choisissez de créer manuellement votre Cloud privé virtuel (VPC) au lieu d’utiliser Terraform, accédez à la page VPC de la console AWS.

Le VPC doit répondre aux exigences indiquées dans le tableau suivant.

Expand
Tableau 1.2. Exigences pour votre VPC
ExigenceDétails

Le nom du VPC

Il faut avoir le nom et l’identifiant VPC spécifiques lors de la création de votre cluster.

Gamme CIDR

La gamme VPC CIDR doit correspondre à votre machine CIDR.

La zone de disponibilité

Il vous faut une zone de disponibilité pour une seule zone, et vous en avez besoin de trois pour les zones de disponibilité pour plusieurs zones.

Le sous-réseau public

Il faut avoir un sous-réseau public avec une passerelle NAT pour les clusters publics. Les clusters privés n’ont pas besoin d’un sous-réseau public.

DNS nom d’hôte et résolution

Assurez-vous que le nom d’hôte DNS et la résolution sont activés.

Étiqueter vos sous-réseaux

Avant de pouvoir utiliser votre VPC pour créer un ROSA avec le cluster HCP, vous devez marquer vos sous-réseaux VPC. Les vérifications automatisées de prévol de service vérifient que ces ressources sont étiquetées correctement avant de pouvoir utiliser ces ressources. Le tableau suivant montre comment vos ressources doivent être étiquetées comme suit:

Expand
A) RessourcesLa cléLa valeur

Le sous-réseau public

Kubernetes.io/rôle/elb

1 ou aucune valeur

Le sous-réseau privé

Kubernetes.io/role/interne-elb

1 ou aucune valeur

Note

Il faut marquer au moins un sous-réseau privé et, le cas échéant, et un sous-réseau public.

Conditions préalables

  • « vous avez créé un VPC.
  • C’est toi qui as installé l’Aws CLI.

Procédure

  1. Balisez vos ressources dans votre terminal en exécutant les commandes suivantes:

    1. Dans le cas des sous-réseaux publics, exécutez:

      $ aws ec2 create-tags --resources <public-subnet-id> --region <aws_region> --tags Key=kubernetes.io/role/elb,Value=1
      Copy to Clipboard Toggle word wrap
    2. Dans le cas des sous-réseaux privés, exécutez:

      $ aws ec2 create-tags --resources <private-subnet-id> --region <aws_region> --tags Key=kubernetes.io/role/internal-elb,Value=1
      Copy to Clipboard Toggle word wrap

La vérification

  • Assurez-vous que la balise est correctement appliquée en exécutant la commande suivante:

    $ aws ec2 describe-tags --filters "Name=resource-id,Values=<subnet_id>"
    Copy to Clipboard Toggle word wrap

    Exemple de sortie

    TAGS    Name                    <subnet-id>        subnet  <prefix>-subnet-public1-us-east-1a
    TAGS    kubernetes.io/role/elb  <subnet-id>        subnet  1
    Copy to Clipboard Toggle word wrap

Avant d’utiliser le service Red Hat OpenShift sur AWS (ROSA) CLI (rosa) pour créer Red Hat OpenShift Service sur AWS (ROSA) avec des clusters de plans de contrôle hébergés (HCP), créez les rôles et les politiques nécessaires à l’échelle du compte, y compris les politiques d’opérateur.

Note

Les ROSA avec les clusters HCP nécessitent des rôles de compte et d’opérateur avec des stratégies gérées AWS jointes. Les politiques gérées par les clients ne sont pas prises en charge. En savoir plus sur les stratégies gérées par AWS pour ROSA avec les clusters HCP, consultez les stratégies gérées AWS pour les rôles de compte ROSA.

Conditions préalables

  • Avec HCP, 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.
  • En utilisant le ROSA CLI, vous vous êtes connecté à votre compte Red Hat.

Procédure

  1. Dans le cas où ils n’existent pas dans votre compte AWS, créez les rôles STS requis à l’échelle du compte et attachez les stratégies en exécutant la commande suivante:

    $ rosa create account-roles --hosted-cp
    Copy to Clipboard Toggle word wrap
  2. Facultatif: Définir votre préfixe en tant que variable environnementale en exécutant la commande suivante:

    $ export ACCOUNT_ROLES_PREFIX=<account_role_prefix>
    Copy to Clipboard Toggle word wrap
    • Afficher la valeur de la variable en exécutant la commande suivante:

      $ echo $ACCOUNT_ROLES_PREFIX
      Copy to Clipboard Toggle word wrap

      Exemple de sortie

      ManagedOpenShift
      Copy to Clipboard Toggle word wrap

Consultez les politiques IAM gérées par AWS pour ROSA, consultez les politiques IAM gérées par AWS pour ROSA.

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

1.2.4. Créer des rôles et des politiques de l’opérateur

Lorsque vous utilisez un ROSA avec le cluster HCP, vous devez créer les rôles IAM d’opérateur requis pour Red Hat OpenShift Service sur AWS (ROSA) avec des déploiements de plans de contrôle hébergés (HCP). Les opérateurs de cluster utilisent les rôles d’opérateur pour obtenir les autorisations temporaires requises pour effectuer des opérations de cluster, telles que la gestion du stockage back-end, les informations d’identification des fournisseurs de cloud et l’accès externe à un cluster.

Conditions préalables

  • Avec HCP, vous avez complété les prérequis AWS pour ROSA.
  • Le dernier service Red Hat OpenShift sur AWS ROSA CLI (rosa) est installé et configuré sur votre hôte d’installation.
  • Les rôles AWS à l’échelle du compte ont été créés.

Procédure

  1. Définissez le nom de votre préfixe sur une variable d’environnement en utilisant la commande suivante:

    $ export OPERATOR_ROLES_PREFIX=<prefix_name>
    Copy to Clipboard Toggle word wrap
  2. Afin de créer vos rôles d’opérateur, exécutez la commande suivante:

    $ rosa create operator-roles --hosted-cp --prefix=$OPERATOR_ROLES_PREFIX --oidc-config-id=$OIDC_ID --installer-role-arn arn:aws:iam::${AWS_ACCOUNT_ID}:role/${ACCOUNT_ROLES_PREFIX}-HCP-ROSA-Installer-Role
    Copy to Clipboard Toggle word wrap

    La ventilation suivante fournit des options pour la création de rôles d’opérateur.

    $ rosa create operator-roles --hosted-cp
    	--prefix=$OPERATOR_ROLES_PREFIX 
    1
    
    	--oidc-config-id=$OIDC_ID 
    2
    
    	--installer-role-arn arn:aws:iam::${AWS_ACCOUNT_ID}:role/${ACCOUNT_ROLES_PREFIX}-HCP-ROSA-Installer-Role 
    3
    Copy to Clipboard Toggle word wrap
    1
    Il faut fournir un préfixe lors de la création de ces rôles d’opérateur. Le fait de ne pas le faire produit une erreur. Consultez les ressources supplémentaires de cette section pour obtenir des informations sur le préfixe de l’opérateur.
    2
    Cette valeur est l’identifiant de configuration OIDC que vous avez créé pour votre ROSA avec le cluster HCP.
    3
    Cette valeur est le rôle d’installateur ARN que vous avez créé lorsque vous avez créé les rôles de compte ROSA.

    Il faut inclure le paramètre --hosted-cp pour créer les rôles corrects pour ROSA avec les clusters HCP. Cette commande renvoie les informations suivantes.

    Exemple de sortie

    ? Role creation mode: auto
    ? Operator roles prefix: <pre-filled_prefix> 
    1
    
    ? OIDC Configuration ID: 23soa2bgvpek9kmes9s7os0a39i13qm4 | https://dvbwgdztaeq9o.cloudfront.net/23soa2bgvpek9kmes9s7os0a39i13qm4 
    2
    
    ? Create hosted control plane operator roles: Yes
    W: More than one Installer role found
    ? Installer role ARN: arn:aws:iam::4540112244:role/<prefix>-HCP-ROSA-Installer-Role
    ? Permissions boundary ARN (optional):
    I: Reusable OIDC Configuration detected. Validating trusted relationships to operator roles:
    I: Creating roles using 'arn:aws:iam::4540112244:user/<userName>'
    I: Created role '<prefix>-openshift-cluster-csi-drivers-ebs-cloud-credentials' with ARN 'arn:aws:iam::4540112244:role/<prefix>-openshift-cluster-csi-drivers-ebs-cloud-credentials'
    I: Created role '<prefix>-openshift-cloud-network-config-controller-cloud-credenti' with ARN 'arn:aws:iam::4540112244:role/<prefix>-openshift-cloud-network-config-controller-cloud-credenti'
    I: Created role '<prefix>-kube-system-kube-controller-manager' with ARN 'arn:aws:iam::4540112244:role/<prefix>-kube-system-kube-controller-manager'
    I: Created role '<prefix>-kube-system-capa-controller-manager' with ARN 'arn:aws:iam::4540112244:role/<prefix>-kube-system-capa-controller-manager'
    I: Created role '<prefix>-kube-system-control-plane-operator' with ARN 'arn:aws:iam::4540112244:role/<prefix>-kube-system-control-plane-operator'
    I: Created role '<prefix>-kube-system-kms-provider' with ARN 'arn:aws:iam::4540112244:role/<prefix>-kube-system-kms-provider'
    I: Created role '<prefix>-openshift-image-registry-installer-cloud-credentials' with ARN 'arn:aws:iam::4540112244:role/<prefix>-openshift-image-registry-installer-cloud-credentials'
    I: Created role '<prefix>-openshift-ingress-operator-cloud-credentials' with ARN 'arn:aws:iam::4540112244:role/<prefix>-openshift-ingress-operator-cloud-credentials'
    I: To create a cluster with these roles, run the following command:
    	rosa create cluster --sts --oidc-config-id 23soa2bgvpek9kmes9s7os0a39i13qm4 --operator-roles-prefix <prefix> --hosted-cp
    Copy to Clipboard Toggle word wrap

    1
    Ce champ est prérempli avec le préfixe que vous définissez dans la commande initiale de création.
    2
    Ce champ vous oblige à sélectionner une configuration OIDC que vous avez créée pour votre ROSA avec le cluster HCP.

    Les rôles d’opérateur sont maintenant créés et prêts à être utilisés pour créer votre ROSA avec le cluster HCP.

La vérification

  • Il est possible de répertorier les rôles d’opérateur associés à votre compte ROSA. Exécutez la commande suivante:

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

    Exemple de sortie

    I: Fetching operator roles
    ROLE PREFIX  AMOUNT IN BUNDLE
    <prefix>      8
    ? Would you like to detail a specific prefix Yes 
    1
    
    ? Operator Role Prefix: <prefix>
    ROLE NAME                                                         ROLE ARN                                                                                         VERSION  MANAGED
    <prefix>-kube-system-capa-controller-manager                       arn:aws:iam::4540112244:role/<prefix>-kube-system-capa-controller-manager                       4.13     No
    <prefix>-kube-system-control-plane-operator                        arn:aws:iam::4540112244:role/<prefix>-kube-system-control-plane-operator                        4.13     No
    <prefix>-kube-system-kms-provider                                  arn:aws:iam::4540112244:role/<prefix>-kube-system-kms-provider                                  4.13     No
    <prefix>-kube-system-kube-controller-manager                       arn:aws:iam::4540112244:role/<prefix>-kube-system-kube-controller-manager                       4.13     No
    <prefix>-openshift-cloud-network-config-controller-cloud-credenti  arn:aws:iam::4540112244:role/<prefix>-openshift-cloud-network-config-controller-cloud-credenti  4.13     No
    <prefix>-openshift-cluster-csi-drivers-ebs-cloud-credentials       arn:aws:iam::4540112244:role/<prefix>-openshift-cluster-csi-drivers-ebs-cloud-credentials       4.13     No
    <prefix>-openshift-image-registry-installer-cloud-credentials      arn:aws:iam::4540112244:role/<prefix>-openshift-image-registry-installer-cloud-credentials      4.13     No
    <prefix>-openshift-ingress-operator-cloud-credentials              arn:aws:iam::4540112244:role/<prefix>-openshift-ingress-operator-cloud-credentials              4.13     No
    Copy to Clipboard Toggle word wrap

    1
    Après l’exécution de la commande, il affiche tous les préfixes associés à votre compte AWS et note combien de rôles sont associés à ce préfixe. Lorsque vous avez besoin de voir tous ces rôles et leurs détails, entrez "Oui" sur l’invite détaillée pour avoir ces rôles listés avec des détails.

1.3. Créer un ROSA avec le cluster HCP à l’aide du CLI

Lorsque vous utilisez le Red Hat OpenShift Service sur AWS (ROSA) CLI, rosa, pour créer un cluster, vous pouvez sélectionner les options par défaut pour créer le cluster rapidement.

Conditions préalables

  • Avec HCP, 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.
  • C’est vous qui avez créé une configuration OIDC.
  • Le rôle de service AWS Elastic Load Balancing (ELB) existe dans votre compte AWS.

Procédure

  1. Faites appel à l’une des commandes suivantes pour créer votre ROSA avec le cluster HCP:

    Note

    Lors de la création d’un ROSA avec le cluster HCP, la machine par défaut Classless Inter-Domain Routing (CIDR) est 10.0.0.0/16. Dans le cas où cela ne correspond pas à la plage CIDR pour vos sous-réseaux VPC, ajoutez --machine-cidr &lt;address_block&gt; aux commandes suivantes. Afin d’en savoir plus sur les gammes CIDR par défaut pour Red Hat OpenShift Service sur AWS, consultez les définitions de la gamme CIDR.

    • Lorsque vous n’avez pas défini de variables environnementales, exécutez la commande suivante:

      $ rosa create cluster --cluster-name=<cluster_name> \ 
      1
      
          --mode=auto --hosted-cp [--private] \ 
      2
      
          --operator-roles-prefix <operator-role-prefix> \ 
      3
      
          --external-id <external-id> \ 
      4
      
          --oidc-config-id <id-of-oidc-configuration> \
          --subnet-ids=<public-subnet-id>,<private-subnet-id>
      Copy to Clipboard Toggle word wrap

      &Lt;.&gt; spécifiez le nom de votre cluster. 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 provisionné 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. &lt;.&gt; Option: L’argument --privé est utilisé pour créer des ROSA privés avec des clusters HCP. Lorsque vous utilisez cet argument, assurez-vous que vous n’utilisez que votre identifiant de sous-réseau privé pour --subnet-ids. &lt;.&gt; Par défaut, 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.

      &Lt;.&gt; optionnel : Un identifiant unique qui pourrait être requis lorsque vous assumez un rôle dans un autre compte.

    • Lorsque vous définissez les variables environnementales, créez un cluster avec un seul pool de machines initial, à l’aide d’une API publique ou privée, et d’un Ingress disponible publiquement ou privé en exécutant la commande suivante:

      $ rosa create cluster --private --cluster-name=<cluster_name> \
          --mode=auto --hosted-cp --operator-roles-prefix=$OPERATOR_ROLES_PREFIX \
          --oidc-config-id=$OIDC_ID --subnet-ids=$SUBNET_IDS
      Copy to Clipboard Toggle word wrap
    • Lorsque vous définissez les variables environnementales, créez un cluster avec un seul pool de machines initial, une API accessible au public et un Ingress disponible au public en exécutant la commande suivante:

      $ rosa create cluster --cluster-name=<cluster_name> --mode=auto \
          --hosted-cp --operator-roles-prefix=$OPERATOR_ROLES_PREFIX \
          --oidc-config-id=$OIDC_ID --subnet-ids=$SUBNET_IDS
      Copy to Clipboard Toggle word wrap
  2. Consultez l’état de votre cluster en exécutant la commande suivante:

    $ rosa describe cluster --cluster=<cluster_name>
    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:

    • 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 plus de 10 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.

  3. Faites le suivi de l’avancement de la création de clusters en regardant le Red Hat OpenShift Service sur les journaux des programmes d’installation AWS. Afin de vérifier les journaux, exécutez la commande suivante:

    $ rosa logs install --cluster=<cluster_name> --watch \ <.>
    Copy to Clipboard Toggle word wrap

    &Lt;.&gt; optionnel: Pour regarder les nouveaux messages de journal au fur et à mesure que l’installation progresse, utilisez l’argument --watch.

1.4. Les prochaines étapes

Créez rapidement un cluster Red Hat OpenShift Service sur AWS (ROSA) 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 ROSA avec le cluster HCP 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

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

2.1.2. Aperçu des spécifications du cluster par défaut

Expand
Tableau 2.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)
  • 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
  • Le cryptage des clés AWS Key Management Service (KMS) n’est pas activé par défaut

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 avec une configuration OIDC gérée.

2.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
2.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.3"
          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 {
      # Extract availability zone names for the specified region, limit it to 3 if multi az or 1 if single
      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 {
      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-hcp" {
      source                 = "terraform-redhat/rosa-hcp/rhcs"
      version                = "1.6.3"
      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_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
      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 si nécessaire.

  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 "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.multi_az ? var.private_subnet_cidrs : [var.private_subnet_cidrs[0]]
      public_subnets  = var.multi_az ? var.public_subnet_cidrs : [var.public_subnet_cidrs[0]]
    
      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.

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

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

Créez un Red Hat OpenShift Service sur AWS (ROSA) avec un cluster de plans de contrôle hébergés (HCP) à l’aide d’une clé AWS Key Management Service (KMS) personnalisée.

3.1. La ROSA avec HCP Prérequis

Afin de créer un ROSA avec le cluster HCP, vous devez avoir les éléments suivants:

  • Cloud privé virtuel configuré (VPC)
  • Les rôles à l’échelle du compte
  • Configuration OIDC
  • Les rôles d’opérateur

Il faut disposer d’un cloud privé virtuel (VPC) pour créer ROSA avec le cluster HCP. Il est possible d’utiliser les méthodes suivantes pour créer un VPC:

  • Créer un VPC à l’aide d’un modèle Terraform
  • Créez manuellement les ressources VPC dans la console AWS
Note

Les instructions Terraform sont à des fins de test et de démonstration. L’installation de votre propre système nécessite quelques modifications au VPC pour votre propre usage. Assurez-vous également que lorsque vous utilisez ce script Terraform, c’est dans la même région que vous avez l’intention d’installer votre cluster. Dans ces exemples, utilisez nous-Est-2.

Important

Le partage de VPC sur plusieurs comptes AWS n’est actuellement pas pris en charge pour ROSA avec HCP. Il ne faut pas installer un ROSA avec le cluster HCP dans des sous-réseaux partagés à partir d’un autre compte AWS. Consultez « Multiples ROSA clusters dans un seul VPC pris en charge ? » pour plus d’informations.

Création d’un cloud privé virtuel à l’aide de Terraform

Le terraform est un outil qui vous permet de créer diverses ressources à l’aide d’un modèle établi. Le processus suivant utilise les options par défaut au besoin pour créer un ROSA avec le cluster HCP. Consultez les ressources supplémentaires pour plus d’informations sur l’utilisation de Terraform.

Conditions préalables

  • La version 1.4.0 ou plus récente de Terraform est installée sur votre machine.
  • « vous avez installé Git sur votre machine.

Procédure

  1. Lancez une invite shell et clonez le dépôt Terraform VPC en exécutant la commande suivante:

    $ git clone https://github.com/openshift-cs/terraform-vpc-example
    Copy to Clipboard Toggle word wrap
  2. Accédez au répertoire créé en exécutant la commande suivante:

    $ cd terraform-vpc-example
    Copy to Clipboard Toggle word wrap
  3. Lancez le fichier Terraform en exécutant la commande suivante:

    $ terraform init
    Copy to Clipboard Toggle word wrap

    Le message confirmant l’initialisation apparaît lorsque ce processus se termine.

  4. Afin de construire votre plan VPC Terraform basé sur le modèle Terraform existant, exécutez la commande plan. Il faut inclure votre région AWS. Choisissez de spécifier un nom de cluster. Après la fin du plan terraform, un fichier rosa.tfplan est ajouté au répertoire hypershift-tf. Consultez le fichier README du dépôt Terraform VPC.

    $ terraform plan -out rosa.tfplan -var region=<region>
    Copy to Clipboard Toggle word wrap
  5. Appliquez ce fichier de plan pour construire votre VPC en exécutant la commande suivante:

    $ terraform apply rosa.tfplan
    Copy to Clipboard Toggle word wrap
    1. Facultatif: Vous pouvez capturer les valeurs des ID de sous-réseau privés, publics et de pool de machines fournis par Terraform en tant que variables d’environnement à utiliser lors de la création de votre ROSA avec le cluster HCP en exécutant les commandes suivantes:

      $ export SUBNET_IDS=$(terraform output -raw cluster-subnets-string)
      Copy to Clipboard Toggle word wrap
    2. Assurez-vous que les variables ont été correctement définies avec la commande suivante:

      $ echo $SUBNET_IDS
      Copy to Clipboard Toggle word wrap

      Exemple de sortie

      $ subnet-0a6a57e0f784171aa,subnet-078e84e5b10ecf5b0
      Copy to Clipboard Toggle word wrap

Création manuelle d’un Cloud privé virtuel

Lorsque vous choisissez de créer manuellement votre Cloud privé virtuel (VPC) au lieu d’utiliser Terraform, accédez à la page VPC de la console AWS.

Le VPC doit répondre aux exigences indiquées dans le tableau suivant.

Expand
Tableau 3.1. Exigences pour votre VPC
ExigenceDétails

Le nom du VPC

Il faut avoir le nom et l’identifiant VPC spécifiques lors de la création de votre cluster.

Gamme CIDR

La gamme VPC CIDR doit correspondre à votre machine CIDR.

La zone de disponibilité

Il vous faut une zone de disponibilité pour une seule zone, et vous en avez besoin de trois pour les zones de disponibilité pour plusieurs zones.

Le sous-réseau public

Il faut avoir un sous-réseau public avec une passerelle NAT pour les clusters publics. Les clusters privés n’ont pas besoin d’un sous-réseau public.

DNS nom d’hôte et résolution

Assurez-vous que le nom d’hôte DNS et la résolution sont activés.

Avant d’utiliser le service Red Hat OpenShift sur AWS (ROSA) CLI (rosa) pour créer Red Hat OpenShift Service sur AWS (ROSA) avec des clusters de plans de contrôle hébergés (HCP), créez les rôles et les politiques nécessaires à l’échelle du compte, y compris les politiques d’opérateur.

Note

Les ROSA avec les clusters HCP nécessitent des rôles de compte et d’opérateur avec des stratégies gérées AWS jointes. Les politiques gérées par les clients ne sont pas prises en charge. En savoir plus sur les stratégies gérées par AWS pour ROSA avec les clusters HCP, consultez les stratégies gérées AWS pour les rôles de compte ROSA.

Conditions préalables

  • Avec HCP, 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.
  • En utilisant le ROSA CLI, vous vous êtes connecté à votre compte Red Hat.

Procédure

  1. Dans le cas où ils n’existent pas dans votre compte AWS, créez les rôles STS requis à l’échelle du compte et attachez les stratégies en exécutant la commande suivante:

    $ rosa create account-roles --hosted-cp
    Copy to Clipboard Toggle word wrap
  2. Facultatif: Définir votre préfixe en tant que variable environnementale en exécutant la commande suivante:

    $ export ACCOUNT_ROLES_PREFIX=<account_role_prefix>
    Copy to Clipboard Toggle word wrap
    • Afficher la valeur de la variable en exécutant la commande suivante:

      $ echo $ACCOUNT_ROLES_PREFIX
      Copy to Clipboard Toggle word wrap

      Exemple de sortie

      ManagedOpenShift
      Copy to Clipboard Toggle word wrap

Consultez les politiques IAM gérées par AWS pour ROSA, consultez les politiques IAM gérées par AWS pour ROSA.

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

3.1.4. Créer des rôles et des politiques de l’opérateur

Lorsque vous utilisez un ROSA avec le cluster HCP, vous devez créer les rôles IAM d’opérateur requis pour Red Hat OpenShift Service sur AWS (ROSA) avec des déploiements de plans de contrôle hébergés (HCP). Les opérateurs de cluster utilisent les rôles d’opérateur pour obtenir les autorisations temporaires requises pour effectuer des opérations de cluster, telles que la gestion du stockage back-end, les informations d’identification des fournisseurs de cloud et l’accès externe à un cluster.

Conditions préalables

  • Avec HCP, vous avez complété les prérequis AWS pour ROSA.
  • Le dernier service Red Hat OpenShift sur AWS ROSA CLI (rosa) est installé et configuré sur votre hôte d’installation.
  • Les rôles AWS à l’échelle du compte ont été créés.

Procédure

  1. Définissez le nom de votre préfixe sur une variable d’environnement en utilisant la commande suivante:

    $ export OPERATOR_ROLES_PREFIX=<prefix_name>
    Copy to Clipboard Toggle word wrap
  2. Afin de créer vos rôles d’opérateur, exécutez la commande suivante:

    $ rosa create operator-roles --hosted-cp --prefix=$OPERATOR_ROLES_PREFIX --oidc-config-id=$OIDC_ID --installer-role-arn arn:aws:iam::${AWS_ACCOUNT_ID}:role/${ACCOUNT_ROLES_PREFIX}-HCP-ROSA-Installer-Role
    Copy to Clipboard Toggle word wrap

    La ventilation suivante fournit des options pour la création de rôles d’opérateur.

    $ rosa create operator-roles --hosted-cp
    	--prefix=$OPERATOR_ROLES_PREFIX 
    1
    
    	--oidc-config-id=$OIDC_ID 
    2
    
    	--installer-role-arn arn:aws:iam::${AWS_ACCOUNT_ID}:role/${ACCOUNT_ROLES_PREFIX}-HCP-ROSA-Installer-Role 
    3
    Copy to Clipboard Toggle word wrap
    1
    Il faut fournir un préfixe lors de la création de ces rôles d’opérateur. Le fait de ne pas le faire produit une erreur. Consultez les ressources supplémentaires de cette section pour obtenir des informations sur le préfixe de l’opérateur.
    2
    Cette valeur est l’identifiant de configuration OIDC que vous avez créé pour votre ROSA avec le cluster HCP.
    3
    Cette valeur est le rôle d’installateur ARN que vous avez créé lorsque vous avez créé les rôles de compte ROSA.

    Il faut inclure le paramètre --hosted-cp pour créer les rôles corrects pour ROSA avec les clusters HCP. Cette commande renvoie les informations suivantes.

    Exemple de sortie

    ? Role creation mode: auto
    ? Operator roles prefix: <pre-filled_prefix> 
    1
    
    ? OIDC Configuration ID: 23soa2bgvpek9kmes9s7os0a39i13qm4 | https://dvbwgdztaeq9o.cloudfront.net/23soa2bgvpek9kmes9s7os0a39i13qm4 
    2
    
    ? Create hosted control plane operator roles: Yes
    W: More than one Installer role found
    ? Installer role ARN: arn:aws:iam::4540112244:role/<prefix>-HCP-ROSA-Installer-Role
    ? Permissions boundary ARN (optional):
    I: Reusable OIDC Configuration detected. Validating trusted relationships to operator roles:
    I: Creating roles using 'arn:aws:iam::4540112244:user/<userName>'
    I: Created role '<prefix>-openshift-cluster-csi-drivers-ebs-cloud-credentials' with ARN 'arn:aws:iam::4540112244:role/<prefix>-openshift-cluster-csi-drivers-ebs-cloud-credentials'
    I: Created role '<prefix>-openshift-cloud-network-config-controller-cloud-credenti' with ARN 'arn:aws:iam::4540112244:role/<prefix>-openshift-cloud-network-config-controller-cloud-credenti'
    I: Created role '<prefix>-kube-system-kube-controller-manager' with ARN 'arn:aws:iam::4540112244:role/<prefix>-kube-system-kube-controller-manager'
    I: Created role '<prefix>-kube-system-capa-controller-manager' with ARN 'arn:aws:iam::4540112244:role/<prefix>-kube-system-capa-controller-manager'
    I: Created role '<prefix>-kube-system-control-plane-operator' with ARN 'arn:aws:iam::4540112244:role/<prefix>-kube-system-control-plane-operator'
    I: Created role '<prefix>-kube-system-kms-provider' with ARN 'arn:aws:iam::4540112244:role/<prefix>-kube-system-kms-provider'
    I: Created role '<prefix>-openshift-image-registry-installer-cloud-credentials' with ARN 'arn:aws:iam::4540112244:role/<prefix>-openshift-image-registry-installer-cloud-credentials'
    I: Created role '<prefix>-openshift-ingress-operator-cloud-credentials' with ARN 'arn:aws:iam::4540112244:role/<prefix>-openshift-ingress-operator-cloud-credentials'
    I: To create a cluster with these roles, run the following command:
    	rosa create cluster --sts --oidc-config-id 23soa2bgvpek9kmes9s7os0a39i13qm4 --operator-roles-prefix <prefix> --hosted-cp
    Copy to Clipboard Toggle word wrap

    1
    Ce champ est prérempli avec le préfixe que vous définissez dans la commande initiale de création.
    2
    Ce champ vous oblige à sélectionner une configuration OIDC que vous avez créée pour votre ROSA avec le cluster HCP.

    Les rôles d’opérateur sont maintenant créés et prêts à être utilisés pour créer votre ROSA avec le cluster HCP.

La vérification

  • Il est possible de répertorier les rôles d’opérateur associés à votre compte ROSA. Exécutez la commande suivante:

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

    Exemple de sortie

    I: Fetching operator roles
    ROLE PREFIX  AMOUNT IN BUNDLE
    <prefix>      8
    ? Would you like to detail a specific prefix Yes 
    1
    
    ? Operator Role Prefix: <prefix>
    ROLE NAME                                                         ROLE ARN                                                                                         VERSION  MANAGED
    <prefix>-kube-system-capa-controller-manager                       arn:aws:iam::4540112244:role/<prefix>-kube-system-capa-controller-manager                       4.13     No
    <prefix>-kube-system-control-plane-operator                        arn:aws:iam::4540112244:role/<prefix>-kube-system-control-plane-operator                        4.13     No
    <prefix>-kube-system-kms-provider                                  arn:aws:iam::4540112244:role/<prefix>-kube-system-kms-provider                                  4.13     No
    <prefix>-kube-system-kube-controller-manager                       arn:aws:iam::4540112244:role/<prefix>-kube-system-kube-controller-manager                       4.13     No
    <prefix>-openshift-cloud-network-config-controller-cloud-credenti  arn:aws:iam::4540112244:role/<prefix>-openshift-cloud-network-config-controller-cloud-credenti  4.13     No
    <prefix>-openshift-cluster-csi-drivers-ebs-cloud-credentials       arn:aws:iam::4540112244:role/<prefix>-openshift-cluster-csi-drivers-ebs-cloud-credentials       4.13     No
    <prefix>-openshift-image-registry-installer-cloud-credentials      arn:aws:iam::4540112244:role/<prefix>-openshift-image-registry-installer-cloud-credentials      4.13     No
    <prefix>-openshift-ingress-operator-cloud-credentials              arn:aws:iam::4540112244:role/<prefix>-openshift-ingress-operator-cloud-credentials              4.13     No
    Copy to Clipboard Toggle word wrap

    1
    Après l’exécution de la commande, il affiche tous les préfixes associés à votre compte AWS et note combien de rôles sont associés à ce préfixe. Lorsque vous avez besoin de voir tous ces rôles et leurs détails, entrez "Oui" sur l’invite détaillée pour avoir ces rôles listés avec des détails.

Il est possible de créer un cluster Red Hat OpenShift Service sur AWS (ROSA) avec une clé KMS fournie par le client qui est utilisée pour chiffrer soit les volumes racine des nœuds, la base de données etcd, soit les deux. L’ARN de clé KMS différent peut être fourni pour chaque option.

Note

Le ROSA avec HCP ne configure pas automatiquement la classe de stockage par défaut pour chiffrer les volumes persistants avec la clé KMS fournie par le client. C’est quelque chose qui peut être configuré dans le cluster après l’installation.

Procédure

  1. Créez une clé KMS personnalisée gérée par le client AWS en exécutant la commande suivante:

    $ KMS_ARN=$(aws kms create-key --region $AWS_REGION --description 'Custom ROSA Encryption Key' --tags TagKey=red-hat,TagValue=true --query KeyMetadata.Arn --output text)
    Copy to Clipboard Toggle word wrap

    Cette commande enregistre la sortie Amazon Resource Name (ARN) de cette clé personnalisée pour d’autres étapes.

    Note

    Les clients doivent fournir les --tags TagKey=red-hat,TagValue=vrai argument qui est requis pour une clé KMS client.

  2. La clé KMS a été créée en exécutant la commande suivante:

    $ echo $KMS_ARN
    Copy to Clipboard Toggle word wrap
  3. Définissez votre identifiant de compte AWS sur une variable d’environnement.

    $ AWS_ACCOUNT_ID=<aws_account_id>
    Copy to Clipboard Toggle word wrap
  4. Ajoutez l’ARN pour le rôle d’installateur à l’échelle du compte et les rôles d’opérateur que vous avez créés 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-HCP-ROSA-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": "Installer Permissions",
                  "Effect": "Allow",
                  "Principal": {
                      "AWS": "arn:aws:iam::${AWS_ACCOUNT_ID}:role/ManagedOpenShift-HCP-ROSA-Installer-Role"
                  },
                  "Action": [
                      "kms:CreateGrant",
                      "kms:DescribeKey",
                      "kms:GenerateDataKeyWithoutPlaintext"
                  ],
                  "Resource": "*"
              },
              {
                  "Sid": "ROSA KubeControllerManager Permissions",
                  "Effect": "Allow",
                  "Principal": {
                      "AWS": "arn:aws:iam::${AWS_ACCOUNT_ID}:role/<operator_role_prefix>-kube-system-kube-controller-manager"
    
                  },
                  "Action": "kms:DescribeKey",
                  "Resource": "*"
              },
              {
                  "Sid": "ROSA KMS Provider Permissions",
                  "Effect": "Allow",
                  "Principal": {
                      "AWS": "arn:aws:iam::${AWS_ACCOUNT_ID}:role/<operator_role_prefix>-kube-system-kms-provider"
                  },
                  "Action": [
                      "kms:Encrypt",
                      "kms:Decrypt",
                      "kms:DescribeKey"
                  ],
                  "Resource": "*"
              },
              {
                  "Sid": "ROSA NodeManager Permissions",
                  "Effect": "Allow",
                  "Principal": {
                      "AWS": "arn:aws:iam::${AWS_ACCOUNT_ID}:role/<operator_role_prefix>-kube-system-capa-controller-manager"
                  },
                  "Action": [
                      "kms:DescribeKey",
                      "kms:GenerateDataKeyWithoutPlaintext",
                      "kms:CreateGrant"
                  ],
                  "Resource": "*"
              }
          ]
      }
    Copy to Clipboard Toggle word wrap
  5. Confirmez les détails du fichier de stratégie créé en exécutant la commande suivante:

    $ cat rosa-key-policy.json
    Copy to Clipboard Toggle word wrap
  6. Appliquez la stratégie de clé nouvellement générée à la clé KMS personnalisée en exécutant la commande suivante:

    $ aws kms put-key-policy --key-id $KMS_ARN \
    --policy file://rosa-key-policy.json \
    --policy-name default
    Copy to Clipboard Toggle word wrap
  7. Créez le cluster en exécutant la commande suivante:

    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.

    $ rosa create cluster --cluster-name <cluster_name> \
    --subnet-ids <private_subnet_id>,<public_subnet_id> \
    --sts \
    --mode auto \
    --machine-cidr 10.0.0.0/16 \
    --compute-machine-type m5.xlarge \
    --hosted-cp \
    --region <aws_region> \
    --oidc-config-id $OIDC_ID \
    --kms-key-arn $KMS_ARN \ 
    1
    
    --etcd-encryption-kms-arn $KMS_ARN \ 
    2
    
    --operator-roles-prefix $OPERATOR_ROLES_PREFIX
    Copy to Clipboard Toggle word wrap
    1
    Cette clé KMS ARN est utilisée pour chiffrer tous les volumes de racine des nœuds de travail. Il n’est pas nécessaire si seulement un cryptage de base de données etcd est nécessaire.
    2
    Cette clé KMS ARN est utilisée pour chiffrer la base de données etcd. La base de données etcd est toujours cryptée par défaut avec un bloc de chiffrement AES, mais peut être cryptée à la place avec une clé KMS. Il n’est pas nécessaire si seul le cryptage du volume racine du nœud est nécessaire.

La vérification

Il est possible de vérifier que votre clé KMS fonctionne à l’aide d’OpenShift Cluster Manager.

  1. Accédez à OpenShift Cluster Manager et sélectionnez Instances.
  2. Choisissez votre instance.
  3. Cliquez sur l’onglet Stockage.
  4. Copiez l’ID de clé KMS.
  5. Cherchez et sélectionnez Key Management Service.
  6. Entrez votre identifiant de clé KMS copié dans le champ Filtre.

Chapitre 4. Création d’un cluster privé sur ROSA avec HCP

Avec les charges de travail des avions de contrôle hébergés (HCP) pour Red Hat OpenShift Service sur AWS (ROSA) qui ne nécessitent pas d’accès public à Internet, vous pouvez créer un cluster privé.

Il est possible de créer un cluster privé avec plusieurs zones de disponibilité (Multi-AZ) sur ROSA avec HCP à l’aide de l’interface de ligne de commande ROSA (CLI), rosa.

Conditions préalables

  • Des quotas de service AWS sont disponibles.
  • Le service ROSA est activé dans la console AWS.
  • La dernière version de la ROSA CLI est installée et configurée sur votre hôte d’installation.

Procédure

La création d’un cluster avec des plans de contrôle hébergés peut prendre environ 10 minutes.

  1. Créez un VPC avec au moins un sous-réseau privé. Assurez-vous que le routage interdomaine sans classe (CIDR) de votre machine correspond au CIDR de votre cloud privé virtuel. Consultez Exigences pour l’utilisation de votre propre VPC et VPC Validation.

    Important

    Lorsque vous utilisez un pare-feu, vous devez le configurer afin que ROSA puisse accéder aux sites requis pour fonctionner.

    Consultez la section « Prérequis de pare-feu AWS PrivateLink » pour plus d’informations.

  2. Créez les rôles IAM à l’échelle du compte en exécutant la commande suivante:

    $ rosa create account-roles --hosted-cp
    Copy to Clipboard Toggle word wrap
  3. Créez la configuration OIDC en exécutant la commande suivante:

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

    Enregistrez l’identifiant de configuration OIDC car vous en avez besoin pour créer les rôles d’opérateur.

    Exemple de sortie

    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 28s4avcdt2l318r1jbk3ifmimkurk384
    If you are going to create a Hosted Control Plane cluster please include '--hosted-cp'
    I: Creating OIDC provider using 'arn:aws:iam::46545644412:user/user'
    I: Created OIDC provider with ARN 'arn:aws:iam::46545644412:oidc-provider/oidc.op1.openshiftapps.com/28s4avcdt2l318r1jbk3ifmimkurk384'
    Copy to Clipboard Toggle word wrap

  4. Créez les rôles de l’opérateur en exécutant la commande suivante:

    $ rosa create operator-roles --hosted-cp --prefix <operator_roles_prefix> --oidc-config-id <oidc_config_id> --installer-role-arn arn:aws:iam::$<account_roles_prefix>:role/$<account_roles_prefix>-HCP-ROSA-Installer-Role
    Copy to Clipboard Toggle word wrap
  5. Créez un ROSA privé avec le cluster HCP en exécutant la commande suivante:

    $ rosa create cluster --private --cluster-name=<cluster-name> --sts --mode=auto --hosted-cp --operator-roles-prefix <operator_role_prefix> --oidc-config-id <oidc_config_id> [--machine-cidr=<VPC CIDR>/16] --subnet-ids=<private-subnet-id1>[,<private-subnet-id2>,<private-subnet-id3>]
    Copy to Clipboard Toggle word wrap
  6. Entrez la commande suivante pour vérifier l’état de votre cluster. Au cours de la création de clusters, le champ État de la production passera de l’attente à l’installation, et enfin, à la préparation.

    $ rosa describe cluster --cluster=<cluster_name>
    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 au bout de 10 minutes, consultez la documentation "Troubleshooting Red Hat OpenShift Service sur les installations AWS" dans la section Ressources supplémentaires.

  7. Entrez la commande suivante pour suivre les journaux d’installation OpenShift pour suivre la progression de votre cluster:

    $ rosa logs install --cluster=<cluster_name> --watch
    Copy to Clipboard Toggle word wrap

Avec ROSA avec des clusters HCP, le point de terminaison AWS PrivateLink exposé dans le VPC du client dispose d’un groupe de sécurité qui limite l’accès aux demandes provenant de la gamme Machine CIDR du cluster. Afin d’accorder l’accès à l’API du cluster à toute entité en dehors du VPC, par le biais du peering VPC, des passerelles de transit ou d’une autre connectivité réseau, vous devez créer et joindre un autre groupe de sécurité au point de terminaison PrivateLink pour accorder l’accès nécessaire.

Important

L’ajout de groupes de sécurité AWS supplémentaires au point de terminaison AWS PrivateLink n’est pris en charge que sur ROSA avec la version 4.17.2 et ultérieure de HCP.

Conditions préalables

  • Le réseau d’entreprise ou autre VPC dispose d’une connectivité.
  • Il vous est permis de créer et d’attacher des groupes de sécurité au sein du VPC.

Procédure

  1. Définissez le nom de votre cluster comme variable environnementale en exécutant la commande suivante:

    $ export CLUSTER_NAME=<cluster_name>
    Copy to Clipboard Toggle word wrap

    Il est possible de vérifier que la variable a été définie en exécutant la commande suivante:

    $ echo $CLUSTER_NAME
    Copy to Clipboard Toggle word wrap

    Exemple de sortie

    hcp-private
    Copy to Clipboard Toggle word wrap

  2. Cherchez l’ID de point de terminaison VPC (VPCE) et l’ID VPC en exécutant la commande suivante:

    $ read -r VPCE_ID VPC_ID <<< $(aws ec2 describe-vpc-endpoints --filters "Name=tag:api.openshift.com/id,Values=$(rosa describe cluster -c ${CLUSTER_NAME} -o yaml | grep '^id: ' | cut -d' ' -f2)" --query 'VpcEndpoints[].[VpcEndpointId,VpcId]' --output text)
    Copy to Clipboard Toggle word wrap
    Avertissement

    La modification ou la suppression du groupe de sécurité AWS PrivateLink par défaut n’est pas prise en charge et pourrait entraîner un comportement inattendu.

  3. Créez un groupe de sécurité supplémentaire en exécutant la commande suivante:

    $ export SG_ID=$(aws ec2 create-security-group --description "Granting API access to ${CLUSTER_NAME} from outside of VPC" --group-name "${CLUSTER_NAME}-api-sg" --vpc-id $VPC_ID --output text)
    Copy to Clipboard Toggle word wrap
  4. Ajoutez une règle entrante (ingress) au groupe de sécurité en exécutant la commande suivante:

    $ aws ec2 authorize-security-group-ingress --group-id $SG_ID --ip-permissions FromPort=443,ToPort=443,IpProtocol=tcp,IpRanges=[{CidrIp=<cidr-to-allow>}] <.>
    Copy to Clipboard Toggle word wrap

    &Lt;.&gt; spécifiez le bloc CIDR à partir duquel vous souhaitez autoriser l’accès.

  5. Ajoutez le nouveau groupe de sécurité au VPCE en exécutant la commande suivante:

    $ aws ec2 modify-vpc-endpoint --vpc-endpoint-id $VPCE_ID --add-security-group-ids $SG_ID
    Copy to Clipboard Toggle word wrap

Désormais, vous pouvez accéder à l’API de votre ROSA avec le cluster privé HCP à partir du bloc CIDR spécifié.

4.3. Autres principes sur votre ROSA avec le cluster HCP

Les rôles AWS Identity and Access Management (IAM) peuvent être autorisés en tant que directeurs supplémentaires pour vous connecter au point de terminaison privé du serveur API de votre cluster.

Il est possible d’accéder à votre ROSA avec le point de terminaison API Server du cluster HCP à partir de l’Internet public ou du point de terminaison de l’interface créé dans les sous-réseaux privés VPC. Par défaut, vous pouvez accéder en privé à votre ROSA avec HCP API Server en utilisant le rôle -kube-system-kube-controller-manager Operator. Afin de pouvoir accéder directement à ROSA avec un serveur d’API HCP à partir d’un autre compte sans utiliser le compte principal où le cluster est installé, vous devez inclure les rôles intercomptes IAM en tant que directeurs supplémentaires. Cette fonctionnalité vous permet de simplifier l’architecture de votre réseau et de réduire les coûts de transfert de données en évitant le peering ou en attachant des VPC multicomptes au VPC de cluster.

Dans ce diagramme, le cluster de création de compte est désigné comme Compte A. Ce compte désigne qu’un autre compte, le compte B, devrait avoir accès au serveur API.

Note

Après avoir configuré d’autres principes autorisés, vous devez créer le point de terminaison VPC de l’interface à partir de l’endroit où vous souhaitez accéder au compte croisé ROSA avec le serveur d’API HCP. Ensuite, créez une zone hébergée privée dans Route53 pour acheminer les appels effectués pour croiser le compte ROSA avec le serveur d’API HCP pour passer par le point de terminaison VPC créé.

Employez l’argument --supplément-autorisé-principaux pour permettre l’accès par d’autres rôles.

Procédure

  1. Ajoutez l’argument --additionnel-autorisé-principals à la commande rosa create cluster, similaire à ce qui suit:

    $ rosa create cluster [...] --additional-allowed-principals <arn_string>
    Copy to Clipboard Toggle word wrap

    Il est possible d’utiliser arn:aws:iam::account_id:role/role_name pour approuver un rôle spécifique.

  2. Lorsque la commande de création de cluster s’exécute, vous recevez un résumé de votre cluster avec les principaux --additionnels-autorisés spécifiés:

    Exemple de sortie

    Name:                       mycluster
    Domain Prefix:              mycluster
    Display Name:               mycluster
    ID:                         <cluster-id>
    External ID:                <cluster-id>
    Control Plane:              ROSA Service Hosted
    OpenShift Version:          4.15.17
    Channel Group:              stable
    DNS:                        Not ready
    AWS Account:                <aws_id>
    AWS Billing Account:        <aws_id>
    API URL:
    Console URL:
    Region:                     us-east-2
    Availability:
     - Control Plane:           MultiAZ
     - Data Plane:              SingleAZ
    
    Nodes:
     - Compute (desired):       2
     - Compute (current):       0
    Network:
     - Type:                    OVNKubernetes
     - Service CIDR:            172.30.0.0/16
     - Machine CIDR:            10.0.0.0/16
     - Pod CIDR:                10.128.0.0/14
     - Host Prefix:             /23
     - Subnets:                 subnet-453e99d40, subnet-666847ce827
    EC2 Metadata Http Tokens:   optional
    Role (STS) ARN:             arn:aws:iam::<aws_id>:role/mycluster-HCP-ROSA-Installer-Role
    Support Role ARN:           arn:aws:iam::<aws_id>:role/mycluster-HCP-ROSA-Support-Role
    Instance IAM Roles:
     - Worker:                  arn:aws:iam::<aws_id>:role/mycluster-HCP-ROSA-Worker-Role
    Operator IAM Roles:
     - arn:aws:iam::<aws_id>:role/mycluster-kube-system-control-plane-operator
     - arn:aws:iam::<aws_id>:role/mycluster-openshift-cloud-network-config-controller-cloud-creden
     - arn:aws:iam::<aws_id>:role/mycluster-openshift-image-registry-installer-cloud-credentials
     - arn:aws:iam::<aws_id>:role/mycluster-openshift-ingress-operator-cloud-credentials
     - arn:aws:iam::<aws_id>:role/mycluster-openshift-cluster-csi-drivers-ebs-cloud-credentials
     - arn:aws:iam::<aws_id>:role/mycluster-kube-system-kms-provider
     - arn:aws:iam::<aws_id>:role/mycluster-kube-system-kube-controller-manager
     - arn:aws:iam::<aws_id>:role/mycluster-kube-system-capa-controller-manager
    Managed Policies:           Yes
    State:                      waiting (Waiting for user action)
    Private:                    No
    Delete Protection:          Disabled
    Created:                    Jun 25 2024 13:36:37 UTC
    User Workload Monitoring:   Enabled
    Details Page:               https://console.redhat.com/openshift/details/s/Bvbok4O79q1Vg8
    OIDC Endpoint URL:          https://oidc.op1.openshiftapps.com/vhufi5lap6vbl3jlq20e (Managed)
    Audit Log Forwarding:       Disabled
    External Authentication:    Disabled
    Additional Principals:      arn:aws:iam::<aws_id>:role/additional-user-role
    Copy to Clipboard Toggle word wrap

Il est possible d’ajouter des principes supplémentaires à votre cluster en utilisant l’interface de ligne de commande (CLI).

Procédure

  • Exécutez la commande suivante pour modifier votre cluster et ajouter un principal supplémentaire qui peut accéder au point de terminaison de ce cluster:

    $ rosa edit cluster -c <cluster_name> --additional-allowed-principals <arn_string>
    Copy to Clipboard Toggle word wrap

    Il est possible d’utiliser arn:aws:iam::account_id:role/role_name pour approuver un rôle spécifique.

4.4. Les prochaines étapes

Configuration des fournisseurs d’identité

La création d’un service Red Hat OpenShift sur le cluster AWS avec verrouillage egress fournit un moyen d’améliorer la stabilité et la sécurité de votre cluster en permettant à votre cluster d’utiliser le registre d’images dans la région locale si le cluster ne peut pas accéder à Internet. Le cluster va essayer de tirer les images de Quay, mais quand elles ne sont pas atteintes, il tirera plutôt les images du registre d’images dans la région locale.

Important

Il est possible d’utiliser uniquement le verrouillage egress sur les clusters utilisant les régions AWS suivantes:

  • à l’ouest-1
  • à l’ouest-2
  • à propos de us-east-1
  • à propos de Us-east-2
  • AP-northeast-1
  • AP-northeast-2
  • AP-northeast-3
  • AP-sud-1
  • AP-sud-est-1
  • AP-sud-est-2
  • ca-central-1
  • centre de l’UE-1
  • UE-Nord-1
  • UE-Ouest-1
  • UE-Ouest-2
  • UE-Ouest-3
  • le SA-Est-1

Les clusters publics et privés disposant d’un verrouillage de sortie obtiennent leurs images de conteneur Red Hat à partir d’un registre situé dans la région locale du cluster au lieu de recueillir ces images à partir de différents points de terminaison et registres sur Internet. Il est possible de créer un cluster entièrement opérationnel qui ne nécessite pas de sortie publique en configurant un cloud privé virtuel (VPC) et en utilisant l’indicateur --properties zero_egress:true lors de la création de votre cluster.

Important

Egress Lockdown est une fonctionnalité d’aperçu technologique seulement. Les fonctionnalités d’aperçu technologique ne sont pas prises en charge avec les accords de niveau de service de production de Red Hat (SLA) et pourraient ne pas être fonctionnellement complètes. Le Red Hat ne recommande pas de les utiliser en production. Ces fonctionnalités offrent un accès précoce aux fonctionnalités du produit à venir, permettant aux clients de tester les fonctionnalités et de fournir des commentaires pendant le processus de développement.

En savoir plus sur la portée du support des fonctionnalités de Red Hat Technology Preview, voir la portée du support des fonctionnalités d’aperçu de la technologie.

Les préquisites

  • Il y a un compte AWS avec suffisamment d’autorisations pour créer des VPC, des sous-réseaux et d’autres infrastructures requises.
  • Le Terraform v1.4.0+ CLI a été installé.
  • Le ROSA v1.2.45+ CLI a été installé.
  • « vous avez installé et configuré le CLI AWS avec les informations d’identification nécessaires.
  • C’est toi qui as installé le Git CLI.
Important

Il est possible d’utiliser le verrouillage de sortie sur toutes les versions prises en charge de Red Hat OpenShift Service sur AWS qui utilisent l’architecture de plan de contrôle hébergé; Cependant, Red Hat suggère d’utiliser la dernière version de z-stream disponible pour chaque version OpenShift Container Platform.

Bien que vous puissiez installer et mettre à jour vos clusters comme vous le feriez un cluster régulier, en raison d’un problème en amont de la façon dont le registre d’images interne fonctionne dans des environnements déconnectés, votre cluster qui utilise le verrouillage de sortie ne sera pas en mesure d’utiliser pleinement tous les composants de la plate-forme, tels que le registre des images. Ces fonctionnalités peuvent être restaurées en utilisant la dernière version ROSA lors de la mise à niveau ou de l’installation de votre cluster.

Il faut disposer d’un cloud privé virtuel (VPC) pour créer des ROSA avec des clusters HCP. Il est possible d’utiliser l’une des méthodes suivantes pour créer un VPC:

  • Créer un VPC à l’aide d’un modèle Terraform
  • Créez manuellement les ressources VPC dans la console AWS
Note

Les instructions Terraform sont à des fins de test et de démonstration. L’installation de votre propre VPC nécessite des modifications pour répondre à vos besoins et contraintes spécifiques. Assurez-vous également que lorsque vous utilisez le script Terraform suivant, c’est dans la même région que vous avez l’intention d’installer votre cluster.

Le terraform est un outil qui vous permet de créer diverses ressources à l’aide d’un modèle établi. Le processus suivant utilise les options par défaut au besoin pour créer un ROSA avec le cluster HCP. Consultez les ressources supplémentaires pour plus d’informations sur l’utilisation de Terraform.

Conditions préalables

  • La version 1.4.0 ou plus récente de Terraform est installée sur votre machine.
  • « vous avez installé Git sur votre machine.

Procédure

  1. Lancez une invite shell et clonez le dépôt Terraform VPC en exécutant la commande suivante:

    $ git clone https://github.com/openshift-cs/terraform-vpc-example
    Copy to Clipboard Toggle word wrap
  2. Accédez au répertoire créé en exécutant la commande suivante:

    $ cd terraform-vpc-example/zero-egress
    Copy to Clipboard Toggle word wrap
  3. Lancez le fichier Terraform en exécutant la commande suivante:

    $ terraform init
    Copy to Clipboard Toggle word wrap

    Le message confirmant l’initialisation apparaît lorsque ce processus se termine.

  4. Afin de construire votre plan VPC Terraform basé sur le modèle Terraform existant, exécutez la commande plan. Il faut inclure votre région AWS, les zones de disponibilité, les blocs CIDR et les sous-réseaux privés. Choisissez de spécifier un nom de cluster. Le fichier rosa-zero-egress.tfplan est ajouté au répertoire hypershift-tf une fois le plan terraform terminé. Consultez le fichier README du dépôt Terraform VPC.

    $ terraform plan -out rosa-zero-egress.tfplan -var region=<aws_region> \ 
    1
    
          -var 'availability_zones=["aws_region_1a","aws_region_1b","aws_region_1c"]'\ 
    2
    
          -var vpc_cidr_block=10.0.0.0/16 \ 
    3
    
          -var 'private_subnets=["10.0.0.0/24", "10.0.1.0/24", "10.0.2.0/24"]' 
    4
    Copy to Clipboard Toggle word wrap
    1
    Entrez votre région AWS.
    Important

    Il est possible d’utiliser uniquement le verrouillage d’évacuation sur les amas qui utilisent l’US-west-1, us-west-2, us-est-1, us-est-2, ap-northeast-1, ap-northeast-2, ap-northeast-3, ap-sud-est-1, ap-sudest-1, ap-sud-est-1, AP-sud-est-2, ca-central-1, eu-central-1, eu-north-1, eu-west-1, eu-west-2, eu-west-3 et sa-east-1 AWS.

    2
    Entrez les zones de disponibilité pour le VPC. À titre d’exemple, pour un VPC qui utilise ap-sud-est-1, vous utiliseriez les zones de disponibilité suivantes: ["ap-sud-est-1a", "ap-sudeast-1b", "ap-sudeast-1c"].
    3
    Entrez le bloc CIDR pour votre VPC.
    4
    Entrez chacun des sous-réseaux créés pour le VPC.
  5. Appliquez ce fichier de plan pour construire votre VPC en exécutant la commande suivante:

    $ terraform apply rosa-zero-egress.tfplan
    Copy to Clipboard Toggle word wrap

5.1.2. Création manuelle d’un Cloud privé virtuel

Lorsque vous choisissez de créer manuellement votre Cloud privé virtuel (VPC) au lieu d’utiliser Terraform, accédez à la page VPC de la console AWS.

Le VPC doit répondre aux exigences indiquées dans le tableau suivant.

Expand
Tableau 5.1. Exigences pour votre VPC
ExigenceDétails

Le nom du VPC

Il faut avoir le nom et l’identifiant VPC spécifiques lors de la création de votre cluster.

Gamme CIDR

La gamme VPC CIDR doit correspondre à votre machine CIDR.

La zone de disponibilité

Il vous faut une zone de disponibilité pour une seule zone, et vous en avez besoin de trois pour les zones de disponibilité pour plusieurs zones.

Le sous-réseau public

Il faut avoir un sous-réseau public avec une passerelle NAT pour les clusters publics. Les clusters privés n’ont pas besoin d’un sous-réseau public.

DNS nom d’hôte et résolution

Assurez-vous que le nom d’hôte DNS et la résolution sont activés.

Étiqueter vos sous-réseaux

Avant de pouvoir utiliser votre VPC pour créer un ROSA avec le cluster HCP, vous devez marquer vos sous-réseaux VPC. Les vérifications automatisées de prévol de service vérifient que ces ressources sont étiquetées correctement avant de pouvoir utiliser ces ressources. Le tableau suivant montre comment vos ressources doivent être étiquetées comme suit:

Expand
A) RessourcesLa cléLa valeur

Le sous-réseau public

Kubernetes.io/rôle/elb

1 ou aucune valeur

Le sous-réseau privé

Kubernetes.io/role/interne-elb

1 ou aucune valeur

Note

Il faut marquer au moins un sous-réseau privé et, le cas échéant, et un sous-réseau public.

Conditions préalables

  • « vous avez créé un VPC.
  • C’est toi qui as installé l’Aws CLI.

Procédure

  1. Balisez vos ressources dans votre terminal en exécutant les commandes suivantes:

    1. Dans le cas des sous-réseaux publics, exécutez:

      $ aws ec2 create-tags --resources <public-subnet-id> --region <aws_region> --tags Key=kubernetes.io/role/elb,Value=1
      Copy to Clipboard Toggle word wrap
    2. Dans le cas des sous-réseaux privés, exécutez:

      $ aws ec2 create-tags --resources <private-subnet-id> --region <aws_region> --tags Key=kubernetes.io/role/internal-elb,Value=1
      Copy to Clipboard Toggle word wrap

La vérification

  • Assurez-vous que la balise est correctement appliquée en exécutant la commande suivante:

    $ aws ec2 describe-tags --filters "Name=resource-id,Values=<subnet_id>"
    Copy to Clipboard Toggle word wrap

    Exemple de sortie

    TAGS    Name                    <subnet-id>        subnet  <prefix>-subnet-public1-us-east-1a
    TAGS    kubernetes.io/role/elb  <subnet-id>        subnet  1
    Copy to Clipboard Toggle word wrap

Configuration des groupes de sécurité AWS et des connexions PrivateLink

Après avoir créé votre VPC, créez vos groupes de sécurité AWS et vos points de terminaison VPC.

Procédure

  1. Créez le groupe de sécurité AWS en exécutant la commande suivante:

    $ aws ec2 create-security-group \
            --group-name allow-inbound-traffic \
            --description "allow inbound traffic" \
            --vpc-id <vpc_id> \ 
    1
    
            --region <aws_region> \ 
    2
    Copy to Clipboard Toggle word wrap
    1
    Entrez l’identifiant de votre VPC.
    2
    Entrez la région AWS où le VPC a été installé.
  2. Accordez l’accès à l’entrée du groupe de sécurité en exécutant la commande suivante:

    $ aws ec2 authorize-security-group-ingress \
            --group-id <group_id> \ 
    1
    
            --protocol -1 \
            --port 0-0 \
            --cidr <vpc_cidr> \ 
    2
    
            --region <aws_region> \ 
    3
    Copy to Clipboard Toggle word wrap
    1
    --group-id utilise l’ID du groupe de sécurité créé avec la commande précédente.
    2
    Entrez le CIDR de votre VPC.
    3
    La région AWS où vous avez installé votre VPC
  3. Créez votre point de terminaison STS VPC en exécutant la commande suivante:

    $ aws ec2 create-vpc-endpoint \
        --vpc-id <vpc_id> \ 
    1
    
        --service-name com.amazonaws.<aws_region>.sts \ 
    2
    
        --vpc-endpoint-type Interface
    Copy to Clipboard Toggle word wrap
    1
    Entrez l’identifiant de votre VPC.
    2
    Entrez la région AWS où le VPC a été installé.
  4. Créez vos points de terminaison ECR VPC en exécutant la commande suivante:

    $ aws ec2 create-vpc-endpoint \
        --vpc-id <vpc_id> \
        --service-name com.amazonaws.<aws_region>.ecr.dkr \ 
    1
    
        --vpc-endpoint-type Interface
    Copy to Clipboard Toggle word wrap
    1
    Entrez la région AWS où se trouve le VPC.
  5. Créez votre point de terminaison S3 VPC en exécutant la commande suivante:

    $ aws ec2 create-vpc-endpoint \
        --vpc-id <vpc_id> \
        --service-name com.amazonaws.<aws_region>.s3
    Copy to Clipboard Toggle word wrap

Avant d’utiliser le service Red Hat OpenShift sur AWS (ROSA) CLI (rosa) pour créer Red Hat OpenShift Service sur AWS (ROSA) avec des clusters de plans de contrôle hébergés (HCP), créez les rôles et les politiques nécessaires à l’échelle du compte, y compris les politiques d’opérateur.

Note

Les ROSA avec les clusters HCP nécessitent des rôles de compte et d’opérateur avec des stratégies gérées AWS jointes. Les politiques gérées par les clients ne sont pas prises en charge. En savoir plus sur les stratégies gérées par AWS pour ROSA avec les clusters HCP, consultez les stratégies gérées AWS pour les rôles de compte ROSA.

Conditions préalables

  • Avec HCP, 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.
  • En utilisant le ROSA CLI, vous vous êtes connecté à votre compte Red Hat.

Procédure

  1. Dans le cas où ils n’existent pas dans votre compte AWS, créez les rôles STS requis à l’échelle du compte et attachez les stratégies en exécutant la commande suivante:

    $ rosa create account-roles --hosted-cp
    Copy to Clipboard Toggle word wrap
  2. Assurez-vous que votre rôle de travailleur a la bonne stratégie AWS en exécutant la commande suivante:

    $ aws iam attach-role-policy \
    --role-name ManagedOpenShift-HCP-ROSA-Worker-Role \ 
    1
    
    --policy-arn "arn:aws:iam::aws:policy/AmazonEC2ContainerRegistryReadOnly"
    Copy to Clipboard Toggle word wrap
    1
    Ce rôle doit inclure le préfixe qui a été créé à l’étape précédente.
  3. Facultatif: Définir votre préfixe en tant que variable environnementale en exécutant la commande suivante:

    $ export ACCOUNT_ROLES_PREFIX=<account_role_prefix>
    Copy to Clipboard Toggle word wrap
    • Afficher la valeur de la variable en exécutant la commande suivante:

      $ echo $ACCOUNT_ROLES_PREFIX
      Copy to Clipboard Toggle word wrap

      Exemple de sortie

      ManagedOpenShift
      Copy to Clipboard Toggle word wrap

Consultez les politiques IAM gérées par AWS pour ROSA, consultez les politiques IAM gérées par AWS pour ROSA.

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

5.4. Créer des rôles et des politiques de l’opérateur

Lorsque vous utilisez un ROSA avec le cluster HCP, vous devez créer les rôles IAM d’opérateur requis pour Red Hat OpenShift Service sur AWS (ROSA) avec des déploiements de plans de contrôle hébergés (HCP). Les opérateurs de cluster utilisent les rôles d’opérateur pour obtenir les autorisations temporaires requises pour effectuer des opérations de cluster, telles que la gestion du stockage back-end, les informations d’identification des fournisseurs de cloud et l’accès externe à un cluster.

Conditions préalables

  • Avec HCP, vous avez complété les prérequis AWS pour ROSA.
  • Le dernier service Red Hat OpenShift sur AWS ROSA CLI (rosa) est installé et configuré sur votre hôte d’installation.
  • Les rôles AWS à l’échelle du compte ont été créés.

Procédure

  1. Définissez le nom de votre préfixe sur une variable d’environnement en utilisant la commande suivante:

    $ export OPERATOR_ROLES_PREFIX=<prefix_name>
    Copy to Clipboard Toggle word wrap
  2. Afin de créer vos rôles d’opérateur, exécutez la commande suivante:

    $ rosa create operator-roles --hosted-cp --prefix=$OPERATOR_ROLES_PREFIX --oidc-config-id=$OIDC_ID --installer-role-arn arn:aws:iam::${AWS_ACCOUNT_ID}:role/${ACCOUNT_ROLES_PREFIX}-HCP-ROSA-Installer-Role
    Copy to Clipboard Toggle word wrap

    La ventilation suivante fournit des options pour la création de rôles d’opérateur.

    $ rosa create operator-roles --hosted-cp
    	--prefix=$OPERATOR_ROLES_PREFIX 
    1
    
    	--oidc-config-id=$OIDC_ID 
    2
    
    	--installer-role-arn arn:aws:iam::${AWS_ACCOUNT_ID}:role/${ACCOUNT_ROLES_PREFIX}-HCP-ROSA-Installer-Role 
    3
    Copy to Clipboard Toggle word wrap
    1
    Il faut fournir un préfixe lors de la création de ces rôles d’opérateur. Le fait de ne pas le faire produit une erreur. Consultez les ressources supplémentaires de cette section pour obtenir des informations sur le préfixe de l’opérateur.
    2
    Cette valeur est l’identifiant de configuration OIDC que vous avez créé pour votre ROSA avec le cluster HCP.
    3
    Cette valeur est le rôle d’installateur ARN que vous avez créé lorsque vous avez créé les rôles de compte ROSA.

    Il faut inclure le paramètre --hosted-cp pour créer les rôles corrects pour ROSA avec les clusters HCP. Cette commande renvoie les informations suivantes.

    Exemple de sortie

    ? Role creation mode: auto
    ? Operator roles prefix: <pre-filled_prefix> 
    1
    
    ? OIDC Configuration ID: 23soa2bgvpek9kmes9s7os0a39i13qm4 | https://dvbwgdztaeq9o.cloudfront.net/23soa2bgvpek9kmes9s7os0a39i13qm4 
    2
    
    ? Create hosted control plane operator roles: Yes
    W: More than one Installer role found
    ? Installer role ARN: arn:aws:iam::4540112244:role/<prefix>-HCP-ROSA-Installer-Role
    ? Permissions boundary ARN (optional):
    I: Reusable OIDC Configuration detected. Validating trusted relationships to operator roles:
    I: Creating roles using 'arn:aws:iam::4540112244:user/<userName>'
    I: Created role '<prefix>-openshift-cluster-csi-drivers-ebs-cloud-credentials' with ARN 'arn:aws:iam::4540112244:role/<prefix>-openshift-cluster-csi-drivers-ebs-cloud-credentials'
    I: Created role '<prefix>-openshift-cloud-network-config-controller-cloud-credenti' with ARN 'arn:aws:iam::4540112244:role/<prefix>-openshift-cloud-network-config-controller-cloud-credenti'
    I: Created role '<prefix>-kube-system-kube-controller-manager' with ARN 'arn:aws:iam::4540112244:role/<prefix>-kube-system-kube-controller-manager'
    I: Created role '<prefix>-kube-system-capa-controller-manager' with ARN 'arn:aws:iam::4540112244:role/<prefix>-kube-system-capa-controller-manager'
    I: Created role '<prefix>-kube-system-control-plane-operator' with ARN 'arn:aws:iam::4540112244:role/<prefix>-kube-system-control-plane-operator'
    I: Created role '<prefix>-kube-system-kms-provider' with ARN 'arn:aws:iam::4540112244:role/<prefix>-kube-system-kms-provider'
    I: Created role '<prefix>-openshift-image-registry-installer-cloud-credentials' with ARN 'arn:aws:iam::4540112244:role/<prefix>-openshift-image-registry-installer-cloud-credentials'
    I: Created role '<prefix>-openshift-ingress-operator-cloud-credentials' with ARN 'arn:aws:iam::4540112244:role/<prefix>-openshift-ingress-operator-cloud-credentials'
    I: To create a cluster with these roles, run the following command:
    	rosa create cluster --sts --oidc-config-id 23soa2bgvpek9kmes9s7os0a39i13qm4 --operator-roles-prefix <prefix> --hosted-cp
    Copy to Clipboard Toggle word wrap

    1
    Ce champ est prérempli avec le préfixe que vous définissez dans la commande initiale de création.
    2
    Ce champ vous oblige à sélectionner une configuration OIDC que vous avez créée pour votre ROSA avec le cluster HCP.

    Les rôles d’opérateur sont maintenant créés et prêts à être utilisés pour créer votre ROSA avec le cluster HCP.

La vérification

  • Il est possible de répertorier les rôles d’opérateur associés à votre compte ROSA. Exécutez la commande suivante:

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

    Exemple de sortie

    I: Fetching operator roles
    ROLE PREFIX  AMOUNT IN BUNDLE
    <prefix>      8
    ? Would you like to detail a specific prefix Yes 
    1
    
    ? Operator Role Prefix: <prefix>
    ROLE NAME                                                         ROLE ARN                                                                                         VERSION  MANAGED
    <prefix>-kube-system-capa-controller-manager                       arn:aws:iam::4540112244:role/<prefix>-kube-system-capa-controller-manager                       4.13     No
    <prefix>-kube-system-control-plane-operator                        arn:aws:iam::4540112244:role/<prefix>-kube-system-control-plane-operator                        4.13     No
    <prefix>-kube-system-kms-provider                                  arn:aws:iam::4540112244:role/<prefix>-kube-system-kms-provider                                  4.13     No
    <prefix>-kube-system-kube-controller-manager                       arn:aws:iam::4540112244:role/<prefix>-kube-system-kube-controller-manager                       4.13     No
    <prefix>-openshift-cloud-network-config-controller-cloud-credenti  arn:aws:iam::4540112244:role/<prefix>-openshift-cloud-network-config-controller-cloud-credenti  4.13     No
    <prefix>-openshift-cluster-csi-drivers-ebs-cloud-credentials       arn:aws:iam::4540112244:role/<prefix>-openshift-cluster-csi-drivers-ebs-cloud-credentials       4.13     No
    <prefix>-openshift-image-registry-installer-cloud-credentials      arn:aws:iam::4540112244:role/<prefix>-openshift-image-registry-installer-cloud-credentials      4.13     No
    <prefix>-openshift-ingress-operator-cloud-credentials              arn:aws:iam::4540112244:role/<prefix>-openshift-ingress-operator-cloud-credentials              4.13     No
    Copy to Clipboard Toggle word wrap

    1
    Après l’exécution de la commande, il affiche tous les préfixes associés à votre compte AWS et note combien de rôles sont associés à ce préfixe. Lorsque vous avez besoin de voir tous ces rôles et leurs détails, entrez "Oui" sur l’invite détaillée pour avoir ces rôles listés avec des détails.

Lorsque vous utilisez Red Hat OpenShift Service sur AWS (ROSA) interface de ligne de commande (CLI), rosa, pour créer un cluster, vous pouvez sélectionner les options par défaut pour créer le cluster rapidement.

Conditions préalables

  • Avec HCP, 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.
  • C’est vous qui avez créé une configuration OIDC.
  • Le rôle de service AWS Elastic Load Balancing (ELB) existe dans votre compte AWS.

Procédure

  1. Faites appel à l’une des commandes suivantes pour créer votre ROSA avec le cluster HCP:

    Note

    Lors de la création d’un ROSA avec le cluster HCP, la machine par défaut Classless Inter-Domain Routing (CIDR) est 10.0.0.0/16. Dans le cas où cela ne correspond pas à la plage CIDR pour vos sous-réseaux VPC, ajoutez --machine-cidr &lt;address_block&gt; aux commandes suivantes. Afin d’en savoir plus sur les gammes CIDR par défaut pour Red Hat OpenShift Service sur AWS, consultez les définitions de la gamme CIDR.

    • Dans le cas où vous n’avez pas défini les variables d’environnement, exécutez la commande suivante:

      $ rosa create cluster --cluster-name=<cluster_name> \ <.>
           --mode=auto --hosted-cp [--private] \ <.>
           --operator-roles-prefix <operator-role-prefix> \ <.>
           --oidc-config-id <id-of-oidc-configuration> \
           --subnet-ids=<private-subnet-id> --region <region> \
           --machine-cidr 10.0.0.0/16 --service-cidr 172.30.0.0/16 \
           --pod-cidr 10.128.0.0/14 --host-prefix 23 \
           --billing-account <root-acct-id> \ <.>
           --properties zero_egress:true
      Copy to Clipboard Toggle word wrap

      &Lt;.&gt; spécifiez le nom de votre cluster. 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 provisionné 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 cluster. &lt;.&gt; Par défaut, 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.

      &Lt;.&gt; fournir le compte AWS qui est responsable de toute facturation.

    • Lorsque vous définissez les variables d’environnement, créez un cluster avec le verrouillage de sortie qui dispose d’un seul pool de machines initial, à l’aide d’une API disponible en privé, et d’un Ingress disponible en privé en exécutant la commande suivante:

      $ rosa create cluster --private --cluster-name=<cluster_name> \
          --mode=auto --hosted-cp --operator-roles-prefix=$OPERATOR_ROLES_PREFIX \
          --oidc-config-id=$OIDC_ID --subnet-ids=$SUBNET_IDS \
          --region <region> --machine-cidr 10.0.0.0/16 --service-cidr 172.30.0.0/16 \
          --pod-cidr 10.128.0.0/14 --host-prefix 23 --billing-account <root-acct-id> \
          --private --properties zero_egress:true
      Copy to Clipboard Toggle word wrap
  2. Consultez l’état de votre cluster en exécutant la commande suivante:

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

    Les changements de champ suivants sont énumérés dans la sortie au fur et à mesure que l’installation du cluster progresse:

    • 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 plus de 10 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.

  3. Faites le suivi de la progression de la création de clusters en regardant le Red Hat OpenShift Service sur les journaux des programmes d’installation AWS. Afin de vérifier les journaux, exécutez la commande suivante:

    $ rosa logs install --cluster=<cluster_name> --watch \ <.>
    Copy to Clipboard Toggle word wrap

    &Lt;.&gt; optionnel: Pour regarder les nouveaux messages de journal au fur et à mesure que l’installation progresse, utilisez l’argument --watch.

Il est possible de créer Red Hat OpenShift Service sur AWS (ROSA) avec des clusters de plans de contrôle hébergés (HCP) qui utilisent un fournisseur d’identité externe OpenID Connect (OIDC) pour émettre des jetons pour l’authentification, en remplaçant le serveur OpenShift OAuth intégré. Alors que le serveur OpenShift OAuth intégré prend en charge l’intégration avec une variété de fournisseurs d’identité, y compris les fournisseurs d’identité OIDC externes, il est limité aux capacités du serveur OAuth lui-même. Il est possible d’intégrer directement des fournisseurs d’identité OIDC externes à ROSA avec des clusters HCP afin de faciliter les flux de travail de machine à machine, tels que CLI, et de fournir des fonctionnalités supplémentaires qui ne sont pas disponibles lors de l’utilisation du serveur OpenShift OAuth intégré.

Important

Comme il n’est pas possible de mettre à niveau ou de convertir des clusters ROSA existants en architecture de plans de contrôle hébergés, vous devez créer un nouveau cluster pour utiliser ROSA avec la fonctionnalité HCP. De plus, vous ne pouvez pas convertir un cluster qui a été créé pour utiliser des fournisseurs d’authentification externes pour utiliser le serveur interne OAuth2. Il faut aussi créer un nouveau cluster.

Important

Le partage de VPC sur plusieurs comptes AWS n’est actuellement pas pris en charge pour ROSA avec HCP. Il ne faut pas installer un ROSA avec le cluster HCP dans des sous-réseaux partagés à partir d’un autre compte AWS. Consultez « Multiples ROSA clusters dans un seul VPC pris en charge ? » pour plus d’informations.

Note

Le ROSA avec les clusters HCP ne prend en charge que l’authentification du Service de jetons de sécurité (STS).

Autres lectures

  • Consultez la documentation AWS pour obtenir des informations sur le démarrage de ROSA avec HCP en utilisant le ROSA CLI en mode automatique.

6.1. La ROSA avec HCP Prérequis

Afin de créer un ROSA avec le cluster HCP, vous devez avoir complété les étapes suivantes:

  • Complétez les prérequis AWS
  • Cloud privé virtuel configuré (VPC)
  • Création de rôles à l’échelle du compte
  • Création d’une configuration OIDC
  • Création de rôles d’opérateur

Dans le ROSA CLI, utilisez l’indicateur --external-auth-fourrs-activé pour créer un cluster qui utilise un service d’authentification externe.

Note

Lors de la création d’un ROSA avec le cluster HCP, la machine par défaut Classless Inter-Domain Routing (CIDR) est 10.0.0.0/16. Dans le cas où cela ne correspond pas à la plage CIDR pour vos sous-réseaux VPC, ajoutez --machine-cidr &lt;address_block&gt; aux commandes suivantes.

Procédure

  • Lorsque vous utilisez les variables OIDC_ID, SUBNET_IDS et OPERATOR_ROLES_PREFIX pour préparer votre environnement, vous pouvez continuer à utiliser ces variables lors de la création de votre cluster. À titre d’exemple, exécutez la commande suivante:

    $ rosa create cluster --hosted-cp --subnet-ids=$SUBNET_IDS \
       --oidc-config-id=$OIDC_ID --cluster-name=<cluster_name> \
       --operator-roles-prefix=$OPERATOR_ROLES_PREFIX \
       --external-auth-providers-enabled
    Copy to Clipboard Toggle word wrap
  • Lorsque vous n’avez pas défini de variables environnementales, exécutez la commande suivante:

    $ rosa create cluster --cluster-name=<cluster_name> --sts --mode=auto \
        --hosted-cp --operator-roles-prefix <operator-role-prefix> \
        --oidc-config-id <ID-of-OIDC-configuration> \
        --external-auth-providers-enabled \
        --subnet-ids=<public-subnet-id>,<private-subnet-id>
    Copy to Clipboard Toggle word wrap

La vérification

  • Assurez-vous que votre authentification externe est activée dans les détails du cluster en exécutant la commande suivante:

    $ rosa describe cluster --cluster=<cluster_name>
    Copy to Clipboard Toggle word wrap
    Name:                       rosa-ext-test
    Display Name:               rosa-ext-test
    ID:                         <cluster_id>
    External ID:                <cluster_ext_id>
    Control Plane:              ROSA Service Hosted
    OpenShift Version:          4.18.0
    Channel Group:              stable
    DNS:                        <dns>
    AWS Account:                <AWS_id>
    AWS Billing Account:        <AWS_id>
    API URL:                    <ocm_api>
    Console URL:
    Region:                     us-east-1
    Availability:
     - Control Plane:           MultiAZ
     - Data Plane:              SingleAZ
    
    Nodes:
     - Compute (desired):       2
     - Compute (current):       0
    Network:
     - Type:                    OVNKubernetes
     - Service CIDR:            <service_cidr>
     - Machine CIDR:            <machine_cidr>
     - Pod CIDR:                <pod_cidr>
     - Host Prefix:             /23
     - Subnets:                 <subnet_ids>
    EC2 Metadata Http Tokens:   optional
    Role (STS) ARN:             arn:aws:iam::<AWS_id>:role/<account_roles_prefix>-HCP-ROSA-Installer-Role
    Support Role ARN:           arn:aws:iam::<AWS_id>:role/<account_roles_prefix>-HCP-ROSA-Support-Role
    Instance IAM Roles:
     - Worker:                  arn:aws:iam::<AWS_id>:role/<account_roles_prefix>-HCP-ROSA-Worker-Role
    Operator IAM Roles:
     - arn:aws:iam::<AWS_id>:role/<operator_roles_prefix>-openshift-cloud-network-config-controller-clo
     - arn:aws:iam::<AWS_id>:role/<operator_roles_prefix>-kube-system-capa-controller-manager
     - arn:aws:iam::<AWS_id>:role/<operator_roles_prefix>-kube-system-control-plane-operator
     - arn:aws:iam::<AWS_id>:role/<operator_roles_prefix>-kube-system-kms-provider
     - arn:aws:iam::<AWS_id>:role/<operator_roles_prefix>-kube-system-kube-controller-manager
     - arn:aws:iam::<AWS_id>:role/<operator_roles_prefix>-openshift-image-registry-installer-cloud-cred
     - arn:aws:iam::<AWS_id>:role/<operator_roles_prefix>-openshift-ingress-operator-cloud-credentials
     - arn:aws:iam::<AWS_id>:role/<operator_roles_prefix>-openshift-cluster-csi-drivers-ebs-cloud-crede
    Managed Policies:           Yes
    State:                      ready
    Private:                    No
    Created:                    Mar 29 2024 14:25:52 UTC
    User Workload Monitoring:   Enabled
    Details Page:               https://<url>
    OIDC Endpoint URL:          https://<endpoint> (Managed)
    Audit Log Forwarding:       Disabled
    External Authentication:    Enabled 
    1
    Copy to Clipboard Toggle word wrap
    1
    L’indicateur d’authentification externe est activé et vous pouvez maintenant créer un fournisseur d’authentification externe.

6.3. Création d’un fournisseur d’authentification externe

Après avoir créé un ROSA avec le cluster HCP avec l’option activée pour les fournisseurs d’authentification externes, vous devez créer un fournisseur à l’aide du ROSA CLI.

Note

À l’instar de la commande rosa create|delete|list idp[s] dans le ROSA CLI, vous ne pouvez pas modifier un fournisseur d’identité existant que vous avez créé à l’aide de rosa créer un fournisseur externe auth. Au lieu de cela, vous devez supprimer le fournisseur d’authentification externe et en créer un nouveau.

Le tableau suivant montre les drapeaux CLI possibles que vous pouvez utiliser lors de la création de votre fournisseur d’authentification externe:

Expand
Drapeau de CLIDescription

--cluster

Le nom ou l’identifiant de votre cluster.

--nom

Le nom utilisé pour désigner le fournisseur d’authentification externe.

--console-client-secret

Cette chaîne est le secret client utilisé pour associer votre compte à l’application. Dans le cas où vous n’incluez pas le secret client, cette commande utilise un OIDC OAuthClient public.

--émetteurs-audiences

Il s’agit d’une liste séparée par des virgules d’audiences symboliques.

--émetteur-url

L’URL de l’émetteur de jetons.

--claim-mapping-username-claim

Le nom de la revendication qui devrait être utilisé pour construire des noms d’utilisateur pour l’identité du cluster.

--claim-mapping-groups-claim

Le nom de la revendication qui devrait être utilisé pour construire des noms de groupe pour l’identité du cluster.

Procédure

  • Afin d’utiliser l’interface de commande interactive, exécutez les commandes suivantes:

    $ rosa create external-auth-provider -c <cluster_name>
    Copy to Clipboard Toggle word wrap
    I: Enabling interactive mode
    ? Name: 
    1
    
    ? Issuer audiences: 
    2
    
    ? The serving url of the token issuer: 
    3
    
    ? CA file path (optional): 
    4
    
    ? Claim mapping username: 
    5
    
    ? Claim mapping groups: 
    6
    
    ? Claim validation rule (optional): 
    7
    
    ? Console client id (optional): 
    8
    Copy to Clipboard Toggle word wrap
    1
    Le nom de votre fournisseur d’authentification externe. Ce nom devrait être un cas inférieur avec des chiffres et des tirets.
    2
    Les identifiants d’audience pour lesquels ce fournisseur d’authentification émet des jetons.
    3
    L’URL de l’émetteur qui sert le jeton.
    4
    Facultatif: Le fichier de certificat à utiliser lors de la présentation de demandes.
    5
    Le nom de la revendication qui est utilisé pour construire les noms d’utilisateur pour l’identité du cluster, par exemple en utilisant le courrier électronique.
    6
    La méthode avec laquelle transformer le jeton ID en une identité de cluster, comme l’utilisation de groupes.
    7
    Facultatif : Les règles qui aident à valider les demandes de jetons qui authentifient vos utilisateurs. Ce champ doit être formaté comme :&lt;required_value&gt;.
    8
    Facultatif: L’identification de l’application ou du client que votre inscription d’application utilise pour la console.
  • Il est possible d’inclure les identifiants requis pour créer votre fournisseur d’authentification externe avec la commande suivante:

    rosa create external-auth-provider --cluster=<cluster_id> \
        --name=<provider_name> --issuer-url=<issuing_url> \
        --issuer-audiences=<audience_id> \
        --claim-mapping-username-claim=email \
        --claim-mapping-groups-claim=groups \
        --console-client-id=<client_id_for_app_registration> \
        --console-client-secret=<client_secret>
    Copy to Clipboard Toggle word wrap

    Exemple de sortie

    I: Successfully created an external authentication provider for cluster '<cluster_id>'
    Copy to Clipboard Toggle word wrap

La vérification

  • Afin de vérifier votre fournisseur d’authentification externe, exécutez l’une des options suivantes:

    • Énumérez la configuration d’authentification externe sur un cluster spécifié avec la commande suivante:

      $ rosa list external-auth-provider -c <cluster_name>
      Copy to Clipboard Toggle word wrap

      Exemple de sortie

      L’exemple suivant montre un fournisseur d’authentification externe Microsoft Entra ID configuré:

      NAME        ISSUER URL
      m-entra-id  https://login.microsoftonline.com/<group_id>/v2.0
      Copy to Clipboard Toggle word wrap
    • Afficher la configuration d’authentification externe sur un cluster spécifié à l’aide de la commande suivante:

      $ rosa describe external-auth-provider \
          -c <cluster_name> --name <name_of_external_authentication>
      Copy to Clipboard Toggle word wrap

      Exemple de sortie

      ID:                          ms-entra-id
      Cluster ID:                  <cluster_id>
      Issuer audiences:
                                   - <audience_id>
      Issuer Url:                  https://login.microsoftonline.com/<group_id>/v2.0
      Claim mappings group:        groups
      Claim mappings username:     email
      Copy to Clipboard Toggle word wrap

En tant que ROSA avec HCP cluster propriétaire, vous pouvez utiliser l’identifiant de verre de rupture pour créer des informations d’identification des clients administratifs temporaires pour accéder à vos clusters qui sont configurés avec des émetteurs de jetons OpenID Connect (OIDC) personnalisés. Créer un identifiant de verre de rupture génère un nouveau fichier cluster-admin kubeconfig. Le fichier kubeconfig contient des informations sur le cluster utilisé par le CLI pour connecter un client au bon cluster et au serveur API. Le fichier kubeconfig nouvellement généré permet d’accéder au ROSA avec le cluster HCP.

Conditions préalables

  • La création d’un ROSA avec le cluster HCP avec authentification externe activée. Création d’un ROSA avec HCP avec le cluster HCP qui utilise des fournisseurs d’authentification externes.
  • « vous avez créé un fournisseur d’authentification externe. Consultez Création d’un fournisseur d’authentification externe pour plus d’informations.
  • Il y a un compte avec les autorisations d’administrateur de cluster.

Procédure

  1. Créez un identifiant de verre cassé en utilisant l’une des commandes suivantes:

    • Afin de créer un identifiant de verre cassé en utilisant l’interface de commande interactive pour spécifier de manière interactive les paramètres personnalisés, exécutez la commande suivante:

      $ rosa create break-glass-credential -c <cluster_name> -i 
      1
      Copy to Clipboard Toggle word wrap
      1
      &lt;cluster_name&gt; par le nom de votre cluster.

      Cette commande démarre un processus CLI interactif:

      Exemple de sortie

      I: Enabling interactive mode
      ? Username (optional): 
      1
      
      ? Expiration duration (optional): 
      2
      
      I: Successfully created a break glass credential for cluster 'ac-hcp-test'.
      Copy to Clipboard Toggle word wrap

      1
      Dans le cas où le nom d’utilisateur est laissé en blanc, la valeur du nom d’utilisateur sera générée au hasard.
      2
      La validité minimale de l’identifiant de verre cassé est de 10 minutes, et la validité maximale est de 24 heures. En cas de blanc, la valeur de la durée d’expiration par défaut est de 24 heures.
    • Créer un identifiant de verre de rupture pour cluster appelé mycluster avec des valeurs spécifiées:

      $ rosa create break-glass-credential -c mycluster --username test-username --expiration 1h
      Copy to Clipboard Toggle word wrap
  2. Énumérez les identifiants d’identification, le statut et les utilisateurs associés disponibles pour un cluster appelé mycluster en exécutant la commande suivante:

    $ rosa list break-glass-credential -c mycluster
    Copy to Clipboard Toggle word wrap

    Exemple de sortie

    ID                                USERNAME    STATUS
    2a7jli9n4phe6c02ul7ti91djtv2o51d  test-user   issued
    Copy to Clipboard Toggle word wrap

    Note

    Il est également possible d’afficher les informations d’identification dans une sortie JSON en ajoutant l’argument -o json à la commande.

  3. Afin d’afficher l’état d’un identifiant de verre cassé, exécutez la commande suivante, en remplaçant &lt;break_glass_credential_id&gt; par l’identifiant d’identification du verre de rupture:

    $ rosa describe break-glass-credential <break_glass_credential_id> -c <cluster_name>
    Copy to Clipboard Toggle word wrap

    Exemple de sortie

    ID:                                    2a7jli9n4phe6c02ul7ti91djtv2o51d
    Username:                              test-user
    Expire at:                             Dec 28 2026 10:23:05 EDT
    Status:                                issued
    Copy to Clipboard Toggle word wrap

    Ce qui suit est une liste des valeurs possibles du champ État:

    • émis L’identifiant d’identification en verre cassé a été délivré et est prêt à être utilisé.
    • expiré Les informations d’identification en verre cassé ont expiré et ne peuvent plus être utilisées.
    • échec L’identifiant d’identification en verre cassé n’a pas réussi à créer. Dans ce cas, vous recevez un journal de service détaillant l’échec. Accès aux journaux de service pour Red Hat OpenShift Service sur les clusters AWS. Les étapes à suivre pour contacter Red Hat Support pour obtenir de l’aide sont disponibles.
    • l’identifiant de verre cassé est actuellement révoqué, ce qui signifie qu’il ne peut pas être utilisé.
    • les informations d’identification en verre cassé ont été révoquées et ne peuvent plus être utilisées.
  4. Afin de récupérer le kubeconfig, exécutez les commandes suivantes:

    • Créer un répertoire kubeconfigs:

      $ mkdir ~/kubeconfigs
      Copy to Clipboard Toggle word wrap
    • Exportez le fichier kubeconfig nouvellement généré, remplaçant &lt;cluster_name&gt; par le nom de votre cluster:

      $ export CLUSTER_NAME=<cluster_name> && export KUBECONFIG=~/kubeconfigs/break-glass-${CLUSTER_NAME}.kubeconfig
      Copy to Clipboard Toggle word wrap
    • Afficher le kubeconfig:

      $ rosa describe break-glass-credential <break_glass_credential_id> -c mycluster --kubeconfig
      Copy to Clipboard Toggle word wrap

      Exemple de sortie

      apiVersion: v1
      clusters:
      - cluster:
          server: <server_url>
        name: cluster
      contexts:
      - context:
          cluster: cluster
          namespace: default
          user: test-username
        name: admin
      current-context: admin
      kind: Config
      preferences: {}
      users:
      - name: test-user
        user:
          client-certificate-data: <client-certificate-data> 
      1
      
          client-key-data: <client-key-data> 
      2
      Copy to Clipboard Toggle word wrap

      1
      Le certificat client contient un certificat pour l’utilisateur signé par les autorités de certification Kubernetes (CA).
      2
      La clé client contient la clé qui a signé le certificat client.
  5. Facultatif: Pour enregistrer le kubeconfig, exécutez la commande suivante:

    $ rosa describe break-glass-credential <break_glass_credential_id> -c mycluster --kubeconfig > $KUBECONFIG
    Copy to Clipboard Toggle word wrap

Le nouveau kubeconfig à partir de l’identifiant de verre de rupture permet d’accéder temporairement à un ROSA avec le cluster HCP.

Conditions préalables

  • Accès à un ROSA avec cluster HCP avec authentification externe activée. Création d’un ROSA avec le cluster HCP qui utilise des fournisseurs d’authentification externes.
  • Les CLI oc et kubectl ont été installées.
  • Le nouveau kubeconfig a été configuré. En savoir plus, voir Créer un identifiant de verre cassé pour un ROSA avec cluster HCP.

Procédure

  1. Accédez aux détails du cluster:

    $ rosa describe break-glass-credential <break_glass_credential_id> -c <cluster_name>  --kubeconfig > $KUBECONFIG
    Copy to Clipboard Toggle word wrap
  2. Énumérez les nœuds du cluster:

    $ oc get nodes
    Copy to Clipboard Toggle word wrap

    Exemple de sortie

    NAME                        STATUS   ROLES   AGE   VERSION
    ip-10-0-0-27.ec2.internal   Ready    worker  8m    v1.28.7+f1b5f6c
    ip-10-0-0-67.ec2.internal   Ready    worker  9m    v1.28.7+f1b5f6c
    Copy to Clipboard Toggle word wrap

  3. Assurez-vous que vous avez les informations d’identification correctes:

    $ kubectl auth whoami
    Copy to Clipboard Toggle word wrap

    Exemple de sortie

    ATTRIBUTE    VALUE
    Username     system:customer-break-glass:test-user
    Groups       [system:masters system:authenticated]
    Copy to Clipboard Toggle word wrap

  4. Appliquer le ClusterRoleBinding pour les groupes définis dans le fournisseur OIDC externe. Le ClusterRoleBinding cartographie le groupe rosa-hcp-admins créé dans Microsoft Entra ID à un groupe de la ROSA avec le cluster HCP.

    $ oc apply -f - <<EOF
    apiVersion: rbac.authorization.k8s.io/v1
    kind: ClusterRoleBinding
    metadata:
      name: rosa-hcp-admins
    roleRef:
      apiGroup: rbac.authorization.k8s.io
      kind: ClusterRole
      name: cluster-admin
    subjects:
    - apiGroup: rbac.authorization.k8s.io
      kind: Group
      name: f715c264-ab90-45d5-8a29-2e91a609a895
    EOF
    Copy to Clipboard Toggle word wrap

    Exemple de sortie

    clusterrolebinding.rbac.authorization.k8s.io/rosa-hcp-admins created
    Copy to Clipboard Toggle word wrap

    Note

    Après l’application du cluster ClusterRoleBinding, la ROSA avec le cluster HCP est configurée, et la rosa CLI et la Red Hat Hybrid Cloud Console sont authentifiées via le fournisseur externe OpenID Connect (OIDC). Désormais, vous pouvez commencer à assigner des rôles et à déployer des applications sur le cluster.

En tout temps, vous pouvez révoquer l’accès aux informations d’identification de verre cassées que vous avez fournies à tout moment en utilisant la commande Break-glass-credentials de révoquation.

Conditions préalables

  • C’est vous qui avez créé un code d’identification en verre cassé.
  • C’est vous qui êtes le propriétaire du cluster.

Procédure

  • Annuler les informations d’identification de verre de rupture pour un ROSA avec le cluster HCP en exécutant la commande suivante.

    Important

    L’exécution de cette commande révoquera l’accès pour toutes les informations d’identification en verre cassées liées au cluster.

    $ rosa revoke break-glass-credentials -c <cluster_name> 
    1
    Copy to Clipboard Toggle word wrap
    1
    &lt;cluster_name&gt; par le nom de votre cluster.

    Exemple de sortie

    ? Are you sure you want to revoke all the break glass credentials on cluster 'my-cluster'?: Yes
    I: Successfully requested revocation for all break glass credentials from cluster 'my-cluster'
    Copy to Clipboard Toggle word wrap

La vérification

  • Le processus de révocation peut prendre plusieurs minutes. Il est possible de vérifier que les informations d’identification en verre cassées pour vos clusters ont été révoquées en exécutant l’une des commandes suivantes:

    • Énumérez toutes les informations d’identification en verre et vérifiez l’état de chacun:

      $ rosa list break-glass-credential -c <cluster_name>
      Copy to Clipboard Toggle word wrap

      Exemple de sortie

      ID                                USERNAME    STATUS
      2330dbs0n8m3chkkr25gkkcd8pnj3lk2  test-user   awaiting_revocation
      Copy to Clipboard Toggle word wrap

    • Il est également possible de vérifier l’état en vérifiant l’identification individuelle:

      $ rosa describe break-glass-credential <break_glass_credential_id> -c <cluster_name>
      Copy to Clipboard Toggle word wrap

      Exemple de sortie

      ID:                                    2330dbs0n8m3chkkr25gkkcd8pnj3lk2
      Username:                              test-user
      Expire at:                             Dec 28 2026 10:23:05 EDT
      Status:                                issued
      Revoked at:                            Dec 27 2026 15:30:33 EDT
      Copy to Clipboard Toggle word wrap

Effacer les fournisseurs d’authentification externes en utilisant le ROSA CLI.

Procédure

  1. Affichez votre fournisseur d’authentification externe sur votre cluster en exécutant la commande suivante:

    $ rosa list external-auth-provider -c <cluster_name>
    Copy to Clipboard Toggle word wrap

    Exemple de sortie

    NAME        ISSUER URL
    entra-test  https://login.microsoftonline.com/<group_id>/v2.0
    Copy to Clipboard Toggle word wrap

  2. Effacer le fournisseur d’authentification externe en exécutant la commande suivante:

    $ rosa delete external-auth-provider <name_of_provider> -c <cluster_name>
    Copy to Clipboard Toggle word wrap

    Exemple de sortie

    ? Are you sure you want to delete external authentication provider entra-test on cluster rosa-ext-test? Yes
    I: Successfully deleted external authentication provider 'entra-test' from cluster 'rosa-ext-test'
    Copy to Clipboard Toggle word wrap

La vérification

  1. Interrogez tous les fournisseurs d’authentification externes de votre cluster en exécutant la commande suivante:

    $ rosa list external-auth-provider -c <cluster_name>
    Copy to Clipboard Toggle word wrap

    Exemple de sortie

    E: there are no external authentication providers for this cluster
    Copy to Clipboard Toggle word wrap

Chapitre 7. Avec des clusters HCP sans plugin CNI

Lors de la création d’un Red Hat OpenShift Service sur AWS (ROSA), vous pouvez utiliser votre propre plugin Container Network Interface (CNI) avec un cluster de plans de contrôle hébergés (HCP). Il est possible de créer un ROSA avec le cluster HCP sans CNI et d’installer votre propre plugin CNI après la création de clusters.

Important

En ce qui concerne les clients qui choisissent d’utiliser leur propre CNI, la responsabilité du support du plugin CNI appartient au client en coordination avec le fournisseur CNI choisi.

Le plugin par défaut pour ROSA avec HCP est le plugin réseau OVN-Kubernetes. Ce plugin est le seul plugin Red Hat pris en charge CNI pour ROSA avec HCP.

Lorsque vous choisissez d’utiliser votre propre CNI pour ROSA avec des clusters HCP, il est fortement recommandé d’obtenir un support commercial du fournisseur de plugins avant de créer vos clusters. La prise en charge de Red Hat ne peut pas aider à résoudre les problèmes liés au CNI tels que la pod pour stocker le trafic pour les clients qui choisissent d’utiliser leur propre CNI. Le Red Hat fournit toujours un soutien pour toutes les questions non-CNI. Dans le cas où vous souhaitez une prise en charge liée au CNI de Red Hat, vous devez installer le cluster avec le plugin réseau OVN-Kubernetes par défaut. Consultez la matrice des responsabilités pour plus d’informations.

7.1. Créer un ROSA avec le cluster HCP sans plugin CNI

7.1.1. Conditions préalables

  • Assurez-vous que vous avez rempli les prérequis AWS.
  • Assurez-vous que vous disposez d’un cloud privé virtuel (VPC) configuré.

Avant d’utiliser le service Red Hat OpenShift sur AWS (ROSA) CLI (rosa) pour créer Red Hat OpenShift Service sur AWS (ROSA) avec des clusters de plans de contrôle hébergés (HCP), créez les rôles et les politiques nécessaires à l’échelle du compte, y compris les politiques d’opérateur.

Note

Les ROSA avec les clusters HCP nécessitent des rôles de compte et d’opérateur avec des stratégies gérées AWS jointes. Les politiques gérées par les clients ne sont pas prises en charge. En savoir plus sur les stratégies gérées par AWS pour ROSA avec les clusters HCP, consultez les stratégies gérées AWS pour les rôles de compte ROSA.

Conditions préalables

  • Avec HCP, 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.
  • En utilisant le ROSA CLI, vous vous êtes connecté à votre compte Red Hat.

Procédure

  1. Dans le cas où ils n’existent pas dans votre compte AWS, créez les rôles STS requis à l’échelle du compte et attachez les stratégies en exécutant la commande suivante:

    $ rosa create account-roles --hosted-cp
    Copy to Clipboard Toggle word wrap
  2. Facultatif: Définir votre préfixe en tant que variable environnementale en exécutant la commande suivante:

    $ export ACCOUNT_ROLES_PREFIX=<account_role_prefix>
    Copy to Clipboard Toggle word wrap
    • Afficher la valeur de la variable en exécutant la commande suivante:

      $ echo $ACCOUNT_ROLES_PREFIX
      Copy to Clipboard Toggle word wrap

      Exemple de sortie

      ManagedOpenShift
      Copy to Clipboard Toggle word wrap

Consultez les politiques IAM gérées par AWS pour ROSA, consultez les politiques IAM gérées par AWS pour ROSA.

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

7.1.4. Créer des rôles et des politiques de l’opérateur

Lorsque vous utilisez un ROSA avec le cluster HCP, vous devez créer les rôles IAM d’opérateur requis pour Red Hat OpenShift Service sur AWS (ROSA) avec des déploiements de plans de contrôle hébergés (HCP). Les opérateurs de cluster utilisent les rôles d’opérateur pour obtenir les autorisations temporaires requises pour effectuer des opérations de cluster, telles que la gestion du stockage back-end, les informations d’identification des fournisseurs de cloud et l’accès externe à un cluster.

Conditions préalables

  • Avec HCP, vous avez complété les prérequis AWS pour ROSA.
  • Le dernier service Red Hat OpenShift sur AWS ROSA CLI (rosa) est installé et configuré sur votre hôte d’installation.
  • Les rôles AWS à l’échelle du compte ont été créés.

Procédure

  1. Définissez le nom de votre préfixe sur une variable d’environnement en utilisant la commande suivante:

    $ export OPERATOR_ROLES_PREFIX=<prefix_name>
    Copy to Clipboard Toggle word wrap
  2. Afin de créer vos rôles d’opérateur, exécutez la commande suivante:

    $ rosa create operator-roles --hosted-cp --prefix=$OPERATOR_ROLES_PREFIX --oidc-config-id=$OIDC_ID --installer-role-arn arn:aws:iam::${AWS_ACCOUNT_ID}:role/${ACCOUNT_ROLES_PREFIX}-HCP-ROSA-Installer-Role
    Copy to Clipboard Toggle word wrap

    La ventilation suivante fournit des options pour la création de rôles d’opérateur.

    $ rosa create operator-roles --hosted-cp
    	--prefix=$OPERATOR_ROLES_PREFIX 
    1
    
    	--oidc-config-id=$OIDC_ID 
    2
    
    	--installer-role-arn arn:aws:iam::${AWS_ACCOUNT_ID}:role/${ACCOUNT_ROLES_PREFIX}-HCP-ROSA-Installer-Role 
    3
    Copy to Clipboard Toggle word wrap
    1
    Il faut fournir un préfixe lors de la création de ces rôles d’opérateur. Le fait de ne pas le faire produit une erreur. Consultez les ressources supplémentaires de cette section pour obtenir des informations sur le préfixe de l’opérateur.
    2
    Cette valeur est l’identifiant de configuration OIDC que vous avez créé pour votre ROSA avec le cluster HCP.
    3
    Cette valeur est le rôle d’installateur ARN que vous avez créé lorsque vous avez créé les rôles de compte ROSA.

    Il faut inclure le paramètre --hosted-cp pour créer les rôles corrects pour ROSA avec les clusters HCP. Cette commande renvoie les informations suivantes.

    Exemple de sortie

    ? Role creation mode: auto
    ? Operator roles prefix: <pre-filled_prefix> 
    1
    
    ? OIDC Configuration ID: 23soa2bgvpek9kmes9s7os0a39i13qm4 | https://dvbwgdztaeq9o.cloudfront.net/23soa2bgvpek9kmes9s7os0a39i13qm4 
    2
    
    ? Create hosted control plane operator roles: Yes
    W: More than one Installer role found
    ? Installer role ARN: arn:aws:iam::4540112244:role/<prefix>-HCP-ROSA-Installer-Role
    ? Permissions boundary ARN (optional):
    I: Reusable OIDC Configuration detected. Validating trusted relationships to operator roles:
    I: Creating roles using 'arn:aws:iam::4540112244:user/<userName>'
    I: Created role '<prefix>-openshift-cluster-csi-drivers-ebs-cloud-credentials' with ARN 'arn:aws:iam::4540112244:role/<prefix>-openshift-cluster-csi-drivers-ebs-cloud-credentials'
    I: Created role '<prefix>-openshift-cloud-network-config-controller-cloud-credenti' with ARN 'arn:aws:iam::4540112244:role/<prefix>-openshift-cloud-network-config-controller-cloud-credenti'
    I: Created role '<prefix>-kube-system-kube-controller-manager' with ARN 'arn:aws:iam::4540112244:role/<prefix>-kube-system-kube-controller-manager'
    I: Created role '<prefix>-kube-system-capa-controller-manager' with ARN 'arn:aws:iam::4540112244:role/<prefix>-kube-system-capa-controller-manager'
    I: Created role '<prefix>-kube-system-control-plane-operator' with ARN 'arn:aws:iam::4540112244:role/<prefix>-kube-system-control-plane-operator'
    I: Created role '<prefix>-kube-system-kms-provider' with ARN 'arn:aws:iam::4540112244:role/<prefix>-kube-system-kms-provider'
    I: Created role '<prefix>-openshift-image-registry-installer-cloud-credentials' with ARN 'arn:aws:iam::4540112244:role/<prefix>-openshift-image-registry-installer-cloud-credentials'
    I: Created role '<prefix>-openshift-ingress-operator-cloud-credentials' with ARN 'arn:aws:iam::4540112244:role/<prefix>-openshift-ingress-operator-cloud-credentials'
    I: To create a cluster with these roles, run the following command:
    	rosa create cluster --sts --oidc-config-id 23soa2bgvpek9kmes9s7os0a39i13qm4 --operator-roles-prefix <prefix> --hosted-cp
    Copy to Clipboard Toggle word wrap

    1
    Ce champ est prérempli avec le préfixe que vous définissez dans la commande initiale de création.
    2
    Ce champ vous oblige à sélectionner une configuration OIDC que vous avez créée pour votre ROSA avec le cluster HCP.

    Les rôles d’opérateur sont maintenant créés et prêts à être utilisés pour créer votre ROSA avec le cluster HCP.

La vérification

  • Il est possible de répertorier les rôles d’opérateur associés à votre compte ROSA. Exécutez la commande suivante:

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

    Exemple de sortie

    I: Fetching operator roles
    ROLE PREFIX  AMOUNT IN BUNDLE
    <prefix>      8
    ? Would you like to detail a specific prefix Yes 
    1
    
    ? Operator Role Prefix: <prefix>
    ROLE NAME                                                         ROLE ARN                                                                                         VERSION  MANAGED
    <prefix>-kube-system-capa-controller-manager                       arn:aws:iam::4540112244:role/<prefix>-kube-system-capa-controller-manager                       4.13     No
    <prefix>-kube-system-control-plane-operator                        arn:aws:iam::4540112244:role/<prefix>-kube-system-control-plane-operator                        4.13     No
    <prefix>-kube-system-kms-provider                                  arn:aws:iam::4540112244:role/<prefix>-kube-system-kms-provider                                  4.13     No
    <prefix>-kube-system-kube-controller-manager                       arn:aws:iam::4540112244:role/<prefix>-kube-system-kube-controller-manager                       4.13     No
    <prefix>-openshift-cloud-network-config-controller-cloud-credenti  arn:aws:iam::4540112244:role/<prefix>-openshift-cloud-network-config-controller-cloud-credenti  4.13     No
    <prefix>-openshift-cluster-csi-drivers-ebs-cloud-credentials       arn:aws:iam::4540112244:role/<prefix>-openshift-cluster-csi-drivers-ebs-cloud-credentials       4.13     No
    <prefix>-openshift-image-registry-installer-cloud-credentials      arn:aws:iam::4540112244:role/<prefix>-openshift-image-registry-installer-cloud-credentials      4.13     No
    <prefix>-openshift-ingress-operator-cloud-credentials              arn:aws:iam::4540112244:role/<prefix>-openshift-ingress-operator-cloud-credentials              4.13     No
    Copy to Clipboard Toggle word wrap

    1
    Après l’exécution de la commande, il affiche tous les préfixes associés à votre compte AWS et note combien de rôles sont associés à ce préfixe. Lorsque vous avez besoin de voir tous ces rôles et leurs détails, entrez "Oui" sur l’invite détaillée pour avoir ces rôles listés avec des détails.

7.2. Créer le cluster

Lorsque vous utilisez le Red Hat OpenShift Service sur l’interface de ligne de commande AWS (ROSA), rosa, pour créer un cluster, vous pouvez ajouter un drapeau --no-cni en option pour créer un cluster sans plugin CNI.

Conditions préalables

  • Avec HCP, 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.
  • C’est vous qui avez créé une configuration OIDC.
  • Le rôle de service AWS Elastic Load Balancing (ELB) existe dans votre compte AWS.

Procédure

  1. Créez votre ROSA avec le cluster HCP avec l’une des commandes suivantes.

    Note

    Lors de la création d’un ROSA avec le cluster HCP, la machine par défaut Classless Inter-Domain Routing (CIDR) est 10.0.0.0/16. Dans le cas où cela ne correspond pas à la plage CIDR pour vos sous-réseaux VPC, ajoutez --machine-cidr &lt;address_block&gt; aux commandes suivantes. Afin d’en savoir plus sur les gammes CIDR par défaut pour Red Hat OpenShift Service sur AWS, consultez les définitions de la gamme CIDR.

    • Créez un cluster avec un seul pool de machines initial, une API accessible au public, Ingress disponible au public et aucun plugin CNI en exécutant la commande suivante:

      $ rosa create cluster --cluster-name=<cluster_name> \
          --sts --mode=auto --hosted-cp --operator-roles-prefix <operator-role-prefix> \
          --oidc-config-id <ID-of-OIDC-configuration> --subnet-ids=<public-subnet-id>,<private-subnet-id> --no-cni
      Copy to Clipboard Toggle word wrap
    • Créez un cluster avec un seul pool de machines initial, une API disponible en privé, Ingress disponible en privé et aucun plugin CNI en exécutant la commande suivante:

      $ rosa create cluster --private --cluster-name=<cluster_name> \
          --sts --mode=auto --hosted-cp --subnet-ids=<private-subnet-id> --no-cni
      Copy to Clipboard Toggle word wrap
    • Lorsque vous utilisez les variables OIDC_ID, SUBNET_IDS et OPERATOR_ROLES_PREFIX pour préparer votre environnement, vous pouvez continuer à utiliser ces variables lors de la création de votre cluster sans plugin CNI. À titre d’exemple, exécutez la commande suivante:

      $ rosa create cluster --hosted-cp --subnet-ids=$SUBNET_IDS --oidc-config-id=$OIDC_ID --cluster-name=<cluster_name> --operator-roles-prefix=$OPERATOR_ROLES_PREFIX --no-cni
      Copy to Clipboard Toggle word wrap
  2. Consultez l’état de votre cluster en exécutant la commande suivante:

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

    Lorsque vous vous connectez pour la première fois au cluster après avoir atteint le statut prêt, les nœuds seront toujours dans l’état non prêt jusqu’à ce que vous installiez votre propre plugin CNI. Après l’installation du CNI, les nœuds changeront pour se préparer.

    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:

    • 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 plus de 10 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.

  3. Faites le suivi de l’avancement de la création de clusters en regardant le Red Hat OpenShift Service sur les journaux des programmes d’installation AWS. Afin de vérifier les journaux, exécutez la commande suivante:

    $ rosa logs install --cluster=<cluster_name> --watch 
    1
    Copy to Clipboard Toggle word wrap
    1
    Facultatif: Pour regarder les nouveaux messages de journal au fur et à mesure que l’installation progresse, utilisez l’argument --watch.

7.2.1. Comportement attendu pour les clusters sans plugin CNI

Bien que ROSA avec l’installation de cluster HCP soit complète, le cluster ne peut pas fonctionner sans un plugin CNI. Comme les nœuds ne sont pas prêts, les charges de travail ne peuvent pas être déployées. Ainsi, le Red Hat OpenShift Service sur la console web AWS cluster n’est pas disponible, vous devez donc utiliser OpenShift CLI (oc) pour vous connecter au cluster. En outre, d’autres composants OpenShift tels que le contrôleur Ingress basé sur HAProxy, le registre d’images et la pile de surveillance basée sur promesseheus ne sont pas en cours d’exécution. Ce comportement est attendu jusqu’à ce que vous installiez un fournisseur CNI.

7.3. Les prochaines étapes

  • Installez votre plugin CNI. Les nœuds passeront alors de l’état non prêt à préparer.
  • Accédez à votre cluster ROSA avec la documentation du cluster ROSA.

Chapitre 8. La suppression d’un ROSA avec le cluster HCP

Dans le cas où vous souhaitez supprimer un Red Hat OpenShift Service sur AWS (ROSA) avec un cluster de plans de contrôle hébergés (HCP), vous pouvez utiliser le Red Hat OpenShift Cluster Manager ou l’interface de ligne de commande ROSA (CLI) (rosa). 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.

Il est possible de supprimer un ROSA avec le cluster HCP en utilisant l’interface de ligne de commande 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. 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.

Conditions préalables

  • « vous avez installé un ROSA avec le cluster HCP.
  • L’installation et la configuration de la dernière ROSA CLI (rosa) sur votre hôte d’installation.

Procédure

  1. Accédez à l’ID du cluster, aux 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 en exécutant la commande suivante:

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

    Exemple de sortie

    Name:                       test_cluster
    Domain Prefix:              test_cluster
    Display Name:               test_cluster
    ID:                         <cluster_id> 
    1
    
    External ID:                <external_id>
    Control Plane:              ROSA Service Hosted
    OpenShift Version:          4.18.0
    Channel Group:              stable
    DNS:                        test_cluster.l3cn.p3.openshiftapps.com
    AWS Account:                <AWS_id>
    AWS Billing Account:        <AWS_id>
    API URL:                    https://api.test_cluster.l3cn.p3.openshiftapps.com:443
    Console URL:
    Region:                     us-east-1
    Availability:
     - Control Plane:           MultiAZ
     - Data Plane:              SingleAZ
    
    Nodes:
     - Compute (desired):       2
     - Compute (current):       0
    Network:
     - Type:                    OVNKubernetes
     - Service CIDR:            172.30.0.0/16
     - Machine CIDR:            10.0.0.0/16
     - Pod CIDR:                10.128.0.0/14
     - Host Prefix:             /23
     - Subnets:                 <subnet_ids>
    EC2 Metadata Http Tokens:   optional
    Role (STS) ARN:             arn:aws:iam::<AWS_id>:role/test_cluster-HCP-ROSA-Installer-Role
    Support Role ARN:           arn:aws:iam::<AWS_id>:role/test_cluster-HCP-ROSA-Support-Role
    Instance IAM Roles:
     - Worker:                  arn:aws:iam::<AWS_id>:role/test_cluster-HCP-ROSA-Worker-Role
    Operator IAM Roles: 
    2
    
     - arn:aws:iam::<AWS_id>:role/test_cluster-openshift-cloud-network-config-controller-cloud-crede
     - arn:aws:iam::<AWS_id>:role/test_cluster-openshift-image-registry-installer-cloud-credentials
     - arn:aws:iam::<AWS_id>:role/test_cluster-openshift-ingress-operator-cloud-credentials
     - arn:aws:iam::<AWS_id>:role/test_cluster-kube-system-kube-controller-manager
     - arn:aws:iam::<AWS_id>:role/test_cluster-kube-system-capa-controller-manager
     - arn:aws:iam::<AWS_id>:role/test_cluster-kube-system-control-plane-operator
     - arn:aws:iam::<AWS_id>:role/hcpcluster-kube-system-kms-provider
     - arn:aws:iam::<AWS_id>:role/test_cluster-openshift-cluster-csi-drivers-ebs-cloud-credentials
    Managed Policies:           Yes
    State:                      ready
    Private:                    No
    Created:                    Apr 16 2024 20:32:06 UTC
    User Workload Monitoring:   Enabled
    Details Page:               https://console.redhat.com/openshift/details/s/<cluster_id>
    OIDC Endpoint URL:          https://oidc.op1.openshiftapps.com/<cluster_id> (Managed) 
    3
    
    Audit Log Forwarding:       Disabled
    External Authentication:    Disabled
    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

    Après la suppression du cluster, vous avez besoin de l’ID de cluster pour supprimer les ressources STS spécifiques au cluster en utilisant le ROSA CLI.

  2. Effacer le cluster en utilisant soit le gestionnaire de cluster OpenShift ou le ROSA CLI (rosa):

    • De supprimer le cluster en utilisant OpenShift Cluster Manager:

      1. Accédez au gestionnaire de cluster OpenShift.
      2. Cliquez sur le menu Options à côté de votre cluster et sélectionnez Supprimer le cluster.
      3. Entrez le nom de votre cluster dans l’invite et cliquez sur Supprimer.
    • De supprimer le cluster à l’aide du ROSA CLI:

      1. Exécutez la commande suivante, 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.

  3. Supprimez les rôles IAM d’opérateur spécifiques au cluster en exécutant la commande suivante:

    $ rosa delete operator-roles --prefix <operator_role_prefix>
    Copy to Clipboard Toggle word wrap
  4. Effacer le fournisseur OIDC en exécutant la commande suivante:

    $ rosa delete oidc-provider --oidc-config-id <oidc_config_id>
    Copy to Clipboard Toggle word wrap

Résolution de problèmes

  • Lorsque le cluster ne peut pas être supprimé en raison des rôles IAM manquants, voir Réparation d’un cluster qui ne peut pas être supprimé.
  • 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 les déploiements HCP, ainsi que les politiques d’opérateur à l’échelle du compte. Les rôles et les politiques AWS Identity and Access Management (IAM) à l’échelle du compte ne peuvent être supprimés qu’après la suppression de tous les 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 services Red Hat OpenShift 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  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

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

  2. Effacer les politiques en ligne à l’échelle du compte et de l’opérateur:

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

    2. 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 IAM pourraient être utilisées par d’autres 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.

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