Membuat dan menyesuaikan beban kerja

Penulis workload

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

Penulis workload harus mengumpulkan resource berikut untuk membuat workload:

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

• Image dalam container untuk mengemas aplikasi ke dalam, 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 dalam container dari Artifact Registry dan menjalankannya.

Kolaborator data harus memvalidasi pernyataan workload sebelum dapat mengakses datanya.

Catatan: Jika resource kolaborator data disimpan di luar Google Cloud, penulis workload juga harus menerapkan token pernyataan sendiri, dan bekerja sama dengan kolaborator data sehingga mereka dapat memverifikasi token tersebut.

Sebelum memulai

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

Berbicara dengan kolaborator data

Sebelum mulai menulis aplikasi, Anda harus berbicara dengan kolaborator data tentang data pribadi yang ingin Anda gunakan. Pertanyaan yang dapat Anda ajukan mencakup hal berikut:

• Apa saja ID organisasi yang terlibat?

• Apa saja nomor project yang terlibat?

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

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

• Bagaimana aplikasi harus membandingkan dan memproses data pribadi?

• Dalam format apa output harus dibuat?

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

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

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

Mem-build solusi Confidential Space

Sebaiknya siapkan dua (atau lebih) project dengan izin yang sesuai sebagai lingkungan pengujian, seperti di Membuat lingkungan Confidential Space pertama Anda. Cobalah untuk mencerminkan penyiapan project kolaborator data sebaik mungkin. Hal ini memungkinkan Anda mendapatkan pengalaman dengan izin lintas project, dan mengambil data yang Anda butuhkan dari resource tertentu. Google Cloud Hal ini juga dapat memberi Anda pemahaman tentang peran operator workload dan kolaborator data serta tanggung jawabnya.

Selama fase build awal, sebaiknya amati praktik berikut:

• Saat bekerja sebagai kolaborator data, minimalkan validasi pernyataan 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 perkembangan aplikasi dan statusnya menjadi lebih mudah diprediksi, Anda dapat semakin mengamankan solusi dengan validasi pernyataan 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 kerja semuanya. Pada saat ini, Anda dapat 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 diproduksi.

Berhati-hatilah dengan output

Saat menguji kode, Anda mungkin tergoda untuk melakukan proses debug dengan mencetak ke STDOUT atau STDERR. Jika Anda memilih untuk melakukannya, berhati-hatilah agar Anda 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 membahayakan privasi dan sensitivitas data asli.

Mem-build image dalam container dengan Docker

Aplikasi harus dikemas ke dalam image dalam container yang di-build oleh Docker, yang disimpan di Artifact Registry. Saat workload di-deploy, image Docker akan diambil dari repositori Artifact Registry oleh image Confidential Space, dijalankan, dan aplikasi dapat mulai menggunakan resource project yang sesuai.

Saat mem-build image Docker, perhatikan hal-hal berikut:

• Kemampuan Linux tambahan

• Batas disk dan memori

• Token OIDC yang habis masa berlakunya

• Resource yang tidak dikelola oleh Google Cloud IAM

• Port masuk

• Kebijakan peluncuran

• Beberapa eksekusi workload

• cgroup dengan namespace

• Image container yang dapat direproduksi

• Image container bertanda tangan

Kemampuan Linux tambahan

Workload Confidential Space berjalan dalam 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 disk booting saat menggunakan ukuran disk booting yang lebih besar. Ukuran partisi kira-kira adalah ukuran disk booting dikurangi 5 GB.

Sebagai bagian dari perlindungan sistem file integritas Confidential Space, Confidential Space menyimpan tag integritas disk dalam memori. Hal 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 Confidential Space VM, yang berarti penggunaan memori yang berlebihan dapat menyebabkan workload error. Pastikan pemilihan mesin Anda mendukung penggunaan memori workload selain overhead integritas disk.

Token OIDC yang habis masa berlakunya

Token OIDC tersedia untuk digunakan oleh workload Anda saat dimulai. Token ini berisi klaim pernyataan terverifikasi tentang VM workload Anda, dan disimpan dalam container workload di /run/container_launcher/attestation_verifier_claims_token. Token akan habis masa berlakunya setelah 60 menit.

Jika token habis masa berlakunya, refresh akan dicoba di latar belakang menggunakan backoff eksponensial hingga berhasil. Jika refresh gagal (karena masalah jaringan, gangguan layanan pernyataan, atau lainnya), kode workload Anda harus dapat menangani kegagalan tersebut.

Workload Anda dapat menangani kegagalan refresh token dengan salah satu cara berikut:

• Mengabaikan token yang habis masa berlakunya, dengan asumsi token tersebut tidak lagi diperlukan setelah penggunaan awal.

• Menunggu token yang habis masa berlakunya berhasil di-refresh.

• Keluar dari workload.

Pemasangan scratch dalam memori

