GSP1183

Ringkasan

Otorisasi Biner merupakan kontrol keamanan waktu deployment yang memastikan hanya image container tepercaya yang di-deploy di Google Kubernetes Engine (GKE) atau Cloud Run. Dengan Otorisasi Biner, Anda dapat mewajibkan image untuk ditandatangani oleh otoritas tepercaya selama proses pengembangan, lalu menerapkan validasi tanda tangan saat melakukan deployment. Dengan menerapkan validasi, Anda dapat memperoleh kontrol yang lebih ketat atas lingkungan container dengan memastikan hanya image terverifikasi yang diintegrasikan ke proses build dan rilis.

Diagram berikut menunjukkan komponen dalam penyiapan Otorisasi Biner/Cloud Build:

Pipeline Cloud Build yang membuat pengesahan Otorisasi Biner.

Dalam pipeline ini:

1. Kode untuk mem-build image container dikirim ke repositori sumber, seperti Cloud Source Repositories.
2. Alat continuous integration (CI), Cloud Build, mem-build dan menguji container.
3. Build mengirim image container ke Container Registry atau registry lain yang menyimpan image yang Anda build.
4. Cloud Key Management Service, yang menyediakan pengelolaan kunci untuk pasangan kunci kriptografis, menandatangani image container. Tanda tangan yang dihasilkan kemudian disimpan dalam pengesahan yang baru dibuat.
5. Pada waktu deployment, attestor memverifikasi pengesahan menggunakan kunci publik dari pasangan kunci. Otorisasi Biner menerapkan kebijakan dengan mewajibkan pengesahan bertanda tangan untuk men-deploy image container.

Dalam lab ini, Anda akan mempelajari alat dan teknik untuk mengamankan artefak yang di-deploy. Lab ini berfokus pada artefak (container) setelah dibuat, tetapi tidak di-deploy ke lingkungan tertentu.

Yang akan Anda pelajari

• Penandatanganan Image
• Kebijakan Kontrol Penerimaan
• Penandatanganan Image yang Dipindai
• Pemberian Otorisasi Image Bertanda Tangan
• Image yang Diblokir dan Tidak Ditandatangani

Penyiapan dan persyaratan

Sebelum mengklik tombol Start Lab

Baca petunjuk ini. Lab memiliki timer yang tidak dapat dijeda. Timer, yang dimulai saat Anda mengklik Start Lab, akan menampilkan durasi ketersediaan resource Google Cloud untuk Anda.

Lab praktis ini dapat Anda gunakan untuk mengerjakan sendiri aktivitas lab di lingkungan cloud sungguhan, bukan di lingkungan demo atau simulasi. Untuk mengakses lab ini, Anda akan diberi kredensial baru yang bersifat sementara dan dapat digunakan untuk login serta mengakses Google Cloud selama durasi lab.

Untuk menyelesaikan lab ini, Anda memerlukan:

• Akses ke browser internet standar (disarankan browser Chrome).

Catatan: Gunakan jendela Samaran atau browser rahasia untuk menjalankan lab ini. Hal ini akan mencegah konflik antara akun pribadi Anda dan akun Siswa, yang mungkin menyebabkan tagihan ekstra pada akun pribadi Anda.

• Waktu untuk menyelesaikan lab. Ingat, setelah dimulai, lab tidak dapat dijeda.

Catatan: Jika Anda sudah memiliki project atau akun pribadi Google Cloud, jangan menggunakannya untuk lab ini agar terhindar dari tagihan ekstra pada akun Anda.

Cara memulai lab dan login ke Konsol Google Cloud

1. Klik tombol Start Lab. Jika Anda perlu membayar lab, jendela pop-up akan terbuka untuk memilih metode pembayaran. Panel Lab Details di sebelah kiri berisi:

   • Tombol Open Google Cloud console
   • Waktu tersisa
   • Kredensial sementara yang harus Anda gunakan untuk lab ini
   • Informasi lain, jika diperlukan, untuk menyelesaikan lab ini

2. Klik Open Google Cloud console (atau klik kanan dan pilih Open Link in Incognito Window jika Anda menjalankan browser Chrome).

   Lab akan menjalankan resource, lalu membuka tab lain yang menampilkan halaman Sign in.

   Tips: Atur tab di jendela terpisah secara berdampingan.

   Catatan: Jika Anda melihat dialog Choose an account, klik Use Another Account.

3. Jika perlu, salin Username di bawah dan tempel ke dialog Sign in.

   {{{user_0.username | "Username"}}}

   Anda juga dapat menemukan Username di panel Lab Details.

