Esta página se ha traducido con Cloud Translation API.

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

Tiempo estimado para completarlo: 60 minutos

Propietario del componente operable: IAC

Perfil de habilidades: ingeniero de implementaciones

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

Config Sync es un componente que se usa en la infraestructura como código (IaC) de Distributed Cloud para gestionar recursos a nivel de clúster y servicios compartidos.
GitLab aloja un repositorio de Git que actúa como fuente de información principal de Config Sync. Un clúster de destino es un clúster que Config Sync gestiona desde la fuente de información veraz del 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 incluyen los dos tipos de zonas siguientes:

Zona de anclaje: 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: la zona que se une al plano de control global.

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

Distributed Cloud instala IaC durante el arranque. Sigue los pasos manuales que se indican a continuación para finalizar la configuración de IaC.

23.1. Configurar la primera zona de IaC

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

23.2. Requisitos previos

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

23.3. Acceso el día 0 a GitLab

Abre la consola web de GitLab en https://iac.GDC_URL. GDC_URL es el dominio que se ha especificado en el 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}')

Usa el nombre de usuario del día 0: ioadmin.

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)

Inicia sesión y ve a Menú > Proyectos > Explorar proyectos gdch/iac para comprobar que se ha creado el repositorio de Git iac.

23.4. Crear usuarios administradores

Crea usuarios administradores específicos en ADFS. No debes usarlas con fines no administrativos y deben tener la extensión "-ga". Ten en cuenta que los usuarios administradores iniciales DEBEN usar el mismo email aquí que en Active Directory Federation Services (ADFS).

Ejecuta el siguiente comando para crear un usuario:

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

Muchas funciones de GitLab requieren una licencia Ultimate para funcionar. En este paso, sustituirás la licencia temporal incluida en GDC por la licencia del sitio. En el artículo Activar GitLab EE con un archivo de licencia o una clave se incluyen todos los detalles.

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

Inicia sesión en la consola web de GitLab como ioadmin.
En la barra de navegación, seleccione Menú y, a continuación, Administrar.
En el menú de navegación, selecciona Configuración y, a continuación, General.
En el área Añadir licencia, añade una licencia subiendo el archivo o introduciendo la clave.
Selecciona la casilla de verificación de los Términos del Servicio.
Selecciona Añadir licencia.

23.6. Configurar un repositorio de GitLab

ConfigSync gestiona objetos de Kubernetes en clústeres de administrador raíz y de administrador de organización, y está configurado para leer del repositorio de IaC de Distributed Cloud proporcionado por GitLab en el clúster de administrador raíz.

Tenemos que configurar las carpetas iniciales de GitLab para que Configsync pueda usar las configuraciones y aplicarlas al clúster de Kubernetes necesario.

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:

Abre el repositorio iac desde "Menú -> Explorar proyectos".
Abre el IDE web.
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
```
Haz clic en el botón "Confirmar".
Selecciona "Commit to the main branch" (Confirmar en la rama principal) y confirma.

23.7. Configurar la aprobación multiparte

Usa esta sección para configurar el sistema de forma que se exija la aprobación de cada solicitud de combinación en el repositorio iac y se impidan las confirmaciones directas (sin crear una solicitud de combinación) en la rama main para aplicar la aprobación multiparte.

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

Ve al repositorio iac.
Usa el IDE web para crear un archivo llamado CODEOWNERS en la carpeta raíz y añade el grupo Distributed Cloud como propietario del repositorio.
```
[Repository Owners]
* @gdch
```
Solo los usuarios añadidos 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 incluyen instrucciones más detalladas sobre los permisos de aprobación específicos.
Haz clic en el botón Confirmar.
Selecciona Confirmar en la rama principal y confirma la acción.
Para añadir más usuarios al archivo CODEOWNERS, crea una solicitud de combinación que deban aprobar los usuarios que ya estén en CODEOWNERS.

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

Puedes conectar ADFS a GitLab con un cliente SAML mediante el framework Auth de GitLab.

Si usas una autoridad de certificación privada para tu proveedor de identidades, debes añadirla a la instancia de GitLab. Obtén la versión 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. Configurar ADFS para la autenticación SAML

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

Ejecuta la aplicación Administración de AD FS como administrador.
En el directorio AD FS, haz clic en la carpeta Relación de confianza para usuario autenticado. En el panel Acciones, haga clic en Agregar veracidad del usuario de confianza.
Se abrirá el asistente para agregar veracidad del usuario de confianza. En el primer paso, selecciona Reclamaciones y haz clic en Empezar.
Selecciona Introducir manualmente los datos sobre el usuario de confianza y haz clic en Siguiente.
Escribe información reconocible sobre la instancia de ADFS en los campos Nombre visible y Notas. Haz clic en Siguiente.
Omite el paso Configurar certificado haciendo clic en Siguiente.
Marca la casilla Habilitar la compatibilidad con el protocolo WebSSO de SAML 2.0. En el campo URL del servicio de inicio de sesión único SAML 2.0 de la parte de confianza, introduce lo siguiente: https://iac.GDC_URL/users/auth/saml/callback.

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

Asigna un nombre a IaC y añade lo siguiente:

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

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

Nota: Para saltarte pasos en la página Configurar identificadores, añade los siguientes identificadores de Relying Party:
```
  # Replace GDC_URL with the cells URL, for example, bert.sesame.street
  https://iac.GDC_URL
  https://iac.GDC_URL/users/auth/saml/callback
