23. Configurer l'infrastructure en tant que code

Temps estimé pour suivre la totalité du cours : 60 minutes

Propriétaire du composant exploitable : IAC

Profil de compétences : ingénieur de déploiement

L'infrastructure en tant que code (IaC) dans Google Distributed Cloud (GDC) sous air gap se compose de deux systèmes :

  • Config Sync est un composant utilisé dans l'infrastructure as code (IaC) Distributed Cloud pour gérer les ressources au niveau du cluster et les services partagés.

  • GitLab héberge un dépôt Git qui sert de source fiable pour Config Sync. Un cluster cible est un cluster que Config Sync gère à partir de la source de vérité dans le dépôt.

    • GitLab inclut un système d'examen du code pour implémenter l'approbation multipartite (MPA) sur les modifications apportées aux règles et à la configuration.

Les deux types de zones suivants sont impliqués dans un déploiement :

  • Zone d'ancrage : zone qui fait déjà partie du plan de contrôle mondial. La première zone est la zone d'ancrage d'un déploiement.
  • Zone de connexion : zone qui rejoint le plan de contrôle mondial.

Config Sync gère les objets Kubernetes dans les clusters root-admin et d'administrateur de l'organisation. Il est configuré pour lire à partir du dépôt IaC Distributed Cloud fourni par GitLab dans le cluster root-admin principal.

Distributed Cloud installe l'IaC lors de l'amorçage. Exécutez les étapes manuelles suivantes pour terminer la configuration de l'IaC.

23.1. Configurer la première zone IaC

Cette section décrit les étapes à suivre pour configurer l'IaC dans la première zone de déploiement.

23.2. Prérequis

  • Amorçage du cluster d'administrateur racine.
  • Créez un client SAML dans l'instance OC IT d'Active Directory Federation Services (ADFS) en tant que client de fédération d'identité dans GitLab.

23.3. Accès à GitLab le jour 0

  1. Ouvrez la console Web GitLab à l'adresse https://iac.GDC_URL. GDC_URL est le domaine spécifié dans le CIQ.

    # Use the root kubeconfig of the root admin cluster.
export ANCHOR_KUBECONFIG=ANCHOR_ZONE_KUBECONFIG
echo https://$(kubectl --kubeconfig $ANCHOR_KUBECONFIG get dnsregistrations \
     -n gitlab-system iac -o jsonpath='{.status.fqdn}')

  2. Utilisez le nom d'utilisateur du jour 0 : ioadmin.

  3. Exécutez la commande suivante pour obtenir le mot de passe :

    export IO_ADMIN_PWD=$(kubectl --kubeconfig $ANCHOR_KUBECONFIG \
  get secret gitlab-basic-users -n gitlab-system  \
  -o jsonpath='{.data.admin}' | base64 -d)

  4. Connectez-vous et accédez à Menu > Projets > Explorer les projets gdch / iac pour vérifier que le dépôt Git iac a été créé.

23.4. Créer des utilisateurs administrateurs

  1. Créez des utilisateurs administrateurs dédiés dans AD FS. Vous ne devez pas les utiliser à des fins non administratives et ils doivent avoir une extension "-ga". Notez que vos utilisateurs administrateurs initiaux DOIVENT utiliser le même email ici que celui qu'ils utilisent dans les services ADFS (Active Directory Federation Services).

  2. Exécutez la commande suivante pour créer un utilisateur :

    export NEW_USER_NAME=NEW_USER_NAME
export NEW_USER_USERNAME=NEW_USERNAME
export NEW_USER_PWD=NEW_USER_PWD
export NEW_USER_EMAIL=NEW_USER_EMAIL
export GDC_URL=GDC_URL
export TOKEN=$(curl -X POST https://iac.$GDC_URL/oauth/token \
    -d "grant_type=password&username=ioadmin&password=${IO_ADMIN_PWD}" \
    | jq -r '.access_token')
USERID=$(curl -X GET https://iac.$GDC_URL/api/v4/users \
    -d access_token=${TOKEN} -d username=ioadmin |\
    sed -E 's/.*"id":"?([^,"]*)"?.*/\1/')
