Prise en charge de l'authentification Kerberos (SPNEGO) pour les sites privés

Ce document décrit comment configurer le gestionnaire de tâches Synthetics (SJM) pour exécuter des moniteurs avec la prise en charge de l’authentification Kerberos. Il inclut également un guide facultatif pour configurer un centre de distribution de clés (KDC) Kerberos, et une application web protégée par SPNEGO sur une instance Amazon Linux 2023 EC2, afin que vous puissiez valider la configuration avant de diriger le gestionnaire de tâches vers votre propre domaine.

Valeurs d’espace réservé

Avant de commencer, identifiez les valeurs suivantes pour votre environnement. Remplacez chaque espace réservé par votre propre valeur partout où il apparaît dans ce document.

Espace réservé	Description	Exemple
`<REALM_NAME>`	Domaine Kerberos (doit être en majuscules)	`KERBTEST.LOCAL`
`<EC2_PRIVATE_IP>`	Adresse IPv4 privée de l'instance EC2	`10.8.9.172`
`<EC2_INTERNAL_HOSTNAME>`	Nom de domaine entièrement qualifié (FQDN) de l’application web	`ip-X-X-X-X.ec2.internal`
`<CLIENT_PRINCIPAL>`	Identité Kerberos attribuée aux workers Synthetics	`synthetics-test`
`<CLIENT_KEYTAB_PATH>`	Chemin complet sur l'hôte où le keytab client est stocké	`/home/ec2-user/kerb-test/synthetics-test.keytab`
`<PRIVATE_LOCATION_KEY>`	Clé de site privé New Relic	`NRSP-us...`

Exigences et compatibilité

L’authentification Kerberos dépend de l’accès réseau direct à votre centre de distribution de clés (KDC), de la résolution DNS interne, et d’horloges étroitement synchronisées. Ces contraintes limitent les endroits où vous pouvez l’exécuter, passez donc en revue les exigences suivantes avant de commencer.

Nous prenons en charge l’authentification Kerberos dans ces environnements :

Sites privés qui exécutent le gestionnaire de tâches Synthetics dans un environnement de conteneur Docker
Sites privés qui exécutent le gestionnaire de tâches Synthetics dans un environnement de conteneur Podman

Nous ne prenons pas en charge l’authentification Kerberos dans ces environnements :

Emplacements publics, qui n’ont aucune route réseau vers votre KDC interne
Environnements de gestionnaire de tâches Kubernetes, et OpenShift

Le gestionnaire de jobs fournit des identifiants Kerberos uniquement aux jobs pour monitorer le navigateur. Les moniteurs d’API scriptés, et les moniteurs de ping s’exécutent sans authentification Kerberos.

Chaque conteneur d’exécution de navigateur acquiert son propre ticket Kerberos (via kinit, avant le lancement de Chrome), votre site privé doit donc également répondre à ces exigences :

Accédez à votre KDC sur le port TCP et UDP 88 depuis l’intérieur des conteneurs d’exécution.
Résolvez votre KDC et les noms d’hôte de l’application cible depuis l’intérieur des conteneurs d’exécution. Sur les déploiements Docker, si le DNS interne ne les résout pas, mappez-les avec RUNTIME_EXTRA_HOSTS (cette variable est spécifique à Docker). Les déploiements Podman dépendent du DNS interne.
Maintenez l’horloge de l’hôte du site privé à moins de 5 minutes de l’horloge du KDC, en utilisant un service tel que chrony. Les conteneurs d’exécution partagent l’horloge du noyau de l’hôte, il suffit donc de synchroniser l’hôte.

Partie 1 : configurer un laboratoire de test Kerberos (facultatif)

Conseil

La partie 1 crée un domaine Kerberos autonome, et une application de test protégée, afin que vous puissiez valider la configuration du gestionnaire de tâches de bout en bout. Il ne s’agit pas du chemin de production, et New Relic ne gère pas votre KDC. Si vous exécutez déjà un KDC Kerberos, ou un domaine Active Directory, obtenez le nom du domaine, l’adresse du KDC, et un keytab client auprès de la personne qui l’administre, puis passez à la partie 2.

Installez le serveur KDC Kerberos et les outils d'administration sur l'instance EC2 hôte :

bash

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

Configurez /etc/krb5.conf pour diriger les requests de domaine vers votre 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

Définissez le port et les règles de chiffrement pour le service 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

Créez la base de données et démarrez les services d'arrière-plan 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

Générez des fichiers keytab contenant des identifiants non interactifs pour le client (worker Synthetics) et le nom de principal du service (SPN) du serveur web cible :

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

Important

