3.17. OpenShift Pipelines 공급망 보안에 Tekton 체인 사용

Tekton Chains는 Kubernetes CRD(Custom Resource Definition) 컨트롤러입니다. 이를 사용하여 Red Hat OpenShift Pipelines를 사용하여 생성된 작업 및 파이프라인의 공급망 보안을 관리할 수 있습니다.

기본적으로 Tekton Chains는 OpenShift Container Platform 클러스터에서 모든 작업 실행 실행을 관찰합니다. 작업이 완료되면 Tekton Chains는 작업 실행 스냅샷을 사용합니다. 그런 다음 스냅샷을 하나 이상의 표준 페이로드 형식으로 변환하고 마지막으로 모든 아티팩트에 서명하고 저장합니다.

작업 실행에 대한 정보를 캡처하기 위해 Tekton 체인은 Result 오브젝트를 사용합니다. 오브젝트를 사용할 수 없는 경우 Tekton은 OCI 이미지의 URL 및 인증된 다이제스트를 조작합니다.

3.17.1. 주요 기능

  • cosignskopeo 와 같은 툴을 통해 생성된 암호화 키를 사용하여 작업 실행, 작업 실행 결과, OCI 레지스트리 이미지에 서명할 수 있습니다.
  • in-toto 와 같은 증명 형식을 사용할 수 있습니다.
  • OCI 리포지토리를 스토리지 백엔드로 사용하여 서명 및 서명된 아티팩트를 안전하게 저장할 수 있습니다.

3.17.2. Tekton 체인 구성

Red Hat OpenShift Pipelines Operator는 기본적으로 Tekton 체인을 설치합니다. TektonConfig 사용자 정의 리소스를 수정하여 Tekton 체인을 구성할 수 있습니다. Operator는 이 사용자 정의 리소스에서 변경한 사항을 자동으로 적용합니다.

사용자 정의 리소스를 편집하려면 다음 명령을 사용합니다.

$ oc edit TektonConfig config

사용자 정의 리소스에는 체인 배열이 포함됩니다. 다음 예와 같이 지원되는 모든 구성 매개변수를 이 배열에 추가할 수 있습니다.

apiVersion: operator.tekton.dev/v1alpha1
kind: TektonConfig
metadata:
  name: config
spec:
  addon: {}
  chain:
    artifacts.taskrun.format: tekton
  config: {}

3.17.2.1. Tekton 체인 구성에 지원되는 매개변수

클러스터 관리자는 지원되는 다양한 매개변수 키와 값을 사용하여 작업 실행, OCI 이미지 및 스토리지에 대한 사양을 구성할 수 있습니다.

3.17.2.1.1. 작업 실행 아티팩트에 지원되는 매개변수

표 3.19. 체인 구성: 작업 실행 아티팩트에 대해 지원되는 매개변수

설명지원되는 값기본값

artifacts.taskrun.format

작업 실행 페이로드를 저장하는 형식입니다.

in-toto, slsa/v1

in-toto

artifacts.taskrun.storage

작업 실행 서명의 스토리지 백엔드입니다. 여러 백엔드를 "tekton,oci" 와 같은 쉼표로 구분된 목록으로 지정할 수 있습니다. 작업 실행 아티팩트 저장을 비활성화하려면 빈 문자열 "" 를 제공합니다.

tekton, oci, gcs, docdb, grafeas

tekton

artifacts.taskrun.signer

작업 실행 페이로드에 서명하기 위한 서명 백엔드입니다.

x509,kms

x509

참고

slsa/v1 은 이전 버전과의 호환성을 위해 In-to 의 별칭입니다.

3.17.2.1.2. 파이프라인 실행 아티팩트에 지원되는 매개변수

표 3.20. 체인 구성: 파이프라인 실행 아티팩트에 대해 지원되는 매개변수

매개변수설명지원되는 값기본값

artifacts.pipelinerun.format

파이프라인 실행 페이로드를 저장하는 형식입니다.

in-toto, slsa/v1

in-toto

artifacts.pipelinerun.storage

