Container Service for Kubernetes：Amankan lingkungan kontainer rahasia dengan remote attestation

Kasus penggunaan 1: Verifikasi lingkungan sebelum peluncuran

Proses ini dirancang untuk administrator kluster guna memastikan bahwa Pod hanya diluncurkan di lingkungan rahasia yang autentik dan tepercaya. Seluruh alur kerja diotomatiskan dan tidak memerlukan intervensi manual.

1. Mulai penerapan: Seorang administrator membuat workload dengan mengirimkan manifes Pod ke server API kluster. kubelet pada node kemudian meminta pembuatan sandbox Pod dari containerd melalui Container Runtime Interface (CRI). containerd memeriksa runtimeClassName Pod dan memanggil runtime Kata Remote yang mendasarinya, yaitu kata-runtime.

2. Buat VM rahasia: Kata Remote merespons permintaan tersebut dengan memanggil Alibaba Cloud OpenAPI untuk meluncurkan ECS TDX confidential VM yang ringan dan terisolasi perangkat keras, yang berfungsi sebagai Pod Kubernetes.

3. Remote attestation wajib: Sebelum citra ditarik, Attestation Agent di dalam VM secara otomatis menghasilkan bukti lingkungan runtime, termasuk tanda tangan perangkat keras, lalu mengirimkannya ke layanan Trustee untuk verifikasi.

4. Validasi dan eksekusi workload: Hanya setelah Trustee mengonfirmasi bahwa bukti tersebut valid, logika kontrol guest akan melanjutkan operasi berikutnya, termasuk menarik gambar aplikasi dan menjalankan kontainer.

Kasus penggunaan 2: Remote attestation saat runtime

Kemampuan ini ditujukan untuk aplikasi kontainer yang sedang berjalan, memungkinkannya membuktikan secara proaktif keamanan lingkungannya sendiri kepada layanan eksternal, sehingga membangun rantai kepercayaan lintas sistem.

1. Aplikasi mengambil bukti: Aplikasi di dalam kontainer meminta laporan remote attestation real-time dengan memanggil operasi API lokal di http://127.0.0.1:8006/aa/evidence.

2. Verifikasi oleh layanan eksternal: Aplikasi mengirim bukti ini ke layanan eksternal (konsumen). Konsumen layanan tersebut kemudian meneruskan bukti ke layanan Trustee tepercayanya sendiri untuk divalidasi. Validasi yang berhasil membuktikan bahwa pihak yang berkomunikasi berjalan di lingkungan rahasia yang dilindungi, sehingga membangun kepercayaan secara dinamis.

1. Konfigurasikan Trustee

Di server Trustee, konfigurasikan kebijakan untuk menentukan karakteristik lingkungan mana yang dianggap tepercaya.

1. Konfigurasikan kebijakan peluncuran keamanan kontainer.

   File kebijakan ini diperlakukan sebagai resource rahasia dan dibaca selama proses startup Pod TDX untuk memicu alur remote attestation.

   # Buat direktori untuk menyimpan kebijakan
   mkdir -p /opt/trustee/kbs/repository/default/container-policy
   
   # Buat file kebijakan yang mengizinkan semua citra (hanya untuk demo)
   cat << EOF > /opt/trustee/kbs/repository/default/container-policy/insecure-accept-all
   {
       "default": [{"type": "insecureAcceptAnything"}],
       "transports": {}
   }
   EOF

2. Konfigurasikan kebijakan remote attestation.

   Kebijakan ini menetapkan standar spesifik untuk lingkungan perangkat keras dan perangkat lunak tepercaya. Misalnya, kebijakan ini dapat mensyaratkan lingkungan berjalan di platform Intel TDX.

   # Ubah file kebijakan /opt/trustee/attestation-service/policies/opa/default.rego
   # Ganti isinya dengan kebijakan remote attestation untuk ECS TDX PeerPods
   cat << EOF > /opt/trustee/attestation-service/policies/opa/default.rego
   package policy
   
   import rego.v1
   
   default executables := 32
   default hardware := 97
   default configuration := 32
   default file_system := 32
   
   ##### ECS TDX PeerPod
   executables := 3 if {
   	input.tdx
   }
   
   hardware := 2 if {
   	# Verifikasi bahwa bukti bertipe Intel TDX
   	input.tdx.quote.header.tee_type == "81000000"
   	# Verifikasi vendor ID
   	input.tdx.quote.header.vendor_id == "939a7233f79c4ca9940a0db3957f0607"
   }
   
   configuration := 2 if {
   	input.tdx
   }
   
   file_system := 2 if {
   	input.tdx
   }
   EOF

