민감한 데이터와 애플리케이션을 보호하는 것은 그 어느 때보다 중요합니다. 예를 들어, Digital Operational Resilience Act (DORA)은 사용 중인 데이터 암호화를 의무화하고 있습니다. 클라우드 기반 가상 머신(VM)의 경우, 이는 기본 클라우드 인프라에서도 데이터가 비공개로 안전하게 유지되도록 보장하는 것을 의미합니다. 바로 이 부분에서 trusted execution environment (TEE)을 사용하는 기밀 VM이 중요한 역할을 합니다.
이 글은 다양한 기밀 컴퓨팅 기술을 사용하여 Red Hat OpenShift Virtualization 에서 기밀 컴퓨팅을 활성화하는 방법을 보여주는 시리즈의 두 번째 글입니다 . 이전 글 에서는 AMD의 SEV-SNP에 대해 다루었습니다. 여기에서는 Intel TDX(Trust Domain Extensions) 기술을 사용하여 이러한 기밀 VM을 실행하도록 OpenShift Virtualization을 구성하는 방법을 설명합니다. 또한 Trustee 라는 도구를 사용하여 이러한 VM의 보안을 검증하는 방법도 보여드리겠습니다 . 구체적으로, VM 부팅 시 trustee-attester를 사용하여 VM 디스크를 안전하게 복호화하고, VM의 신뢰성이 입증된 경우에만 민감한 데이터에 액세스할 수 있도록 합니다.
참고: 이 문서에서는 KubeVirt (OpenShift 가상화 기반) 를 기반으로 구축된 실험적 설정인 개념 증명(PoC)에 대해 설명합니다 . Kubevirt에서 이 지원을 활성화하는 작업이 진행 중입니다. 제안 문서에 대한 진행 중인 논의는 github 향상 풀 리퀘스트 에서 , 지원을 구현하는 변경 사항은 kubevirt 풀 리퀘스트 에서 확인할 수 있습니다 .
호스트 준비
이 실험적 설정에서는 호스트를 Red Hat OpenShift Container Platform 으로 단일 노드 구성으로 구성합니다 . Intel TDX를 사용하려면 이 고급 보안 기능을 지원하도록 호스트의 운영 체제 커널을 업데이트해야 합니다.
TDX 기능 지원은 Linux 커널 6.16 버전부터 통합되었습니다. QEMU는 9.* 버전부터, Libvirt는 9.* 버전부터 TDX를 지원해 왔습니다. TDX를 지원하는 패키지를 다운로드 할 수 있습니다.
TDX가 작동하려면 다음 지침 에 따라 BIOS에서 SGX를 활성화하세요 . 또한 BIOS에서 SGX Auto MP Registration Agent라는 특정 설정을 활성화해야 하며 , 경우에 따라 시스템 펌웨어를 업데이트해야 합니다.
호스트가 업데이트된 커널로 부팅된 후 dmesg | grep -i tdx 명령을 실행하여 TDX가 활성화되었는지 확인할 수 있습니다.
이러한 전제 조건을 완료한 후, 필요한 TDX 및 증명 기능이 포함된 실험적 브랜치 에서 KubeVirt를 배포합니다.
소프트웨어 구성 요소
그림 1은 배포된 소프트웨어 구성 요소를 보여줍니다. 이는 PoC(개념 증명)임을 유의하시기 바랍니다. 오픈 소스 커뮤니티에서 논의가 진행 중이므로 향후 다른 설계로 이어질 수 있습니다.
이 PoC에서는 TDX와 함께 작동하도록 구성된 QEMU 및 Libvirt와 같은 기본 가상화 소프트웨어를 사용합니다. 시스템은 KubeVirt를 빌드할 때 이러한 구성을 통합합니다. VM을 기밀로 처리해야 함을 나타내기 위해 사이드카 컨테이너를 통해 도우미 프로그램이 배포됩니다. 이 사이드카는 VM 구성을 특정하게 변경하여 QEMU에 기밀 VM 보호 기능을 적용하도록 지시합니다. 이 사이드카의 사용은 이 PoC에만 국한됩니다.
KubeVirt에서 virt-launcher 포드는 VM의 QEMU 프로세스가 실행되는 곳입니다. 이 포드를 확장하기 위해 quote generation service (QGS)를 추가했습니다. 이 서비스는 기밀 VM이 신원을 증명하거나 보안 상태를 검증해야 할 때마다 QEMU와 통신합니다. 이 프로세스를 증명(attestation)이라고 합니다. VM이 이 검증을 요청하면 QGS는 VM의 현재 상태에 대한 보안 디지털 지문 또는 증명 보고서인 견적 BLOB을 생성합니다. 이 작업을 수행하려면 그림 1과 같이 QGS가 특정 하드웨어 장치에 직접 액세스해야 합니다.
또 다른 중요한 구성 요소는 multi-package registration agent (MPA)입니다. 이 서비스는 호스트 시스템이 시작될 때 한 번만 실행됩니다. 이 서비스의 목적은 호스트 하드웨어를 인텔 서버에 안전하게 등록하는 것입니다. 이 등록은 QGS가 정상적으로 작동하고 유효한 증명 보고서를 생성하는 데 필수적인 단계입니다. 이 설정에서 MPA 서비스는 특별히 구성된 권한이 있는 포드(pod) 내에서 실행됩니다.
기밀 VM이 증명 블롭(즉, 보안 디지털 지문)을 생성하려면 다음을 포함한 일련의 내부 명령을 실행합니다.
mkdir /sys/kernel/config/tsm/report/report0 cd /sys/kernel/config/tsm/report/report0 dd if=/dev/urandom bs=64 count=1 > inblob hexdump -C outblob
blob 요청은 configfs-tsm이라는 Linux 표준 인터페이스를 사용합니다. 이 인터페이스는 구성 파일 시스템(configfs)을 통해 trusted security modules (TSMs)과 표준화된 방식으로 상호 작용할 수 있도록 합니다. 이 인터페이스는 모든 기밀 기술(예: AMD sev-snp, ARM cca, INTEL tdx)에서 공통적으로 사용됩니다. outblob 파일을 읽으면 quote blob이 출력됩니다. blob 생성을 위해 QEMU는 QGS와 상호 작용하여 이 보안 디지털 지문을 생성하고 이를 VM으로 다시 전송합니다.
이 PoC는 증명 보고서의 로컬 생성에 중점을 두지만, 실제 시나리오에서는 생성된 블롭(BLOB)이 검증을 위해 원격 서버로 전송됩니다. 이는 호스트 시스템 자체가 손상될 수 있기 때문에 매우 중요합니다. 신뢰할 수 있는 원격 검증자만이 증명 보고서를 안전하게 검증하고 VM 디스크의 복호화 비밀번호와 같은 중요한 기밀 정보의 공개 여부를 결정할 수 있습니다.
이 더 광범위한 프로세스를 지원하기 위해 Trustee 프로젝트의 두 가지 구성 요소인 trustee-attester와 trustee-operator를 소개합니다. Trustee-attester는 기밀 VM 내부에서 실행되며 클라이언트 역할을 하여 비밀을 요청합니다. trustee-operator는 OpenShift 클러스터에 배포되어 서버 역할을 합니다. attester는 VM에서 보안 BLOB을 수집하여 오퍼레이터에 전송합니다. 오퍼레이터는 이 증명의 유효성을 검증합니다. VM이 신뢰할 수 있다고 판단되면 운영자는 비밀 집합(즉, 복호화 키)을 VM에 반환합니다.
이 설정을 보여주기 위해 간단한 비디오를 제작했습니다. 이 데모에서는 VM 내에 시스템 서비스로 trustee-attester가 설치됩니다. VM이 부팅되면 증명자가 자동으로 증명 BLOB을 trustee-operator로 전송합니다. 오퍼레이터는 증명을 검증하고, 검증이 완료되면 VM 디스크 암호를 해독하는 데 필요한 비밀번호를 공개합니다. 이를 통해 VM은 보호된 데이터에 액세스하고 완전히 부팅할 수 있습니다.
이 스니펫은 암호화된 디스크로 기밀 VM을 만드는 방법을 보여줍니다.
mvaralar@fedora:~/Desktop/confclusters $ oc apply -f openshift/cnv/fedora_vm_encrypted.yaml virtualmachine.kubevirt.io/tdx-encrypted created
다음 스니펫에서는 기밀 VM을 실행하는 QEMU 프로세스가 포함된 virt-launcher 포드를 보여줍니다.
NAME READY STATUS RESTARTS AGE virt-launcher-tdx-encrypted-b2hjh 0/4 PodInitializing 0 8s virt-launcher-tdx7-xs7rp 4/4 Running 0 27d virtlab2401virtengrdu2dcredhatcom-debug-nx7lc 0/1 Completed 0 47d
이 VM에는 trustee-operator에서 암호 해독 시크릿을 검색하도록 구성된 시스템 서비스가 있습니다.
다음 스니펫에서는 기밀 VM이 부팅을 시도하는 모습을 볼 수 있습니다. VM은 trustee-operator에 연결을 시도한 후 QGS 서비스에도 연결을 시도합니다.
See "systemctl status 'systemd-cryptsetup@\x2ddc03b9744a03.service'" for details [DEPEND] Dependency failed for cryptsetup.target - Local Encrypted Volumes. [ OK ] Reached target sysinit.target - System Initialization. [ OK ] Reached target basic.target - Basic System. [ 28.904027] dracut: ATTESTATION SERVICE: Trying to fetch passphrase from http://172.30.19.138:8080: 1 [ 28.910971] dracut: Executing: /usr/bin/trustee-attester --url http://172.30.19.138:8080 get-resource --path default/kbsres1/key1 [ 43.178599] dracut: ATTESTATION SERVICE: Trying to fetch passphrase from http://172.30.19.138:8080: 2 [ 43.182141] dracut: Executing: /usr/bin/trustee-attester --url http://172.30.19.138:8080 get-resource --path default/kbsres1/key1 [ 57.443960] dracut: ATTESTATION SERVICE: Trying to fetch passphrase from http://172.30.19.138:8080: 3 [ 57.455281] dracut: Executing: /usr/bin/trustee-attester --url http://172.30.19.138:8080 get-resource --path default/kbsres1/key1 [ 71.722762] dracut: ATTESTATION SERVICE: Trying to fetch passphrase from http://172.30.19.138:8080
QGS 서비스가 실행될 때까지 VM은 계속해서 증명 BLOB을 요청합니다.
이 PoC에서는 다음과 같이 QGS 서비스를 수동으로 시작해야 합니다.
mvaralar@fedora:~/Desktop/confclusters $ watch oc get pods mvaralar@fedora:~/Desktop/confclusters $ oc rsh virt-launcher-tdx-encrypted-b2hjh sh-5.1$ cp /etc/sgx_default_qcnl.conf /tmp/conf sh-5.1$ sed -i "s/\"use_secure_cert\": true/\"use_secure_cert\": false/g" /tmp/conf sh-5.1$ export QCNL_CONF_PATH=/tmp/conf sh-5.1$ /usr/sbin/qgs --debug --no-daemon --verbose
VM이 복호화 비밀번호를 성공적으로 획득하면 이를 사용하여 디스크를 복호화합니다. VM이 완전히 부팅되면 Intel TDX를 사용하는 기밀 VM을 실제로 실행하고 있음을 확인할 수 있습니다. 다음 스니펫은 기밀 VM이 부팅되는 모습을 보여줍니다.
[ OK ] Started gssproxy.service - GSSAPI Proxy Daemon. [ OK ] Started nfs-client.target - NFS client services. [ OK ] Reached target remote-fs-pre.target - Preparation for Remote File Systems. [ OK ] Reached target remote-cryptsetup.target - Remote Encrypted Volumes. [ OK ] Reached target remote-fs.target - Remote File Systems. [ OK ] Starting systemd-user-sessions.service - Permit User Sessions... [ OK ] Finished systemd-user-sessions.service - Permit User Sessions. [ OK ] Started extd.service - Deferred execution scheduler. [ OK ] Started crond.service - Command Scheduler. [ OK ] Starting plymouth-quit-wait.service - Wait until boot process finishes up... [ OK ] Starting plymouth-quit.service - Terminate Plymouth Boot Screen... 105.155912] fbcon: Taking over console Fedora Linux 42 (Server Edition) Kernel 6.14.0-63.fc42.x86_64 on x86_64 (ttyS0) Web console: https://example-u6viovlxt17wv2b7:9090/ or https://10.0.2.2:9090/ example-u6viovlxt17wv2b7 login: root Password: Last login: Wed May 21 12:01:40 on ttyS0 [root@example-u6viovlxt17wv2b7 ~]# dmesg | grep tdx [ 0.000000] tdx: Guest detected [ 0.000000] tdx: Attributes: SEPT_VE_DISABLE [ 0.000000] tdx: TD_CTLS: PENDING_VE_DISABLE ENUM_TOPOLOGY [ 37.941673] systemd[1]: Detected confidential virtualization tdx. [ 37.941697] systemd[1]: Detected confidential virtualization tdx.
QGS가 QEMU의 요청에 올바르게 응답했는지 확인할 수 있습니다.
다음은 Blob 생성 중의 QGS 응답입니다.
tee_att_get_quote return Success About to write response in thread [7fd79b0fc640] About to shutdown and close socket Erased a connection, now [0]
마지막 생각
이 문서에서는 Intel TDX 기술을 활용하여 Red Hat OpenShift Virtualization에서 안전한 기밀 VM을 실행하는 개념 증명(PoC)을 시연했습니다. 이러한 VM이 TEE를 사용하여 기본 클라우드 인프라의 민감한 데이터를 보호하는 방법과 증명을 사용하여 플랫폼의 신뢰성을 검증하는 방법을 살펴보았습니다.
Trustee를 통합함으로써 VM이 어떻게 안전하게 신원을 확인할 수 있는지 보여주었습니다. 원격 Trustee 서버를 통해 VM의 신원을 확인하면 암호화된 디스크가 자동으로 잠금 해제되어 VM이 안전하고 검증된 상태일 때만 민감한 데이터에 접근할 수 있도록 합니다. 이는 실험적인 설정이지만, OpenShift와 같은 클라우드 환경에서 중요한 워크로드의 데이터 프라이버시와 보안을 강화할 수 있는 기밀 컴퓨팅의 잠재력을 잘 보여줍니다.
