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.
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 :
Catégorie | Privilè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
-
Dans la perspective Administrator de la console web, naviguez vers Workloads
Secrets. Dans le tableau de la page Secrets, recherchez le secret racine de votre fournisseur de cloud.
Plate-forme Nom secret AWS
aws-creds
L'azur
azure-credentials
PCG
gcp-credentials
RHOSP
openstack-credentials
RHV
ovirt-credentials
VMware vSphere
vsphere-creds
- Cliquez sur le menu Options sur la même ligne que le secret et sélectionnez Edit Secret.
- 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.
- Mettez à jour le texte du ou des champs Value avec les nouvelles informations d'authentification de votre fournisseur de cloud, puis cliquez sur Save.
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.
NoteSi 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é :
-
Dans la perspective Administrator de la console web, naviguez vers Workloads
Secrets. - 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.