auths 서브섹션

auths 섹션은 컨테이너의 레지스트리에 대한 정보로 구성됩니다. 공용 이미지가 계약에서 사용되는 경우에는 신임 정보가 필요하지 않으므로 auths 섹션이 필요하지 않습니다. auths 서브섹션은 컨테이너 이미지가 개인용인 경우에만 필요합니다. 이 하위 섹션에는 다음 샘플에 표시된 대로 이미지 정보가 없습니다. 이 서브섹션에는 이미지 레지스트리의 이름과 동일한 사용자 이름 암호와 같은 신임 정보가 포함되어야 합니다. 키는 호스트 이름이어야 합니다. Container Registry 또는 기본 docker 레지스트리에 대한 다음 문자열:

https://index.docker.io/v1/

다음 스니펫은 IBM Cloud 레지스트리의 예를 보여줍니다. API키 사용에 대한 자세한 정보는 클라이언트 소프트웨어를 사용하여 자동화에서 인증 을 참조하십시오.

auths:
  us.icr.io:
    password: <apikey>
    username: iamapikey

compose 서브섹션

이는 아카이브 서브섹션으로 구성됩니다. 아카이브 서브섹션에는 docker-compose.yaml 파일의 Base64 인코딩 TGZ 파일 아카이브가 포함되어 있습니다. Hyper Protect Container Runtime 이미지가 Docker Engine 및 Docker Compose 를 사용하여 컨테이너를 시작하므로 컨테이너에 대한 정보는 먼저 표준 Docker-compose 파일을 사용하여 작성되어야 합니다. 이 파일은 아카이브되고, Base64 로 인코딩되며, 이 프로세스의 출력은 컴포즈 섹션 내의 아카이브 하위 섹션에 대한 값으로 제공됩니다. 자세한 정보는 Docker Compose개요 를 참조하십시오.

Docker-compose 파일의 볼륨 정보 아래에 지정된 마운트 포인트는 계약의 워크로드 섹션에 지정된 볼륨 마운트 포인트와 정렬될 수 있습니다.

Docker 작성 파일의 일부로 빌드를 실행하는 것은 지원되지 않습니다. Docker 작성 파일에 build 섹션이 없는지 확인하십시오.

"yaml" 및 "yml" 형식 모두 docker-compose 파일에 대해 지원됩니다. 다음 도커 컴포즈 파일의 예시를 참조하세요.

version: '3'
services:
  nginx:
    image: nginx@sha256:e73ba8654ba7fd1834e78a3d4e9d72ffaaa3372d42996af5c34ba3e1abc293e8
    privileged: true
    user: 0:0
    restart: always
    ports:
    - 80:80

작업 부하 섹션이 사전 암호화되어 있을 때 레지스트리가 알려지지 않은 경우가 있습니다. 예를 들어, 작업량 제공자가 배포자가 레지스트리 미러 또는 개인 Container Registry 를 사용하도록 허용하려는 경우, 레지스트리와 풀 자격 증명을 동적으로 재정의할 수 있습니다. 이 작업은 작업량 제공자와 배포자 사이에 조율되어야 합니다. 자세한 정보는 동적 레지스트리 참조 사용 을 참조하십시오.

다음 단계를 완료하여 Base64 인코딩된 아카이브 파일. 그만큼 Base64 출력은 다음에서 사용할 수 있습니다. compose.b64 파일. <COMPOSE_Folder> 으로 이동하여 다음 명령을 실행합니다:

tar czvf compose.tgz docker-compose.yml

base64 -w0 compose.tgz > compose.b64

compose tgz 파일에 디렉터리와 일반 파일만 포함되어 있는지 확인하세요. 링크 또는 파이프는 지원되지 않습니다.

compose.b64 의 컨텐츠를 compose - > archive값으로 복사하십시오.

compose:
  archive: <paste the content of compose.b64 >

이 예제에서는 다음 출력과 유사한 응답을 볼 수 있습니다.

compose:
  archive: H4sIAKOFmGIAA+2RTW6DMBBGs84pRuyB8Q8k+DIRwZOGtmBkkyrcvhgnLVVV1EWkqhJv4ZHt8ednWZvqhWxcmaYzjpKhed08HETMpQRfd3k2VeRhPpEJCUxymTPkIuOALBOIG8DHq3zn4vrSjiqdLY/nsv+xb2w7nRZywlPgo/4THNm3uiKntgCWdO1aowmZnwLUTflECpwo8Jpu9NyZ2zvQgdADFEudoXyQzSu+fPPzseSvedo6qjV7mDa2anZbdH8totL6somtUlvX8K4SJshDsFKU2NmFvAZuMc9U37wceeys+Y6BI8Fi6+6vxK5RS+YFDh6RNu//tuVlZWVJd4BcjKckQAIAAA=

