Ringkasan validasi berkelanjutan

Validasi berkelanjutan (CV) dengan kebijakan platform berbasis pemeriksaan 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 CV menentukan bahwa Pod melanggar kebijakan platform, CV akan mencatat pelanggaran tersebut ke Cloud Logging.

CV dengan kebijakan platform menggantikan validasi berkelanjutan lama (tidak digunakan lagi).

Mengapa menggunakan CV?

Meskipun penerapan Otorisasi Biner memberikan 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 penegakan Otorisasi Biner dan CV dengan kebijakan berbasis pemeriksaan, Anda dapat memastikan bahwa kepatuhan terhadap 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 pembaruan. Pod yang sudah berjalan tidak terpengaruh. Image tersebut akan terus berjalan meskipun Otorisasi Biner, menggunakan kebijakan yang diperbarui, kini akan memblokir deployment image yang sama.

    Oleh karena itu, saat Anda memperbarui kebijakan project-singleton Binary Authorization, sebaiknya Anda juga membuat atau memperbarui kebijakan platform CV agar sesuai dengan kebijakan project-singleton. Dengan begitu, CV akan memberi tahu Anda tentang Pod yang sedang berjalan dan melanggar kebijakan yang telah diperbarui.

  • Memantau metadata gambar: CV menyediakan pemeriksaan khusus untuk perubahan metadata gambar, termasuk yang berikut ini:

    • Pengesahan: Mencatat log CV saat pengesahan pada image Pod tidak lagi valid.
    • Kualitas: CV mencatat log saat mendeteksi bahwa gambar Pod tidak lagi baru.
    • Provenans: CV dapat memeriksa apakah image Pod dibuat dengan builder tepercaya, menggunakan konfigurasi build yang ada di repositori sumber tepercaya.
    • Tanda tangan Sigstore: Mencatat log CV saat pada image Pod tidak memiliki tanda tangan Sigstore yang valid.
    • Direktori tepercaya: CV mencatat log saat image Pod berada di direktori repositori yang tidak tercantum dalam kebijakan platform Anda.
    • Kerentanan: CV mencatat log saat kerentanan diidentifikasi dalam image Pod.

  • Pemantauan uji coba: Saat Anda mengaktifkan uji coba, Otorisasi Biner mengizinkan semua image di-deploy. Dengan mengaktifkan CV dengan kebijakan platform yang cocok dengan kebijakan singleton project Anda, CV secara rutin mencatat image yang melanggar kebijakan platform.

  • Pemantauan breakglass: Saat Anda men-deploy Pod menggunakan breakglass, Binary Authorization akan melewati penerapan kebijakan singleton project dan mencatat satu peristiwa ke Cloud Audit Logs. Namun, dengan menggunakan kebijakan platform yang cocok, CV terus mencatat Pod yang melanggar kebijakan secara rutin, termasuk Pod yang di-deploy menggunakan breakglass.

Cara kerja CV

Untuk menggunakan CV, Anda harus mengaktifkannya di cluster GKE Anda.

Setelah Anda men-deploy image di cluster, CV memantau Pod terkait untuk memastikan kesesuaiannya dengan kebijakan platform berbasis pemeriksaan Anda.

CV tidak mendukung tag gambar, selain yang ditentukan dalam gambar yang dikecualikan.

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 dan container sementara.

Selama setiap peninjauan, CV mengambil daftar gambar yang terkait dengan setiap Pod. Kemudian, CV memverifikasi bahwa informasi gambar memenuhi kebijakan platform.

CV mencatat pelanggaran kebijakan platform

Saat CV menentukan bahwa gambar melanggar kebijakan platform, CV mencatat pelanggaran dan temuan lainnya ke Cloud Logging. Entri log terpisah ditulis untuk setiap kebijakan platform yang dilanggar, untuk setiap Pod.

Saat CV mengevaluasi gambar Pod menggunakan kebijakan platform, gambar tersebut mungkin memenuhi beberapa pemeriksaan dan melanggar pemeriksaan lainnya. CV menghasilkan entri log setiap kali ada gambar Pod yang melanggar pemeriksaan. Entri log hanya berisi image Pod yang melanggar kebijakan platform. Jika semua gambar memenuhi semua pemeriksaan, tidak ada entri log yang dihasilkan.

