Augmenter les limites des règles de conservation

Dans Google Distributed Cloud (GDC) sous air gap, une contrainte empêche les utilisateurs de dépasser une durée de conservation maximale définie GDCHRestrictAttributeRange. Cette contrainte est appliquée aux ressources personnalisées (CR) de bucket dans les clusters d'administrateur de l'organisation par le contrôleur de règles d'Anthos Config Management. Cela signifie que seuls les comptes de service système, les utilisateurs système et les utilisateurs du groupe system:masters peuvent supprimer les finaliseurs par défaut. La procédure décrite explique comment augmenter les limites de la règle de conservation sur les CR de bucket.

Prérequis

• Outils : CLI kubectl
• Accès requis : Générer le fichier KUBECONFIG pour le cluster
• Accès requis : Obtenir le rôle Policy Admin dans le cluster

Générez le fichier KUBECONFIG pour le cluster.

Les commandes Kubectl nécessitent un fichier KUBECONFIG valide pour fonctionner. Ce processus fournit des instructions détaillées pour générer le fichier KUBECONFIG pour les clusters d'administrateur racine, d'administrateur d'organisation, de système d'organisation et d'utilisateur.

Prérequis

Avant de continuer, assurez-vous de disposer des éléments suivants :

• gdcloud est installé.

• La CLI kubectl est installée.

• Un certificat signé par une autorité de certification (CA) installé sur le poste de travail.

• Nom de l'organisation.

• URL racine (GDC). L'administrateur informatique de l'OC doit vous fournir l'URL racine.

Définir les variables d'environnement requises

Suivez les instructions de cette section pour générer le fichier KUBECONFIG pour org-admin, system ou tout autre cluster utilisateur.

1. Exécutez la commande suivante pour définir la variable d'environnement ORG à utiliser ultérieurement dans le terminal actuel. ORG est le nom de votre organisation.

   export ORG=
   

2. Exécutez la commande suivante pour définir la variable d'environnement CONSOLE_URL à utiliser ultérieurement dans le terminal actuel :

   export CONSOLE_URL=https://console.${ORG:?}.$GDC_URL/
   gdcloud config set core/organization_console_url ${CONSOLE_URL:?}
   

   Remplacez GDC_URL par l'URL de base de votre projet GDC.

Se connecter au cluster

1. Exécutez la commande suivante pour vous connecter :

   gdcloud auth login --no-browser
   

2. Copiez la commande gdcloud qui s'affiche, puis exécutez-la sur une machine ayant accès au navigateur.

3. Copiez l'URL imprimée et collez-la dans la barre d'adresse d'un navigateur Web.

4. Suivez les instructions sur la page Web pour terminer le processus de connexion.

5. Une fois la connexion établie, le navigateur affiche le message Authentification réussie. Veuillez fermer cette fenêtre.

6. Suivez les instructions sur le terminal. Une fois la connexion établie, le message Vous êtes maintenant connecté s'affiche sur le terminal.

Générer le fichier KUBECONFIG

1. Exécutez la commande suivante pour définir la variable d'environnement CLUSTER à utiliser ultérieurement dans le terminal actuel. CLUSTER est le nom de cluster souhaité.

   export CLUSTER=
   

   Consultez le tableau suivant pour déterminer le nom du cluster en remplaçant ORGANIZATION-NAME et CLUSTER-NAME par les valeurs appropriées :

   Cluster	Nom du cluster
   administrateur racine	root-admin
   Administrateur de l'organisation	ORGANIZATION-NAME-admin
   Système org	ORGANIZATION-NAME-system
   utilisateur	CLUSTER-NAME

   Vous verrez que chacun des noms représente les éléments suivants :

   • Le nom du cluster d'administrateur racine est root-admin.
   • Les noms des clusters d'administrateur et de système d'organisation pour une organisation nommée amira sont respectivement amira-admin et amira-system.
   • Les noms de cluster pour les clusters d'utilisateur sont leurs noms de cluster.

2. Exécutez la commande suivante pour générer le fichier KUBECONFIG et valider les identifiants : sh export KUBECONFIG=${HOME}/${CLUSTER:?}-kubeconfig.yaml rm ${KUBECONFIG:?} gdcloud clusters get-credentials ${CLUSTER:?} [[ $(kubectl config current-context) == *${CLUSTER:?}* ]] && echo "Success. Your kubeconfig is at $KUBECONFIG" || echo "Failure" La commande devrait renvoyer le résultat suivant :

   Success. Your kubeconfig is at /usr/local/google/home/iris/kubeconfig-amira-admin.yaml
   

Obtenir le rôle d'administrateur des règles dans le cluster

Ce processus vous permet d'obtenir un accès élevé temporaire à un cluster.

Prérequis

Avant de continuer, assurez-vous de disposer des éléments suivants :

