Suporte à autenticação Kerberos (SPNEGO) para localizações privadas

Este documento descreve como configurar o gerenciador de trabalhos de Sintéticos (SJM) para executar monitores com suporte à autenticação Kerberos. Ele também inclui um passo a passo opcional para configurar um Centro de Distribuição de Chaves (KDC) Kerberos e um aplicativo web protegido por SPNEGO em uma instância de EC2 do Amazon Linux 2023, para que você possa validar a configuração antes de apontar o gerenciador de trabalhos para o seu próprio realm.

Valores de espaço reservado

Antes de começar, identifique os seguintes valores para o seu ambiente. Substitua cada espaço reservado pelo seu próprio valor onde quer que ele apareça neste documento.

Espaço reservado	Descrição	Exemplo
`<REALM_NAME>`	Realm do Kerberos (deve estar em maiúsculas)	`KERBTEST.LOCAL`
`<EC2_PRIVATE_IP>`	Endereço IPv4 privado da instância de EC2	`10.8.9.172`
`<EC2_INTERNAL_HOSTNAME>`	Nome de domínio totalmente qualificado (FQDN) do aplicativo web	`ip-X-X-X-X.ec2.internal`
`<CLIENT_PRINCIPAL>`	Identidade Kerberos atribuída aos workers de Sintéticos	`synthetics-test`
`<CLIENT_KEYTAB_PATH>`	Caminho completo no host onde o keytab do cliente está armazenado	`/home/ec2-user/kerb-test/synthetics-test.keytab`
`<PRIVATE_LOCATION_KEY>`	Chave de localização privada da New Relic	`NRSP-us...`

Requisitos e compatibilidade

A autenticação Kerberos depende de acesso direto à rede para o seu Key Distribution Center (KDC), resolução de DNS interno e relógios rigorosamente sincronizados. Essas restrições limitam onde você pode executá-la, portanto, revise os seguintes requisitos antes de começar.

Oferecemos suporte à autenticação Kerberos nestes ambientes:

Localizações privadas que executam o gerenciador de tarefas Sintético em um ambiente de contêiner Docker
Localizações privadas que executam o gerenciador de jobs de Sintéticos em um ambiente de contêiner Podman

Não oferecemos suporte à autenticação Kerberos nestes ambientes:

Localizações públicas, que não têm rota de rede para o seu KDC interno
Ambientes do gerenciador de jobs do Kubernetes e do OpenShift

O gerenciador de jobs fornece credenciais Kerberos apenas para jobs de monitor de navegador. Monitores de API com script e monitores de ping são executados sem autenticação Kerberos.

Cada contêiner de tempo de execução do navegador adquire seu próprio ticket Kerberos (via kinit, antes do lançamento do Chrome), portanto, sua localização privada também deve atender a estes requisitos:

Acesse seu KDC na porta 88 TCP e UDP de dentro dos contêineres de tempo de execução.
Resolva os nomes do host do seu KDC e do aplicativo de destino de dentro dos contêineres de tempo de execução. Nas implantações do Docker, se o DNS interno não os resolver, mapeie-os com RUNTIME_EXTRA_HOSTS — esta variável é exclusiva do Docker. As implantações do Podman dependem do DNS interno.
Mantenha o relógio do host da localização privada com uma diferença máxima de 5 minutos em relação ao relógio do KDC, usando um serviço como chrony. Os contêineres de tempo de execução compartilham o relógio do kernel do host, portanto, sincronizar o host é suficiente.

Parte 1: configurar um laboratório de testes Kerberos (opcional)

Dica

A Parte 1 cria um realm do Kerberos independente e um aplicativo de teste protegido para que você possa validar a configuração do gerenciador de trabalhos de ponta a ponta. Não é o caminho de produção e a New Relic não gerencia o seu KDC. Se você já executa um KDC do Kerberos ou um domínio do Active Directory, obtenha o nome do realm, o endereço do KDC e um keytab de cliente de quem o administra e, em seguida, pule para a Parte 2.

Instale o servidor KDC do Kerberos e as ferramentas de administração na instância de EC2 do host:

bash

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

Configure o /etc/krb5.conf para direcionar requests de realm para o seu 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 as regras de porta e criptografia para o serviço 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

Crie o banco de dados e inicie os serviços em segundo plano do 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

Gere arquivos keytab contendo credenciais não interativas tanto para o cliente (worker de Sintéticos) quanto para o nome principal de serviço (SPN) do servidor web de destino:

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