4. Klik Next.

5. Salin Password di bawah dan tempel ke dialog Welcome.

   {{{user_0.password | "Password"}}}

   Anda juga dapat menemukan Password di panel Lab Details.

6. Klik Next.

   Penting: Anda harus menggunakan kredensial yang diberikan lab. Jangan menggunakan kredensial akun Google Cloud Anda. Catatan: Penggunaan akun Google Cloud sendiri untuk lab ini mungkin dikenai biaya tambahan.

7. Klik untuk melanjutkan ke halaman berikutnya:

   • Setujui persyaratan dan ketentuan.
   • Jangan tambahkan opsi pemulihan atau autentikasi 2 langkah (karena ini akun sementara).
   • Jangan daftar uji coba gratis.

Setelah beberapa saat, Konsol Google Cloud akan terbuka di tab ini.

Catatan: Untuk melihat menu dengan daftar produk dan layanan Google Cloud, klik Navigation menu di kiri atas.

Mengaktifkan Cloud Shell

Cloud Shell adalah mesin virtual yang dilengkapi dengan berbagai alat pengembangan. Mesin virtual ini menawarkan direktori beranda persisten berkapasitas 5 GB dan berjalan di Google Cloud. Cloud Shell menyediakan akses command-line untuk resource Google Cloud Anda.

1. Klik Activate Cloud Shell di bagian atas konsol Google Cloud.

Setelah terhubung, Anda sudah diautentikasi, dan project ditetapkan ke Project_ID, . Output berisi baris yang mendeklarasikan Project_ID untuk sesi ini:

Project Cloud Platform Anda dalam sesi ini disetel ke {{{project_0.project_id | "PROJECT_ID"}}}

gcloud adalah alat command line untuk Google Cloud. Alat ini sudah terinstal di Cloud Shell dan mendukung pelengkapan command line.

2. (Opsional) Anda dapat menampilkan daftar nama akun yang aktif dengan perintah ini:

gcloud auth list

3. Klik Authorize.

Output:

ACTIVE: * ACCOUNT: {{{user_0.username | "ACCOUNT"}}} Untuk menetapkan akun aktif, jalankan: $ gcloud config set account `ACCOUNT`

4. (Opsional) Anda dapat menampilkan daftar ID project dengan perintah ini:

gcloud config list project

Output:

[core] project = {{{project_0.project_id | "PROJECT_ID"}}} Catatan: Untuk mendapatkan dokumentasi gcloud yang lengkap di Google Cloud, baca panduan ringkasan gcloud CLI.

Penyiapan Lingkungan

Di Cloud Shell, tetapkan project ID dan nomor project untuk project Anda. Simpan keduanya sebagai variabel PROJECT_ID dan PROJECT_NUMBER:

export PROJECT_ID=$(gcloud config get-value project) export PROJECT_NUMBER=$(gcloud projects describe $PROJECT_ID \ --format='value(projectNumber)')

Mengaktifkan layanan

Mengaktifkan semua layanan yang diperlukan:

gcloud services enable \ cloudkms.googleapis.com \ cloudbuild.googleapis.com \ container.googleapis.com \ containerregistry.googleapis.com \ artifactregistry.googleapis.com \ containerscanning.googleapis.com \ ondemandscanning.googleapis.com \ binaryauthorization.googleapis.com

Tugas 1. Membuat repositori Artifact Registry

Di lab ini, Anda akan menggunakan Artifact Registry untuk menyimpan dan memindai image.

1. Buat repositori dengan perintah berikut:

gcloud artifacts repositories create artifact-scanning-repo \ --repository-format=docker \ --location={{{ project_0.default_region | "REGION" }}} \ --description="Docker repository"

2. Konfigurasi Docker untuk menggunakan kredensial gcloud Anda saat mengakses Artifact Registry:

gcloud auth configure-docker {{{ project_0.default_region | "REGION" }}}-docker.pkg.dev

3. Buat dan ubah menjadi direktori kerja:

mkdir vuln-scan && cd vuln-scan

4. Selanjutnya, tentukan contoh image. Buat file bernama Dockerfile dengan konten berikut:

cat > ./Dockerfile << EOF FROM python:3.8-alpine # App WORKDIR /app COPY . ./ RUN pip3 install Flask==2.1.0 RUN pip3 install gunicorn==20.1.0 RUN pip3 install Werkzeug==2.2.2 CMD exec gunicorn --bind :\$PORT --workers 1 --threads 8 main:app EOF