play 서브섹션

에서 play 하위 섹션에서는 다음을 통해 워크로드를 정의할 수 있습니다. 포드 설명자. 각 팟 (Pod) 에는 하나 이상의 컨테이너 정의가 포함될 수 있습니다. 설명자는 다음 중 한 가지 방법으로 제공할 수 있습니다:

• play 의 resources 서브섹션에 있는 일반 YAML 형식.니다 있습니다. 이 섹션은 디스크립터의 배열이며 두 가지 유형의 디스크립터 Pods 및 ConfigMaps를 지원합니다.

  다음 예제는 resources 섹션을 사용하는 방법을 보여줍니다.

  workload: |
    type: workload
    play:
      resources:
        - apiVersion: v1
          kind: Pod
          metadata:
            name: busybox
          spec:
            containers:
            - name: main
              image: ...
              command:
              - printenv
              envFrom:
              - configMapRef:
                  name: contract.config.map
                  optional: false
            restartPolicy: Never
  

• 에서 archive 하위 섹션 play, 아카이브는 Base64 인코딩되고 gzip으로 압축된 tar 파일입니다. 팟 (Pod) 또는 ConfigMaps 는 이 tar 파일의 최상위 레벨에서 YAML 파일로 표시됩니다. 또한, 파일 내에 추가 파일이 포함되어 있을 수 있으며, 모든 파일은 Pod가 시작되기 전에 호스트 파일 시스템으로 추출됩니다. 현재 작업 디렉토리 는 파일이 추출된 디렉토리이므로 상대 경로가 있는 볼륨 마운트를 사용하여 YAML 파일에서 파일 또는 디렉토리를 마운트할 수 있습니다.

  예:

  workload: |
    type: workload
    play:
      archive: ${COMPOSE_VALUE}
    auths:
      us.icr.io:
        username: iamapikey
        password: Eqx0TS....
    volumes:
      test-volume:
        mount: /var/hyperprotect
        seed: "workload phrase"
        filesystem: ext4
  

• play 의 templates 서브섹션에 있는 템플리트 형식으로. 이 섹션은 YAML 형식의 디스크립터 배열입니다. 포드 또는 ConfigMaps 설명자를 작성할 때 알려지지 않은 가변성 포인트(POV)를 가질 수 있습니다. 이러한 POV는 템플릿으로 표현될 수 있으며, 계약의 정보로부터 배포 시점에 값이 완성됩니다. go 템플리트 를 템플리트 구문으로 사용합니다. 이 구문은 helm 차트에 사용되는 것과 동일하므로 템플리트를 k8s와 쉽게 교환할 수 있습니다. 다음 Built-In 오브젝트를 지원합니다.

  • 환경: 이 오브젝트에는 워크로드와 환경 섹션 사이에 병합된 환경 변수가 포함되어 있습니다. 오브젝트는 {{ .Env }} 로 사용 가능합니다.

  예:

  workload: |
    type: workload
    auths:
     docker.io:
      password: <password>
      username: test
    play:
      templates:
        - apiVersion: v1
          kind: Pod
          metadata:
            name: busybox
          spec:
            containers:
            - name: main
              image: "{{ .Env.REGISTRY }}/hpse-docker-busybox-s390x@sha256:732efa374f1e6c964caeacab0bcb370385ee386041a14d4a32176462e3f75c7b"
              command:
              - printenv
              envFrom:
              - configMapRef:
                  name: contract.config.map
                  optional: false
            restartPolicy: Never
  env: |
    type: env
    logging:
      logRouter:
        hostname: 34be57c7-6ff2-4685-8839-903921e90ab9.ingress.jp-tok.logs.cloud.ibm.com
        iamApiKey: <iamApiKey of the service instance> / xxxx
        port: 443
    env:
      REGISTRY: docker-io/test
  

  {{ .Env REGISTRY }} 표현식은 이 예에서 계약의 env 섹션에 정의된 REGISTRY 환경 변수를 참조합니다.

  템플리트는 유효한 YAML이어야 하므로, 대체 표현식이 문자열의 첫 번째 파트로 표시되는 경우에는 이스케이프되어야 합니다. 그렇지 않으면 다음과 충돌합니다. 블록 매핑 통사론. 이것은 모델 표현 대신 문서의 텍스트 표현에 표현식이 적용되는 헬름 템플릿 과는 다릅니다.

