Menerapkan Otorisasi Biner menggunakan Cloud Build dan GKE

---

Tutorial ini menunjukkan cara menyiapkan, mengonfigurasikan, dan menggunakan Otorisasi Biner untuk Google Kubernetes Engine (GKE). Otorisasi biner adalah proses pembuatan attestations pada image container dengan tujuan memverifikasi bahwa kriteria tertentu telah terpenuhi sebelum Anda dapat men-deploy image ke GKE.

Misalnya, Otorisasi Biner dapat memverifikasi bahwa sebuah aplikasi lulus pengujian unitnya atau bahwa sebuah aplikasi dibuat menggunakan serangkaian sistem tertentu. Untuk informasi selengkapnya, lihat Ringkasan Software Delivery Shield.

Tutorial ini ditujukan bagi praktisi yang ingin lebih memahami pemindaian kerentanan container dan otorisasi biner, serta implementasi dan penerapannya dalam pipeline CI/CD.

Tutorial ini mengasumsikan bahwa Anda sudah memahami topik dan teknologi berikut:

• Continuous integration dan deployment berkelanjutan
• Pemindaian kerentanan Common Vulnerabilities and Exposure (CVE)
• GKE
• Artifact Registry
• Cloud Build
• Cloud Key Management Service (Cloud KMS)

Tujuan

• Deploy cluster GKE untuk staging dan production.
• Membuat beberapa attestor dan pengesahan.
• Men-deploy pipeline CI/CD menggunakan Cloud Build.
• Menguji pipeline deployment.
• Mengembangkan proses break-glass.

Biaya

Dalam dokumen ini, Anda menggunakan komponen Google Cloud yang dapat ditagih berikut:

• GKE
• Cloud Build
• Cloud Source Repositories
• Artifact Registry
• Cloud KMS

Untuk membuat perkiraan biaya berdasarkan proyeksi penggunaan Anda, gunakan kalkulator harga. Pengguna baru Google Cloud mungkin memenuhi syarat untuk mendapatkan uji coba gratis.

Setelah menyelesaikan tugas yang dijelaskan dalam dokumen ini, Anda dapat menghindari penagihan berkelanjutan dengan menghapus resource yang Anda buat. Untuk mengetahui informasi selengkapnya, lihat Pembersihan.

Sebelum memulai

1. Login ke akun Google Cloud Anda. Jika Anda baru menggunakan Google Cloud, buat akun untuk mengevaluasi performa produk kami dalam skenario dunia nyata. Pelanggan baru juga mendapatkan kredit gratis senilai $300 untuk menjalankan, menguji, dan men-deploy workload.

2. Di konsol Google Cloud, pada halaman pemilih project, pilih atau buat project Google Cloud.

   Catatan: Jika tidak berencana untuk menyimpan resource yang Anda buat dalam prosedur ini, buatlah project, bukan memilih project yang ada. Setelah menyelesaikan langkah ini, Anda dapat menghapus project, yang menghapus semua resource yang terkait dengan project ini.

   Buka pemilih project

3. Pastikan penagihan telah diaktifkan untuk project Google Cloud Anda.

4. Enable the Binary Authorization, Cloud Build, Cloud KMS, GKE, Artifact Registry, Artifact Analysis, Resource Manager, and Cloud Source Repositories APIs.

   Enable the APIs

5. Di konsol Google Cloud, pada halaman pemilih project, pilih atau buat project Google Cloud.

   Catatan: Jika tidak berencana untuk menyimpan resource yang Anda buat dalam prosedur ini, buatlah project, bukan memilih project yang ada. Setelah menyelesaikan langkah ini, Anda dapat menghapus project, yang menghapus semua resource yang terkait dengan project ini.

   Buka pemilih project

6. Pastikan penagihan telah diaktifkan untuk project Google Cloud Anda.

7. Enable the Binary Authorization, Cloud Build, Cloud KMS, GKE, Artifact Registry, Artifact Analysis, Resource Manager, and Cloud Source Repositories APIs.

   Enable the APIs

