Belajar Kata Containers - Secure Boot & Image Trust

#Pendahuluan

Dua episode terakhir menjaga runtime (microVM) dan jaringan. Episode 15 menjaga sesuatu yang lebih mendasar: dari mana code yang berjalan itu berasal? MicroVM yang paling aman sekalipun tidak berharga jika guest kernel-nya adalah image yang dirusak, atau container image yang di-pull berasal dari sumber yang tidak terpercaya.

Episode ini membahas dua sisi supply chain: secure boot — memastikan guest kernel yang boot adalah yang seharusnya, dan image trust — memastikan container image yang dijalankan ditandatangani, terdokumentasi (SBOM), dan lolos policy admission.

#Secure Boot untuk Guest Kernel

#Konsep Verifikasi Signature

Secure boot berarti: sebelum guest kernel dieksekusi, signature-nya diverifikasi. Hanya kernel yang ditandatangani dengan kunci tepercaya yang boleh di-boot. Ini mencegah serangan di mana attacker mengganti file kernel guest dengan versi berbahaya — misalnya lewat akses ke filesystem node.

Di Kata, guest kernel dan guest image bisa ditandatangani. Verifikasi dilakukan sebelum boot, sehingga microVM tidak pernah mengeksekusi binary yang tidak terautentikasi.

#Konfigurasi di Kata

Kata menyediakan opsi terkait secure boot di file konfigurasi:

/etc/kata-containers/configuration.toml

[hypervisor.qemu]
# Enable secure boot for the guest
enable_secure_boot = true

enable_secure_boot = true mengaktifkan secure boot pada guest. Dengan fitur ini aktif, boot akan gagal jika image guest tidak memiliki signature yang valid — sebuah kegagalan yang lebih baik daripada menjalankan image yang dicurigai.

Perlu dicatat: secure boot bukan pengganti untuk semua kontrol supply chain. Ia menjaga guest image Kata. Image aplikasi di dalam guest tetap harus dijaga dengan mekanisme image trust di bawah.

#Image Signing dan Attestation

#Image Signing

Container image harus ditandatangani sebelum dijalankan. Signing memastikan image berasal dari sumber yang benar dan tidak diubah selama transit. Tools umumnya: cosign (Sigstore) dan Notary. Dengan signing, pihak yang menjalankan image bisa memverifikasi siapa yang menerbitkannya.

Alur singkat signing dengan cosign:

cosign sign ghcr.io/perusahaan/image:1.0.0
cosign verify --key cosign.pub ghcr.io/perusahaan/image:1.0.0

cosign sign menambahkan signature ke image, dan cosign verify memverifikasi signature tersebut dengan kunci publik. Di lingkungan production, verifikasi ini dilakukan otomatis sebelum image dijalankan — lewat admission controller di bawah.

#Image Attestation

Attestation melangkah lebih jauh dari signing: bukan hanya "siapa yang menerbitkan", tapi "apa isi image". Attestation membawa klaim terverifikasi — misalnya SBOM image, hasil scan vulnerability, atau provenance build (dari CI mana image dibangun). Sigstore menyebutnya provenance; mekanisme umum lainnya adalah in-toto attestation.

Dari episode 11, kalian sudah mengenal attestation untuk confidential computing. Prinsipnya sama di sini: sebelum trust, buktikan dulu.

#SBOM: Inventori Perangkat Lunak

SBOM (Software Bill of Materials) adalah inventori lengkap komponen software dalam sebuah image — setiap paket, library, dan versinya. Mengapa penting untuk workload Kata? Karena microVM menambah komponen sistem (guest kernel, agent, hypervisor) di atas image aplikasi. Untuk audit penuh, SBOM harus mencakup keduanya.

Buat dan simpan SBOM sebagai artefak yang bisa di-audit:

syft ghcr.io/perusahaan/image:1.0.0 -o spdx-json > sbom.json

syft ... -o spdx-json > sbom.json menghasilkan SBOM dalam format SPDX. Simpan SBOM ini bersama image di registry — sehingga saat insiden terjadi, kalian bisa menjawab "paket mana yang terlibat" dalam hitungan menit, bukan hari.