apiVersion: v1
kind: Pod
metadata:
  name: busybox
spec:
  containers:
  - name: main
    image: ...
    command:
    - printenv
    envFrom:
    - configMapRef:
        name: contract.config.map
        optional: false
  restartPolicy: Never

apiVersion: v1
kind: Pod
metadata:
  name: busybox
spec:
  containers:
  - name: main
    image: ...
    volumeMounts:
    - name: test-volume
      readOnly: true
      mountPath: /fromHost
  volumes:
  - name: test-volume
    hostPath:
      path: /var/hyperprotect
      type: Directory
  restartPolicy: Never

images 서브섹션

images 서브섹션은 서명된 이미지에만 적용됩니다.

<container registry>/<username or namespace>/<image name>
eg- us.icr.io/mynamespace/my-haproxy:

notary: "https://notary.us.icr.io"

cat ~/.docker/trust/tuf/us.icr.io/<username>/<imagename>/metadata/root.json

images:
  dct:
    us.icr.io/mynamespace/my-haproxy:
      notary: "https://notary.us.icr.io"
      publicKey: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUJpRENDQVM2Z0F3SUJBZ0lSQUxCMXBPYlpEQlRRc09GSFlxazMzaWd3Q2dZSUtvWkl6ajBFQXdJd0tqRW8KTUNZR0ExVUVBeE1mZFhNdWFXTnlMbWx2TDNCeVlXSm9ZWFF4TWpNdmJYa3RhR0Z3Y205NGVUQWVGdzB5TWpBMApNVE14TURFd01ETmFGdzB6TWpBME1UQXhNREV3TUROYU1Db3hLREFtQmdOVkJBTVRIM1Z6TG1samNpNXBieTl3CmNtRmlhR0YwTVRJekwyMTVMV2hoY0hKdmVIa3dXVEFUQmdjcWhrak9QUUlCQmdncWhrak9QUU1CQndOQ0FBU1AKWGsrelE2MlFZNjI3MWQ1cTBMZHY3SGc3QzZkMGZOUlRsQmJXekhOWWFDZzlpU0piYnVNdjVBY0JmMjlqQi83eApqYzhzVitxMksyemtkTHV4QWxGWm96VXdNekFPQmdOVkhROEJBZjhFQkFNQ0JhQXdFd1lEVlIwbEJBd3dDZ1lJCkt3WUJCUVVIQXdNd0RBWURWUjBUQVFIL0JBSXdBREFLQmdncWhrak9QUVFEQWdOSUFEQkZBaUIzd0JTa0IxaXAKZHZZYlBMbFBmS3RZT0hsYnZzUllKa0FZM2hnY0xuNWhwQUloQUt6cmhsU3p4K1I5bmdtMTBlZVkyaFNCRmgrawpMWHp6SFkwaktTVzhyM1FhCi0tLS0tRU5EIENFUlRJRklDQVRFLS0tLS0K

services:
  <imagename>:
    image: s390x/redis@sha256:db467ab5c53bdeef65762a7534e26fecb94a0f218bd38afd2eaba1a670c472b1

gpg -a --export ${KEY_ID}|base64 -w0

images:
  rhs:
      OCI-image-identifier:
        publicKey: abcdef

workload- volumes 서브섹션

volumes 섹션은 작성 시 데이터 볼륨이 인스턴스에 첨부된 경우에만 계약에서 제공해야 합니다. 이 섹션에 제공된 정보는 첨부된 데이터 볼륨(사용자가 제공)을 탑재하는 데 사용되며, 나중에 "시드"를 사용하여 암호화됩니다( workload 및 env 섹션에 제공됨). "마운트" 필드에 대해 선택한 경로를 제공할 수 있습니다. 사용자가 제공하는 경로는 내부적으로 데이터 볼륨을 마운트하는 데 사용됩니다. 컨테이너 워크로드와 관련된 모든 데이터가 이 데이터 볼륨에 저장되도록 하려면, 계약서에 제공된 마운트 경로가 docker-compose.yaml 파일의 볼륨 섹션에 제공된 경로와 일치해야 합니다.