8. Di konsol Google Cloud, aktifkan Cloud Shell.

   Aktifkan Cloud Shell

   Di bagian bawah Google Cloud Console, Cloud Shell sesi akan terbuka dan menampilkan perintah command line. Cloud Shell adalah lingkungan shell dengan Google Cloud CLI yang sudah terinstal, dan dengan nilai yang sudah ditetapkan untuk project Anda saat ini. Diperlukan waktu beberapa detik untuk melakukan inisialisasi sesi.

Semua perintah di dalam tutorial ini dijalankan di Cloud Shell.

Arsitektur pipeline CI/CD

Aspek penting dari siklus proses pengembangan software (SDLC) adalah memastikan dan menegakkan deployment aplikasi mengikuti proses persetujuan organisasi Anda. Salah satu metode untuk menjalankan pemeriksaan dan keseimbangan ini adalah dengan Otorisasi Biner di GKE. Pertama, Otorisasi Biner melampirkan catatan ke image kontainer. Kemudian, GKE akan memverifikasi bahwa catatan yang diperlukan telah tersedia sebelum Anda dapat men-deploy aplikasi.

Catatan ini, atau attestations, membuat pernyataan tentang image tersebut. Pengesahan dapat sepenuhnya dikonfigurasi, tetapi berikut adalah beberapa contoh umum:

• Aplikasi tersebut lulus pengujian unit.
• Aplikasi telah diverifikasi oleh tim Penjaminan Kualitas (QA).
• Aplikasi dipindai untuk mencari kerentanan dan tidak ada kerentanan yang ditemukan.

Diagram berikut menggambarkan SDLC tempat satu pengesahan diterapkan setelah pemindaian kerentanan selesai tanpa adanya kerentanan yang diketahui.

Dalam tutorial ini, Anda akan membuat pipeline CI/CD menggunakan Cloud Source Repositories, Cloud Build, Artifact Registry, dan GKE. Diagram berikut ini menggambarkan pipeline CI/CD.

Pipeline CI/CD ini terdiri dari langkah-langkah berikut:

1. Mem-build image container dengan kode sumber aplikasi.

2. Mengirim image container ke Artifact Registry.

3. Artifact Analysis, memindai image container untuk menemukan kerentanan keamanan yang diketahui atau CVE.

Jika image tidak berisi CVE dengan skor keparahan di atas lima, image tersebut akan dinyatakan tidak memiliki CVE kritikal dan akan otomatis di-deploy ke staging. Skor yang lebih besar dari lima menunjukkan kerentanan kelas menengah hingga kritis, sehingga tidak disahkan atau di-deploy.

Tim QA memeriksa aplikasi di cluster staging. Jika memenuhi persyaratan, mereka akan menerapkan pengesahan manual bahwa image container memiliki kualitas yang cukup untuk di-deploy ke production. Manifes production akan diperbarui dan aplikasi di-deploy ke cluster GKE production.

Cluster GKE dikonfigurasi untuk memeriksa image container untuk pengesahan dan menolak deployment apa pun yang tidak memiliki pengesahan yang diperlukan. Cluster GKE staging hanya memerlukan pengesahan pemindaian kerentanan, tetapi production cluster GKE memerlukan pemindaian kerentanan dan pengesahan QA.

Dalam tutorial ini, Anda akan memperkenalkan kegagalan dalam pipeline CI/CD untuk menguji dan memverifikasi penerapan ini. Terakhir, Anda menerapkan prosedur akses darurat untuk mengabaikan pemeriksaan deployment ini di GKE jika terjadi keadaan darurat.

Menyiapkan lingkungan Anda

Tutorial ini menggunakan variabel lingkungan berikut. Anda dapat mengubah nilai ini agar sesuai dengan persyaratan Anda, tetapi semua langkah dalam tutorial mengasumsikan variabel lingkungan ini ada dan berisi nilai yang valid.

1. Di Cloud Shell, tetapkan project Google Cloud tempat Anda men-deploy dan mengelola semua resource yang digunakan dalam tutorial ini:

   export PROJECT_ID="${DEVSHELL_PROJECT_ID}"
   gcloud config set project ${PROJECT_ID}
   