Confidential Space mendukung penambahan ruang scratch dalam memori. Hal ini menggunakan memori yang tersedia di Confidential Space VM. Karena ruang scratch menggunakan memori Confidential VM, ruang tersebut 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 di container yang sedang berjalan menggunakan konfigurasi yang dipisahkan dengan tanda titik koma. type dan source selalu tmpfs. The destination adalah titik pemasangan, yang berinteraksi dengan tee.launch_policy.allow_mount_destinations kebijakan peluncuran. Anda dapat secara opsional menentukan ukuran tmpfs dalam byte. Ukuran default adalah 50% dari memori VM.

Port masuk

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

Perhatian: Port terbuka memperluas permukaan serangan workload. Penulis workload harus berhati-hati untuk mengamankan workload mereka dengan benar.

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 []

Catatan: Mengubah port yang diekspos untuk image akan mengubah ringkasannya. Pemilik resource mungkin perlu memperbarui penyedia identitas workload mereka untuk mengotorisasi ringkasan image baru.

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

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

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

Kebijakan peluncuran

Kebijakan peluncuran mengganti 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.

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: Operator workload: Variabel metadata tee-added-capabilities.	Boolean (default adalah false)	Menentukan apakah operator workload dapat menambahkan kemampuan Linux tambahan ke container workload.
tee.launch_policy.allow_cgroups Berinteraksi dengan: Operator workload: Variabel metadata.tee-cgroup-ns	Boolean (default 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: Operator workload: Variabel metadata.tee-cmd Kolaborator data: Pernyataan container.cmd_override.	Boolean (default 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: Operator workload: Variabel metadata tee-env-ENVIRONMENT_VARIABLE_NAME. Kolaborator data: Pernyataan container.env dan container.env_override.	String yang dipisahkan koma	String yang dipisahkan koma dari nama variabel lingkungan yang diizinkan dan dapat ditetapkan oleh operator workload dengan tee-env-ENVIRONMENT_VARIABLE_NAME nilai metadata.
tee.launch_policy.allow_mount_destinations Berinteraksi dengan: Operator workload: Variabel metadata.tee-mount	String yang dipisahkan titik dua	String yang dipisahkan titik dua dari direktori pemasangan yang diizinkan dan dapat dipasang oleh operator workload menggunakan tee-mount. Contoh: /run/tmp:/var/tmp:/tmp
tee.launch_policy.log_redirect Berinteraksi dengan: Operator workload: Variabel metadata.tee-container-log-redirect	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 mengizinkan stdout dan stderr pengalihan saat menggunakan image debug. always: Selalu mengizinkan stdout dan stderr pengalihan. never: Tidak pernah mengizinkan stdout dan stderr pengalihan.
tee.launch_policy.monitoring_memory_allow Berinteraksi dengan: Kolaborator data: Pernyataan monitoring_enabled.memory . Operator workload: Variabel metadata tee-monitoring-memory-enable.	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 mengizinkan pemantauan penggunaan memori saat menggunakan image debug. always: Selalu mengizinkan pemantauan penggunaan memori. never: Tidak pernah mengizinkan pemantauan penggunaan memori. Perhatian: Jika Anda mengizinkan pemantauan penggunaan memori, operator workload dapat melihat metrik penggunaan memori workload di Cloud Logging dan Metrics Explorer. Jika workload Anda tidak ditulis dengan cara yang mencegah total penggunaan memori membocorkan informasi sensitif, blokir fitur ini pada workload produksi.

Beberapa eksekusi workload

Untuk memastikan lingkungan yang bersih, VM harus dimulai ulang untuk memulai ulang workload. Tindakan ini mengenkripsi disk VM dengan kunci sementara, untuk mengatasi vektor serangan yang mengubah image workload pada disk setelah didownload dan diukur.

Tindakan ini juga menambahkan overhead seperti waktu booting dan menarik image workload ke setiap eksekusi workload. Jika overhead ini terlalu memengaruhi performa workload, Anda dapat membuat kode untuk memulai ulang workload ke dalam workload itu sendiri, dengan risiko meningkatkan profil risiko Anda.

cgroup dengan namespace

Workload Confidential Space berjalan tanpa pemasangan cgroup secara default.

Untuk mengelola cgroup dalam container workload, Anda dapat menggunakan tee-cgroup-ns. Tindakan ini akan membuat pemasangan di /sys/fs/cgroup dalam sistem file container.

Image container yang dapat direproduksi

Mem-build image container dengan cara yang dapat direproduksi dapat membantu meningkatkan kepercayaan antarpihak. Anda dapat mem-build 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 harus 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 pernyataan, bukan menentukan ringkasan image dalam kebijakan WIP.

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

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

Selama runtime, tanda tangan dikirim ke layanan pernyataan Confidential Space untuk diverifikasi. Layanan pernyataan menampilkan token klaim pernyataan 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",
  }
]

Catatan: Jika penulis workload memperbarui tanda tangan container untuk workload yang sedang berjalan, Confidential Space dapat memerlukan waktu hingga 1 jam untuk mendeteksi tanda tangan yang diperbarui.

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