volumes 서브섹션에는 사용자 제공 시드를 사용하여 데이터 볼륨의 자동 암호화를 지원합니다. 데이터 볼륨이 Hyper Protect Virtual Servers 인스턴스에 연결되는 경우 계약의 volumes 하위 섹션에 있는 "seed" 필드를 통해 제공되는 시드를 사용하여 자동으로 암호화됩니다. 따라서 두 개의 시드가 제공되어야 합니다. 하나는 workload 섹션 (워크로드 페르소나에 의해) 을 통해 제공되고 다른 하나는 env 섹션 (배치자 페르소나에 의해) 을 통해 제공됩니다. 이 두 시드는 내부적으로 UTF8 시퀀스로 변환된 후 연결됩니다. 나중에 연결된 시퀀스의 해시 (SHA256) 는 데이터 볼륨을 암호화하기 위해 LUKS 비밀번호 문구로 사용되는 16진다이제스트로 계산됩니다.

다음 명령을 사용하여 헥스다이제스트의 유효성을 검사할 수 있습니다:

echo -n "seed1seed2" | sha256sum

여기서 계약의 워크로드 섹션에서 "시드" 를 제공하는 방법을 학습할 수 있습니다. env 섹션을 통해 "seed" 입력을 제공하는 방법에 대한 자세한 정보는 env 섹션 을 참조하십시오. 암호화를 위해 두 시드를 모두 제공해야 합니다. 제공된 인스턴스 중 하나의 seed만 종료되는 경우 암호화에 실패합니다.

Hyper Protect Crypto Services와 통합하여 저장된 데이터에 상위 레벨의 암호화 보호 및 제어를 추가할 수 있습니다. ibm-hyper-protect-container-runtime-1-0-s390x-11 부터 Hyper Protect Crypto Services 를 사용하여 무작위 값을 세 번째 시드로 생성하고 루트 키로 랩핑할 수 있습니다. LUKS 비밀번호 문구는 세 개 의 시드 (메타데이터 파티션의 시드와 계약의 두 시드) 를 사용하여 생성됩니다. 자세한 정보는 데이터 보안을 참조하십시오.

다음 스니펫은 볼륨 섹션의 예입니다.

volumes:
  test:
    filesystem: ext4
    mount: /mnt/data
    seed: "workload phrase"

VPC 인스턴스의 새 Hyper Protect Virtual Servers 의 경우 HPCR 이미지 버전 ibm-hyper-protect-container-runtime-1-0-s390x-9 부터 데이터 볼륨이 두 파트로 파티션됩니다. 첫 번째 파티션 (100Mib) 은 내부 메타데이터용으로 예약되어 있으며 두 번째 파티션은 워크로드용 데이터 볼륨으로 남아 있습니다. 새 볼륨만 파티션되며 이전 했 (스냅샷) 버전의 HPCR 이미지와 함께 파티션된 볼륨을 사용할 수 없습니다. 기존의 암호화된 볼륨을 사용한 프로비저닝도 작동합니다. 차이점은 기존 볼륨이 파티션되지 않으며 이 볼륨을 사용하여 이전 이미지로 돌아갈 수도 있다는 점입니다.

ibm-hyper-protect-container-runtime-1-0-s390x-12 부터 배치자 및 제공자는 "시드 롤링" 기능을 사용할 수 있습니다. 시드를 굴리거나 회전시켜 보안 상태를 높이거나 시드가 손상되는 경우에는 옵션이 제공됩니다. 배치자, 제공자 또는 둘 다에서 시드를 롤링하려는 경우 현재 시드 정보를 previousSeed 매개변수에 지정해야 하며 새 시드 정보를 seed 매개변수에 지정해야 합니다.

다음 스니펫은 볼륨 섹션의 예입니다.

volumes:
  test:
    filesystem: ext4
    mount: /mnt/data
    seed: "workload phrase1"
    previousSeed: "workload phrase"

ibm-hyper-protect-container-runtime-1-0-s390x-13 부터 가상 서버 인스턴스를 시작할 때 여러 볼륨을 연결할 수 있습니다. 인스턴스가 실행될 때 첨부된 볼륨은 무시됩니다.

다음 스니펫은 볼륨 섹션의 예입니다.