Le mode de fichier du keytab client a moins d’importance qu’il n’y paraît : la principale limite de confiance ici est l’accès au socket Docker — SJM lui-même nécessite -v /var/run/docker.sock:/var/run/docker.sock:rw, et toute personne disposant de cet accès peut déjà lire n’importe quel fichier sur l’hôte en tant que root, quels que soient ses bits d’autorisation. Conservez le keytab client sous la propriété de root, tel que créé ci-dessus, avec les autorisations 644 — cela correspond à l’identité d’exécution du conteneur d’exécution du navigateur (UID 2000, GID 0) via le bit de lecture de groupe. Ne le modifiez pas avec chown pour un utilisateur différent, cela peut rompre cette correspondance de groupe, et laisser l’accès dépendre entièrement du bit de lecture universelle. Le keytab du service HTTP est la propre identité du serveur web de test : donnez-lui l’UID, et le GID sous lesquels Apache s’exécute à l’intérieur du conteneur de l’étape 6, 33, l’utilisateur www-data sur Debian, et maintenez ses autorisations à 644 également. Vous n’avez pas besoin du keytab HTTP pour configurer le gestionnaire de tâches.

Conseil

Vous n’avez besoin de cette étape que si vous souhaitez exécuter un serveur web de test sur le même hôte pour valider la configuration. Vous n’en avez pas besoin pour configurer le SJM.

Déployez un conteneur Apache configuré avec 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

Assurez-vous que le domaine interne se résout localement sur l'hôte, et vérifiez que l'authentification Kerberos se termine avec succès :

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/

Un test réussi répond avec HTTP/1.1 200 OK et affiche le contenu de la page web protégée.

Partie 2 : configurer le gestionnaire de tâches Synthetics pour Kerberos

Pour permettre aux conteneurs d'exécuteur de navigateur Synthetics de résoudre automatiquement le KDC, d'acquérir des tickets Kerberos, et de s'authentifier auprès des points de terminaison protégés, ajoutez les variables d'environnement Kerberos et le montage de volume keytab suivants à la commande qui démarre votre gestionnaire de tâches.

Prudence

Lorsque vous activez Kerberos sur un site privé, chaque tâche de monitoring de navigateur sur ce site reçoit le montage du keytab et les variables d’environnement Kerberos. Le gestionnaire de tâches ne filtre pas les identifiants par moniteur, ni par URL. Chrome décide quels hôtes reçoivent un ticket Kerberos en se basant uniquement sur KERBEROS_HOST_ALLOWLIST; gardez donc cette liste d’autorisation aussi restreinte que possible.

Important

Définissez les quatre variables KERBEROS_*, ou n’en définissez aucune. Si vous n’en définissez que certaines, le gestionnaire de jobs Synthetics ne parvient pas à démarrer, et enregistre une erreur de configuration Kerberos incomplète dans les logs.

