Notes

K8s 17. Confidential Computing

Kubernetes/container 환경에서 application code 변경 없이 confidential computing을 적용하는 no-code-change 접근을 data in use, TEE, attestation, key release, privileged user threat, DevSecOps 관점에서 정리한다.

Published: Jun 3, 2026
Updated: Jun 3, 2026
Area: Cloud Infrastructure
Type: concept
Series: Kubernetes Essentials
Category: Notes

KubernetesConfidential ComputingData in UseTEEAttestationIBM Cloud Data ShieldContainer SecurityPrivileged User AttackZero TrustDevSecOps

Confidential computing은 기존의 data at rest와 data in transit 보호를 넘어, application이 데이터를 실제로 처리하는 순간인 data in use까지 보호하려는 보안 모델이다.

기존 보안 모델은 주로 저장 중인 데이터와 전송 중인 데이터를 보호했다.

Data at rest
  → disk, database, object storage 등에 저장된 데이터

Data in transit
  → network를 통해 이동 중인 데이터

하지만 application이 데이터를 처리하려면 어느 순간에는 암호화된 데이터가 복호화되어 memory 위에 올라와야 한다.

encrypted data
  ↓ decrypt
plaintext in memory
  ↓ process
result
  ↓ encrypt / store / send

이때 발생하는 data in use를 hardware-backed Trusted Execution Environment 안에서 보호하려는 접근이 confidential computing이다.

핵심 요약

Confidential computing은 application이 데이터를 처리하는 순간에도 data confidentiality와 integrity를 보장하려는 보안 접근이다.

기존 보호:
  data at rest
  data in transit

추가로 필요한 보호:
  data in use

해결 방향:
  hardware-based Trusted Execution Environment
  secure enclave
  attestation
  key release policy
  runtime protection

여기서 no-code-change approach는 application business logic을 다시 작성하지 않고도, 기존 containerized application을 confidential computing 환경으로 감싸서 보호하는 접근을 의미한다.

Application code no change
  ≠
Deployment no change

Business logic no change
  +
Runtime/deployment/security layer 변경

한 문장으로 정리하면 다음과 같다.

No-code-change confidential computing은 기존 containerized application의 business logic을 바꾸지 않고, hardware-backed TEE와 attestation 기반 runtime protection을 적용해 Kubernetes 환경에서 data in use와 privileged infrastructure threat를 줄이는 cloud native security 접근이다.

왜 data in use 보호가 필요한가?

Cloud security에서는 보통 data state를 세 가지로 나눈다.

Data at rest
  → 저장 중인 데이터

Data in transit
  → 전송 중인 데이터

Data in use
  → CPU와 memory에서 처리 중인 데이터

기존 보안 체계는 data at rest와 data in transit을 비교적 잘 다뤄왔다.

Data at rest
  → disk encryption
  → database encryption
  → object storage encryption
  → KMS/HSM 기반 key management

Data in transit
  → TLS
  → mTLS
  → VPN
  → private network

문제는 data in use다. 데이터가 처리되려면 어느 순간에는 plaintext 형태로 memory 위에 존재해야 한다.

encrypted customer record
  ↓ decrypt
plaintext customer record in memory
  ↓ process
encrypted result

이 순간이 공격 표면이 된다.

root 권한을 가진 host admin
compromised kernel
malicious privileged container
debugging tool
memory dump
runtime introspection
insider threat
cloud infrastructure operator

Confidential computing은 이 지점을 줄이려는 기술이다.

Kubernetes container 환경에서의 문제

Kubernetes는 containerized workload를 실행하기 위한 platform이지만, 모든 threat를 자동으로 막아주지는 않는다.

Kubernetes cluster에는 여러 권한 계층이 있다.

cluster-admin
namespace admin
node admin
container runtime access
cloud infrastructure operator
CI/CD operator
application owner

일반적인 container 보안은 다음을 통해 강화한다.

RBAC
NetworkPolicy
Pod Security Standards
non-root container
readOnlyRootFilesystem
image scanning
admission control
Secrets management
node hardening
runtime security