5. Buat file bernama main.py dengan konten berikut:

cat > ./main.py << EOF import os from flask import Flask app = Flask(__name__) @app.route("/") def hello_world(): name = os.environ.get("NAME", "Worlds") return "Hello {}!".format(name) if __name__ == "__main__": app.run(debug=True, host="0.0.0.0", port=int(os.environ.get("PORT", 8080))) EOF

6. Gunakan Cloud Build untuk mem-build dan secara otomatis mengirim container Anda ke Artifact Registry.

gcloud builds submit . -t {{{ project_0.default_region | "REGION" }}}-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image

Klik Periksa progres saya untuk memverifikasi tujuan. Membuat repositori Artifact Registry.

Tugas 2. Penandatanganan Image

Apa itu Attestor

• Orang/proses ini bertanggung jawab atas satu link dalam rantai kepercayaan sistem.
• Attestor menyimpan kunci kriptografis, dan menandatangani image jika lulus proses persetujuan.
• Meskipun Pembuat Kebijakan menentukan kebijakan secara abstrak dan berlevel tinggi, Attestor bertanggung jawab untuk secara konkret menerapkan beberapa aspek kebijakan.
• Ini bisa berupa orang sungguhan, seperti penguji QA atau manajer, atau bot dalam sistem CI.
• Keamanan sistem bergantung pada kredibilitas mereka, sehingga penting agar kunci pribadi mereka tetap aman.

Setiap peran ini dapat mewakili satu orang atau tim di organisasi Anda. Dalam lingkungan produksi, peran-peran ini kemungkinan akan dikelola oleh project Google Cloud Platform yang berbeda, dan akses ke resource akan dibagikan di antara peran-peran tersebut secara terbatas menggunakan Cloud IAM.

Attestor di Otorisasi Biner diimplementasikan di atas Cloud Container Analysis API, jadi penting untuk menjelaskan cara kerjanya sebelum melanjutkan. Container Analysis API dirancang untuk memungkinkan Anda mengaitkan metadata dengan image container tertentu.

Sebagai contoh, Catatan dapat dibuat untuk melacak kerentanan Heartbleed. Kemudian, vendor keamanan akan membuat pemindai untuk menguji kerentanan image container, dan membuat Kemunculan yang terkait dengan setiap container yang disusupi.

Selain melacak kerentanan, Container Analysis dirancang sebagai API metadata generik. Otorisasi Biner menggunakan Container Analysis untuk mengaitkan tanda tangan dengan image container yang diverifikasinya. Catatan Container Analysis digunakan untuk merepresentasikan satu attestor, dan Kemunculan dibuat serta dikaitkan dengan setiap container yang telah disetujui attestor.

API Otorisasi Biner menggunakan konsep "attestor" dan "pengesahan", tetapi konsep ini diimplementasikan menggunakan Catatan dan Kemunculan yang sesuai di Container Analysis API.

Membuat Catatan Attestor

Catatan Attestor hanyalah sedikit data yang berfungsi sebagai label untuk jenis tanda tangan yang diterapkan. Misalnya, satu catatan mungkin menunjukkan pemindaian kerentanan, sementara catatan lain mungkin digunakan untuk persetujuan QA. Catatan akan dirujuk selama proses penandatanganan.

1. Buat catatan:

cat > ./vulnz_note.json << EOM { "attestation": { "hint": { "human_readable_name": "Container Vulnerabilities attestation authority" } } } EOM

2. Simpan catatan

NOTE_ID=vulnz_note curl -vvv -X POST \ -H "Content-Type: application/json" \ -H "Authorization: Bearer $(gcloud auth print-access-token)" \ --data-binary @./vulnz_note.json \ "https://containeranalysis.googleapis.com/v1/projects/${PROJECT_ID}/notes/?noteId=${NOTE_ID}"

3. Verifikasi catatan

curl -vvv \ -H "Authorization: Bearer $(gcloud auth print-access-token)" \ "https://containeranalysis.googleapis.com/v1/projects/${PROJECT_ID}/notes/${NOTE_ID}"

Catatan Anda kini disimpan dalam Container Analysis API.

4. Membuat Attestor

Attestor digunakan untuk melakukan proses penandatanganan image yang sebenarnya dan akan melampirkan kemunculan catatan ke image untuk verifikasi nanti. Untuk menggunakan attestor, Anda juga harus mendaftarkan catatan dengan Otorisasi Biner:

5. Buat Attestor

ATTESTOR_ID=vulnz-attestor gcloud container binauthz attestors create $ATTESTOR_ID \ --attestation-authority-note=$NOTE_ID \ --attestation-authority-note-project=${PROJECT_ID}

