23. Configurazione di Infrastructure as Code

Tempo stimato per completare il corso: 60 minuti

Proprietario del componente utilizzabile: IAC

Profilo delle competenze: ingegnere del deployment

Infrastructure as Code (IaC) in Google Distributed Cloud (GDC) con air gap è costituito da due sistemi:

  • Config Sync è un componente utilizzato in Distributed Cloud Infrastructure as Code (IaC) per la gestione delle risorse a livello di cluster e dei servizi condivisi.

  • GitLab ospita un repository Git che funge da fonte attendibile per Config Sync. Un cluster di destinazione è un cluster che Config Sync gestisce dall'origine della verità nel repository.

    • GitLab include un sistema di revisione del codice per implementare l'approvazione multi-party (MPA) per le modifiche a criteri e configurazione.

In un deployment sono coinvolti i seguenti due tipi di zone:

  • Zona di ancoraggio: la zona che fa già parte del control plane globale. La prima zona è la zona di ancoraggio di un deployment.
  • Zona di unione: la zona che si unisce al control plane globale.

Config Sync gestisce gli oggetti Kubernetes nei cluster root-admin e amministratore dell'organizzazione. È configurato per leggere dal repository Distributed Cloud IaC gestito da GitLab nel cluster root-admin principale.

Distributed Cloud installa IaC durante il bootstrap. Esegui i seguenti passaggi manuali per completare la configurazione di IaC.

23.1. Configurare l'infrastruttura come codice della prima zona

Questa sezione include i passaggi per configurare IaC nella prima zona di deployment.

23.2. Prerequisiti

  • È stato eseguito il bootstrap del cluster di amministrazione principale.
  • Crea un client SAML nell'istanza ADFS (Active Directory Federation Services) di OC IT come client di federazione delle identità in GitLab.

23.3. Accesso a GitLab il giorno 0

  1. Apri la console web GitLab all'indirizzo https://iac.GDC_URL. GDC_URL è il dominio specificato nella 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. Utilizza il nome utente del giorno 0: ioadmin.

  3. Esegui questo comando per ottenere la password:

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

  4. Accedi e vai a Menu > Progetti > Esplora progetti gdch / iac per verificare che sia stato creato il repository Git iac.

23.4. Creare utenti amministratore

  1. Crea utenti amministratore dedicati in ADFS. Non devi utilizzarli per scopi non amministrativi e devono avere un'estensione "-ga". Tieni presente che gli utenti amministratore iniziali DEVONO utilizzare lo stesso email qui utilizzato in Active Directory Federation Services (ADFS).

  2. Esegui questo comando per creare un nuovo utente:

    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. Aggiorna la licenza GitLab

Molte funzionalità di GitLab richiedono una licenza "Ultimate" per funzionare. In questo passaggio sostituirai la licenza temporanea fornita con GDC con la licenza del sito. Attivare GitLab EE con un file di licenza o una chiave contiene tutti i dettagli.

La codice licenza del sito che hai ricevuto è un file di testo ASCII con codifica Base64 con estensione .gitlab-license. Utilizzerai questa chiave per attivare GitLab.

  1. Accedi alla console web GitLab come ioadmin.
  2. Nella barra di navigazione, seleziona Menu e poi Amministrazione.
  3. Nel menu di navigazione, seleziona Impostazioni e poi Generali.
  4. Nell'area Aggiungi licenza, aggiungi una licenza caricando il file o inserendo la chiave.
  5. Seleziona la casella di controllo Termini di servizio.
  6. Seleziona Aggiungi licenza.

23.6. Configurare il repository GitLab

ConfigSync gestisce gli oggetti Kubernetes nel cluster root-admin e nei cluster org-admin ed è configurato per leggere dal repository Distributed Cloud IaC gestito da GitLab nel cluster root-admin.

Dobbiamo configurare le cartelle GitLab iniziali per consentire a Configsync di utilizzare le configurazioni e applicarle al cluster Kubernetes richiesto.

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

