Membuat dan menyesuaikan beban kerja

Workload dibuat oleh penulis workload, dan memproses data rahasia yang ingin digunakan oleh kolaborator data.

Penulis workload perlu menyusun resource berikut untuk membuat workload:

  • Aplikasi untuk memproses data rahasia. Anda dapat menulis aplikasi dalam bahasa apa pun yang Anda pilih, asalkan Anda membangun image container yang mendukungnya.

  • Image container untuk memaketkan aplikasi, menggunakan Docker.

  • Repositori di Artifact Registry untuk menyimpan image Docker.

  • Kebijakan peluncuran yang ditetapkan pada image container yang mengontrol cara workload dapat dijalankan, dan membatasi kemampuan operator workload berbahaya.

Untuk men-deploy workload, Confidential VM dijalankan oleh operator workload berdasarkan image Confidential Space. Tindakan ini akan mengambil image container dari Artifact Registry dan menjalankannya.

Kolaborator data harus memvalidasi pengesahan workload sebelum dapat mengakses data mereka.

Sebelum memulai

Menulis workload untuk Confidential Space tidak hanya melibatkan kode dan proses debug. Anda juga perlu berbicara dengan kolaborator data untuk menilai kebutuhan mereka, menyiapkan lingkungan, mengemas kode ke dalam image container, dan bekerja sama dengan operator workload untuk memastikan semuanya di-deploy dengan benar.

Berdiskusi dengan kolaborator data

Sebelum mulai menulis aplikasi, Anda perlu berdiskusi dengan kolaborator data tentang data pribadi yang ingin Anda kerjakan. Pertanyaan yang dapat Anda ajukan mencakup:

  • Apa saja ID organisasi yang terlibat?

  • Berapa nomor project yang terlibat?

  • Apa saja resource Google Cloud yang perlu saya akses, dan apa ID serta namanya?

  • Apakah ada resource yang perlu saya akses yang tidak dikelola oleh IAM Google Cloud?

  • Layanan pengesahan apa yang ingin Anda gunakan, Google Cloud Attestation atau Intel Trust Authority?

  • Bagaimana seharusnya aplikasi membandingkan dan memproses data pribadi?

  • Dalam format apa output harus ditampilkan?

  • Di mana output harus disimpan, dan apakah harus dienkripsi?

  • Apakah semua kolaborator data melihat hasil yang sama, atau apakah outputnya unik untuk masing-masing kolaborator?

Selain itu, setiap kolaborator data mungkin juga memiliki persyaratan privasi unik yang perlu Anda penuhi. Sangat penting untuk memastikan tidak ada data pribadi yang terekspos sebagai akibat dari workload.

Membangun solusi Confidential Space Anda

Sebaiknya siapkan dua (atau lebih) project dengan izin yang sesuai sebagai lingkungan pengujian, seperti dalam Membuat lingkungan Confidential Space pertama Anda. Cobalah untuk mencerminkan penyiapan project kolaborator data sebaik mungkin. Dengan demikian, Anda dapat memperoleh pengalaman dengan izin lintas project, dan mengambil data yang Anda perlukan dari resource Google Cloud tertentu. Hal ini juga dapat memberi Anda apresiasi terhadap peran operator workload dan kolaborator data serta tanggung jawab mereka.

Selama fase pembuatan awal, sebaiknya amati praktik berikut:

  • Saat bekerja sebagai kolaborator data, pertahankan validasi pengesahan seminimal mungkin demi kecepatan pengembangan.

  • Saat bekerja sebagai operator workload, gunakan image debug Confidential Space, bukan produksi, saat men-deploy workload. Hal ini memberi Anda lebih banyak cara untuk memecahkan masalah workload.

Seiring dengan berkembangnya aplikasi dan statusnya yang makin dapat diprediksi, Anda dapat makin mengunci solusi dengan validasi pengesahan dan kebijakan peluncuran, serta beralih ke image Confidential Space produksi.

Setelah workload berfungsi dengan benar di lingkungan pengujian, Anda dapat beralih ke pengujian di project kolaborator data dengan resource nyata, tetapi data palsu, sehingga Anda dapat menunjukkan kepada kolaborator data cara kerjanya. Pada tahap ini, Anda mungkin mulai bekerja dengan operator workload independen.

Jika semuanya berfungsi dan outputnya sesuai harapan, Anda dapat mulai menguji data produksi. Setelah pengujian selesai dan semua pihak menyetujui hasilnya, workload siap untuk dimasukkan ke dalam produksi.