curl -X POST https://iac.$GDC_URL/api/v4/users \
    -d username=${NEW_USER_USERNAME} -d password=${NEW_USER_PWD} -d name=${NEW_USER_NAME} \
    -d email=${NEW_USER_EMAIL} -d admin=true -d access_token=${TOKEN} 
curl -X POST https://iac.$GDC_URL/oauth/revoke \
    -d client_id=${USERID} -d "token=${TOKEN}"

23.5. Mettre à jour la licence GitLab

De nombreuses fonctionnalités de GitLab nécessitent une licence "Ultimate" pour fonctionner. Dans cette étape, vous allez remplacer la licence temporaire fournie avec GDC par la licence propre au site. Pour en savoir plus, consultez Activer GitLab EE avec un fichier ou une clé de licence.

La clé de licence du site que vous avez reçue est un fichier texte ASCII encodé en base64 avec une extension .gitlab-license. Vous utiliserez cette clé pour activer GitLab.

  1. Connectez-vous à la console Web GitLab en tant que ioadmin.
  2. Dans la barre de navigation, sélectionnez Menu, puis Admin.
  3. Dans le menu de navigation, sélectionnez Paramètres, puis Général.
  4. Dans la section "Ajouter une licence", ajoutez une licence en important le fichier ou en saisissant la clé.
  5. Cochez la case "Conditions d'utilisation".
  6. Sélectionnez "Ajouter une licence".

23.6. Configurer le dépôt GitLab

ConfigSync gère les objets Kubernetes dans les clusters administrateur racine et administrateur d'organisation, et est configuré pour lire à partir du dépôt Distributed Cloud IaC fourni par GitLab dans le cluster administrateur racine.

Nous devons configurer les dossiers GitLab initiaux pour que Configsync puisse consommer les configurations et les appliquer au cluster Kubernetes requis.

infrastructure
│   └── zonal
│     └── zones
│         ├── ${anchor_zone_name}
│           ├── root-admin
│             ├── kustomization.yaml
│   └── global
│     └── orgs
│         ├── root
│           ├── kustomization.yaml

Suivez les étapes ci-dessous pour créer la structure de fichier initiale :

  1. Ouvrez le dépôt iac à partir de "Menu -> Explore Projects" (Menu -> Explorer les projets).

  2. Ouvrez l'IDE Web.

  3. Créez un fichier dans /infrastructure/zonal/zones/${anchor_zone_name}/root-admin/kustomization.yaml avec le contenu suivant :

    apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
metadata:
  name: root-admin-kustomization

  4. Cliquez sur le bouton "Commit" (Valider).

  5. Sélectionnez "Effectuer un commit dans la branche principale", puis confirmez.

23.7. Configurer l'approbation multipartite

Utilisez cette section pour configurer le système afin d'exiger une approbation pour chaque demande de fusion dans le dépôt iac et d'empêcher tout commit direct (sans créer de demande de fusion) dans la branche main afin d'appliquer l'approbation multipartite (MPA).

23.7.1. Activer l'approbation des demandes de fusion dans GitLab

  1. Accédez au dépôt iac.

  2. Utilisez l'IDE Web pour créer un fichier nommé CODEOWNERS dans le dossier racine et ajoutez le groupe Distributed Cloud en tant que propriétaire du dépôt.

    [Repository Owners]
* @gdch

    Seuls les utilisateurs ajoutés au fichier CODEOWNERS peuvent approuver les demandes de fusion dans le dépôt iac. Ce fichier générique est destiné à la configuration uniquement. Pour obtenir des instructions plus détaillées sur les autorisations d'approbation précises, consultez IAC-R0007.

  3. Cliquez sur le bouton Valider.

  4. Sélectionnez Valider sur la branche principale, puis confirmez.

  5. Pour ajouter des utilisateurs au fichier CODEOWNERS, créez une demande de fusion qui devra être approuvée par les utilisateurs existants dans CODEOWNERS.

23.8. Connecter Active Directory Federation Services (ADFS) à GitLab

Vous pouvez connecter ADFS à GitLab avec un client SAML à l'aide du framework Auth de GitLab.

Si vous utilisez une autorité de certification privée pour votre fournisseur d'identité, vous devez l'ajouter à l'instance GitLab. Obtenez la version base64 du certificat de l'autorité de certification ADFS et placez-la dans un secret.

