워크로드는 워크로드 작성자가 만들며 데이터 공동작업자가 작업하려는 기밀 데이터를 처리합니다.
워크로드 작성자는 워크로드를 만들기 위해 다음 리소스를 모아야 합니다.
기밀 데이터를 처리하는 애플리케이션 지원하는 컨테이너화된 이미지를 빌드하는 경우 원하는 언어로 애플리케이션을 작성할 수 있습니다.
Docker를 사용하여 애플리케이션을 패키징하는 컨테이너화된 이미지
Docker 이미지를 저장할 Artifact Registry의 저장소입니다.
워크로드를 실행하는 방법을 제어하고 악의적인 워크로드 운영자의 기능을 제한하는 컨테이너 이미지에 설정된 실행 정책
워크로드를 배포하기 위해 워크로드 운영자가 Confidential Space 이미지를 기반으로 컨피덴셜 VM을 실행합니다. 이렇게 하면 Artifact Registry에서 컨테이너화된 이미지를 가져와 실행합니다.
데이터 공동작업자가 워크로드의 증명을 확인해야 데이터에 액세스할 수 있습니다.
시작하기 전에
Confidential Space용 워크로드를 작성하는 것은 단순한 코드와 디버깅 그 이상입니다. 또한 데이터 공동작업자와 협력하여 요구사항을 평가하고, 환경을 설정하고, 코드를 컨테이너화된 이미지로 패키징하고, 워크로드 운영자와 협력하여 모든 것이 올바르게 배포되는지 확인해야 합니다.
데이터 공동작업자와 대화하기
애플리케이션 작성을 시작하기 전에 데이터 공동작업자와 내가 작업할 비공개 데이터에 관해 대화를 나눠야 합니다. 다음과 같은 질문을 할 수 있습니다.
관련된 조직 ID는 무엇인가요?
관련된 프로젝트 번호는 무엇인가요?
액세스해야 하는 Google Cloud 리소스는 무엇이며 ID와 이름은 무엇인가요?
Google CloudIAM에서 관리하지 않는 리소스에 액세스해야 하나요?
애플리케이션은 비공개 데이터를 어떻게 비교하고 처리해야 하나요?
출력 형식은 어떻게 되나요?
출력은 어디에 저장해야 하며 암호화해야 하나요?
모든 데이터 공동작업자에게 동일한 결과가 표시되나요? 아니면 각 공동작업자에게 고유한 결과가 표시되나요?
또한 각 데이터 공동작업자에게는 충족해야 하는 고유한 개인 정보 보호 요구사항이 있을 수 있습니다. 워크로드로 인해 민감한 정보가 노출되지 않도록 하는 것이 매우 중요합니다.
Confidential Space 솔루션 빌드
첫 번째 Confidential Space 환경 만들기와 같이 적절한 권한이 있는 프로젝트를 두 개 이상 테스트 환경으로 설정하는 것이 좋습니다. 데이터 공동작업자의 프로젝트 설정을 최대한 미러링해 보세요. 이를 통해 교차 프로젝트 권한을 사용해 보고 특정 Google Cloud 리소스에서 필요한 데이터를 검색해 볼 수 있습니다. 또한 워크로드 운영자 및 데이터 공동작업자 역할과 그 책임을 이해하는 데 도움이 됩니다.
초기 빌드 단계에서는 다음과 같은 관행을 따르는 것이 좋습니다.
데이터 공동작업자로 작업할 때는 개발 속도를 위해 증명 유효성 검사를 최소화하세요.
워크로드 운영자로 작업할 때는 워크로드를 배포할 때 프로덕션 대신 Confidential Space 디버그 이미지를 사용하세요. 이렇게 하면 워크로드 문제를 해결할 수 있는 방법이 더 많아집니다.
애플리케이션이 성숙해지고 상태가 더 예측 가능해지면 증명 유효성 검사 및 출시 정책으로 솔루션을 점점 더 잠그고 프로덕션 컨피덴셜 스페이스 이미지로 전환할 수 있습니다.
테스트 환경에서 워크로드가 올바르게 작동하는지 확인한 후에는 데이터 공동작업자의 프로젝트에서 실제 리소스와 가짜 데이터를 사용하여 테스트로 전환하여 데이터 공동작업자에게 모든 작동 방식을 보여줄 수 있습니다. 이 시점에서 독립형 워크로드 운영자를 사용하기 시작할 수 있습니다.
모든 것이 작동하고 출력이 예상대로 표시되면 프로덕션 데이터로 테스트를 시작할 수 있습니다. 테스트가 완료되고 모든 당사자가 결과에 서명하면 워크로드를 프로덕션에 적용할 수 있습니다.
출력 주의
코드를 테스트하는 동안 STDOUT 또는 STDERR에 출력하여 디버그하고 싶을 수 있습니다. 이렇게 하려면 로그에 액세스하여 다른 당사자가 읽을 수 있는 비공개 데이터를 노출하지 않도록 주의하세요. 코드가 프로덕션에서 작동하기 시작하기 전에 코드가 꼭 필요한 것 외에는 아무것도 출력하지 않는지 확인합니다.
최종 출력도 마찬가지입니다. 원본 데이터의 개인 정보 보호 및 민감성을 손상시키지 않는 최종 결과만 제공합니다.
Docker로 컨테이너화된 이미지 빌드
애플리케이션은 Docker에서 빌드한 컨테이너화된 이미지로 패키징되어야 하며, 이 이미지는 Artifact Registry에 저장됩니다. 워크로드가 배포되면 Docker 이미지가 기밀 정보 공간 이미지에 의해 Artifact Registry 저장소에서 가져와 실행되며 애플리케이션은 적절한 프로젝트 리소스에 대한 작업을 시작할 수 있습니다.
Docker 이미지를 빌드할 때는 다음 사항을 고려하세요.
디스크 및 메모리 한도
Confidential Space는 더 큰 부팅 디스크 크기를 사용할 때 부팅 디스크 상태 파티션의 크기를 자동으로 조정합니다. 파티션 크기는 대략 부팅 디스크 크기에서 5GB를 뺀 값입니다.
Confidential Space 무결성 파일 시스템 보호의 일환으로 Confidential Space는 디스크 무결성 태그를 메모리에 저장합니다. 이렇게 하면 디스크 바이트당 약 1% 의 메모리 오버헤드가 발생합니다. 예를 들어 100GB 디스크에는 1GB의 메모리가 필요하고 10TB 디스크에는 100GB의 메모리가 필요합니다.
VM 메모리 제한을 초과하지 않도록 합니다. 스왑 메모리는 Confidential Space VM에서 사용 중지되므로 메모리를 과도하게 사용하면 워크로드가 비정상 종료될 수 있습니다. 머신 선택이 디스크 무결성 오버헤드 외에도 워크로드 메모리 사용량을 지원하는지 확인합니다.
만료된 OIDC 토큰
워크로드가 시작될 때 워크로드에서 사용할 수 있는 OIDC 토큰이 제공됩니다. 워크로드의 VM에 관한 확인된 증명 클레임을 포함하며 /run/container_launcher/attestation_verifier_claims_token의 워크로드 컨테이너에 저장됩니다. 토큰은 60분 후에 만료됩니다.
토큰이 만료되면 지수 백오프를 사용하여 백그라운드에서 갱신을 시도하며 성공할 때까지 계속 시도합니다. 네트워크 문제, 증명 서비스 중단 또는 기타 이유로 인해 새로고침이 실패하면 워크로드 코드에서 이 실패를 처리할 수 있어야 합니다.
워크로드는 다음 방법 중 하나로 토큰 새로고침 실패를 처리할 수 있습니다.
만료된 토큰은 초기 사용 후 더 이상 필요하지 않으므로 무시합니다.
만료된 토큰이 새로고침될 때까지 기다립니다.
워크로드를 종료합니다.
인메모리 스크래치 마운트
Confidential Space는 메모리 내 스크래치 공간 추가를 지원합니다. 이렇게 하면 Confidential Space VM의 사용 가능한 메모리가 사용됩니다. 스크래치 공간은 컨피덴셜 VM의 메모리를 사용하므로 컨피덴셜 VM과 동일한 무결성 및 기밀성 속성을 갖습니다.
tee-dev-shm-size를 사용하여 워크로드의 /dev/shm 공유 메모리 마운트 크기를 늘릴 수 있습니다.
/dev/shm 크기는 KB로 지정됩니다.
tee-mount를 사용하여 세미콜론으로 구분된 구성을 사용하여 실행 중인 컨테이너에서 tmpfs 마운트를 지정할 수 있습니다. type 및 source는 항상 tmpfs입니다. destination는 tee.launch_policy.allow_mount_destinations 실행 정책과 상호작용하는 마운트 포인트입니다. 원하는 경우 tmpfs 크기를 바이트 단위로 지정할 수 있습니다. 기본 크기는 VM 메모리의 50% 입니다.
인바운드 포트
기본적으로 Confidential Space VM은 모든 인바운드 포트를 차단하는 방화벽 규칙으로 작동합니다. Confidential Space 이미지 버전 230600 이상을 사용하는 경우 워크로드 이미지를 빌드할 때 Dockerfile에 열린 상태로 유지할 인바운드 포트를 지정할 수 있습니다.
포트를 열려면 포트 번호 및 tcp 또는 udp의 프로토콜(선택사항)과 함께 EXPOSE 키워드를 Dockerfile에 추가합니다. 포트의 프로토콜을 지정하지 않으면 TCP와 UDP가 모두 허용됩니다. 다음은 수신 포트를 노출하는 Dockerfile의 예입니다.
FROM alpine:latest
EXPOSE 80
EXPOSE 443/tcp
EXPOSE 81/udp
WORKDIR /test
COPY salary /test
ENTRYPOINT ["/test/salary"]
CMD []
사용하는 기본 이미지에 따라 일부 포트가 이미 노출되어 있을 수 있습니다. Dockerfile는 추가 포트만 노출합니다. 기본 이미지에서 이미 열어둔 포트는 차단할 수 없습니다.
워크로드 운영자는 워크로드를 실행하기 전에 VPC 방화벽에서 노출된 포트가 열려 있는지 확인해야 합니다. 포트 번호는 워크로드 작성자가 제공하거나 Docker 이미지 정보에서 가져올 수 있습니다.
노출된 포트는 콘솔에 로깅되며 tee-container-log-redirect 메타데이터 변수를 사용할 때 Cloud Logging으로 리디렉션됩니다.
출시 정책
시작 정책은 워크로드 운영자가 설정한 VM 메타데이터 변수를 재정의하여 악의적인 작업을 제한합니다. 워크로드 작성자는 컨테이너 이미지를 빌드하는 과정에서 라벨이 있는 정책을 설정할 수 있습니다.
예를 들어 Dockerfile의 경우:
LABEL "tee.launch_policy.allow_cmd_override"="true"
Bazel BUILD 파일의 경우:
container_image(
...
labels={"tee.launch_policy.allow_cmd_override":"true"}
...
)
사용 가능한 출시 정책은 다음 표에 나와 있습니다.
| 정책 | 유형 | 설명 |
|---|---|---|
|
다음과 상호작용:
|
부울(기본값: false) |
워크로드 컨테이너의 Dockerfile에 지정된
CMD를 워크로드 연산자가
tee-cmd 메타데이터 값으로 재정의할 수 있는지 결정합니다.
|
|
다음과 상호작용:
|
쉼표로 구분된 문자열 |
워크로드 운영자가
tee-env-ENVIRONMENT_VARIABLE_NAME 메타데이터 값으로 설정할 수 있는 허용된 환경 변수 이름의 쉼표로 구분된 문자열입니다.
|
|
다음과 상호작용:
|
콜론으로 구분된 문자열 |
워크로드 운영자가 예: |
|
다음과 상호작용:
|
정의된 문자열 |
워크로드 운영자가
유효한 값은 다음과 같습니다.
|
|
다음과 상호작용:
|
정의된 문자열 |
워크로드 운영자가
유효한 값은 다음과 같습니다.
|
여러 워크로드 실행
정상적인 환경을 보장하려면 워크로드를 다시 시작할 때 VM을 다시 시작해야 합니다. 이렇게 하면 일회용 키로 VM 디스크를 암호화하여 디스크에서 워크로드 이미지를 다운로드하고 측정한 후 수정하는 공격 벡터를 해결할 수 있습니다.
또한 부팅 시간과 각 워크로드 실행에 워크로드 이미지를 가져오는 등의 오버헤드가 추가됩니다. 이러한 오버헤드가 워크로드의 성능에 너무 큰 영향을 미치는 경우 워크로드 자체에 워크로드 재시작을 코딩할 수 있지만, 이 경우 위험 프로필이 증가합니다.
재현 가능한 컨테이너 이미지
재현 가능한 방식으로 컨테이너 이미지를 빌드하면 당사자 간의 신뢰를 높이는 데 도움이 될 수 있습니다. Bazel로 재현 가능한 이미지를 빌드할 수 있습니다.
Google Cloud IAM에서 관리하지 않는 리소스
Google Cloud IAM에서 관리하지 않는 리소스에 액세스하려면 워크로드에서 맞춤 잠재고객을 지정해야 합니다.
자세한 내용은 Google Cloud IAM에서 관리하지 않는 리소스에 액세스를 참고하세요.
서명된 컨테이너 이미지
공개 키로 컨테이너 이미지에 서명할 수 있으며, 그러면 데이터 공동작업자가 WIP 정책에서 이미지 다이제스트를 지정하는 대신 서명에 이를 사용할 수 있습니다.
즉, 데이터 공동작업자는 워크로드가 업데이트될 때마다 WIP 정책을 업데이트할 필요가 없으며 워크로드는 보호된 리소스에 계속 중단 없이 액세스할 수 있습니다.
Sigstore Cosign을 사용하여 컨테이너 이미지에 서명할 수 있습니다. Confidential Space에서 서명을 가져올 수 있도록 하려면 워크로드 운영자가 워크로드를 배포하기 전에 tee-signed-image-repos 메타데이터 변수에 서명 정보를 추가해야 합니다.
런타임 중에 서명은 확인을 위해 Confidential Space 증명 서비스로 전송됩니다. 증명 서비스는 확인된 서명 클레임이 포함된 증명 클레임 토큰을 반환합니다. 다음은 서명 소유권 주장의 예입니다.
"image_signatures": [
{
"key_id": "hexadecimal-sha256-fingerprint-public-key1",
"signature": "base64-encoded-signature",
"signature_algorithm": "RSASSA_PSS_SHA256"
},
{
"key_id": "hexadecimal-sha256-fingerprint-public-key2",
"signature": "base64-encoded-signature",
"signature_algorithm": "RSASSA_PSS_SHA256",
},
{
"key_id": "hexadecimal-sha256-fingerprint-public-key3",
"signature": "base64-encoded-signature",
"signature_algorithm": "RSASSA_PSS_SHA256",
}
],
컨테이너 이미지 서명을 구성하려면 서명된 컨테이너 이미지 Codelab을 참고하세요.