Soporte de autenticación Kerberos (SPNEGO) para ubicaciones privadas

Este documento describe cómo configurar el administrador de trabajos de Sintéticos (SJM) para ejecutar monitores con compatibilidad de autenticación de Kerberos. También incluye un tutorial opcional para establecer un Centro de distribución de claves (KDC) de Kerberos y una aplicación web protegida por SPNEGO en una instancia EC2 de Amazon Linux 2023, para que pueda validar la configuración antes de apuntar el administrador de trabajos a su propio dominio.

Valores de marcador de posición

Antes de comenzar, identifique los siguientes valores para su entorno. Reemplace cada marcador de posición con su propio valor dondequiera que aparezca en este documento.

Marcador de posición	Descripción	Ejemplo
`<REALM_NAME>`	Reino de Kerberos (debe estar en mayúsculas)	`KERBTEST.LOCAL`
`<EC2_PRIVATE_IP>`	Dirección IPv4 privada de la instancia EC2	`10.8.9.172`
`<EC2_INTERNAL_HOSTNAME>`	Nombre de dominio completo (FQDN) de la aplicación web	`ip-X-X-X-X.ec2.internal`
`<CLIENT_PRINCIPAL>`	Identidad de Kerberos asignada a los trabajadores de Sintéticos	`synthetics-test`
`<CLIENT_KEYTAB_PATH>`	Ruta completa en el host donde se almacena el keytab del cliente	`/home/ec2-user/kerb-test/synthetics-test.keytab`
`<PRIVATE_LOCATION_KEY>`	Clave de ubicación privada de New Relic	`NRSP-us...`

Requisitos y compatibilidad

La autenticación de Kerberos depende del acceso directo de red al Centro de distribución de claves (KDC), la resolución de DNS interna y los relojes estrechamente sincronizados. Estas restricciones limitan dónde puede ejecutarlo, así que revise los siguientes requisitos antes de comenzar.

Admitimos la autenticación de Kerberos en estos entornos:

Ubicaciones privadas que ejecutan el administrador de trabajos de Sintéticos en un entorno de contenedor de Docker
Ubicaciones privadas que ejecutan el administrador de trabajos de Sintéticos en un entorno de contenedor de Podman

No admitimos la autenticación de Kerberos en estos entornos:

Ubicaciones públicas, que no tienen ruta de red al KDC interno
Entornos del administrador de trabajos de Kubernetes y OpenShift

El administrador de trabajos proporciona credenciales de Kerberos solo a los trabajos de monitor de navegador. Los monitores de API con script y los monitores de ping se ejecutan sin autenticación de Kerberos.

Cada contenedor de tiempo de ejecución del navegador adquiere su propio ticket de Kerberos (a través de kinit, antes del lanzamiento de Chrome), por lo que la ubicación privada también debe cumplir con estos requisitos:

Acceda a su KDC en el puerto 88 de TCP y UDP desde dentro de los contenedores de tiempo de ejecución.
Resuelva los nombres de host de su KDC y de la aplicación objetivo desde el interior de los contenedores de tiempo de ejecución. En los despliegues de Docker, si el DNS interno no los resuelve, asócielos con RUNTIME_EXTRA_HOSTS —esta variable es exclusiva de Docker. Los despliegues de Podman dependen del DNS interno.
Mantenga el reloj del host de la ubicación privada a menos de 5 minutos del reloj del KDC, usando un servicio como chrony. Los contenedores de tiempo de ejecución comparten el reloj del kernel del host, por lo que sincronizar el host es suficiente.

Parte 1: configurar un laboratorio de pruebas de Kerberos (opcional)

Sugerencia

La Parte 1 crea un reino de Kerberos autónomo y una aplicación de prueba protegida para que pueda validar la configuración del administrador de trabajos de principio a fin. No es la ruta de producción y New Relic no administra su KDC. Si ya ejecuta un KDC de Kerberos o un dominio de Active Directory, obtenga el nombre del reino, la dirección del KDC y un keytab de cliente de quien lo administre, y luego pase a la Parte 2.