3. Restart layanan Trustee untuk menerapkan kebijakan.

   service as restart

2. Deploy Pod dengan remote attestation diaktifkan

1. Persiapkan initdata dan deploy Pod.

   initdata digunakan untuk meneruskan informasi konfigurasi ke PeerPod, termasuk alamat layanan Trustee.

   # Ganti dengan alamat IP Trustee yang sebenarnya
   TRUSTEE_SERVICE_ENDPOINT=1.2.3.4
   
   # Hasilkan file initdata.toml
   cat <<EOF > initdata.toml
   version = "0.1.0"
   algorithm = "sha256"
   [data]
   "aa.toml" = '''
   [eventlog_config]
   enable_eventlog = true
   [token_configs]
   [token_configs.kbs]
   url = "http://${TRUSTEE_SERVICE_ENDPOINT}:8080"
   '''
   "cdh.toml" = '''
   [kbc]
   name = "cc_kbc"
   url = "http://${TRUSTEE_SERVICE_ENDPOINT}:8080"
   [image]
   image_security_policy_uri = "kbs:///default/container-policy/insecure-accept-all"
   '''
   EOF
   
   # Kompres initdata dengan gzip dan encode dengan Base64
   initdata=$(cat initdata.toml | gzip | base64 -w0)

   Jalankan echo $initdata untuk melihat konten terencode dari initdata.

2. Buat file YAML Pod.

   Tuliskan string initdata yang dihasilkan pada langkah sebelumnya ke bidang annotations metadata Pod.

   # Buat file bernama pod.yaml
   cat << EOF > pod.yaml
   apiVersion: v1
   kind: Pod
   metadata:
     name: pod-caa-demo
     annotations:
       io.katacontainers.config.hypervisor.cc_init_data: ${initdata}
   spec:
     runtimeClassName: kata-remote
     containers:
       - image: alibaba-cloud-linux-3-registry.cn-hangzhou.cr.aliyuncs.com/alinux3/alinux3:latest
         name: hello
         command: ["sh", "-c", "echo hello && sleep infinity"]
   EOF

3. Deploy Pod.

   kubectl apply -f pod.yaml

   Setelah penerapan, jalankan kubectl get po pod-caa-demo untuk memeriksa status Pod.

4. Verifikasi status remote attestation di server Trustee.

   Periksa log layanan remote attestation untuk memastikan validasi lingkungan berhasil.

   journalctl -u as -f 

   Jika Anda melihat pesan Tdx Verifier/endorsement check passed di log, hal ini menunjukkan bahwa remote attestation berhasil dan Pod telah dimulai di lingkungan tepercaya.

1. Dapatkan bukti remote attestation dari dalam kontainer

curl 127.0.0.1:8006/aa/evidence?runtime_data=AAAA

2. Persiapkan lingkungan verifikasi

Proses verifikasi bergantung pada instans Trustee independen dan tepercaya.

1. (Opsional) Jalankan yum install trustee -y untuk menginstal Trustee di server verifier Anda.

