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

Tempo estimado para a conclusão: 60 minutos

Proprietário do componente operacional: IAC

Perfil de habilidade: engenheiro de implantação

A Infraestrutura como código (IaC) no Google Distributed Cloud (GDC) com isolamento físico consiste em dois sistemas:

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

  • O GitLab hospeda um repositório Git que serve como fonte da verdade (SoT, na sigla em inglês) para o Config Sync. Um cluster de destino é um cluster que o Config Sync gerencia 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, na sigla em inglês) em mudanças de política e configuração.

Os dois tipos de zonas a seguir estão envolvidos em uma implantação:

  • Zona de ancoragem: a zona que já faz parte do plano de controle global. A primeira zona é a zona de ancoragem de uma implantação.
  • Zona de junção: a zona que está entrando no plano de controle global.

O Config Sync gerencia objetos do Kubernetes nos clusters root-admin e organization-admin. Ele está configurado para ler do repositório de IaC do Distributed Cloud fornecido pelo GitLab no cluster root-admin principal.

O Distributed Cloud instala a IaC durante a inicialização. Execute as etapas manuais a seguir para concluir a configuração da IaC.

23.1. Configurar a primeira IaC de zona

Esta seção inclui etapas para configurar a IaC na primeira zona de implantação.

23.2. Pré-requisitos

  • Inicializou o cluster de administrador raiz.
  • Crie um cliente SAML na instância do Active Directory Federation Services (ADFS) da OC IT como o cliente de federação de identidade no GitLab.

23.3. Acesso ao GitLab no dia 0

  1. Abra o console da Web do GitLab em https://iac.GDC_URL. GDC_URL é o domínio especificado na 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 usuário do dia 0: ioadmin.

  3. Execute o comando a seguir para receber a senha:

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

  4. Faça login e acesse Menu > Projetos > Explorar projetos gdch / iac para verificar se o repositório Git iac foi criado.

23.4. Criar usuários administradores

  1. Crie usuários administradores dedicados no ADFS. Não use esses cookies para fins não administrativos, e eles precisam ter uma extensão "-ga". Os usuários administradores iniciais PRECISAM usar o mesmo email aqui que usam nos Serviços de Federação do Active Directory (ADFS).

  2. Execute o comando a seguir para criar um novo usuário:

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

Muitos recursos do GitLab exigem uma licença "Ultimate" para funcionar. Nesta etapa, você vai substituir a licença temporária enviada com o GDC pela licença do site. Ativar o GitLab EE com um arquivo de licença ou chave contém todos os detalhes.

A chave de licença do site que você recebeu é um arquivo de texto ASCII codificado em base64 com uma extensão .gitlab-license. Você vai usar essa chave para ativar o GitLab.

  1. Faça login no console da Web do GitLab como ioadmin.
  2. Na barra de navegação, selecione Menu e depois Administrador.
  3. No menu de navegação, selecione Configurações e depois Geral.
  4. Na área "Adicionar licença", faça upload do arquivo ou insira a chave.
  5. Marque a caixa de seleção dos Termos de Serviço.
  6. Selecione "Adicionar licença".

23.6. Configurar o repositório do GitLab

O ConfigSync gerencia objetos do Kubernetes no cluster root-admin e nos clusters org-admin e está configurado para ler do repositório de IaC do Distributed Cloud fornecido pelo GitLab no cluster root-admin.

Precisamos 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 as etapas para criar a estrutura de arquivos inicial:

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

  2. Abra a "Web IDE".

  3. Crie um arquivo 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 "Confirmar na ramificação principal" e confirme.

23.7. Configurar a aprovação de outra parte (MPA)

Use esta seção para configurar o sistema de modo que seja necessária a aprovação de todas as solicitações de mesclagem no repositório iac e impedir commits diretos (sem criar uma solicitação de mesclagem) na ramificação main para aplicar a aprovação por várias partes (MPA).

