Ringkasan validasi berkelanjutan

Pratinjau

Produk atau fitur ini tunduk pada "Persyaratan Penawaran Pra-GA" di bagian Persyaratan Layanan Umum di Persyaratan Khusus Layanan. Produk dan fitur pra-GA tersedia "sebagaimana adanya" dan mungkin memiliki dukungan terbatas. Untuk mengetahui informasi selengkapnya, lihat deskripsi tahap peluncuran.

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 terkait terus sesuai dengan 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 image yang terkait dengan Pod yang berjalan agar terus mematuhi kebijakan Anda.

Oleh karena itu, saat mengaktifkan penerapan Otorisasi Biner dan CV dengan kebijakan berbasis pemeriksaan, Anda dapat memastikan bahwa kepatuhan kebijakan divalidasi di seluruh siklus proses orkestrasi.

CV berguna dalam skenario berikut:

• Perubahan kebijakan: Saat Anda mengupdate kebijakan penegakan project-singleton Otorisasi Biner, Otorisasi Biner hanya memvalidasi image yang di-deploy setelah update. Pod yang sudah berjalan tidak akan terpengaruh. Image tersebut akan terus berjalan meskipun Otorisasi Biner, yang menggunakan kebijakan yang diperbarui, kini akan memblokir image yang sama agar tidak di-deploy.

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

• Memantau metadata gambar: CV menyediakan pemeriksaan tertentu untuk perubahan pada metadata gambar, termasuk hal berikut:

  • Pengesahan: Log CV saat pengesahan pada image Pod tidak lagi valid.
  • Kesegaran: CV mencatat log saat mendeteksi bahwa image Pod tidak lagi baru.
  • Provenance: CV dapat memeriksa apakah image Pod di-build dengan builder tepercaya, menggunakan konfigurasi build yang berada di repositori sumber tepercaya.
  • Tanda tangan Sigstore: CV mencatat log saat pada image Pod tidak memiliki tanda tangan Sigstore yang valid.
  • Direktori tepercaya: CV mencatat saat image Pod berada di direktori repositori yang tidak tercantum dalam kebijakan platform Anda.
  • Kerentanan: CV mencatat log saat kerentanan teridentifikasi dalam image Pod.

• Pemantauan uji coba: Saat Anda mengaktifkan uji coba, Otorisasi Biner akan 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 mengabaikan penerapan kebijakan singleton project dan mencatat satu peristiwa ke Cloud Audit Logs. Namun, dengan menggunakan kebijakan platform yang cocok, CV akan terus mencatat Pod yang melanggar kebijakan secara berkala, termasuk Pod yang di-deploy menggunakan breakglass.

Cara kerja CV

Untuk menggunakan CV, Anda harus mengaktifkannya di cluster GKE.

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

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

CV secara rutin meninjau Pod yang berjalan

Untuk memantau Pod yang berjalan, CV meninjau gambar yang terkait dengan setiap Pod setidaknya setiap 24 jam. CV juga memantau penampung init dan penampung sementara.

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

CV mencatat pelanggaran kebijakan platform

Saat CV 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 gambar Pod menggunakan kebijakan platform, gambar tersebut mungkin memenuhi beberapa pemeriksaan dan melanggar pemeriksaan lainnya. CV menghasilkan entri log setiap kali gambar Pod melanggar pemeriksaan apa pun. 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 image yang tidak sesuai kebijakan dihentikan. Jika Pod yang tidak mematuhi kebijakan dihentikan selama interval antara validasi, entri log akhir yang dihasilkan CV dapat muncul setelah penghentian, selama evaluasi CV berikutnya.

Pod yang tidak mematuhi kebijakan harus dicatat ke dalam log minimal sekali, bahkan untuk Pod yang berumur singkat.

CV tidak menghentikan Pod yang sedang berjalan.

CV menggunakan resource feed

Untuk mengambil informasi tentang Pod yang berjalan di cluster GKE, CV membuat resource feed yang disebut binauthz-cv-cai-feed.

Penting: Menghapus atau mengubah feed binauthz-cv-cai-feed dapat menyebabkan CV gagal. CV secara otomatis memulihkan feed yang hilang atau diubah, tetapi dapat gagal mencatat temuan hingga melakukannya.

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 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 agar image Anda memiliki pengesahan sebelum diizinkan untuk di-deploy, dan Anda juga ingin memastikan bahwa Pod yang berjalan sesuai dengan persyaratan yang sama. Untuk melakukannya, Anda mengonfigurasi kebijakan penerapan singleton project dengan penanda tangan. Kemudian, Anda membuat kebijakan platform dengan pemeriksaan pengesahan penandatanganan sederhana. yang memiliki pengautentikasi berdasarkan catatan dan kunci publik yang sama dengan attestor.

