23. Configuração da infraestrutura como código

Tempo estimado até à conclusão: 60 minutos

Proprietário do componente acionável: IAC

Perfil de competências: engenheiro de implementação

A infraestrutura como código (IaC) no Google Distributed Cloud (GDC) isolado consiste em dois sistemas:

  • O Config Sync é um componente usado na infraestrutura como código (IaC) da Distributed Cloud para gerir recursos ao nível do cluster e serviços partilhados.

  • O GitLab aloja um repositório Git que serve como fonte de informações fidedignas (SoT) para o Config Sync. Um cluster de destino é um cluster que o Config Sync gere a partir da SoT no repositório.

    • O GitLab inclui um sistema de revisão de código para implementar a aprovação de várias partes (MPA) nas alterações de políticas e configurações.

Os seguintes dois tipos de zonas estão envolvidos numa implementação:

  • Zona de ancoragem: a zona que já faz parte do plano de controlo global. A primeira zona é a zona de referência de uma implementação.
  • Zona de associação: a zona que está a associar-se ao plano de controlo global.

O Config Sync gere objetos do Kubernetes nos clusters root-admin e organization-admin. Está configurado para ler a partir do repositório de IaC da nuvem distribuída disponibilizado pelo GitLab no cluster root-admin principal.

A nuvem distribuída instala a IaC durante o arranque. Execute os seguintes passos manuais para concluir a configuração da IaC.

23.1. Configure a primeira IaC de zona

Esta secção inclui passos para configurar a IaC na primeira zona de implementação.

23.2. Pré-requisitos

  • O cluster de administrador raiz foi inicializado.
  • Crie um cliente SAML na instância dos Serviços de federação do Active Directory (ADFS) do OC IT como cliente de federação de identidades no GitLab.

23.3. Acesso no Dia 0 ao GitLab

  1. Abra a consola Web do GitLab em https://iac.GDC_URL. GDC_URL é o domínio que foi especificado no 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. Use o nome de utilizador do dia 0: ioadmin.

  3. Execute o seguinte comando para obter a palavra-passe:

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

  4. Inicie sessão e navegue para Menu > Projetos > Explorar projetos gdch / iac para verificar se o repositório iac Git foi criado.

23.4. Crie utilizadores administradores

  1. Crie utilizadores administradores dedicados no ADFS. Não os pode usar para fins não administrativos e têm de ter uma extensão "-ga". Tenha em atenção que os utilizadores administradores iniciais TÊM de usar o mesmo email aqui que usam nos Serviços de federação do Active Directory (ADFS).

  2. Execute o seguinte comando para criar um novo utilizador:

    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. Atualize a licença do GitLab

Muitas funcionalidades do GitLab requerem uma licença "Ultimate" para funcionar. Neste passo, vai substituir a licença temporária enviada com o GDC pela licença do site. Ative o GitLab EE com um ficheiro de licença ou uma chave que contenha detalhes completos.

A chave de licença do site que recebeu é um ficheiro de texto ASCII codificado em base64 com uma extensão .gitlab-license. Vai usar esta chave para ativar o GitLab.

  1. Inicie sessão na consola Web do GitLab como ioadmin.
  2. Na barra de navegação, selecione Menu e, de seguida, Administração.
  3. No menu de navegação, selecione Definições e, de seguida, Geral.
  4. Na área Adicionar licença, adicione uma licença carregando o ficheiro ou introduzindo a chave.
  5. Selecione a caixa de verificação dos Termos de Utilização.
  6. Selecione Adicionar licença.

23.6. Configure o repositório do GitLab

O ConfigSync gere objetos Kubernetes no cluster de administrador principal e nos clusters de administrador da organização, e está configurado para ler a partir do repositório de IaC da nuvem distribuída fornecido pelo GitLab no cluster de administrador principal.

Temos de configurar as pastas iniciais do GitLab para que o Configsync consuma as configurações e as aplique ao cluster do Kubernetes necessário.

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