Segui i passaggi per creare la struttura iniziale dei file:

  1. Apri il repository iac da "Menu -> Esplora progetti".

  2. Apri "Web IDE".

  3. Crea un file in /infrastructure/zonal/zones/${anchor_zone_name}/root-admin/kustomization.yaml con i seguenti contenuti:

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

  4. Fai clic sul pulsante "Commit".

  5. Seleziona "Commit to the main branch" (Esegui il commit nel ramo principale) e conferma.

23.7. Configurare l'approvazione da più parti

Utilizza questa sezione per configurare il sistema in modo da richiedere l'approvazione di ogni richiesta di unione al repository iac e impedire qualsiasi commit diretto (senza creare una richiesta di unione) al ramo main per applicare l'approvazione da più parti (MPA).

23.7.1. Abilitare l'approvazione delle richieste di unione in GitLab

  1. Vai al repository iac.

  2. Utilizza l'IDE web per creare un file denominato CODEOWNERS nella cartella principale e aggiungi il gruppo Distributed Cloud come proprietari del repository come primo passaggio:

    [Repository Owners]
* @gdch

    Solo gli utenti aggiunti al file CODEOWNERS possono approvare le richieste di unione nel repository iac. Questo file generico è solo a scopo di configurazione. Istruzioni più dettagliate per le autorizzazioni di approvazione granulari sono descritte in dettaglio in IAC-R0007.

  3. Fai clic sul pulsante Commit.

  4. Seleziona Esegui il commit nel ramo principale e conferma.

  5. Per aggiungere altri utenti al file CODEOWNERS, crea una richiesta di unione da approvare dagli utenti esistenti in CODEOWNERS.

23.8. Connetti Active Directory Federation Services (ADFS) a GitLab

Puoi connettere ADFS a GitLab con un client SAML utilizzando il framework Auth di GitLab.

Se utilizzi un'autorità di certificazione privata per il tuo provider di identità, devi aggiungerla all'istanza GitLab. Recupera la versione Base64 del certificato CA ADFS e inseriscila in 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. Configurare ADFS per l'autenticazione SAML

