OpenShift Pipelines 보안
OpenShift Pipelines의 보안 기능
초록
1장. OpenShift Pipelines 공급망 보안에 Tekton 체인 사용 링크 복사링크가 클립보드에 복사되었습니다!
Tekton 체인은 Kubernetes CRD(Custom Resource Definition) 컨트롤러입니다. 이를 사용하여 Red Hat OpenShift Pipelines를 사용하여 생성된 작업 및 파이프라인의 공급망 보안을 관리할 수 있습니다.
기본적으로 Tekton 체인은 OpenShift Container Platform 클러스터의 모든 작업 실행 실행을 관찰합니다. 작업이 완료되면 Tekton 체인은 작업 실행의 스냅샷을 사용합니다. 그런 다음 스냅샷을 하나 이상의 표준 페이로드 형식으로 변환하고 마지막으로 모든 아티팩트를 서명하고 저장합니다.
작업 실행에 대한 정보를 캡처하기 위해 Tekton 체인은 Result 오브젝트를 사용합니다. 오브젝트를 사용할 수 없는 경우 Tekton은 OCI 이미지의 URL과 인증된 다이제스트를 체인합니다.
1.1. 주요 기능 링크 복사링크가 클립보드에 복사되었습니다!
-
cosign및skopeo와 같은 툴을 통해 생성된 암호화 키를 사용하여 작업 실행, 작업 실행 결과, OCI 레지스트리 이미지에 서명할 수 있습니다. -
인증 형식(예:
in-to-to)을 사용할 수 있습니다. - OCI 리포지토리를 스토리지 백엔드로 사용하여 서명 및 서명된 아티팩트를 안전하게 저장할 수 있습니다.
1.2. Tekton 체인 구성 링크 복사링크가 클립보드에 복사되었습니다!
Red Hat OpenShift Pipelines Operator는 기본적으로 Tekton 체인을 설치합니다. TektonConfig 사용자 정의 리소스를 수정하여 Tekton 체인을 구성할 수 있습니다. Operator는 이 사용자 정의 리소스에서 변경한 사항을 자동으로 적용합니다.
사용자 정의 리소스를 편집하려면 다음 명령을 사용합니다.
oc edit TektonConfig config
$ oc edit TektonConfig config
사용자 정의 리소스에는 체인 배열이 포함됩니다. 다음 예와 같이 지원되는 모든 구성 매개변수를 이 배열에 추가할 수 있습니다.
1.2.1. Tekton 체인 구성에 지원되는 매개변수 링크 복사링크가 클립보드에 복사되었습니다!
클러스터 관리자는 지원되는 다양한 매개변수 키와 값을 사용하여 작업 실행, OCI 이미지 및 스토리지에 대한 사양을 구성할 수 있습니다.
1.2.1.1. 작업 실행 아티팩트에 지원되는 매개변수 링크 복사링크가 클립보드에 복사되었습니다!
| 키 | 설명 | 지원되는 값 | 기본값 |
|---|---|---|---|
|
| 작업 실행 페이로드를 저장하는 형식입니다. |
|
|
|
|
작업 실행 서명을 위한 스토리지 백엔드입니다. |
|
|
|
| 작업 실행 페이로드에 서명하기 위한 서명 백엔드입니다. |
|
|
slsa/v1 은 이전 버전과의 호환성을 위해 In-to 의 별칭입니다.
1.2.1.2. 파이프라인 실행 아티팩트에 지원되는 매개변수 링크 복사링크가 클립보드에 복사되었습니다!
| 매개변수 | 설명 | 지원되는 값 | 기본값 |
|---|---|---|---|
|
| 파이프라인 실행 페이로드를 저장하는 형식입니다. |
|
|
|
|
파이프라인 실행 서명을 저장하기 위한 스토리지 백엔드입니다. |
|
|
|
| 파이프라인 실행 페이로드에 서명하기 위한 서명 백엔드입니다. |
|
|
-
slsa/v1은 이전 버전과의 호환성을 위해In-to의 별칭입니다. -
grafeas스토리지 백엔드의 경우 컨테이너 분석만 지원됩니다. Tekton 체인의 현재 버전에서는grafeas서버 주소를 구성할 수 없습니다.
1.2.1.3. OCI 아티팩트에 지원되는 매개변수 링크 복사링크가 클립보드에 복사되었습니다!
| 매개변수 | 설명 | 지원되는 값 | 기본값 |
|---|---|---|---|
|
| OCI 페이로드를 저장하는 형식입니다. |
|
|
|
|
OCI 서명을 저장하기 위한 스토리지 백엔드입니다. |
|
|
|
| OCI 페이로드에 서명하기 위한 서명 백엔드입니다. |
|
|
1.2.1.4. KMS 서명자에서 지원되는 매개변수 링크 복사링크가 클립보드에 복사되었습니다!
| 매개변수 | 설명 | 지원되는 값 | 기본값 |
|---|---|---|---|
|
|
|
지원되는 스키마: |
1.2.1.5. 스토리지에 지원되는 매개변수 링크 복사링크가 클립보드에 복사되었습니다!
| 매개변수 | 설명 | 지원되는 값 | 기본값 |
|---|---|---|---|
|
| 스토리지를 위한 GCS 버킷 | ||
|
| OCI 서명 및 인증을 저장하기 위한 OCI 리포지토리입니다. |
아티팩트 스토리지 백엔드 중 하나를 | |
|
| 인증 정보용으로 설정할 빌더 ID |
|
docdb 스토리지 방법이 아티팩트에 해당하는 경우 docstore 스토리지 옵션을 구성합니다. go-cloud docstore URI 형식에 대한 자세한 내용은 docstore 패키지 설명서 를 참조하십시오. Red Hat OpenShift Pipelines는 다음 문서 서비스를 지원합니다.
-
firestore -
dynamodb
| 매개변수 | 설명 | 지원되는 값 | 기본값 |
|---|---|---|---|
|
|
|
|
아티팩트에 대해 grafeas 스토리지 방법을 활성화하면 Grafeas 스토리지 옵션을 구성합니다. Grafeas 노트 및 발생에 대한 자세한 내용은 Grafeas 개념을 참조하십시오.
발생을 생성하기 위해 Red Hat OpenShift Pipelines는 먼저 발생을 연결하는 데 사용되는 노트를 생성해야 합니다. Red Hat OpenShift Pipelines는 두 가지 유형인 ATTESTATION Occurrence 및 BUILD Occurrence를 생성합니다.
Red Hat OpenShift Pipelines는 구성 가능한 noteid 를 노트 이름의 접두사로 사용합니다. ATTESTATION 노트에 대한 접미사 -simplesigning 과 BUILD note의 접미사 -intoto 를 추가합니다. noteid 필드가 구성되지 않은 경우 Red Hat OpenShift Pipelines는 tekton-<NAMESPACE >를 접두사로 사용합니다.
| 매개변수 | 설명 | 지원되는 값 | 기본값 |
|---|---|---|---|
|
| 발생을 저장하기 위한 Grafeas 서버가 있는 OpenShift Container Platform 프로젝트입니다. | ||
|
| 선택 사항: 생성된 모든 노트의 이름에 사용할 접두사입니다. | 공백이 없는 문자열입니다. | |
|
|
선택 사항: Grafeas |
|
선택적으로 바이너리 투명성 증명의 추가 업로드를 활성화할 수 있습니다.
| 매개변수 | 설명 | 지원되는 값 | 기본값 |
|---|---|---|---|
|
| 자동 바이너리 투명도 업로드를 활성화하거나 비활성화합니다. |
|
|
|
| 활성화된 경우 바이너리 투명도를 업로드하기 위한 URL입니다. |
|
transparency.enabled 를 수동 으로 설정하면 다음 주석이 있는 작업 실행 및 파이프라인 실행만 투명 로그에 업로드됩니다.
chains.tekton.dev/transparency-upload: "true"
chains.tekton.dev/transparency-upload: "true"
x509 서명 백엔드를 구성하는 경우 Fulcio를 사용하여 키 없이 서명을 선택적으로 활성화할 수 있습니다.
| 매개변수 | 설명 | 지원되는 값 | 기본값 |
|---|---|---|---|
|
| Fulcio에서 자동 인증서 요청 요청을 활성화하거나 비활성화합니다. |
|
|
|
| 활성화된 경우 인증서를 요청하는 Fulcio 주소입니다. |
| |
|
| 예상되는 OIDC 발행자 |
| |
|
| ID 토큰을 요청할 공급자입니다. |
| Red Hat OpenShift Pipelines는 모든 공급자를 사용하려고 합니다. |
|
| ID 토큰이 포함된 파일의 경로입니다. | ||
|
|
TUF 서버의 URL입니다. |
|
kms 서명 백엔드를 구성하는 경우 필요에 따라 OIDC 및 Spire를 포함한 KMS 구성을 설정합니다.
| 매개변수 | 설명 | 지원되는 값 | 기본값 |
|---|---|---|---|
|
|
KMS 서버의 URI( | ||
|
|
KMS 서버의 인증 토큰( | ||
|
|
OIDC 인증 경로(예: Vault의 경우 | ||
|
| OIDC 인증의 역할입니다. | ||
|
|
KMS 토큰에 대한 Spire 소켓의 URI입니다(예: | ||
|
| SVID를 Spire에서 요청하는 대상입니다. |
1.3. Tekton 체인에서 데이터에 서명하기 위한 보안 링크 복사링크가 클립보드에 복사되었습니다!
클러스터 관리자는 키 쌍을 생성하고 Tekton Chains를 사용하여 Kubernetes 시크릿을 사용하여 아티팩트에 서명할 수 있습니다. Tekton 체인이 작동하려면 암호화된 키의 개인 키와 암호가 openshift-pipelines 네임스페이스에 signing-secrets 시크릿의 일부로 존재해야 합니다.
현재 Tekton 체인은 x509 및 cosign 서명 스키마를 지원합니다.
지원되는 서명 체계 중 하나만 사용하십시오.
Tekton 체인과 x509 서명 스키마를 사용하려면 ed25519 또는 ecdsa 유형의 x509.pem 개인 키를 signing-secrets Kubernetes 시크릿에 저장합니다.
1.3.1. cosign을 사용하여 서명 링크 복사링크가 클립보드에 복사되었습니다!
툴을 사용하여 Tekton 체인에 공동 서명 스키마를 사용할 수 있습니다.
cosign
사전 요구 사항
- cosign 툴을 설치했습니다.
프로세스
다음 명령을 실행하여
cosign.key및cosign.pub키 쌍을 생성합니다.cosign generate-key-pair k8s://openshift-pipelines/signing-secrets
$ cosign generate-key-pair k8s://openshift-pipelines/signing-secretsCopy to Clipboard Copied! Toggle word wrap Toggle overflow cosign은 암호를 입력하라는 메시지를 표시한 다음 Kubernetes 시크릿을 생성합니다.
-
암호화된
cosign.key개인 키와cosign.password암호 해독 암호를signing-secretsKubernetes 시크릿에 저장합니다. 개인 키가ENCRYPTED COSIGN PRIVATE KEY유형의 암호화된 PEM 파일로 저장되었는지 확인합니다.
1.3.2. skopeo를 사용하여 서명 링크 복사링크가 클립보드에 복사되었습니다!
skopeo 툴을 사용하여 키를 생성하고 Tekton 체인과 함께 cosign 서명 스키마에 사용할 수 있습니다.
사전 요구 사항
- skopeo 툴을 설치했습니다.
프로세스
다음 명령을 실행하여 공개/개인 키 쌍을 생성합니다.
skopeo generate-sigstore-key --output-prefix <mykey>
$ skopeo generate-sigstore-key --output-prefix <mykey>1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- &
lt;mykey>를 선택한 키 이름으로 바꿉니다.
Skopeo는 개인 키에 대한 암호를 입력하라는 메시지를 표시한 다음 <mykey>
.private 및 <mykey>.pub 라는 키파일을 만듭니다.다음 명령을 실행하여
base64툴을 사용하여 <mykey>.pub파일을 인코딩합니다.base64 -w 0 <mykey>.pub > b64.pub
$ base64 -w 0 <mykey>.pub > b64.pubCopy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여
base64툴을 사용하여 <mykey>.private파일을 인코딩합니다.base64 -w 0 <mykey>.private > b64.private
$ base64 -w 0 <mykey>.private > b64.privateCopy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여
base64툴을 사용하여 passhprase를 인코딩합니다.echo -n '<passphrase>' | base64 -w 0 > b64.passphrase
$ echo -n '<passphrase>' | base64 -w 0 > b64.passphrase1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- &
lt;passphrase>를 키 쌍에 사용한 암호로 바꿉니다.
다음 명령을 실행하여
openshift-pipelines네임스페이스에signing-secrets시크릿을 생성합니다.oc create secret generic signing-secrets -n openshift-pipelines
$ oc create secret generic signing-secrets -n openshift-pipelinesCopy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여
signing-secrets시크릿을 편집합니다.oc edit secret -n openshift-pipelines signing-secrets
$ oc edit secret -n openshift-pipelines signing-secretsCopy to Clipboard Copied! Toggle word wrap Toggle overflow 다음과 같은 방식으로 시크릿 데이터에 인코딩된 키를 추가합니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
1.3.3. "비밀번호가 이미 있음" 오류 해결 링크 복사링크가 클립보드에 복사되었습니다!
signing-secret 시크릿이 이미 채워진 경우 이 보안을 생성하는 명령에서 다음 오류 메시지를 출력할 수 있습니다.
Error from server (AlreadyExists): secrets "signing-secrets" already exists
Error from server (AlreadyExists): secrets "signing-secrets" already exists
보안을 삭제하여 이 오류를 해결할 수 있습니다.
프로세스
다음 명령을 실행하여
signing-secret시크릿을 삭제합니다.oc delete secret signing-secrets -n openshift-pipelines
$ oc delete secret signing-secrets -n openshift-pipelinesCopy to Clipboard Copied! Toggle word wrap Toggle overflow - 키 쌍을 다시 생성하여 선호하는 서명 스키마를 사용하여 시크릿에 저장합니다.
1.4. OCI 레지스트리에 인증 링크 복사링크가 클립보드에 복사되었습니다!
클러스터 관리자는 OCI 레지스트리로 서명을 푸시하기 전에 레지스트리에 인증하도록 Tekton 체인을 구성해야 합니다. Tekton 체인 컨트롤러는 작업이 실행되는 동일한 서비스 계정을 사용합니다. 서명을 OCI 레지스트리로 내보내는 데 필요한 자격 증명으로 서비스 계정을 설정하려면 다음 단계를 수행합니다.
프로세스
Kubernetes 서비스 계정의 네임스페이스 및 이름을 설정합니다.
export NAMESPACE=<namespace> export SERVICE_ACCOUNT_NAME=<service_account>
$ export NAMESPACE=<namespace>1 $ export SERVICE_ACCOUNT_NAME=<service_account>2 Copy to Clipboard Copied! Toggle word wrap Toggle overflow Kubernetes 시크릿을 생성합니다.
oc create secret registry-credentials \ --from-file=.dockerconfigjson \ --type=kubernetes.io/dockerconfigjson \ -n $NAMESPACE
$ oc create secret registry-credentials \ --from-file=.dockerconfigjson \1 --type=kubernetes.io/dockerconfigjson \ -n $NAMESPACECopy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Docker 구성 파일의 경로로 바꿉니다. 기본 경로는
~/.docker/config.json입니다.
서비스 계정에 시크릿에 대한 액세스 권한을 부여합니다.
oc patch serviceaccount $SERVICE_ACCOUNT_NAME \ -p "{\"imagePullSecrets\": [{\"name\": \"registry-credentials\"}]}" -n $NAMESPACE$ oc patch serviceaccount $SERVICE_ACCOUNT_NAME \ -p "{\"imagePullSecrets\": [{\"name\": \"registry-credentials\"}]}" -n $NAMESPACECopy to Clipboard Copied! Toggle word wrap Toggle overflow Red Hat OpenShift Pipelines가 모든 작업 실행에 할당하는 기본
파이프라인서비스 계정을 패치하면 Red Hat OpenShift Pipelines Operator가 서비스 계정을 재정의합니다. 모범 사례로 다음 단계를 수행할 수 있습니다.사용자의 작업 실행에 할당할 별도의 서비스 계정을 생성합니다.
oc create serviceaccount <service_account_name>
$ oc create serviceaccount <service_account_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 작업 실행 템플릿에서
serviceaccountname필드의 값을 설정하여 서비스 계정을 작업 실행에 연결합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 새로 생성된 서비스 계정의 이름으로 바꿉니다.
1.5. 추가 인증 없이 작업 실행 서명 생성 및 확인 링크 복사링크가 클립보드에 복사되었습니다!
추가 인증과 함께 Tekton Chains를 사용하여 작업 실행 서명을 확인하려면 다음 작업을 수행합니다.
- 암호화된 x509 키 쌍을 생성하여 Kubernetes 시크릿으로 저장합니다.
- Tekton 체인 백엔드 스토리지를 구성합니다.
- 작업 실행을 생성하고 서명하고, 서명 및 페이로드를 작업 실행 자체에 주석으로 저장합니다.
- 서명된 작업 실행에서 서명 및 페이로드를 검색합니다.
- 작업 실행 서명을 확인합니다.
사전 요구 사항
다음 구성 요소가 클러스터에 설치되어 있는지 확인합니다.
- Red Hat OpenShift Pipelines Operator
- Tekton 체인
- cosign
프로세스
- 암호화된 x509 키 쌍을 생성하여 Kubernetes 시크릿으로 저장합니다. 키 쌍을 생성하여 시크릿으로 저장하는 방법에 대한 자세한 내용은 " Tekton 체인에서 시크릿 서명"을 참조하십시오.
Tekton 체인 구성에서 OCI 스토리지를 비활성화하고 작업 실행 스토리지 및 형식을
tekton로 설정합니다.TektonConfig사용자 지정 리소스에서 다음 값을 설정합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow TektonConfig사용자 지정 리소스를 사용하여 Tekton 체인 구성에 대한 자세한 내용은 " Tekton 체인 구성"을 참조하십시오.Tekton 체인 컨트롤러를 다시 시작하여 수정된 구성이 적용되었는지 확인하려면 다음 명령을 입력합니다.
oc delete po -n openshift-pipelines -l app=tekton-chains-controller
$ oc delete po -n openshift-pipelines -l app=tekton-chains-controllerCopy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 입력하여 작업 실행을 생성합니다.
oc create -f https://raw.githubusercontent.com/tektoncd/chains/main/examples/taskruns/task-output-image.yaml
$ oc create -f https://raw.githubusercontent.com/tektoncd/chains/main/examples/taskruns/task-output-image.yaml1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 예제 URI를 작업 실행을 가리키는 URI 또는 파일 경로로 바꿉니다.
출력 예
taskrun.tekton.dev/build-push-run-output-image-qbjvh created
taskrun.tekton.dev/build-push-run-output-image-qbjvh createdCopy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 입력하여 단계의 상태를 확인합니다. 프로세스가 완료될 때까지 기다립니다.
tkn tr describe --last
$ tkn tr describe --lastCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow base64로 인코딩된 주석으로 저장된 오브젝트에서 서명을 검색하려면 다음 명령을 입력합니다.tkn tr describe --last -o jsonpath="{.metadata.annotations.chains\.tekton\.dev/signature-taskrun-$TASKRUN_UID}" | base64 -d > sig$ tkn tr describe --last -o jsonpath="{.metadata.annotations.chains\.tekton\.dev/signature-taskrun-$TASKRUN_UID}" | base64 -d > sigCopy to Clipboard Copied! Toggle word wrap Toggle overflow export TASKRUN_UID=$(tkn tr describe --last -o jsonpath='{.metadata.uid}')$ export TASKRUN_UID=$(tkn tr describe --last -o jsonpath='{.metadata.uid}')Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 생성한 공개 키를 사용하여 서명을 확인하려면 다음 명령을 입력합니다.
cosign verify-blob-attestation --insecure-ignore-tlog --key path/to/cosign.pub --signature sig --type slsaprovenance --check-claims=false /dev/null
$ cosign verify-blob-attestation --insecure-ignore-tlog --key path/to/cosign.pub --signature sig --type slsaprovenance --check-claims=false /dev/null
- 1
path/to/cosign.pub를 공개 키 파일의 경로 이름으로 바꿉니다.출력 예
Verified OK
Verified OKCopy to Clipboard Copied! Toggle word wrap Toggle overflow
1.5.1. 추가 리소스 링크 복사링크가 클립보드에 복사되었습니다!
1.6. Tekton Chain을 사용하여 이미지와 검증에 서명 및 확인 링크 복사링크가 클립보드에 복사되었습니다!
클러스터 관리자는 Tekton Chains를 사용하여 다음 작업을 수행하여 image 및 provenances에 서명하고 확인할 수 있습니다.
- 암호화된 x509 키 쌍을 생성하여 Kubernetes 시크릿으로 저장합니다.
- 이미지, 이미지 서명 및 서명된 이미지 테스트를 저장하기 위해 OCI 레지스트리에 대한 인증을 설정합니다.
- 검증 정보를 생성하고 서명하도록 Tekton 체인을 구성합니다.
- 작업 실행에 Kaniko로 이미지를 생성합니다.
- 서명된 이미지와 서명된 인증서를 확인합니다.
사전 요구 사항
다음 사항이 클러스터에 설치되어 있는지 확인합니다.
프로세스
암호화된 x509 키 쌍을 생성하여 Kubernetes 시크릿으로 저장합니다.
cosign generate-key-pair k8s://openshift-pipelines/signing-secrets
$ cosign generate-key-pair k8s://openshift-pipelines/signing-secretsCopy to Clipboard Copied! Toggle word wrap Toggle overflow 메시지가 표시되면 암호를 입력합니다. cosign은 생성된 개인 키를
openshift-pipelines네임스페이스에signing-secretsKubernetes 시크릿의 일부로 저장하고 공개 키를cosign.pub로컬 파일에 씁니다.이미지 레지스트리에 대한 인증을 구성합니다.
- OCI 레지스트리로 서명을 푸시하도록 Tekton 체인 컨트롤러를 구성하려면 작업 실행의 서비스 계정과 연결된 인증 정보를 사용합니다. 자세한 내용은 " OCI 레지스트리에 인증" 섹션을 참조하십시오.
이미지를 빌드하고 레지스트리로 내보내는 Kaniko 작업에 대한 인증을 구성하려면 필요한 인증 정보가 포함된 docker
config.json파일의 Kubernetes 시크릿을 생성합니다.oc create secret generic <docker_config_secret_name> \ --from-file <path_to_config.json>
$ oc create secret generic <docker_config_secret_name> \1 --from-file <path_to_config.json>2 Copy to Clipboard Copied! Toggle word wrap Toggle overflow
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"}}'$ 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"}}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow Kaniko 작업을 시작합니다.
Kaniko 작업을 클러스터에 적용합니다.
oc apply -f examples/kaniko/kaniko.yaml
$ oc apply -f examples/kaniko/kaniko.yaml1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Kaniko 작업의 URI 또는 파일 경로로 바꿉니다.
적절한 환경 변수를 설정합니다.
export REGISTRY=<url_of_registry> export DOCKERCONFIG_SECRET_NAME=<name_of_the_secret_in_docker_config_json>
$ export REGISTRY=<url_of_registry>1 $ export DOCKERCONFIG_SECRET_NAME=<name_of_the_secret_in_docker_config_json>2 Copy to Clipboard Copied! Toggle word wrap Toggle overflow 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
$ tkn task start --param IMAGE=$REGISTRY/kaniko-chains --use-param-defaults --workspace name=source,emptyDir="" --workspace name=dockerconfig,secret=$DOCKERCONFIG_SECRET_NAME kaniko-chainsCopy to Clipboard Copied! Toggle word wrap Toggle overflow 모든 단계가 완료될 때까지 이 작업의 로그를 관찰합니다. 인증에 성공하면 최종 이미지가
$REGISTRY/kaniko-chains로 푸시됩니다.
Tekton
체인에서 인증 정보를 생성하고 서명할 때까지 1분 정도 기다린 다음 작업 실행 시 chain.tekton.dev/signed=true주석의 가용성을 확인합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 작업 실행 이름으로 대체합니다.
이미지와 인증을 확인합니다.
cosign verify --key cosign.pub $REGISTRY/kaniko-chains cosign verify-attestation --key cosign.pub $REGISTRY/kaniko-chains
$ cosign verify --key cosign.pub $REGISTRY/kaniko-chains $ cosign verify-attestation --key cosign.pub $REGISTRY/kaniko-chainsCopy to Clipboard Copied! Toggle word wrap Toggle overflow Rekor에서 이미지의 출처를 확인합니다.
- $REGISTRY/kaniko-chains 이미지의 다이제스트를 가져옵니다. 작업 실행을 검색하거나 이미지를 가져와 다이제스트를 추출할 수 있습니다.
Rekor를 검색하여 이미지의
sha256다이제스트와 일치하는 모든 항목을 찾습니다.rekor-cli search --sha <image_digest>
$ rekor-cli search --sha <image_digest>1 <uuid_1>2 <uuid_2>3 ...Copy to Clipboard Copied! Toggle word wrap Toggle overflow 검색 결과에는 일치하는 항목의 UUID가 표시됩니다. 해당 UUID 중 하나에 인증 정보가 있습니다.
테스트를 확인하십시오.
rekor-cli get --uuid <uuid> --format json | jq -r .Attestation | base64 --decode | jq
$ rekor-cli get --uuid <uuid> --format json | jq -r .Attestation | base64 --decode | jqCopy to Clipboard Copied! Toggle word wrap Toggle overflow
2장. 권한 있는 보안 컨텍스트에서 Pod 사용 링크 복사링크가 클립보드에 복사되었습니다!
OpenShift Pipelines 1.3.x 이상 버전의 기본 구성에서는 파이프라인 실행 또는 작업 실행으로 인해 pod가 실행된 경우 권한 있는 보안 컨텍스트로 Pod를 실행할 수 없습니다. 이러한 Pod의 경우 기본 서비스 계정은 pipeline 이며 파이프라인 서비스 계정과 연결된 SCC(보안 컨텍스트 제약 조건)는 pipelines-scc 입니다. pipelines-scc SCC는 anyuid SCC와 유사하지만 파이프라인 SCC의 YAML 파일에 정의된 것과 약간의 차이점이 있습니다.
pipelines-scc.yaml 스니펫 예
또한 OpenShift Pipelines의 일부로 제공되는 Buildah 클러스터 작업은 vfs를 기본 스토리지 드라이버로 사용합니다.
2.1. 파이프라인 실행 및 작업 실행 권한이 있는 보안 컨텍스트에서 Pod 실행 링크 복사링크가 클립보드에 복사되었습니다!
프로세스
privileged있는 보안 컨텍스트를 사용하여 Pod(파이프라인 실행 또는 작업 실행)를 실행하려면 다음 수정 작업을 수행합니다.
명시적 SCC를 갖도록 연결된 사용자 계정 또는 서비스 계정을 구성합니다. 다음 방법을 사용하여 구성을 수행할 수 있습니다.
다음 명령을 실행합니다.
oc adm policy add-scc-to-user <scc-name> -z <service-account-name>
$ oc adm policy add-scc-to-user <scc-name> -z <service-account-name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 또는
RoleBinding및Role또는ClusterRole에 대한 YAML 파일을 수정합니다.RoleBinding오브젝트의 예Copy to Clipboard Copied! Toggle word wrap Toggle overflow ClusterRole오브젝트의 예Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 사용하는 역할 바인딩에 따라 적절한 클러스터 역할로 바꿉니다.
참고기본 YAML 파일의 복사본을 만들고 중복 파일을 변경하는 것이 좋습니다.
-
vfs스토리지 드라이버를 사용하지 않는 경우 작업 실행 또는 파이프라인 실행과 연결된 서비스 계정을 구성하여 권한 있는 SCC를 구성하고 보안 컨텍스트를privileged: true로 설정합니다.
2.2. 사용자 정의 SCC 및 사용자 정의 서비스 계정을 사용하여 파이프라인 실행 및 작업 실행 링크 복사링크가 클립보드에 복사되었습니다!
기본 파이프라인 서비스 계정과 연결된 SCC(보안 컨텍스트 제약 조건)를 사용하는 경우 파이프라인 실행 및 작업 실행 Pod가 시간 초과에 직면할 수 있습니다. 이는 기본 pipelines -sccpipelines-scc SCC에서 fsGroup.type 매개변수가 MustRunAs 로 설정되어 있기 때문에 발생합니다.
Pod 시간 초과에 대한 자세한 내용은 BZ#1995779 를 참조하십시오.
Pod 시간 초과를 방지하려면 fsGroup.type 매개변수를 RunAsAny 로 설정하여 사용자 지정 SCC를 생성하고 사용자 지정 서비스 계정과 연결할 수 있습니다.
가장 좋은 방법은 파이프라인 실행 및 작업 실행을 위해 사용자 정의 SCC 및 사용자 정의 서비스 계정을 사용합니다. 이 접근 방식을 사용하면 유연성이 향상되고 업그레이드 중에 기본값이 수정될 때 실행이 중단되지 않습니다.
프로세스
fsGroup.type매개변수를RunAsAny로 설정하여 사용자 지정 SCC를 정의합니다.예: 사용자 정의 SCC
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 사용자 지정 SCC를 생성합니다.
예:
my-sccSCC 생성oc create -f my-scc.yaml
$ oc create -f my-scc.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 사용자 정의 서비스 계정을 생성합니다.
예:
fsgroup-runasany서비스 계정 생성oc create serviceaccount fsgroup-runasany
$ oc create serviceaccount fsgroup-runasanyCopy to Clipboard Copied! Toggle word wrap Toggle overflow 사용자 지정 SCC를 사용자 지정 서비스 계정과 연결합니다.
예:
my-sccSCC를fsgroup-runasany서비스 계정과 연결oc adm policy add-scc-to-user my-scc -z fsgroup-runasany
$ oc adm policy add-scc-to-user my-scc -z fsgroup-runasanyCopy to Clipboard Copied! Toggle word wrap Toggle overflow 권한 있는 작업에 사용자 정의 서비스 계정을 사용하려면 다음 명령을 실행하여
권한 있는SCC를 사용자 정의 서비스 계정과 연결할 수 있습니다.예:
권한 있는SCC를fsgroup-runasany서비스 계정에 연결oc adm policy add-scc-to-user privileged -z fsgroup-runasany
$ oc adm policy add-scc-to-user privileged -z fsgroup-runasanyCopy to Clipboard Copied! Toggle word wrap Toggle overflow 파이프라인 실행 및 작업 실행에서 사용자 정의 서비스 계정을 사용합니다.
예: 파이프라인은
fsgroup-runasany사용자 지정 서비스 계정으로 YAML을 실행합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 예: 작업에서는
fsgroup-runasany사용자 지정 서비스 계정으로 YAML을 실행합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow
3장. 이벤트 리스너로 Webhook 보안 링크 복사링크가 클립보드에 복사되었습니다!
관리자는 이벤트 리스너를 사용하여 Webhook를 보호할 수 있습니다. 네임스페이스를 생성한 후 네임스페이스에 operator.tekton.dev/enable-annotation=enabled 레이블을 추가하여 Eventlistener 리소스의 HTTPS를 활성화합니다. 그런 다음 재암호화 TLS 종료를 사용하여 Trigger 리소스 및 보안 경로를 생성합니다.
Red Hat OpenShift Pipelines에서 트리거는 Eventlistener 리소스에 대한 비보안 HTTP 및 보안 HTTPS 연결을 모두 지원합니다. HTTPS는 클러스터 내부 및 외부의 연결을 보호합니다.
Red Hat OpenShift Pipelines는 네임스페이스의 레이블을 감시하는 tekton-operator-proxy-webhook Pod를 실행합니다. 네임스페이스에 라벨을 추가하면 Webhook에서 EventListener 오브젝트에 service.beta.openshift.io/serving-cert-secret-name=<secret_name> 주석을 설정합니다. 이를 통해 시크릿과 필수 인증서를 생성합니다.
service.beta.openshift.io/serving-cert-secret-name=<secret_name>
service.beta.openshift.io/serving-cert-secret-name=<secret_name>
또한 생성된 시크릿을 Eventlistener pod 마운트하여 요청을 보호할 수 있습니다.
3.1. OpenShift 경로와의 보안 연결 제공 링크 복사링크가 클립보드에 복사되었습니다!
재암호화 TLS 종료로 경로를 생성합니다.
oc create route reencrypt --service=<svc-name> --cert=tls.crt --key=tls.key --ca-cert=ca.crt --hostname=<hostname>
$ oc create route reencrypt --service=<svc-name> --cert=tls.crt --key=tls.key --ca-cert=ca.crt --hostname=<hostname>
또는 재암호화된 TLS 종료 YAML 파일을 만들어 보안 경로를 만들 수도 있습니다.
보안 경로를 생성하기 위해 TLS 종료 YAML을 재암호화하는 예
oc create route reencrypt --help 명령을 실행하여 더 많은 옵션을 표시할 수 있습니다.
3.2. 보안 HTTPS 연결을 사용하여 샘플 EventListener 리소스 생성 링크 복사링크가 클립보드에 복사되었습니다!
이 섹션에서는 pipelines-tutorial 예제를 사용하여 보안 HTTPS 연결을 사용하여 샘플 EventListener 리소스 생성을 만드는 방법을 보여줍니다.
프로세스
pipelines-tutorial 리포지토리에서 사용 가능한 YAML 파일에서
TriggerBinding리소스를 생성합니다.oc create -f https://raw.githubusercontent.com/openshift/pipelines-tutorial/master/03_triggers/01_binding.yaml
$ oc create -f https://raw.githubusercontent.com/openshift/pipelines-tutorial/master/03_triggers/01_binding.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow pipelines-tutorial 리포지토리에서 직접
TriggerTemplate리소스를 생성합니다.oc create -f https://raw.githubusercontent.com/openshift/pipelines-tutorial/master/03_triggers/02_template.yaml
$ oc create -f https://raw.githubusercontent.com/openshift/pipelines-tutorial/master/03_triggers/02_template.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow pipelines-tutorial 리포지토리에서 직접
Trigger리소스를 생성합니다.oc create -f https://raw.githubusercontent.com/openshift/pipelines-tutorial/master/03_triggers/03_trigger.yaml
$ oc create -f https://raw.githubusercontent.com/openshift/pipelines-tutorial/master/03_triggers/03_trigger.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 보안 HTTPS 연결을 사용하여
EventListener리소스를 생성합니다.Eventlistener리소스에 대한 보안 HTTPS 연결을 활성화하려면 레이블을 추가합니다.oc label namespace <ns-name> operator.tekton.dev/enable-annotation=enabled
$ oc label namespace <ns-name> operator.tekton.dev/enable-annotation=enabledCopy to Clipboard Copied! Toggle word wrap Toggle overflow pipelines-tutorial 리포지토리에서 사용 가능한 YAML 파일에서
EventListener리소스를 생성합니다.oc create -f https://raw.githubusercontent.com/openshift/pipelines-tutorial/master/03_triggers/04_event_listener.yaml
$ oc create -f https://raw.githubusercontent.com/openshift/pipelines-tutorial/master/03_triggers/04_event_listener.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 재암호화 TLS 종료로 경로를 생성합니다.
oc create route reencrypt --service=<svc-name> --cert=tls.crt --key=tls.key --ca-cert=ca.crt --hostname=<hostname>
$ oc create route reencrypt --service=<svc-name> --cert=tls.crt --key=tls.key --ca-cert=ca.crt --hostname=<hostname>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
4장. 보안을 사용하여 리포지터리로 파이프라인 인증 링크 복사링크가 클립보드에 복사되었습니다!
파이프라인 및 작업에는 Git 리포지토리 및 컨테이너 리포지토리로 인증하기 위해 인증 정보가 필요할 수 있습니다. Red Hat OpenShift Pipelines에서는 시크릿을 사용하여 실행 중에 Git 리포지토리 또는 컨테이너 리포지토리와 상호 작용하는 파이프라인 실행 및 작업 실행을 인증할 수 있습니다.
Git 리포지토리를 사용한 인증에 대한 시크릿을 Git 시크릿 이라고 합니다.
파이프라인 실행 또는 작업 실행에서는 연결된 서비스 계정을 통해 시크릿에 대한 액세스 권한을 얻습니다. 또는 파이프라인 또는 작업에서 작업 공간을 정의하고 해당 시크릿을 작업 공간에 바인딩할 수 있습니다.
4.1. 사전 요구 사항 링크 복사링크가 클립보드에 복사되었습니다!
-
ocOpenShift 명령줄 유틸리티를 설치했습니다.
4.2. 서비스 계정을 사용하여 보안 제공 링크 복사링크가 클립보드에 복사되었습니다!
서비스 계정을 사용하여 Git 리포지토리 및 컨테이너 리포지토리를 통한 인증에 대한 시크릿을 제공할 수 있습니다.
시크릿을 서비스 계정과 연결할 수 있습니다. 시크릿의 정보는 이 서비스 계정에서 실행되는 작업에 사용할 수 있습니다.
4.2.1. 서비스 계정의 보안 유형 및 주석 링크 복사링크가 클립보드에 복사되었습니다!
서비스 계정을 사용하여 인증 보안을 제공하는 경우 OpenShift Pipelines는 여러 가지 보안 유형을 지원합니다. 이러한 보안 유형의 대부분은 인증 보안이 유효한 리포지토리를 정의하는 주석을 제공해야 합니다.
4.2.1.1. Git 인증 보안 링크 복사링크가 클립보드에 복사되었습니다!
서비스 계정을 사용하여 인증 보안을 제공하는 경우 OpenShift Pipelines는 Git 인증에 대해 다음 유형의 보안을 지원합니다.
-
kubernetes.io/basic-auth: 기본 인증을 위한 사용자 이름과 암호 -
kubernetes.io/ssh-auth: SSH 기반 인증을 위한 키
서비스 계정을 사용하여 인증 보안을 제공하는 경우 Git 시크릿에 하나 이상의 주석 키가 있어야 합니다. 각 키의 이름은 tekton.dev/git- 로 시작해야 하며 값은 OpenShift Pipelines에서 시크릿의 인증 정보를 사용해야 하는 호스트의 URL입니다.
다음 예에서 OpenShift Pipelines는 basic-auth 시크릿을 사용하여 github.com 및 gitlab.com 의 리포지토리에 액세스합니다.
예: 여러 Git 리포지토리를 사용한 기본 인증을 위한 인증 정보
다음 예와 같이 ssh-auth 시크릿을 사용하여 Git 리포지토리에 액세스하기 위한 개인 키를 제공할 수도 있습니다.
예: SSH 기반 인증을 위한 개인 키
- 1
- SSH 개인 키 파일의 내용입니다.
4.2.1.2. 컨테이너 레지스트리 인증 보안 링크 복사링크가 클립보드에 복사되었습니다!
서비스 계정을 사용하여 인증 보안을 제공하는 경우 OpenShift Pipelines는 컨테이너(Docker) 레지스트리 인증에 대해 다음 유형의 보안을 지원합니다.
-
kubernetes.io/basic-auth: 기본 인증을 위한 사용자 이름과 암호 -
kubernetes.io/dockercfg: 직렬화된~/.dockercfg파일 -
kubernetes.io/dockerconfigjson: 직렬화된~/.docker/config.json파일
서비스 계정을 사용하여 인증 보안을 제공하는 경우 kubernetes.io/basic-auth 유형의 컨테이너 레지스트리 시크릿에 하나 이상의 주석 키가 있어야 합니다. 각 키의 이름은 tekton.dev/docker- 로 시작해야 하며 값은 OpenShift Pipelines에서 시크릿의 인증 정보를 사용해야 하는 호스트의 URL입니다. 이 주석은 다른 유형의 컨테이너 레지스트리 시크릿에는 필요하지 않습니다.
다음 예에서 OpenShift Pipelines는 사용자 이름과 암호를 사용하는 basic-auth 시크릿을 사용하여 quay.io 및 my-registry.example.com 에서 컨테이너 레지스트리에 액세스합니다.
예: 여러 컨테이너 리포지토리를 사용한 기본 인증을 위한 인증 정보
다음 예와 같이 기존 구성 파일에서 kubernetes.io/dockercfg 및 kubernetes.io/dockerconfigjson 시크릿을 생성할 수 있습니다.
예: 기존 구성 파일에서 컨테이너 리포지토리에 인증하기 위한 시크릿을 생성하는 명령
oc create secret generic docker-secret-config \
--from-file=config.json=/home/user/.docker/config.json \
--type=kubernetes.io/dockerconfigjson
$ oc create secret generic docker-secret-config \
--from-file=config.json=/home/user/.docker/config.json \
--type=kubernetes.io/dockerconfigjson
다음 예제와 같이 oc 명령줄 유틸리티를 사용하여 인증 정보에서 kubernetes.io/dockerconfigjson 시크릿을 생성할 수도 있습니다.
예: 인증 정보에서 컨테이너 리포지토리에 인증하기 위한 시크릿을 생성하는 명령
oc create secret docker-registry docker-secret-config \ --docker-email=<email> \ --docker-username=<username> \ --docker-password=<password> \ --docker-server=my-registry.example.com:5000
$ oc create secret docker-registry docker-secret-config \
--docker-email=<email> \
--docker-username=<username> \
--docker-password=<password> \
--docker-server=my-registry.example.com:5000
4.2.2. 서비스 계정을 사용하여 Git에 대한 기본 인증 구성 링크 복사링크가 클립보드에 복사되었습니다!
암호 보호 리포지토리에서 리소스를 검색하는 파이프라인의 경우 해당 파이프라인에 대한 기본 인증을 구성할 수 있습니다.
기본 인증이 아닌 SSH 기반 인증을 사용하는 것이 좋습니다.
파이프라인에 대한 기본 인증을 구성하려면 기본 인증 보안을 생성하고 이 보안을 서비스 계정과 연결한 다음, 이 서비스 계정을 TaskRun 또는 PipelineRun 리소스와 연결합니다.
GitHub의 경우 일반 암호를 사용한 인증은 더 이상 사용되지 않습니다. 대신 개인 액세스 토큰 을 사용합니다.
프로세스
secret.yaml파일에서 시크릿의 YAML 매니페스트를 생성합니다. 이 매니페스트에서 사용자 이름과 암호 또는 GitHub 개인 액세스 토큰 을 지정하여 대상 Git 리포지토리에 액세스합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow serviceaccount.yaml파일에서 서비스 계정에 대한 YAML 매니페스트를 생성합니다. 이 매니페스트에서 보안을 서비스 계정과 연결합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow run.yaml파일에서 작업 실행 또는 파이프라인 실행에 대한 YAML 매니페스트를 생성하고 서비스 계정을 작업 실행 또는 파이프라인 실행과 연결합니다. 다음 예제 중 하나를 사용합니다.서비스 계정을
TaskRun리소스와 연결합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 서비스 계정을
PipelineRun리소스와 연결합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow
다음 명령을 입력하여 생성한 YAML 매니페스트를 적용합니다.
oc apply --filename secret.yaml,serviceaccount.yaml,run.yaml
$ oc apply --filename secret.yaml,serviceaccount.yaml,run.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
4.2.3. 서비스 계정을 사용하여 Git에 대한 SSH 인증 구성 링크 복사링크가 클립보드에 복사되었습니다!
SSH 키를 사용하여 구성된 리포지토리에서 리소스를 검색하려면 파이프라인에 대한 SSH 기반 인증을 구성해야 합니다.
파이프라인에 대한 SSH 기반 인증을 구성하려면 SSH 개인 키를 사용하여 인증 시크릿을 생성하고 이 보안을 서비스 계정과 연결한 다음, 이 서비스 계정을 TaskRun 또는 PipelineRun 리소스와 연결합니다.
프로세스
-
SSH 개인 키를 생성하거나 일반적으로
~/.ssh/id_rsa파일에서 사용할 수 있는 기존 개인 키를 복사합니다. secret.yaml파일에서 시크릿의 YAML 매니페스트를 생성합니다. 이 매니페스트에서ssh-privatekey의 값을 SSH 개인 키 파일의 콘텐츠로 설정하고known_hosts값을 알려진 호스트 파일의 콘텐츠로 설정합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 중요알려진 호스트 파일을 생략하면 OpenShift Pipelines에서 서버의 공개 키를 수락합니다.
-
선택 사항: 주석 값 끝에
:<port_number>를 추가하여 사용자 정의 SSH 포트를 지정합니다. 예:tekton.dev/git-0: github.com:2222. serviceaccount.yaml파일에서 서비스 계정에 대한 YAML 매니페스트를 생성합니다. 이 매니페스트에서 보안을 서비스 계정과 연결합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow run.yaml파일에서 서비스 계정을 작업 실행 또는 파이프라인 실행과 연결합니다. 다음 예제 중 하나를 사용합니다.서비스 계정을 작업과 연결하려면 다음을 실행합니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 서비스 계정을 파이프라인과 연결하려면 다음을 실행합니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
변경 사항을 적용합니다.
oc apply --filename secret.yaml,serviceaccount.yaml,run.yaml
$ oc apply --filename secret.yaml,serviceaccount.yaml,run.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
4.2.4. 서비스 계정을 사용하여 컨테이너 레지스트리 인증 구성 링크 복사링크가 클립보드에 복사되었습니다!
레지스트리에서 컨테이너 이미지를 검색하거나 컨테이너 이미지를 레지스트리로 푸시하려면 파이프라인의 경우 해당 레지스트리에 대한 인증을 구성해야 합니다.
파이프라인에 대한 레지스트리 인증을 구성하려면 Docker 구성 파일을 사용하여 인증 보안을 생성하고 이 보안을 서비스 계정과 연결한 다음, 이 서비스 계정을 TaskRun 또는 PipelineRun 리소스와 연결합니다.
프로세스
다음 명령을 입력하여 인증 정보가 포함된 기존
config.json파일에서 컨테이너 레지스트리 인증 보안을 생성합니다.oc create secret generic my-registry-credentials \ --from-file=config.json=/home/user/credentials/config.json
$ oc create secret generic my-registry-credentials \1 --from-file=config.json=/home/user/credentials/config.json2 Copy to Clipboard Copied! Toggle word wrap Toggle overflow serviceaccount.yaml파일에서 서비스 계정에 대한 YAML 매니페스트를 생성합니다. 이 매니페스트에서 보안을 서비스 계정과 연결합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 작업 실행 또는 파이프라인 실행에 대한 YAML 매니페스트를
run.yaml파일로 생성합니다. 이 파일에서 서비스 계정을 작업 실행 또는 파이프라인 실행과 연결합니다. 다음 예제 중 하나를 사용합니다.서비스 계정을 작업과 연결하려면 다음을 실행합니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 서비스 계정을 파이프라인과 연결하려면 다음을 실행합니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
다음 명령을 입력하여 변경 사항을 적용합니다.
oc apply --filename serviceaccount.yaml,run.yaml
$ oc apply --filename serviceaccount.yaml,run.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
4.2.5. 서비스 계정을 사용한 인증에 대한 추가 고려 사항 링크 복사링크가 클립보드에 복사되었습니다!
경우에 따라 서비스 계정을 사용하여 제공하는 인증 보안을 사용하려면 추가 단계를 완료해야 합니다.
4.2.5.1. 작업의 SSH Git 인증 링크 복사링크가 클립보드에 복사되었습니다!
작업 단계에서 Git 명령을 직접 호출하고 SSH 인증을 사용할 수 있지만 추가 단계를 완료해야 합니다.
OpenShift Pipelines는 /tekton/home/.ssh 디렉터리에 SSH 파일을 제공하고 $HOME 변수를 /tekton/home 으로 설정합니다. 그러나 Git SSH 인증은 $HOME 변수를 무시하고 사용자의 /etc/passwd 파일에 지정된 홈 디렉터리를 사용합니다. 따라서 Git 명령을 사용하는 단계에서는 /tekton/home/.ssh 디렉터리를 연결된 사용자의 홈 디렉터리에 심볼릭 링크해야 합니다.
예를 들어 작업이 root 사용자로 실행되는 경우 Git 명령 앞에 다음 명령을 포함해야 합니다.
그러나 git 유형 또는 Tekton 카탈로그에서 사용할 수 있는 git-clone 작업의 파이프라인 리소스를 사용할 때는 명시적 심볼릭 링크가 필요하지 않습니다.
git 유형 작업에서 SSH 인증을 사용하는 예로, authenticating-git-commands.yaml 을 참조하십시오.
4.2.5.2. 루트가 아닌 사용자로 시크릿 사용 링크 복사링크가 클립보드에 복사되었습니다!
다음과 같은 특정 시나리오에서 루트가 아닌 사용자로 시크릿을 사용해야 할 수 있습니다.
- 컨테이너가 실행을 실행하는 데 사용하는 사용자 및 그룹은 플랫폼에 의해 무작위화됩니다.
- 작업의 단계에서는 루트가 아닌 보안 컨텍스트를 정의합니다.
- 작업은 작업의 모든 단계에 적용되는 글로벌 루트가 아닌 보안 컨텍스트를 지정합니다.
이러한 시나리오에서는 작업 실행 및 파이프라인 실행을 루트가 아닌 사용자로 실행할 때 다음 측면을 고려하십시오.
-
Git에 대한 SSH 인증을 사용하려면 사용자에게
/etc/passwd디렉터리에 유효한 홈 디렉터리가 구성되어 있어야 합니다. 유효한 홈 디렉터리가 없는 UID를 지정하면 인증에 실패합니다. -
SSH 인증은
$HOME환경 변수를 무시합니다. 따라서 OpenShift Pipelines(/tekton/home)에서 루트가 아닌 사용자의 유효한 홈 디렉터리에 정의된$HOME디렉터리의 적절한 시크릿 파일을 심볼릭해야 합니다.
또한 루트가 아닌 보안 컨텍스트에서 SSH 인증을 구성하려면 예제의 git-clone-and-check 단계를 참조하십시오.
4.3. 작업 영역을 사용하여 보안 제공 링크 복사링크가 클립보드에 복사되었습니다!
작업 공간을 사용하여 Git 리포지토리 및 컨테이너 리포지토리에 대한 인증을 위한 시크릿을 제공할 수 있습니다.
작업에서 이름이 지정된 작업 영역을 구성하여 작업 영역을 마운트된 경로를 지정할 수 있습니다. 작업을 실행할 때 이 이름이 있는 작업 공간으로 시크릿을 제공합니다. OpenShift Pipelines가 작업을 실행하면 시크릿의 정보를 작업에 사용할 수 있습니다.
작업 영역을 사용하여 인증 보안을 제공하는 경우 시크릿에 대한 주석이 필요하지 않습니다.
4.3.1. 작업 영역을 사용하여 Git에 대한 SSH 인증 구성 링크 복사링크가 클립보드에 복사되었습니다!
SSH 키를 사용하여 구성된 리포지토리에서 리소스를 검색하려면 파이프라인에 대한 SSH 기반 인증을 구성해야 합니다.
파이프라인에 대한 SSH 기반 인증을 구성하려면 SSH 개인 키를 사용하여 인증 시크릿을 생성하고, 이 시크릿에 대해 이름이 지정된 작업 영역을 구성하고, 작업을 실행할 때 시크릿을 지정합니다.
프로세스
다음 명령을 입력하여 기존
.ssh디렉터리의 파일에서 Git SSH 인증 보안을 생성합니다.oc create secret generic my-github-ssh-credentials \ --from-file=id_ed25519=/home/user/.ssh/id_ed25519 \ --from-file=known_hosts=/home/user/.ssh/known_hosts
$ oc create secret generic my-github-ssh-credentials \1 --from-file=id_ed25519=/home/user/.ssh/id_ed25519 \2 --from-file=known_hosts=/home/user/.ssh/known_hosts3 Copy to Clipboard Copied! Toggle word wrap Toggle overflow 작업 정의에서 Git 인증을 위해 이름이 지정된 작업 공간을 구성합니다(예:
ssh-directory):작업 공간 정의 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
작업 단계에서
$(workspaces.<workspace_name>.path)환경 변수의 경로를 사용하여 디렉터리에 액세스합니다(예:$(workspaces.ssh-directory.path)). 작업을 실행할 때
tkn task start명령에--workspace인수를 포함하여 이름이 지정된 작업 공간에 대한 보안을 지정합니다.tkn task start <task_name>
$ tkn task start <task_name> --workspace name=<workspace_name>,secret=<secret_name>1 # ...Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- &
lt;workspace_name>을 구성한 작업 공간 이름으로 바꾸고 <secret_name>을 생성한 시크릿 이름으로 바꿉니다.
인증에 SSH 키를 사용하여 Git 리포지토리 복제 작업 예
- 1
- 이 스크립트는 ssh가 자격 증명을 검색하는 표준 폴더인
${HOME}/.에 시크릿 콘텐츠를 복사합니다.ssh
작업 실행을 위한 명령 예
tkn task start git-clone
$ tkn task start git-clone
--param url=git@github.com:example-github-user/buildkit-tekton
--workspace name=output,emptyDir=""
--workspace name=ssh-directory,secret=my-github-ssh-credentials
--use-param-defaults --showlog
4.3.2. 작업 영역을 사용하여 컨테이너 레지스트리 인증 구성 링크 복사링크가 클립보드에 복사되었습니다!
레지스트리에서 컨테이너 이미지를 검색하려면 파이프라인의 경우 해당 레지스트리에 대한 인증을 구성해야 합니다.
컨테이너 레지스트리에 대한 인증을 구성하려면 Docker 구성 파일을 사용하여 인증 보안을 생성하고, 작업에서 이 시크릿에 대해 이름이 지정된 작업 영역을 구성하고, 작업을 실행할 때 시크릿을 지정합니다.
프로세스
다음 명령을 입력하여 인증 정보가 포함된 기존
config.json파일에서 컨테이너 레지스트리 인증 보안을 생성합니다.oc create secret generic my-registry-credentials \ --from-file=config.json=/home/user/credentials/config.json
$ oc create secret generic my-registry-credentials \1 --from-file=config.json=/home/user/credentials/config.json2 Copy to Clipboard Copied! Toggle word wrap Toggle overflow 작업 정의에서 Git 인증을 위해 이름이 지정된 작업 공간을 구성합니다(예:
ssh-directory):작업 공간 정의 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
작업 단계에서
$(workspaces.<workspace_name>.path)환경 변수의 경로를 사용하여 디렉터리에 액세스합니다(예:$(workspaces.dockerconfig.path). 작업을 실행하려면
tkn task start명령에--workspace인수를 포함하여 이름이 지정된 작업 공간에 대한 보안을 지정합니다.tkn task start <task_name>
$ tkn task start <task_name> --workspace name=<workspace_name>,secret=<secret_name>1 # ...Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- &
lt;workspace_name>을 구성한 작업 공간 이름으로 바꾸고 <secret_name>을 생성한 시크릿 이름으로 바꿉니다.
Skopeo를 사용하여 컨테이너 리포지토리에서 이미지를 복사하는 작업의 예
작업 실행을 위한 명령 예
tkn task start skopeo-copy
$ tkn task start skopeo-copy
--workspace name=dockerconfig,secret=my-registry-credentials
--use-param-defaults --showlog
4.3.3. 작업 영역을 사용하여 특정 단계로 시크릿 제한 링크 복사링크가 클립보드에 복사되었습니다!
작업 영역을 사용하여 인증 보안을 제공하고 작업에서 작업 영역을 정의하는 경우 기본적으로 작업의 모든 단계에서 작업 영역을 사용할 수 있습니다.
보안을 특정 단계로 제한하려면 작업 사양과 단계 사양 모두에서 작업 공간을 정의합니다.
프로세스
다음 예제와 같이 작업 사양 및 단계 사양 모두에서
workspaces:정의를 추가합니다.하나의 단계만 인증 정보 작업 공간에 액세스할 수 있는 작업 정의의 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
5장. Buildah를 루트가 아닌 사용자로 사용하여 컨테이너 이미지 빌드 링크 복사링크가 클립보드에 복사되었습니다!
컨테이너에서 root 사용자로 OpenShift Pipelines를 실행하면 컨테이너 프로세스 및 호스트를 다른 잠재적으로 악의적인 리소스에 노출할 수 있습니다. 컨테이너에서 루트가 아닌 특정 사용자로 워크로드를 실행하여 이러한 유형의 노출을 줄일 수 있습니다. Buildah를 루트가 아닌 사용자로 사용하여 컨테이너 이미지의 빌드를 실행하려면 다음 단계를 수행할 수 있습니다.
- 사용자 정의 서비스 계정(SA) 및 SCC(보안 컨텍스트 제약 조건)를 정의합니다.
-
ID
1000과 함께build사용자를 사용하도록 Buildah를 구성합니다. - 사용자 정의 구성 맵으로 작업 실행을 시작하거나 파이프라인 실행과 통합합니다.
5.1. 사용자 정의 서비스 계정 및 보안 컨텍스트 제약 조건 구성 링크 복사링크가 클립보드에 복사되었습니다!
기본 파이프라인 SA에서는 네임스페이스 범위 외부의 사용자 ID를 사용할 수 있습니다. 기본 SA에 대한 종속성을 줄이기 위해 사용자 ID 1000 을 사용하여 빌드 사용자에 필요한 클러스터 역할 및 역할 바인딩을 사용하여 사용자 지정 SA 및 SCC를 정의할 수 있습니다.
현재 컨테이너에서 Buildah를 성공적으로 실행하려면 allowPrivilegeEscalation 설정을 활성화해야 합니다. 이 설정을 통해 Buildah는 루트가 아닌 사용자로 실행할 때 SETUID 및 SETGID 기능을 활용할 수 있습니다.
프로세스
필요한 클러스터 역할 및 역할 바인딩을 사용하여 사용자 지정 SA 및 SCC를 만듭니다.
예: 사용된 ID
1000의 사용자 정의 SA 및 SCCCopy to Clipboard Copied! Toggle word wrap Toggle overflow
- 1
- 사용자 지정 SA를 정의합니다.
- 2
- 수정된
runAsUser필드를 사용하여 제한된 권한을 기반으로 생성된 사용자 정의 SCC를 정의합니다. - 3
- 현재 컨테이너에서 Buildah를 성공적으로 실행하려면
allowPrivilegeEscalation설정을 활성화해야 합니다. 이 설정을 통해 Buildah는 루트가 아닌 사용자로 실행할 때SETUID및SETGID기능을 활용할 수 있습니다. - 4
- 사용자 ID
1000으로 실행되도록 사용자 지정 SCC와 함께 연결된 모든 Pod를 제한합니다. - 5
- 사용자 지정 SCC를 사용하는 클러스터 역할을 정의합니다.
- 6
- 사용자 지정 SCC를 사용하는 클러스터 역할을 사용자 지정 SA에 바인딩합니다.
5.2. 빌드 사용자를 사용하도록 Buildah 구성 링크 복사링크가 클립보드에 복사되었습니다!
Buildah 작업을 정의하여 사용자 ID 1000 과 함께 빌드 사용자를 사용할 수 있습니다.
프로세스
buildah클러스터 작업의 사본을 일반 작업으로 생성합니다.oc get clustertask buildah -o yaml | yq '. |= (del .metadata |= with_entries(select(.key == "name" )))' | yq '.kind="Task"' | yq '.metadata.name="buildah-as-user"' | oc create -f -
$ oc get clustertask buildah -o yaml | yq '. |= (del .metadata |= with_entries(select(.key == "name" )))' | yq '.kind="Task"' | yq '.metadata.name="buildah-as-user"' | oc create -f -Copy to Clipboard Copied! Toggle word wrap Toggle overflow 복사한
buildah작업을 편집합니다.oc edit task buildah-as-user
$ oc edit task buildah-as-userCopy to Clipboard Copied! Toggle word wrap Toggle overflow 예:
build사용자를 사용하여 Buildah 작업Copy to Clipboard Copied! Toggle word wrap Toggle overflow
5.3. 사용자 정의 구성 맵 또는 파이프라인 실행을 사용하여 작업 실행 시작 링크 복사링크가 클립보드에 복사되었습니다!
사용자 정의 Buildah 클러스터 작업을 정의한 후 사용자 ID 1000 을 사용하여 이미지를 빌드 사용자로 빌드 하는 TaskRun 오브젝트를 생성할 수 있습니다. 또한 PipelineRun 오브젝트의 일부로 TaskRun 오브젝트를 통합할 수 있습니다.
프로세스
사용자 정의
ConfigMap및Dockerfile오브젝트를 사용하여TaskRun오브젝트를 생성합니다.예: Buildah를 사용자 ID
1000으로 실행하는 작업 실행Copy to Clipboard Copied! Toggle word wrap Toggle overflow (선택 사항) 파이프라인 및 해당 파이프라인 실행을 생성합니다.
예: 파이프라인 및 해당 파이프라인 실행
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 작업 실행 또는 파이프라인 실행을 시작합니다.
5.4. 권한이 없는 빌드의 제한 링크 복사링크가 클립보드에 복사되었습니다!
권한이 없는 빌드의 프로세스는 대부분의 Dockerfile 오브젝트에서 작동합니다. 그러나 몇 가지 알려진 제한 사항으로 인해 빌드가 실패할 수 있습니다.
-
필요한 권한 문제 부족으로 인해
--mount=type=cache옵션을 사용하면 실패할 수 있습니다. 자세한 내용은 이 문서를 참조하십시오. -
마운트 리소스에 사용자 정의 SCC에서 제공하지 않는 추가 기능이 필요하므로
--mount=type=secret옵션을 사용하면 실패합니다.
추가 리소스