Siga os passos para criar a estrutura de ficheiros inicial:

  1. Abra o repositório iac em "Menu -> Explorar projetos".

  2. Abra o "IDE Web".

  3. Crie um ficheiro em /infrastructure/zonal/zones/${anchor_zone_name}/root-admin/kustomization.yaml com o seguinte conteúdo:

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

  4. Clique no botão "Confirmar".

  5. Selecione "Commit to the main branch" e confirme.

23.7. Configure a aprovação de várias partes (AVP)

Use esta secção para configurar o sistema de modo a exigir aprovação em todos os pedidos de união ao repositório iac e impedir commits diretos (sem criar um pedido de união) ao ramo main para aplicar a aprovação de várias partes (AVP).

23.7.1. Ative a aprovação de pedidos de união no GitLab

  1. Navegue para o repositório iac.

  2. Use o IDE Web para criar um ficheiro denominado CODEOWNERS na pasta raiz e adicione o grupo Distributed Cloud como proprietários do repositório como primeiro passo:

    [Repository Owners]
* @gdch

    Apenas os utilizadores adicionados ao ficheiro CODEOWNERS podem aprovar pedidos de união no repositório iac. Este ficheiro genérico destina-se apenas a fins de configuração. As instruções mais detalhadas para autorizações de aprovação detalhadas estão descritas no artigo IAC-R0007.

  3. Clique no botão Confirmar.

  4. Selecione Consolidar no ramo principal e confirme.

  5. Para adicionar mais utilizadores ao ficheiro CODEOWNERS, crie um pedido de união a ser aprovado pelos utilizadores existentes em CODEOWNERS.

23.8. Associe o Active Directory Federation Services (ADFS) ao GitLab

Pode associar o ADFS ao GitLab com um cliente SAML através da framework Auth do GitLab.

Se estiver a usar uma autoridade de certificação privada para o seu fornecedor de identidade, tem de a adicionar à instância do GitLab. Obtenha a versão base64 do certificado da AC do ADFS e coloque-a num segredo.

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. Configure o ADFS para a autenticação SAML

Antes de associar o GitLab ao ADFS através da configuração do Helm, o ADFS tem de criar um cliente SAML. Na instância do Windows, siga estes passos:

  1. Execute a app AD FS Management como administrador.

    Clique em Executar como administrador.

  2. No diretório AD FS, clique na pasta Relying Party Trust. No painel Ações, clique em Adicionar confiança da parte fidedigna.

  3. É aberto o assistente Adicionar confiança de parte fidedigna. No primeiro passo, selecione Reivindicações ativadas e clique em Iniciar.

  4. Selecione Introduzir dados sobre a parte fidedigna manualmente e clique em Seguinte.

  5. Introduza algumas informações reconhecíveis sobre a instância do ADFS nos campos Nome a apresentar e Notas. Clique em Seguinte.

  6. Ignore o passo Configurar certificado clicando em Seguinte.

  7. Clique na caixa de verificação Ativar suporte para o protocolo WebSSO SAML 2.0. No campo URL do serviço de SSO SAML 2.0 da parte fidedigna, introduza o seguinte: https://iac.GDC_URL/users/auth/saml/callback.

    Substitua GDC_URL pelo URL da organização no GDC.

  8. Atribua um nome à IaC e adicione o seguinte:

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

  9. Clique em Seguinte para os passos Configurar identificadores, Escolher política de controlo de acesso e Pronto para adicionar confiança para concluir o assistente.

      # 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. O ecrã é atualizado com a confiança da parte fidedigna recém-criada. Clique com o botão direito do rato no item e selecione Editar política de emissão de reivindicações.

    Lista de relações de confiança com partes fidedignas com colunas Ativado, Tipo, Identificador e Política de controlo de acesso

  11. Clique no botão Adicionar regra. No passo Escolher tipo de regra, selecione o Modelo de regra de reivindicação de Enviar atributos LDAP como reivindicações. Clique em Seguinte.

  12. No passo Configurar regra de reivindicação, preencha os seguintes parâmetros:

    1. No campo Nome da regra de reivindicação, introduza Email.
    2. Na lista Armazenamento de atributos, selecione Active Directory.
    3. Na tabela Mapeamento de atributos LDAP para tipos de reivindicações de saída, na coluna Atributo LDAP, selecione ou escreva E-Mail-Addresses.

    4. Na coluna Tipo de reivindicação de saída da tabela, selecione ou escreva E-Mail Address.

    5. Conclua o assistente.

  13. Clique no botão Adicionar regra.

  14. Clique com o botão direito do rato no item e clique novamente em Editar política de emissão de reivindicações no item.

  15. No passo Escolher tipo de regra, selecione o modelo de regra de reivindicação de Transformar uma reivindicação recebida. Clique em Seguinte.

  16. No passo Configurar regra de reivindicação, preencha os seguintes parâmetros:

    1. No campo Nome da regra de reivindicação, introduza Transform email to nameid.
    2. No campo Tipo de reivindicação recebida, selecione ou escreva E-Mail Address.
    3. No campo Tipo de reivindicação de saída, selecione ou escreva Name ID.
    4. No campo Formato do ID do nome de saída, selecione ou escreva Persistent Identifier.

    5. Selecione a opção Transmitir todos os valores de reivindicação.

    6. Conclua o assistente.