volumes:
  test1:
    filesystem: "ext4"
    mount: "/mnt/data"
    seed: "seed1"
  test2:
    filesystem: "ext4"
    mount: "/mnt/test2"
    seed: "seed2"
  test3:
    filesystem: "ext4"
    mount: "/mnt/test3"
    seed: "seed3"

logging 서브섹션

 env:
   logging:
     logRouter:
       hostname: <host name of the service instance> /
       iamApiKey: <iamApiKey of the service instance> / xxxx
       port: <port of the service instance(443)

env- volumes 서브섹션

이 섹션을 계속하기 전에 워크로드 섹션의 workload-volumes 서브섹션을 읽으십시오. 이미 언급한 대로, 첨부된 데이터 볼륨의 자동 디스크 암호화를 위해 두 개의 고객 seed를 제공해야 합니다. 하나는 workload- volumes 서브섹션에 있고 다른 하나는 env- volumes 서브섹션에 있습니다. 시드는 사용자가 선택한 임의의 텍스트일 수 있습니다.

env- volumes 하위 섹션의 다음 예를 참조하십시오

volumes:
  test:
    seed: "env phrase"

"시드 롤링" 기능을 사용하는 경우 다음 스니펫을 예로 사용할 수 있습니다.

volumes:
  test:
    seed: "env phrase1"
    previousSeed: "env phrase"

여러 볼륨을 사용하는 경우 배치자는 볼륨이 미리 작성되었는지 확인하고 계약 파일에 볼륨 ID도 지정해야 합니다. 그렇지 않으면 볼륨 이름을 지정하고 동일한 이름으로 볼륨을 작성해야 합니다. 둘 다 지정되지 않으면 볼륨 키가 볼륨 이름으로 간주되며, 가상 서버 인스턴스가 생성되는 동안 또는 그 이전에 동일한 이름으로 볼륨을 생성해야 합니다. 다음 코드 조각이 그 예입니다:

 env: |
   logging:
     logRouter:
       hostname: 34be57c7-6ff2-4685-8839-903921e90ab9.ingress.jp-tok.logs.cloud.ibm.com
       iamApiKey: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
       port: 443
   volumes:
     test1:
       apiKey: "L4SsSE32xxxxxjAgfHCVkdW8xl_CiqMn4Lpc1dzTD"
       volumeID: "r006-f7b44467-01af-xxx-xxxx-xxxxxxx"
       seed: "seed1"
     test2:
       apiKey: "L4SsSE32xxxxxjAgfHCVkdW8xl_CiqMn4Lpc1dzTD"
       volumeName: "volume2"
       seed: "seed2"
     test3:
       apiKey: "L4SsSE32xxxxxjAgfHCVkdW8xl_CiqMn4Lpc1dzTD"
       seed: "seed3"

여기서:

• 볼륨 이름: VPC에서 볼륨을 생성할 때 지정한 이름입니다.
• 볼륨 ID: 작성된 볼륨의 시스템 생성 볼륨 ID입니다.
• 볼륨 키: 각 볼륨의 고유 볼륨 이름입니다.

볼륨 키는 작업량 하위 섹션의 키와 동일해야 합니다.

언급한 대로 Hyper Protect Crypto Services 와 통합하여 세 번째 시드를 생성하고 루트 키로 랩핑할 수 있습니다. 다음 예를 참조하십시오. 자세한 정보는 데이터 보안을 참조하십시오.

volumes:
 test:
   kms:
     - apiKey: "L4SsSE32xxxxxjAgfHCVkdW8xl_CiqMn4Lpc1dzTD"
       crn: "crn:v1:bluemix:public:hs-crypto:us-south:a/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx:xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx:key:xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
       type: "public"
     - apiKey: "L4SsSE32xxxxxjAgfHCVkdW8xl_CiqMn4Lpc1dzTD"
       crn: "crn:v1:bluemix:public:hs-crypto:us-south:a/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx:xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx:key:xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
       type: "private"
   seed: "seed1"
   apiKey: "**********************"
   kmsTimeout: 10

signingKey 서브섹션

사용 방법에 대한 자세한 내용은 signingKey, 계약서 서명을 참조하세요.

env 서브섹션

• workload 섹션에서 팟 (Pod) 디스크립터가 사용되는 경우:

  play 하위 섹션 에서 템플리트 형식에 대한 예제를 참조하십시오.