하지만 privileged user가 node나 runtime에 접근할 수 있는 상황이라면, application 내부의 민감한 data in use는 여전히 위험할 수 있다.

예를 들어 공격자는 다음을 시도할 수 있다.

container process 조사
environment variable 확인
mounted secret 확인
runtime debug
memory dump
filesystem 접근
privileged pod 실행
hostPath mount
container runtime socket 접근

문제의 핵심은 다음 질문이다.

Kubernetes 보안을 잘 해도,
privileged user나 infrastructure operator를 완전히 신뢰해야 하는가?

Application code를 다시 작성하지 않고,
containerized application의 runtime data를 더 강하게 보호할 수 있는가?

Confidential computing은 이 질문에 대한 하나의 보안 layer다.

Confidential computing의 기본 구조

Confidential computing의 중심 개념은 TEE(Trusted Execution Environment)다.

TEE는 hardware 기반으로 격리된 실행 환경이다.

Normal world
  ├─ host OS
  ├─ hypervisor
  ├─ admin tools
  ├─ other workloads
  └─ privileged users

Trusted Execution Environment
  └─ protected application + protected data

핵심 보안 목표는 다음이다.

data confidentiality
  → TEE 밖에서는 data를 읽기 어렵게 한다.

data integrity
  → TEE 밖에서 data나 execution state를 임의로 변조하기 어렵게 한다.

code integrity
  → 기대한 code가 실행 중인지 검증한다.

attestation
  → remote party가 “정말 신뢰 가능한 TEE에서 실행 중인지” 확인한다.

즉 confidential computing의 목표는 다음처럼 정리할 수 있다.

host를 완전히 신뢰하지 않는다.
hypervisor를 완전히 신뢰하지 않는다.
privileged operator를 완전히 신뢰하지 않는다.
hardware-backed TEE와 attestation으로 실행 환경을 검증한다.

No code change가 의미하는 것

No code change는 중요한 표현이다.

이 말은 보통 다음을 의미한다.

application source code를 confidential computing 전용으로 다시 작성하지 않는다.
business logic을 바꾸지 않는다.
기존 containerized application을 최대한 그대로 사용한다.
보호 기능은 runtime, wrapper, platform, deployment layer에서 제공한다.

하지만 “아무것도 안 바꾼다”는 뜻은 아니다.

바뀔 수 있는 것은 다음이다.

deployment 방식
container runtime
image packaging
manifest 설정
node type
security profile
key release flow
attestation 설정
CI/CD packaging step

즉 더 정확한 표현은 다음과 같다.

Application code no change
  ≠
Deployment no change

Business logic no change
  +
Runtime/deployment/security layer 변경

이 구분이 중요하다. No-code-change approach는 application 개발자의 migration 부담을 줄이지만, platform engineering과 DevSecOps 측면에서는 설정과 운영 흐름이 추가된다.

IBM Cloud Data Shield가 다루는 문제

No-code-change confidential computing 접근의 예로 IBM Cloud Data Shield를 볼 수 있다.

개념적으로 정리하면 다음 흐름이다.

기존 containerized app
  ↓
IBM Cloud Data Shield 적용
  ↓
application을 protected execution environment 안에서 실행
  ↓
privileged user가 container 내부 data에 접근하기 어려워짐
  ↓
application code는 그대로 유지

일반적인 Kubernetes container는 worker node 위에서 실행된다.

Worker Node
  ├─ kubelet
  ├─ container runtime
  ├─ Pod
  │   └─ container process
  └─ host OS / kernel

Confidential computing을 적용하면 sensitive workload가 더 강한 trust boundary 안에서 실행된다.

Worker Node / Infrastructure
  ├─ normal control plane interaction
  ├─ Kubernetes scheduling
  ├─ Pod lifecycle
  └─ protected enclave / TEE
      └─ application process + sensitive data

여기서 중요한 점은 Kubernetes workflow와 confidential computing boundary가 함께 작동해야 한다는 것이다.

Privileged user attack이란 무엇인가?

