Ringkasan validasi berkelanjutan

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 atau attestation-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/
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 (seperti myimage:foo dan myimage: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 dengan us-central1.pkg.dev/myproject/my-image, us-central1.pkg.dev/myproject/my-image1, dan us-central1.pkg.dev/myproject/my-image2, dengan tag dan/atau ringkasan apa pun.
us-central1.pkg.dev/my-project/** cocok dengan us-central1.pkg.dev/myproject/my-image dan us-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.