Instale el servidor KDC de Kerberos y las herramientas de administración en la instancia EC2 del host:

bash

$sudo dnf install -y krb5-server krb5-workstation

Configure /etc/krb5.conf para dirigir las requests del reino a su KDC:

bash

$sudo tee /etc/krb5.conf > /dev/null <<'EOF'
$[libdefaults]
$    default_realm = <REALM_NAME>
$    dns_lookup_realm = false
$    dns_lookup_kdc = false
$    rdns = false
$
$[realms]
$    <REALM_NAME> = {
$        kdc = <EC2_PRIVATE_IP>
$        admin_server = <EC2_PRIVATE_IP>
$    }
$
$[domain_realm]
$    <EC2_INTERNAL_HOSTNAME> = <REALM_NAME>
$EOF

Defina las reglas de puerto y cifrado para el servicio KDC:

bash

$sudo tee /var/kerberos/krb5kdc/kdc.conf > /dev/null <<'EOF'
$[kdcdefaults]
$    kdc_ports = 88
$    kdc_tcp_ports = 88
$
$[realms]
$    <REALM_NAME> = {
$        acl_file = /var/kerberos/krb5kdc/kadm5.acl
$        dict_file = /usr/share/dict/words
$        admin_keytab = /var/kerberos/krb5kdc/kadm5.keytab
$        supported_enctypes = aes256-cts-hmac-sha1-96:normal aes128-cts-hmac-sha1-96:normal
$    }
$EOF

Cree la base de datos e inicie los servicios en segundo plano de KDC:

bash

$# Create the Kerberos database (assign a master password when prompted)
$sudo kdb5_util create -r <REALM_NAME> -s
$
$# Grant admin permissions and enable KDC services on system boot
$echo "*/admin@<REALM_NAME> *" | sudo tee /var/kerberos/krb5kdc/kadm5.acl
$sudo systemctl enable --now krb5kdc kadmin

Genere archivos keytab que contengan credenciales no interactivas tanto para el cliente (worker de Sintéticos) como para el nombre principal de servicio (SPN) del servidor web objetivo:

bash

$mkdir -p /home/ec2-user/kerb-test
$
$# 1. Create client principal & keytab for synthetics runners
$sudo kadmin.local -q "addprinc -randkey <CLIENT_PRINCIPAL>@<REALM_NAME>"
$sudo kadmin.local -q "ktadd -k <CLIENT_KEYTAB_PATH> <CLIENT_PRINCIPAL>@<REALM_NAME>"
$sudo chmod 644 <CLIENT_KEYTAB_PATH>
$
$# 2. Create HTTP service principal name (SPN) keytab for the web server
$sudo kadmin.local -q "addprinc -randkey HTTP/<EC2_INTERNAL_HOSTNAME>@<REALM_NAME>"
$sudo kadmin.local -q "ktadd -k /home/ec2-user/kerb-test/http.keytab HTTP/<EC2_INTERNAL_HOSTNAME>@<REALM_NAME>"
$sudo chown 33:33 /home/ec2-user/kerb-test/http.keytab
$sudo chmod 644 /home/ec2-user/kerb-test/http.keytab

Importante

El modo de archivo del keytab del cliente importa menos de lo que parece: el límite de confianza principal aquí es el acceso al socket de Docker —SJM en sí requiere -v /var/run/docker.sock:/var/run/docker.sock:rw, y cualquiera con ese acceso ya puede leer cualquier archivo en el host como root independientemente de sus bits de permiso. Mantenga el keytab del cliente como propiedad de root, tal como se creó anteriormente, con los permisos 644 —esto coincide con la identidad de ejecución del contenedor de tiempo de ejecución del navegador (UID 2000, GID 0) a través del bit de lectura de grupo. No cambie su propiedad a un usuario diferente con chown, hacerlo puede romper esa coincidencia de grupo y dejar el acceso dependiendo completamente del bit de lectura global. El keytab del servicio HTTP es la propia identidad del servidor web de prueba: asígnele el UID y el GID con los que se ejecuta Apache dentro del contenedor del paso 6 — 33, el usuario www-data en Debian— y mantenga sus permisos en 644 también. No necesita el keytab HTTP para configurar el administrador de trabajos.