#Policy Admission dengan Kyverno/OPA

#Mengapa Admission Policy

Signing dan SBOM tidak berguna jika tidak ditegakkan. Admission controller berada di jalur pembuatan pod: setiap permintaan membuat pod diverifikasi dulu terhadap policy. Jika image tidak ditandatangani, pod ditolak — tidak ada jalan pintas.

Dua tool yang umum dipakai: Kyverno (policy berbasis YAML, Kubernetes-native) dan OPA/Gatekeeper (Rego, general purpose). Keduanya bekerja dengan pod Kata seperti pod biasa.

#Contoh Policy Kyverno

Policy sederhana: hanya image yang ditandatangani yang boleh berjalan:

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-image-signature
spec:
  validationFailureAction: Enforce
  rules:
    - name: check-cosign
      match:
        any:
          - resources:
              kinds:
                - Pod
      verifyImages:
        - imageReferences:
            - "ghcr.io/perusahaan/*"
          attestors:
            - count: 1
              entries:
                - keys:
                    publicKeys: |-
                      -----BEGIN PUBLIC KEY-----
                      ...
                      -----END PUBLIC KEY-----

validationFailureAction: Enforce membuat policy menolak pod yang melanggar. verifyImages memeriksa bahwa image punya signature dari attestor yang tepercaya sebelum pod diizinkan. Pod Kata tidak terkecuali — policy ini berlaku untuk semua pod, termasuk yang memakai RuntimeClass kata.

#Policy Spesifik untuk Workload Kata

Kalian juga bisa membuat policy yang mensyaratkan RuntimeClass tertentu untuk workload untrusted. Misalnya: pod dari namespace sandbox wajib memakai runtimeClassName: kata — sehingga tidak ada workload untrusted yang diam-diam berjalan di runc:

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-kata-for-untrusted
spec:
  validationFailureAction: Enforce
  rules:
    - name: sandbox-must-use-kata
      match:
        any:
          - resources:
              kinds:
                - Pod
      preconditions:
        all:
          - key: "{{ request.object.metadata.namespace }}"
            operator: Equals
            value: sandbox
      validate:
        message: "Workload di namespace sandbox harus memakai runtimeClassName: kata"
        pattern:
          spec:
            runtimeClassName: kata

Policy ini menjamin seluruh workload untrusted di namespace sandbox berjalan di microVM. Dengan admission policy seperti ini, keputusan keamanan bukan lagi bergantung pada ingatan engineer — melainkan ditegakkan sistem.

#Rantai Kepercayaan Menyeluruh

Gabungkan semua lapisan menjadi rantai kepercayaan:

1. Guest kernel diverifikasi dengan secure boot.
2. Container image ditandatangani dan diverifikasi signature-nya.
3. SBOM terdokumentasi untuk audit.
4. Admission policy menegakkan 1-3 di jalur pembuatan pod.
5. RuntimeClass dipilih berdasarkan tingkat kepercayaan workload.

Satu rantai putus, dan trust boundary episode 13 melemah. Membangun semuanya sejak awal jauh lebih murah daripada memperbaiki setelah insiden.

#Penutup

Inti yang harus dibawa pulang:

• Secure boot memverifikasi signature guest kernel sebelum boot.
• Image signing memastikan image dari sumber yang benar dan tidak diubah.
• SBOM adalah inventori komponen yang wajib di-audit.
• Kyverno/OPA menegakkan policy admission di jalur pembuatan pod.
• Policy bisa mewajibkan RuntimeClass kata untuk workload untrusted.
• Rantai kepercayaan: guest kernel → image → SBOM → admission → runtime.

Di episode 16 selanjutnya kita akan membahas multi-tenancy & isolation best practice — satu pod per microVM, resource isolation via VM, pola sandbox, dan praktik memisahkan workload trusted/untrusted di node berbeda dengan monitoring per-VM. Inilah episode yang menyatukan pola-pola isolasi ke dalam desain cluster nyata.