파이프라인 실행 서명을 저장하기 위한 스토리지 백엔드입니다. 여러 백엔드를 "tekton,oci" 와 같은 쉼표로 구분된 목록으로 지정할 수 있습니다. 파이프라인 실행 아티팩트 저장을 비활성화하려면 빈 문자열 "" 를 제공합니다.

tekton, oci, gcs, docdb, grafeas

tekton

artifacts.pipelinerun.signer

파이프라인 실행 페이로드에 서명하기 위한 서명 백엔드입니다.

x509, kms

x509

참고
  • slsa/v1 은 이전 버전과의 호환성을 위해 In-to 의 별칭입니다.
  • grafeas 스토리지 백엔드의 경우 컨테이너 분석만 지원됩니다. Tekton 체인의 현재 버전에서는 grafeas 서버 주소를 구성할 수 없습니다.
3.17.2.1.3. OCI 아티팩트에 지원되는 매개변수

표 3.21. 체인 구성: OCI 아티팩트에 대해 지원되는 매개변수

매개변수설명지원되는 값기본값

artifacts.oci.format

OCI 페이로드를 저장하는 형식입니다.

simplesigning

simplesigning

artifacts.oci.storage

OCI 서명을 저장하기 위한 스토리지 백엔드입니다. 여러 백엔드를 "oci,tekton" 과 같은 쉼표로 구분된 목록으로 지정할 수 있습니다. OCI 아티팩트 저장을 비활성화하려면 빈 문자열 "" 를 제공합니다.

tekton, oci, gcs, docdb, grafeas

oci

artifacts.oci.signer

OCI 페이로드에 서명하기 위한 서명 백엔드입니다.

x509, kms

x509

3.17.2.1.4. KMS 서명자에서 지원되는 매개변수

표 3.22. 체인 설정: KMS 서명자에 대해 지원되는 매개변수

매개변수설명지원되는 값기본값

signers.kms.kmsref

kms 서명자에서 사용할 KMS 서비스에 대한 URI 참조입니다.

지원되는 스키마: gcpkms://, awskms://, azurekms://, hashivault://. 자세한 내용은 Sigstore 설명서의 KMS 지원을 참조하십시오.

 
3.17.2.1.5. 스토리지에 지원되는 매개변수

표 3.23. 체인 구성: 스토리지에 지원되는 매개변수

매개변수설명지원되는 값기본값

storage.gcs.bucket

스토리지를 위한 GCS 버킷

  

artifacts.oci.repository

OCI 서명 및 인증을 저장하기 위한 OCI 리포지토리입니다.

아티팩트 스토리지 백엔드 중 하나를 oci 로 구성하고 이 키를 정의하지 않으면 Tekton 체인은 저장된 OCI 아티팩트 자체와 함께 인증 정보를 저장합니다. 이 키를 정의하면 인증 정보는 OCI 아티팩트와 함께 저장되지 않으며 대신 지정된 위치에 저장됩니다. 자세한 내용은 cosign 문서를 참조하십시오.

 

builder.id

인증 정보용으로 설정할 빌더 ID

 

https://tekton.dev/chains/v2

docdb 스토리지 방법이 아티팩트에 해당하는 경우 docstore 스토리지 옵션을 구성합니다. go-cloud docstore URI 형식에 대한 자세한 내용은 docstore 패키지 설명서 를 참조하십시오. Red Hat OpenShift Pipelines는 다음 문서 서비스를 지원합니다.

  • Firestore
  • dynamodb

표 3.24. 체인 구성: docstore 스토리지에 대해 지원되는 매개변수

매개변수설명지원되는 값기본값

storage.docdb.url

docstore 컬렉션에 대한 go-cloud URI 참조입니다. 모든 아티팩트에 대해 docdb 스토리지 방법이 활성화된 경우 사용됩니다.

Firestore://projects/[PROJECT]/databases/(default)/documents/[COLLECTION]?name_field=name

 

아티팩트에 대해 grafeas 스토리지 방법을 활성화하면 Grafeas 스토리지 옵션을 구성합니다. Grafeas 노트 및 발생에 대한 자세한 내용은 Grafeas 개념을 참조하십시오.

발생을 생성하기 위해 Red Hat OpenShift Pipelines는 먼저 발생을 연결하는 데 사용되는 노트를 생성해야 합니다. Red Hat OpenShift Pipelines는 두 가지 유형인 ATTESTATION Occurrence 및 BUILD Occurrence를 생성합니다.

