Ansible Automation Platform 2에서 Windows용 Kerberos 사용

Kerberos는 주로 도메인 환경에서 Windows 서버를 관리하는 데 선호되는 인증 방법입니다. 이제 고객은 Red Hat Ansible Automation Platform을 통해 향후 몇 년 동안 Kerberos 인증을 사용할 수 있습니다. 그렇다면 이 주제를 다시 살펴보는 이유는 무엇일까요? 

Ansible Automation Platform 2는 2021년 7월에 릴리스되었으며 플랫폼의 주요 아키텍처 재설계였습니다. 근본적인 변경 사항 중 하나는 오토메이션 실행 환경 의 도입이었습니다. 즉, 컨테이너를 사용하여 Ansible Playbook을 일관되게 패키징, 배포하고 실행하는 것입니다. 짧게 이야기하면, 오토메이션 실행 환경은 RHEL 기본 이미지, Ansible Core, Ansible 오토메이션을 실행하는 데 필요한 모든 종속성(일반적으로 Ansible Content Collections 및 Python 라이브러리)으로 구성됩니다. 

컨테이너로 전환한다는 것은 localhost가 이제 컨테이너라는 점을 고려해야 한다는 것을 의미합니다. 오토메이션 실행 환경과 관련하여, localhost가 보이는 것과 어떻게 다른지 자세히 설명한 훌륭한 블로그 포스트가 있습니다.

이 모든 것을 염두에 두고 Ansible Automation Platform 2에서 Kerberos 인증을 구성하는 방법, 구성을 테스트하는 방법, Kerberos를 사용하도록 오토메이션 컨트롤러를 구성하는 방법에 대한 가이드형 예제를 살펴보겠습니다.

예시 구성

Kerberos를 Ansible과 함께 사용하려면 Kerberos 구성 파일이 필요합니다. 구성 파일의 내용은 DNS 구성, KDC 검색 및 도메인 수와 같은 요인에 따라 달라집니다. 이 예제에는 오토메이션 컨트롤러 서버에서 검색할 수 없는 단일 도메인 DEMOLAB.LOCAL이 있습니다.

다음은 샘플 Kerberos 클라이언트 구성입니다. 오토메이션 컨트롤러 관리 가이드에 유사한 예제가 문서화되어 있습니다.

[libdefaults] 
rdns = false 
default_realm = DEMOLAB.LOCAL 

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

이제 오토메이션 실행 환경을 고려해야 하며, localhost는 보이는 것과 다르다는 것을 기억해야 합니다! 오토메이션 컨트롤러에서 Ansible Playbook을 실행하면 이를 통해 컨트롤러 노드의 기반 파일 시스템에 액세스할 수 없는 컨테이너 이미지를 호출하게 됩니다. 실행 환경에서 Kerberos 클라이언트 구성에 액세스할 수 있는지 확인해야 합니다. 여기서 두 가지 옵션을 사용할 수 있습니다.

1. Kerberos 클라이언트 구성을 오토메이션 컨트롤러에서 실행 중인 실행 환경에 매핑할 수 있습니다.
2. Ansible Builder를 사용하여 자체 실행 환경을 사용자 정의 및 구축하고 krb5.conf를 이미지에 추가할 수 있습니다.

이 예제에서는 다른 변경 작업이 필요하지 않으므로 Kerberos 클라이언트 구성을 실행 중인 실행 환경에 매핑하겠습니다. 

파일을 실행 환경에 매핑하기 위해 /etc/krb5.conf.d/DEMOLAB.LOCAL.conf라는 오토메이션 컨트롤러 서버의 Kerberos 클라이언트 구성 디렉터리에 구성을 작성하겠습니다.

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

커맨드라인에서 테스트

이제 커맨드라인에서 구성을 확인할 수 있습니다. 먼저 어떤 실행 환경을 테스트에 사용할 수 있는지 확인하겠습니다. 오토메이션 컨트롤러 서버에서 awx 사용자로 전환하고 실행 환경 이미지를 나열할 수 있습니다. 여기에서 테스트할 이미지인 ee-supported-rhel8 실행 환경을 확인할 수 있습니다.

$ 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 

다른 이미지로 테스트해야 하는 경우 'podman pull'을 사용하여 컨테이너 레지스트리에서 관련 이미지를 복사합니다.

이제 구성 디렉터리를 실행 환경에 매핑하고 Kerberos 티켓을 인증하고 받을 수 있는지 확인하겠습니다. 다음 Podman 명령은 실행 환경 컨테이너를 시작하고 /etc/krb5.conf.d/를 실행 중인 컨테이너에 매핑합니다. 또한 컨테이너 내부에 인터랙티브 셸이 제공되므로 kinit를 테스트할 수 있습니다. 마지막으로, Kerberos는 자격 증명 캐시를 사용하여 유효한 Kerberos 자격 증명을 보유합니다. 앞에서 설명한 대로, localhost는 여기에서 다르게 보이기 때문에 파일 시스템과 Kerberos 캐시에 액세스할 수 없습니다. KRB5CCNAME 변수를 설정하여 구성을 테스트할 수 있도록 임시 Kerberos 자격 증명 캐시를 생성하겠습니다. winrm 연결 플러그인에서도 유사한 메커니즘을 사용합니다. 