Privileged user attack은 높은 권한을 가진 사용자가 application data에 접근하려는 상황을 의미한다.

예를 들어 다음 actor가 있을 수 있다.

cluster administrator
node administrator
cloud infrastructure operator
malicious insider
compromised privileged account
compromised CI/CD operator

일반적인 보안 체계에서는 이런 actor를 어느 정도 신뢰해야 한다.

root 권한자는 host filesystem을 볼 수 있다.
node admin은 container runtime에 접근할 수 있다.
cluster-admin은 Pod spec과 Secret을 볼 수 있다.
infrastructure operator는 VM lifecycle을 제어할 수 있다.

Confidential computing은 이 신뢰 범위를 줄이려는 접근이다.

기존 모델:
  privileged operator를 신뢰해야 함

confidential computing 모델:
  privileged operator도 TEE 내부 plaintext data에는 접근하기 어렵게 함

다만 완전한 마법은 아니다. Confidential computing이 줄이는 것은 특정 threat surface다. 다음 문제까지 자동으로 해결하지는 않는다.

application 내부 취약점
잘못된 authorization
공개 API 취약점
악성 code 배포
secret을 log로 출력하는 문제
plaintext를 TEE 밖으로 직접 전송하는 문제

Confidential computing이 Kubernetes 보안과 다른 점

Kubernetes 보안과 confidential computing은 서로 대체 관계가 아니다.

영역	Kubernetes 보안	Confidential computing
접근 제어	RBAC, ServiceAccount	TEE 내부 접근 제한
network	NetworkPolicy, mTLS	TEE 밖 traffic 자체를 자동 해결하지는 않음
Pod 권한	Pod Security, securityContext	privileged actor로부터 runtime data 보호
image	image scanning, signing	실행 환경의 confidentiality/integrity 강화
secret	Kubernetes Secret, external secret manager	secret이 memory에서 사용될 때 보호
node	node hardening, patching	underlying platform 신뢰 축소
runtime	seccomp, AppArmor, SELinux	hardware-isolated execution

Kubernetes 보안은 주로 다음을 제어한다.

누가 무엇을 배포할 수 있는가?
Pod가 어떤 권한으로 실행되는가?
Pod끼리 통신할 수 있는가?
어떤 image를 쓸 수 있는가?
Secret을 누가 볼 수 있는가?

Confidential computing은 다음 질문을 다룬다.

application이 데이터를 처리하는 순간,
그 plaintext data를 host, hypervisor, privileged operator가 볼 수 있는가?

따라서 둘은 함께 써야 한다.

Kubernetes hardening
  +
Confidential computing
  +
Secrets management
  +
Supply chain security
  +
Observability

No-code confidential computing의 예상 흐름

No-code-change confidential computing 흐름을 DevOps 관점으로 풀면 다음과 같다.

1. 기존 containerized application 준비
2. sensitive workload 식별
3. confidential computing 지원 runtime/platform 선택
4. application image를 secure runtime에 맞게 packaging
5. Kubernetes/OpenShift에 배포
6. attestation으로 실행 환경 검증
7. 검증된 환경에만 secret/key release
8. protected environment 안에서 application 실행
9. privileged user attack 시 plaintext data 접근 차단

일반적인 배포와 비교하면 다음과 같다.

기존 Kubernetes 배포:
  container image
  ↓
Deployment
  ↓
Pod
  ↓
container runtime
  ↓
application process

Confidential computing 적용:
  container image
  ↓
shielding / confidential runtime packaging
  ↓
Deployment
  ↓
TEE / enclave capable runtime
  ↓
protected application process

Application code는 그대로일 수 있지만, runtime layer와 deployment layer에 confidential computing 설정이 추가된다.

Attestation이 중요한 이유

Confidential computing에서 attestation은 핵심이다.

단순히 “보호된 환경에서 실행 중이다”라고 주장하는 것만으로는 부족하다. 외부의 key manager나 client가 정말 신뢰 가능한 environment인지 확인해야 한다.

Attestation의 mental model은 다음이다.