2. Tetapkan region tempat Anda men-deploy resource ini:

   export REGION="us-central1"
   

   Cluster GKE dan kunci Cloud KMS berada di region ini. Dalam tutorial ini, region-nya adalah us-central1. Untuk informasi selengkapnya tentang wilayah, lihat Geografi dan wilayah.

3. Tetapkan nomor project Cloud Build:

   export PROJECT_NUMBER="$(gcloud projects describe "${PROJECT_ID}" \
     --format='value(projectNumber)')"
   

4. Tetapkan email akun layanan Cloud Build:

   export CLOUD_BUILD_SA_EMAIL="${PROJECT_NUMBER}@cloudbuild.gserviceaccount.com"
   

Membuat cluster GKE

Buat dua cluster GKE dan berikan izin Identity and Access Management (IAM) untuk Cloud Build men-deploy aplikasi ke GKE. Pembuatan cluster GKE memerlukan waktu beberapa menit.

1. Di Cloud Shell, buat cluster GKE untuk staging:

   gcloud container clusters create "staging-cluster" \
     --project "${PROJECT_ID}" \
     --machine-type "n1-standard-1" \
     --region "${REGION}" \
     --num-nodes "1" \
     --binauthz-evaluation-mode=PROJECT_SINGLETON_POLICY_ENFORCE
   

2. Buat cluster GKE untuk production:

   gcloud container clusters create "prod-cluster" \
     --project "${PROJECT_ID}" \
     --machine-type "n1-standard-1" \
     --region "${REGION}" \
     --num-nodes "1" \
     --binauthz-evaluation-mode=PROJECT_SINGLETON_POLICY_ENFORCE
   

3. Berikan izin akun layanan Cloud Build untuk men-deploy ke GKE:

   gcloud projects add-iam-policy-binding "${PROJECT_ID}" \
     --member "serviceAccount:${CLOUD_BUILD_SA_EMAIL}" \
     --role "roles/container.developer"
   

Membuat kunci penandatanganan

Membuat dua kunci asimetris Cloud KMS untuk menandatangani pengesahan.

1. Di Cloud Shell, buat key ring Cloud KMS bernama binauthz:

   gcloud kms keyrings create "binauthz" \
     --project "${PROJECT_ID}" \
     --location "${REGION}"
   

2. Buat kunci Cloud KMS asimetris bernama vulnz-signer yang akan digunakan untuk menandatangani dan memverifikasi pengesahan pemindaian kerentanan:

   gcloud kms keys create "vulnz-signer" \
     --project "${PROJECT_ID}" \
     --location "${REGION}" \
     --keyring "binauthz" \
     --purpose "asymmetric-signing" \
     --default-algorithm "rsa-sign-pkcs1-4096-sha512"
   

3. Buat kunci Cloud KMS asimetris bernama qa-signer untuk menandatangani dan memverifikasi pengesahan QA:

   gcloud kms keys create "qa-signer" \
     --project "${PROJECT_ID}" \
     --location "${REGION}" \
     --keyring "binauthz" \
     --purpose "asymmetric-signing" \
     --default-algorithm "rsa-sign-pkcs1-4096-sha512"
   

Mengonfigurasi pengesahan

Anda dapat membuat catatan yang dilampirkan ke image container, memberikan izin ke akun layanan Cloud Build untuk melihat catatan tersebut, melampirkan catatan, dan membuat attestor menggunakan kunci dari langkah sebelumnya.

Membuat pengesahan pemindai kerentanan

1. Di Cloud Shell, buat catatan Artifact Analysis bernama vulnz-note:

   curl "https://containeranalysis.googleapis.com/v1/projects/${PROJECT_ID}/notes/?noteId=vulnz-note" \
     --request "POST" \
     --header "Content-Type: application/json" \
     --header "Authorization: Bearer $(gcloud auth print-access-token)" \
     --header "X-Goog-User-Project: ${PROJECT_ID}" \
     --data-binary @- <<EOF
       {
         "name": "projects/${PROJECT_ID}/notes/vulnz-note",
         "attestation": {
           "hint": {
             "human_readable_name": "Vulnerability scan note"
           }
         }
       }
   EOF
   

