23. Configuración de la infraestructura como código

Tiempo estimado para completar la actividad: 60 minutos

Propietario del componente operable: IAC

Perfil de habilidad: ingeniero de implementación

La infraestructura como código (IaC) en Google Distributed Cloud (GDC) aislado consta de dos sistemas:

  • Config Sync es un componente que se usa en la infraestructura como código (IaC) de Distributed Cloud para administrar los recursos a nivel del clúster y los servicios compartidos.

  • GitLab aloja un repositorio de Git que sirve como fuente de información (SoT) para el Sincronizador de configuración. Un clúster de destino es un clúster que Sincronizador de configuración administra desde la SoT en el repositorio.

    • GitLab incluye un sistema de revisión de código para implementar la aprobación de varias partes (MPA) en los cambios de políticas y configuración.

En una implementación, se involucran los siguientes dos tipos de zonas:

  • Zona de anclaje: Es la zona que ya forma parte del plano de control global. La primera zona es la zona de anclaje de una implementación.
  • Zona de unión: Es la zona que se une al plano de control global.

Sincronizador de configuración administra objetos de Kubernetes en los clústeres root-admin y de administrador de la organización. Está configurado para leer desde el repositorio de IaC de Distributed Cloud que proporciona GitLab en el clúster principal root-admin.

Distributed Cloud instala IaC durante el arranque. Ejecuta los siguientes pasos manuales para completar la configuración de IaC.

23.1. Configura la primera zona de IaC

En esta sección, se incluyen los pasos para configurar la IaC en la primera zona de implementación.

23.2. Requisitos previos

  • Se inició el clúster de administrador raíz.
  • Crea un cliente de SAML en la instancia de Servicios de federación de Active Directory (ADFS) de OC IT como el cliente de federación de identidades en GitLab.

23.3. Acceso el día 0 a GitLab

  1. Abre la consola web de GitLab en https://iac.GDC_URL. GDC_URL es el dominio que se especificó en la 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. Usa el nombre de usuario del día 0: ioadmin.

  3. Ejecuta el siguiente comando para obtener la contraseña:

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

  4. Accede y navega a Menú > Proyectos > Explora proyectos gdch / iac para verificar que se haya creado el repositorio de Git iac.

23.4. Crea usuarios administradores

  1. Crea usuarios administradores dedicados en ADFS. No debes usarlos para fines no administrativos y deben tener la extensión "-ga". Ten en cuenta que tus usuarios administradores iniciales DEBEN usar el mismo email aquí que el que usan en los Servicios de federación de Active Directory (ADFS).

  2. Ejecuta el siguiente comando para crear un usuario nuevo:

    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. Actualiza la licencia de GitLab

Muchas funciones de GitLab requieren una licencia "Ultimate" para funcionar. En este paso, reemplazarás la licencia temporal que se incluye con GDC por la licencia propia del sitio. Activa GitLab EE con un archivo o una clave de licencia contiene todos los detalles.

La clave de licencia del sitio que recibiste es un archivo de texto ASCII codificado en base64 con una extensión .gitlab-license. Usarás esta clave para activar GitLab.

  1. Accede a la consola web de GitLab como ioadmin.
  2. En la barra de navegación, selecciona Menú y, luego, Administrador.
  3. En el menú de navegación, selecciona Configuración y, luego, General.
  4. En el área Add License, agrega una licencia subiendo el archivo o ingresando la clave.
  5. Selecciona la casilla de verificación de las Condiciones del Servicio.
  6. Selecciona Agregar licencia.

23.6. Configura el repositorio de GitLab

ConfigSync administra objetos de Kubernetes en clústeres de administrador raíz y clústeres de administrador de la organización, y está configurado para leer desde el repositorio de IaC de Distributed Cloud que GitLab entrega en el clúster de administrador raíz.

Debemos configurar las carpetas iniciales de GitLab para que Configsync consuma las configuraciones y las aplique al clúster de Kubernetes requerido.

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

