19.3. Utilisation du mode passthrough

Le mode Passthrough est pris en charge pour Amazon Web Services (AWS), Microsoft Azure, Google Cloud Platform (GCP), Red Hat OpenStack Platform (RHOSP), Red Hat Virtualization (RHV) et VMware vSphere.

En mode passthrough, le Cloud Credential Operator (CCO) transmet le justificatif d'identité cloud fourni aux composants qui demandent des justificatifs d'identité cloud. L'identifiant doit être autorisé à effectuer l'installation et les opérations requises par les composants du cluster, mais il ne doit pas être en mesure de créer de nouveaux identifiants. Le CCO ne tente pas de créer d'autres informations d'identification à portée limitée en mode passthrough.

Note

Le mode manuel est la seule configuration CCO prise en charge pour Microsoft Azure Stack Hub.

19.3.1. Exigences en matière de permissions pour le mode Passthrough

Lorsque vous utilisez le CCO en mode passthrough, assurez-vous que les informations d'identification que vous fournissez répondent aux exigences du nuage sur lequel vous exécutez ou installez OpenShift Container Platform. Si les informations d'identification fournies par le CCO à un composant qui crée un CR CredentialsRequest ne sont pas suffisantes, ce composant signalera une erreur lorsqu'il tentera d'appeler une API pour laquelle il ne dispose pas d'autorisations.

19.3.1.1. Autorisations d'Amazon Web Services (AWS)

L'identifiant que vous fournissez pour le mode passthrough dans AWS doit avoir toutes les autorisations requises pour tous les CR CredentialsRequest qui sont requis par la version d'OpenShift Container Platform que vous exécutez ou installez.

Pour trouver les CR CredentialsRequest nécessaires, voir Création manuelle d'IAM pour AWS.

19.3.1.2. Permissions Microsoft Azure

L'identifiant que vous fournissez pour le mode passthrough dans Azure doit avoir toutes les permissions requises pour tous les CR CredentialsRequest requis par la version d'OpenShift Container Platform que vous exécutez ou installez.

Pour trouver les CR CredentialsRequest nécessaires, voir Création manuelle d'IAM pour Azure.

19.3.1.3. Autorisations pour Google Cloud Platform (GCP)

L'identifiant que vous fournissez pour le mode passthrough dans GCP doit avoir toutes les autorisations requises pour tous les CR CredentialsRequest qui sont requis par la version d'OpenShift Container Platform que vous exécutez ou installez.

Pour trouver les CR CredentialsRequest nécessaires, voir Création manuelle d'IAM pour GCP.

19.3.1.4. Permissions de Red Hat OpenStack Platform (RHOSP)

Pour installer un cluster OpenShift Container Platform sur RHOSP, le CCO a besoin d'un identifiant avec les permissions d'un rôle d'utilisateur member.

19.3.1.5. Permissions de Red Hat Virtualization (RHV)

Pour installer un cluster OpenShift Container Platform sur RHV, le CCO a besoin d'un identifiant avec les privilèges suivants :

  • DiskOperator
  • DiskCreator
  • UserTemplateBasedVm
  • TemplateOwner
  • TemplateCreator
  • ClusterAdmin sur le cluster spécifique ciblé pour le déploiement d'OpenShift Container Platform

19.3.1.6. Permissions VMware vSphere

Pour installer un cluster OpenShift Container Platform sur VMware vSphere, le CCO a besoin d'un identifiant avec les privilèges vSphere suivants :

Tableau 19.2. Privilèges vSphere requis

CatégoriePrivilèges

Magasin de données

Allocate space

Dossier

Create folder, Delete folder

tagging vSphere

Tous les privilèges

Réseau

Assign network

Ressources

Assign virtual machine to resource pool

Stockage en fonction du profil

Tous les privilèges

vApp

Tous les privilèges

Machine virtuelle

Tous les privilèges

19.3.2. Informations d'identification de l'administrateur Format du secret de la racine