• Docker 작성 파일이 workload 섹션에서 사용되는 경우:

  Docker 작성 파일에 환경 섹션이 있는 경우 다음 스니펫을 예제로 사용할 수 있습니다.

  environment:
    KEY1: "${Value1}"
    KEY2: "${Value2}"
  

  도커 컴포즈 파일에 이전 예제에서 보았던 것처럼 환경 섹션이 있는 경우, deployer의 환경 설정( env ) 섹션에 값을 전달할 수 있습니다. 다음 예제는 env 변수의 값을 지정하는 방법을 보여줍니다.

  env:
   value1: "abc"
   value2: "xyz"
  

암호화 인증서 다운로드 및 공개 키 추출

1. 인증서를 다운로드하십시오. 다음 표에는 이미지의 버전을 기반으로 하는 암호화 인증서 만료 날짜 및 더 이상 사용되지 않는 이미지 날짜가 나열되어 있습니다.

   2025년 3월 25일부터 인증서 링크가 변경됩니다.

   암호화 인증서 만료 날짜 및 이미지 사용 중단/사용되지 않는 날짜

   이미지 버전	인증서 링크	암호화 인증서 만료 날짜	지원 중단 날짜	사용 안함 날짜
   ibm-hyper-protect-container-runtime-1-0-s390x-23	인증서	2026년 2월 26일
   ibm-hyper-protect-container-runtime-1-0-s390x-22	인증서	2026년 2월 26일
   ibm-hyper-protect-container-runtime-1-0-s390x-21	인증서	2026년 2월 26일
   ibm-hyper-protect-container-runtime-1-0-s390x-20	인증서	2025년 9월 2일
   ibm-hyper-protect-container-runtime-1-0-s390x-19	인증서	2025년 9월 2일
   ibm-hyper-protect-container-runtime-1-0-s390x-18	인증서	2025년 7월 4일
   ibm-hyper-protect-container-runtime-1-0-s390x-17	인증서	2025년 7월 4일

   참고:

   • 사용 중단: 이 이미지를 사용하여 IBM Cloud 의 CLI에서 인스턴스를 생성할 수 있습니다. 사용 중단 상태는 상태가 사용 중단으로 변경되기 전에 이미지의 사용을 방해할 수 있습니다.
   • 사용 불가: 이 이미지를 사용하여 인스턴스를 만들 수 없습니다. 사용하지 않는 이미지를 인스턴스를 생성하는 데 사용하려고 하면, 해당 이미지를 인스턴스를 생성하는 데 사용할 수 없다는 메시지가 표시됩니다.
   • 항상 이미지에 해당하는 암호화 인증서를 다운로드하고 계약을 암호화하세요.

   이미지 더 이상 사용되지 않음 또는 더 이상 사용되지 않음 상태를 확인하기 위해 IBM Cloud 이미지 목록 명령을 사용할 수도 있습니다.

   이미지 목록 명령에 대한 문서 를 참조하여 이미지의 상태를 가져올 수 있습니다.

2. 계약 암호화 인증서 검증 항목의 지침에 따라 암호화 인증서를 검증합니다.

계약의 암호화된 workload 섹션 작성

계약에 있는 섹션의 값은 일반 텍스트이거나 암호화될 수 있습니다. Ubuntu 시스템에서 다음 단계를 완료하여 계약에 사용된 작업 부하 섹션을 암호화하십시오

1. 워크로드 요구사항에 따라 docker-compose.yaml 파일을 작성하십시오. 예를 들면 다음과 같습니다.

   services:
     redisnode01:
       image: s390x/redis@sha256:db467ab5c53bdeef65762a7534e26fecb94a0f218bd38afd2eaba1a670c472b1
       ports:
         - "6379:6379"
   

   자세한 정보는 Docker Compose개요 를 참조하십시오.

2. 계약의 워크로드 섹션 을 작성하고 workload.yaml 파일에 컨텐츠를 추가하십시오.

3. workload.yaml 파일 및 ibm-hyper-protect-container-runtime-1-0-s390x-23-encrypt.crt 의 전체 경로를 내보내십시오.

   WORKLOAD="<PATH to workload.yaml>"
   CONTRACT_KEY="<PATH to ibm-hyper-protect-container-runtime-1-0-s390x-23-encrypt.crt>"
   

4. 임의의 암호를 생성하려면 다음 명령을 사용하십시오(계약은 임의의 암호를 사용하는 대칭형 AES를 통해 암호화됩니다):

   PASSWORD="$(openssl rand 32 | base64 -w0)"
   