cat <<EOF > adfs-ca-cert-secret.yaml
apiVersion: v1
data:
  tls.crt: ADFS_CA_CERTIFICATE_BASE64
kind: Secret
metadata:
  name: adfs-ca-cert-secret
  namespace: gitlab-system
type: Opaque
EOF

kubectl apply -f adfs-ca-cert-secret.yaml

23.8.1. Configurer ADFS pour l'authentification SAML

Avant de connecter GitLab à ADFS à l'aide de la configuration Helm, ADFS doit créer un client SAML. Dans votre instance Windows, procédez comme suit :

  1. Exécutez l'application Gestion AD FS en tant qu'administrateur.

    Cliquez sur &quot;Exécuter en tant qu&#39;administrateur&quot;.

  2. Dans le répertoire AD FS, cliquez sur le dossier Approbation de partie de confiance. Dans le panneau Actions, cliquez sur Ajouter une approbation de partie de confiance.

  3. L'assistant Ajouter une approbation de partie de confiance s'ouvre. Pour la première étape, sélectionnez Claims aware (Prise en charge des revendications), puis cliquez sur Start (Démarrer).

  4. Sélectionnez Saisir manuellement les données concernant le tiers de confiance, puis cliquez sur Suivant.

  5. Saisissez des informations reconnaissables sur l'instance ADFS dans les champs Nom à afficher et Notes. Cliquez sur Next (Suivant).

  6. Ignorez l'étape Configurer le certificat en cliquant sur Suivant.

  7. Cochez la case Enable support for the SAML 2.0 WebSSO protocol (Activer la prise en charge du protocole WebSSO SAML 2.0). Dans le champ URL du service d'authentification unique SAML 2.0 de confiance, saisissez l'URL suivante : https://iac.GDC_URL/users/auth/saml/callback.

    Remplacez GDC_URL par l'URL de l'organisation dans GDC.

  8. Donnez un nom à IaC et ajoutez les éléments suivants :

    https://iac.GDC_URL.sesame.street https://iac.GDC_URL.sesame.street/users/auth/saml/callback

  9. Cliquez sur Suivant pour les étapes Configurer les identifiants, Choisir une stratégie de contrôle d'accès et Prêt à ajouter la confiance afin de terminer l'assistant.

      # Replace GDC_URL with the cells URL, for example, bert.sesame.street
  https://iac.GDC_URL
  https://iac.GDC_URL/users/auth/saml/callback

  10. L'affichage est mis à jour avec l'approbation de partie de confiance que vous venez de créer. Effectuez un clic droit sur votre élément, puis sélectionnez Modifier la stratégie d'émission de revendication.

    Liste des relations de confiance avec les colonnes &quot;Activé&quot;, &quot;Type&quot;, &quot;Identifiant&quot; et &quot;Règle de contrôle des accès&quot;

  11. Cliquez sur le bouton Ajouter une règle. À l'étape Choisir le type de règle, sélectionnez le modèle de règle de revendication Envoyer les attributs LDAP en tant que revendications. Cliquez sur Suivant.

  12. Dans l'étape Configurer la règle de revendication, renseignez les paramètres suivants :

    1. Dans le champ Nom de la règle de revendication, saisissez Email.
    2. Dans la liste Magasin d'attributs, sélectionnez Active Directory.
    3. Dans le tableau Mappage des attributs LDAP aux types de revendications sortantes, dans la colonne Attribut LDAP, sélectionnez ou saisissez E-Mail-Addresses.

    4. Dans la colonne Type de revendication sortante du tableau, sélectionnez ou saisissez E-Mail Address.

    5. Terminez l'assistant.

  13. Cliquez sur le bouton Ajouter une règle.

  14. Effectuez un clic droit sur l'élément, puis cliquez à nouveau sur Modifier la stratégie d'émission de revendication.

  15. À l'étape Choisir le type de règle, sélectionnez le modèle de règle de revendication Transformer une revendication entrante. Cliquez sur Suivant.

  16. Dans l'étape Configurer la règle de revendication, renseignez les paramètres suivants :

    1. Dans le champ Nom de la règle de revendication, saisissez Transform email to nameid.
    2. Dans le champ Type de revendication entrante, sélectionnez ou saisissez E-Mail Address.
    3. Dans le champ Type de revendication sortante, sélectionnez ou saisissez Name ID.
    4. Dans le champ Format de l'ID de nom sortant, sélectionnez ou saisissez Persistent Identifier.

    5. Sélectionnez l'option Transmettre toutes les valeurs de revendication.

    6. Terminez l'assistant.