Kebijakan platform bersifat khusus 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 kumpulan pemeriksaan dapat menentukan satu atau beberapa pemeriksaan.

Kebijakan platform dapat mengecualikan gambar dari penilaian 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 menimpa kebijakan yang ada dengan deskripsi kebijakan yang Anda berikan dalam file YAML. Untuk menambahkan pemeriksaan baru ke kebijakan platform yang ada, sebaiknya jelaskan kebijakan yang ada, simpan ke file YAML, tambahkan pemeriksaan baru, lalu perbarui kebijakan menggunakan file yang diperbarui.

Kebijakan beberapa 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 dapat 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 yang akan dikaitkan dengan setiap cluster GKE, baik kebijakan platform lokal maupun kebijakan platform dalam project yang berbeda.

Beberapa pemeriksaan per kebijakan 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 konfigurasikan, 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 satu project

Anda dapat menyiapkan CV dalam satu project.

Dalam penyiapan satu project, Otorisasi Biner akan 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 diperlukan peran Identity and Access Management (IAM) tambahan.

Untuk mempelajari lebih lanjut cara mengonfigurasi penyiapan multi-project untuk keamanan tambahan, lihat Pemisahan masalah.

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 CV serta menyiapkan peran dan izin IAM yang diperlukan.

Cara menggunakan CV

Untuk menggunakan CV, Anda biasanya melakukan hal berikut:

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

Penting: Saat Anda mengupdate cluster yang ada untuk mengaktifkan CV, cluster tersebut mungkin sudah menggunakan Otorisasi Biner untuk penerapan. Dalam hal ini, gunakan flag berikut untuk memastikan penegakan terus berlanjut: --binauthz-evaluation-mode=POLICY_BINDINGS_AND_PROJECT_SINGLETON_POLICY_ENFORCE

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. Kolom ini hanya digunakan saat CV mencatat pelanggaran kebijakan. Ini dihilangkan dalam beberapa contoh nanti dalam panduan ini.

Pemeriksaan selalu tolak

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

Anda dapat menggabungkan pemeriksaan selalu tolak 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 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 pemeriksaan selalu tolak dapat digunakan, lihat Menggunakan beberapa kumpulan pemeriksaan.

Pemeriksaan keaktualan gambar

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