6. Verifikasi Attestor

gcloud container binauthz attestors list

Baris terakhir menunjukkan NUM_PUBLIC_KEYS: 0 Anda akan memberikan kunci di langkah berikutnya.

Cloud Build secara otomatis membuat attestor built-by-cloud-build di project Anda saat Anda menjalankan build yang menghasilkan image. Jadi, perintah di atas menampilkan dua attestor, vulnz-attestor dan built-by-cloud-build. Setelah image berhasil di-build, Cloud Build akan otomatis menandatangani dan membuat pengesahan untuk image tersebut.

7. Akun layanan Otorisasi Biner akan memerlukan hak untuk melihat catatan pengesahan. Berikan akses ke Peran IAM dengan panggilan API berikut:

PROJECT_NUMBER=$(gcloud projects describe "${PROJECT_ID}" --format="value(projectNumber)") BINAUTHZ_SA_EMAIL="service-${PROJECT_NUMBER}@gcp-sa-binaryauthorization.iam.gserviceaccount.com" cat > ./iam_request.json << EOM { 'resource': 'projects/${PROJECT_ID}/notes/${NOTE_ID}', 'policy': { 'bindings': [ { 'role': 'roles/containeranalysis.notes.occurrences.viewer', 'members': [ 'serviceAccount:${BINAUTHZ_SA_EMAIL}' ] } ] } } EOM

8. Gunakan file untuk membuat Kebijakan IAM:

curl -X POST \ -H "Content-Type: application/json" \ -H "Authorization: Bearer $(gcloud auth print-access-token)" \ --data-binary @./iam_request.json \ "https://containeranalysis.googleapis.com/v1/projects/${PROJECT_ID}/notes/${NOTE_ID}:setIamPolicy"

Klik Periksa progres saya untuk memverifikasi tujuan. Membuat Attestor.

Tugas 3. Menambahkan kunci KMS

Sebelum dapat menggunakan attestor ini, otoritas Anda harus membuat pasangan kunci kriptografis yang dapat digunakan untuk menandatangani image container. Hal ini dapat dilakukan melalui Google Cloud Key Management Service (KMS).

1. Pertama, tambahkan beberapa variabel lingkungan untuk mendeskripsikan kunci baru:

KEY_LOCATION=global KEYRING=binauthz-keys KEY_NAME=codelab-key KEY_VERSION=1

2. Buat keyring untuk menyimpan sekumpulan kunci:

gcloud kms keyrings create "${KEYRING}" --location="${KEY_LOCATION}"

3. Buat pasangan kunci penandatanganan asimetris baru untuk attestor

gcloud kms keys create "${KEY_NAME}" \ --keyring="${KEYRING}" --location="${KEY_LOCATION}" \ --purpose asymmetric-signing \ --default-algorithm="ec-sign-p256-sha256"

Anda akan melihat kunci Anda muncul di halaman KMS di Konsol Cloud.

4. Sekarang, kaitkan kunci dengan attestor Anda melalui perintah binauthz gcloud:

gcloud beta container binauthz attestors public-keys add \ --attestor="${ATTESTOR_ID}" \ --keyversion-project="${PROJECT_ID}" \ --keyversion-location="${KEY_LOCATION}" \ --keyversion-keyring="${KEYRING}" \ --keyversion-key="${KEY_NAME}" \ --keyversion="${KEY_VERSION}"

5. Jika Anda mencetak daftar otoritas lagi, Anda akan melihat kunci yang terdaftar:

gcloud container binauthz attestors list

Klik Periksa progres saya untuk memverifikasi tujuan. Menambahkan kunci KMS.

Tugas 4. Membuat pengesahan yang ditandatangani

Pada tahap ini, Anda telah mengonfigurasi fitur yang memungkinkan Anda menandatangani image. Gunakan Attestor yang Anda buat sebelumnya untuk menandatangani Image Container yang telah Anda kerjakan.

Pengesahan harus menyertakan tanda tangan kriptografis untuk menyatakan bahwa attestor telah memverifikasi image container tertentu dan aman untuk dijalankan di cluster Anda.

1. Untuk menentukan image container mana yang akan disahkan, jalankan perintah berikut untuk menentukan ringkasannya:

CONTAINER_PATH={{{ project_0.default_region | "REGION" }}}-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image DIGEST=$(gcloud container images describe ${CONTAINER_PATH}:latest \ --format='get(image_summary.digest)')