23.8.2. Ajouter une configuration SAML à GitLab

Cette section décrit la procédure à suivre pour ajouter une configuration SAML à GitLab.

23.8.2.1. Enregistrer GitLab dans le fournisseur d'identité

Ouvrez la configuration de votre client SAML dans ADFS. GitLab nécessite les valeurs suivantes pour s'intégrer à votre IdP :

  • assertion_customer_service_url : URL vers laquelle le fournisseur d'identité redirige l'utilisateur après l'avoir authentifié. Définissez-la sur https://iac.GDC_URL/users/auth/saml/callback.

    Remplacez GDC_URL par l'URL de l'organisation dans GDC.

  • idp_cert_fingerprint : GitLab utilise cette empreinte digitale pour valider le certificat d'un message SAML entrant. Pour trouver le idp_cert_fingerprint dans ADFS, procédez comme suit :

    1. Exécutez l'application AD FS Management en tant qu'administrateur.

    2. Dans l'arborescence des répertoires AD FS > Service > Certificats, cliquez sur le dossier Certificats. Un certificat s'affiche dans la section Signature de jetons. Effectuez un clic droit sur ce certificat, puis sélectionnez Afficher le certificat.

      Afficher le certificat ADFS.

    3. Dans la fenêtre Certificate (Certificat), accédez à l'onglet Details. Faites défiler la liste jusqu'à ce que vous trouviez un élément appelé Thumbprint. Cliquez sur l'élément et copiez le contenu affiché dans la console.

      Obtenir l&#39;empreinte ADFS.

  • idp_sso_target_url : GitLab ciblera ce point de terminaison lors de l'authentification par SAML. Pour trouver le idp_sso_target_url dans ADFS, procédez comme suit :

    1. Exécutez l'application Gestion AD FS en tant qu'administrateur.

    2. Cliquez sur le dossier Points de terminaison dans l'arborescence AD FS > Service.

      Points de terminaison

      Obtenir les points de terminaison ADFS.

    3. Sur l'écran central, recherchez une ligne de type SAML 2.0/WS-Federation. Le point de terminaison cible est votre URL ADFS et le point de terminaison cible. Par exemple, si le nom de domaine de votre instance est https://ocit.gdch.test/ et que le point de terminaison cible est /adfs/ls, idp_sso_target_url est https://ocit.gdch.test/adfs/ls.

  • issuer : URL utilisée par GitLab pour s'identifier. Utilisez https://iac.GDC_URL.

    Préparez les valeurs du fournisseur d'identité ci-dessus et écrivez-les dans une configuration personnalisée appelée custom_saml.yaml. Modifiez ce fichier YAML pour obtenir la configuration nécessaire à votre client SAML.

    cat <<EOF > custom_saml.yaml
name: saml
label: "ADFS SAML" # This is the label the login button will use.
args:
  assertion_consumer_service_url: "https://iac.GDC_URL/users/auth/saml/callback"
  idp_cert_fingerprint: "ADFS_IDP_CERT_FINGERPRINT"
  idp_sso_target_url: "ADFS_IDP_SSO_TARGET_URL"
  issuer: "https://iac.GDC_URL"

  # These parameters are necessary for ADFS to connect to GitLab. Do not change unless you are sure of what you're doing.
  name_identifier_format: "urn:oasis:names:tc:SAML:2.0:nameid-format:persistent"
  attribute_statements: { email: ['http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress'] }
EOF

    Lorsque vous êtes prêt, appliquez votre configuration en tant que secret appelé custom-gitlab-saml-provider.

    cat <<EOF > custom-gitlab-saml-provider.yaml
apiVersion: v1
data:
  provider: |
  $(cat custom_saml.yaml | base64 -w 0)
kind: Secret
metadata:
  name: custom-gitlab-saml-provider
  namespace: gitlab-system
  annotations:
    "helm.sh/hook": post-install,post-upgrade
    "helm.sh/hook-weight": "-5"
