17. 프로젝트 서명 및 확인¶

17.1. 사전 요구 사항¶

• RHEL 노드를 다음과 같이 올바르게 구독해야 합니다.

  • RHEL 서브스크립션과 baseos 및 appstream 리포지토리가 활성화된 경우

  • Ansible Automation Platform 서브스크립션 및 적절한 Ansible Automation Platform 채널이 활성화되었습니다.

  ansible-automation-platform-2.3-for-rhel-8-x86_64-rpms for RHEL 8
  ansible-automation-platform-2.3-for-rhel-9-x86_64-rpms for RHEL 9
  

• 콘텐츠에 서명하려면 유효한 GPG 공용/개인 키 쌍이 필요합니다. 자세한 내용은 `How to create GPG keypairs`_을 참조하십시오.

GPG 키에 대한 자세한 내용은 `GnuPG documentation <https://www.gnupg.org/documentation/index.html>`_을 참조하십시오.

다음 명령을 사용하여 유효한 GPG 키 쌍과 기본 GnuPG 인증 키에 있는지 확인할 수 있습니다.

$ gpg --list-secret-keys

위의 명령이 출력을 생성하지 않거나 ``trustdb was created``를 나타내는 한 줄의 출력을 생성하지 않으면 기본 키 링에 시크릿 키가 없습니다. 이 경우 `How to create GPG keypairs`_을 참조하여 진행하기 전에 새 키 쌍을 만드는 방법을 알아봅니다. 그 이외의 출력을 생성하는 경우 유효한 시크릿 키가 있고 ``ansible-sign``을 사용하여 이동할 준비가 된 것입니다.

17.2. Ansible Automation Controller에 GPG 키 추가¶

컨트롤러의 콘텐츠 소싱 및 검증에 GPG 키를 사용하려면 CLI에서 다음 명령을 실행하여 추가해야 합니다.

$ gpg --list-keys
$ gpg --export --armour <key fingerprint> > my_public_key.asc

1. 컨트롤러 사용자 인터페이스의 왼쪽 탐색 메뉴에서 인증 정보**를 클릭한 다음 **추가 버튼을 클릭합니다.

2. 새 인증 정보에 의미 있는 이름을 지정합니다(예: 《인프라 팀 공개 GPG 키》)

3. 인증 정보 유형 필드에서 **GPG 공개 키**를 선택합니다.

4. **검색**을 클릭하여 공개 키 파일을 찾아서 선택합니다(예: my_public_key.asc)

5. 완료되면 **저장**을 클릭합니다.

이제 이 인증 정보를 projects 에서 선택할 수 있으며 향후 프로젝트 동기화 시 컨텐츠 확인이 자동으로 수행됩니다.

참고

프로젝트 캐시 SCM 시간 제한을 사용하여 컨트롤러가 서명된 콘텐츠를 재검토하는 빈도를 제어합니다. 프로젝트를 시작할 때 업데이트하도록 구성된 작업 템플릿의 경우 마지막 업데이트 이후 N초가 경과한 후 업데이트하라는 캐시 시간 초과 설정을 실행할 수 있습니다. 유효성 검사가 너무 자주 실행되는 경우 프로젝트의 선택 세부 정보 창의 캐시 제한 시간 필드에 시간을 지정하여 프로젝트 업데이트의 빈도를 줄일 수 있습니다.

17.3. ansible-sign CLI 유틸리티에 액세스¶

ansible-sign 유틸리티는 사용자가 프로젝트에 서명하고 프로젝트 서명 여부를 확인할 수 있는 옵션을 제공합니다.

1. 다음 명령을 실행하여 ansible-sign 를 설치합니다.

$ dnf install ansible-sign

2. ``ansible-sign``이/가 성공적으로 설치되었는지 확인합니다.

$ ansible-sign --version

다음과 유사한 출력 (다른 버전 번호가 있을 수 있음)

ansible-sign 0.1

ansible-sign 을 성공적으로 설치했음을 나타냅니다.

17.4. 프로젝트에 서명¶

이름에서 알 수 있듯이 프로젝트에 서명하려면 Ansible 프로젝트 디렉터리가 포함됩니다. 프로젝트 디렉터리 구조의 보다 정교한 예제는 `Ansible documentation <https://docs.ansible.com/ansible/latest/user_guide/sample_setup.html>`_을 참조하십시오.

다음 샘플 프로젝트에는 매우 간단한 구성이 있습니다. 인벤토리 파일 및 플레이북 디렉토리 아래에 있는 두 개의 작은 플레이북:

$ cd sample-project/
$ tree -a .
.
├── inventory
└── playbooks
    └── get_uptime.yml
    └── hello.yml

1 directory, 3 files

ansible-sign 가 변조되지 않도록 콘텐츠를 보호하는 방법은 프로젝트의 모든 보안 파일의 체크섬(SHA256)을 사용하여 체크섬 매니페스트 파일로 컴파일한 다음 해당 매니페스트 파일에 서명하는 것입니다.