Sigue estos pasos para crear la estructura de archivos inicial:

  1. Abre el repositorio iac desde "Menú -> Explorar proyectos".

  2. Abre el "IDE web".

  3. Crea un archivo en /infrastructure/zonal/zones/${anchor_zone_name}/root-admin/kustomization.yaml con el siguiente contenido:

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

  4. Haz clic en el botón “Confirmar”.

  5. Selecciona "Confirmar en la rama principal" y confirma.

23.7. Configura la aprobación de varias partes (MPA)

Usa esta sección para configurar el sistema de modo que exija la aprobación de cada solicitud de combinación en el repositorio iac y evitar cualquier confirmación directa (sin crear una solicitud de combinación) en la rama main para aplicar la aprobación de varias partes (MPA).

23.7.1. Habilita la aprobación de solicitudes de combinación en GitLab

  1. Navega al repositorio iac.

  2. Usa el IDE web para crear un archivo llamado CODEOWNERS en la carpeta raíz y agrega el grupo de Distributed Cloud como propietario del repositorio en el primer paso:

    [Repository Owners]
* @gdch

    Solo los usuarios agregados al archivo CODEOWNERS pueden aprobar solicitudes de combinación en el repositorio iac. Este archivo genérico solo se usa para la configuración. En IAC-R0007, se proporcionan instrucciones más detalladas para los permisos de aprobación detallados.

  3. Haz clic en el botón Confirmar.

  4. Selecciona Confirmar en la rama principal y confirma.

  5. Para agregar más usuarios al archivo CODEOWNERS, crea una solicitud de combinación para que la aprueben los usuarios existentes en CODEOWNERS.

23.8. Conecta los Servicios de federación de Active Directory (ADFS) a GitLab

Puedes conectar ADFS a GitLab con un cliente SAML a través del framework de Auth de GitLab.

Si usas una autoridad de certificación privada para tu proveedor de identidad, debes agregarla a la instancia de GitLab. Obtén la versión en base64 del certificado de la CA de ADFS y colócala en un secreto.

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. Configura ADFS para la autenticación de SAML

Antes de conectar GitLab a ADFS con la configuración de Helm, ADFS debe crear un cliente de SAML. En tu instancia de Windows, sigue estos pasos:

  1. Ejecuta la app de Administración de AD FS como administrador.

    Haz clic en Ejecutar como administrador.

  2. En el directorio AD FS, haz clic en la carpeta Relación de confianza con la parte autenticada. En el panel Actions, haz clic en Add Relying Party Trust.

  3. Se abrirá el Asistente para agregar relación de confianza con la parte autenticada. En el primer paso, selecciona Claims aware y haz clic en Start.

  4. Selecciona Ingresar datos sobre el usuario de confianza de forma manual y haz clic en Siguiente.

  5. Ingresa información reconocible sobre la instancia de ADFS en los campos Nombre visible y Notas. Haz clic en Siguiente.

  6. Haz clic en Siguiente para omitir el paso Configurar certificado.

  7. Haz clic en la casilla de verificación Habilitar compatibilidad con el protocolo SAML 2.0 WebSSO. En el campo URL del servicio SSO SAML 2.0 de la parte autenticada, ingresa lo siguiente: https://iac.GDC_URL/users/auth/saml/callback.

    Reemplaza GDC_URL por la URL de la organización en GDC.

  8. Asigna un nombre a la IaC y agrega lo siguiente:

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

  9. Haz clic en Siguiente en los pasos Configurar identificadores, Elegir política de control de acceso y Listo para agregar confianza para finalizar el asistente.

      # 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. La pantalla se actualizará con la relación de confianza con la parte autenticada que acabas de crear. Haz clic con el botón derecho en tu elemento y selecciona Editar política de emisión de reclamaciones.

    Lista de las relaciones de confianza de terceros con las columnas Habilitado, Tipo, Identificador y Política de control de acceso

  11. Haz clic en el botón Agregar regla y, en el paso Elige un tipo de regla, selecciona la Plantilla de regla de reclamación de Enviar atributos LDAP como reclamaciones. Haga clic en Siguiente.

  12. En el paso Configurar regla de reclamación, completa los siguientes parámetros:

    1. En el campo Nombre de la regla de reclamo, ingresa Email.
    2. En la lista Attribute Store, selecciona Active Directory.
    3. En la tabla Mapping of LDAP attributes to outgoing claim types, en la columna LDAP attribute, selecciona o escribe E-Mail-Addresses.

    4. En la columna Tipo de reclamo saliente de la tabla, selecciona o escribe E-Mail Address.

    5. Finaliza el asistente.

  13. Haz clic en el botón Agregar regla.

  14. Haz clic con el botón derecho en el elemento y, luego, vuelve a hacer clic en Edit Claim Issurance Policy.

  15. En el paso Elige un tipo de regla, selecciona la Plantilla de regla de reclamación de Transformar una reclamación entrante. Haz clic en Siguiente.

  16. En el paso Configurar regla de reclamación, completa los siguientes parámetros:

    1. En el campo Nombre de la regla de reclamo, ingresa Transform email to nameid.
    2. En el campo Tipo de reclamo entrante, selecciona o escribe E-Mail Address.
    3. En el campo Tipo de reclamo saliente, selecciona o escribe Name ID.
    4. En el campo Formato del ID de nombre saliente, selecciona o escribe Persistent Identifier.

    5. Selecciona la opción Pasar todos los valores de la reclamación.

    6. Finaliza el asistente.

