Como usar o Kerberos para Windows no Ansible Automation Platform 2

O Kerberos costuma ser o método de autenticação mais escolhido para gerenciar servidores Windows em um ambiente de domínio. Há muitos anos, os clientes podem aproveitar a autenticação do Kerberos graças ao Red Hat Ansible Automation Platform. Por que revisitar esse assunto? 

O Ansible Automation Platform 2 foi lançado em julho de 2021 e representou uma grande reformulação da plataforma. Uma das principais mudanças foi a introdução dos automation execution environments: o uso de containers para empacotar, distribuir e executar playbooks do Ansible com consistência. Sem entrar em muitos detalhes, os automation execution environments consistem em uma imagem base do RHEL, no Ansible Core e em todas as dependências necessárias para executar a automação do Ansible. Em geral, essas dependências são as Ansible Content Collections e as bibliotecas Python. 

Quando se trata dos containers, às vezes precisamos considerar que o localhost é um deles. Há um excelente post no blog que explica em detalhes como o localhost não é o que parece em relação aos automation execution environments.

Considerando tudo isso, você verá a seguir um exemplo com orientações sobre como configurar a autenticação do Kerberos no Ansible Automation Platform 2, testar a configuração e definir o automation controller para usar o Kerberos.

Exemplo de configuração

Para usar o Kerberos com o Ansible, precisamos de um arquivo de configuração do Kerberos. O conteúdo dele varia com base em fatores como configuração DNS, descoberta de KDC e quantidade de domínios. Neste exemplo, temos um único domínio que é DEMOLAB.LOCAL. Vale notar que ele não é detectável pelo automation controller server.

Confira a seguir o exemplo de configuração do cliente Kerberos. Há um exemplo parecido no guia do automation controller para administradores.

 [libdefaults] 
rdns = false 
default_realm = DEMOLAB.LOCAL 

[realms] 
 DEMOLAB.LOCAL = { 
  kdc = ms-ad.demolab.local 
  admin_server = ms-ad.demolab.local 
 }   

Agora, precisamos considerar os automation execution environments e lembrar que o localhost não é o que parece. Quando o automation controller executa um playbook do Ansible, ele invoca uma imagem de container que não tem acesso ao sistema de arquivos subjacente do nó do controller. É necessário verificar se o execution environment tem acesso à configuração do cliente Kerberos. Há duas maneiras de fazer isso.

1. Mapear a configuração do cliente Kerberos para o execution environment em execução usando o automation controller.
2. Personalizar e criar o próprio execution environment usando o Ansible Builder e adicionar "krb5.conf" à imagem.

Neste exemplo, mapearemos a configuração do cliente Kerberos para o execution environment em execução, já que outras alterações não são necessárias. 

Para mapear o arquivo para o execution environment, grave a configuração no diretório correspondente do cliente Kerberos localizado no automation controller server /etc/krb5.conf.d/DEMOLAB.LOCAL.conf.

# cat /etc/krb5.conf.d/DEMOLAB.LOCAL.conf 

[libdefaults] 
rdns = false 
default_realm = DEMOLAB.LOCAL 

[realms] 
 DEMOLAB.LOCAL = { 
  kdc = ms-ad.demolab.local 
  admin_server = ms-ad.demolab.local 
 }  

Teste na linha de comando

Está tudo pronto para verificar a configuração usando a linha de comando. Primeiro, confirme quais execution environments estão disponíveis para teste. No servidor do automation controller, podemos alternar para o usuário do AWX e listar as imagens de execution environment. Veja a seguir que o execution environment ee-supported-rhel8 está disponível. Esta é a imagem que será usada no teste.

$ su - awx 
$ podman images 
REPOSITORY                                                         TAG     IMAGE ID   CREATED   SIZE 
registry.redhat.io/ansible-automation-platform-23/ee-supported-rhel8  latest   024856bccc5f  4 weeks ago  1.66 GB

Se você precisar usar outra imagem no teste, utilize "podman pull" para copiar a opção relevante de um registro de containers.

Agora, precisamos ver se podemos mapear o diretório de configurações para o execution environment, fazer a autenticação e gerar um ticket do Kerberos. O comando do Podman a seguir inicia o container do execution environment e mapeia /etc/krb5.conf.d/ para o container em execução. Você também tem acesso a um shell interativo dentro do container para testar o kinit. Um último detalhe sobre isso é que o Kerberos usa um cache para armazenar credenciais válidas. E como o localhost não é o que parece, não temos acesso ao sistema de arquivos e ao cache do Kerberos. É preciso criar um cache temporário de credenciais do Kerberos para testar a configuração. Para isso, defina a variável KRB5CCNAME. O plugin de conexão WinRM usa um mecanismo parecido. 

$ podman run --rm  -v "/etc/krb5.conf.d:/etc/krb5.conf.d:O" -it registry.redhat.io/ansible-automation-platform-23/ee-supported-rhel8:latest /bin/bash 