CV terus mencatat pelanggaran kebijakan hingga Pod dengan gambar yang tidak sesuai kebijakan dihentikan. Jika Pod yang tidak sesuai kebijakan dihentikan selama interval antara validasi, entri log yang dihasilkan CV terakhir dapat muncul setelah penghentian, selama evaluasi CV berikutnya.

Pod yang tidak sesuai kebijakan harus dicatat setidaknya sekali, bahkan untuk Pod yang berumur pendek.

CV tidak menghentikan Pod yang sedang berjalan.

CV menggunakan resource feed

Untuk mengambil informasi tentang Pod yang berjalan di cluster GKE Anda, CV 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 singleton project. Meskipun project deployment hanya dapat memiliki satu kebijakan project singleton lama, Anda dapat mengonfigurasi beberapa kebijakan platform. Setiap kebijakan platform dapat berada di satu atau beberapa project.

Kebijakan platform hanya berfungsi dengan CV dan tidak mendukung penerapan Otorisasi Biner. Oleh karena itu, sebaiknya jika Anda ingin menggunakan penegakan Otorisasi Biner dan pemantauan CV, buat kebijakan singleton project untuk penegakan dan kebijakan platform untuk pemantauan.

Misalnya, anggaplah Anda ingin mengonfigurasi Otorisasi Biner untuk menerapkan bahwa image Anda harus memiliki pengesahan sebelum diizinkan untuk di-deploy, dan Anda juga ingin memastikan bahwa Pod yang sedang berjalan mematuhi persyaratan yang sama. Untuk melakukannya, Anda mengonfigurasi kebijakan penerapan singleton project dengan pengesah. Kemudian, Anda membuat kebijakan platform dengan pemeriksaan pengesahan penandatanganan sederhana. yang memiliki pengautentikasi berdasarkan catatan dan kunci publik yang sama dengan pengesah.

Kebijakan platform bersifat spesifik per platform. GKE adalah satu-satunya platform yang didukung.

Anda dapat mengonfigurasi pemeriksaan di kebijakan platform. Pemeriksaan dikelompokkan ke dalam satu atau beberapa set pemeriksaan. Setiap set pemeriksaan dapat menentukan satu atau beberapa pemeriksaan.

Kebijakan platform dapat mengecualikan gambar dari evaluasi oleh CV.

Izin yang diperlukan

Untuk mencantumkan atau mendeskripsikan kebijakan platform, Anda memerlukan peran binaryauthorization.policyViewer. Untuk membuat, mengubah, dan menghapus kebijakan platform, Anda memerlukan peran binaryauthorization.policyEditor. Untuk mengetahui informasi selengkapnya, lihat Mengelola kebijakan platform.

Pembaruan kebijakan

Memperbarui kebijakan platform akan menggantikan kebijakan yang ada dengan deskriptor kebijakan yang Anda berikan dalam file YAML. Untuk menambahkan pemeriksaan baru ke kebijakan platform yang ada, sebaiknya Anda mendeskripsikan kebijakan yang ada, menyimpannya ke file YAML, menambahkan pemeriksaan baru, lalu memperbarui kebijakan menggunakan file yang diperbarui.

Kebijakan multi-platform

Anda dapat membuat kebijakan platform di project yang sama dengan cluster (kebijakan platform lokal) atau di project lain.

Karena Anda dapat mengonfigurasi sejumlah kebijakan platform, Anda harus memberi nama setiap kebijakan dengan nama resource yang unik. Saat menjalankan perintah gcloud CLI, Anda merujuk ke kebijakan platform lokal menggunakan ID-nya. Saat merujuk ke kebijakan platform di project lain, Anda menggunakan nama resource, dalam format berikut: projects/POLICY_PROJECT_ID/platforms/gke/policies/POLICY_ID

Anda dapat memilih kebijakan platform mana yang akan dikaitkan dengan setiap cluster GKE, baik kebijakan platform lokal maupun kebijakan di project lain.

Beberapa pemeriksaan per kebijakan platform

Anda dapat mengonfigurasi beberapa pemeriksaan dalam 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, gambar yang dievaluasi oleh satu pemeriksaan akan terus dievaluasi oleh pemeriksaan lainnya.