Prima di connettere GitLab ad ADFS utilizzando la configurazione Helm, ADFS deve creare un client SAML. Nella tua istanza Windows, segui questi passaggi:

  1. Esegui l'app Gestione AD FS come amministratore.

    Fai clic su Esegui come amministratore.

  2. Nella directory AD FS, fai clic sulla cartella Attendibilità componente. Nel riquadro Azioni, fai clic su Aggiungi attendibilità componente.

  3. Viene visualizzata la procedura guidata di aggiunta dell'attendibilità componente. Per il primo passaggio, seleziona Riconoscimento delle rivendicazioni e fai clic su Avvia.

  4. Seleziona Inserisci manualmente i dati sul componente e fai clic su Avanti.

  5. Inserisci alcune informazioni riconoscibili sull'istanza ADFS nei campi Nome visualizzato e Note. Fai clic su Avanti.

  6. Salta il passaggio Configura certificato facendo clic su Avanti.

  7. Fai clic sulla casella di controllo Enable support for the SAML 2.0 WebSSO protocol (Attiva il supporto del protocollo WebSSO SAML 2.0). Nel campo Relying party SAML 2.0 SSO service URL (URL del servizio SSO SAML 2.0 della relying party), inserisci quanto segue: https://iac.GDC_URL/users/auth/saml/callback.

    Sostituisci GDC_URL con l'URL dell'organizzazione in GDC.

  8. Assegna un nome all'IaC e aggiungi quanto segue:

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

  9. Fai clic su Avanti per i passaggi Configura identificatori, Scegli criterio di controllo dell'accesso e Pronto per aggiungere l'attendibilità per completare la procedura guidata.

      # 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. Il display viene aggiornato con l'attendibilità della relying party appena creata. Fai clic con il tasto destro del mouse sull'elemento e seleziona Modifica criterio di emissione delle rivendicazioni.

    Elenco di trust delle relying party con le colonne Enabled (Attivato), Type (Tipo), Identifier (Identificatore) e Access Control Policy (Policy di controllo dell&#39;accesso)

  11. Fai clic sul pulsante Aggiungi regola, seleziona Modello di regola attestazione di Invia attributi LDAP come attestazioni nel passaggio Scegli tipo di regola. Fai clic su Avanti.

  12. Nel passaggio Configura regola di rivendicazione, completa i seguenti parametri:

    1. Nel campo Nome regola di rivendicazione, inserisci Email.
    2. Nell'elenco Archivio attributi, seleziona Active Directory.
    3. Nella tabella Mappatura degli attributi LDAP ai tipi di rivendicazione in uscita, nella colonna Attributo LDAP, seleziona o digita E-Mail-Addresses.

    4. Nella colonna Tipo di rivendicazione in uscita della tabella, seleziona o digita E-Mail Address.

    5. Completa la procedura guidata.

  13. Fai clic sul pulsante Aggiungi regola.

  14. Fai clic con il tasto destro del mouse sull'elemento e poi di nuovo su Modifica criteri di emissione delle attestazioni.

  15. Nel passaggio Scegli tipo di regola, seleziona il Modello di regola attestazione di Trasforma un'attestazione in entrata. Fai clic su Avanti.

  16. Nel passaggio Configura regola di rivendicazione, completa i seguenti parametri:

    1. Nel campo Nome regola di rivendicazione, inserisci Transform email to nameid.
    2. Nel campo Tipo di rivendicazione in entrata, seleziona o digita E-Mail Address.
    3. Nel campo Tipo di attestazione in uscita, seleziona o digita Name ID.
    4. Nel campo Formato ID nome in uscita, seleziona o digita Persistent Identifier.

    5. Seleziona l'opzione Trasferisci tutti i valori delle rivendicazioni.

    6. Completa la procedura guidata.

23.8.2. Aggiungi la configurazione SAML a GitLab

Questa sezione fornisce i passaggi per aggiungere la configurazione SAML a GitLab.

23.8.2.1. Registra GitLab nel provider di identità

Apri la configurazione del client SAML in ADFS. Per l'integrazione con il tuo IdP, GitLab richiede i seguenti valori:

  • assertion_customer_service_url: l'IdP reindirizza a questo URL dopo aver autenticato l'utente. Imposta il valore su https://iac.GDC_URL/users/auth/saml/callback.

    Sostituisci GDC_URL con l'URL dell'organizzazione in GDC.

  • idp_cert_fingerprint: GitLab utilizza questa impronta per verificare il certificato di un messaggio SAML in entrata. Per trovare idp_cert_fingerprint in ADFS:

    1. Esegui l'app AD FS Management come amministratore.

    2. Nell'albero delle directory AD FS > Service > Certificates, fai clic sulla cartella Certificates. Viene visualizzato un certificato nella sezione Firma token. Fai clic con il tasto destro del mouse sul certificato e seleziona Visualizza certificato.

      Visualizza certificato ADFS.

    3. Nella finestra Certificato, vai alla scheda Details. Scorri l'elenco finché non vedi un elemento chiamato Thumbprint. Fai clic sull'elemento e copia i contenuti visualizzati nella console.

      ADFS get thumbprint.

  • idp_sso_target_url - GitLab prenderà di mira questo endpoint durante l'autenticazione tramite SAML. Per trovare idp_sso_target_url in ADFS, segui questi passaggi:

    1. Esegui l'app Gestione AD FS come amministratore.

    2. Fai clic sulla cartella Endpoint nell'albero delle directory AD FS > Service.

      Endpoint.

      ADFS get endpoints.

    3. Nella schermata centrale, cerca una riga con il tipo SAML 2.0/WS-Federation. L'endpoint di destinazione è l'URL ADFS e l'endpoint di destinazione. Ad esempio, se il nome di dominio della tua istanza è https://ocit.gdch.test/ e l'endpoint di destinazione è /adfs/ls, il idp_sso_target_url è https://ocit.gdch.test/adfs/ls.

  • issuer: l'URL utilizzato da GitLab per identificarsi. Utilizza https://iac.GDC_URL.

    Prepara i valori IdP precedenti e scrivili in una configurazione personalizzata chiamata custom_saml.yaml. Modifica questo file YAML per ottenere la configurazione necessaria per il tuo 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

    Quando è tutto pronto, applica la configurazione come secret chiamato 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

    Puoi utilizzare il secret durante la creazione di subcomponentoverride.yaml. Scopri di più sulle variabili nella documentazione di 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

Viene creato l'override del sottocomponente. Per verificare che la configurazione sia stata creata, esegui: sh kubectl get subcomponentoverride -n root

L'output è simile al seguente:

NAME            AGE
iac-gitlab   1s

23.8.2.2. Inizializza il primo utente SAML che ha eseguito l'accesso

L'attivazione di SAML rimuove l'accesso locale. Gli utenti devono seguire le procedure di accesso di emergenza per riattivare l'accesso locale e riaccedere a ioadmin.

Gli amministratori inizializzati per primi creati in Crea utenti amministrativi funzioneranno senza ulteriori modifiche come amministratori. Non devono avere accesso al progetto. Per aggiungere utenti al progetto Distributed Cloud, segui la procedura descritta in Eseguire l'onboarding di un nuovo utente da ADFS.

23.8.3. Verificare la connessione ADFS

  1. Controlla lo stato dei pod webservice di GitLab:

    kubectl --kubeconfig $KUBECONFIG get pod -l app=webservice,release=gitlab -n gitlab-system
    NOME PRONTO STATO RIAVVII AGE
    gitlab-webservice-default-5d99b4d7c7-9fmln 2/2 In esecuzione 0 4m6s
    gitlab-webservice-default-5d99b4d7c7-w99p4 2/2 In esecuzione 0 96s
    gitlab-webservice-default-7884d4c8b9-qjhtv 2/2 In fase di chiusura 0 18 ore

  2. Vai a https://iac.GDC_URL e verifica di visualizzare questa schermata, che mostra il pulsante ADFS SAML per utilizzare l'accesso SSO e nessun campo per l'accesso diretto con nome utente e password.

  3. Fai clic su ADFS SAML. Verifica che ti venga chiesto di accedere ad ADFS.

  4. Dopo aver eseguito l'accesso ad ADFS, verifica di aver eseguito l'accesso a GitLab e di poter interagire con l'applicazione.

23.9. Bloccare l'account amministratore del giorno 0

Dopo aver abilitato SAML, disattiva l'autenticazione tramite password per l'interfaccia web, quindi reimposta la password per ioadmin poiché l'accesso API persiste.

  1. Esegui il seguente script.

      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. Memorizza la nuova password nel 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)"'}]'