5. 다음 명령을 사용하여 ibm-hyper-protect-container-runtime-1-0-s390x-23-encrypt.crt 로 비밀번호를 암호화하십시오.

   ENCRYPTED_PASSWORD="$(echo -n "$PASSWORD" | base64 -d | openssl rsautl -encrypt -inkey $CONTRACT_KEY -certin | base64 -w0 )"
   

6. 다음 명령을 사용하여 무작위 비밀번호로 workload.yaml 파일을 암호화하십시오.

   ENCRYPTED_WORKLOAD="$(echo -n "$PASSWORD" | base64 -d | openssl enc -aes-256-cbc -pbkdf2 -pass stdin -in "$WORKLOAD" | base64 -w0)"
   

7. 다음 명령을 사용하여 계약의 암호화된 섹션을 가져오십시오.

   echo "hyper-protect-basic.${ENCRYPTED_PASSWORD}.${ENCRYPTED_WORKLOAD}"
   

8. 7단계에서 출력을 가져와서 user-data.yaml 파일에 추가하십시오.

   workload: hyper-protect-basic.js7TGt77EQ5bgTIKk5C0pViFTRHqWtn..............
   

   hyper-protect-basic 접두부는 필수입니다.

계약의 암호화된 env 섹션 작성

Ubuntu 시스템에서 다음 단계를 완료하여 계약에 사용되는 env 섹션을 암호화하십시오

1. 계약의 env 섹션 을 작성하고 env.yaml 파일에 컨텐츠를 추가하십시오.

2. env.yaml 파일 및 ibm-hyper-protect-container-runtime-1-0-s390x-23-encrypt.crt 의 전체 경로를 내보내십시오.

   ENV="<PATH to env.yaml>"
   CONTRACT_KEY="<PATH to ibm-hyper-protect-container-runtime-1-0-s390x-23-encrypt.crt>"
   

3. 다음 명령을 사용하여 임의의 비밀번호를 생성합니다:

   PASSWORD="$(openssl rand 32 | base64 -w0)"
   

4. 다음 명령을 사용하여 ibm-hyper-protect-container-runtime-1-0-s390x-23-encrypt.crt 로 비밀번호를 암호화하십시오.

   ENCRYPTED_PASSWORD="$(echo -n "$PASSWORD" | base64 -d | openssl rsautl -encrypt -inkey $CONTRACT_KEY  -certin | base64 -w0)"
   

5. 다음 명령을 사용하여 무작위 비밀번호로 env.yaml 를 암호화하십시오.

   ENCRYPTED_ENV="$(echo -n "$PASSWORD" | base64 -d | openssl enc -aes-256-cbc -pbkdf2 -pass stdin -in "$ENV" | base64 -w0)"
   

6. 다음 명령을 사용하여 계약의 암호화된 섹션을 가져오십시오.

   echo "hyper-protect-basic.${ENCRYPTED_PASSWORD}.${ENCRYPTED_ENV}"
   

7. 워크로드 섹션을 암호화하려면 계약의 암호화된 workload 섹션 작성 을 참조하십시오.

8. 6단계에서 출력을 가져와서 user-data.yaml 파일에 추가하십시오.

   env: hyper-protect-basic.VWg/5/SWE+9jLfhr8q4i.........
   

1. 로깅 인스턴스의 세부사항 가져오기

IBM Log Analysis 또는 일반 syslog 백엔드를 사용하여 로깅을 구성할 수 있습니다. 이 예제에서는 IBM Log Analysis를 사용합니다. 다양한 플랜 중에서 선택할 수 있습니다. 호스트 이름과 수집 키와 같은 필수 세부 정보를 얻는 방법을 이해하려면 VPC용 Hyper Protect Virtual Servers 의 로깅을 참조하십시오.

2. env 섹션 작성

일반 텍스트 계약을 사용하는 경우 파이프 기호 '|'를 놓치지 않도록 주의하십시오. 섹션을 암호화하려는 경우에는 필요하지 않습니다.

env: |
  type: env
  logging:
    logRouter:
      hostname: 34be57c7-6ff2-4685-8839-903921e90ab9.ingress.jp-tok.logs.cloud.ibm.com
      iamApiKey: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
      port: 443

3. Docker 작성 파일 준비

