19.2. Utilisation du mode menthe
Le mode Mint est pris en charge pour Amazon Web Services (AWS) et Google Cloud Platform (GCP).
Le mode Mint est le mode par défaut sur les plateformes pour lesquelles il est pris en charge. Dans ce mode, le CCO (Cloud Credential Operator) utilise l'identifiant cloud de niveau administrateur fourni pour créer de nouveaux identifiants pour les composants du cluster avec uniquement les autorisations spécifiques requises.
Si l'identifiant n'est pas supprimé après l'installation, il est stocké et utilisé par le CCO pour traiter les CR CredentialsRequest
pour les composants du cluster et créer de nouveaux identifiants pour chacun d'entre eux avec uniquement les autorisations spécifiques requises. Le rapprochement continu des informations d'identification du nuage en mode "mint" permet d'effectuer des actions qui nécessitent des informations d'identification ou des autorisations supplémentaires, telles que la mise à niveau.
Le mode Mint stocke les informations d'identification au niveau de l'administrateur dans l'espace de noms du cluster kube-system
. Si cette approche ne répond pas aux exigences de sécurité de votre organisation, consultez Alternatives to storing administrator-level secrets in the kube-system project pour AWS ou GCP.
19.2.1. Exigences en matière de permissions pour le mode Mint
Lorsque vous utilisez l'OCC en mode menthe, 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 ne sont pas suffisantes pour le mode mint, le CCO ne peut pas créer d'utilisateur IAM.
19.2.1.1. Autorisations d'Amazon Web Services (AWS)
L'identifiant que vous fournissez pour le mode menthe dans AWS doit avoir les permissions suivantes :
-
iam:CreateAccessKey
-
iam:CreateUser
-
iam:DeleteAccessKey
-
iam:DeleteUser
-
iam:DeleteUserPolicy
-
iam:GetUser
-
iam:GetUserPolicy
-
iam:ListAccessKeys
-
iam:PutUserPolicy
-
iam:TagUser
-
iam:SimulatePrincipalPolicy
19.2.1.2. Autorisations pour Google Cloud Platform (GCP)
L'identifiant que vous fournissez pour le mode menthe dans GCP doit avoir les permissions suivantes :
-
resourcemanager.projects.get
-
serviceusage.services.list
-
iam.serviceAccountKeys.create
-
iam.serviceAccountKeys.delete
-
iam.serviceAccounts.create
-
iam.serviceAccounts.delete
-
iam.serviceAccounts.get
-
iam.roles.get
-
resourcemanager.projects.getIamPolicy
-
resourcemanager.projects.setIamPolicy
19.2.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 de Google Cloud Platform (GCP)
apiVersion: v1 kind: Secret metadata: namespace: kube-system name: gcp-credentials stringData: service_account.json: <base64-encoded_service_account>
19.2.3. Mode Mint avec suppression ou rotation des informations d'identification au niveau de l'administrateur
Actuellement, ce mode n'est pris en charge que sur AWS et GCP.
Dans ce mode, un utilisateur installe OpenShift Container Platform avec un credential de niveau administrateur comme dans le mode normal mint. Cependant, ce processus supprime le secret d'accès de niveau administrateur du cluster après l'installation.
L'administrateur peut demander au Cloud Credential Operator de faire sa propre demande d'autorisation en lecture seule, ce qui lui permet de vérifier si tous les objets CredentialsRequest
ont les autorisations requises. L'autorisation au niveau de l'administrateur n'est donc pas nécessaire, à moins que quelque chose doive être modifié. Une fois que le justificatif d'identité associé est supprimé, il peut être supprimé ou désactivé sur le nuage sous-jacent, si on le souhaite.
Avant une mise à niveau sans z-stream, vous devez rétablir le secret d'authentification avec l'authentification de niveau administrateur. Si l'identifiant n'est pas présent, la mise à niveau risque d'être bloquée.
Les informations d'identification au niveau de l'administrateur ne sont pas stockées de manière permanente dans le cluster.
En suivant ces étapes, il est toujours nécessaire d'avoir des informations d'identification de niveau administrateur dans le cluster pendant de brèves périodes. Il faut également réinstaurer manuellement le secret avec les informations d'identification de niveau administrateur pour chaque mise à niveau.
19.2.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 menthe, Amazon Web Services (AWS) et Google Cloud Platform (GCP) 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
PCG
gcp-credentials
- 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.
Supprimer chaque secret de composant référencé par les objets individuels
CredentialsRequest
.-
Connectez-vous au CLI de OpenShift Container Platform en tant qu'utilisateur ayant le rôle
cluster-admin
. Obtenir les noms et les espaces de noms de tous les secrets de composants référencés :
$ oc -n openshift-cloud-credential-operator get CredentialsRequest \ -o json | jq -r '.items[] | select (.spec.providerSpec.kind=="<provider_spec>") | .spec.secretRef'
où
<provider_spec>
est la valeur correspondante pour votre fournisseur de services en nuage :-
AWS :
AWSProviderSpec
-
GCP :
GCPProviderSpec
Exemple partiel de sortie pour AWS
{ "name": "ebs-cloud-credentials", "namespace": "openshift-cluster-csi-drivers" } { "name": "cloud-credential-operator-iam-ro-creds", "namespace": "openshift-cloud-credential-operator" }
-
AWS :
Supprimer chacun des secrets des composants référencés :
$ oc delete secret <secret_name> \1 -n <secret_namespace> 2
Exemple de suppression d'un secret AWS
$ oc delete secret ebs-cloud-credentials -n openshift-cluster-csi-drivers
Il n'est pas nécessaire de supprimer manuellement les informations d'identification à partir de la console du fournisseur. En supprimant les secrets des composants référencés, le CCO supprimera les informations d'identification existantes de la plateforme et en créera de nouvelles.
-
Connectez-vous au CLI de OpenShift Container Platform en tant qu'utilisateur ayant le rôle
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é.
19.2.3.2. Suppression des informations d'identification du fournisseur de services en nuage
Après avoir installé un cluster OpenShift Container Platform avec le Cloud Credential Operator (CCO) en mode mineur, vous pouvez supprimer le secret d'authentification de niveau administrateur de l'espace de noms kube-system
dans le cluster. Le justificatif d'identité de niveau administrateur n'est requis que pour les modifications nécessitant des autorisations élevées, telles que les mises à niveau.
Avant une mise à niveau sans z-stream, vous devez rétablir le secret d'authentification avec l'authentification de niveau administrateur. Si l'identifiant n'est pas présent, la mise à niveau risque d'être bloquée.
Conditions préalables
- Votre cluster est installé sur une plateforme qui prend en charge la suppression des informations d'identification du nuage à partir du CCO. Les plateformes prises en charge sont AWS et GCP.
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
PCG
gcp-credentials
- Cliquez sur le menu Options sur la même ligne que le secret et sélectionnez Delete Secret.