2. Sekarang, Anda dapat menggunakan gcloud untuk membuat pengesahan. Perintah ini akan mengambil detail kunci yang ingin Anda gunakan untuk penandatanganan, dan image container tertentu yang ingin Anda setujui:

gcloud beta container binauthz attestations sign-and-create \ --artifact-url="${CONTAINER_PATH}@${DIGEST}" \ --attestor="${ATTESTOR_ID}" \ --attestor-project="${PROJECT_ID}" \ --keyversion-project="${PROJECT_ID}" \ --keyversion-location="${KEY_LOCATION}" \ --keyversion-keyring="${KEYRING}" \ --keyversion-key="${KEY_NAME}" \ --keyversion="${KEY_VERSION}"

Dalam istilah Container Analysis, tindakan ini akan membuat kemunculan baru, dan melampirkannya ke catatan attestor Anda.

3. Untuk memastikan semuanya berfungsi seperti yang diharapkan, jalankan perintah berikut untuk mencantumkan pengesahan Anda:

gcloud container binauthz attestations list \ --attestor=$ATTESTOR_ID --attestor-project=${PROJECT_ID}

Tugas 5. Kebijakan kontrol penerimaan

Otorisasi Biner adalah fitur di GKE dan Cloud Run yang memberikan kemampuan untuk memvalidasi aturan sebelum image container diizinkan untuk dijalankan. Validasi dijalankan pada setiap permintaan untuk menjalankan image, baik dari pipeline CI/CD tepercaya maupun pengguna yang mencoba men-deploy image secara manual. Dengan kemampuan ini, Anda dapat mengamankan lingkungan runtime secara lebih efektif daripada hanya pemeriksaan pipeline CI/CD.

Untuk memahami kemampuan ini, Anda akan mengubah kebijakan GKE default untuk menerapkan aturan otorisasi yang ketat.

1. Buat cluster GKE dengan otorisasi biner yang diaktifkan:

gcloud beta container clusters create binauthz \ --zone {{{ project_0.default_zone | "ZONE" }}} \ --binauthz-evaluation-mode=PROJECT_SINGLETON_POLICY_ENFORCE

2. Izinkan Cloud Build men-deploy ke cluster ini:

gcloud projects add-iam-policy-binding ${PROJECT_ID} \ --member="serviceAccount:${PROJECT_NUMBER}@cloudbuild.gserviceaccount.com" \ --role="roles/container.developer"

Izinkan Semua kebijakan

Pertama, verifikasi status kebijakan default dan kemampuan Anda untuk men-deploy image apa pun

1. Tinjau kebijakan yang ada:

gcloud container binauthz policy export

2. Perhatikan bahwa kebijakan terkait proses penegakan kebijakan ditetapkan ke ALWAYS_ALLOW

evaluationMode: ALWAYS_ALLOW

3. Deploy Contoh untuk memverifikasi bahwa Anda dapat men-deploy apa pun:

kubectl run hello-server --image gcr.io/google-samples/hello-app:1.0 --port 8080

4. Verifikasi bahwa deployment berfungsi:

kubectl get pods

Anda akan melihat output berikut:

5. Hapus deployment:

kubectl delete pod hello-server

Tolak Semua kebijakan

Sekarang, perbarui kebijakan untuk melarang semua image.

1. Ekspor kebijakan saat ini ke file yang dapat diedit:

gcloud container binauthz policy export > policy.yaml

2. Di editor teks, buka file policy.yaml' dan ubah evaluationMode dari `ALWAYS_ALLOW menjadi ALWAYS_DENY:

edit policy.yaml

Pastikan file YAML kebijakan yang diedit terlihat seperti berikut:

globalPolicyEvaluationMode: ENABLE defaultAdmissionRule: evaluationMode: ALWAYS_DENY enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG name: projects/PROJECT_ID/policy

Kebijakan ini relatif sederhana. Baris globalPolicyEvaluationMode menyatakan bahwa kebijakan ini memperluas kebijakan global yang ditentukan oleh Google. Hal ini memungkinkan semua container GKE resmi berjalan secara default. Selain itu, kebijakan ini mendeklarasikan defaultAdmissionRule yang menyatakan bahwa semua pod lainnya akan ditolak. Aturan penerimaan mencakup baris enforcementMode, yang menyatakan bahwa semua pod yang tidak sesuai dengan aturan ini harus diblokir agar tidak berjalan di cluster.

Untuk mengetahui petunjuk tentang cara mem-build kebijakan yang lebih kompleks, lihat dokumentasi Otorisasi Biner.