bash-4.4# export KRB5CCNAME=`mktemp` 
bash-4.4# echo $KRB5CCNAME 
/tmp/tmp.ZzBXbtGiV1 
bash-4.4# kinit svc-ansible@DEMOLAB.LOCAL 
Password for svc-ansible@DEMOLAB.LOCAL: 
bash-4.4# klist 
Ticket cache: FILE:/tmp/tmp.ZzBXbtGiV1 
Default principal: svc-ansible@DEMOLAB.LOCAL 

Valid starting Expires         Service principal 
04/04/23 14:01:37  04/05/23 00:01:37  krbtgt/DEMOLAB.LOCAL@DEMOLAB.LOCAL 
    renew until 04/11/23 14:01:33

Como um teste extra, podemos verificar se o ticket funciona na autenticação em um servidor específico. Após executar o kinit no execution environment, podemos usar o kvno para fazer a autenticação com um host de destino. Neste exemplo, vamos verificar se podemos usar o ticket para fazer a autenticação com "windows2.demolab.local".

bash-4.4# kvno http/windows2.demolab.local 
http/windows2.demolab.local@DEMOLAB.LOCAL: kvno = 1 
bash-4.4# klist 
Ticket cache: FILE:/tmp/tmp.pe2PBReLm5 
Default principal: svc-ansible@DEMOLAB.LOCAL 

Valid starting Expires         Service principal 
05/10/23 15:26:35  05/11/23 01:26:35  krbtgt/DEMOLAB.LOCAL@DEMOLAB.LOCAL 
    renew until 05/17/23 15:26:33 
05/10/23 15:26:49  05/11/23 01:26:35  http/windows2.demolab.local@DEMOLAB.LOCAL 
    renew until 05/17/23 15:26:3

O teste deu certo! Agora, vamos passar a configuração para o automation controller. 

Configuração do automation controller

Precisamos adicionar uma credencial Machine ao automation controller para nossa conta do Windows. Ela precisa ser o nome principal do usuário (UPN) no formato "nomedeusuário@DOMÍNIO.COM". Para adicionar uma credencial ao automation controller, navegue até Credentials no menu à esquerda, pressione Add e selecione o tipo de credencial como Machine. Digite o usuário e a senha do domínio da seguinte maneira:

Em seguida, é possível mapear a configuração do cliente Kerberos para o execution environment. Um administrador precisará configurar Settings -> Job Settings  e editar a opção "Paths to expose to isolated jobs" adicionando o diretório do Kerberos. Perceba que estamos usando o mesmo formato do teste na interface de linha de comando (CLI). A nova configuração será assim:

Agora, vamos testar. Podemos usar um playbook de "ping" para validar a configuração. Também é possível ampliar a geração de log para incluir mensagens de conexão do WinRM. Edite o modelo do job e defina o detalhamento como o nível 5.

Ao iniciar o modelo de job, você verá as mensagens de conexão detalhadas.

Perceba que o cache temporário de credenciais do Kerberos foi criado, a conta pode ser autenticada, e geramos um ticket. O playbook será concluído com sucesso.

Solução de problemas

Algumas mensagens de erro podem aparecer quando você configurar o Kerberos em um execution environment. Veja alguns erros prováveis e suas possíveis soluções.

• Included profile directory could not be read while initializing Kerberos 5 library: isso pode indicar que há no diretório "/etc/krb5.conf.d" um arquivo de configuração que está tentando incluir diretórios extras a que o execution environment não têm acesso. Verifique os arquivos de configuração em "/etc/krb5.conf.d" que possam ter uma opção includedir.
• Invalid UID in persistent keyring name while getting default ccache: não se esqueça de definir um diretório de cache temporário de credenciais conforme descrito acima.
• Cannot find KDC for realm "<DOMAIN>" while getting initial credentials: pode haver muitos motivos para esse erro. Verifique se a configuração do Kerberos está correta e se um KDC válido está listado nela. Se você depende do DNS para pesquisar KDCs, verifique se "dns_lookup_kdc" está definido como "true". 
• Server not found in Kerberos database: muitas vezes, isso está relacionado a problemas do DNS ou a um inventário do Ansible configurado incorretamente. Verifique se o nome do host no inventário corresponde ao nome do servidor no DNS. Além disso, confirme se o Ansible está tentando se conectar ao host usando o FQDN por meio dos logs de depuração do WinRM. Veja um exemplo onde a variável "ansible_host" está definida como um servidor Windows, e que tentamos nos conectar ao IP em vez do nome do host.

Próximas etapas

Esperamos que esse exemplo tenha ajudado você a entender algumas das mudanças no Ansible Automation Platform 2 e a começar a usar a autenticação do Kerberos para gerenciar servidores Windows. O Windows continua sendo uma peça-chave para o Ansible, e há mais recursos disponíveis para ajudar você na sua jornada.

• Ansible para o Windows: descubra como usar o Ansible para gerenciar casos de uso comuns e infraestrutura do Windows.
• Teste de subscrição: o que acha de começar agora? Participe de um teste de subscrição para ter acesso ilimitado a todos os componentes do Ansible Automation Platform.