Red Hat OpenShift Pipelines는 구성 가능한 noteid 를 노트 이름의 접두사로 사용합니다. ATTESTATION 노트에 대한 접미사 -simplesigningBUILD note의 접미사 -intoto 를 추가합니다. noteid 필드가 구성되지 않은 경우 Red Hat OpenShift Pipelines는 tekton-<NAMESPACE >를 접두사로 사용합니다.

표 3.25. 체인 구성: Grafeas 스토리지에 지원되는 매개변수

매개변수설명지원되는 값기본값

storage.grafeas.projectid

발생을 저장하기 위한 Grafeas 서버가 있는 OpenShift Container Platform 프로젝트입니다.

  

storage.grafeas.noteid

선택 사항: 생성된 모든 노트의 이름에 사용할 접두사입니다.

공백이 없는 문자열입니다.

 

storage.grafeas.notehint

선택 사항: Grafeas ATTESTATION 참고 사항의 human_readable_name 필드입니다.

 

이 인증 노트는 Tekton 체인에 의해 생성되었습니다.

선택적으로 바이너리 투명성 증명의 추가 업로드를 활성화할 수 있습니다.

표 3.26. 체인 구성: 투명성 강화 스토리지를 위한 지원되는 매개변수

매개변수설명지원되는 값기본값

transparency.enabled

자동 바이너리 투명도 업로드를 활성화하거나 비활성화합니다.

true,false,manual

false

transparency.url

활성화된 경우 바이너리 투명도를 업로드하기 위한 URL입니다.

 

https://rekor.sigstore.dev

참고

transparency.enabled수동 으로 설정하면 다음 주석이 있는 작업 실행 및 파이프라인 실행만 투명 로그에 업로드됩니다.

chains.tekton.dev/transparency-upload: "true"

x509 서명 백엔드를 구성하는 경우 Fulcio를 사용하여 키 없이 서명을 선택적으로 활성화할 수 있습니다.

표 3.27. 체인 구성: Fulcio를 사용한 x509 키 없이 서명에 대해 지원되는 매개변수

매개변수설명지원되는 값기본값

signers.x509.fulcio.enabled

Fulcio에서 자동 인증서 요청 요청을 활성화하거나 비활성화합니다.

true, false

false

signers.x509.fulcio.address

활성화된 경우 인증서를 요청하는 Fulcio 주소입니다.

 

https://v1.fulcio.sigstore.dev

signers.x509.fulcio.issuer

예상되는 OIDC 발행자

 

https://oauth2.sigstore.dev/auth

signers.x509.fulcio.provider

ID 토큰을 요청할 공급자입니다.

Google,spiffe,github,파일 시스템

Red Hat OpenShift Pipelines는 모든 공급자를 사용하려고 합니다.

signers.x509.identity.token.file

ID 토큰이 포함된 파일의 경로입니다.

  

signers.x509.tuf.mirror.url

TUF 서버의 URL입니다. $TUF_URL/root.json 이 있어야 합니다.

 

https://sigstore-tuf-root.storage.googleapis.com

kms 서명 백엔드를 구성하는 경우 필요에 따라 OIDC 및 Spire를 포함한 KMS 구성을 설정합니다.

표 3.28. 체인 구성: KMS 서명에 지원되는 매개변수

매개변수설명지원되는 값기본값

signers.kms.auth.address

KMS 서버의 URI( VAULT_ADDR값 ).

signers.kms.auth.token

KMS 서버의 인증 토큰( VAULT_TOKEN값 ).

signers.kms.auth.oidc.path

OIDC 인증 경로(예: Vault의 경우 jwt )입니다.

signers.kms.auth.oidc.role

OIDC 인증의 역할입니다.

signers.kms.auth.spire.sock