Par convention, chaque fournisseur d'informatique en nuage utilise un secret racine d'identification dans l'espace de noms kube-system, qui est ensuite utilisé pour satisfaire toutes les demandes d'identification et créer leurs secrets respectifs. Cela se fait soit en créant de nouvelles informations d'identification avec mint mode, soit en copiant le secret racine des informations d'identification avec passthrough mode.

Le format du secret varie selon le nuage et est également utilisé pour chaque secret CredentialsRequest.

Format secret d'Amazon Web Services (AWS)

apiVersion: v1
kind: Secret
metadata:
  namespace: kube-system
  name: aws-creds
stringData:
  aws_access_key_id: <base64-encoded_access_key_id>
  aws_secret_access_key: <base64-encoded_secret_access_key>

Format secret Microsoft Azure

apiVersion: v1
kind: Secret
metadata:
  namespace: kube-system
  name: azure-credentials
stringData:
  azure_subscription_id: <base64-encoded_subscription_id>
  azure_client_id: <base64-encoded_client_id>
  azure_client_secret: <base64-encoded_client_secret>
  azure_tenant_id: <base64-encoded_tenant_id>
  azure_resource_prefix: <base64-encoded_resource_prefix>
  azure_resourcegroup: <base64-encoded_resource_group>
  azure_region: <base64-encoded_region>

Sur Microsoft Azure, le format du secret d'identification comprend deux propriétés qui doivent contenir l'identifiant d'infrastructure du cluster, généré de manière aléatoire pour chaque installation de cluster. Cette valeur peut être trouvée après l'exécution de la création de manifestes :

$ cat .openshift_install_state.json | jq '."*installconfig.ClusterID".InfraID' -r

Exemple de sortie

mycluster-2mpcn

Cette valeur sera utilisée dans les données secrètes comme suit :

azure_resource_prefix: mycluster-2mpcn
azure_resourcegroup: mycluster-2mpcn-rg

Format secret de Google Cloud Platform (GCP)

apiVersion: v1
kind: Secret
metadata:
  namespace: kube-system
  name: gcp-credentials
stringData:
  service_account.json: <base64-encoded_service_account>

Format secret de la plateforme Red Hat OpenStack (RHOSP)

apiVersion: v1
kind: Secret
metadata:
  namespace: kube-system
  name: openstack-credentials
data:
  clouds.yaml: <base64-encoded_cloud_creds>
  clouds.conf: <base64-encoded_cloud_creds_init>

Format secret de Red Hat Virtualization (RHV)

apiVersion: v1
kind: Secret
metadata:
  namespace: kube-system
  name: ovirt-credentials
data:
  ovirt_url: <base64-encoded_url>
  ovirt_username: <base64-encoded_username>
  ovirt_password: <base64-encoded_password>
  ovirt_insecure: <base64-encoded_insecure>
  ovirt_ca_bundle: <base64-encoded_ca_bundle>

Format secret VMware vSphere

apiVersion: v1
kind: Secret
metadata:
  namespace: kube-system
  name: vsphere-creds
data:
 vsphere.openshift.example.com.username: <base64-encoded_username>
 vsphere.openshift.example.com.password: <base64-encoded_password>

19.3.3. Gestion des informations d'identification en mode "Passthrough

Si les CR de CredentialsRequest changent au fil du temps lors de la mise à niveau du cluster, vous devez mettre à jour manuellement les informations d'identification du mode passthrough pour répondre aux exigences. Pour éviter les problèmes d'informations d'identification lors d'une mise à niveau, vérifiez les CR CredentialsRequest dans l'image de la nouvelle version d'OpenShift Container Platform avant de procéder à la mise à niveau. Pour localiser les CR CredentialsRequest nécessaires pour votre fournisseur de cloud, voir Manually creating IAM pour AWS, Azure ou GCP.

19.3.3.1. Rotation manuelle des informations d'identification des fournisseurs de services en nuage

Si les informations d'identification de votre fournisseur de cloud sont modifiées pour une raison quelconque, vous devez mettre à jour manuellement le secret utilisé par le CCO (Cloud Credential Operator) pour gérer les informations d'identification du fournisseur de cloud.