TEE가 measurement 생성
  ↓
hardware root of trust가 report/signature 제공
  ↓
remote verifier가 report 검증
  ↓
예상한 code와 environment인지 확인
  ↓
검증 성공 시 secret/key release

왜 중요한가?

공격자가 비슷한 이름의 fake environment를 만들 수 있다.
잘못된 image가 실행될 수 있다.
debug mode가 켜진 enclave일 수 있다.
취약한 runtime version일 수 있다.

Attestation은 이런 질문에 답한다.

정말 기대한 code가 실행 중인가?
정말 기대한 hardware-backed TEE 안에서 실행 중인가?
runtime이 변조되지 않았는가?
이 environment에 secret을 줘도 되는가?

Confidential computing에서 key release, secret injection, sensitive data access는 attestation과 연결될 때 의미가 커진다.

Key release와 confidential workload

Confidential computing에서 key management는 매우 중요하다.

Sensitive data를 처리하려면 application이 key나 secret을 가져야 한다. 그런데 그 key를 아무 환경에나 주면 confidential computing 의미가 약해진다.

좋은 흐름은 다음이다.

Application starts in TEE
  ↓
TEE attestation report 생성
  ↓
Key manager가 attestation 검증
  ↓
검증된 workload에만 key release
  ↓
Application이 TEE 내부에서 data decrypt/process

즉 key release 기준이 단순 identity에서 더 나아간다.

기존 방식:
  이 ServiceAccount인가?
  이 IAM role인가?

Confidential computing 방식:
  이 identity인가?
  +
  이 workload가 기대한 TEE에서 실행 중인가?
  +
  이 code measurement가 예상값과 일치하는가?

이것이 Zero Trust 관점과도 잘 맞는다.

Kubernetes에서 confidential workload를 운영하는 구조

Kubernetes 관점에서는 confidential workload를 일반 workload와 분리해 운영하는 것이 자연스럽다.

예시 구조:

Cluster
  ├─ general node pool
  │   ├─ frontend
  │   ├─ public API
  │   └─ batch worker
  │
  └─ confidential node pool
      ├─ payment processor
      ├─ medical data processor
      ├─ key handling service
      └─ sensitive analytics job

Scheduling은 label과 taint/toleration으로 제어할 수 있다.

nodeSelector:
  workload-type: confidential

또는 다음처럼 toleration을 사용할 수 있다.

tolerations:
  - key: "confidential"
    operator: "Equal"
    value: "true"
    effect: "NoSchedule"

운영자는 다음을 분리해야 한다.

일반 workload
  → standard node pool

민감 workload
  → confidential computing 지원 node pool / runtime

관리 plane
  → 최소 권한

secret/key release
  → attestation 기반

어떤 workload가 confidential computing에 적합한가?

모든 application을 confidential computing으로 감쌀 필요는 없다.

적합한 workload는 다음과 같다.

개인정보 처리
금융 transaction 처리
의료 데이터 처리
암호화 key 처리
AI model inference 중 민감한 input 처리
multi-party data collaboration
regulated data processing
high-value business logic
digital asset custody
fraud detection pipeline

특히 다음 조건이 있으면 confidential computing을 검토할 만하다.

cloud provider나 infrastructure operator까지 완전히 신뢰하기 어렵다.
privileged admin threat를 줄이고 싶다.
data in use 보호가 compliance 요구사항과 연결된다.
민감 데이터가 memory에서 처리된다.
고객에게 stronger isolation guarantee를 제공해야 한다.

반대로 다음 workload에는 과할 수 있다.

public static web serving
민감 데이터가 거의 없는 stateless frontend
단순 CRUD admin tool
내부 개발용 low-risk service
latency가 극도로 민감하지만 confidential runtime 검증이 안 된 workload

Confidential computing이 막아주는 것과 못 막는 것

Confidential computing은 강력하지만 모든 보안을 해결하지 않는다.

줄여줄 수 있는 위험