Otorisasi Biner mengevaluasi semua pemeriksaan yang dikonfigurasi dalam kebijakan platform untuk setiap image, kecuali jika image cocok dengan pola daftar yang diizinkan untuk image yang dikecualikan. Untuk mengetahui informasi selengkapnya, lihat Mengecualikan gambar.

Penyiapan project tunggal

Anda dapat menyiapkan CV dalam satu project.

Dalam penyiapan satu project, Otorisasi Biner otomatis menyiapkan peran yang diperlukan di agen layanan Otorisasi Biner.

Jika cluster GKE, kebijakan platform yang terikat ke 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 keamanan tambahan, lihat Pemisahan tugas.

Penyiapan multi-project

Saat Anda mengonfigurasi penyiapan CV multi-project dengan kebijakan platform, kebijakan platform, image, cluster GKE, dan jenis resource lain yang bergantung pada CV dapat berada di project yang berbeda.

Dalam penyiapan multi-project, penting untuk mengetahui tujuan setiap project dan resource yang perlu diakses dan disiapkan CV untuk menetapkan peran dan izin IAM yang diperlukan dengan tepat.

Cara menggunakan CV

Untuk menggunakan CV, Anda biasanya melakukan hal berikut:

  1. Tentukan pemeriksaan yang ingin Anda gunakan.
  2. Susun satu atau beberapa kebijakan platform menggunakan file YAML kebijakan. File menentukan pemeriksaan yang ingin Anda gunakan.
  3. Buat kebijakan platform. Kebijakan dapat disimpan di project pilihan Anda.
  4. Pilih apakah akan mengaktifkan CV di cluster individual atau di fleet.
  5. Periksa log CV di Logging untuk peristiwa.
  6. Tinjau log dan perbarui build serta proses lainnya untuk menghasilkan gambar yang memenuhi pemeriksaan.

Cek

Bagian ini menjelaskan pemeriksaan spesifik yang disediakan 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. CV hanya digunakan saat mencatat pelanggaran kebijakan. Hal ini tidak disertakan dalam beberapa contoh di bagian selanjutnya dalam panduan ini.

Pemeriksaan selalu ditolak

Pemeriksaan selalu ditolak menjamin bahwa semua gambar yang tunduk pada pemeriksaan ini gagal dievaluasi. Setiap kali CV meninjau Pod yang sedang berjalan dengan pemeriksaan ini, CV akan menghasilkan entri log untuk setiap Pod.

Anda dapat menggabungkan pemeriksaan selalu ditolak dengan daftar yang diizinkan atau beberapa set pemeriksaan untuk memastikan bahwa Otorisasi Biner selalu menghasilkan log untuk Pod dalam kasus tertentu.

Untuk menggunakan pemeriksaan selalu ditolak, tambahkan alwaysDeny: true di blok checks, seperti berikut:

gkePolicy:
  checkSets:
    - displayName: "My check set"
      checks:
        - alwaysDeny: true

Nilai alwaysDeny tidak dapat ditetapkan ke false. Sebagai gantinya, hapus centang.

Untuk contoh cara penggunaan pemeriksaan selalu ditolak, lihat Menggunakan beberapa set pemeriksaan.

Pemeriksaan keaktualan gambar

Pemeriksaan keaktualan gambar menghitung durasi gambar telah berjalan dan mencatat saat durasi telah melampaui nilai minimum, maxUploadAgeDays.

Dalam contoh YAML kebijakan platform berikut, CV mencatat Pod dengan gambar yang diupload ke repositori tempat gambar tersebut 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 sederhana

Anda dapat menggunakan pemeriksaan pengesahan penandatanganan sederhana CV untuk memeriksa bahwa setiap image Pod memiliki pengesahan yang valid dan ditandatangani.

Pemeriksaan ini setara dengan evaluasi pengesahan dalam kebijakan penerapan Otorisasi Biner. Anda dapat mengonfigurasi pemeriksaan ini dengan catatan dan kunci yang sama yang Anda gunakan di pengesah Anda. Sebaiknya gunakan pemeriksaan ini, bukan validasi berkelanjutan lama (tidak digunakan lagi).

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