KMS 토큰에 대한 Spire 소켓의 URI입니다(예: unix:///tmp/spire-agent/public/api.sock).

signers.kms.auth.spire.audience

SVID를 Spire에서 요청하는 대상입니다.

3.17.3. Tekton 체인에서 데이터에 서명하기 위한 보안

클러스터 관리자는 키 쌍을 생성하고 Tekton Chains를 사용하여 Kubernetes 시크릿을 사용하여 아티팩트에 서명할 수 있습니다. Tekton 체인이 작동하려면 암호화된 키의 개인 키와 암호가 openshift-pipelines 네임스페이스에 signing-secrets 시크릿의 일부로 존재해야 합니다.

현재 Tekton Chains는 x509cosign 서명 체계를 지원합니다.

참고

지원되는 서명 체계 중 하나만 사용하십시오.

Tekton Chains와 함께 x509 서명 스키마를 사용하려면 ed25519 또는 ecdsa 유형의 x509.pem 개인 키를 signing-secrets Kubernetes 시크릿에 저장합니다.

3.17.3.1. cosign을 사용하여 서명

cosign 툴을 사용하여 Tekton 체인에 공동 서명 스키마를 사용할 수 있습니다.

사전 요구 사항

  • cosign 툴을 설치했습니다.

절차

  1. 다음 명령을 실행하여 cosign.keycosign.pub 키 쌍을 생성합니다.

    $ cosign generate-key-pair k8s://openshift-pipelines/signing-secrets

    cosign은 암호를 입력하라는 메시지를 표시한 다음 Kubernetes 시크릿을 생성합니다.

  2. signing-secrets Kubernetes 시크릿에 암호화된 cosign.key 개인 키와 cosign.password 암호 해독 암호를 저장합니다. 개인 키가 ENCRYPTED COSIGN PRIVATE KEY 유형의 암호화된 PEM 파일로 저장되었는지 확인합니다.

3.17.3.2. skopeo를 사용하여 서명

skopeo 툴을 사용하여 키를 생성하고 Tekton 체인과 함께 cosign 서명 스키마에 사용할 수 있습니다.

사전 요구 사항

  • skopeo 툴을 설치했습니다.

절차

  1. 다음 명령을 실행하여 공개/개인 키 쌍을 생성합니다.

    $ skopeo generate-sigstore-key --output-prefix <mykey> 1
    1
    & lt;mykey >를 선택한 키 이름으로 바꿉니다.

    Skopeo는 개인 키에 대한 암호를 입력하라는 메시지를 표시한 다음 <mykey> .private 및 <mykey > .pub 라는 키 파일을 만듭니다.

  2. 다음 명령을 실행하여 base64 툴을 사용하여 < mykey>.pub 파일을 인코딩합니다.

    $ base64 -w 0 <mykey>.pub > b64.pub
  3. 다음 명령을 실행하여 base64 툴을 사용하여 < mykey>.private 파일을 인코딩합니다.

    $ base64 -w 0 <mykey>.private > b64.private
  4. 다음 명령을 실행하여 base64 툴을 사용하여 passhprase를 인코딩합니다.

    $ echo -n '<passphrase>' | base64 -w 0 > b64.passphrase 1
    1
    & lt;passphrase& gt;를 키 쌍에 사용한 암호로 바꿉니다.
  5. 다음 명령을 실행하여 openshift-pipelines 네임스페이스에 signing-secrets 시크릿을 생성합니다.

    $ oc create secret generic signing-secrets -n openshift-pipelines
  6. 다음 명령을 실행하여 signing-secrets 시크릿을 편집합니다.

    $ oc edit secret -n openshift-pipelines signing-secrets

    다음과 같은 방식으로 시크릿 데이터에 인코딩된 키를 추가합니다.

    apiVersion: v1
    data:
      cosign.key: <Encoded <mykey>.private> 1
      cosign.password: <Encoded passphrase> 2
      cosign.pub: <Encoded <mykey>.pub> 3
    immutable: true
    kind: Secret
    metadata:
      name: signing-secrets
    # ...
    type: Opaque
    1
    & lt;Encoded <mykey>.private >을 b64.private 파일의 내용으로 바꿉니다.
    2
    & lt;Encoded passphrase& gt;를 b64.passphrase 파일의 콘텐츠로 바꿉니다.
    3
    & lt;Encoded <mykey>.pub >를 b64.pub 파일의 내용으로 바꿉니다.

3.17.3.3. "비밀번호가 이미 있음" 오류 해결

signing-secret 시크릿이 이미 채워진 경우 이 보안을 생성하는 명령에서 다음 오류 메시지를 출력할 수 있습니다.

Error from server (AlreadyExists): secrets "signing-secrets" already exists

보안을 삭제하여 이 오류를 해결할 수 있습니다.

절차

  1. 다음 명령을 실행하여 signing-secret 시크릿을 삭제합니다.

    $ oc delete secret signing-secrets -n openshift-pipelines
  2. 키 쌍을 다시 생성하여 선호하는 서명 스키마를 사용하여 시크릿에 저장합니다.

3.17.4. OCI 레지스트리에 인증

클러스터 관리자는 OCI 레지스트리로 서명을 푸시하기 전에 레지스트리에 인증하도록 Tekton Chains를 구성해야 합니다. Tekton Chains 컨트롤러는 작업을 실행하는 동일한 서비스 계정을 사용합니다. 서명을 OCI 레지스트리로 푸시하는 데 필요한 자격 증명으로 서비스 계정을 설정하려면 다음 단계를 수행합니다.

절차

  1. Kubernetes 서비스 계정의 네임스페이스 및 이름을 설정합니다.

    $ export NAMESPACE=<namespace> 1
    $ export SERVICE_ACCOUNT_NAME=<service_account> 2
    1
    서비스 계정과 연결된 네임스페이스입니다.
    2
    서비스 계정의 이름입니다.
  2. Kubernetes 시크릿을 생성합니다.

    $ oc create secret registry-credentials \
      --from-file=.dockerconfigjson \ 1
      --type=kubernetes.io/dockerconfigjson \
      -n $NAMESPACE
    1
    Docker 구성 파일의 경로로 바꿉니다. 기본 경로는 ~/.docker/config.json 입니다.
  3. 시크릿에 서비스 계정 액세스 권한을 부여합니다.

    $ oc patch serviceaccount $SERVICE_ACCOUNT_NAME \
      -p "{\"imagePullSecrets\": [{\"name\": \"registry-credentials\"}]}" -n $NAMESPACE

    Red Hat OpenShift Pipelines가 모든 작업 실행에 할당하는 기본 파이프라인 서비스 계정을 패치하면 Red Hat OpenShift Pipelines Operator가 서비스 계정을 재정의합니다. 모범 사례로 다음 단계를 수행할 수 있습니다.

    1. 사용자 작업 실행에 할당할 별도의 서비스 계정을 생성합니다.

      $ oc create serviceaccount <service_account_name>
    2. 작업 실행 템플릿에서 serviceaccountname 필드의 값을 설정하여 서비스 계정을 작업 실행에 연결합니다.

      apiVersion: tekton.dev/v1beta1
      kind: TaskRun
      metadata:
      name: build-push-task-run-2
      spec:
      serviceAccountName: build-bot 1
      taskRef:
        name: build-push
      ...
      1
      새로 생성된 서비스 계정의 이름으로 바꿉니다.

3.17.5. 추가 인증없이 작업 실행 서명 생성 및 확인

추가 인증과 함께 Tekton Chains를 사용하여 작업 실행 서명을 확인하려면 다음 작업을 수행합니다.

  • 암호화된 x509 키 쌍을 생성하여 Kubernetes 시크릿으로 저장합니다.
  • Tekton 체인 백엔드 스토리지를 구성합니다.
  • 작업 실행을 생성하고 서명하고, 작업 실행 자체에 서명 및 페이로드를 주석으로 저장합니다.
  • 서명된 작업 실행에서 서명 및 페이로드를 검색합니다.
  • 작업 실행 서명을 확인합니다.

사전 요구 사항

다음 구성 요소가 클러스터에 설치되어 있는지 확인합니다.

  • Red Hat OpenShift Pipelines Operator
  • Tekton 체인
  • cosign

절차

  1. 암호화된 x509 키 쌍을 생성하여 Kubernetes 시크릿으로 저장합니다. 키 쌍을 생성하여 시크릿으로 저장하는 방법에 대한 자세한 내용은 " Tekton 체인에서 시크릿 서명"을 참조하십시오.
  2. Tekton Chains 구성에서 OCI 스토리지를 비활성화하고 작업 실행 스토리지 및 형식을 tekton 로 설정합니다. TektonConfig 사용자 지정 리소스에서 다음 값을 설정합니다.

    apiVersion: operator.tekton.dev/v1alpha1
    kind: TektonConfig
    metadata:
      name: config
    spec:
    # ...
        chain:
          artifacts.oci.storage: ""
          artifacts.taskrun.format: tekton
          artifacts.taskrun.storage: tekton
    # ...

    TektonConfig 사용자 지정 리소스를 사용하여 Tekton 체인 구성에 대한 자세한 내용은 " Tekton 체인 구성"을 참조하십시오.

  3. Tekton 체인 컨트롤러를 다시 시작하여 수정된 구성이 적용되었는지 확인하려면 다음 명령을 입력합니다.

    $ oc delete po -n openshift-pipelines -l app=tekton-chains-controller
  4. 다음 명령을 입력하여 작업 실행을 생성합니다.

    $ oc create -f https://raw.githubusercontent.com/tektoncd/chains/main/examples/taskruns/task-output-image.yaml 1
    1
    예제 URI를 작업 실행을 가리키는 URI 또는 파일 경로로 바꿉니다.

    출력 예

    taskrun.tekton.dev/build-push-run-output-image-qbjvh created

  5. 다음 명령을 입력하여 단계의 상태를 확인합니다. 프로세스가 완료될 때까지 기다립니다.

    $ tkn tr describe --last

    출력 예

    [...truncated output...]
    NAME                            STATUS
    ∙ create-dir-builtimage-9467f   Completed
    ∙ git-source-sourcerepo-p2sk8   Completed
    ∙ build-and-push                Completed
    ∙ echo                          Completed
    ∙ image-digest-exporter-xlkn7   Completed

  6. base64 로 인코딩된 주석으로 저장된 오브젝트에서 서명을 검색하려면 다음 명령을 입력합니다.

    $ tkn tr describe --last -o jsonpath="{.metadata.annotations.chains\.tekton\.dev/signature-taskrun-$TASKRUN_UID}" | base64 -d > sig
    $ export TASKRUN_UID=$(tkn tr describe --last -o  jsonpath='{.metadata.uid}')
  7. 생성한 공개 키를 사용하여 서명을 확인하려면 다음 명령을 입력합니다.
$ cosign verify-blob-attestation --insecure-ignore-tlog --key path/to/cosign.pub --signature sig --type slsaprovenance --check-claims=false /dev/null 1
1
path/to/cosign.pub 를 공개 키 파일의 경로 이름으로 바꿉니다.

출력 예

Verified OK

3.17.5.1. 추가 리소스

3.17.6. Tekton Chains를 사용하여 이미지 및 검증에 서명 및 확인

클러스터 관리자는 다음 작업을 수행하여 Tekton Chains를 사용하여 이미지와 검증에 서명하고 검증할 수 있습니다.

  • 암호화된 x509 키 쌍을 생성하여 Kubernetes 시크릿으로 저장합니다.
  • 이미지, 이미지 서명 및 서명된 이미지 인증서를 저장할 OCI 레지스트리에 대한 인증을 설정합니다.
  • Tekton Chains를 구성하고 서명할 수 있도록 구성합니다.
  • 작업 실행에서 Kaniko로 이미지를 만듭니다.
  • 서명된 이미지와 서명된 검증 정보를 확인합니다.

사전 요구 사항

클러스터에 다음이 설치되어 있는지 확인합니다.

  • Red Hat OpenShift Pipelines Operator
  • Tekton 체인
  • cosign
  • Rekor
  • jq

절차

  1. 암호화된 x509 키 쌍을 생성하고 Kubernetes 시크릿으로 저장합니다.

    $ cosign generate-key-pair k8s://openshift-pipelines/signing-secrets

    메시지가 표시되면 암호를 입력합니다. cosign은 생성된 개인 키를 openshift-pipelines 네임스페이스에 signing-secrets Kubernetes 시크릿의 일부로 저장하고 공개 키를 cosign.pub 로컬 파일에 씁니다.

  2. 이미지 레지스트리에 대한 인증을 구성합니다.

    1. 서명을 OCI 레지스트리로 푸시하도록 Tekton Chains 컨트롤러를 구성하려면 작업 실행의 서비스 계정과 연결된 자격 증명을 사용합니다. 자세한 내용은 "COO 레지스트리에 대한 인증" 섹션을 참조하십시오.
    2. 이미지를 빌드하고 레지스트리로 푸시하는 Kaniko 작업에 대한 인증을 구성하려면 필요한 인증 정보가 포함된 docker config.json 파일의 Kubernetes 시크릿을 생성합니다.

      $ oc create secret generic <docker_config_secret_name> \ 1
        --from-file <path_to_config.json> 2
      1
      docker 구성 보안의 이름으로 바꿉니다.
      2
      docker config.json 파일의 경로로 바꿉니다.
  3. chain-config 오브젝트에서 artifacts.taskrun.format,artifacts.taskrun.storage, transparency.enabled 매개변수를 설정하여 Tekton 체인 을 구성합니다.

    $ oc patch configmap chains-config -n openshift-pipelines -p='{"data":{"artifacts.taskrun.format": "in-toto"}}'
    
    $ oc patch configmap chains-config -n openshift-pipelines -p='{"data":{"artifacts.taskrun.storage": "oci"}}'
    
    $ oc patch configmap chains-config -n openshift-pipelines -p='{"data":{"transparency.enabled": "true"}}'
  4. Kaniko 작업을 시작합니다.

    1. Kaniko 작업을 클러스터에 적용합니다.

      $ oc apply -f examples/kaniko/kaniko.yaml 1
      1
      Kaniko 작업의 URI 또는 파일 경로로 바꿉니다.
    2. 적절한 환경 변수를 설정합니다.

      $ export REGISTRY=<url_of_registry> 1
      
      $ export DOCKERCONFIG_SECRET_NAME=<name_of_the_secret_in_docker_config_json> 2
      1
      이미지를 푸시하려는 레지스트리의 URL로 바꿉니다.
      2
      docker config.json 파일에서 보안 이름으로 바꿉니다.
    3. Kaniko 작업을 시작합니다.

      $ tkn task start --param IMAGE=$REGISTRY/kaniko-chains --use-param-defaults --workspace name=source,emptyDir="" --workspace name=dockerconfig,secret=$DOCKERCONFIG_SECRET_NAME kaniko-chains

      모든 단계가 완료될 때까지 이 작업의 로그를 관찰합니다. 인증에 성공하면 최종 이미지가 $REGISTRY/kaniko-chains 로 푸시됩니다.

  5. Tekton Chains가 이를 생성하고 서명할 수 있도록 1분 정도 기다린 다음 작업 실행에서 chain.tekton.dev/signed=true 주석의 가용성을 확인합니다.

    $ oc get tr <task_run_name> \ 1
    -o json | jq -r .metadata.annotations
    
    {
      "chains.tekton.dev/signed": "true",
      ...
    }
    1
    작업 실행 이름으로 바꿉니다.
  6. 이미지와 attestation을 확인합니다.

    $ cosign verify --key cosign.pub $REGISTRY/kaniko-chains
    
    $ cosign verify-attestation --key cosign.pub $REGISTRY/kaniko-chains
  7. Rekor에서 이미지의 입증된 정보를 찾으십시오.

    1. $REGISTRY/kaniko-chains 이미지의 다이제스트를 가져옵니다. 작업 실행을 검색하거나 이미지를 가져와서 다이제스트를 추출할 수 있습니다.
    2. Rekor를 검색하여 이미지의 sha256 다이제스트와 일치하는 모든 항목을 찾습니다.

      $ rekor-cli search --sha <image_digest> 1
      
      <uuid_1> 2
      <uuid_2> 3
      ...
      1
      이미지 sha256 다이제스트로 바꿉니다.
      2
      처음 일치하는 UUID(Universally unique identifier)입니다.
      3
      두 번째와 일치하는 UUID입니다.

      검색 결과에는 일치하는 항목의 UUID가 표시됩니다. 이러한 UUID 중 하나에는 검증이 있습니다.

    3. 인증서를 확인하십시오.

      $ rekor-cli get --uuid <uuid> --format json | jq -r .Attestation | base64 --decode | jq

3.17.7. 추가 리소스