Dalam contoh YAML kebijakan platform berikut, CV mencatat Pod dengan image yang diupload ke repositori tempat Pod 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 ditandatangani dan valid.

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 (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

Sebagai ganti pengesah Otorisasi Biner, pemeriksaan pengesahan CV memiliki pengautentikasi. Anda menentukan pengautentikasi langsung dalam kebijakan, di blok attestationAuthenticators.

Dalam kebijakan platform, simpleSigningAttestationCheck dapat memiliki beberapa attestationAuthenticators dan beberapa kunci di setiap pkixPublicKeySet. Pemeriksaan akan terpenuhi jika setiap image Pod memiliki pengesahan yang valid dan ditandatangani dengan kunci mana pun di pkixPublicKeySet pengautentikasi mana pun.

Penting: Meskipun kebijakan singleton project Otorisasi Biner memerlukan pengesahan yang valid dari kunci apa pun dari setiap pengautentikasi, pemeriksaan pengesahan penandatanganan sederhana memerlukan pengesahan dari kunci apa pun di pengautentikasi apa pun. Untuk mengonfigurasi kebijakan singleton project yang setara dengan beberapa pengautentikasi, Anda harus mengonfigurasi beberapa pemeriksaan pengesahan dalam kebijakan platform. Mengonfigurasi beberapa pengautentikasi atau beberapa kunci saja tidak cukup.

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

• Kunci PGP tidak didukung.
• Attester tidak diperlukan. Sebagai gantinya, Anda membuat kunci secara manual, lalu menjelaskan kebijakan platform untuk mengambil ID kunci yang kemudian Anda gunakan untuk membuat atestasi.
• 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 tidak menentukan dalam kebijakan. Sebagai gantinya, CV akan mencari atestasi 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 satu atau beberapa project yang berisi pengesahan secara eksplisit 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, CV akan mencoba menemukan ringkasan gambar. Karena tidak ada, gambar melanggar pemeriksaan.

Pemeriksaan SLSA

Pemeriksaan SLSA memeriksa asal usul yang ditentukan SLSA dari 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 berikut:

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

• Cloud Build harus telah 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 image telah ditandatangani menggunakan tanda tangan Sigstore.

Pemeriksaan ini hanya mendukung image yang dihosting di Artifact Registry. Fungsi ini memeriksa apakah tanda tangan yang diambil dari Artifact Registry 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 akan terpenuhi jika setiap image Pod memiliki pengesahan valid yang ditandatangani dengan kunci mana pun di publicKeySet pengautentikasi mana pun.

Penting: Meskipun kebijakan singleton project Otorisasi Biner memerlukan pengesahan yang valid dari kunci apa pun dari setiap pengesah, pemeriksaan tanda tangan Sigstore memerlukan pengesahan dari kunci apa pun di otoritas mana pun. Untuk mengonfigurasi kebijakan singleton project yang setara dengan beberapa otoritas, Anda harus mengonfigurasi beberapa pemeriksaan tanda tangan Sigstore dalam kebijakan platform. Mengonfigurasi beberapa pengautentikasi atau beberapa kunci saja tidak cukup.

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 image Pod berada di direktori yang tercantum, image tersebut sesuai dengan kebijakan. Gambar pod yang tidak berada dalam 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 nilai minimum tingkat keparahan kerentanan dan kerentanan tertentu (sebagai CVE). Image dengan kerentanan yang melanggar pemeriksaan kerentanan akan dicatat ke Logging.

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

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, 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 Eksposur Kerentanan Umum (CVE) tertentu. Jika kerentanan yang diidentifikasi 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, CV akan mencatat entri ke Logging.

Memvalidasi 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, periksa kebijakan singleton project Otorisasi Biner dan kebijakan platform CV.

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 kumpulan pemeriksaan dikecualikan dari kumpulan pemeriksaan, dan hanya berlaku saat 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 berikut:

• Awalan nama gambar, yang 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, tag, dan ringkasan image 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 nama, 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 dengan 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:
  - 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 kumpulan pemeriksaan (checkSets) yang tercantum di bagian gkePolicy.

pengecualian tingkat checkSet

Contoh berikut menunjukkan cara mengecualikan gambar di tingkat kumpulan 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.

pengecualian 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 kumpulan pemeriksaan

Kebijakan berbasis pemeriksaan CV dapat berisi lebih dari satu kumpulan pemeriksaan. CV mengevaluasi satu set pemeriksaan setiap kali mengevaluasi kebijakan. Anda dapat menganggap kumpulan 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 kumpulan pemeriksaan terpisah, yang hanya dievaluasi di lingkungan pengembangan, dan yang dievaluasi dalam produksi.

Setiap kumpulan pemeriksaan dicakupkan ke namespace Kubernetes atau akun layanan Kubernetes. Cakupan menentukan Pod mana yang akan diterapkan pemeriksaan.

Jika kumpulan pemeriksaan dikonfigurasi dengan cakupan, kumpulan pemeriksaan tersebut hanya berlaku untuk Pod yang berjalan di cakupan tersebut.

Jika tidak memiliki cakupan, kumpulan pemeriksaan disebut kumpulan 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 kumpulan pemeriksaan 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 dicakupkan ke prod-namespace, sehingga pemeriksaannya hanya memengaruhi Pod yang berjalan dalam cakupan tersebut. Kumpulan pemeriksaan kedua dibatasi untuk 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 CV mengevaluasi kumpulan pemeriksaan yang disebut Prod check set, CV akan memeriksa hal berikut untuk image Pod yang berjalan di namespace Kubernetes prod-namespace:

• Image disimpan di direktori prod-images tepercaya.
• Gambar diupload dalam 30 hari terakhir.

Saat CV mengevaluasi kumpulan 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.

Kumpulan pemeriksaan default berfungsi sebagai generik. Pemeriksaan selalu tolak memastikan bahwa CV mencatat semua Pod yang berjalan di namespace lain.

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 yang ditetapkan memiliki aturan berikut:

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

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

• Hanya boleh ada satu kumpulan pemeriksaan default, dan harus dicantumkan terakhir.

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

CV Lama

Perhatian: Validasi berkelanjutan lama (CV lama) dengan kebijakan singleton project tidak digunakan lagi. Mulai 15 April 2024, Anda tidak dapat lagi mengaktifkan CV lama dengan kebijakan project-singleton pada project baru, dan dukungan untuk project yang ada akan dihapus pada 1 Mei 2025. Sebagai gantinya, gunakan validasi berkelanjutan (CV) dengan kebijakan platform berbasis pemeriksaan. Pengguna CV lama yang sudah ada dapat memigrasikan kebijakan project-singleton ke kebijakan platform. Untuk mempelajari caranya, lihat Migrasi.

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 penerapan Otorisasi Biner-nya tidak diaktifkan.

Pelajari cara menggunakan CV lama (tidak digunakan lagi) 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.