Daripada pengesah Otorisasi Biner, pemeriksaan pengesahan CV memiliki pengautentikasi. Anda menentukan autentikator secara langsung dalam kebijakan, di blok attestationAuthenticators.

Dalam kebijakan platform, simpleSigningAttestationCheck dapat memiliki beberapa attestationAuthenticators dan beberapa kunci di setiap pkixPublicKeySet. Pemeriksaan dinyatakan berhasil jika setiap gambar Pod memiliki pengesahan valid yang ditandatangani dengan kunci apa pun di pkixPublicKeySet autentikator apa pun.

Kebijakan platform CV berbeda dengan kebijakan penerapan project-singleton dalam hal berikut:

  • Kunci PGP tidak didukung.
  • Attestor tidak diperlukan. Sebagai gantinya, Anda membuat kunci secara manual, lalu mendeskripsikan kebijakan platform untuk mengambil ID kunci yang kemudian Anda gunakan untuk membuat pengesahan.
  • Anda membuat dan menandatangani payload secara manual, membuat file JSON pengesahan, dan membuat pengesahan menggunakan Artifact Analysis API.
  • Anda tetap membuat Catatan Analisis Artefak, tetapi Anda 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 menentukan secara eksplisit satu atau beberapa project yang berisi pengesahan dengan menggunakan nama resource projects/ATTESTATION_PROJECT_ID.

CV tidak mendukung tag gambar, kecuali yang ditentukan dalam gambar yang dikecualikan.

Jika image di-deploy dengan tag image, bukan ringkasan, CV akan mengevaluasinya terlebih dahulu terhadap image yang dikecualikan, karena daftar yang diizinkan dapat menyertakan tag. Jika gambar tidak dikecualikan, maka CV akan mencoba menemukan ringkasan gambar. Karena tidak ada, gambar melanggar pemeriksaan.

Pemeriksaan SLSA

Pemeriksaan SLSA memeriksa asal usul yang ditentukan SLSA 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 meninjau gambar menggunakan kebijakan platform ini, CV akan memeriksa hal-hal berikut:

  • Image harus dibuat oleh builder tepercaya. Cloud Build adalah satu-satunya builder tepercaya yang didukung oleh pemeriksaan SLSA.

  • Cloud Build harus telah membuat pengesahan di attestation-project1 atau attestation-project2.

  • Image harus dibuat menggunakan file konfigurasi tingkat teratas 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 image telah ditandatangani menggunakan tanda tangan Sigstore.

Pemeriksaan ini hanya mendukung gambar yang dihosting di Artifact Registry. Pemeriksaan ini akan memeriksa apakah ada tanda tangan yang diambil dari Artifact Registry dapat berhasil diverifikasi oleh kunci apa pun dalam kebijakan.

Kebijakan platform contoh 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 yang valid yang ditandatangani dengan kunci apa pun di publicKeySet pengautentikasi apa pun.

Pemeriksaan direktori tepercaya

Pemeriksaan direktori tepercaya memeriksa apakah image Pod berada di salah satu direktori tepercaya yang disediakan yang Anda tentukan dalam kebijakan platform.

Saat menggunakan pemeriksaan ini, sebaiknya Anda juga melindungi 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 contoh kebijakan platform, trustedDirPatterns mencantumkan direktori tepercaya. Jika semua gambar Pod berada di direktori yang tercantum, gambar tersebut mematuhi kebijakan. Gambar pod yang tidak berada di direktori yang tercantum melanggar kebijakan, dan CV mencatat pelanggaran tersebut.

Pemeriksaan kerentanan

Pemeriksaan kerentanan menggunakan pemindaian kerentanan Artifact Analysis untuk memeriksa apakah image Pod berisi kerentanan. Hal ini mencakup kerentanan baru yang diidentifikasi oleh pemindaian kerentanan sejak Pod di-deploy. Dalam pemeriksaan kerentanan, Anda dapat mengonfigurasi batas tingkat keparahan kerentanan dan kerentanan tertentu (sebagai CVE). Image dengan kerentanan yang melanggar pemeriksaan kerentanan dicatat ke Logging.