23.8.2. Adicione a configuração SAML ao GitLab

Esta secção indica os passos para adicionar a configuração SAML ao Gitlab.

23.8.2.1. Registe o GitLab no Fornecedor de identidade

Abra a configuração do cliente SAML no ADFS. O GitLab requer os seguintes valores para a integração com o seu IdP:

  • assertion_customer_service_url: o IdP redireciona para este URL após a autenticação do utilizador. Define para https://iac.GDC_URL/users/auth/saml/callback.

    Substitua GDC_URL pelo URL da organização no GDC.

  • idp_cert_fingerprint: o GitLab usa esta impressão digital para validar o certificado de uma mensagem SAML recebida. Para encontrar o idp_cert_fingerprint no ADFS, siga estes passos:

    1. Execute a app AD FS Management como administrador.

    2. Na árvore de diretórios AD FS > Serviço > Certificados, clique na pasta Certificados. Vê um certificado na secção Assinatura de tokens. Clique com o botão direito do rato nesse certificado e selecione Ver certificado.

      ADFS view certificate.

    3. Na janela Certificado, aceda ao separador Details. Desloque a página até ver um item denominado Thumbprint. Clique no item e copie o conteúdo apresentado na consola.

      ADFS get thumbprint.

  • idp_sso_target_url - O GitLab vai segmentar este ponto final quando fizer a autenticação por SAML. Para encontrar o idp_sso_target_url no ADFS, siga estes passos:

    1. Execute a app AD FS Management como administrador.

    2. Clique na pasta Endpoints na árvore de diretórios AD FS > Service

      Pontos finais.

      ADFS get endpoints.

    3. No ecrã central, procure uma linha com o tipo SAML 2.0/WS-Federation. O ponto final de destino é o URL do ADFS e o ponto final de destino. Por exemplo, se o nome de domínio da sua instância for https://ocit.gdch.test/ e o ponto final de destino for /adfs/ls, o idp_sso_target_url é https://ocit.gdch.test/adfs/ls.

  • issuer: o URL que o GitLab usa para se identificar. Use https://iac.GDC_URL.

    Prepare os valores do IdP anteriores e escreva-os numa configuração personalizada denominada custom_saml.yaml. Edite este ficheiro YAML para obter a configuração necessária para o seu cliente 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 tiver tudo pronto, aplique a configuração como um segredo denominado 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

    Pode usar o segredo quando criar subcomponentoverride.yaml. Saiba mais sobre as variáveis na documentação do 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

Esta ação cria a substituição do subcomponente. Para verificar se a configuração foi criada, execute o seguinte comando: sh kubectl get subcomponentoverride -n root