로깅 세부사항이 있다고 가정하고 단순 Docker 작성 파일을 찾으십시오. 다음 예제에는 공용 NGINX 컨테이너가 있습니다. 예제를 사용하여 docker-compose.yaml 을 작성하십시오.

services:
  nginx:
    image: docker.io/library/nginx@sha256:b1306efee704017b0e02efadc011d374063a4e9c47b86bdc57744fc3f0666383
    ports:
    - 80:80
    - 443:443

4. Docker-compose 파일의 base64-encoded 버전 가져오기

tar -czvf compose.tgz docker-compose.yaml

base64 -i compose.tgz > compose.b64

5. 작성 섹션 작성

  compose:
    archive: H4sIADXNg2IAA+3W326CMBQGcK59it555XbanraMq70KlOLIJhjqzPb2q6g3S9xiIi7T75eQlj+hDYcP6vvVuo/hMZsQJc6YsU2+t2NfsmKyyhHLjKRUSmbCTDmpo/e4KQchsqHvNz9d99v5f8of6l/3/jUMi8Puw+fq7XJj7ApsmU/WX2m7r7/j9Abs6s/W2kzQ5aZw2p3XfxuG2PZdIeZ6Poth2LY+xGImRLdsu49dR4h2VS5DsT/yHF9KZWxRSU02NCGkxJJ0FQVSoSlrn8Jba5eyrEsOT55dlduq9sY55sbrhlJpda7HG6/7YRP3YyxETkVOhz6zLtI2++unc/tO5b+84AfgrPyn4JM0pDXyfw3I/32bMvdH5+SfOK0TpdZWIv/XgPzftynX/Udn/f/NmH+l8P+/CuQfAAAAAAAAAAAAAOD2fAEPQbuiACgAAA==

6. 워크로드 섹션 채우기

일반 텍스트 계약서를 사용하는 경우 파이프 기호(|)를 놓치지 않도록 주의하십시오.

workload: |
  type: workload
  compose:
    archive: H4sIADXNg2IAA+3W326CMBQGcK59it555XbanraMq70KlOLIJhjqzPb2q6g3S9xiIi7T75eQlj+hDYcP6vvVuo/hMZsQJc6YsU2+t2NfsmKyyhHLjKRUSmbCTDmpo/e4KQchsqHvNz9d99v5f8of6l/3/jUMi8Puw+fq7XJj7ApsmU/WX2m7r7/j9Abs6s/W2kzQ5aZw2p3XfxuG2PZdIeZ6Poth2LY+xGImRLdsu49dR4h2VS5DsT/yHF9KZWxRSU02NCGkxJJ0FQVSoSlrn8Jba5eyrEsOT55dlduq9sY55sbrhlJpda7HG6/7YRP3YyxETkVOhz6zLtI2++unc/tO5b+84AfgrPyn4JM0pDXyfw3I/32bMvdH5+SfOK0TpdZWIv/XgPzftynX/Udn/f/NmH+l8P+/CuQfAAAAAAAAAAAAAOD2fAEPQbuiACgAAA==

7. 간단한 계약이 준비되었습니다.

env: |
  type: env
  logging:
    logRouter:
      hostname: 34be57c7-6ff2-4685-8839-903921e90ab9.ingress.jp-tok.logs.cloud.ibm.com
      iamApiKey: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
      port: 443
workload: |
  type: workload
  compose:
    archive: H4sIADXNg2IAA+3W326CMBQGcK59it555XbanraMq70KlOLIJhjqzPb2q6g3S9xiIi7T75eQlj+hDYcP6vvVuo/hMZsQJc6YsU2+t2NfsmKyyhHLjKRUSmbCTDmpo/e4KQchsqHvNz9d99v5f8of6l/3/jUMi8Puw+fq7XJj7ApsmU/WX2m7r7/j9Abs6s/W2kzQ5aZw2p3XfxuG2PZdIeZ6Poth2LY+xGImRLdsu49dR4h2VS5DsT/yHF9KZWxRSU02NCGkxJJ0FQVSoSlrn8Jba5eyrEsOT55dlduq9sY55sbrhlJpda7HG6/7YRP3YyxETkVOhz6zLtI2++unc/tO5b+84AfgrPyn4JM0pDXyfw3I/32bMvdH5+SfOK0TpdZWIv/XgPzftynX/Udn/f/NmH+l8P+/CuQfAAAAAAAAAAAAAOD2fAEPQbuiACgAAA==