Untuk menggunakan pemeriksaan ini, Anda harus mengaktifkan pemindaian kerentanan di Analisis Artefak terlebih dahulu.

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 apa pun yang dapat diidentifikasi oleh Analisis Artefak. Selain itu, blockedCves mencantumkan Common Vulnerability Exposure (CVE) tertentu. Jika kerentanan yang teridentifikasi melebihi salah satu tingkat keparahan yang ditentukan atau cocok dengan salah satu CVE yang tercantum dalam blockedCves, dan tidak cocok dengan salah satu CVE yang tercantum dalam allowedCves, maka CV akan mencatat entri ke Logging.

Memvalidasi kebijakan yang diperbarui

Setelah Anda memperbarui kebijakan platform CV, sebaiknya Anda memvalidasi bahwa Otorisasi Biner dan CV terus beroperasi seperti yang Anda harapkan.

Memvalidasi konfigurasi Anda

Untuk memeriksa konfigurasi Anda, periksa kebijakan singleton project Otorisasi Biner dan kebijakan platform CV Anda.

Memvalidasi operasi

Untuk memvalidasi bahwa Otorisasi Biner dan CV beroperasi seperti yang Anda harapkan, Anda dapat men-deploy Pod pengujian, lalu memeriksa entri Otorisasi Biner di Logging.

Mengecualikan 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 gambar dari seluruh kebijakan. Daftar yang diizinkan di tingkat set pemeriksaan mengecualikan dari set pemeriksaan, dan hanya berlaku saat set 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 berikut ini:

  • Awalan nama gambar, yang diakhiri dengan karakter pengganti * atau **.
  • Hanya nama image, tanpa tag atau ringkasan.
  • Nama image dengan tag (atau awalan tag dengan karakter pengganti *).
  • Nama image dengan ringkasan.
  • Nama image dengan tag dan ringkasan.

Berikut adalah contoh pola daftar yang diizinkan:

  • us-central1.pkg.dev/my-project/my-image:latest@sha256:77b0b75136b9bd0fd36fb50f4c92ae0dbdbbe164ab67885e736fa4374e0cbb8c mencocokkan nama, tag, dan ringkasan image yang persis sama.
  • us-central1.pkg.dev/my-project/my-image:latest cocok dengan nama dan tag, dengan digest apa pun (atau tanpa digest).
  • us-central1.pkg.dev/my-image:foo* mencocokkan 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 nama, dengan tag dan/atau ringkasan.

Karakter pengganti * dan ** dapat digunakan untuk mencocokkan nama apa pun dengan awalan tertentu. * cocok dengan akhiran yang tidak menyertakan /. ** cocok dengan akhiran yang dapat mencakup /, 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 dengan us-central1.pkg.dev/my-image:*.

Pengecualian tingkat gkePolicy

Contoh berikut menunjukkan cara mengecualikan gambar di tingkat kebijakan platform. Semua gambar di direktori exempt-images1 dan exempt-images2 serta subdirektorinya dikecualikan dari pemantauan CV.

gkePolicy:
  imageAllowlist:
  - allowPattern: "us-central1-docker.pkg.dev/PROJECT_ID/exempt-images1/**"
  - allowPattern: "us-central1-docker.pkg.dev/PROJECT_ID/exempt-images2/**"
  checkSets:
      checks:
        ...

Dalam kebijakan, gambar yang tercantum di bagian imageAllowlist dikecualikan dari semua set pemeriksaan (checkSets) yang tercantum di bagian gkePolicy.

checkSet-level exemption

Contoh berikut menunjukkan cara mengecualikan gambar di tingkat set pemeriksaan:

gkePolicy:
  checkSets:
    imageAllowlist:
    - allowPattern: "us-central1-docker.pkg.dev/PROJECT_ID/exempt-images1/**"
    - allowPattern: "us-central1-docker.pkg.dev/PROJECT_ID/exempt-images2/**"
    checks:
      ...

Dalam kebijakan, gambar yang tercantum di bagian imageAllowlist dikecualikan dari semua pemeriksaan yang tercantum di bagian checkSets.

pembebasan tingkat pemeriksaan

Contoh berikut menunjukkan cara mengecualikan gambar di tingkat pemeriksaan:

gkePolicy:
  checkSets:
    checks:
      imageAllowlist:
      - allowPattern: "us-central1-docker.pkg.dev/PROJECT_ID/exempt-images1/**"
      - allowPattern: "us-central1-docker.pkg.dev/PROJECT_ID/exempt-images2/**"
      ...

Menggunakan beberapa set pemeriksaan

Kebijakan berbasis pemeriksaan CV dapat berisi lebih dari satu set pemeriksaan. CV mengevaluasi satu set pemeriksaan setiap kali mengevaluasi kebijakan. Anda dapat menganggap set pemeriksaan sebagai sub-kebijakan yang harus dievaluasi dalam situasi yang berbeda. Misalnya, jika Anda ingin menerapkan pemeriksaan yang berbeda di lingkungan pengembangan daripada di lingkungan produksi, Anda dapat menempatkan pemeriksaan untuk setiap lingkungan dalam set pemeriksaan terpisah, satu yang dievaluasi hanya di lingkungan pengembangan, dan satu yang dievaluasi dalam produksi.

Setiap set pemeriksaan dicakup ke namespace Kubernetes atau akun layanan Kubernetes. Cakupan menentukan Pod mana yang akan menerapkan set pemeriksaan.

Jika dikonfigurasi dengan cakupan, set pemeriksaan hanya berlaku untuk Pod yang berjalan dalam cakupan tersebut.

Jika tidak memiliki cakupan, set pemeriksaan disebut set pemeriksaan default, yang berarti pemeriksaan berlaku untuk semua Pod, terlepas dari namespace Kubernetes atau cakupan akun layanannya.

Sebagian besar contoh kebijakan dalam panduan CV hanya menggunakan set pemeriksaan default.

Contoh konfigurasi kebijakan berikut mengonfigurasi tiga set 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 konfigurasi contoh, set pemeriksaan pertama dicakup ke prod-namespace, sehingga pemeriksaannya hanya memengaruhi Pod yang berjalan dalam cakupan tersebut. Set pemeriksaan kedua dicakup ke dev-namespace, sehingga pemeriksaannya hanya memengaruhi Pod yang berjalan dalam cakupan tersebut. Set pemeriksaan ketiga adalah set pemeriksaan default. Pemeriksaannya berlaku untuk semua Pod di cluster yang berjalan di luar cakupan prod-namespace dan dev-namespace.

Saat mengevaluasi set pemeriksaan yang disebut Prod check set, CV akan memeriksa 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 set pemeriksaan yang disebut Dev check set, CV akan mengevaluasi Pod yang berjalan di namespace Kubernetes dev-namespace, memeriksa apakah image di Pod berasal dari direktori dev-images.

Set pemeriksaan default bertindak sebagai penampung. Pemeriksaan selalu ditolak memastikan bahwa CV mencatat semua Pod yang berjalan di namespace lain.

Untuk menggunakan akun layanan Kubernetes sebagai cakupan set pemeriksaan, ganti kunci kubernetesNamespace dalam contoh dengan kubernetesServiceAccount. Nilai memiliki format my-namespace:my-service-account.

Cakupan set yang diperiksa memiliki aturan berikut:

  • Hanya boleh ada satu set pemeriksaan per cakupan dalam kebijakan platform.

  • Jika kebijakan berisi set pemeriksaan yang tercakup dalam namespace dan tercakup dalam akun layanan, set pemeriksaan yang tercakup dalam akun layanan harus dicantumkan terlebih dahulu, diikuti dengan set pemeriksaan yang tercakup dalam namespace.

  • Hanya boleh ada satu set pemeriksaan default, dan set tersebut harus tercantum terakhir.

Jika kebijakan platform berisi set pemeriksaan, kebijakan tersebut harus berisi setidaknya satu set pemeriksaan default. Kebijakan platform tanpa set pemeriksaan diizinkan, tetapi karena tidak ada pemeriksaan yang dilanggar, CV tidak menghasilkan entri log apa pun.

CV Lama

Bagian ini menjelaskan kebijakan CV lama. Jika Anda baru menggunakan CV, sebaiknya gunakan CV dengan kebijakan berbasis pemeriksaan.

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 (tidak digunakan lagi) dan melihat peristiwa CV lama di Cloud Logging.

Langkah berikutnya