3.6. 서명된 컨테이너 작업
자동화 실행 환경은 Ansible Automation Platform에서 작업을 실행하는 데 사용하는 컨테이너 이미지입니다. 이 콘텐츠를 프라이빗 자동화 허브로 다운로드하여 조직 내에 게시할 수 있습니다.
3.6.1. 컨테이너 서명을 위해 시스템 배포 링크 복사링크가 클립보드에 복사되었습니다!
컨테이너 서명이 준비되도록 시스템을 배포하려면 먼저 자동화 콘텐츠 수집 및 컨테이너 서명을 활성화했는지 확인합니다. 그런 다음 서명 스크립트를 생성하거나 실행 환경을 수동으로 추가 및 서명 할 수 있습니다.
설치 프로그램은 설치 프로그램이 있는 동일한 서버에서 스크립트와 키를 찾습니다.
프로세스
터미널에서 서명 스크립트를 생성하고 설치 프로그램 매개 변수로 스크립트 경로를 전달합니다.
예:
#!/usr/bin/env bash # pulp_container SigningService will pass the next 4 variables to the script. MANIFEST_PATH=$1 FINGERPRINT="$PULP_SIGNING_KEY_FINGERPRINT" IMAGE_REFERENCE="$REFERENCE" SIGNATURE_PATH="$SIG_PATH" # Create container signature using skopeo skopeo standalone-sign \ $MANIFEST_PATH \ $IMAGE_REFERENCE \ $FINGERPRINT \ --output $SIGNATURE_PATH # Optionally pass the passphrase to the key if password protected. # --passphrase-file /path/to/key_password.txt # Check the exit status STATUS=$? if [ $STATUS -eq 0 ]; then echo {\"signature_path\": \"$SIGNATURE_PATH\"} else exit $STATUS fiautomationhub_*로 시작하는 컨테이너 서명 옵션을 보려면 Ansible Automation Platform 설치 프로그램 인벤토리 파일을 검토하십시오.[all:vars] . . . automationhub_create_default_container_signing_service = True automationhub_container_signing_service_key = /absolute/path/to/key/to/sign automationhub_container_signing_service_script = /absolute/path/to/script/that/signs-
설치가 완료되면 Ansible Automation Platform에 로그인하고
로 이동합니다. - container-default 또는 컨테이너-anyname 이라는 키가 있는지 확인합니다.
container-default 서비스는 Ansible Automation Platform 설치 프로그램에서 생성합니다.
3.6.2. 자동화 허브에 원격으로 컨테이너 추가 링크 복사링크가 클립보드에 복사되었습니다!
다음 두 가지 방법 중 하나로 자동화 허브에 원격으로 컨테이너를 추가할 수 있습니다.
- 원격 생성
- 자동화 실행 환경 사용
프로세스
- Ansible Automation Platform에 로그인합니다.
-
탐색 패널에서
를 선택합니다. 클릭합니다.
- 이름 필드에 컨테이너가 있는 레지스트리의 이름을 입력합니다.
- URL 필드에 컨테이너가 있는 레지스트리의 URL을 입력합니다.
- 필요한 경우 Username 필드에 사용자 이름을 입력합니다.
- 필요한 경우 암호 필드에 암호를 입력합니다.
- 클릭합니다.
3.6.3. 실행 환경 추가 및 서명 링크 복사링크가 클립보드에 복사되었습니다!
자동화 실행 환경은 시스템 수준의 종속성 및 컬렉션 기반 콘텐츠를 통합할 수 있는 컨테이너 이미지입니다. 각 실행 환경을 사용하면 작업을 실행할 수 있는 사용자 지정 이미지를 사용할 수 있으며, 각 실행 환경에는 작업을 실행할 때 필요한 항목만 포함됩니다.
프로세스
-
탐색 패널에서
선택합니다. 을 클릭하고 표시되는 필드에 관련 정보를 입력합니다.
- Name 필드에는 로컬 레지스트리의 실행 환경 이름이 표시됩니다.
- Upstream 이름 필드는 원격 서버의 이미지 이름입니다.
- 레지스트리 의 드롭다운 메뉴에서 레지스트리 이름을 선택합니다.
- 선택 사항: Add tag(s) to include 필드에 태그를 입력합니다. 필드가 비어 있으면 모든 태그가 전달됩니다. 전달할 리포지토리별 태그를 지정해야 합니다.
- 선택 사항: 제외할 태그 추가에 제외할 태그를 입력합니다.
- 클릭합니다. 표시되는 목록에 새 실행 환경이 표시되어야 합니다.
새 자동화 실행 환경을 동기화하고 서명합니다.
- 아이콘 Cryostat 를 클릭하고 실행 환경 동기화 를 선택합니다.
- 아이콘 Cryostat 를 클릭하고 Sign execution environment 를 선택합니다.
- 새 실행 환경을 클릭합니다. 세부 정보 페이지에서 서명된 레이블을 찾아 실행 환경에 서명되었는지 확인합니다.
3.6.4. 로컬 환경에서 컨테이너 이미지 푸시 링크 복사링크가 클립보드에 복사되었습니다!
다음 절차에 따라 로컬 시스템에서 자동화 실행 환경에 서명하고 서명된 실행 환경을 자동화 허브 레지스트리로 푸시합니다.
프로세스
터미널에서 Podman 또는 현재 사용 중인 컨테이너 클라이언트에 로그인합니다.
> podman pull <container-name>실행 환경을 가져온 후 태그를 추가합니다(예: latest, rc, beta 또는 버전 번호(예: 1.0; 2.3 등):
> podman tag <container-name> <server-address>/<container-name>:<tag name>변경 후 실행 환경에 로그인하고 자동화 허브 레지스트리로 다시 푸시합니다.
> podman push <server-address>/<container-name>:<tag name> --tls-verify=false --sign-by <reference to the gpg key on your local>실행 환경이 서명되지 않은 경우 현재 서명이 포함된 경우에만 푸시할 수 있습니다. 또는 다음 스크립트를 사용하여 서명하지 않고 실행 환경을 푸시할 수 있습니다.
> podman push <server-address>/<container-name>:<tag name> --tls-verify=false-
실행 환경이 푸시되면
로 이동합니다. - 새 실행 환경을 표시하려면 새로 고침 아이콘을 클릭합니다.
- 내보낸 이미지를 보려면 이미지의 이름을 클릭합니다.
문제 해결
각 실행 환경의 세부 정보 페이지는 서명되었는지 여부를 나타냅니다. 세부 정보 페이지에 이미지가 Unsigned 임을 나타내는 경우 다음 단계를 사용하여 자동화 허브에서 실행 환경에 서명할 수 있습니다.
- 실행 환경 이름을 클릭하여 세부 정보 페이지로 이동합니다.
아이콘 Cryostat를 클릭합니다. 세 가지 옵션을 사용할 수 있습니다.
- 실행 환경에 서명
- 컨트롤러에서 사용
- 실행 환경 삭제
- 드롭다운 메뉴에서 Sign execution environment 를 클릭합니다.
검증
서명 서비스는 실행 환경에 서명합니다. 실행 환경이 서명되면 상태가 "signed"로 변경됩니다.
3.6.5. 서명된 이미지가 있는 정책 링크 복사링크가 클립보드에 복사되었습니다!
podman 또는 기타 이미지 클라이언트에서 해당 서명에 특정 정책을 할당하여 이미지의 유효성을 보장하기 위해 정책을 사용할 수 있습니다.
3.6.6. podman을 사용하여 특정 서명으로 이미지에 서명되었는지 확인 링크 복사링크가 클립보드에 복사되었습니다!
실행 환경이 특정 서명에 의해 서명되도록 하려면 먼저 로컬 환경에 서명해야 합니다.
프로세스
-
탐색 패널에서
를 선택합니다. - 사용 중인 서명 옆에 있는 아이콘을 클릭합니다. 키를 다운로드했음을 나타내기 위해 새 창이 열려 있어야 합니다.
3.6.7. 서명을 확인하도록 클라이언트 구성 링크 복사링크가 클립보드에 복사되었습니다!
원격 레지스트리에서 가져온 실행 환경이 올바르게 서명되었는지 확인하려면 먼저 정책 파일에서 적절한 공개 키를 사용하여 실행 환경을 구성해야 합니다.
사전 요구 사항
- 클라이언트에는 서명을 확인하도록 sudo 권한이 구성되어 있어야 합니다.
프로세스
터미널을 열고 다음 명령을 사용합니다.
> sudo <name of editor> /etc/containers/policy.json표시되는 파일은 다음과 유사합니다.
{ "default": [{"type": "reject"}], "transports": { "docker": { "quay.io": [{"type": "insecureAcceptAnything"}], "docker.io": [{"type": "insecureAcceptAnything"}], "<server-address>": [ { "type": "signedBy", "keyType": "GPGKeys", "keyPath": "/tmp/containersig.txt" }] } } }이 파일은
quay.io또는docker.io가 모두 확인을 수행하지 않음을 보여줍니다. 유형은거부의 기본 유형을 재정의하는insecureAcceptAnything이기 때문입니다. 그러나 매개변수유형은"signedBy"로 설정되어 있으므로 <server-address>는 확인을 수행합니다.참고현재 지원되는 유일한
keyType은 GPG 키입니다.<
;server-address> 항목에서 키 파일의 이름을 포함하도록keyPath<1>를 수정합니다.{ "default": [{"type": "reject"}], "transports": { "docker": { "quay.io": [{"type": "insecureAcceptAnything"}], "docker.io": [{"type": "insecureAcceptAnything"}], "<server-address>": [{ "type": "signedBy", "keyType": "GPGKeys", "keyPath": "/tmp/<key file name>", "signedIdentity": { "type": "matchExact" } }] } } }- 파일을 저장하고 닫습니다.
검증
- Podman을 사용하여 파일을 가져오거나 선택한 클라이언트를 가져옵니다.
> podman pull <server-address>/<container-name>:<tag name> --tls-verify=false
이 응답은 실행 환경이 오류 없이 서명되었는지 확인합니다. 실행 환경이 서명되지 않은 경우 명령이 실패합니다.
추가 리소스
- policy.json에 대한 자세한 내용은 containers-policy.json 설명서 를 참조하십시오.