Berhati-hatilah dengan output

Saat menguji kode, Anda mungkin tergoda untuk melakukan debug dengan mencetak ke STDOUT atau STDERR. Jika Anda memilih untuk melakukannya, berhati-hatilah agar tidak mengekspos data pribadi yang dapat dibaca oleh pihak lain dengan mengakses log. Sebelum kode Anda mulai berfungsi dalam produksi, pastikan kode tersebut tidak menghasilkan output apa pun selain yang benar-benar diperlukan.

Hal yang sama berlaku untuk output akhir. Hanya berikan hasil akhir yang tidak mengorbankan privasi dan sensitivitas data asli.

Membangun image container dengan Docker

Aplikasi perlu dipaketkan ke dalam image container yang dibangun oleh Docker, yang disimpan di Artifact Registry. Saat workload di-deploy, image Docker diambil dari repositori Artifact Registry oleh image Confidential Space, dijalankan, dan aplikasi dapat mulai mengerjakan resource project yang sesuai.

Saat membangun image Docker, pertimbangkan hal-hal berikut:

Kemampuan Linux tambahan

Workload Confidential Space berjalan di container Linux menggunakan containerd. Container ini berjalan menggunakan kemampuan Linux default.

Untuk menambahkan kemampuan, Anda dapat menggunakan tee-added-capabilities.

Batas disk dan memori

Confidential Space secara otomatis mengubah ukuran partisi stateful boot disk saat menggunakan ukuran boot disk yang lebih besar. Ukuran partisi kira-kira sama dengan ukuran boot disk dikurangi 5 GB.

Sebagai bagian dari perlindungan sistem file integritas Confidential Space, Confidential Space menyimpan tag integritas disk dalam memori. Tindakan ini menggunakan overhead memori sekitar 1% untuk setiap byte disk. Misalnya, disk 100 GB memerlukan memori 1 GB dan disk 10 TB memerlukan memori 100 GB.

Pastikan untuk tetap berada dalam batas memori VM. Memori swap dinonaktifkan di VM Confidential Space, yang berarti penggunaan memori yang berlebihan dapat membuat workload error. Pastikan pilihan mesin Anda mendukung penggunaan memori workload selain overhead integritas disk.

Penghentian normal

Saat operator meminta penonaktifan VM Confidential Space, Confidential Space Launcher akan mencoba menghentikan workload dengan baik dengan mengirimkan sinyal SIGTERM. Setelah diterima, workload memiliki waktu hingga 120 detik untuk melakukan pembersihan sebelum Peluncur Confidential Space memulai proses penonaktifan. Workload yang tidak menerapkan penanganan sinyal SIGTERM akan langsung dihentikan setelah menerima sinyal.

Pemasangan scratch dalam memori

Confidential Space mendukung penambahan ruang sementara dalam memori. Tindakan ini menggunakan memori yang tersedia di VM Confidential Space. Karena ruang sementara menggunakan memori Confidential VM, ruang ini memiliki properti integritas dan kerahasiaan yang sama dengan Confidential VM.

Anda dapat menggunakan tee-dev-shm-size untuk meningkatkan ukuran pemasangan memori bersama /dev/shm untuk workload. Ukuran /dev/shm ditentukan dalam KB.

Anda dapat menggunakan tee-mount untuk menentukan pemasangan tmpfs dalam container yang berjalan menggunakan konfigurasi yang dipisahkan titik koma. type dan source selalu tmpfs. destination adalah titik pemasangan, yang berinteraksi dengan kebijakan peluncuran tee.launch_policy.allow_mount_destinations. Anda dapat menentukan ukuran tmpfs dalam byte (opsional). Ukuran defaultnya adalah 50% dari memori VM.

Port masuk

Secara default, VM Confidential Space beroperasi dengan aturan firewall untuk memblokir semua port masuk. Saat menggunakan versi image Confidential Space 230600 atau yang lebih tinggi, Anda dapat menentukan port masuk agar tetap terbuka di Dockerfile saat membangun image workload.

Untuk membuka port, tambahkan kata kunci EXPOSE ke Dockerfile, beserta nomor port yang akan tetap terbuka dan protokol opsional tcp atau udp. Jika Anda tidak menentukan protokol untuk port, TCP dan UDP akan diizinkan. Berikut adalah contoh Dockerfile yang mengekspos port masuk:

FROM alpine:latest
EXPOSE 80
EXPOSE 443/tcp
EXPOSE 81/udp
WORKDIR /test
COPY salary /test
ENTRYPOINT ["/test/salary"]
CMD []

Bergantung pada image dasar yang Anda gunakan, beberapa port mungkin sudah terekspos. Dockerfile Anda hanya mengekspos port tambahan; image ini tidak dapat memblokir port yang telah dibuka oleh image dasar.

Operator workload harus memastikan bahwa port yang terekspos terbuka di firewall VPC sebelum menjalankan workload. Nomor port dapat diberikan oleh pembuat workload, atau diambil dari informasi image Docker.

Port yang terekspos dicatat dalam log di konsol dan dialihkan ke Cloud Logging saat menggunakan variabel metadata tee-container-log-redirect.

Kebijakan peluncuran

Kebijakan peluncuran menggantikan variabel metadata VM yang ditetapkan oleh operator workload untuk membatasi tindakan berbahaya. Penulis workload dapat menetapkan kebijakan dengan label sebagai bagian dari pembuatan image container mereka.

Misalnya, dalam Dockerfile:

LABEL "tee.launch_policy.allow_cmd_override"="true"

Dalam file BUILD Bazel:

container_image(
    ...
    labels={"tee.launch_policy.allow_cmd_override":"true"}
    ...
)

Kebijakan peluncuran yang tersedia ada dalam tabel berikut:

Kebijakan Jenis Deskripsi

tee.launch_policy.allow_capabilities

Berinteraksi dengan:

 Boolean (default-nya adalah false) Menentukan apakah operator workload dapat menambahkan kemampuan Linux tambahan ke container workload.

tee.launch_policy.allow_cgroups

Berinteraksi dengan:

 Boolean (default-nya adalah false) Menentukan apakah container workload diizinkan untuk menyertakan pemasangan cgroup dengan namespace di /sys/fs/cgroup.

tee.launch_policy.allow_cmd_override

Berinteraksi dengan:

 Boolean (default-nya adalah false) Menentukan apakah CMD yang ditentukan dalam Dockerfile container workload dapat diganti oleh operator workload dengan nilai metadata tee-cmd.

tee.launch_policy.allow_env_override

Berinteraksi dengan:

 String yang dipisahkan koma String yang dipisahkan koma dari nama variabel lingkungan yang diizinkan untuk ditetapkan oleh operator workload dengan nilai metadata tee-env-ENVIRONMENT_VARIABLE_NAME.

tee.launch_policy.allow_mount_destinations

Berinteraksi dengan:

 String yang dipisahkan titik dua

String yang dipisahkan titik dua dari direktori pemasangan yang diizinkan untuk dipasang oleh operator workload menggunakan tee-mount.

Contoh: /run/tmp:/var/tmp:/tmp

tee.launch_policy.log_redirect

Berinteraksi dengan:

 String yang ditentukan

Menentukan cara kerja logging jika tee-container-log-redirect ditetapkan ke true oleh operator workload.

Nilai yang valid adalah sebagai berikut:

  • debugonly (default): Hanya izinkan pengalihan stdout dan stderr saat menggunakan image debug.
  • always: Selalu izinkan pengalihan stdout dan stderr.
  • never: Jangan pernah mengizinkan pengalihan stdout dan stderr.

tee.launch_policy.monitoring_memory_allow

Berinteraksi dengan:

 String yang ditentukan

Menentukan cara kerja pemantauan penggunaan memori workload jika tee-monitoring-memory-enable ditetapkan ke true oleh operator workload.

Nilai yang valid adalah sebagai berikut:

  • debugonly (default): Hanya izinkan pemantauan penggunaan memori saat menggunakan image debug.
  • always: Selalu izinkan pemantauan penggunaan memori.
  • never: Jangan pernah izinkan pemantauan penggunaan memori.

tee.launch_policy.nonroot_container

Berinteraksi dengan:

 String yang ditentukan

Menentukan apakah akan membatasi hak istimewa eksekusi container.

Nilai yang valid adalah sebagai berikut:

  • unrestricted (default): Penulis workload mengizinkan container untuk berjalan sebagai root atau non-root. Operator workload memilih menggunakan tee-nonroot-container.
  • nonrootonly: Penulis workload mengharuskan container dijalankan sebagai pengguna non-root. Operator workload harus menetapkan tee-nonroot-container ke true, atau VM akan gagal meluncurkan workload.

Beberapa operasi workload