Commande standard (sans 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

Commande requise (avec la prise en charge de Kerberos activée)

Ajoutez les quatre variables d’environnement KERBEROS_* (-e) et le montage du volume keytab (-v) à la commande que vous utilisez déjà pour démarrer le gestionnaire de tâches.

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

Ajoutez les mêmes variables Kerberos et le même montage keytab à la commande podman run de Installer le gestionnaire de tâches. Podman exécute le gestionnaire de tâches dans un pod plutôt que de monter le socket Docker, conservez donc vos paramètres CONTAINER_ENGINE, PODMAN_API_SERVICE_PORT, et PODMAN_POD_NAME existants.

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

Conseil

Sur les hôtes SELinux, ajoutez un indicateur de réétiquetage afin que le conteneur puisse lire le keytab. Le gestionnaire de tâches et chaque conteneur d’exécution de navigateur dont il effectue le lancement s’exécutent dans le même pod (PODMAN_POD_NAME), et Podman partage une étiquette SELinux entre tous les conteneurs d’un pod ; :ro,Z fonctionne donc ici même si plusieurs conteneurs lisent le keytab. Utilisez :Z plutôt que :ro,Z, car le keytab n’a jamais besoin d’être partagé avec des conteneurs en dehors de ce pod. Pour plus d’informations, consultez la documentation sur les volumes Podman.

Partie 3 : dépanner l’authentification Kerberos

Si l’initialisation de Kerberos échoue à l’intérieur du conteneur d’exécution, le pipeline de démarrage du conteneur procède tout de même au lancement du navigateur, et exécute votre moniteur. Le moniteur échoue ensuite contre un point de terminaison protégé avec un challenge HTTP 401, ou un délai de navigation dépassé, et nous ajoutons un tag au résultat avec une cause racine KerberosInitWarning. Comme l’échec ressemble à un dépassement de délai ordinaire, vérifiez vos logs de tâches pour trouver les codes d’erreur suivants avant d’enquêter sur le script du moniteur.

Ces codes sont distincts de la validation de démarrage de la Partie 2 — si vous ne définissez que certaines des variables KERBEROS_*, le gestionnaire de jobs ne démarre tout simplement pas, et aucun de ces codes n’apparaîtra jamais dans les logs d’un job.

Code d’erreur	Cause	Que faire
`KERBEROS_KDC_UNREACHABLE`	Le conteneur d’exécution ne peut pas atteindre le KDC sur le réseau.	Vérifiez les règles du pare-feu pour le port TCP, et UDP 88 entre l’hôte de votre site privé, et le KDC.
`KERBEROS_BAD_CREDENTIAL`	Le principal ne correspond pas au keytab, ou le keytab est endommagé.	Vérifiez le keytab sur l’hôte en exécutant `klist -kt <CLIENT_KEYTAB_PATH>` .
`KERBEROS_CLOCK_SKEW`	L’horloge de l’hôte diffère de l’horloge du KDC de plus de 5 minutes.	Synchronisez l’horloge de l’hôte avec NTP, en utilisant un service tel que `chrony` .
`KERBEROS_DNS_LOOKUP_FAILED`	Le conteneur ne peut pas résoudre le nom d’hôte du KDC, ou le domaine.	Vérifiez les paramètres du résolveur DNS interne pour votre conteneur de gestionnaire de jobs, ou mappez les hôtes avec `RUNTIME_EXTRA_HOSTS` .
`KERBEROS_CONFIG_INVALID`	Le conteneur d’exécution ne peut pas lire le keytab monté, ou aucun principal n’a pu en être extrait (un keytab vide, ou malformé).	Vérifiez que le keytab est lisible à l’intérieur du conteneur d’exécution et contient au moins un principal : `klist -kt <CLIENT_KEYTAB_PATH>` .
`KERBEROS_UNKNOWN_FAILURE`	Une défaillance cryptographique, ou GSSAPI au niveau du système a interrompu la négociation.	Comparez les types de chiffrement dans votre keytab client ( `klist -kt -e <CLIENT_KEYTAB_PATH>` répertorie le type de chiffrement de chaque entrée) avec la valeur `supported_enctypes` configurée sur votre KDC à l’étape 3. Une inadéquation entre ce que le keytab propose, et ce que le KDC accepte provoque la plupart de ces échecs.

Cette traduction automatique est fournie pour votre commodité.

Prise en charge de l'authentification Kerberos (SPNEGO) pour les sites privés

Valeurs d’espace réservé

Exigences et compatibilité

Partie 1 : configurer un laboratoire de test Kerberos (facultatif)

Conseil

Étape 1 : installer les packages Kerberos

Étape 2 : configurer le système Kerberos (`/etc/krb5.conf`)

Étape 3 : configurez le daemon KDC (`kdc.conf`)

Étape 4 : initialiser la base de données principale et les daemons KDC

Étape 5 : générer les keytabs client et serveur

Important

(Facultatif) Étape 6 : déployer un conteneur web de test

Conseil

Étape 7 : vérifiez le DNS local et la négociation Kerberos

Partie 2 : configurer le gestionnaire de tâches Synthetics pour Kerberos

Prudence

Important

Commande standard (sans Kerberos)

Commande requise (avec la prise en charge de Kerberos activée)

Docker

Podman

Conseil

Partie 3 : dépanner l’authentification Kerberos

Cette traduction automatique est fournie pour votre commodité.

Prise en charge de l'authentification Kerberos (SPNEGO) pour les sites privés

Valeurs d’espace réservé .css-21sua1{background:none;border:none;width:0;padding:0;}

Exigences et compatibilité

Partie 1 : configurer un laboratoire de test Kerberos (facultatif)

Conseil

Étape 2 : configurer le système Kerberos (/etc/krb5.conf)

Étape 3 : configurez le daemon KDC (kdc.conf)

Étape 4 : initialiser la base de données principale et les daemons KDC

Étape 5 : générer les keytabs client et serveur

(Facultatif) Étape 6 : déployer un conteneur web de test

Étape 7 : vérifiez le DNS local et la négociation Kerberos

Partie 2 : configurer le gestionnaire de tâches Synthetics pour Kerberos

Prudence

Important

Commande standard (sans Kerberos)

Commande requise (avec la prise en charge de Kerberos activée)

Docker

Podman

Partie 3 : dépanner l’authentification Kerberos

Valeurs d’espace réservé

Étape 2 : configurer le système Kerberos (`/etc/krb5.conf`)

Étape 3 : configurez le daemon KDC (`kdc.conf`)