O modo de arquivo do keytab do cliente importa menos do que parece: o limite de confiança primário aqui é o acesso ao soquete do Docker — o próprio SJM requer -v /var/run/docker.sock:/var/run/docker.sock:rw, e qualquer pessoa com esse acesso já pode ler qualquer arquivo no host como root, independentemente de seus bits de permissão. Mantenha o keytab do cliente como propriedade do root, conforme criado acima, com as permissões 644 — isso corresponde à identidade de execução do contêiner de tempo de execução do navegador (UID 2000, GID 0) por meio do bit de leitura de grupo. Não altere a propriedade para um usuário diferente, pois fazer isso pode quebrar essa correspondência de grupo e deixar o acesso dependendo inteiramente do bit de leitura global. O keytab do serviço HTTP é a própria identidade do servidor da web de teste: atribua a ele o UID e o GID com os quais o Apache é executado dentro do contêiner da etapa 6 — 33, o usuário www-data no Debian — e mantenha suas permissões em 644 também. Você não precisa do keytab HTTP para configurar o gerenciador de tarefas.

Dica

Esta etapa só é necessária se desejar executar um servidor web de teste no mesmo host para validar a configuração. Ela não é necessária para configurar o SJM.

Implante um contêiner Apache configurado com 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

Certifique-se de que o domínio interno seja resolvido localmente no host e verifique se a autenticação Kerberos é concluída com sucesso:

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/

Um teste bem-sucedido responde com HTTP/1.1 200 OK e exibe o conteúdo da página web protegida.

Parte 2: configurar o gerenciador de jobs de Sintéticos para o Kerberos

Para permitir que os contêineres do executor de navegador do Sintéticos resolvam automaticamente o KDC, adquiram tickets Kerberos e se autentiquem em endpoints protegidos, adicione as seguintes variáveis de ambiente Kerberos e a montagem de volume keytab ao comando que inicia o seu gerenciador de trabalhos.

Cuidado

Quando você ativa o Kerberos em uma localização privada, cada trabalho de monitor de navegador nessa localização recebe a montagem keytab e as variáveis de ambiente Kerberos. O gerenciador de jobs não filtra credenciais por monitor ou por URL. O Chrome decide quais hosts recebem um ticket Kerberos com base apenas em KERBEROS_HOST_ALLOWLIST, portanto, mantenha essa lista de permissões o mais restrita possível.

Importante

Defina todas as quatro variáveis KERBEROS_*, ou não defina nenhuma delas. Se definir apenas algumas, o gerenciador de tarefas Sintético falha ao iniciar e registra um erro de configuração incompleta do Kerberos.