EOF
kubectl apply -f custom-gitlab-saml-provider.yaml

    Vous pouvez utiliser le secret lors de la création de subcomponentoverride.yaml. Pour en savoir plus sur les variables, consultez la documentation GitLab.

    cat <<EOF > subcomponentoverride.yaml
apiVersion: lcm.private.gdc.goog/v1
kind: SubcomponentOverride
metadata:
  name: iac-gitlab
  namespace: root
spec:
  subComponentRef: "iac-gitlab"
  backend:
    operableParameters:
      omniauth:
        enabled: true
        providers:
        - secret: custom-gitlab-saml-provider
      certificates:
        customCAs:
        - secret: adfs-ca-cert-secret
        - configMap: trust-store-root-ext
EOF
kubectl apply -f subcomponentoverride.yaml

Cela crée le remplacement du sous-composant. Pour vérifier que la configuration a été créée, exécutez la commande suivante : sh kubectl get subcomponentoverride -n root

Le résultat ressemble à ce qui suit :

NAME            AGE
iac-gitlab   1s

23.8.2.2. Initialiser le premier utilisateur SAML connecté

L'activation de SAML supprime la connexion locale. Les utilisateurs doivent suivre les procédures d'accès d'urgence pour réactiver la connexion locale et accéder de nouveau à ioadmin.

Les premiers administrateurs initialisés créés dans Créer des utilisateurs administrateurs fonctionneront sans autre modification. Ils ne doivent pas avoir accès au projet. Pour ajouter des utilisateurs au projet Distributed Cloud, suivez la procédure Intégrer un nouvel utilisateur depuis ADFS.

23.8.3. Vérifier la connexion ADFS

  1. Vérifiez l'état des pods webservice GitLab :

    kubectl --kubeconfig $KUBECONFIG get pod -l app=webservice,release=gitlab -n gitlab-system
    NOM READY ÉTAT REDÉMARRAGES ÂGE
    gitlab-webservice-default-5d99b4d7c7-9fmln 2/2 En cours d'exécution 0 4m6s
    gitlab-webservice-default-5d99b4d7c7-w99p4 2/2 En cours d'exécution 0 96s
    gitlab-webservice-default-7884d4c8b9-qjhtv 2/2 En cours d'arrêt 0 18 h

  2. Accédez à https://iac.GDC_URL et vérifiez que l'écran ADFS SAML s'affiche. Il permet d'utiliser la connexion SSO et ne comporte pas de champs directs pour le nom d'utilisateur et le mot de passe.

  3. Cliquez sur ADFS SAML. Vérifiez que vous êtes invité à vous connecter à ADFS.

  4. Après vous être connecté à ADFS, vérifiez que vous êtes connecté à GitLab et que vous pouvez désormais interagir avec l'application.

23.9. Verrouiller le compte administrateur du jour 0

Une fois SAML activé, désactivez l'authentification par mot de passe pour l'interface Web, puis réinitialisez le mot de passe de ioadmin, car l'accès à l'API persiste.

  1. Exécutez le script ci-après.

      export KUBECONFIG=/root/release/root-admin/root-admin-kubeconfig
  export PWD=$(kubectl get secret gitlab-basic-users -n gitlab-system -o yaml \
      | grep admin | head -n1 | awk '{print $2}' | xargs echo | base64 -d)
  export TOKEN=$(curl -X POST https://iac.GDC_URL/oauth/token \
      -d "grant_type=password&username=ioadmin&password=${PWD}" \
      | jq -r '.access_token')
  curl -X PUT  https://iac.GDC_URL/api/v4/application/settings \
      -d access_token=${TOKEN} \
      -d password_authentication_enabled_for_web=false
  NEWPASS=$(cat /dev/urandom | tr -dc 'a-zA-Z0-9' | fold -w 32 | head -n 1)
  USERID=$(curl -X GET https://iac.GDC_URL/api/v4/users \
      -d access_token=${TOKEN} -d username=ioadmin |\
      jq -r '.[] | .id')
  curl -X PUT  https://iac.GDC_URL/api/v4/users/${USERID} \
      -d access_token=${TOKEN} -d username=ioadmin \
      -d "password=${NEWPASS}" \
      -d user_id=${USERID}
  curl -X POST https://iac.GDC_URL/oauth/revoke \
      -d client_id=${USERID} -d "token=${TOKEN}"

  2. Stockez le nouveau mot de passe dans le secret gitlab-basic-users.

      kubectl patch secret gitlab-basic-users -n gitlab-system --type=json -p'[{"op": "replace", "path": "/data/admin", "value": '"$(echo $NEWPASS | base64 -w0)"'}]'