23.7.1. Ativar a aprovação de solicitação de mesclagem no GitLab

  1. Navegue até o repositório iac.

  2. Use o IDE da Web para criar um arquivo chamado CODEOWNERS na pasta raiz e adicione o grupo do Distributed Cloud como proprietário do repositório como primeira etapa:

    [Repository Owners]
* @gdch

    Somente os usuários adicionados ao arquivo CODEOWNERS podem aprovar solicitações de fusão no repositório iac. Esse arquivo genérico é apenas para fins de configuração. Instruções mais detalhadas sobre permissões de aprovação refinadas estão em IAC-R0007.

  3. Clique no botão Confirmar.

  4. Selecione Fazer commit na ramificação principal e confirme.

  5. Para adicionar mais usuários ao arquivo CODEOWNERS, crie uma solicitação de mesclagem para ser aprovada pelos usuários atuais em CODEOWNERS.

23.8. Conectar os Serviços de Federação do Active Directory (ADFS) ao GitLab

É possível conectar o ADFS ao GitLab com um cliente SAML usando o framework Auth do GitLab.

Se você estiver usando uma autoridade de certificação particular para seu provedor de identidade, adicione-a à instância do GitLab. Extraia a versão base64 do certificado da CA do ADFS e coloque-a em um 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. Configurar o ADFS para autenticação SAML

Antes de conectar o GitLab ao ADFS usando a configuração do Helm, o ADFS precisa criar um cliente SAML. Na sua instância do Windows, siga estas etapas:

  1. Execute o app Gerenciamento do AD FS como administrador.

    Clique em &quot;Executar como administrador&quot;.

  2. No diretório AD FS, clique na pasta Relying Party Trust. No painel Ações, clique em Adicionar confiança de terceiros confiáveis.

  3. O Assistente para adicionar relação de confiança com terceira parte confiável é aberto. Na primeira etapa, selecione Claims aware e clique em Start.

  4. Selecione Inserir dados sobre terceiros confiáveis manualmente e clique em Próxima.

  5. Insira algumas informações reconhecíveis sobre a instância do ADFS nos campos Nome de exibição e Observações. Clique em Next.

  6. Pule a etapa Configurar certificado clicando em Próxima.

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

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

  8. Dê um nome para a IaC e adicione o seguinte:

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

  9. Clique em Próxima nas etapas Configurar identificadores, Escolher política de controle 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. A tela é atualizada com a relação de confiança com a parte confiável recém-criada. Clique com o botão direito do mouse no item e selecione Editar política de emissão de declarações.

    Lista de confianças de terceiros com as colunas &quot;Ativado&quot;, &quot;Tipo&quot;, &quot;Identificador&quot; e &quot;Política de controle de acesso&quot;

  11. Clique no botão Adicionar regra. Na etapa Escolher tipo de regra, selecione o Modelo de regra de declaração de Enviar atributos LDAP como declarações. Clique em Próxima.

  12. Na etapa Configurar regra de declaração, preencha os seguintes parâmetros:

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

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

    5. Conclua o assistente.

  13. Clique no botão Adicionar regra.

  14. Clique com o botão direito do mouse no item e clique em Editar política de emissão de declaração novamente.

  15. Na etapa Escolher tipo de regra, selecione o Modelo de regra de declaração de Transformar uma reivindicação recebida. Clique em Avançar.

  16. Na etapa Configurar regra de declaração, preencha os seguintes parâmetros:

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

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

    6. Conclua o assistente.

23.8.2. Adicionar configuração SAML ao GitLab

Nesta seção, mostramos as etapas para adicionar a configuração do SAML ao GitLab.