23.8.2. Agrega la configuración de SAML a GitLab

En esta sección, se proporcionan los pasos para agregar la configuración de SAML a GitLab.

23.8.2.1. Registra GitLab en el proveedor de identidad

Abre la configuración del cliente SAML en ADFS. GitLab requiere los siguientes valores para integrarse con tu IdP:

  • assertion_customer_service_url: El IdP redirecciona a esta URL después de autenticar al usuario. Establécelo en https://iac.GDC_URL/users/auth/saml/callback.

    Reemplaza GDC_URL por la URL de la organización en GDC.

  • idp_cert_fingerprint: GitLab usa esta huella digital para verificar el certificado de un mensaje SAML entrante. Para encontrar el idp_cert_fingerprint en ADFS, sigue estos pasos:

    1. Ejecuta la app AD FS Management como administrador.

    2. En el árbol de directorios AD FS > Servicio > Certificados, haz clic en la carpeta Certificados. Verás un certificado en la sección Firma de token. Haz clic con el botón derecho en ese certificado y selecciona Ver certificado.

      Ver certificado de ADFS

    3. En la ventana Certificado, ve a la pestaña Details. Desplázate por la lista hasta que veas un elemento llamado Thumbprint. Haz clic en el elemento y copia el contenido que se muestra en la consola.

      Obtén la huella digital de ADFS.

  • idp_sso_target_url: GitLab segmentará este extremo cuando se autentique por SAML. Para encontrar el idp_sso_target_url en ADFS, sigue estos pasos:

    1. Ejecuta la app de Administración de AD FS como administrador.

    2. Haz clic en la carpeta Endpoints en el árbol de directorios AD FS > Service.

      Endpoints

      Son los extremos de obtención de ADFS.

    3. En la pantalla central, busca una fila con el tipo SAML 2.0/WS-Federation. El extremo de destino es tu URL de ADFS y el extremo de destino. Por ejemplo, si el nombre de dominio de tu instancia es https://ocit.gdch.test/ y el extremo de destino es /adfs/ls, el idp_sso_target_url es https://ocit.gdch.test/adfs/ls.

  • issuer: Es la URL que usa GitLab para identificarse. Usa https://iac.GDC_URL

    Prepara los valores del IdP anteriores y escríbelos en una configuración personalizada llamada custom_saml.yaml. Edita este archivo YAML para obtener la configuración necesaria para tu cliente de 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

    Cuando esté todo listo, aplica tu configuración como un secreto llamado 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

    Puedes usar el secreto cuando crees subcomponentoverride.yaml. Obtén más información sobre las variables en la documentación de 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

Esto crea la anulación del subcomponente. Para verificar que se creó la configuración, ejecuta el siguiente comando: sh kubectl get subcomponentoverride -n root

El resultado es similar a este:

NAME            AGE
iac-gitlab   1s

23.8.2.2. Inicializa el primer usuario de SAML que accedió

Si habilitas SAML, se quitará el acceso local. Los usuarios deben seguir los procedimientos de acceso de emergencia para volver a habilitar el acceso local y recuperar el acceso a ioadmin.

Los primeros administradores inicializados que se crearon en Crear usuarios administradores funcionarán como administradores sin más modificaciones. No deberían tener acceso al proyecto. Para agregar usuarios al proyecto de Distributed Cloud, sigue los pasos que se indican en Incorpora un usuario nuevo desde ADFS.

23.8.3. Verifica la conexión de ADFS

  1. Verifica el estado de los pods de GitLab webservice:

    kubectl --kubeconfig $KUBECONFIG get pod -l app=webservice,release=gitlab -n gitlab-system
    NOMBRE READY ESTADO REINICIOS EDAD
    gitlab-webservice-default-5d99b4d7c7-9fmln 2/2 En ejecución 0 4 min 6 s
    gitlab-webservice-default-5d99b4d7c7-w99p4 2/2 En ejecución 0 96 s
    gitlab-webservice-default-7884d4c8b9-qjhtv 2/2 Finalizando 0 18 h

  2. Ve a https://iac.GDC_URL y verifica que veas esta pantalla, que muestra el botón ADFS SAML para usar el acceso con SSO y no muestra los campos directos de usuario y contraseña.

  3. Haz clic en SAML de ADFS. Verifica que se te solicite acceder a ADFS.

  4. Después de acceder a ADFS, verifica que también hayas accedido a GitLab y que ahora puedas interactuar con la aplicación.

23.9. Bloquea la cuenta de administrador del día 0

Después de habilitar SAML, inhabilita la autenticación con contraseña para la interfaz web y, luego, restablece la contraseña de ioadmin, ya que persiste el acceso a la API.

  1. Ejecuta la siguiente secuencia de comandos.

      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. Almacena la contraseña nueva en el secreto 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)"'}]'

Usa las cuentas de OI ADFS para acceder.

23.10. Configura la IaC de la zona de unión

En esta sección, se describen los pasos para configurar la IaC en la zona de unión de la implementación.

23.11. Requisitos previos

Antes de configurar la zona de unión, debes iniciar el clúster de administrador raíz.

23.12. Configura la credencial de configsync

Sigue estos pasos para configurar las credenciales del Sincronizador de configuración:

  1. Conéctate al clúster de administrador raíz de la zona de anclaje.

  2. Recupera las credenciales del Sincronizador de configuración:

    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 el archivo iac-creds-replica.json.

  4. Conéctate al clúster de administrador raíz de la zona que se une.

  5. Pega el archivo iac-creds-replica.json.

  6. Aplica las credenciales del Sincronizador de configuración al clúster de administrador raíz:

    # 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. Asegúrate de que la credencial del Sincronizador de configuración esté configurada:

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

23.13. Configura la fuente de información del Sincronizador de configuración

Sigue estos pasos para configurar la fuente de información del Sincronizador de configuración:

  1. Conéctate al clúster de administrador raíz de la zona de anclaje.

  2. Obtén el FQDN de GitLab:

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

  3. Conéctate al clúster de administrador raíz de la zona que se une.

  4. Crea el archivo SubcomponentOverride de 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 el destino del Sincronizador de configuración:

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

  6. Asegúrate de que el repositorio de Git del Sincronizador de configuración esté configurado:

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

  7. Asegúrate de que Config Sync no tenga errores en las zonas de anclaje y de unión.

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

    1. Si root-sync contiene el error KNV2004, la ruta de directorio que usa la zona de unión o anclaje no existe en el repositorio iac. Para encontrar el directorio requerido, ejecuta lo siguiente:

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

    2. Crea la ruta de acceso que generó el comando anterior en el repositorio iac y agrega un archivo kustomization.yaml genérico. Luego, fusiona la rama main.

    3. Vuelve a ejecutar el comando get RootSync original para asegurarte de que el Sincronizador de configuración no tenga errores.