• Un autre IO doit agir en tant qu'approbateur de demandes GitLab. L'IO doit être autorisé à approuver une demande GitLab.
• Nom du cluster auquel vous souhaitez accéder. Par exemple : root-admin, org-1-admin.
• Type de rôle que vous souhaitez assumer. Par exemple : Role ClusterRole, ProjectRole ou OrganizationRole.
• Rôle que vous souhaitez assumer.
• Espace de noms de l'accès requis. Non requis pour ClusterRole et OrganizationRole.
• Accès à un poste de travail OC IT.
• Identifiants pour GitLab.

Exécuter le script d'accès élevé

1. Dans le répertoire private-cloud/operations/tools/ de votre poste de travail, exécutez le script elevated-access-script.sh.

2. Répondez à la question "Veuillez saisir l'URL GDCH du cluster..." en indiquant $GDCH_URL.

3. Répondez à la question "Enter Gitlab username:" (Saisissez le nom d'utilisateur Gitlab) en indiquant le nom d'utilisateur que vous utilisez pour vous connecter à Gitlab.

4. À la question "Enter Gitlab personal access token:" (Saisissez le jeton d'accès personnel GitLab), saisissez le jeton d'accès personnel de votre compte. Pour créer un jeton d'accès personnel, procédez comme suit :

   1. Accédez à https://gitlab.$GDCH_URL/gdch/iac. Connectez-vous à votre compte IO Gitlab.

   2. Sélectionnez votre avatar.

   3. Sélectionnez Modifier la fiche.

   4. Dans le menu de navigation, sélectionnez Jetons d'accès.

   5. Saisissez un nom et une date d'expiration pour le jeton.

   6. Sélectionnez les niveaux d'accès souhaités.

   7. Sélectionnez Créer un jeton d'accès personnel.

5. Le script va maintenant cloner le dépôt iac dans votre répertoire local.

6. Répondez à la question "Saisissez le préfixe de votre IdP". IdP Prefix est un préfixe spécifique à chaque fournisseur d'identité, qui est ajouté avant chaque nom d'utilisateur dans un cluster GDC. Vous pouvez trouver ce préfixe de deux manières :

   • consulter votre Watch Commander ;
   • en récupérant les instructions de configuration de GDC, en particulier la section "Gestion de l'identité et des accès" du Guide de l'utilisateur des opérateurs.

   La forme habituelle de ce préfixe est un ensemble de mots suivi d'un délimiteur, c'est-à-dire gdch-infra-operator-.

7. Répondez à la question "Saisissez votre nom d'utilisateur" en indiquant le nom d'utilisateur que vous utilisez pour vous connecter à votre fournisseur d'identité.

8. Répondez à la question "Saisissez le nom du cluster pour lequel vous avez besoin du rôle" en indiquant le nom du cluster pour lequel vous avez besoin du rôle.

9. Le script vous invite à choisir un type de rôle Kubernetes. Saisissez le type de rôle que vous demandez.

10. Répondez à la question "Saisissez le rôle que vous devez assumer" en indiquant le nom du rôle.

11. Saisissez la durée d'accès du rôle. La durée d'accès recommandée est de trois heures.

12. Le script génère trois fichiers YAML.

    1. ./iac/infrastructure/zonal/zones/ZONE_NAME/${CLUSTER}/kustomization.yaml
    2. ./iac/infrastructure/zonal/zones/ZONE_NAME/${CLUSTER}/${USER}-bindings/kustomization.yaml
    3. ./iac/infrastructure/zonal/zones/ZONE_NAME/${CLUSTER}/${USER}-bindings/${ROLE}-binding.yaml

    Vérifiez que chaque fichier est correct en appuyant sur Y, ou appuyez sur N pour modifier le fichier dans vim.

13. Après avoir confirmé tous les fichiers, le script les transfère vers une branche elevated_access dans GitLab et crée une demande de fusion.

Examiner et approuver une demande d'accès élevé

La liste suivante spécifie les actions effectuées pour une demande d'accès étendu à examiner et approuver :

1. Un autre IO examine la demande GitLab, y compris les fichiers de configuration des règles, pour l'approuver de manière appropriée.
2. Une fois que l'IO a approuvé la demande, le système accorde l'accès pour la période demandée.
3. Le système révoque l'accès après le délai d'expiration défini.

Contrainte de correctif

Après avoir obtenu l'accès requis, exécutez la commande suivante pour définir la nouvelle durée de conservation maximale du bucket. Cet exemple montre une nouvelle durée maximale de 120 jours, mais veillez à mettre à jour la commande avec la valeur demandée par votre administrateur de plate-forme :

kubectl patch GDCHRestrictAttributeRange restrict-bucket-retention-policy -p '{"spec":{"parameters":{"attributeMaxValue":120}}}' --type=merge

Le résultat doit se présenter sous la forme suivante :

gdchrestrictattributerange.constraints.gatekeeper.sh/restrict-bucket-retention-policy patched