Sugerencia

Solo necesita este paso si desea ejecutar un servidor web de prueba en el mismo host para validar la configuración. No lo necesita para configurar el SJM.

Despliegue un contenedor de Apache configurado con mod_auth_gssapi:

bash

$mkdir -p ~/kerb-test/httpd-image && cd ~/kerb-test/httpd-image
$
$cat > kerb-test.conf <<'EOF'
$<Location /kerb-test>
$    AuthType GSSAPI
$    AuthName "Kerberos Login"
$    GssapiCredStore keytab:/etc/krb5-http.keytab
$    Require valid-user
$</Location>
$EOF
$
$cat > Dockerfile <<'EOF'
$FROM debian:bookworm-slim
$RUN apt-get update && \
>    apt-get install -y --no-install-recommends apache2 libapache2-mod-auth-gssapi krb5-user && \
>    a2enmod auth_gssapi && \
>    mkdir -p /var/www/html/kerb-test && \
>    echo '<h1>Kerberos SSO worked</h1>' > /var/www/html/kerb-test/index.html && \
>    rm -rf /var/lib/apt/lists/*
$COPY kerb-test.conf /etc/apache2/conf-enabled/kerb-test.conf
$EXPOSE 80
$CMD ["apache2ctl", "-D", "FOREGROUND"]
$EOF
$
$docker build -t kerb-test-httpd .
$
$docker run -d --name kerb-test-httpd \
>  -p 8080:80 \
>  -v /etc/krb5.conf:/etc/krb5.conf:ro \
>  -v /home/ec2-user/kerb-test/http.keytab:/etc/krb5-http.keytab:ro \
>  kerb-test-httpd

Asegúrese de que el dominio interno se resuelva localmente en el host y verifique que la autenticación Kerberos se complete correctamente:

bash

$# 1. Map internal hostname in /etc/hosts
$echo "<EC2_PRIVATE_IP> <EC2_INTERNAL_HOSTNAME>" | sudo tee -a /etc/hosts
$
$# 2. Verify unauthenticated challenge returns 401 Unauthorized
$curl -i http://<EC2_INTERNAL_HOSTNAME>:8080/kerb-test/
$
$# 3. Test ticket acquisition and end-to-end Kerberos SSO
$kinit -kt <CLIENT_KEYTAB_PATH> <CLIENT_PRINCIPAL>@<REALM_NAME>
$curl --negotiate -u : -i http://<EC2_INTERNAL_HOSTNAME>:8080/kerb-test/

Una prueba exitosa responde con HTTP/1.1 200 OK y muestra el contenido de la página web protegida.

Parte 2: configure el gestor de trabajos de Sintéticos para Kerberos

Para permitir que los contenedores del ejecutor del navegador de Sintéticos resuelvan automáticamente el KDC, adquieran tickets de Kerberos y se autentiquen en los extremos protegidos, agregue las siguientes variables de entorno de Kerberos y el montaje de volumen de keytab al comando que inicia el administrador de trabajos.

Advertencia

Cuando habilita Kerberos en una ubicación privada, cada trabajo de monitor de navegador en esa ubicación recibe el montaje de keytab y las variables de entorno de Kerberos. El administrador de trabajos no filtra las credenciales por monitor ni por URL. Chrome decide qué hosts reciben un ticket de Kerberos basándose solo en KERBEROS_HOST_ALLOWLIST, así que mantenga esa lista de permitidos lo más reducida posible.

Importante

Configure las cuatro variables KERBEROS_* o no configure ninguna. Si solo configura algunos, el administrador de trabajos de Sintéticos no se inicia y registra un error de configuración de Kerberos incompleta.

Comando estándar (sin Kerberos)

bash

$docker run -e PRIVATE_LOCATION_KEY=<PRIVATE_LOCATION_KEY> \
>  -d --restart unless-stopped \
>  -v /var/run/docker.sock:/var/run/docker.sock:rw \
>  newrelic/synthetics-job-manager

Comando requerido (con soporte para Kerberos habilitado)

Agregue las cuatro variables de entorno de KERBEROS_* (-e) y el montaje de volumen del keytab (-v) al comando que ya utiliza para iniciar el administrador de trabajos.

bash

$docker run -d \
>  --name sjm-container \
>  --restart unless-stopped \
>  -e PRIVATE_LOCATION_KEY=<PRIVATE_LOCATION_KEY> \
>  -e KERBEROS_REALM=<REALM_NAME> \
>  -e KERBEROS_KDC=<EC2_PRIVATE_IP> \
>  -e KERBEROS_HOST_ALLOWLIST=<EC2_INTERNAL_HOSTNAME> \
>  -e KERBEROS_KEYTAB_HOST_PATH=<CLIENT_KEYTAB_PATH> \
>  -e RUNTIME_EXTRA_HOSTS=<EC2_INTERNAL_HOSTNAME>:<EC2_PRIVATE_IP> \
>  -v /var/run/docker.sock:/var/run/docker.sock:rw \
>  -v <CLIENT_KEYTAB_PATH>:<CLIENT_KEYTAB_PATH>:ro \
>  newrelic/synthetics-job-manager

Agregue las mismas variables de Kerberos y el montaje de keytab al comando podman run de Instalar el administrador de trabajos. Podman ejecuta el administrador de trabajos en un pod en lugar de montar el socket de Docker, así que mantenga la configuración existente de CONTAINER_ENGINE, PODMAN_API_SERVICE_PORT y PODMAN_POD_NAME.

bash

$podman run -d \
>  --pod SYNTHETICS \
>  --restart unless-stopped \
>  -e PRIVATE_LOCATION_KEY=<PRIVATE_LOCATION_KEY> \
>  -e CONTAINER_ENGINE=PODMAN \
>  -e PODMAN_API_SERVICE_PORT=8000 \
>  -e PODMAN_POD_NAME=SYNTHETICS \
>  -e KERBEROS_REALM=<REALM_NAME> \
>  -e KERBEROS_KDC=<EC2_PRIVATE_IP> \
>  -e KERBEROS_HOST_ALLOWLIST=<EC2_INTERNAL_HOSTNAME> \
>  -e KERBEROS_KEYTAB_HOST_PATH=<CLIENT_KEYTAB_PATH> \
>  -v <CLIENT_KEYTAB_PATH>:<CLIENT_KEYTAB_PATH>:ro,Z \
>  newrelic/synthetics-job-manager

Sugerencia

En los hosts de SELinux, agregue un indicador de reetiquetado para que el contenedor pueda leer el keytab. El administrador de trabajos y cada contenedor de tiempo de ejecución del navegador que lanza se ejecutan dentro del mismo pod (PODMAN_POD_NAME), y Podman comparte una etiqueta de SELinux en todos los contenedores de un pod —por lo que :ro,Z funciona aquí aunque varios contenedores lean el keytab. Use :Z en lugar de :ro,Z, ya que el keytab nunca necesita compartirse con contenedores fuera de este pod. Para obtener más información, consulte la documentación de volúmenes de Podman.

Parte 3: solucionar problemas de autenticación de Kerberos

Si la inicialización de Kerberos falla dentro del contenedor de tiempo de ejecución, la canalización de inicio del contenedor aún realiza el lanzamiento del navegador y ejecuta el monitor. Luego, el monitor falla frente a un extremo protegido con un desafío HTTP 401 o un tiempo de espera de navegación, y agregamos una etiqueta al resultado con una causa raíz de KerberosInitWarning. Debido a que la falla parece un tiempo de espera ordinario, revise los logs de trabajo en busca de los siguientes códigos de error antes de investigar el script del monitor.

Estos códigos son independientes de la validación de inicio de la Parte 2 —si configura solo algunas de las variables de KERBEROS_*, el administrador de trabajos no se iniciará en absoluto y ninguno de estos códigos aparecerá en los logs de un trabajo.

Código de error	Causa	Qué hacer
`KERBEROS_KDC_UNREACHABLE`	El contenedor de tiempo de ejecución no puede comunicarse con el KDC a través de la red.	Compruebe las reglas del firewall para el puerto 88 de TCP y UDP entre el host de su ubicación privada y el KDC.
`KERBEROS_BAD_CREDENTIAL`	El principal no coincide con el keytab, o el keytab está dañado.	Verifique el keytab en el host ejecutando `klist -kt <CLIENT_KEYTAB_PATH>`.
`KERBEROS_CLOCK_SKEW`	El reloj del host difiere del reloj del KDC en más de 5 minutos.	Sincronice el reloj del host con NTP, mediante un servicio como `chrony`.
`KERBEROS_DNS_LOOKUP_FAILED`	El contenedor no puede resolver el nombre de host del KDC ni el reino.	Compruebe la configuración del resolutor de DNS interno para su contenedor del administrador de trabajos, o asigne los hosts con `RUNTIME_EXTRA_HOSTS`.
`KERBEROS_CONFIG_INVALID`	El contenedor de tiempo de ejecución no puede leer el keytab montado, o no se pudo analizar ningún principal a partir de este (un keytab vacío o mal formado).	Verifique que el keytab sea legible dentro del contenedor de tiempo de ejecución y contenga al menos un principal: `klist -kt <CLIENT_KEYTAB_PATH>`.
`KERBEROS_UNKNOWN_FAILURE`	Un error criptográfico o de GSSAPI a nivel del sistema detuvo el protocolo de enlace.	Compare los tipos de cifrado en el keytab del cliente (`klist -kt -e <CLIENT_KEYTAB_PATH>` enumera el enctype de cada entrada) con el valor `supported_enctypes` configurado en el KDC en el paso 3. Una discrepancia entre lo que ofrece el keytab y lo que acepta el KDC causa la mayoría de estas fallas.

Te ofrecemos esta traducción automática para facilitar la lectura.

Soporte de autenticación Kerberos (SPNEGO) para ubicaciones privadas

Valores de marcador de posición

Requisitos y compatibilidad

Parte 1: configurar un laboratorio de pruebas de Kerberos (opcional)

Sugerencia

Paso 1: instalar los paquetes de Kerberos

Paso 2: configurar el Kerberos del sistema (`/etc/krb5.conf`)

Paso 3: configure el daemon de KDC (`kdc.conf`)

Paso 4: inicialice la base de datos maestra y los daemon de KDC

Paso 5: generar los keytabs de cliente y servidor

Importante

(Opcional) Paso 6: desplegar un contenedor web de prueba

Sugerencia

Paso 7: verificar el DNS local y el handshake de Kerberos

Parte 2: configure el gestor de trabajos de Sintéticos para Kerberos

Advertencia

Importante

Comando estándar (sin Kerberos)

Comando requerido (con soporte para Kerberos habilitado)

Docker

Podman

Sugerencia

Parte 3: solucionar problemas de autenticación de Kerberos

Te ofrecemos esta traducción automática para facilitar la lectura.

Soporte de autenticación Kerberos (SPNEGO) para ubicaciones privadas

Valores de marcador de posición .css-21sua1{background:none;border:none;width:0;padding:0;}

Requisitos y compatibilidad

Parte 1: configurar un laboratorio de pruebas de Kerberos (opcional)

Sugerencia

Paso 2: configurar el Kerberos del sistema (/etc/krb5.conf)

Paso 3: configure el daemon de KDC (kdc.conf)

Paso 4: inicialice la base de datos maestra y los daemon de KDC

Paso 5: generar los keytabs de cliente y servidor

(Opcional) Paso 6: desplegar un contenedor web de prueba

Paso 7: verificar el DNS local y el handshake de Kerberos

Parte 2: configure el gestor de trabajos de Sintéticos para Kerberos

Advertencia

Importante

Comando estándar (sin Kerberos)

Comando requerido (con soporte para Kerberos habilitado)

Docker

Podman

Parte 3: solucionar problemas de autenticación de Kerberos

Valores de marcador de posición

Paso 2: configurar el Kerberos del sistema (`/etc/krb5.conf`)

Paso 3: configure el daemon de KDC (`kdc.conf`)