3. Di Cloud Shell, jalankan perintah berikut untuk menerapkan kebijakan baru:

gcloud container binauthz policy import policy.yaml

Tunggu beberapa detik hingga perubahan diterapkan.

4. Coba deployment workload contoh:

kubectl run hello-server --image gcr.io/google-samples/hello-app:1.0 --port 8080

5. Deployment gagal dengan pesan berikut:

Error from server (VIOLATES_POLICY): admission webhook "imagepolicywebhook.image-policy.k8s.io" denied the request: Image gcr.io/google-samples/hello-app:1.0 denied by Binary Authorization default admission rule. Denied by always_deny admission rule

Mengembalikan kebijakan untuk mengizinkan semua

Sebelum melanjutkan ke bagian berikutnya, kembalikan perubahan kebijakan.

1. Di editor teks, ubah evaluationMode dari ALWAYS_DENY menjadi ALWAYS_ALLOW.

edit policy.yaml

File YAML kebijakan yang diedit akan muncul sebagai berikut:

globalPolicyEvaluationMode: ENABLE defaultAdmissionRule: evaluationMode: ALWAYS_ALLOW enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG name: projects/PROJECT_ID/policy

2. Terapkan kebijakan yang telah dikembalikan:

gcloud container binauthz policy import policy.yaml

Klik Periksa progres saya untuk memverifikasi tujuan. Membuat cluster GKE dan perbarui kebijakan.

Tugas 6. Menandatangani image secara otomatis

Anda telah mengaktifkan penandatanganan image, dan secara manual menggunakan Attestor untuk menandatangani contoh image Anda. Dalam praktiknya, Anda akan ingin menerapkan pengesahan selama proses otomatis, seperti pipeline CI/CD.

Di bagian ini, Anda akan mengonfigurasi Cloud Build untuk mengesahkan image secara otomatis.

Peran yang diperlukan

1. Tambahkan peran Binary Authorization Attestor Viewer ke Akun Layanan Cloud Build:

gcloud projects add-iam-policy-binding ${PROJECT_ID} \ --member serviceAccount:${PROJECT_NUMBER}@cloudbuild.gserviceaccount.com \ --role roles/binaryauthorization.attestorsViewer

2. Tambahkan peran Cloud KMS CryptoKey Signer/Verifier ke Akun Layanan Cloud Build (Penandatanganan berbasis KMS):

gcloud projects add-iam-policy-binding ${PROJECT_ID} \ --member serviceAccount:${PROJECT_NUMBER}@cloudbuild.gserviceaccount.com \ --role roles/cloudkms.signerVerifier gcloud projects add-iam-policy-binding ${PROJECT_ID} \ --member serviceAccount:${PROJECT_NUMBER}-compute@developer.gserviceaccount.com \ --role roles/cloudkms.signerVerifier

3. Tambahkan peran Container Analysis Notes Attacher ke Akun Layanan Cloud Build:

gcloud projects add-iam-policy-binding ${PROJECT_ID} \ --member serviceAccount:${PROJECT_NUMBER}@cloudbuild.gserviceaccount.com \ --role roles/containeranalysis.notes.attacher

Sediakan akses untuk Akun Layanan Cloud Build

Cloud Build akan memerlukan hak untuk mengakses API pemindaian on-demand.

• Berikan akses dengan perintah berikut:

gcloud projects add-iam-policy-binding ${PROJECT_ID} \ --member="serviceAccount:${PROJECT_NUMBER}@cloudbuild.gserviceaccount.com" \ --role="roles/iam.serviceAccountUser" gcloud projects add-iam-policy-binding ${PROJECT_ID} \ --member="serviceAccount:${PROJECT_NUMBER}@cloudbuild.gserviceaccount.com" \ --role="roles/ondemandscanning.admin"

Siapkan Langkah Custom Build Cloud Build

Anda akan menggunakan langkah Custom Build di Cloud Build untuk menyederhanakan proses pengesahan. Google menyediakan langkah Custom Build ini yang berisi fungsi bantuan untuk menyederhanakan proses. Sebelum digunakan, kode untuk langkah build kustom harus dibangun ke dalam container dan dikirim ke Cloud Build.

• Untuk melakukannya, jalankan perintah berikut:

git clone https://github.com/GoogleCloudPlatform/cloud-builders-community.git cd cloud-builders-community/binauthz-attestation gcloud builds submit . --config cloudbuild.yaml cd ../.. rm -rf cloud-builders-community

Tambahkan langkah penandatanganan ke cloudbuild.yaml