Untuk menjalankan ulang workload, operator workload harus memulai ulang instance VM. Tindakan ini akan memulai workload di lingkungan yang sebersih mungkin dan mengenkripsi disk instance VM dengan kunci sementara baru.

Memulai ulang akan mengatasi vektor serangan yang mengubah image workload pada disk setelah didownload dan diukur. Namun, hal ini juga menambah overhead seperti waktu booting dan menarik image workload ke setiap operasi workload. Jika overhead ini terlalu memengaruhi performa workload, dengan mengorbankan peningkatan profil risiko, Anda dapat membuat kode mulai ulang workload ke dalam workload itu sendiri.

Cgroup dengan namespace

Workload Confidential Space berjalan tanpa pemasangan cgroup secara default.

Untuk mengelola cgroup dalam container workload, Anda dapat menggunakan tee-cgroup-ns. Kunci metadata ini menginstruksikan instance VM untuk membuat pemasangan di /sys/fs/cgroup dalam sistem file container.

Eksekusi container non-root

Anda dapat memilih untuk menjalankan container sebagai pengguna non-root untuk mengurangi dampak container breakout. Jika eksekusi container non-root diaktifkan, Confidential Space akan mengonfigurasi namespace pengguna Linux dan namespace jaringan untuk workload. UID dan GID container 0-65535 dipetakan ke ID tanpa hak istimewa yang dimulai dari 100000 di Confidential VM. Proses yang berjalan sebagai root di dalam container, atau keluar darinya, hanya memiliki akses tanpa hak istimewa ke VM. Anda tidak perlu menambahkan petunjuk USER ke Dockerfile.

Eksekusi non-root memerlukan image Confidential Space confidential-space-261001 atau yang lebih baru. Anda dapat mengonfigurasinya sebagai opsional atau wajib:

  • Penulis workload: Gunakan label kebijakan peluncuran tee.launch_policy.nonroot_container di image container Anda. Jika kebijakan ini disetel ke nonrootonly, operator workload harus menjalankan container sebagai pengguna non-root.

  • Operator workload: Teruskan variabel metadata tee-nonroot-container=true saat membuat VM. Jika penulis workload menetapkan nonrootonly, variabel metadata ini diperlukan, atau VM akan gagal meluncurkan workload.

Image container yang dapat direproduksi

Membangun image container dengan cara yang dapat direproduksi dapat membantu meningkatkan kepercayaan antarpihak. Anda dapat membuat image yang dapat direproduksi dengan Bazel.

Resource yang tidak dikelola oleh Google Cloud IAM

Untuk mengakses resource yang tidak dikelola oleh Google Cloud IAM, workload Anda perlu menentukan audiens kustom.

Untuk mengetahui informasi selengkapnya, lihat Mengakses resource yang tidak dikelola oleh Google Cloud IAM.

Image container bertanda tangan

Anda dapat menandatangani image container dengan kunci publik, yang kemudian dapat digunakan oleh kolaborator data untuk pengesahan, alih-alih menentukan ringkasan image dalam kebijakan WIP mereka.

Artinya, kolaborator data tidak perlu memperbarui kebijakan WIP mereka setiap kali workload diperbarui, dan workload dapat terus mengakses resource yang dilindungi tanpa gangguan.

Anda dapat menggunakan Sigstore Cosign untuk menandatangani image container. Agar Confidential Space dapat mengambil tanda tangan, operator workload harus menambahkan informasi tanda tangan ke variabel metadata tee-signed-image-repos sebelum men-deploy workload.

Selama runtime, tanda tangan dikirim ke layanan pengesahan untuk verifikasi. Layanan pengesahan menampilkan token klaim pengesahan yang berisi klaim tanda tangan terverifikasi. Berikut adalah contoh klaim tanda tangan:

"image_signatures": [
  {
    "key_id": "hexadecimal-sha256-fingerprint-public-key1",
    "signature": "base64-encoded-signature",
    "signature_algorithm": "RSASSA_PSS_SHA256"
  },
  {
    "key_id": "hexadecimal-sha256-fingerprint-public-key2",
    "signature": "base64-encoded-signature",
    "signature_algorithm": "RSASSA_PSS_SHA256",
  },
  {
    "key_id": "hexadecimal-sha256-fingerprint-public-key3",
    "signature": "base64-encoded-signature",
    "signature_algorithm": "RSASSA_PSS_SHA256",
  }
]

Untuk mengonfigurasi penandatanganan image container, lihat Codelab image container bertanda tangan.