Triển Khi Confidential Compute Workload trên AWS EKS với AMD SEV-SNP, Kata Containers và Quản Lý Khóa Trustee

Trong các ngành công nghiệp tuân thủ quy định nghiêm ngặt như y tế, giao dịch thuật toán tài chính và quốc phòng, hạ tầng điện toán đám mây đa người dùng (multi-tenant) luôn tiềm ẩn những nguy cơ bảo mật. Các cơ chế bảo mật Kubernetes truyền thống như Linux namespaces, cgroups, AppArmor hay NetworkPolicies không thể bảo vệ dữ liệu đang xử lý trong bộ nhớ (data-in-use) nếu hệ điều hành host, hypervisor hoặc hạ tầng nhà cung cấp cloud bị xâm nhập.

Confidential Compute (Điện toán bảo mật) giải quyết bài toán này bằng cách mở rộng mã hóa từ dữ liệu lưu trữ (data-at-rest) và dữ liệu truyền tải (data-in-transit) sang dữ liệu đang xử lý (data-in-use). Bằng cách kết hợp Môi trường thực thi tin cậy dựa trên phần cứng (Hardware-rooted Trusted Execution Environments - TEEs) như AMD SEV-SNP (Secure Encrypted Virtualization-Secure Nested Paging) cùng lightweight hypervisors (Kata Containers) và kiến trúc xác thực từ xa (Trustee/Key Broker Service), doanh nghiệp có thể chạy các ứng dụng nhạy cảm trên đám mây với sự đảm bảo tuyệt đối về mặt mật mã học.

1. Mô Hình Hiểm Họa (Threat Model) & Kiến Trúc Nền Tảng

Mục tiêu cốt lõi của cụm Confidential Kubernetes là loại bỏ OS của node host, quản trị viên hypervisor AWS và các workload của các người dùng khác khỏi Vùng tin cậy điện toán (Trusted Computing Base - TCB). Mô hình hiểm họa này giả định rằng kernel của EKS worker node có thể bị độc hại hoàn toàn.

AMD SEV-SNP cung cấp cơ chế mã hóa bộ nhớ thông qua các khóa mã hóa phần cứng AES do bộ xử lý bảo mật AMD (AMD Secure Processor - AMD-SP) tạo ra cho từng máy ảo guest. Nó ngăn chặn các cuộc tấn công ở cấp độ hypervisor như đọc bộ nhớ, chèn bộ nhớ, hủy hoại trạng thái và tấn công phát lại (replay attacks) nhờ cơ chế bảo vệ phân trang lồng nhau (nested paging).

Để hiện thực hóa khả năng bảo vệ phần cứng này trên Kubernetes, chúng ta kết hợp 3 thành phần chính:

• Phần cứng AMD SEV-SNP: Các loại EC2 Instance AWS Nitro (ví dụ: dòng m7a hoặc c6a hỗ trợ SEV-SNP) hỗ trợ mã hóa bộ nhớ bằng phần cứng.
• Kata Containers (CoCo / Confidential Containers): Container runtime khởi tạo các MicroVM mỏng nhẹ bằng QEMU/cloud-hypervisor thay vì dùng chung kernel như container tiêu chuẩn.
• Trustee (Key Broker Service / Attestation Service): Bộ giải pháp thuộc CNCF quản lý quy trình xác thực hardware attestation, so sánh chỉ số đo lường khởi động (launch measurements) với giá trị chuẩn và chỉ giải phóng khóa mã hóa khi tính toàn vẹn được chứng minh.

2. Khởi Tạo Hạ Tầng AWS EKS Hỗ Trợ AMD SEV-SNP

Để triển khai node group EKS hỗ trợ Confidential Compute phần cứng, chúng ta cần sử dụng đúng loại AMD EC2 Instance, build AMI tùy chỉnh đã bật các module KVM và SEV-SNP, cùng cấu hình Nitro Guest OS.

Dưới đây là file Terraform chuẩn production khởi tạo Node Group EKS với instance AMD SEV-SNP và Custom Launch Template:

# main.tf - Cấu hình EKS Confidential Node Group
resource "aws_launch_template" "eks_sev_snp_template" {
  name_prefix   = "eks-sev-snp-"
  image_id      = var.custom_sev_snp_ami_id # Ubuntu 22.04 / AL2023 tùy chỉnh đã cài driver SEV-SNP
  instance_type = "m7a.2xlarge"             # AMD EPYC Gen 4 hỗ trợ SEV-SNP

  cpu_options {
    core_count       = 4
    threads_per_core = 2
  }

  capacity_reservation_specification {
    capacity_reservation_preference = "open"
  }

  metadata_options {
    http_endpoint               = "enabled"
    http_tokens                 = "required" # Bắt buộc IMDSv2
    http_put_response_hop_limit = 1
  }

  user_data = base64encode(<<-EOF
    #!/bin/bash
    set -o errexit
    set -o pipefail

    # Bật module AMD SEV-SNP trên Host Kernel
    modprobe kvm_amd sev=1 sev_snp=1
    echo "options kvm_amd sev=1 sev_snp=1" > /etc/modprobe.d/kvm-amd.conf

    # Bootstrap EKS Node
    /etc/eks/bootstrap.sh ${var.cluster_name} \
      --boto-extra-args '--region ${var.aws_region}' \
      --kubelet-extra-args '--node-labels=workload.topology.kubernetes.io/confidential=true'
  EOF
  )

  tag_specifications {
    resource_type = "instance"
    tags = {
      Name                                   = "eks-confidential-node"
      "confidential-compute.aws/sev-snp"     = "true"
    }
  }
}

resource "aws_eks_node_group" "sev_snp_nodes" {
  cluster_name    = aws_eks_cluster.main.name
  node_group_name = "sev-snp-confidential-workers"
  node_role_arn   = aws_iam_role.node_role.arn
  subnet_ids      = var.private_subnet_ids

  scaling_config {
    desired_size = 2
    max_size     = 10
    min_size     = 1
  }

  launch_template {
    id      = aws_launch_template.eks_sev_snp_template.id
    version = "$Latest"
  }

  labels = {
    "node.kubernetes.io/confidential-runtime" = "kata-coco"
  }
}

3. Cấu Hình Containerd & Runtime Kata Containers (CoCo)

Sau khi khởi tạo node, Containerd phải được cấu hình để chuyển tiếp yêu cầu của workload xuống Kata Containers với tính năng hypervisor SEV-SNP. Runtime `kata-cc` sẽ xây dựng các tham số QEMU tích hợp SEV-SNP.

Đoạn mã sau thể hiện cấu hình `/etc/containerd/config.toml` trên từng confidential node:

# Cấu hình Containerd Runtime cho Kata Confidential Containers
[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.kata-cc]
  runtime_type = "io.containerd.kata-cc.v2"
  privileged_without_host_tokens = false
  
  [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.kata-cc.options]
    ConfigPath = "/opt/kata/share/defaults/kata-containers/configuration-qemu-sev.toml"

# Nội dung tham khảo của configuration-qemu-sev.toml:
# [hypervisor.qemu]
# path = "/opt/kata/bin/qemu-system-x86_64"
# machine_type = "q35"
# machine_accelerators = "sev-snp=on"
# enable_sev = true
# sev_snp = true
# firmware = "/opt/ovmf/OVMF.sev.fd"

Đăng ký RuntimeClass trong cụm Kubernetes:

apiVersion: node.k8s.io/v1
kind: RuntimeClass
metadata:
  name: kata-cc
handler: kata-cc
scheduling:
  nodeSelector:
    node.kubernetes.io/confidential-runtime: "kata-coco"
tolerations:
- key: "confidential-node"
  operator: "Exists"
  effect: "NoSchedule"

4. Kiến Trúc Xác Thực Từ Xa (Remote Attestation) với Trustee (KBS / AS)

Các confidential container không thể nhúng trực tiếp khóa giải mã tĩnh bên trong image layer vì kẻ tấn công có quyền root trên host có thể đọc đĩa trước khi container chạy. Thay vào đó, container image sẽ ở trạng thái mã hóa cho đến khi Guest MicroVM chứng minh được danh tính và trạng thái khởi động thông qua remote attestation.

Quy trình xác thực được thực hiện qua **Trustee Security Framework**:

1. Khởi Động Pod: Kata MicroVM khởi động một Guest OS hợp lệ (đã cài Attestation-Agent) bên trong vùng cách ly phần cứng AMD SEV-SNP.
2. Tạo Hardware Attestation Quote: Kernel bên trong guest gửi yêu cầu lấy một bản báo cáo attestation có chữ ký phần cứng từ chip AMD-SP (`/dev/sev-guest`). Báo cáo này chứa chỉ số đo lường phần cứng (launch digest của BIOS, kernel, initrd, và command-line).
3. Gửi Yêu Cầu Xác Thực: Attestation Agent gửi quote này cùng bản đo lường payload đến **Attestation Service (AS)** của Trustee thông qua **Key Broker Service (KBS)**.
4. Kiểm Tra & Đối Đối: AS xác minh chuỗi chứng chỉ bằng Versioned Chip Endorsement Key (VCEK) của AMD, kiểm tra danh sách chứng chỉ bị thu hồi (CRL), và đánh giá qua policy Open Policy Agent (OPA).
5. Giải Phóng Khóa: Sau khi đánh giá thành công, KBS trả khóa giải mã container hoặc token KMS trực tiếp vào bộ nhớ encrypted VM thông qua kênh TLS kết thúc bên trong TEE.

Dưới đây là policy Open Policy Agent (`policy.rego`) kiểm tra chỉ số khởi động cho workload AMD SEV-SNP:

package policy

default allow = false

# Kiểm tra loại phần cứng TEE là AMD SEV-SNP
default is_sev_snp = false
is_sev_snp {
    input.tee == "sev"
    input.launch_measurement != ""
}

# Các chỉ số Launch Measurement hợp lệ (Digest của firmware, kernel, initrd)
valid_launch_measurements = {
    "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855",
    "f12a84c20b8e404a39d8bc321c11030eef7922d25081f9b34313d5236683f124"
}

# Quy tắc đánh giá Policy
allow {
    is_sev_snp
    valid_launch_measurements[input.launch_measurement]
    input.svn >= 2                 # Kiểm tra Security Version Number
    input.policy_bitmask == "0x30000" # Cấm chế độ Debug
}

5. Triển Khai Pod Bảo Mật Trên EKS

Khi các node EKS và hệ thống Trustee Attestation đã sẵn sàng, chúng ta tiến hành deploy ứng dụng với `runtimeClassName: kata-cc`. Container image được kéo về dưới dạng mã hóa và giải mã trực tiếp trong biên giới bộ nhớ của MicroVM.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: confidential-payment-processor
  namespace: secure-workloads
  labels:
    app.kubernetes.io/name: payment-processor
    security.tier: confidential
spec:
  replicas: 3
  selector:
    matchLabels:
      app: payment-processor
  template:
    metadata:
      labels:
        app: payment-processor
      annotations:
        # Yêu cầu Confidential Data Hub (CDH) lấy Secret từ Trustee KBS
        io.katacontainers.config.hypervisor.machine_type: "q35"
        trustee.confidentialcontainers.org/kbs-endpoint: "https://kbs.trustee.internal:8080"
        trustee.confidentialcontainers.org/secret-resource-path: "kbs:///default/payment-keys/stripe-api-key"
    spec:
      runtimeClassName: kata-cc
      nodeSelector:
        node.kubernetes.io/confidential-runtime: "kata-coco"
      containers:
      - name: processor
        # Container Image được mã hóa bằng ocicrypt / Skopeo
        image: 123456789012.dkr.ecr.us-east-1.amazonaws.com/finance/payment-processor:v1.2.0-encrypted
        imagePullPolicy: Always
        resources:
          limits:
            cpu: "2"
            memory: "4Gi"
          requests:
            cpu: "1"
            memory: "2Gi"
        env:
        - name: STRIPE_API_KEY
          valueFrom:
            secretKeyRef:
              name: trustee-injected-stripe-key
              key: key
        securityContext:
          allowPrivilegeEscalation: false
          readOnlyRootFilesystem: true
          runAsNonRoot: true
          runAsUser: 10001
          capabilities:
            drop:
            - ALL

6. Tối Ưu Vận Hành, Hiệu Năng & Governance

Vận hành các ứng dụng SEV-SNP Confidential Compute ở quy mô lớn đòi hỏi sự cân bằng giữa bảo mật và hiệu năng:

Bằng cách triển khai mô hình bảo mật Zero-Trust đa lớp—kết hợp mã hóa bộ nhớ phần cứng AMD SEV-SNP, sự cô lập của Kata MicroVM và cơ chế Remote Attestation từ Trustee—doanh nghiệp có thể đảm bảo an toàn tuyệt đối cho dữ liệu nhạy cảm nhất ngay trên EKS public cloud.