$ 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

추가 테스트로, 티켓을 특정 서버에 대한 인증에 사용할 수 있는지 확인할 수 있습니다. 실행 환경에서 kinit를 성공적으로 실행한 후에 kvno를 사용하여 대상 호스트로 인증할 수 있습니다. 이 예제에서는 티켓을 사용하여 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

테스트 결과가 좋아 보입니다! 이제 구성을 오토메이션 컨트롤러로 이동하겠습니다. 

오토메이션 컨트롤러 구성

Windows 계정에 대해 오토메이션 컨트롤러에 머신 자격 증명을 추가해야 합니다. 이는 'username@DOMAIN.COM' 형식의 사용자 계정 이름(User Principal Name, UPN)이어야 합니다. 오토메이션 컨트롤러에서 자격 증명을 추가하려면 왼쪽 메뉴에서 Credentials(자격 증명)로 이동하여 Add(추가)를 누른 다음 자격 증명 유형을 Machine(머신)으로 선택합니다. 다음과 같이 도메인 사용자 및 비밀번호를 입력합니다.

그런 다음 Kerberos 클라이언트 구성을 실행 환경에 매핑할 수 있습니다. 관리자는 Settings(설정) -> Job Settings(작업 설정) 을 구성하고 'path to expose to isolated jobs'를 편집하여 Kerberos 디렉터리를 추가해야 합니다. 이 형식은 CLI에서 테스트할 때 사용한 형식과 동일합니다. 새 구성은 다음과 같이 표시됩니다.

이제 테스트할 시간입니다! 간단한 'ping' 플레이북을 사용하여 구성을 검증할 수 있습니다. WinRM 연결 메시지를 포함하도록 로깅을 늘릴 수도 있습니다. 작업 템플릿을 편집하고 자세한 정보 표시 수준을 5로 설정합니다.

작업 템플릿을 시작하면 자세한 연결 메시지가 표시됩니다.

임시 Kerberos 자격 증명 캐시가 생성되고 계정을 인증할 수 있으며 티켓을 얻은 것을 확인할 수 있습니다. 플레이북이 성공적으로 완료됩니다.

문제 해결

실행 환경 내에서 Kerberos를 구성할 때 몇 가지 오류 메시지가 나타날 수 있습니다. 표시될 수 있는 몇 가지 오류와 가능한 해결책은 다음과 같습니다.

• Kerberos 5 라이브러리를 초기화하는 동안 포함된 프로필 디렉터리를 읽을 수 없음 - 이는 /etc/krb5.conf.d 디렉터리에 실행 환경이 액세스할 수 없는 추가 디렉터리를 포함하려고 시도하는 구성 파일이 있는 것을 나타내는 것일 수 있습니다. /etc/krb5.conf.d에서 includedir 옵션이 있을 수 있는 구성 파일이 있는지 확인합니다.
• 기본 캐시를 가져오는 동안 퍼시스턴트 인증 키 이름에 잘못된 UID가 있음 - 위에서 설명한 대로 임시 자격 증명 캐시 디렉터리를 설정해야 합니다.
• 초기 자격 증명을 가져오는 동안 '<DOMAIN>' 영역의 KDC를 찾을 수 없음 - 이 오류에는 여러 가지 이유가 있을 수 있습니다. Kerberos 구성이 올바르게 보이는지 확인하고 유효한 KDC가 구성에 나열되는지 확인합니다. DNS를 사용하여 KDC를 조회하는 경우 dns_lookup_kdc 가 true로 설정되어 있는지 확인합니다. 
• Kerberos 데이터베이스에서 서버를 찾을 수 없음 - 이는 주로 DNS 문제 또는 잘못 구성된 Ansible 인벤토리와 관련이 있을 수 있습니다. 인벤토리의 호스트 이름이 DNS의 서버 이름과 일치하는지 확인합니다. 또한 Ansible이 WinRM 디버그 로그를 사용하여 FQDN을 통해 호스트에 연결을 시도하는지 확인합니다. 다음 예시는 Windows 서버에 대해 ansible_host 변수가 설정되어 있고 호스트 이름 대신 IP에 연결을 시도하는 경우입니다.

다음 단계

이 예시가 Ansible Automation Platform 2의 변경 사항과 Windows 서버 관리를 위해 Kerberos 인증을 시작하는 방법을 이해하는 데 도움이 되었기를 바랍니다. Windows는 계속해서 Ansible에서 최우선순위로 지원되며, 그 여정에 도움이 되는 더 많은 리소스를 이용할 수 있습니다.

• Ansible for Windows - Ansible을 사용하여 Windows 인프라를 관리하는 방법과 일반적인 활용 사례를 알아보세요.
• 체험판 서브스크립션 - 사용할 준비가 되셨나요? Ansible Automation Platform의 모든 구성 요소에 무제한으로 액세스할 수 있는 고유 체험판 서브스크립션을 신청하세요.