privileged infrastructure operator의 memory 접근
host-level inspection
일부 runtime introspection
memory dump 기반 data exposure
cloud provider 내부자 위협 일부
다른 tenant나 host component로부터의 data in use 노출

자동으로 해결하지 못하는 것

application 자체의 SQL injection
잘못된 authorization logic
API token 탈취
취약한 dependency
malicious container image
supply chain compromise
secret을 log에 출력하는 문제
plaintext를 TEE 밖으로 전송하는 문제
잘못된 network policy
과도한 RBAC 권한
client-side data leakage
side-channel attack 전체

즉 confidential computing은 보안 layer 중 하나다.

Confidential computing
  ≠ complete security

Confidential computing
  = data in use 보호와 privileged infrastructure trust 축소

No-code approach의 장점

No-code-change 방식의 가장 큰 장점은 adoption barrier를 낮춘다는 것이다.

기존 confidential computing은 개발자가 enclave programming model을 직접 이해해야 하는 경우가 많았다.

application refactoring
enclave SDK 학습
trusted/untrusted partitioning
syscall 제한 대응
memory 제한 대응
special build pipeline

No-code-change approach는 이 부담을 줄인다.

장점:

기존 application code를 유지할 수 있다.
migration 비용이 낮다.
DevOps workflow에 통합하기 쉽다.
Kubernetes container 전략과 맞추기 쉽다.
기존 microservices 중 민감 service만 선택적으로 보호할 수 있다.
team이 enclave programming을 깊게 몰라도 시작할 수 있다.

No-code approach의 한계

No-code-change는 편리하지만 trade-off가 있다.

모든 workload가 자동으로 잘 동작하지 않을 수 있다.
특정 system call, runtime behavior, memory pattern에 제약이 있을 수 있다.
debugging이 어려워질 수 있다.
performance overhead가 생길 수 있다.
observability 방식이 제한될 수 있다.
hardware 지원 node가 필요할 수 있다.
attestation/key release workflow가 추가된다.
CI/CD packaging이 바뀔 수 있다.

또한 code를 바꾸지 않는다고 해서 architecture 검토가 필요 없는 것은 아니다.

sensitive data가 TEE 밖으로 log에 남는가?
application이 외부 service로 plaintext를 보내는가?
secret이 환경변수로 과도하게 노출되는가?
debug endpoint가 열려 있는가?
admin API가 과도한 권한을 갖는가?

No-code approach는 “쉽게 시작하게 해주는 방법”이지, security design을 대체하지 않는다.

Kubernetes 보안과 함께 적용해야 할 것

Confidential computing을 적용하더라도 Kubernetes security baseline은 필요하다.

RBAC 최소 권한

cluster-admin 남용 금지
namespace별 권한 분리
ServiceAccount별 최소 권한
CI/CD deploy 권한 제한

확인 명령:

kubectl auth can-i create pods
kubectl auth can-i get secrets -n production

Pod Security

privileged container 금지
hostPath 제한
hostNetwork 제한
runAsNonRoot
allowPrivilegeEscalation: false
readOnlyRootFilesystem
capabilities drop

예시:

securityContext:
  runAsNonRoot: true
  allowPrivilegeEscalation: false
  readOnlyRootFilesystem: true
  capabilities:
    drop:
      - ALL

NetworkPolicy

sensitive workload로 들어오는 traffic 제한
sensitive workload에서 나가는 egress 제한
broker/db/key manager 접근만 허용

Image security

image scanning
image signing
trusted registry
SBOM
admission policy

Secret management

Kubernetes Secret plain 사용 최소화
external secret manager
KMS/HSM
attestation 기반 key release
rotation
least privilege

Confidential computing은 이 보안 baseline 위에 올라가는 추가 layer로 보는 것이 맞다.

DevOps workflow에서의 위치

No-code confidential computing을 DevOps workflow에 넣으면 다음처럼 된다.

Source code
  ↓
CI test
  ↓
container image build
  ↓
image scan / sign
  ↓
confidential packaging or shielding step
  ↓
registry push
  ↓
Kubernetes manifest / Helm values update
  ↓
deploy to confidential node pool
  ↓