2. Beri akun layanan Cloud Build izin untuk melihat dan melampirkan catatan vulnz-note ke image container:

   curl "https://containeranalysis.googleapis.com/v1/projects/${PROJECT_ID}/notes/vulnz-note:setIamPolicy" \
     --request POST \
     --header "Content-Type: application/json" \
     --header "Authorization: Bearer $(gcloud auth print-access-token)" \
     --header "X-Goog-User-Project: ${PROJECT_ID}" \
     --data-binary @- <<EOF
       {
         "resource": "projects/${PROJECT_ID}/notes/vulnz-note",
         "policy": {
           "bindings": [
             {
               "role": "roles/containeranalysis.notes.occurrences.viewer",
               "members": [
                 "serviceAccount:${CLOUD_BUILD_SA_EMAIL}"
               ]
             },
             {
               "role": "roles/containeranalysis.notes.attacher",
               "members": [
                 "serviceAccount:${CLOUD_BUILD_SA_EMAIL}"
               ]
             }
           ]
         }
       }
   EOF
   

3. Buat attestor pemindai kerentanan:

   gcloud container binauthz attestors create "vulnz-attestor" \
     --project "${PROJECT_ID}" \
     --attestation-authority-note-project "${PROJECT_ID}" \
     --attestation-authority-note "vulnz-note" \
     --description "Vulnerability scan attestor"
   

4. Tambahkan kunci publik untuk kunci penandatanganan attestor:

   gcloud beta container binauthz attestors public-keys add \
     --project "${PROJECT_ID}" \
     --attestor "vulnz-attestor" \
     --keyversion "1" \
     --keyversion-key "vulnz-signer" \
     --keyversion-keyring "binauthz" \
     --keyversion-location "${REGION}" \
     --keyversion-project "${PROJECT_ID}"
   

5. Beri akun layanan Cloud Build izin untuk melihat pengesahan yang dibuat oleh vulnz-attestor:

   gcloud container binauthz attestors add-iam-policy-binding "vulnz-attestor" \
     --project "${PROJECT_ID}" \
     --member "serviceAccount:${CLOUD_BUILD_SA_EMAIL}" \
     --role "roles/binaryauthorization.attestorsViewer"
   

6. Beri izin akun layanan Cloud Build untuk menandatangani objek menggunakan kunci vulnz-signer:

   gcloud kms keys add-iam-policy-binding "vulnz-signer" \
     --project "${PROJECT_ID}" \
     --location "${REGION}" \
     --keyring "binauthz" \
     --member "serviceAccount:${CLOUD_BUILD_SA_EMAIL}" \
     --role 'roles/cloudkms.signerVerifier'
   

Membuat pengesahan QA

1. Di Cloud Shell, buat catatan Artifact Analysis bernama qa-note:

   curl "https://containeranalysis.googleapis.com/v1/projects/${PROJECT_ID}/notes/?noteId=qa-note" \
     --request "POST" \
     --header "Content-Type: application/json" \
     --header "Authorization: Bearer $(gcloud auth print-access-token)" \
     --header "X-Goog-User-Project: ${PROJECT_ID}" \
     --data-binary @- <<EOF
       {
         "name": "projects/${PROJECT_ID}/notes/qa-note",
         "attestation": {
           "hint": {
             "human_readable_name": "QA note"
           }
         }
       }
   EOF
   