O resultado é semelhante ao seguinte:

NAME            AGE
iac-gitlab   1s

23.8.2.2. Inicialize o primeiro utilizador SAML com sessão iniciada

A ativação do SAML remove o início de sessão local. Os utilizadores têm de seguir os procedimentos de acesso de emergência para reativar o início de sessão local e voltar a ter acesso ao ioadmin.

Os primeiros administradores inicializados criados em Criar utilizadores administradores funcionam sem modificações adicionais como administradores. Não devem ter acesso ao projeto. Para adicionar utilizadores ao projeto Distributed Cloud, siga o artigo Integre um novo utilizador do ADFS.

23.8.3. Valide a ligação ADFS

  1. Verifique o estado dos pods do GitLab:webservice

    kubectl --kubeconfig $KUBECONFIG get pod -l app=webservice,release=gitlab -n gitlab-system
    NOME PRONTO ESTADO REINÍCIOS IDADE
    gitlab-webservice-default-5d99b4d7c7-9fmln 2/2 Em execução 0 4m6s
    gitlab-webservice-default-5d99b4d7c7-w99p4 2/2 Em execução 0 96s
    gitlab-webservice-default-7884d4c8b9-qjhtv 2/2 A terminar 0 18h

  2. Aceda a https://iac.GDC_URL e verifique se vê este ecrã, que apresenta o botão ADFS SAML para usar o início de sessão único e não apresenta campos de utilizador e palavra-passe de início de sessão direto.

  3. Clique em ADFS SAML. Verifique se lhe é pedido para iniciar sessão no ADFS.

  4. Depois de iniciar sessão no ADFS, verifique se tem sessão iniciada no GitLab e se já pode interagir com a aplicação.

23.9. Bloqueie a conta de administrador do dia 0

Depois de ativar o SAML, desative a autenticação por palavra-passe para a interface Web e, em seguida, reponha a palavra-passe para ioadmin, uma vez que o acesso à API persiste.

  1. Execute o seguinte 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. Armazene a nova palavra-passe no segredo 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)"'}]'

Use contas no OI ADFS para iniciar sessão.

23.10. Configure a IaC da zona de associação

Esta secção descreve os passos para configurar a IaC na zona de junção da implementação.

23.11. Pré-requisitos

Antes de configurar a zona de associação, tem de iniciar o cluster de administrador raiz.

23.12. Configure a credencial do Config Sync

Siga estes passos para configurar as credenciais do Config Sync:

  1. Faça a ligação ao cluster de administrador principal da zona de ancoragem.

  2. Recupere as credenciais do 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. Copie o ficheiro iac-creds-replica.json.

  4. Faça a ligação ao cluster de administrador principal da zona de associação.

  5. Cole o ficheiro iac-creds-replica.json.

  6. Aplique as credenciais do Config Sync ao cluster de administrador principal:

    # 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. Certifique-se de que a credencial do Config Sync está configurada:

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

23.13. Configure a origem de confiança do Config Sync

Siga estes passos para configurar a origem de referência do Config Sync:

  1. Faça a ligação ao cluster de administrador principal da zona de ancoragem.

  2. Obtenha o FQDN do GitLab:

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

  3. Faça a ligação ao cluster de administrador principal da zona de associação.

  4. Crie o ficheiro 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. Configure o destino do Config Sync:

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

  6. Certifique-se de que o repositório Git do Config Sync está configurado:

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

  7. Certifique-se de que o Config Sync não tem erros nas zonas de união e de âncora.

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

    1. Se root-sync contiver o erro KNV2004, o caminho do diretório usado pela âncora ou pela zona de junção não existe no repositório iac. Encontre o diretório necessário executando o seguinte comando:

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

    2. Crie o caminho gerado pelo comando anterior no repositório iac e adicione um ficheiro kustomization.yaml genérico. Em seguida, faça a união com a ramificação main.

    3. Volte a executar o comando get RootSync original para garantir que o Config Sync não tem erros.