Le processus de rotation des informations d'identification du nuage dépend du mode utilisé par l'OCC. Après avoir effectué la rotation des informations d'identification pour un cluster utilisant le mode menthe, vous devez supprimer manuellement les informations d'identification du composant qui ont été créées par l'information d'identification supprimée.

Conditions préalables

  • Votre cluster est installé sur une plateforme qui prend en charge la rotation manuelle des identifiants cloud avec le mode CCO que vous utilisez :

    • Pour le mode passthrough, Amazon Web Services (AWS), Microsoft Azure, Google Cloud Platform (GCP), Red Hat OpenStack Platform (RHOSP), Red Hat Virtualization (RHV) et VMware vSphere sont pris en charge.
  • Vous avez modifié les informations d'identification utilisées pour l'interface avec votre fournisseur de services en nuage.
  • Les nouvelles informations d'identification ont des autorisations suffisantes pour le mode que CCO est configuré pour utiliser dans votre cluster.

Procédure

  1. Dans la perspective Administrator de la console web, naviguez vers WorkloadsSecrets.
  2. Dans le tableau de la page Secrets, recherchez le secret racine de votre fournisseur de cloud.

    Plate-formeNom secret

    AWS

    aws-creds

    L'azur

    azure-credentials

    PCG

    gcp-credentials

    RHOSP

    openstack-credentials

    RHV

    ovirt-credentials

    VMware vSphere

    vsphere-creds

  3. Cliquez sur le menu Options kebab sur la même ligne que le secret et sélectionnez Edit Secret.
  4. Enregistrez le contenu du ou des champs Value. Vous pouvez utiliser ces informations pour vérifier que la valeur est différente après la mise à jour des informations d'identification.
  5. Mettez à jour le texte du ou des champs Value avec les nouvelles informations d'authentification de votre fournisseur de cloud, puis cliquez sur Save.
  6. Si vous mettez à jour les informations d'identification pour un cluster vSphere qui n'a pas activé vSphere CSI Driver Operator, vous devez forcer un déploiement du gestionnaire de contrôleur Kubernetes pour appliquer les informations d'identification mises à jour.

    Note

    Si le vSphere CSI Driver Operator est activé, cette étape n'est pas nécessaire.

    Pour appliquer les informations d'identification vSphere mises à jour, connectez-vous au CLI de OpenShift Container Platform en tant qu'utilisateur ayant le rôle cluster-admin et exécutez la commande suivante :

    $ oc patch kubecontrollermanager cluster \
      -p='{"spec": {"forceRedeploymentReason": "recovery-'"$( date )"'"}}' \
      --type=merge

    Pendant que les informations d'identification sont diffusées, l'état de l'opérateur du contrôleur Kubernetes Controller Manager est indiqué à l'adresse Progressing=true. Pour afficher l'état, exécutez la commande suivante :

    $ oc get co kube-controller-manager

Vérification

Pour vérifier que les informations d'identification ont changé :

  1. Dans la perspective Administrator de la console web, naviguez vers WorkloadsSecrets.
  2. Vérifiez que le contenu du ou des champs Value a été modifié.

Ressources complémentaires

19.3.4. Réduire les autorisations après l'installation

Lorsque vous utilisez le mode "passthrough", chaque composant dispose des mêmes autorisations que celles utilisées par tous les autres composants. Si vous ne réduisez pas les autorisations après l'installation, tous les composants disposent des autorisations générales nécessaires à l'exécution du programme d'installation.

Après l'installation, vous pouvez réduire les autorisations sur votre justificatif d'identité à celles qui sont nécessaires pour exécuter le cluster, comme défini par les CR CredentialsRequest dans l'image de version pour la version d'OpenShift Container Platform que vous utilisez.

Pour trouver les CR CredentialsRequest nécessaires pour AWS, Azure ou GCP et savoir comment modifier les autorisations utilisées par le CCO, voir Manually creating IAM pour AWS, Azure ou GCP.

19.3.5. Ressources complémentaires