2. Beri akun layanan Cloud Build izin untuk melihat dan melampirkan catatan qa-note ke image container:

   curl "https://containeranalysis.googleapis.com/v1/projects/${PROJECT_ID}/notes/qa-note:setIamPolicy" \
     --request POST \
     --header "Content-Type: application/json" \
     --header "Authorization: Bearer $(gcloud auth print-access-token)" \
     --header "X-Goog-User-Project: ${PROJECT_ID}" \
     --data-binary @- <<EOF
       {
         "resource": "projects/${PROJECT_ID}/notes/qa-note",
         "policy": {
           "bindings": [
             {
               "role": "roles/containeranalysis.notes.occurrences.viewer",
               "members": [
                 "serviceAccount:${CLOUD_BUILD_SA_EMAIL}"
               ]
             },
             {
               "role": "roles/containeranalysis.notes.attacher",
               "members": [
                 "serviceAccount:${CLOUD_BUILD_SA_EMAIL}"
               ]
             }
           ]
         }
       }
   EOF
   

3. Buat attestor QA:

   gcloud container binauthz attestors create "qa-attestor" \
     --project "${PROJECT_ID}" \
     --attestation-authority-note-project "${PROJECT_ID}" \
     --attestation-authority-note "qa-note" \
     --description "QA attestor"
   

4. Tambahkan kunci publik untuk kunci penandatanganan attestor:

   gcloud beta container binauthz attestors public-keys add \
     --project "${PROJECT_ID}" \
     --attestor "qa-attestor" \
     --keyversion "1" \
     --keyversion-key "qa-signer" \
     --keyversion-keyring "binauthz" \
     --keyversion-location "${REGION}" \
     --keyversion-project "${PROJECT_ID}"
   

5. Beri akun layanan Cloud Build izin untuk melihat pengesahan yang dibuat oleh qa-attestor:

   gcloud container binauthz attestors add-iam-policy-binding "qa-attestor" \
     --project "${PROJECT_ID}" \
     --member "serviceAccount:${CLOUD_BUILD_SA_EMAIL}" \
     --role "roles/binaryauthorization.attestorsViewer"
   

6. Berikan izin kepada tim QA Anda untuk menandatangani pengesahan:

   Catatan: Ini adalah contoh penggunaan alias tim atau grup untuk memberikan izin. Anda juga dapat menambahkan pengguna individu. Jika Anda tidak memiliki alias tim untuk diuji, ganti anggota dengan alamat email Anda, misalnya user:[e-mail].

   gcloud kms keys add-iam-policy-binding "qa-signer" \
     --project "${PROJECT_ID}" \
     --location "${REGION}" \
     --keyring "binauthz" \
     --member "group:[e-mail]" \
     --role 'roles/cloudkms.signerVerifier'
   

Menetapkan kebijakan Otorisasi Biner

Meskipun Anda membuat cluster GKE dengan --binauthz-evaluation-mode=PROJECT_SINGLETON_POLICY_ENFORCE, Anda harus membuat kebijakan yang menginstruksikan GKE tentang pengesahan apa yang diperlukan biner untuk dijalankan di cluster. Kebijakan Otorisasi Biner ada pada level project, tetapi berisi konfigurasi untuk level cluster.

Kebijakan berikut ini mengubah kebijakan default dengan cara seperti berikut:

• Mengubah evaluationMode default menjadi ALWAYS_DENY. Hanya image yang dikecualikan atau image dengan pengesahan yang diperlukan yang diizinkan untuk dijalankan di cluster.

• Mengaktifkan globalPolicyEvaluationMode, yang mengubah daftar yang diizinkan default agar hanya menyertakan image sistem yang disediakan oleh Google.

• Menentukan aturan penerimaan cluster berikut ini:

  • staging-cluster memerlukan pengesahan dari vulnz-attestor.

  • prod-cluster memerlukan pengesahan dari vulnz-attestor dan qa-attestor.

Untuk informasi selengkapnya tentang kebijakan Otorisasi Biner, baca Referensi kebijakan YAML.