Tambahkan langkah pengesahan ke pipeline Cloud Build Anda.

1. Tinjau langkah penandatanganan di bawah ini.

Hanya tinjau. Jangan Salin

#Sign the image only if the previous severity check passes - id: 'create-attestation' name: 'gcr.io/${PROJECT_ID}/binauthz-attestation:latest' args: - '--artifact-url' - '{{{ project_0.default_region | "REGION" }}}-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image' - '--attestor' - 'projects/${PROJECT_ID}/attestors/$ATTESTOR_ID' - '--keyversion' - 'projects/${PROJECT_ID}/locations/$KEY_LOCATION/keyRings/$KEYRING/cryptoKeys/$KEY_NAME/cryptoKeyVersions/$KEY_VERSION'

2. Tulis file cloudbuild.yaml dengan pipeline lengkap di bawah ini:

cat > ./cloudbuild.yaml << EOF steps: # build - id: "build" name: 'gcr.io/cloud-builders/docker' args: ['build', '-t', '{{{ project_0.default_region | "REGION" }}}-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image', '.'] waitFor: ['-'] # additional CICD checks (not shown) #Retag - id: "retag" name: 'gcr.io/cloud-builders/docker' args: ['tag', '{{{ project_0.default_region | "REGION" }}}-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image', '{{{ project_0.default_region | "REGION" }}}-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image:good'] #pushing to artifact registry - id: "push" name: 'gcr.io/cloud-builders/docker' args: ['push', '{{{ project_0.default_region | "REGION" }}}-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image:good'] #Sign the image only if the previous severity check passes - id: 'create-attestation' name: 'gcr.io/${PROJECT_ID}/binauthz-attestation:latest' args: - '--artifact-url' - '{{{ project_0.default_region | "REGION" }}}-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image:good' - '--attestor' - 'projects/${PROJECT_ID}/attestors/$ATTESTOR_ID' - '--keyversion' - 'projects/${PROJECT_ID}/locations/$KEY_LOCATION/keyRings/$KEYRING/cryptoKeys/$KEY_NAME/cryptoKeyVersions/$KEY_VERSION' images: - {{{ project_0.default_region | "REGION" }}}-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image:good EOF

3. Jalankan build:

gcloud builds submit

Tinjau build di Histori Cloud Build

Di konsol Cloud, buka halaman Cloud Build > Build history, lalu tinjau build terbaru dan keberhasilan eksekusi langkah-langkah build.

Klik Periksa progres saya untuk memverifikasi tujuan. Menambahkan langkah penandatanganan.

Tugas 7. Memberi otorisasi image bertanda tangan

Sekarang, Anda akan mengupdate GKE untuk menggunakan Otorisasi Biner dalam memvalidasi bahwa image memiliki tanda tangan dari Pemindaian kerentanan sebelum mengizinkan image berjalan.

Memperbarui Kebijakan GKE untuk Mewajibkan Pengesahan

Mewajibkan penandatanganan image oleh Attestor Anda dengan menambahkan clusterAdmissionRules ke Kebijakan BinAuth GKE Anda

Saat ini, cluster Anda menjalankan kebijakan dengan satu aturan: izinkan container dari repositori resmi, dan tolak semua yang lain.

1. Ganti kebijakan dengan konfigurasi yang diperbarui menggunakan perintah di bawah ini:

COMPUTE_ZONE={{{ project_0.default_region | "REGION" }}} cat > binauth_policy.yaml << EOM defaultAdmissionRule: enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG evaluationMode: REQUIRE_ATTESTATION requireAttestationsBy: - projects/${PROJECT_ID}/attestors/vulnz-attestor globalPolicyEvaluationMode: ENABLE clusterAdmissionRules: ${COMPUTE_ZONE}.binauthz: evaluationMode: REQUIRE_ATTESTATION enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG requireAttestationsBy: - projects/${PROJECT_ID}/attestors/vulnz-attestor EOM

2. Anda kini akan memiliki file baru di disk, yang disebut updated_policy.yaml. Sekarang, alih-alih menolak semua image dengan aturan default, aturan tersebut akan memeriksa attestor Anda terlebih dahulu untuk melakukan verifikasi.

3. Upload kebijakan baru ke Otorisasi Biner:

gcloud beta container binauthz policy import binauth_policy.yaml

Men-deploy image yang ditandatangani

1. Dapatkan ringkasan image yang bagus:

CONTAINER_PATH={{{ project_0.default_region | "REGION" }}}-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image DIGEST=$(gcloud container images describe ${CONTAINER_PATH}:good \ --format='get(image_summary.digest)')

