Membuat dan menyesuaikan beban kerja


Beban kerja dibuat oleh penulis beban kerja, dan memproses data rahasia yang ingin digunakan oleh kolaborator data.

Penulis workload perlu menggabungkan 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 container yang mendukungnya.

  • Image dalam 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 beban kerja sebelum dapat mengakses data mereka.

Sebelum memulai

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

Berbicara dengan kolaborator data

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

  • Apa 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?

  • Bagaimana aplikasi harus membandingkan dan memproses data pribadi?

  • Dalam format apa output harus dibuat?

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

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

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 beban kerja.

Membuat solusi Confidential Space

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. Hal ini memungkinkan Anda mendapatkan pengalaman dengan izin lintas project, dan mengambil data yang Anda perlukan dari resource Google Cloud tertentu. Hal ini juga dapat memberi Anda pemahaman tentang peran operator beban kerja dan kolaborator data serta tanggung jawabnya.

Selama fase awal pembuatan, sebaiknya amati praktik berikut:

  • Saat bekerja sebagai kolaborator data, minimalkan validasi pengesahan untuk 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 beban kerja.

Seiring aplikasi Anda berkembang dan statusnya menjadi lebih dapat diprediksi, Anda dapat semakin 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 yang sebenarnya, tetapi data palsu sehingga Anda dapat menunjukkan kepada kolaborator data cara semuanya berfungsi. Pada tahap ini, Anda mungkin mulai menggunakan operator beban kerja independen.

Jika semuanya berfungsi dan output-nya seperti yang diharapkan, Anda dapat mulai menguji pada data produksi. Setelah pengujian selesai dan semua pihak menyetujui hasilnya, beban kerja siap untuk diproduksi.

Berhati-hatilah dengan output

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

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

Mem-build image dalam container dengan Docker

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

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

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 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. 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 VM Ruang Rahasia, yang berarti penggunaan memori yang berlebihan dapat membuat error pada workload. Pastikan pemilihan mesin Anda mendukung penggunaan memori beban kerja Anda selain overhead integritas disk.

Token OIDC yang sudah habis masa berlakunya

Token OIDC disediakan untuk digunakan oleh workload Anda saat dimulai. File ini berisi klaim pengesahan terverifikasi tentang VM workload Anda, dan disimpan di penampung workload di /run/container_launcher/attestation_verifier_claims_token. Masa berlaku token akan berakhir setelah 60 menit.

Jika masa berlaku token habis, pembaruan akan dicoba di latar belakang menggunakan backoff eksponensial hingga berhasil. Jika pembaruan gagal (karena masalah jaringan, penghentian layanan pengesahan, atau lainnya), kode beban kerja Anda harus dapat menangani kegagalan tersebut.

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

  • Abaikan token yang sudah tidak berlaku, dengan asumsi token tersebut tidak diperlukan lagi setelah penggunaan awal.

  • Tunggu hingga token yang sudah tidak berlaku berhasil diperbarui.

  • Keluar dari workload.

Pemasangan awal dalam memori

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

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

Anda dapat menggunakan tee-mount untuk menentukan mount tmpfs dalam penampung yang berjalan menggunakan konfigurasi yang dipisahkan titik koma. type dan source selalu tmpfs. destination adalah mountpoint, yang berinteraksi dengan kebijakan peluncuran tee.launch_policy.allow_mount_destinations. Anda dapat menentukan ukuran tmpfs dalam byte secara opsional. Ukuran default-nya adalah 50% dari memori VM.

Port masuk

Secara default, VM Confidential Space beroperasi dengan aturan firewall untuk memblokir semua port masuk. Saat menggunakan image Confidential Space versi 230600 atau yang lebih tinggi, Anda dapat menentukan port masuk agar tetap terbuka di Dockerfile saat mem-build 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 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 diekspos. Dockerfile Anda hanya mengekspos port tambahan; Dockerfile tidak dapat memblokir port yang telah dibuka oleh image dasar.

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

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

Kebijakan peluncuran

Kebijakan peluncuran mengganti variabel metadata VM yang ditetapkan oleh operator beban kerja untuk membatasi tindakan berbahaya. Penulis workload dapat menetapkan kebijakan dengan label sebagai bagian dari mem-build 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_cmd_override

Berinteraksi dengan:

Boolean (defaultnya adalah false) Menentukan apakah CMD yang ditentukan dalam Dockerfile penampung beban kerja dapat diganti oleh operator beban kerja 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 yang diizinkan untuk ditetapkan oleh operator beban kerja dengan nilai metadata tee-env-ENVIRONMENT_VARIABLE_NAME.

tee.launch_policy.allow_mount_destinations

Berinteraksi dengan:

  • Operator beban kerja: Variabel metadata tee-mount.
String yang dipisahkan titik dua

String yang dipisahkan titik dua dari direktori pemasangan yang diizinkan yang diizinkan untuk dipasang oleh operator beban kerja 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 beban kerja.

Nilai yang valid adalah:

  • 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 beban kerja jika tee-memory-monitoring-enable ditetapkan ke true oleh operator beban kerja.

Nilai yang valid adalah:

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

Beberapa beban kerja berjalan

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

Hal ini juga menambahkan overhead seperti waktu booting dan mengambil image workload ke setiap penyelenggaraan workload. Jika overhead ini terlalu memengaruhi performa workload, Anda dapat membuat kode untuk memulai ulang workload ke dalam workload itu sendiri, dengan biaya peningkatan profil risiko.

Image container yang dapat direkonstruksi

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 IAM Google Cloud

Untuk mengakses resource yang tidak dikelola oleh IAM Google Cloud , beban kerja Anda harus menentukan audiens kustom.

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

Image container yang ditandatangani

Anda dapat menandatangani image container dengan kunci publik, yang kemudian dapat digunakan collaborator data untuk pengesahan, bukan menentukan ringkasan image dalam kebijakan WIP mereka.

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 variabel metadata tee-signed-image-repos sebelum men-deploy workload.

Selama runtime, tanda tangan dikirim ke layanan pengesahan Ruang Rahasia 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 yang ditandatangani.