2. Konfigurasikan kebijakan validasi sisi klien.

   Di node verifier, buat file kebijakan baru /opt/trustee/attestation-service/policies/opa/client.rego di layanan Trustee.

   # Buat file client.rego dengan isi berikut
   cat <<EOF > /opt/trustee/attestation-service/policies/opa/client.rego
   
   # Kebijakan untuk memverifikasi bukti yang diperoleh dari kontainer rahasia (TEE)
   package policy
   import rego.v1
   
   # --- Skor default ---
   default executables := 32
   default hardware := 97
   default configuration := 32
   default file_system := 32
   
   # --- Aturan validasi untuk Alibaba Cloud ECS TDX PeerPods ---
   # Contoh: skor 2 = "tepercaya", 3 = "menegaskan"
   # Jika bukti input berisi bidang "tdx", tumpukan perangkat lunak dianggap "menegaskan"
   executables := 3 if {
       input.tdx
   }
   
   # Aturan penilaian perangkat keras: Jika kedua kondisi berikut terpenuhi, lingkungan perangkat keras dinilai "tepercaya" (skor 2).
   hardware := 2 if {
       # Periksa bidang tipe TEE. Harus berupa identifikasi Intel TDX "81000000"
       input.tdx.quote.header.tee_type == "81000000"
   
       # Periksa bidang vendor ID. Harus berupa UUID resmi Intel
       input.tdx.quote.header.vendor_id == "939a7233f79c4ca9940a0db3957f0607"
   }
   
   # Jika input berupa bukti TDX, konfigurasinya dianggap "tepercaya".
   configuration := 2 if {
       input.tdx
   }
   
   # Jika input berupa bukti TDX, sistem filenya dianggap "tepercaya".
   file_system := 2 if {
       input.tdx
   }
   EOF

3. Restart Trustee untuk menerapkan kebijakan client.rego.

   service as-restful restart

3. Persiapkan dan kirim permintaan verifikasi

Kirimkan bukti yang diperoleh dari kontainer ke layanan verifikasi.

1. (Disarankan) Simpan bukti asli secara aman.

   Untuk menghindari kesalahan akibat karakter khusus, kami sarankan Anda menyimpan bukti ke file.

   # Buat file sementara bernama evidence.json
   cat > evidence.json

   Setelah menjalankan perintah, tempelkan string JSON lengkap tersebut. Lalu, simpan file dan keluar dari mode edit.

2. Baca bukti dari file dan persiapkan permintaan.

   # Baca konten dari file ke variabel
   EVIDENCE=$(cat evidence.json)
   
   # Encode bukti dengan Base64 dan buat agar aman untuk URL
   BASE64EVIDENCE=$(echo ${EVIDENCE} | base64 -w 0 2>/dev/null | tr '+/' '-_' | tr -d '=' )
   
   # Buat file badan permintaan yang berisi bukti terencode
   cat << EOF > request.json
   {
       "verification_requests": [
           {
               "tee": "tdx",
               "evidence": "${BASE64EVIDENCE}"
           }
       ],
       "policy_ids": ["client"]
   }
   EOF

3. Kirim permintaan verifikasi.
   Kirim permintaan POST ke titik akhir /attestation layanan verifikasi lokal Anda pada port default 50005.

   curl -k -X POST http://127.0.0.1:50005/attestation \     -i \     -H 'Content-Type: application/json' \     -d @request.json

   Badan respons akan berisi bidang token, yang merupakan string JWT. Ini adalah token verifikasi Anda. Salin token tersebut.

4. Uraikan dan evaluasi hasil verifikasi

Uraikan token JWT untuk mengambil skor keandalan setiap sub-status lingkungan saat ini.

1. Simpan token verifikasi.

   # Ganti '<...>' dengan string JWT yang sebenarnya (tanpa tanda kutip)
   TOKEN='<Paste the JWT token here>'

2. Uraikan token dan lihat skornya.

   echo $TOKEN | cut -d'.' -f2 | base64 -d |  jq '.submods.cpu0."ear.trustworthiness-vector"'

   Output yang diharapkan:

   base64: invalid input
   {
     "configuration": 2,
     "executables": 3,
     "file-system": 2,
     "hardware": 2
   }

   • Pesan base64: invalid input dapat diabaikan dengan aman.

   • Konten JSON menunjukkan hasil verifikasi. Skor-skor tersebut sesuai dengan nilai yang ditentukan dalam file kebijakan Anda, yang mengonfirmasi bahwa kontainer berjalan di lingkungan TDX yang sesuai dan tepercaya. Verifikasi berhasil.