5.9. Trustee 값, 정책 및 시크릿 구성
Trustee에 대해 다음 값, 정책 및 시크릿을 구성할 수 있습니다.
- 선택 사항: 참조 값 공급자 서비스에 대한 참조 값입니다.
- 선택사항: 인증 정책입니다.
- Intel Trust Domain Extensions(TDX)용 인증서 캐싱 서비스 프로비저닝.
- 선택 사항: Trustee 클라이언트의 사용자 정의 키의 시크릿입니다.
- 선택사항: 컨테이너 이미지 서명 확인을 위한 시크릿입니다.
- 컨테이너 이미지 서명 확인 정책. 이 정책은 필수입니다. 컨테이너 이미지 서명 확인을 사용하지 않는 경우 서명을 확인하지 않는 정책을 생성해야 합니다.
- 리소스 액세스 정책.
5.9.1. 참조 값 구성
하드웨어 플랫폼의 신뢰할 수 있는 다이제스트를 지정하여 RVPS(Reference Value Provider Service)에 대한 참조 값을 구성할 수 있습니다.
클라이언트는 실행 중인 소프트웨어, TEE(신뢰할 수 있는 실행 환경) 하드웨어 및 펌웨어에서 측정을 수집하고 클레임과 함께 Attestation Server에 견적을 제출합니다. 이러한 측정은 Trustee에 등록된 신뢰할 수 있는 다이제스트와 일치해야 합니다. 이 프로세스에서는 기밀 VM(CVM)이 예상 소프트웨어 스택을 실행 중이고 변조되지 않도록 합니다.
프로세스
rvps-configmap.yaml
매니페스트 파일을 생성합니다.apiVersion: v1 kind: ConfigMap metadata: name: rvps-reference-values namespace: trustee-operator-system data: reference-values.json: | [ 1 ]
- 1
- 필요한 경우 하드웨어 플랫폼에 대해 신뢰할 수 있는 다이제스트를 지정합니다. 그렇지 않으면 비워 둡니다.
다음 명령을 실행하여 RVPS 구성 맵을 생성합니다.
$ oc apply -f rvps-configmap.yaml
5.9.2. 인증 정책 생성
기본 테스트 정책을 재정의하는 인증 정책을 생성할 수 있습니다.
프로세스
다음 예에 따라
attestation-policy.yaml
매니페스트 파일을 생성합니다.apiVersion: v1 kind: ConfigMap metadata: name: attestation-policy namespace: trustee-operator-system data: default.rego: | package policy 1 import future.keywords.every default allow = false allow { every k, v in input { judge_field(k, v) } } judge_field(input_key, input_value) { has_key(data.reference, input_key) reference_value := data.reference[input_key] match_value(reference_value, input_value) } judge_field(input_key, input_value) { not has_key(data.reference, input_key) } match_value(reference_value, input_value) { not is_array(reference_value) input_value == reference_value } match_value(reference_value, input_value) { is_array(reference_value) array_include(reference_value, input_value) } array_include(reference_value_array, input_value) { reference_value_array == [] } array_include(reference_value_array, input_value) { reference_value_array != [] some i reference_value_array[i] == input_value } has_key(m, k) { _ = m[k] }
- 1
- 인증 정책은 Open Policy Agent 사양을 따릅니다. 이 예에서 attestation 정책은 테스트 보고서에 제공된 클레임을 RVPS 데이터베이스에 등록된 참조 값과 비교합니다. 인증 프로세스는 모든 값이 일치하는 경우에만 성공합니다.
다음 명령을 실행하여 인증 정책 구성 맵을 생성합니다.
$ oc apply -f attestation-policy.yaml
5.9.3. TDX용 PCCS 구성
Intel Trust Domain Extensions (TDX)를 사용하는 경우 PCCS(프로비저닝 인증서 캐싱 서비스)를 사용하도록 Trustee를 구성해야 합니다.
PCCS는 PCK(프로비저닝 인증 키) 인증서를 검색하고 로컬 데이터베이스에 캐시합니다.
공용 Intel PCCS 서비스를 사용하지 마십시오. 온프레미스 또는 퍼블릭 클라우드에서 로컬 캐싱 서비스를 사용합니다.
프로세스
다음 예에 따라
tdx-config.yaml
매니페스트 파일을 생성합니다.apiVersion: v1 kind: ConfigMap metadata: name: tdx-config namespace: trustee-operator-system data: sgx_default_qcnl.conf: | \ { "collateral_service": "https://api.trustedservices.intel.com/sgx/certification/v4/", "pccs_url": "<pccs_url>" 1 }
- 1
- PCCS URL을 지정합니다(예:
https://localhost:8081/sgx/certification/v4/
).
다음 명령을 실행하여 TDX 구성 맵을 생성합니다.
$ oc apply -f tdx-config.yaml
5.9.4. 클라이언트의 사용자 지정 키를 사용하여 보안 생성
Trustee 클라이언트에 대한 사용자 지정 키가 하나 이상 포함된 보안을 생성할 수 있습니다.
이 예에서 kbsres1
시크릿에는 클라이언트가 검색하는 두 개의 항목(key1
,key2
)이 있습니다. 동일한 형식을 사용하여 요구 사항에 따라 보안을 추가할 수 있습니다.
사전 요구 사항
- 하나 이상의 사용자 지정 키를 생성했습니다.
프로세스
다음 예에 따라 사용자 정의 키에 대한 보안을 생성합니다.
$ oc apply secret generic kbsres1 \ --from-literal key1=<custom_key1> \ 1 --from-literal key2=<custom_key2> \ -n trustee-operator-system
- 1
- 사용자 정의 키를 지정합니다.
kbsres1
시크릿은KbsConfig
사용자 지정 리소스의spec.kbsSecretResources
키에 지정됩니다.
5.9.5. 컨테이너 이미지 서명 확인을 위한 보안 생성
컨테이너 이미지 서명 확인을 사용하는 경우 공개 컨테이너 이미지 서명 키가 포함된 보안을 생성해야 합니다.
Confidential compute attestation Operator는 시크릿을 사용하여 서명을 확인하여 인증된 컨테이너 이미지만 해당 환경에 배포되도록 합니다.
Red Hat Trusted Artifact Signer 또는 기타 툴을 사용하여 컨테이너 이미지에 서명할 수 있습니다.
프로세스
다음 명령을 실행하여 컨테이너 이미지 서명 확인에 대한 보안을 생성합니다.
$ oc apply secret generic <type> \ 1 --from-file=<tag>=./<public_key_file> \ 2 -n trustee-operator-system
-
<
type>
값을 기록합니다.KbsConfig
사용자 지정 리소스를 생성할 때spec.kbsSecretResources
키에 이 값을 추가해야 합니다.
5.9.6. 컨테이너 이미지 서명 확인 정책 생성
서명 확인이 항상 활성화되므로 컨테이너 이미지 서명 확인 정책을 생성합니다. 이 정책이 없으면 Pod가 시작되지 않습니다.
컨테이너 이미지 서명 확인을 사용하지 않는 경우 서명 확인 없이 정책을 생성합니다.
자세한 내용은 containers-policy.json 5 를 참조하십시오.
프로세스
다음 예에 따라
security-policy-config.json
파일을 생성합니다.서명 확인 없이:
{ "default": [ { "type": "insecureAcceptAnything" }], "transports": {} }
서명 확인으로 다음을 수행합니다.
{ "default": [ { "type": "insecureAcceptAnything" } ], "transports": { "<transport>": { 1 "<registry>/<image>": 2 [ { "type": "sigstoreSigned", "keyPath": "kbs:///default/<type>/<tag>" 3 } ] } } }
다음 명령을 실행하여 보안 정책을 생성합니다.
$ oc apply secret generic security-policy \ --from-file=osc=./<security-policy-config.json> \ -n trustee-operator-system
보안 유형,
security-policy
또는 키osc
를 변경하지 마십시오.security-policy
시크릿은KbsConfig
사용자 지정 리소스의spec.kbsSecretResources
키에 지정됩니다.
5.9.7. 리소스 액세스 정책 생성
Trustee 정책 엔진에 대한 리소스 액세스 정책을 구성합니다. 이 정책은 Trustee가 액세스할 수 있는 리소스를 결정합니다.
Trustee 정책 엔진은 TEE 증명의 유효성을 결정하는 Attestation Service 정책 엔진과 다릅니다.
프로세스
resourcepolicy-configmap.yaml
매니페스트 파일을 생성합니다.apiVersion: v1 kind: ConfigMap metadata: name: resource-policy namespace: trustee-operator-system data: policy.rego: | 1 package policy 2 default allow = false allow { input["tee"] != "sample" }
- 1
- 리소스 정책의 이름
policy.rego
는 Trustee 구성 맵에 정의된 리소스 정책과 일치해야 합니다. - 2
- 리소스 정책은 Open Policy Agent 사양을 따릅니다. 이 예제에서는 TEE가 샘플 attester가 아닌 경우 모든 리소스를 검색할 수 있습니다.
다음 명령을 실행하여 리소스 정책 구성 맵을 생성합니다.
$ oc apply -f resourcepolicy-configmap.yaml