attestation / key release
  ↓
runtime monitoring

중요한 검증 포인트:

shielded image가 올바르게 생성되었는가?
attestation policy가 기대한 measurement를 검증하는가?
key release가 검증된 workload에만 일어나는가?
Pod가 confidential node에 scheduling되는가?
fallback으로 일반 node에 뜨지 않는가?
debug mode가 꺼져 있는가?
log에 민감정보가 남지 않는가?

운영 관점에서 확인해야 할 체크리스트

Confidential workload를 Kubernetes에서 운영한다면 다음을 확인해야 한다.

Confidential computing 지원 hardware/node pool인가?
Pod가 confidential node에만 배치되는가?
일반 node로 fallback되지 않는가?
attestation policy가 설정되어 있는가?
key release가 attestation에 묶여 있는가?
Secret이 TEE 밖에 plaintext로 남지 않는가?
container image가 scan/sign 되었는가?
runtime debug 권한이 제한되어 있는가?
log와 trace에 민감정보가 남지 않는가?
NetworkPolicy로 접근 범위가 제한되는가?
RBAC가 최소 권한인가?
node admin과 application owner의 책임 경계가 명확한가?
성능 overhead를 측정했는가?
장애 시 fallback 정책이 있는가?

특히 중요한 질문은 이것이다.

이 workload가 정말 TEE 안에서 실행되고 있음을 어떻게 증명할 것인가?

답은 attestation이다.

Observability와 debugging의 trade-off

Confidential computing은 보안을 강화하지만, 운영 가시성에는 trade-off가 생길 수 있다.

기존 debugging 방식:

process inspect
memory dump
runtime attach
filesystem inspection
container exec
debug sidecar

Confidential computing 환경에서는 이런 방식이 제한될 수 있다.

좋은 점:

privileged user가 민감 data를 들여다보기 어려워진다.

어려운 점:

운영자도 문제를 직접 들여다보기 어렵다.

따라서 application은 처음부터 안전한 observability를 갖춰야 한다.

structured logging
민감정보 masking
correlation ID
metrics
health endpoint
audit log
distributed tracing
secure debug mode

Confidential workload에서는 “운영자가 나중에 들어가서 보면 된다”는 접근이 위험하다. 미리 안전한 관측 지점을 설계해야 한다.

성능과 resource 고려사항

Confidential computing은 hardware protection을 사용하기 때문에 workload 특성에 따라 overhead가 있을 수 있다.

확인할 것:

startup time
memory overhead
CPU overhead
I/O overhead
network throughput
latency p95 / p99
enclave memory limit
container image size
attestation latency
key release latency

성능 검증은 일반 benchmark보다 실제 workload 기준으로 해야 한다.

실제 request pattern
실제 payload size
실제 concurrency
실제 dependency
실제 encryption/decryption path
실제 peak traffic

즉 confidential computing 적용 전후로 다음을 비교해야 한다.

baseline deployment
  vs
confidential deployment

비교 metric:
  p50 latency
  p95 latency
  p99 latency
  throughput
  CPU usage
  memory usage
  error rate
  startup time

Zero Trust 관점에서의 의미

Confidential computing은 Zero Trust와 잘 맞는다.

Zero Trust는 기본적으로 다음 전제를 둔다.

network 내부라고 신뢰하지 않는다.
operator라고 무조건 신뢰하지 않는다.
identity와 context를 계속 검증한다.
least privilege를 적용한다.

Confidential computing은 여기에 다음을 추가한다.

runtime environment도 검증한다.
hardware-backed attestation으로 실행 환경을 확인한다.
검증된 workload에만 key를 준다.
privileged infrastructure actor의 trust를 줄인다.

즉 접근 모델이 다음처럼 바뀐다.

기존:
  이 사용자가 권한이 있는가?

강화된 모델:
  이 사용자가 권한이 있는가?
  이 workload가 기대한 code인가?
  이 workload가 기대한 TEE에서 실행 중인가?
  이 runtime state가 attested 되었는가?