23.8.2.1. Registrar o GitLab no provedor de identidade

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

  • assertion_customer_service_url: o IdP redireciona para esse URL depois de autenticar o usuário. Defina como https://iac.GDC_URL/users/auth/saml/callback.

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

  • idp_cert_fingerprint: o GitLab usa essa impressão digital para verificar o certificado de uma mensagem SAML recebida. Para encontrar o idp_cert_fingerprint no ADFS, siga estas etapas:

    1. Execute o app AD FS Management como administrador.

    2. Na árvore de diretórios AD FS > Serviço > Certificados, clique na pasta Certificados. Você vai encontrar um certificado na seção Token-signing. Clique com o botão direito do mouse no certificado e selecione Exibir certificado.

      Certificado de visualização do ADFS.

    3. Na janela Certificado, acesse a guia Details. Role a lista até encontrar um item chamado Thumbprint. Clique no item e copie o conteúdo exibido no console.

      ADFS get thumbprint.

  • idp_sso_target_url: o GitLab vai segmentar esse endpoint ao autenticar por SAML. Para encontrar o idp_sso_target_url no ADFS, siga estas etapas:

    1. Execute o app Gerenciamento do AD FS como administrador.

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

      Endpoints.

      ADFS get endpoints.

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

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

    Prepare os valores de IdP anteriores e grave-os em uma configuração personalizada chamada custom_saml.yaml. Edite esse arquivo YAML para receber a configuração necessária para 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 estiver tudo pronto, aplique a configuração como um secret chamado 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

    É possível usar o secret ao criar subcomponentoverride.yaml. Saiba mais sobre variáveis na documentação do GitLab (em inglês).

    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

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

O resultado será assim:

NAME            AGE
iac-gitlab   1s

23.8.2.2. Inicializar o primeiro usuário SAML conectado

A ativação do SAML remove o login local. Os usuários precisam seguir os procedimentos de acesso de emergência para reativar o login local e recuperar o acesso ao ioadmin.

Os primeiros administradores inicializados criados em Criar usuários administradores vão funcionar sem mais modificações. Eles não podem ter acesso ao projeto. Para adicionar usuários ao projeto do Distributed Cloud, siga as etapas em Integrar um novo usuário do ADFS.

23.8.3. Verificar a conexão do ADFS

  1. Verifique o status dos pods webservice do GitLab:

    kubectl --kubeconfig $KUBECONFIG get pod -l app=webservice,release=gitlab -n gitlab-system
    NOME READY STATUS REINICIALIZAÇÕES 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 Encerrando 0 18h

  2. Acesse https://iac.GDC_URL e verifique se a tela exibida tem o botão SAML do ADFS para usar o login por SSO e não tem campos de nome de usuário e senha de login direto.

  3. Clique em SAML do ADFS. Verifique se você precisa fazer login no ADFS.

  4. Depois de fazer login no ADFS, verifique se você também fez login no GitLab e se já pode interagir com o aplicativo.

23.9. Bloquear a conta de administrador do Dia 0

Depois que o SAML for ativado, desative a autenticação por senha na interface da Web e redefina a senha de ioadmin, já que o acesso à API persiste.

  1. Execute o script a seguir.

      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 senha no 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)"'}]'

Use contas no OI ADFS para fazer login.

23.10. Configurar a IaC da zona de junção

Nesta seção, descrevemos as etapas para configurar a IaC na zona de junção da implantação.

23.11. Pré-requisitos

Antes de configurar a zona de junção, é necessário fazer o bootstrap do cluster de administrador raiz.

23.12. Configurar credencial do configsync

Siga estas etapas para configurar as credenciais do Config Sync:

  1. Conecte-se ao cluster de administrador raiz 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 arquivo iac-creds-replica.json.

  4. Conecte-se ao cluster de administrador raiz da zona de junção.

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

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

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

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

23.13. Configurar a fonte de verdade do Config Sync

Siga estas etapas para configurar a fonte da verdade do Config Sync:

  1. Conecte-se ao cluster de administrador raiz da zona de ancoragem.

  2. Encontre o FQDN do GitLab:

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

  3. Conecte-se ao cluster de administrador raiz da zona de junção.

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

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

  6. Verifique se 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. Verifique se o Config Sync não tem erros nas zonas de ancoragem e de junção.

    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 zona de junção não vai existir no repositório iac. Encontre o diretório necessário executando:

      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 arquivo kustomization.yaml genérico. Em seguida, faça a mesclagem com a ramificação main.

    3. Execute novamente o comando get RootSync original para garantir que o Config Sync não tenha erros.