Comando padrão (sem 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 obrigatório (com suporte a Kerberos habilitado)

Adicione as quatro variáveis de ambiente KERBEROS_* (-e) e a montagem de volume keytab (-v) ao comando que você já usa para iniciar o gerenciador de trabalhos.

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

Adicione as mesmas variáveis Kerberos e a montagem do keytab ao comando podman run de Instalar o gerenciador de jobs. O Podman executa o gerenciador de jobs em um pod em vez de montar o soquete do Docker, portanto, mantenha as suas configurações existentes de CONTAINER_ENGINE, PODMAN_API_SERVICE_PORT e 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

Dica

Em hosts SELinux, adicione uma flag de relabel para que o contêiner possa ler o keytab. O gerenciador de jobs e cada contêiner de tempo de execução de navegador que ele lança são executados dentro do mesmo pod (PODMAN_POD_NAME), e o Podman compartilha um rótulo SELinux entre todos os contêineres em um pod — portanto, :ro,Z funciona aqui, mesmo que vários contêineres leiam o keytab. Use :Z em vez de :ro,Z, já que o keytab nunca precisa ser compartilhado com contêineres fora deste pod. Para obter mais informações, consulte a documentação de volume do Podman.

Parte 3: solução de problemas de autenticação Kerberos

Se a inicialização do Kerberos falhar dentro do contêiner de tempo de execução, o pipeline de inicialização do contêiner ainda faz o lançamento do navegador e executa o seu monitor. O monitor então falha em um endpoint protegido com um desafio HTTP 401 ou um tempo limite de navegação, e adicionamos a tag de causa raiz KerberosInitWarning ao resultado. Como a falha parece um tempo limite comum, verifique os logs do seu job em busca dos seguintes códigos de erro antes de investigar o script do monitor.

Esses códigos são separados da validação de inicialização na Parte 2 — se você definir apenas algumas das variáveis KERBEROS_*, o gerenciador de trabalhos falhará ao iniciar imediatamente, e nenhum desses códigos aparecerá nos logs de um trabalho.

Código de erro	Causa	O que fazer
`KERBEROS_KDC_UNREACHABLE`	O contêiner de tempo de execução não consegue acessar o KDC pela rede.	Verifique as regras de firewall para a porta TCP e UDP 88 entre o host da sua localização privada e o KDC.
`KERBEROS_BAD_CREDENTIAL`	O principal não corresponde ao keytab, ou o keytab está danificado.	Verifique o keytab no host executando `klist -kt <CLIENT_KEYTAB_PATH>` .
`KERBEROS_CLOCK_SKEW`	O relógio do host difere do relógio do KDC em mais de 5 minutos.	Sincronize o relógio do host com o NTP, usando um serviço como `chrony` .
`KERBEROS_DNS_LOOKUP_FAILED`	O contêiner não consegue resolver o nome do host do KDC ou o realm.	Verifique as configurações do resolvedor DNS interno para o contêiner do seu gerenciador de tarefas ou mapeie os hosts com `RUNTIME_EXTRA_HOSTS` .
`KERBEROS_CONFIG_INVALID`	O contêiner de tempo de execução não consegue ler o keytab montado, ou nenhum principal pôde ser analisado a partir dele (um keytab vazio ou malformado).	Verifique se o keytab pode ser lido dentro do contêiner de tempo de execução e se contém pelo menos um principal: `klist -kt <CLIENT_KEYTAB_PATH>` .
`KERBEROS_UNKNOWN_FAILURE`	Uma falha criptográfica ou de GSSAPI no nível do sistema interrompeu o handshake.	Compare os tipos de criptografia no seu keytab de cliente ( `klist -kt -e <CLIENT_KEYTAB_PATH>` lista o enctype de cada entrada) com o valor `supported_enctypes` configurado no seu KDC na etapa 3. Uma incompatibilidade entre o que o keytab oferece e o que o KDC aceita causa a maioria dessas falhas.

Esta tradução de máquina é fornecida para sua comodidade.

Suporte à autenticação Kerberos (SPNEGO) para localizações privadas

Valores de espaço reservado

Requisitos e compatibilidade

Parte 1: configurar um laboratório de testes Kerberos (opcional)

Dica

Etapa 1: instalar pacotes do Kerberos

Etapa 2: configurar o Kerberos do sistema (`/etc/krb5.conf`)

Etapa 3: configure o daemon KDC (`kdc.conf`)

Passo 4: inicializar o banco de dados mestre e os daemons do KDC

Etapa 5: gerar keytabs de cliente e servidor

Importante

(Opcional) Etapa 6: implantar um contêiner web de teste

Dica

Etapa 7: verificar o DNS local e o handshake do Kerberos

Parte 2: configurar o gerenciador de jobs de Sintéticos para o Kerberos

Cuidado

Importante

Comando padrão (sem Kerberos)

Comando obrigatório (com suporte a Kerberos habilitado)

Docker

Homem-Pod

Dica

Parte 3: solução de problemas de autenticação Kerberos

Esta tradução de máquina é fornecida para sua comodidade.

Suporte à autenticação Kerberos (SPNEGO) para localizações privadas

Valores de espaço reservado .css-21sua1{background:none;border:none;width:0;padding:0;}

Requisitos e compatibilidade

Parte 1: configurar um laboratório de testes Kerberos (opcional)

Dica

Etapa 2: configurar o Kerberos do sistema (/etc/krb5.conf)

Etapa 3: configure o daemon KDC (kdc.conf)

Passo 4: inicializar o banco de dados mestre e os daemons do KDC

Etapa 5: gerar keytabs de cliente e servidor

(Opcional) Etapa 6: implantar um contêiner web de teste

Etapa 7: verificar o DNS local e o handshake do Kerberos

Parte 2: configurar o gerenciador de jobs de Sintéticos para o Kerberos

Cuidado

Importante

Comando padrão (sem Kerberos)

Comando obrigatório (com suporte a Kerberos habilitado)

Docker

Homem-Pod

Parte 3: solução de problemas de autenticação Kerberos

Valores de espaço reservado

Etapa 2: configurar o Kerberos do sistema (`/etc/krb5.conf`)

Etapa 3: configure o daemon KDC (`kdc.conf`)