Utilisez les comptes dans OI ADFS pour vous connecter.

23.10. Configurer l'IaC de la zone de connexion

Cette section décrit la procédure à suivre pour configurer l'IaC dans la zone de déploiement.

23.11. Prérequis

Avant de configurer la zone de jonction, vous devez amorcer le cluster d'administrateur racine.

23.12. Configurer les identifiants Config Sync

Pour configurer les identifiants Config Sync, procédez comme suit :

  1. Connectez-vous au cluster d'administrateur racine de la zone d'ancrage.

  2. Récupérez les identifiants Config Sync :

    kubectl --kubeconfig $ANCHOR_KUBECONFIG get secret -n config-management-system iac-creds-replica -o json |\
    jq 'del(.metadata.creationTimestamp, .metadata.resourceVersion, .metadata.uid)' > iac-creds-replica.json

  3. Copiez le fichier iac-creds-replica.json.

  4. Connectez-vous au cluster d'administrateur racine de la zone à laquelle vous souhaitez vous joindre.

  5. Collez le fichier iac-creds-replica.json.

  6. Appliquez les identifiants Config Sync au cluster d'administrateur racine :

    # Use the root kubeconfig of the root admin cluster.
export JOINING_KUBECONFIG=JOINING_ZONE_KUBECONFIG
kubectl --kubeconfig $JOINING_KUBECONFIG apply -f iac-creds-replica.json

  7. Assurez-vous que les identifiants Config Sync sont configurés :

    kubectl --kubeconfig $JOINING_KUBECONFIG get secret -n config-management-system \
    iac-creds-replica -o yaml

23.13. Configurer la source de vérité Config Sync

Procédez comme suit pour configurer la source de référence Config Sync :

  1. Connectez-vous au cluster d'administrateur racine de la zone d'ancrage.

  2. Obtenez le FQDN de GitLab :

    export primaryDnsFQDN=$(kubectl --kubeconfig $ANCHOR_KUBECONFIG get DNSRegistration \
    -n gitlab-system iac -o jsonpath='{.status.fqdn}')

  3. Connectez-vous au cluster d'administrateur racine de la zone à laquelle vous souhaitez vous joindre.

  4. Créez le fichier IaC SubcomponentOverride :

    echo "apiVersion: lcm.private.gdc.goog/v1
kind: SubcomponentOverride
metadata:
    name: iac
    namespace: root
spec:
    subComponentRef: "iac-configsync"
    backend:
        operableParameters:
            primaryDnsFQDN: ${primaryDnsFQDN}" > iac-subcomponentoverride.yaml

  5. Configurez la cible Config Sync :

    kubectl --kubeconfig $JOINING_KUBECONFIG apply -f iac-subcomponentoverride.yaml

  6. Assurez-vous que le dépôt Git Config Sync est configuré :

    kubectl --kubeconfig $JOINING_KUBECONFIG get RootSync -n config-management-system \
    root-sync -o jsonpath='{.spec.git.repo}'

  7. Assurez-vous que Config Sync ne présente aucune erreur dans les zones d'ancrage et de jonction.

    kubectl --kubeconfig $JOINING_KUBECONFIG get RootSync \
    -n config-management-system root-sync \
    -o jsonpath='{.status.source.errors[0].errorMessage}'

    1. Si root-sync contient l'erreur KNV2004, cela signifie que le chemin d'accès au répertoire utilisé par la zone d'ancrage ou de jonction n'existe pas dans le dépôt iac. Recherchez le répertoire requis en exécutant la commande suivante :

      kubectl --kubeconfig $JOINING_KUBECONFIG get RootSync \
    -n config-management-system root-sync
    -o jsonpath='{.spec.git.dir}'

    2. Créez le chemin d'accès généré par la commande précédente dans le dépôt iac et ajoutez un fichier kustomization.yaml générique. Ensuite, fusionnez-le dans la branche main.

    3. Réexécutez la commande get RootSync d'origine pour vous assurer que Config Sync ne présente aucune erreur.