1. Di Cloud Shell, buat file YAML yang menjelaskan kebijakan Otorisasi Biner untuk project Google Cloud:

   cat > ./binauthz-policy.yaml <<EOF
   admissionWhitelistPatterns:
   - namePattern: docker.io/istio/*
   defaultAdmissionRule:
     enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG
     evaluationMode: ALWAYS_DENY
   globalPolicyEvaluationMode: ENABLE
   clusterAdmissionRules:
     # Staging cluster
     ${REGION}.staging-cluster:
       evaluationMode: REQUIRE_ATTESTATION
       enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG
       requireAttestationsBy:
       - projects/${PROJECT_ID}/attestors/vulnz-attestor
   
     # Production cluster
     ${REGION}.prod-cluster:
       evaluationMode: REQUIRE_ATTESTATION
       enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG
       requireAttestationsBy:
       - projects/${PROJECT_ID}/attestors/vulnz-attestor
       - projects/${PROJECT_ID}/attestors/qa-attestor
   EOF
   

2. Upload kebijakan baru tersebut ke project Google Cloud:

   gcloud container binauthz policy import ./binauthz-policy.yaml \
     --project "${PROJECT_ID}"
   

Membuat pemeriksa pemindaian kerentanan dan mengaktifkan API

Buat image container yang digunakan sebagai langkah build di Cloud Build. Container ini membandingkan skor tingkat keparahan dari setiap kerentanan yang terdeteksi dengan nilai minimum yang dikonfigurasi. Jika skor berada di dalam nilai minimum, Cloud Build akan membuat pengesahan pada container. Jika skor berada di luar ambang batas, build akan gagal, dan tidak ada pengesahan yang dibuat.

1. Di Cloud Shell, buat repositori Artifact Registry yang baru untuk menyimpan image attestor:

   gcloud artifacts repositories create cloudbuild-helpers \
     --repository-format=DOCKER --location=${REGION}
   

2. Clone alat otorisasi biner dan sumber aplikasi sampel:

   git clone https://github.com/GoogleCloudPlatform/gke-binary-auth-tools ~/binauthz-tools
   

3. Build dan kirim container attestor pemindaian kerentanan bernama attestor ke cloudbuild-helpers Artifact Registry:

   gcloud builds submit \
     --project "${PROJECT_ID}" \
     --tag "us-central1-docker.pkg.dev/${PROJECT_ID}/cloudbuild-helpers/attestor" \
     ~/binauthz-tools
   

Menyiapkan pipeline Cloud Build

Buat repositori Cloud Source Repositories dan pemicu Cloud Build untuk aplikasi contoh dan manifes Kubernetes.

Membuat Cloud Source Repositories hello-app dan repositori Artifact Registry

1. Di Cloud Shell, buat repositori Cloud Source Repositories untuk aplikasi contoh:

   gcloud source repos create hello-app \
     --project "${PROJECT_ID}"
   

2. Buat clone repositori secara lokal:

   gcloud source repos clone hello-app ~/hello-app \
     --project "${PROJECT_ID}"
   

3. Buatlah salinan kode contoh ke dalam repositori:

   cp -R ~/binauthz-tools/examples/hello-app/* ~/hello-app
   

4. Buat repositori Artifact Registry yang baru untuk menyimpan image aplikasi:

   gcloud artifacts repositories create applications \
     --repository-format=DOCKER --location=${REGION}
   

Buat pemicu Cloud Build hello-app

1. Di konsol Google Cloud, buka halaman Triggers.

   Buka Pemicu

2. Klik Kelola Repositories.

3. Untuk repositori hello-app, klik ..., lalu pilih Tambahkan Pemicu.

4. Di jendela Setelan Pemicu, masukkan detail berikut ini:

   • Di kolom Nama, masukkan build-vulnz-deploy.
   • Untuk Peristiwa, pilih Kirim ke cabang.
   • Di kolom Repositori, pilih hello-app dari menu.
   • Di kolom Cabang, masukkan master.
   • Untuk Konfigurasi, pilih file konfigurasi Cloud Build (yaml atau json).
   • Di Lokasi, pilih Repositori, masukkan nilai default /cloudbuild.yaml.

5. Tambahkan pasangan Variabel Substitusi berikut ini:

   • _COMPUTE_REGION dengan nilai us-central1 (atau region yang Anda pilih di awal).
   • _KMS_KEYRING dengan nilai binauthz.
   • _KMS_LOCATION dengan nilai us-central1 (atau region yang Anda pilih di awal).
   • _PROD_CLUSTER dengan nilai prod-cluster.
   • _QA_ATTESTOR dengan nilai qa-attestor.
   • _QA_KMS_KEY dengan nilai qa-signer.
   • _QA_KMS_KEY_VERSION dengan nilai 1.
   • _STAGING_CLUSTER dengan nilai staging-cluster.
   • _VULNZ_ATTESTOR dengan nilai vulnz-attestor.
   • _VULNZ_KMS_KEY dengan nilai vulnz-signer.
   • _VULNZ_KMS_KEY_VERSION dengan nilai 1.

6. Klik Create.

Menguji pipeline Cloud Build

Uji pipeline CI/CD dengan committing dan mengirim aplikasi contoh ke repositori Cloud Source Repositories. Cloud Build mendeteksi perubahan, mem-build, dan men-deploy aplikasi ke staging-cluster. Pipeline menunggu hingga 10 menit untuk verifikasi QA. Setelah deployment diverifikasi oleh tim QA, proses dilanjutkan dan manifes Kubernetes production diperbarui dan Cloud Build men-deploy aplikasi ke prod-cluster.

1. Di Cloud Shell, commit dan kirim file hello-app ke repositori Cloud Source Repositories untuk memicu build:

   cd ~/hello-app
   
   git add .
   git commit -m "Initial commit"
   git push origin master
   

2. Di konsol Google Cloud, buka halaman Histori.

   Buka halaman Histori

3. Untuk melihat progres build, klik proses berjalan Cloud Build yang terbaru.

   

4. Setelah deployment ke staging-cluster selesai, buka halaman Service.

   Buka halaman Service

5. Untuk memverifikasi bahwa aplikasi tersebut berfungsi, klik link Endpoint untuk aplikasi.

6. Buka halaman Repositori.

   Buka halaman Image

7. Klik applications.

8. Klik hello-app.

9. Klik image yang Anda validasi dalam deployment staging.

   

10. Salin nilai Ringkasan dari detail image. Informasi ini diperlukan pada langkah selanjutnya

    

11. Untuk menerapkan pengesahan QA manual, ganti ... dengan nilai yang Anda salin dari detail image. Variabel DIGEST harus dalam format sha256:hash-value`.

    Langkah build Await QA attestation juga akan menghasilkan output perintah yang dapat disalin dan ditempel, seperti yang ditunjukkan di bawah ini.

    DIGEST="sha256:..." # Replace with your value
    
    gcloud beta container binauthz attestations sign-and-create \
      --project "${PROJECT_ID}" \
      --artifact-url "${REGION}-docker.pkg.dev/${PROJECT_ID}/applications/hello-app@${DIGEST}" \
      --attestor "qa-attestor" \
      --attestor-project "${PROJECT_ID}" \
      --keyversion "1" \
      --keyversion-key "qa-signer" \
      --keyversion-location "${REGION}" \
      --keyversion-keyring "binauthz" \
      --keyversion-project "${PROJECT_ID}"
    

12. Untuk memverifikasi bahwa aplikasi telah di-deploy, buka halaman Service.

    Buka halaman Service

13. Untuk melihat aplikasi, klik link endpoint.

Men-deploy gambar yang belum disahkan

Sejauh ini, aplikasi contoh tidak memiliki kerentanan. Perbarui aplikasi untuk output pesan yang berbeda dan mengubah image dasar.

1. Di Cloud Shell, ubah output dari Hello World menjadi Binary Authorization, dan ubah image dasar dari distroless menjadi debian:

   cd ~/hello-app
   sed -i "s/Hello World/Binary Authorization/g" main.go
   sed -i "s/FROM gcr\.io\/distroless\/static-debian11/FROM debian/g" Dockerfile
   

2. Commit dan kirim perubahan:

   git add .
   git commit -m "Change message and base image"
   git push origin master
   

3. Untuk memantau status pipeline CI/CD, di Konsol Google Cloud buka halaman Histori.

   Buka halaman Histori

   Build ini gagal karena CVE terdeteksi pada image.

4. Untuk memeriksa CVE yang teridentifikasi, buka halaman Images.

   Buka halaman Image

5. Klik hello-app.

6. Untuk meninjau CVE yang teridentifikasi, klik ringkasan kerentanan untuk image terbaru.

   

7. Di Cloud Shell, cobalah untuk men-deploy image baru ke production tanpa pengesahan dari pemindaian kerentanan:

   export SHA_DIGEST="[SHA_DIGEST_VALUE]"
   
   cd ~/hello-app
   sed "s/REGION/${REGION}/g" kubernetes/deployment.yaml.tpl | \
       sed "s/GOOGLE_CLOUD_PROJECT/${PROJECT_ID}/g" | \
       sed -e "s/DIGEST/${SHA_DIGEST}/g" > kubernetes/deployment.yaml
   
   gcloud container clusters get-credentials \
       --project=${PROJECT_ID} \
       --region="${REGION}" prod-cluster
   
   kubectl apply -f kubernetes
   

8. Di konsol Google Cloud, buka halaman Workload.

   Buka halaman Workload

   

   Image gagal di-deploy karena tidak ditandatangani oleh vulnz-attestor dan qa-attestor.

Prosedur akses darurat

Terkadang, Anda perlu mengizinkan perubahan yang berada di luar alur kerja normal. Untuk mengizinkan deployment image tanpa pengesahan yang diperlukan, definisi pod diberi anotasi dengan flag kebijakan akses darurat. Jika flag ini diaktifkan, GKE tetap akan memeriksa pengesahan yang diperlukan, tetapi memungkinkan image container di-deploy dan mencatat pelanggaran ke dalam log.

Untuk informasi selengkapnya tentang cara mengabaikan pemeriksaan pengesahan, lihat Mengganti kebijakan.

1. Di Cloud Shell, hapus tanda komentar pada anotasi akses darurat di manifes Kubernetes:

   sed -i "31s/^#//" kubernetes/deployment.yaml
   

2. Gunakan kubectl untuk menerapkan perubahan.

   kubectl apply -f kubernetes
   

3. Untuk memverifikasi bahwa perubahan telah di-deploy ke prod-cluster, buka halaman Workload di Konsol Google Cloud.

   Buka halaman Workload

   Pesan error deployment kini sudah hilang.

4. Untuk memverifikasi bahwa aplikasi telah di-deploy, buka halaman Service.

   Buka halaman Service

5. Untuk melihat aplikasi, klik link endpoint.

Pembersihan

Agar tidak perlu membayar biaya pada akun Google Cloud Anda untuk resource yang digunakan dalam tutorial ini, hapus project yang berisi resource tersebut, atau simpan project dan hapus setiap resource.

Menghapus project

Perhatian: Menghapus project memiliki efek berikut:
• Semua hal dalam project akan dihapus. Jika menggunakan project yang sudah ada untuk tugas dalam dokumen ini, saat Anda menghapusnya, pekerjaan lain yang telah Anda lakukan dalam project tersebut juga akan terhapus.
• Project ID kustom hilang. Saat membuat project ini, Anda mungkin telah membuat project ID kustom yang ingin digunakan di masa mendatang. Untuk mempertahankan URL yang menggunakan project ID, seperti URL appspot.com, hapus resource yang dipilih di dalam project, bukan menghapus seluruh project.
1. Di konsol Google Cloud, buka halaman Manage resource.

   Buka Manage resource

2. Pada daftar project, pilih project yang ingin Anda hapus, lalu klik Delete.
3. Pada dialog, ketik project ID, lalu klik Shut down untuk menghapus project.

Langkah selanjutnya

• Praktik Terbaik untuk membuat Container.
• Men-deploy aplikasi web dalam container.
• Continuous delivery bergaya GitOps dengan Cloud Build.
• Image dasar yang dikelola.
• Pelajari arsitektur referensi, diagram, dan praktik terbaik tentang Google Cloud. Lihat Cloud Architecture Center kami.