Validasi berkelanjutan (CV) adalah fitur Otorisasi Biner yang memungkinkan Anda memantau Pod yang berjalan di Google Kubernetes Engine (GKE) untuk memastikan bahwa image container terkaitnya terus mematuhi kebijakan platform berbasis pemeriksaan Otorisasi Biner yang Anda tentukan.
Saat menentukan bahwa Pod melanggar kebijakan platform, CV akan mencatat pelanggaran ke Cloud Logging.
CV dengan kebijakan platform menggantikan validasi berkelanjutan lama.
Mengapa menggunakan CV?
Meskipun penerapan Otorisasi Biner menyediakan validasi image satu kali saat Anda men-deploy image container, CV terus memantau bahwa image yang terkait dengan Pod yang sedang berjalan terus mematuhi kebijakan Anda.
Oleh karena itu, saat mengaktifkan penerapan Otorisasi Biner dan CV dengan kebijakan berbasis pemeriksaan, Anda dapat memastikan kesesuaian kebijakan divalidasi di seluruh siklus proses orkestrasi.
CV berguna dalam skenario berikut:
Perubahan kebijakan: Saat Anda memperbarui kebijakan penerapan project-singleton Otorisasi Biner, Otorisasi Biner hanya memvalidasi image yang di-deploy setelah update. Pod yang sudah berjalan tidak akan terpengaruh. Library tersebut terus berjalan meskipun Otorisasi Biner, dengan menggunakan kebijakan yang telah diperbarui, sekarang akan memblokir image yang sama agar tidak di-deploy.
Oleh karena itu, saat memperbarui kebijakan singleton project Otorisasi Biner, sebaiknya Anda juga membuat atau memperbarui kebijakan platform CV agar sesuai dengan kebijakan singleton project. Dengan demikian, CV akan menginformasikan bahwa Anda telah menjalankan Pod yang melanggar kebijakan yang telah Anda update.
Memantau metadata gambar: CV memberikan pemeriksaan khusus untuk melihat perubahan pada metadata gambar, termasuk hal berikut:
- Pengesahan: Catat CV saat pengesahan pada image Pod tidak lagi valid.
- Keaktualan: Log CV saat mendeteksi bahwa gambar Pod tidak lagi baru.
- Provenance: CV dapat memeriksa apakah image Pod dibuat dengan builder tepercaya, menggunakan konfigurasi build yang berada di repositori sumber tepercaya.
- Tanda tangan Sigstore: Membuat log CV saat image pada Pod tidak memiliki tanda tangan Sigstore yang valid.
- Direktori tepercaya: Logging CV saat image Pod berada di direktori repositori yang tidak tercantum dalam kebijakan platform Anda.
- Kerentanan: CV membuat log saat kerentanan teridentifikasi dalam image Pod.
Pemantauan uji coba: Jika Anda mengaktifkan uji coba, Otorisasi Biner memungkinkan semua gambar di-deploy. Dengan mengaktifkan CV melalui kebijakan platform yang sesuai dengan kebijakan singleton project Anda, CV secara rutin akan mencatat gambar yang melanggar kebijakan platform.
Pemantauan akses darurat: Saat Anda men-deploy Pod menggunakan breaklight, Otorisasi Biner akan mengabaikan penegakan kebijakan singleton project dan mencatat satu peristiwa ke Cloud Audit Logs. Namun, dengan menggunakan kebijakan platform yang sesuai, CV akan terus mencatat Pod yang melanggar kebijakan secara rutin, termasuk Pod yang di-deploy menggunakan akses darurat.
Cara kerja CV
Untuk menggunakan CV, Anda harus mengaktifkannya di cluster GKE.
Setelah men-deploy image di cluster, CV akan memantau Pod terkait untuk memastikan kesesuaiannya dengan kebijakan platform berbasis pemeriksaan Anda.
CV tidak mendukung tag gambar, selain yang ditentukan dalam gambar pengecualian.
CV secara rutin meninjau Pod yang sedang berjalan
Untuk memantau Pod yang sedang berjalan, CV meninjau gambar yang terkait dengan setiap Pod setidaknya setiap 24 jam. CV juga memantau container init.
Selama setiap peninjauan, CV akan mengambil daftar gambar yang terkait dengan setiap Pod. CV kemudian memverifikasi bahwa informasi gambar memenuhi kebijakan platform.
Pelanggaran log CV terhadap kebijakan platform
Saat menentukan bahwa gambar melanggar kebijakan platform, CV akan mencatat pelanggaran dan temuan lainnya ke Cloud Logging. Entri log terpisah ditulis untuk setiap kebijakan platform yang dilanggar, untuk setiap pod.
Saat CV mengevaluasi image Pod menggunakan kebijakan platform, gambar mungkin telah memenuhi beberapa pemeriksaan dan melanggar yang lainnya. CV menghasilkan entri log setiap kali gambar Pod melanggar satu atau beberapa pemeriksaan. Entri log hanya berisi image yang melanggar kebijakan platform. Jika semua gambar memenuhi semua pemeriksaan, tidak ada entri log yang dihasilkan.
Sampai Pod dengan image yang tidak sesuai kebijakan dihentikan, CV akan terus mencatat pelanggaran kebijakan. Pod yang tidak sesuai dengan kebijakan yang dihentikan selama interval antar-pemeriksaan akan dicatat selama peninjauan CV berikutnya.
CV tidak menghentikan Pod yang sedang berjalan.
CV menggunakan resource feed
Untuk mengambil informasi tentang Pod yang berjalan di cluster GKE,
CV akan membuat resource feed yang disebut binauthz-cv-cai-feed
.
Kebijakan platform CV
Untuk menggunakan CV, Anda harus mengonfigurasi kebijakan platform terlebih dahulu.
Kebijakan platform berbeda dengan kebijakan Otorisasi Biner lama, yang juga disebut kebijakan project-singleton. Meskipun project deployment hanya dapat memiliki satu kebijakan project-singleton lama, Anda dapat mengonfigurasi beberapa kebijakan platform. Setiap kebijakan platform dapat berada dalam satu atau beberapa project.
Kebijakan platform hanya berfungsi dengan CV dan tidak mendukung penerapan Otorisasi Biner. Oleh karena itu, jika Anda ingin menggunakan penerapan Otorisasi Biner dan pemantauan CV, buat kebijakan singleton project untuk penerapan dan kebijakan platform untuk pemantauan.
Misalnya, Anda ingin mengonfigurasi Otorisasi Biner untuk menerapkan bahwa image Anda memiliki pengesahan sebelum diizinkan untuk di-deploy, dan Anda juga ingin memastikan bahwa Pod yang sedang berjalan sesuai dengan persyaratan yang sama. Untuk melakukannya, konfigurasikan kebijakan penerapan singleton project dengan attestor. Selanjutnya, buat kebijakan platform dengan pemeriksaan pengesahan penandatanganan sederhana yang memiliki pengautentikasi berdasarkan catatan dan kunci publik yang sama dengan attestor.
Kebijakan platform bersifat spesifik untuk platform tertentu. GKE adalah satu-satunya platform yang didukung.
Anda dapat mengonfigurasi pemeriksaan di kebijakan platform. Pemeriksaan dikelompokkan menjadi satu atau beberapa kumpulan pemeriksaan. Setiap kumpulan pemeriksaan dapat menentukan satu atau beberapa pemeriksaan.
Kebijakan platform dapat mengecualikan gambar dari evaluasi oleh CV.
Izin yang diperlukan
Untuk mencantumkan atau menjelaskan kebijakan platform, Anda memerlukan
peran binaryauthorization.policyViewer
. Untuk membuat, mengubah, dan menghapus kebijakan
platform, Anda memerlukan peran binaryauthorization.policyEditor
.
Untuk informasi selengkapnya, lihat Mengelola kebijakan platform.
Pembaruan kebijakan
Memperbarui kebijakan platform akan menimpa kebijakan yang ada dengan deskripsi kebijakan yang Anda berikan dalam file YAML. Untuk menambahkan pemeriksaan baru ke kebijakan platform yang ada, sebaiknya describe kebijakan yang ada, simpan ke file YAML, tambahkan pemeriksaan baru, lalu perbarui kebijakan menggunakan file yang diperbarui.
Beberapa kebijakan platform
Anda dapat membuat kebijakan platform di project yang sama dengan cluster (kebijakan platform lokal) atau di project lainnya.
Karena Anda dapat mengonfigurasi sejumlah kebijakan platform, beri nama setiap kebijakan dengan
nama resource yang unik. Saat menjalankan perintah gcloud CLI, Anda dapat merujuk ke kebijakan platform lokal menggunakan ID-nya. Saat merujuk pada kebijakan platform di
project lain, gunakan nama resource dalam format berikut:
projects/POLICY_PROJECT_ID/platforms/gke/policies/POLICY_ID
Anda dapat memilih kebijakan platform yang akan dikaitkan dengan setiap cluster GKE, baik itu kebijakan platform lokal atau kebijakan platform yang berbeda.
Kebijakan beberapa pemeriksaan per platform
Anda dapat mengonfigurasi beberapa pemeriksaan di setiap kebijakan platform dengan menambahkannya ke
blok checks
kebijakan. Untuk mempelajari lebih lanjut pemeriksaan tertentu yang
dapat Anda konfigurasi, lihat pemeriksaan.
Jika kebijakan platform CV Anda menentukan lebih dari satu pemeriksaan, image yang dievaluasi oleh satu pemeriksaan akan terus dievaluasi oleh pemeriksaan lainnya.
Otorisasi Biner mengevaluasi semua pemeriksaan yang dikonfigurasi dalam kebijakan platform untuk setiap gambar kecuali jika gambar tersebut cocok dengan pola daftar gambar yang diizinkan. Untuk informasi selengkapnya, lihat Mengecualikan gambar.
Penyiapan satu project
Anda dapat menyiapkan CV dalam satu project.
Dalam penyiapan project tunggal, Otorisasi Biner otomatis menyiapkan peran yang diperlukan dalam agen layanan Otorisasi Biner.
Jika cluster GKE, kebijakan platform yang terikat dengan cluster, dan metadata yang diperlukan oleh pemeriksaan semuanya berada dalam project yang sama, tidak ada peran Identity and Access Management (IAM) tambahan yang diperlukan.
Untuk mempelajari lebih lanjut cara mengonfigurasi penyiapan multi-project untuk meningkatkan keamanan, lihat Pemisahan fokus.
Penyiapan multi-project
Jika Anda mengonfigurasi penyiapan CV multi-project dengan kebijakan platform, kebijakan platform, image, cluster GKE, dan jenis resource lain yang bergantung pada CV masing-masing dapat berada di project yang berbeda.
Dalam penyiapan multi-project, penting untuk mengetahui tujuan setiap project dan resource yang diperlukan CV untuk mengakses serta menyiapkan peran dan izin IAM yang diperlukan.
Cara menggunakan CV
Untuk menggunakan CV, Anda biasanya melakukan hal berikut:
- Tentukan pemeriksaan yang ingin digunakan.
- Membuat satu atau beberapa kebijakan platform menggunakan file YAML kebijakan. File ini menentukan pemeriksaan mana yang ingin Anda gunakan.
- Buat kebijakan platform. Kebijakan ini dapat disimpan dalam project pilihan Anda.
- Pilih apakah akan mengaktifkan CV di cluster individual atau di fleet.
- Periksa log CV di Logging untuk mengetahui peristiwa.
- Tinjau log dan perbarui build Anda serta proses lainnya untuk menghasilkan image yang memenuhi pemeriksaan.
Cek
Bagian ini menjelaskan pemeriksaan spesifik yang diberikan CV.
Kebijakan berbasis pemeriksaan memiliki format kanonis berikut:
gkePolicy: checkSets: - checks: - CHECK_TYPE1: CHECK_TYPE1_PARAMETERS displayName: CHECK_TYPE1_DISPLAY_NAME - CHECK_TYPE2: CHECK_TYPE2_PARAMETERS displayName: CHECK_TYPE2_DISPLAY_NAME displayName: CHECK_SET_DISPLAY_NAME
Kolom displayName
di checks
dan checkSets
bersifat opsional. Pesan ini hanya digunakan
saat CV mencatat pelanggaran kebijakan ke dalam log. Bagian ini dihilangkan pada beberapa
contoh nanti dalam panduan ini.
Selalu tolak pemeriksaan
Pemeriksaan always-toy, menjamin bahwa semua gambar yang terpengaruh oleh evaluasi pemeriksaan ini akan gagal. Setiap kali CV meninjau Pod yang menjalankan pemeriksaan ini, CV akan menghasilkan entri log untuk setiap Pod.
Anda dapat menggabungkan pemeriksaan yang selalu ditolak dengan daftar yang diizinkan atau beberapa kumpulan pemeriksaan untuk memastikan bahwa Otorisasi Biner selalu menghasilkan log untuk Pod dalam kasus tertentu.
Untuk menggunakan pemeriksaan selalu tolak, tambahkan alwaysDeny: true
dalam blok checks
, sebagai
berikut:
gkePolicy:
checkSets:
- displayName: "My check set"
checks:
- alwaysDeny: true
Nilai alwaysDeny
tidak dapat ditetapkan ke false
. Sebagai gantinya, hapus tanda centang.
Untuk melihat contoh penggunaan pemeriksaan selalu tolak, lihat Menggunakan beberapa kumpulan pemeriksaan.
Pemeriksaan keaktualan gambar
Pemeriksaan keaktualan gambar menghitung durasi gambar berjalan dan mencatat log saat durasi melampaui batas, maxUploadAgeDays
.
Pada contoh YAML kebijakan platform berikut, CV mencatat Pod ke dalam log dengan image yang diupload ke repositori tempatnya di-deploy lebih dari 30 hari yang lalu.
gkePolicy:
checkSets:
checks:
- imageFreshnessCheck:
maxUploadAgeDays: 30
displayName: "My image freshness check"
displayName: "My check set"
Pemeriksaan pengesahan penandatanganan yang sederhana
Anda dapat menggunakan pemeriksaan pengesahan penandatanganan sederhana CV untuk memeriksa bahwa setiap image Pod memiliki pengesahan yang valid dan bertanda tangan.
Pemeriksaan ini setara dengan evaluasi pengesahan dalam kebijakan penerapan Otorisasi Biner. Anda dapat mengonfigurasi pemeriksaan ini dengan catatan dan kunci yang sama dengan yang Anda gunakan di attestor. Sebaiknya gunakan pemeriksaan ini, bukan validasi berkelanjutan lama.
Berikut adalah contoh kebijakan platform dengan pemeriksaan pengesahan penandatanganan sederhana:
gkePolicy:
checkSets:
checks:
simpleSigningAttestationCheck:
containerAnalysisAttestationProjects:
- "projects/my-attestation-project1"
- "projects/my-attestation-project2"
attestationAuthenticators:
pkixPublicKeySet:
pkixPublicKeys:
publicKeyPem: |
-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQxXxgAEvgQuW1FHYZPB2PTQfOJKUkS9sjMO/1os10xOWrhl1kQo4EnzMOovROWVLo+m9mcwp7nRQ2qQDThZdSFi0nFJ1A==
-----END PUBLIC KEY-----
signatureAlgorithm: ECDSA_P256_SHA256
Sebagai ganti attestor Otorisasi Biner,
pemeriksaan pengesahan CV memiliki pengautentikasi. Anda menentukan
autentikasi secara langsung dalam kebijakan, di blok attestationAuthenticators
.
Dalam kebijakan platform, simpleSigningAttestationCheck
dapat memiliki beberapa
attestationAuthenticators
dan beberapa kunci di setiap pkixPublicKeySet
. Pemeriksaan
ini akan terpenuhi saat setiap image Pod memiliki pengesahan valid yang ditandatangani
dengan kunci apa pun di pkixPublicKeySet
pengautentikasi apa pun.
Kebijakan platform CV berbeda dari kebijakan penegakan singleton project dalam hal berikut:
- Kunci PGP tidak didukung.
- Attestor tidak diperlukan. Sebagai gantinya, Anda membuat kunci secara manual, lalu describe kebijakan platform untuk mengambil ID kunci yang kemudian digunakan untuk membuat pengesahan.
- Anda dapat membuat dan menandatangani payload secara manual, membuat file JSON pengesahan, dan membuat pengesahan menggunakan Artifact Analysis API.
- Anda masih membuat Catatan Analisis Artefak, tetapi tidak
menentukannya dalam kebijakan. Sebagai gantinya, CV akan mencari
pengesahan di setiap project yang tercantum di
kolom
containerAnalysisAttestationProjects
. - Pengesahan masih disimpan dalam kemunculan Analisis Artefak, tetapi dapat disimpan di lebih dari satu project.
- Anda harus secara eksplisit menentukan satu atau beberapa project yang berisi pengesahan
dengan menggunakan nama resource
projects/ATTESTATION_PROJECT_ID
.
CV tidak mendukung tag gambar, kecuali tag yang ditentukan dalam gambar dikecualikan.
Jika gambar di-deploy dengan tag gambar, bukan ringkasan, CV akan mengevaluasinya terlebih dahulu berdasarkan gambar yang dikecualikan, karena daftar yang diizinkan dapat menyertakan tag. Jika gambar tidak dikecualikan, CV akan mencoba menemukan ringkasan gambar. Karena tidak ada satu pun, gambar melanggar pemeriksaan.
Pemeriksaan SLSA
Pemeriksaan SLSA memeriksa provenance yang ditentukan SLSA untuk image Pod.
Berikut adalah contoh konfigurasi YAML kebijakan platform CV:
gkePolicy:
checkSets:
checks:
imageAllowlist:
allowPattern: "gcr.io/my-images/not-built-by-GCB/**"
- slsaCheck:
rules:
trustedBuilder: GOOGLE_CLOUD_BUILD
attestationSource:
- containerAnalysisAttestationProjects: "projects/attestation-project1"
- containerAnalysisAttestationProjects: "projects/attestation-project2"
# Require that images were built using a checked-in top-level config file.
configBasedBuildRequired: true
# Which repos the config file can be from.
trustedSourceRepoPatterns:
- "source.cloud.google.com/my-project/my-source-repo"
- "github.com/my-github-user/*"
displayName: "My SLSA check"
displayName: "My check set"
Saat CV meninjau gambar menggunakan kebijakan platform ini, hal berikut akan diperiksa:
Image harus dibuat oleh builder tepercaya. Cloud Build adalah satu-satunya builder tepercaya yang didukung pemeriksaan SLSA.
Cloud Build harus sudah membuat pengesahan di
attestation-project1
atauattestation-project2
.Image harus dibuat menggunakan file konfigurasi level atas dari salah satu repositori tepercaya berikut:
- Repositori
source.cloud.google.com/my-project/my-source-repo/
- Repositori apa pun di
github.com/my-github-user/
- Repositori
Gambar di
gcr.io/my-images/not-built-by-GCB/
atau subdirektorinya (yang tidak dibuat oleh Cloud Build) dikecualikan dari pemeriksaan karena akan melanggarnya.
Pemeriksaan tanda tangan Sigstore
Pemeriksaan tanda tangan Sigstore memverifikasi bahwa gambar telah ditandatangani menggunakan tanda tangan Sigstore.
Pemeriksaan ini hanya mendukung image yang dihosting di Artifact Registry. Pemeriksaan ini memeriksa apakah tanda tangan yang diambil dari Artifact Registry dapat berhasil diverifikasi oleh kunci apa pun dalam kebijakan.
Contoh kebijakan platform berikut menjelaskan cara mengonfigurasi pemeriksaan tanda tangan Sigstore:
gkePolicy:
checkSets:
- checks:
- displayName: sigstore-signature-check
sigstoreSignatureCheck:
sigstoreAuthorities:
- displayName: sigstore-authority
publicKeySet:
publicKeys:
publicKeyPem: |
-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQxXxgAEvgQuW1FHYZPB2PTQfOJKUkS9sjMO/1os10xOWrhl1kQo4EnzMOovROWVLo+m9mcwp7nRQ2qQDThZdSFi0nFJ1A==
-----END PUBLIC KEY-----
Dalam kebijakan platform, sigstoreSignatureCheck
dapat memiliki beberapa
sigstoreAuthorities
dan beberapa kunci di setiap publicKeySet
. Pemeriksaan ini akan terpenuhi jika setiap image Pod memiliki pengesahan valid yang ditandatangani dengan kunci apa pun di publicKeySet
pengautentikasi apa pun.
Pemeriksaan direktori tepercaya
Pemeriksaan direktori tepercaya akan memeriksa apakah image Pod berada di salah satu direktori tepercaya yang Anda tetapkan dalam kebijakan platform.
Saat menggunakan pemeriksaan ini, sebaiknya Anda juga mengamankan repositori yang Anda cantumkan sebagai direktori tepercaya dalam kebijakan Anda dari akses yang tidak sah.
Contoh kebijakan platform berikut menjelaskan cara mengonfigurasi pemeriksaan direktori tepercaya:
gkePolicy:
checkSets:
checks:
trustedDirectoryCheck:
trustedDirPatterns:
- "gcr.io/my-project/gcr-directory"
- "us-central1-docker.pkg.dev/my-project/ar-directory"
displayName: "My trusted directory check"
displayName: "My check set"
Dalam kebijakan platform contoh, trustedDirPatterns
mencantumkan direktori tepercaya. Jika semua image Pod berada di direktori yang tercantum, berarti image tersebut sesuai dengan kebijakan. Image Pod yang tidak berada di direktori yang tercantum
melanggar kebijakan, dan CV mencatat pelanggaran dalam log.
Pemeriksaan kerentanan
Pemeriksaan kerentanan menggunakan pemindaian kerentanan Artifact Analysis untuk memeriksa apakah image Pod berisi kerentanan atau tidak. Hal ini mencakup kerentanan baru yang diidentifikasi oleh pemindaian kerentanan sejak Pod di-deploy. Pada pemeriksaan kerentanan, Anda dapat mengonfigurasi batas tingkat keparahan kerentanan dan kerentanan tertentu (sebagai CVE). Gambar dengan kerentanan yang melanggar pemeriksaan kerentanan akan dicatat ke dalam Logging.
Untuk menggunakan pemeriksaan ini, Anda harus mengaktifkan pemindaian kerentanan terlebih dahulu di Artifact Analysis.
Contoh konfigurasi kebijakan platform berikut berisi pemeriksaan kerentanan:
gkePolicy:
checkSets:
- displayName: "Default check set"
checks:
- vulnerabilityCheck:
maximumFixableSeverity: MEDIUM
maximumUnfixableSeverity: HIGH
allowedCves:
- "CVE-2022-11111"
- "CVE-2022-22222"
blockedCves:
- "CVE-2022-33333"
- "CVE-2022-44444"
containerAnalysisVulnerabilityProjects: "projects/my-project"
Dalam contoh ini, maximumUnfixableSeverity
dan maximumFixableSeverity
menentukan
tingkat keparahan Sistem Skor Kerentanan Umum (CVSS) yang terkait
dengan kerentanan yang dapat diidentifikasi oleh Analisis Artefak.
Selain itu, blockedCves
mencantumkan Eksposur Kerentanan Umum (CVE) tertentu. Jika kerentanan yang teridentifikasi melebihi salah satu tingkat keparahan yang ditetapkan
atau cocok dengan salah satu CVE yang tercantum di blockedCves
, dan tidak cocok dengan
salah satu CVE yang tercantum di allowedCves
, CV akan mencatat entri ke
Logging.
Validasi kebijakan yang diperbarui
Setelah memperbarui kebijakan platform CV, sebaiknya Anda memvalidasi bahwa Otorisasi Biner dan CV terus beroperasi seperti yang Anda harapkan.
Memvalidasi konfigurasi
Untuk memeriksa konfigurasi Anda, periksa kebijakan project-singleton Otorisasi Biner dan Kebijakan platform CV.
Validasi operasi
Untuk memvalidasi bahwa Otorisasi Biner dan CV beroperasi seperti yang diharapkan, Anda dapat men-deploy Pod pengujian, lalu memeriksa entri Otorisasi Biner di Logging.
Kecualikan gambar dengan daftar yang diizinkan
Saat membuat kebijakan platform, Anda dapat mengecualikan gambar dari pemeriksaan dengan menambahkan URL-nya ke daftar yang diizinkan. Daftar yang diizinkan di tingkat kebijakan mengecualikan image dari seluruh kebijakan. Daftar yang diizinkan di tingkat kumpulan pemeriksaan dikecualikan dari pemeriksaan yang ditetapkan, dan hanya berlaku jika kumpulan pemeriksaan tersebut dievaluasi. Daftar yang diizinkan dalam pemeriksaan hanya mengecualikan gambar dari pemeriksaan tersebut.
Pola daftar yang diizinkan adalah pola yang cocok dengan satu atau beberapa URL gambar. Pola daftar yang diizinkan dapat berupa salah satu dari pola berikut:
- Awalan nama gambar, diakhiri dengan karakter pengganti
*
atau**
. - Hanya nama gambar, tanpa tag atau ringkasan.
- Nama gambar dengan tag (atau awalan tag dengan karakter pengganti
*
). - Nama image dengan ringkasan.
- Nama gambar dengan tag dan ringkasan.
Berikut adalah contoh pola daftar yang diizinkan:
us-central1.pkg.dev/my-project/my-image:latest@sha256:77b0b75136b9bd0fd36fb50f4c92ae0dbdbbe164ab67885e736fa4374e0cbb8c
cocok dengan nama gambar, tag, dan ringkasan yang sama persis.us-central1.pkg.dev/my-project/my-image:latest
cocok dengan nama dan tag, dengan ringkasan apa pun (atau tanpa ringkasan).us-central1.pkg.dev/my-image:foo*
cocok dengan nama dan awalan tag (sepertimyimage:foo
danmyimage:foobar
), dengan ringkasan apa pun (atau tanpa ringkasan).us-central1.pkg.dev/my-project/my-image@sha256:77b0b75136b9bd0fd36fb50f4c92ae0dbdbbe164ab67885e736fa4374e0cbb8c
cocok dengan nama dan ringkasan, dengan tag apa pun (atau tanpa tag).us-central1.pkg.dev/my-project/my-image
cocok dengan namanya, dengan tag dan/atau ringkasan apa pun.
Karakter pengganti *
dan **
dapat digunakan untuk mencocokkan nama apa pun dengan
awalan tertentu. *
cocok dengan akhiran yang tidak menyertakan /
. **
cocok dengan
akhiran yang dapat menyertakan /
, tetapi **
hanya dapat digunakan setelah /
. Perhatikan bahwa
*
dan **
tidak dapat digunakan dengan tag atau ringkasan.
Contoh:
us-central1.pkg.dev/my-project/my-image*
cocok denganus-central1.pkg.dev/myproject/my-image
,us-central1.pkg.dev/myproject/my-image1
, danus-central1.pkg.dev/myproject/my-image2
, dengan tag dan/atau ringkasan apa pun.us-central1.pkg.dev/my-project/**
cocok denganus-central1.pkg.dev/myproject/my-image
danus-central1.pkg.dev/my-project/some-directory/other-image
, dengan tag dan/atau ringkasan apa pun.
Perhatikan bahwa awalan nama dan awalan tag tidak boleh kosong. Jadi, *
atau **
saja
bukan pola yang valid, begitu juga us-central1.pkg.dev/my-image:*
.
Pengecualian tingkat gkePolicy
Contoh berikut menunjukkan cara mengecualikan gambar di tingkat kebijakan
platform. Semua gambar dalam direktori exempt-images1
dan exempt-images2
serta subdirektorinya dikecualikan dari pemantauan
CV.
gkePolicy:
imageAllowlist:
- allow_pattern: "us-central1-docker.pkg.dev/PROJECT_ID/exempt-images1/**"
- allow_pattern: "us-central1-docker.pkg.dev/PROJECT_ID/exempt-images2/**"
checkSets:
checks:
...
Dalam kebijakan, gambar yang tercantum dalam imageAllowlist
dikecualikan dari semua
set pemeriksaan (checkSets
) yang tercantum dalam gkePolicy
.
Pengecualian level checkSet
Contoh berikut menunjukkan cara mengecualikan gambar di tingkat kumpulan pemeriksaan:
gkePolicy:
checkSets:
imageAllowlist:
- allow_pattern: "us-central1-docker.pkg.dev/PROJECT_ID/exempt-images1/**"
- allow_pattern: "us-central1-docker.pkg.dev/PROJECT_ID/exempt-images2/**"
checks:
...
Dalam kebijakan, gambar yang tercantum dalam imageAllowlist
dikecualikan dari semua
pemeriksaan yang tercantum di bagian checkSets
.
pengecualian tingkat pemeriksaan
Contoh berikut menunjukkan cara mengecualikan gambar di tingkat pemeriksaan:
gkePolicy:
checkSets:
checks:
imageAllowlist:
- allow_pattern: "us-central1-docker.pkg.dev/PROJECT_ID/exempt-images1/**"
- allow_pattern: "us-central1-docker.pkg.dev/PROJECT_ID/exempt-images2/**"
...
Menggunakan beberapa set pemeriksaan
Kebijakan berbasis pemeriksaan CV dapat berisi lebih dari satu kumpulan pemeriksaan. CV mengevaluasi satu set pemeriksaan setiap kali mengevaluasi kebijakan. Anda dapat menganggap set pemeriksaan sebagai sub-kebijakan yang harus dievaluasi dalam berbagai situasi. Misalnya, jika ingin menerapkan pemeriksaan yang berbeda di lingkungan pengembangan dibandingkan dengan yang dilakukan di lingkungan produksi, Anda dapat menempatkan pemeriksaan untuk setiap lingkungan dalam kumpulan pemeriksaan terpisah, satu yang hanya dievaluasi di lingkungan pengembangan, dan satu lagi yang dievaluasi dalam produksi.
Setiap set pemeriksaan tercakup dalam namespace Kubernetes atau akun layanan Kubernetes. Cakupan menentukan Pod tempat kumpulan pemeriksaan diterapkan.
Jika kumpulan pemeriksaan dikonfigurasi dengan cakupan, kumpulan tersebut hanya berlaku untuk Pod yang berjalan dalam cakupan tersebut.
Jika kumpulan pemeriksaan tidak memiliki cakupan, hal ini disebut set pemeriksaan default. Artinya, pemeriksaan tersebut berlaku untuk semua Pod, terlepas dari namespace Kubernetes atau cakupan akun layanannya.
Sebagian besar contoh kebijakan dalam panduan CV hanya menggunakan set centang default.
Contoh konfigurasi kebijakan berikut mengonfigurasi tiga kumpulan pemeriksaan:
gkePolicy:
checkSets:
- displayName: "Prod check set"
scope:
kubernetesNamespace: "prod-namespace"
checks:
- trustedDirectoryCheck:
trustedDirPatterns: "gcr.io/my-project/prod-images"
- imageFreshnessCheck:
maxUploadAgeDays: 30
- displayName: "Dev check set"
scope:
kubernetesNamespace: "dev-namespace"
checks:
- trustedDirectoryCheck:
trustedDirPatterns: "gcr.io/my-project/dev-images"
- displayName: "Default check set"
checks:
- alwaysDeny: true
Dalam contoh konfigurasi, kumpulan pemeriksaan pertama memiliki cakupan prod-namespace
,
sehingga pemeriksaannya hanya memengaruhi Pod yang berjalan dalam cakupan tersebut. Kumpulan pemeriksaan kedua
memiliki cakupan dev-namespace
sehingga pemeriksaannya hanya memengaruhi Pod yang berjalan dalam cakupan tersebut.
Rangkaian pemeriksaan ketiga adalah rangkaian pemeriksaan default. Pemeriksaannya berlaku untuk semua Pod di
cluster yang berjalan di luar cakupan prod-namespace
dan dev-namespace
.
Saat mengevaluasi kumpulan pemeriksaan yang disebut Prod check set
, CV akan memeriksa hal-hal berikut untuk image Pod yang berjalan di namespace Kubernetes prod-namespace
:
- Gambar disimpan di direktori
prod-images
tepercaya. - Gambar diupload dalam 30 hari terakhir.
Saat mengevaluasi kumpulan pemeriksaan yang disebut Dev check set
, CV
akan mengevaluasi Pod yang berjalan di namespace Kubernetes dev-namespace
, dan memeriksa
apakah image dalam Pod berasal dari direktori dev-images
.
Kumpulan pemeriksaan default berfungsi sebagai generik. Pemeriksaan always-deny, memastikan bahwa CV akan mencatat semua Pod yang berjalan di namespace lain ke dalam log.
Untuk menggunakan akun layanan Kubernetes sebagai cakupan kumpulan pemeriksaan, ganti kunci kubernetesNamespace
dalam contoh dengan kubernetesServiceAccount
. Nilainya memiliki format my-namespace:my-service-account
.
Periksa cakupan kumpulan memiliki aturan berikut:
Hanya boleh ada satu kumpulan pemeriksaan per cakupan dalam kebijakan platform.
Jika kebijakan berisi kumpulan pemeriksaan cakupan namespace dan cakupan akun layanan, kumpulan pemeriksaan cakupan akun layanan harus dicantumkan terlebih dahulu, lalu diikuti dengan set pemeriksaan cakupan namespace.
Hanya boleh ada satu pemeriksaan default, dan harus dicantumkan terakhir.
Jika kebijakan platform berisi kumpulan pemeriksaan, kebijakan tersebut harus berisi setidaknya satu kumpulan centang default. Kebijakan platform tanpa kumpulan pemeriksaan diizinkan, tetapi karena tidak ada pemeriksaan yang harus dilanggar, CV tidak akan menghasilkan entri log apa pun.
CV Lama
Bagian ini menjelaskan kebijakan CV lama. Jika Anda baru menggunakan CV, sebaiknya gunakan kebijakan platform CV.
Untuk mendukung pengguna CV lama, CV dapat diaktifkan di project yang menjalankan GKE. CV kemudian menggunakan kebijakan penerapan Otorisasi Biner untuk memeriksa semua Pod yang berjalan di semua cluster dalam project, termasuk cluster yang tidak mengaktifkan penerapan Otorisasi Biner.
Pelajari cara menggunakan CV lama dan melihat peristiwa CV lama di Cloud Logging.
Langkah selanjutnya
- Menggunakan pemeriksaan keaktualan gambar
- Menggunakan pemeriksaan pengesahan penandatanganan sederhana
- Menggunakan pemeriksaan tanda tangan Sigstore
- Menggunakan pemeriksaan SLSA
- Menggunakan pemeriksaan direktori tepercaya
- Menggunakan pemeriksaan kerentanan
- Melihat log CV
- Pelajari Otorisasi Biner.