콘텐츠에 서명하기 위한 첫 번째 단계는 ansible-sign``에 보호할 파일을 알려주는 파일을 생성하는 것입니다. 이 파일은 ``MANIFEST.in 이라고 하며 프로젝트 루트 디렉터리에 있어야 합니다.

내부적으로 ansible-sign 은 Python의 distlib 라이브러리의 distlib.manifest 모듈을 사용하므로 MANIFEST.in 는 이 라이브러리에서 지정하는 구문을 따라야 합니다. MANIFEST.in 파일 지시문에 대한 설명은 `Python Packaging User Guide <https://packaging.python.org/en/latest/guides/using-manifest-in/#manifest-in-commands>`_을 참조하십시오.

샘플 프로젝트에는 두 개의 지시문이 포함되어 있으므로 다음과 같은 MANIFEST.in 파일이 생성됩니다.

include inventory
recursive-include playbooks *.yml

이 파일을 사용하여 체크섬 매니페스트 파일을 생성하고 서명하십시오. 다음 두 단계는 모두 단일 ansible-sign 명령으로 수행됩니다.

$ ansible-sign project gpg-sign .
[OK   ] GPG signing successful!
[NOTE ] Checksum manifest: ./.ansible-sign/sha256sum.txt
[NOTE ] GPG summary: signature created

이제 프로젝트에 서명되었습니다.

gpg-sign 하위 명령은 project 하위 명령에 있습니다. 프로젝트 콘텐츠에 서명하기 위해 모든 명령은 ansible-sign project 로 시작합니다. 위에서 언급했듯이 일반적으로 모든 ansible-sign project 명령은 프로젝트 루트 디렉터리를 최종 인수로 사용합니다.

앞에서 설명한 대로 ansible-sign 는 기본적으로 기본 키링을 사용하며 프로젝트에 서명하기 위해 찾을 수 있는 첫 번째 사용 가능한 시크릿 키를 찾습니다. --fingerprint 옵션과 함께 사용할 특정 시크릿 키를 지정하거나 --gnupg-home 옵션을 사용하여 완전히 독립된 GPG 홈 디렉토리를 지정할 수 있습니다.

프로젝트 디렉터리의 구조를 볼 때 새 .ansible-sign 디렉터리가 생성되었는지 확인합니다. 이 디렉터리에는 체크섬 매니페스트 및 GPG 분리 서명이 포함되어 있습니다.

$ tree -a .
.
├── .ansible-sign
│   ├── sha256sum.txt
│   └── sha256sum.txt.sig
├── inventory
├── MANIFEST.in
└── playbooks
    ├── get_uptime.yml
    └── hello.yml

17.5. 프로젝트 확인¶

서명된 Ansible 프로젝트가 변경되지 않았는지 확인하려면 ansible-sign 를 사용하여 서명이 유효한지 여부와 파일의 체크섬이 해당 체크섬 매니페스트와 일치하는지 확인할 수 있습니다. 특히 ansible-sign project gpg-verify 명령을 사용하여 이러한 두 조건을 자동으로 확인할 수 있습니다.

$ ansible-sign project gpg-verify .
[OK   ] GPG signature verification succeeded.
[OK   ] Checksum validation succeeded.

어떤 이유로든 확인이 실패하면 원인을 디버깅하는 데 도움이 되는 정보가 표시됩니다. 명령에서 ansible-sign 직후 글로벌 --debug 플래그를 전달하여 더 자세한 정보를 활성화할 수 있습니다.

17.6. 자동화 서명¶

신뢰할 수 있는 CI 환경(예: OpenShift, Jenkins 등)이 있는 환경에서는 서명 프로세스를 자동화할 수 있습니다. 예를 들어 선택한 CI 플랫폼에 GPG 개인 키를 시크릿으로 저장하고 CI 환경에서 GnuPG로 가져올 수 있습니다. 그런 다음 일반 CI 워크플로/컨테이너/환경 내에서 위의 서명 워크플로를 통해 실행할 수 있습니다.

GPG를 사용하여 프로젝트에 서명할 때 환경 변수 ANSIBLE_SIGN_GPG_PASSPHRASE 는 서명 키의 암호로 설정할 수 있습니다. 이는 CI 파이프라인에 삽입(및 마스크/보안)할 수 있습니다.

당면 상황에 따라 ansible-sign 는 서명 및 확인 중에 다른 종료 코드를 사용하여 반환됩니다. 이는 CI 환경이 장애에 따라 다르게 작동할 수 있기 때문에 CI 및 자동화의 맥락에서 유용할 수 있습니다(예: 일부 오류에 대해서는 경고를 보내지만 다른 오류에 대해서는 자동으로 실패함).

다음은 현재 ansible-sign 에서 사용되는 종료 코드이며 안정적인 것으로 간주할 수 있습니다.