Utilizza gli account in OI ADFS per accedere.

23.10. Configurare l'infrastruttura come codice della zona di unione

Questa sezione descrive i passaggi per configurare l'IaC nella zona di unione del deployment.

23.11. Prerequisiti

Prima di configurare la zona di unione, devi eseguire il bootstrap del cluster di amministrazione principale.

23.12. Configura le credenziali di ConfigSync

Segui questi passaggi per configurare le credenziali di Config Sync:

  1. Connettiti al cluster di amministrazione principale della zona di ancoraggio.

  2. Recupera le credenziali di 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. Copia il file iac-creds-replica.json.

  4. Connettiti al cluster di amministrazione principale della zona di unione.

  5. Incolla il file iac-creds-replica.json.

  6. Applica le credenziali di Config Sync al cluster di amministrazione principale:

    # 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. Assicurati che le credenziali di Config Sync siano configurate:

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

23.13. Configurare l'unica fonte attendibile di Config Sync

Segui questi passaggi per configurare l'origine attendibile di Config Sync:

  1. Connettiti al cluster di amministrazione principale della zona di ancoraggio.

  2. Recupera il nome di dominio completo di GitLab:

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

  3. Connettiti al cluster di amministrazione principale della zona di unione.

  4. Crea il file SubcomponentOverride IaC:

    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. Configura la destinazione di Config Sync:

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

  6. Assicurati che il repository Git di Config Sync sia configurato:

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

  7. Assicurati che Config Sync non presenti errori nelle zone di ancoraggio e di unione.

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

    1. Se root-sync contiene l'errore KNV2004, il percorso della directory utilizzato dall'ancoraggio o dalla zona di unione non esiste nel repository iac. Trova la directory richiesta eseguendo:

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

    2. Crea il percorso generato dal comando precedente nel repository iac e aggiungi un file kustomization.yaml generico. Quindi, esegui il merge nel ramo main.

    3. Esegui di nuovo il comando get RootSync originale per assicurarti che Config Sync non presenti errori.