Cloud native와 confidential computing의 연결

Cloud native는 container, Kubernetes, CI/CD, microservices, observability를 기반으로 빠르게 배포하고 확장하는 구조다.

Confidential computing은 여기에 보안 경계를 추가한다.

Cloud native:
  빠른 배포
  자동 확장
  declarative operation
  microservices
  Kubernetes runtime

Confidential computing:
  data in use 보호
  runtime isolation
  attestation
  privileged actor trust 축소

둘을 결합하면 다음 구조가 된다.

Cloud Native Confidential Workload
  =
  containerized application
  +
  Kubernetes orchestration
  +
  hardware-backed TEE
  +
  attestation-based key release
  +
  DevSecOps pipeline

적용 시 구분 기준

Confidential computing은 모든 workload에 무조건 적용하는 기술이 아니다. 적용 여부는 risk와 cost를 기준으로 판단해야 한다.

질문	판단 기준
민감한 data in use가 있는가?	개인정보, 금융, 의료, key material, 민감한 AI input
privileged operator를 완전히 신뢰하기 어려운가?	cloud infra, outsourced operation, multi-tenant 환경
application code 변경이 어려운가?	legacy app, packaged app, migration 비용 큼
performance overhead를 감당할 수 있는가?	p95/p99 latency와 throughput 검증 필요
attestation 기반 key release가 필요한가?	key manager와 policy integration 필요
debugging/observability 제한을 감당할 수 있는가?	structured logging과 metrics 선설계 필요

적합한 경우:

민감 데이터 처리 + cloud native 운영 + privileged threat 감소 필요

부적합할 수 있는 경우:

민감 데이터가 거의 없음
성능 overhead를 감당하기 어려움
observability와 debugging 대안이 없음
hardware 지원 환경이 없음

전체 mental model

No-code confidential computing을 이해하는 흐름은 다음과 같다.

1. 기존 보안은 data at rest와 data in transit을 주로 보호했다.

2. 하지만 application이 데이터를 처리하는 순간,
   data는 memory에서 plaintext 형태로 존재할 수 있다.

3. 이 data in use는 privileged user, compromised host, infrastructure operator,
   runtime inspection 같은 threat에 노출될 수 있다.

4. Confidential computing은 hardware-based attested TEE를 사용해
   data in use와 application code를 보호하려는 접근이다.

5. Kubernetes container 환경에서는 privileged user attack과 node/runtime 접근이
   민감 workload에 대한 위협이 될 수 있다.

6. No-code-change 접근은 existing containerized application의 source code를 바꾸지 않고도
   confidential computing 보호를 적용하려는 방식이다.

7. No code change는 application logic을 바꾸지 않는다는 뜻이지,
   deployment/runtime/security configuration이 전혀 바뀌지 않는다는 뜻은 아니다.

8. Attestation은 key manager나 verifier가 workload가 정말 기대한 TEE에서
   실행 중인지 확인하는 핵심 절차다.

9. Confidential computing은 RBAC, NetworkPolicy, Pod Security, image scanning,
   Secret management를 대체하지 않고 보완한다.

10. 운영에서는 performance, debugging, observability, hardware support,
    CI/CD integration, key release policy를 함께 설계해야 한다.

요약

No-code-change confidential computing은 기존 Kubernetes/container application을 크게 다시 작성하지 않고도 confidential computing protection을 적용하는 접근이다.

핵심은 다음이다.

기존 보호:
  data at rest
  data in transit

추가로 필요한 보호:
  data in use

해결 방향:
  hardware-based attested TEE
  secure enclave
  attestation
  key release policy
  no-code-change container protection

이 접근은 application source code 변경 부담을 줄이면서, Kubernetes 환경에서 privileged user attack과 data in use 노출 위험을 줄이는 데 도움을 줄 수 있다.

하지만 이것은 완전한 보안 솔루션이 아니다. RBAC, NetworkPolicy, Pod Security, image signing/scanning, secret management, supply chain security, observability와 함께 적용해야 한다.

한 문장으로 정리하면 다음과 같다.