Membuat dan menyesuaikan beban kerja

Workload dibuat oleh pembuat 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 membuat image yang di-container yang mendukungnya.

• Image dalam container untuk mengemas aplikasi ke dalamnya, menggunakan Docker.

• Repositori di Artifact Registry untuk menyimpan image Docker.

• Kebijakan peluncuran yang ditetapkan pada image container yang mengontrol cara menjalankan beban kerja, dan membatasi kemampuan operator beban kerja berbahaya.

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

Kolaborator data harus memvalidasi pengesahan beban kerja sebelum dapat mengakses datanya.

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 yang di-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 kolaborator data Anda tentang data pribadi yang ingin mereka kerjakan. Pertanyaan yang dapat Anda ajukan meliputi:

• Apa ID organisasi yang terlibat?

• Berapa nomor project yang terlibat?

• Apa saja Google Cloud resource yang perlu saya akses, serta ID dan 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 ditampilkan?

• 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 akibat dari beban kerja.

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. Hal ini memungkinkan Anda mendapatkan pengalaman dengan izin lintas project, dan mengambil data yang Anda butuhkan dari resource Google Cloud tertentu. Anda juga dapat mengapresiasi peran operator workload dan kolaborator data serta tanggung jawab mereka.

Selama fase pembuatan awal, sebaiknya amati praktik berikut:

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

Seiring aplikasi Anda menjadi lebih matang dan statusnya menjadi lebih dapat diprediksi, Anda dapat semakin mengamankan solusi Anda dengan validasi pengesahan dan kebijakan peluncuran, serta beralih ke image Ruang Rahasia produksi.

Setelah beban kerja Anda berfungsi dengan benar di lingkungan pengujian, Anda dapat beralih ke pengujian di project kolaborator data dengan resource nyata, tetapi data palsu sehingga Anda dapat mendemonstrasikan kepada kolaborator data cara kerjanya. Pada saat ini, Anda dapat mulai menggunakan operator workload independen.

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

Berhati-hatilah dengan output

Saat menguji kode, Anda mungkin tergoda untuk men-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 di produksi, pastikan kode tersebut tidak menghasilkan 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.

Membangun image dalam container dengan Docker

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

Saat membuat image Docker, pertimbangkan hal-hal berikut:

• Kemampuan Linux tambahan

• Batas disk dan memori

• Token OIDC yang sudah 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 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 adalah 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 Confidential Space, yang berarti penggunaan memori yang berlebihan dapat menyebabkan workload mengalami error. Pastikan pilihan mesin Anda mendukung penggunaan memori beban kerja selain overhead integritas disk.

Token OIDC yang sudah habis masa berlakunya

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

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

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

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

• Tunggu hingga token yang sudah tidak berlaku berhasil diperbarui.

• Keluar dari workload.

Pemasangan sementara 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 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 beban kerja. 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 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 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 versi image Confidential Space 230600 atau yang lebih baru, Anda dapat menentukan port masuk yang harus tetap terbuka di Dockerfile saat membuat image workload.

Untuk membuka port, tambahkan kata kunci EXPOSE ke Dockerfile Anda, beserta nomor port yang akan tetap dibuka dan protokol opsional tcp atau udp. Jika Anda tidak menentukan protokol untuk port, TCP dan UDP diizinkan. Berikut 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 diberikan oleh penulis beban kerja, atau ditarik 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:

Beberapa run workload

Untuk memastikan lingkungan yang bersih, VM harus dimulai ulang untuk memulai ulang beban kerja. Hal ini mengenkripsi disk VM dengan kunci sementara, untuk mengatasi vektor serangan berupa modifikasi gambar beban kerja pada disk setelah didownload dan diukur.

Hal ini juga menambahkan overhead seperti waktu booting dan menarik image workload ke setiap eksekusi workload. Jika overhead ini terlalu memengaruhi performa workload Anda, Anda dapat mengodekan 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

Membangun image container secara berulang 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, beban kerja 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 pengesahan, bukan 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. 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 Confidential Space untuk diverifikasi. 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.