2. Gunakan ringkasan dalam konfigurasi Kubernetes:

cat > deploy.yaml << EOM apiVersion: v1 kind: Service metadata: name: deb-httpd spec: selector: app: deb-httpd ports: - protocol: TCP port: 80 targetPort: 8080 --- apiVersion: apps/v1 kind: Deployment metadata: name: deb-httpd spec: replicas: 1 selector: matchLabels: app: deb-httpd template: metadata: labels: app: deb-httpd spec: containers: - name: deb-httpd image: ${CONTAINER_PATH}@${DIGEST} ports: - containerPort: 8080 env: - name: PORT value: "8080" EOM

3. Deploy aplikasi ke GKE

kubectl apply -f deploy.yaml

Di konsol Cloud, buka Kubernetes Engine > Workloads dan tinjau keberhasilan deployment image.

Klik Periksa progres saya untuk memverifikasi tujuan. Men-deploy image yang ditandatangani.

Tugas 8. Image yang Diblokir dan Tidak Ditandatangani

Mem-build Image

1. Gunakan Docker lokal untuk mem-build image ke cache lokal Anda:

docker build -t {{{ project_0.default_region | "REGION" }}}-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image:bad .

2. Kirim image yang tidak ditandatangani ke repo:

docker push {{{ project_0.default_region | "REGION" }}}-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image:bad

3. Dapatkan ringkasan image yang buruk:

CONTAINER_PATH={{{ project_0.default_region | "REGION" }}}-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image DIGEST=$(gcloud container images describe ${CONTAINER_PATH}:bad \ --format='get(image_summary.digest)')

4. Gunakan ringkasan dalam konfigurasi Kubernetes:

cat > deploy.yaml << EOM apiVersion: v1 kind: Service metadata: name: deb-httpd spec: selector: app: deb-httpd ports: - protocol: TCP port: 80 targetPort: 8080 --- apiVersion: apps/v1 kind: Deployment metadata: name: deb-httpd spec: replicas: 1 selector: matchLabels: app: deb-httpd template: metadata: labels: app: deb-httpd spec: containers: - name: deb-httpd image: ${CONTAINER_PATH}@${DIGEST} ports: - containerPort: 8080 env: - name: PORT value: "8080" EOM

5. Coba deploy aplikasi ke GKE

kubectl apply -f deploy.yaml

Tinjau workload di konsol dan perhatikan error yang menyatakan bahwa deployment ditolak:

Tidak ada pengesahan yang valid dan ditandatangani oleh kunci yang dipercayai oleh attestor

Klik Periksa progres saya untuk memverifikasi tujuan. Men-deploy image yang tidak bertanda tangan.

Selamat!

Anda telah mempelajari cara membuat Attestor untuk menandatangani image guna memvalidasi aturan sebelum image container diizinkan dijalankan. Anda telah mempelajari cara menulis kebijakan untuk memberi tahu Cloud Build agar mengizinkan atau menolak akses ke cluster GKE, dan Anda telah menggunakan Otorisasi Biner dengan Google Cloud KMS untuk memvalidasi tanda tangan image, serta mencegah akses image yang tidak bertanda tangan ke cluster Kubernetes.

Langkah berikutnya/pelajari lebih lanjut

• Mengamankan deployment image di Cloud Run dan Google Kubernetes Engine | Dokumentasi Cloud Build
• Panduan memulai: Mengonfigurasi kebijakan Otorisasi Biner dengan GKE | Google Cloud

Pelatihan & Sertifikasi Google Cloud

...membantu Anda mendapatkan manfaat optimal dari teknologi Google Cloud. Kelas kami mencakup keterampilan teknis dan praktik terbaik untuk membantu Anda memahami dengan cepat dan melanjutkan proses pembelajaran. Kami menawarkan pelatihan tingkat dasar hingga lanjutan dengan opsi on demand, live, dan virtual agar dapat disesuaikan dengan jadwal Anda yang sibuk. Sertifikasi membantu Anda memvalidasi dan membuktikan keterampilan serta keahlian Anda dalam teknologi Google Cloud.

Manual Terakhir Diperbarui pada 10 September 2024

Lab Terakhir Diuji pada 11 Juli 2024

Hak cipta 2024 Google LLC. Semua hak dilindungi undang-undang. Google dan logo Google adalah merek dagang dari Google LLC. Semua nama perusahaan dan produk lain mungkin adalah merek dagang masing-masing perusahaan yang bersangkutan.