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:
Untuk membuat perkiraan biaya berdasarkan proyeksi penggunaan Anda,
gunakan kalkulator harga.
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
- 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.
-
Di konsol Google Cloud, pada halaman pemilih project, pilih atau buat project Google Cloud.
-
Pastikan penagihan telah diaktifkan untuk project Google Cloud Anda.
-
Enable the Binary Authorization, Cloud Build, Cloud KMS, GKE, Artifact Registry, Artifact Analysis, Resource Manager, and Cloud Source Repositories APIs.
-
Di konsol Google Cloud, pada halaman pemilih project, pilih atau buat project Google Cloud.
-
Pastikan penagihan telah diaktifkan untuk project Google Cloud Anda.
-
Enable the Binary Authorization, Cloud Build, Cloud KMS, GKE, Artifact Registry, Artifact Analysis, Resource Manager, and Cloud Source Repositories APIs.
-
Di konsol Google Cloud, 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:
Mem-build image container dengan kode sumber aplikasi.
Mengirim image container ke Artifact Registry.
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.
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}
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.Tetapkan nomor project Cloud Build:
export PROJECT_NUMBER="$(gcloud projects describe "${PROJECT_ID}" \ --format='value(projectNumber)')"
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.
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
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
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.
Di Cloud Shell, buat key ring Cloud KMS bernama
binauthz
:gcloud kms keyrings create "binauthz" \ --project "${PROJECT_ID}" \ --location "${REGION}"
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"
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
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
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
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"
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}"
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"
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
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
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
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"
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}"
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"
Berikan izin kepada tim QA Anda untuk menandatangani pengesahan:
gcloud kms keys add-iam-policy-binding "qa-signer" \ --project "${PROJECT_ID}" \ --location "${REGION}" \ --keyring "binauthz" \ --member "group:qa-team@example.com" \ --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 menjadiALWAYS_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 darivulnz-attestor
.prod-cluster
memerlukan pengesahan darivulnz-attestor
danqa-attestor
.
Untuk informasi selengkapnya tentang kebijakan Otorisasi Biner, baca Referensi kebijakan YAML.
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
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.
Di Cloud Shell, buat repositori Artifact Registry yang baru untuk menyimpan image attestor:
gcloud artifacts repositories create cloudbuild-helpers \ --repository-format=DOCKER --location=${REGION}
Clone alat otorisasi biner dan sumber aplikasi sampel:
git clone https://github.com/GoogleCloudPlatform/gke-binary-auth-tools ~/binauthz-tools
Build dan kirim container attestor pemindaian kerentanan bernama
attestor
kecloudbuild-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
Di Cloud Shell, buat repositori Cloud Source Repositories untuk aplikasi contoh:
gcloud source repos create hello-app \ --project "${PROJECT_ID}"
Buat clone repositori secara lokal:
gcloud source repos clone hello-app ~/hello-app \ --project "${PROJECT_ID}"
Buatlah salinan kode contoh ke dalam repositori:
cp -R ~/binauthz-tools/examples/hello-app/* ~/hello-app
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
Di konsol Google Cloud, buka halaman Triggers.
Klik Kelola Repositories.
Untuk repositori
hello-app
, klik ..., lalu pilih Tambahkan Pemicu.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
.
- Di kolom Nama, masukkan
Tambahkan pasangan Variabel Substitusi berikut ini:
_COMPUTE_REGION
dengan nilaius-central1
(atau region yang Anda pilih di awal)._KMS_KEYRING
dengan nilaibinauthz
._KMS_LOCATION
dengan nilaius-central1
(atau region yang Anda pilih di awal)._PROD_CLUSTER
dengan nilaiprod-cluster
._QA_ATTESTOR
dengan nilaiqa-attestor
._QA_KMS_KEY
dengan nilaiqa-signer
._QA_KMS_KEY_VERSION
dengan nilai1
._STAGING_CLUSTER
dengan nilaistaging-cluster
._VULNZ_ATTESTOR
dengan nilaivulnz-attestor
._VULNZ_KMS_KEY
dengan nilaivulnz-signer
._VULNZ_KMS_KEY_VERSION
dengan nilai1
.
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
.
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
Di konsol Google Cloud, buka halaman Histori.
Untuk melihat progres build, klik proses berjalan Cloud Build yang terbaru.
Setelah deployment ke
staging-cluster
selesai, buka halaman Service.Untuk memverifikasi bahwa aplikasi tersebut berfungsi, klik link Endpoint untuk aplikasi.
Buka halaman Repositori.
Klik
applications
.Klik
hello-app
.Klik image yang Anda validasi dalam deployment staging.
Salin nilai Ringkasan dari detail image. Informasi ini diperlukan pada langkah selanjutnya
Untuk menerapkan pengesahan QA manual, ganti
...
dengan nilai yang Anda salin dari detail image. VariabelDIGEST
harus dalam formatsha256: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}"
Untuk memverifikasi bahwa aplikasi telah di-deploy, buka halaman Service.
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.
Di Cloud Shell, ubah output dari
Hello World
menjadiBinary Authorization
, dan ubah image dasar daridistroless
menjadidebian
: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
Commit dan kirim perubahan:
git add . git commit -m "Change message and base image" git push origin master
Untuk memantau status pipeline CI/CD, di Konsol Google Cloud buka halaman Histori.
Build ini gagal karena CVE terdeteksi pada image.
Untuk memeriksa CVE yang teridentifikasi, buka halaman Images.
Klik
hello-app
.Untuk meninjau CVE yang teridentifikasi, klik ringkasan kerentanan untuk image terbaru.
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
Di konsol Google Cloud, buka halaman Workload.
Image gagal di-deploy karena tidak ditandatangani oleh
vulnz-attestor
danqa-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.
Di Cloud Shell, hapus tanda komentar pada anotasi akses darurat di manifes Kubernetes:
sed -i "31s/^#//" kubernetes/deployment.yaml
Gunakan
kubectl
untuk menerapkan perubahan.kubectl apply -f kubernetes
Untuk memverifikasi bahwa perubahan telah di-deploy ke
prod-cluster
, buka halaman Workload di Konsol Google Cloud.Pesan error deployment kini sudah hilang.
Untuk memverifikasi bahwa aplikasi telah di-deploy, buka halaman Service.
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
- Di konsol Google Cloud, buka halaman Manage resource.
- Pada daftar project, pilih project yang ingin Anda hapus, lalu klik Delete.
- 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.