```
La pantalla se actualiza con la confianza de la parte verificadora que acabas de crear. Haz clic con el botón derecho en el elemento y selecciona Editar política de emisión de reclamaciones.
Haz clic en el botón Añadir regla. En el paso Elegir tipo de regla, selecciona la Plantilla de regla de notificación de Enviar atributos LDAP como notificaciones. Haz clic en Siguiente.
En el paso Configurar regla de reclamación, completa los siguientes parámetros:
1. En el campo Nombre de la regla de reclamación, introduce Email.
2. En la lista Almacén de atributos, selecciona Active Directory.
3. En la tabla Asignación de atributos LDAP a tipos de reclamaciones salientes, en la columna Atributo LDAP, seleccione o escriba E-Mail-Addresses.
4. En la columna Tipo de reclamación saliente de la tabla, seleccione o escriba E-Mail Address.
5. Finaliza el asistente.
Haz clic en el botón Añadir regla.
Haz clic con el botón derecho en el elemento y, de nuevo, en Editar política de emisión de reclamaciones.
En el paso Elegir tipo de regla, selecciona la Plantilla de regla de notificación de Transformar una notificación entrante. Haz clic en Siguiente.
En el paso Configurar regla de reclamación, completa los siguientes parámetros:
1. En el campo Nombre de la regla de reclamación, introduce Transform email to nameid.
2. En el campo Tipo de reclamación entrante, seleccione o escriba E-Mail Address.
3. En el campo Tipo de notificación saliente, selecciona o escribe Name ID.
4. En el campo Formato de ID de nombre saliente, selecciona o escribe Persistent Identifier.
5. Selecciona la opción Transferir todos los valores de las reclamaciones.
6. Finaliza el asistente.

23.8.2. Añadir configuración de SAML a GitLab

En esta sección se indican los pasos para añadir la configuración de SAML a GitLab.

23.8.2.1. Registrar GitLab en el proveedor de identidades

Abre la configuración de tu cliente SAML en AD FS. GitLab requiere los siguientes valores para integrarse con tu proveedor de identidades:

assertion_customer_service_url: el proveedor de identidades redirige a esta URL después de autenticar al usuario. Asigna el valor https://iac.GDC_URL/users/auth/saml/callback.

Sustituye 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 aplicación AD FS Management como administrador.
2. En el árbol de directorios, vaya a AD FS > Servicio > Certificados y haga 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.
3. En la ventana Certificado, ve a la pestaña Details. Desplázate por la lista hasta que veas un elemento llamado Thumbprint. Haga clic en el elemento y copie el contenido que se muestra en la consola.
idp_sso_target_url: GitLab usará este endpoint para autenticar mediante SAML. Para encontrar el idp_sso_target_url en ADFS, sigue estos pasos:
1. Ejecuta la aplicación Administración de AD FS como administrador.
2. Haga clic en la carpeta Endpoints (Puntos de conexión) en el árbol de directorios AD FS > Service (Servicio).
  
  Endpoints.
3. En la pantalla central, busca una fila con el tipo SAML 2.0/WS-Federation. El endpoint de destino es tu URL de ADFS y el endpoint de destino. Por ejemplo, si el nombre de dominio de tu instancia es https://ocit.gdch.test/ y el endpoint de destino es /adfs/ls, el idp_sso_target_url es https://ocit.gdch.test/adfs/ls.

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

Prepara los valores del proveedor de identidades 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 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 lo tengas todo listo, aplica la 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 al crear subcomponentoverride.yaml. Consulta 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

De esta forma, se crea la sustitución del subcomponente. Para verificar que se ha creado la configuración, ejecuta el siguiente comando: sh kubectl get subcomponentoverride -n root

El resultado debería ser similar al siguiente:

NAME            AGE
iac-gitlab   1s

23.8.2.2. Inicializar el primer usuario de SAML que haya iniciado sesión

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

Los primeros administradores creados en Crear usuarios administradores funcionarán como administradores sin necesidad de hacer más cambios. No deberían tener acceso al proyecto. Para añadir usuarios al proyecto de Distributed Cloud, sigue los pasos que se indican en Incorporar un nuevo usuario desde ADFS.

23.8.3. Verificar la conexión de ADFS

Comprueba el estado de los pods de GitLab webservice:

kubectl --kubeconfig $KUBECONFIG get pod -l app=webservice,release=gitlab -n gitlab-system

NOMBRE	LISTA	ESTADO	EDAD
gitlab-webservice-default-5d99b4d7c7-9fmln	2/2	En ejecución	4m6s
gitlab-webservice-default-5d99b4d7c7-w99p4	2/2	En ejecución	96s
gitlab-webservice-default-7884d4c8b9-qjhtv	2/2	Finalizando	18 h

Ve a https://iac.GDC_URL y comprueba que aparece esta pantalla, en la que se muestra el botón SAML de ADFS para usar el inicio de sesión único y no hay campos de nombre de usuario y contraseña para iniciar sesión directamente.
Haz clic en ADFS SAML. Verifica que se te pide que inicies sesión en ADFS.
Después de iniciar sesión en ADFS, comprueba que has iniciado sesión en GitLab y que ahora puedes interactuar con la aplicación.

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

Una vez que se haya habilitado SAML, inhabilita la autenticación con contraseña para la interfaz web y, a continuación, cambia la contraseña de ioadmin, ya que el acceso a la API persiste.

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}"

Almacena la nueva contraseña 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 cuentas de OI ADFS para iniciar sesión.

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

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

23.11. Requisitos previos

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

23.12. Configurar la credencial de configsync

Sigue estos pasos para configurar las credenciales de Config Sync:

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

Obtén las credenciales de 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

Copia el archivo iac-creds-replica.json.
Conéctate al clúster de administrador raíz de la zona a la que te vas a unir.
Pega el archivo iac-creds-replica.json.

Aplica las credenciales de Config Sync 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

Comprueba que la credencial de Config Sync esté configurada:

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

23.13. Configurar la fuente de información veraz de Config Sync

Sigue estos pasos para configurar la fuente de información de Config Sync:

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

Obtén el FQDN de GitLab:

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

Conéctate al clúster de administrador raíz de la zona a la que te vas a unir.

Crea el archivo 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

Configura el destino de Config Sync:

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

Comprueba que el repositorio de Git de Config Sync esté configurado:

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

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, significa que la ruta del directorio que usa la zona de anclaje o de unión no existe en el repositorio iac. Busca el directorio necesario ejecutando el siguiente comando:
```
kubectl --kubeconfig $JOINING_KUBECONFIG get RootSync \
    -n config-management-system root-sync
    -o jsonpath='{.spec.git.dir}'
```
2. Crea la ruta de salida del comando anterior en el repositorio iac y añade un archivo kustomization.yaml genérico. A continuación, haz una fusión con la rama main.
3. Vuelve a ejecutar el comando get RootSync original para asegurarte de que Config Sync no tiene errores.