Membuat pengesahan dengan Kritis Signer

Tutorial ini menjelaskan cara membangun Kritis Signer dan menggunakannya untuk memeriksa kerentanan pada image container sebelum membuat pengesahan Otorisasi Biner.

Ringkasan

Kritis Signer adalah alat command line open source yang dapat membuat pengesahan Otorisasi Biner berdasarkan kebijakan yang Anda konfigurasi. Anda juga dapat menggunakan Kritis Signer untuk membuat pengesahan setelah memeriksa image untuk mendeteksi kerentanan yang diidentifikasi oleh Analisis Artefak.

Selain itu, Cloud Build dapat menjalankan Kritis Signer sebagai builder kustom dalam pipeline build.

Dalam tutorial ini, Anda akan membuat build satu kali untuk builder kustom Kritis Signer, lalu menjalankan contoh pipeline build. Setiap contoh pipeline berisi langkah-langkah build berikut:

1. Buat contoh image container.
2. Mengirim image ke Container Registry.
3. Periksa dan tanda tangani gambar: Gunakan Kritis Signer untuk membuat pengesahan berdasarkan kebijakan.

Dalam langkah build check-and-sign di setiap pipeline, Kritis Signer melakukan hal berikut:

1. Memindai image yang baru dibuat dengan Artifact Analysis dan mengambil daftar kerentanan.
2. Memeriksa daftar kerentanan terhadap aturan penandatanganan kerentanan dalam kebijakan, lalu:
   1. Jika semua kerentanan yang teridentifikasi memenuhi aturan penandatanganan kerentanan, Kritis Signer akan membuat pengesahan.
   2. Jika ada kerentanan yang teridentifikasi melanggar aturan penandatanganan kerentanan, Kritis Signer tidak akan membuat pengesahan.

Pada waktu deployment, pelaksana Otorisasi Biner akan memeriksa pengesahan yang dapat diverifikasi. Tanpa satu kode akses, alat ini tidak mengizinkan image untuk di-deploy.

Tutorial ini juga menjelaskan cara menjalankan Kritis Signer dalam mode hanya centang di pipeline Cloud Build. Dalam mode ini, Kritis Signer tidak membuat pengesahan, melainkan hanya memeriksa apakah hasil kerentanan memenuhi aturan penandatanganan kerentanan dalam kebijakan. Jika demikian, langkah build Kritis Signer akan berhasil dan pipeline akan terus berjalan. Jika tidak, langkah akan gagal dan pipeline akan keluar.

Tujuan

Dalam tutorial ini, Anda akan melakukan beberapa hal berikut:

1. Siapkan Kritis Signer sebagai builder kustom Cloud Build.
2. Lihat kebijakan yang berisi aturan penandatanganan kerentanan.
3. Jalankan Kritis Signer dalam membuat pengesahan berdasarkan hasil pemindaian kerentanan.
4. Jalankan Kritis Signer dalam mode hanya centang.

Biaya

Tutorial ini menggunakan produk Google Cloud berikut.

• Container Registry
• Artifact Analysis
• Cloud Build
• Cloud Key Management Service

Gunakan Kalkulator Harga untuk membuat perkiraan biaya berdasarkan penggunaan yang diproyeksikan.

Sebelum memulai

Di bagian ini, Anda akan melakukan penyiapan sistem satu kali.

Menyiapkan lingkungan Anda

1. Simpan project Google Cloud Anda dalam variabel lingkungan.

   Catatan: Project Google Cloud ini digunakan di sepanjang tutorial ini.

   export PROJECT_ID=PROJECT_ID
   

   Ganti PROJECT_ID dengan project Google Cloud Anda.

2. Tetapkan ID project default ke project Google Cloud Anda:

   gcloud config set project $PROJECT_ID
   

3. Simpan nomor project dalam variabel lingkungan untuk langkah-langkah berikutnya:

   export PROJECT_NUMBER=$(gcloud projects list --filter="${PROJECT_ID}" \
    --format="value(PROJECT_NUMBER)")
   

4. Mengaktifkan API:

   Untuk memastikan layanan yang diperlukan untuk panduan ini diaktifkan, jalankan perintah berikut:

   gcloud services enable \
     cloudbuild.googleapis.com \
     containerregistry.googleapis.com \
     containerscanning.googleapis.com \
     cloudkms.googleapis.com
   

Menyiapkan peran IAM

Jalankan perintah berikut untuk mengonfigurasi akun layanan Cloud Build dengan peran berikut:

• containeranalysis.notes.editor: menambahkan peran Artifact Analysis Notes Editor untuk mengelola attestor.
• containeranalysis.notes.occurrences.viewer: menambahkan peran Artifact Analysis Occurrences for Notes untuk mengelola kerentanan dan kemunculan pengesahan.
• roles/containeranalysis.occurrences.editor: menambahkan peran Artifact Analysis Occurrences Editor untuk membuat kejadian pengesahan di Artifact Analysis.

• cloudkms.signer: menambahkan peran Penandatangan CryptoKey Cloud KMS yang memungkinkan akun layanan mengakses layanan penandatanganan Cloud KMS.

  gcloud projects add-iam-policy-binding $PROJECT_ID --member serviceAccount:$[e-mail] --role roles/containeranalysis.notes.editor
  gcloud projects add-iam-policy-binding $PROJECT_ID --member serviceAccount:$[e-mail] --role roles/containeranalysis.notes.occurrences.viewer
  gcloud projects add-iam-policy-binding $PROJECT_ID --member serviceAccount:$[e-mail] --role roles/containeranalysis.occurrences.editor
  gcloud projects add-iam-policy-binding $PROJECT_ID --member serviceAccount:$[e-mail] --role roles/cloudkms.signer
  

Menyiapkan builder kustom Kritis Signer

Di bagian ini, Anda akan melakukan penyiapan satu kali untuk builder kustom Kritis Signer. Setelah Anda mendapatkan, membangun, dan mengirim Kritis Signer, solusi ini dapat digunakan di pipeline Cloud Build mana pun.

Bagian ini menunjukkan cara:

• Buat clone repositori Kritis.
• Bangun builder kustom Kritis Signer Cloud Build.
• Mengirim Kritis Signer ke Container Registry agar tersedia untuk digunakan sebagai langkah build Cloud Build.

Jalankan perintah berikut untuk mendapatkan kode dan file konfigurasi yang digunakan dalam panduan ini:

1. Clone repositori Kritis:

   git clone https://github.com/grafeas/kritis.git
   

   Repositori ini berisi hal-hal berikut:

   • Kode sumber untuk Kritis yang juga menyertakan Kritis Signer.
   • File konfigurasi Cloud Build yang digunakan oleh Cloud Build untuk membangun builder kustom Kritis Signer.
   • Contoh kebijakan yang berisi aturan penandatanganan kerentanan.
   • Contoh file konfigurasi Cloud Build. Setiap file konfigurasi menggunakan Kritis Signer dalam pipeline pemindaian kerentanan.

2. Buka direktori kritis/:

   cd kritis
   

3. Buat dan daftarkan builder kustom Kritis Signer.

   Langkah penyiapan satu kali ini membangun builder kustom Kritis Signer dan mendaftarkannya ke Cloud Build. Setelah terdaftar, builder kustom tersedia untuk digunakan di pipeline Cloud Build mana pun.

   gcloud builds submit . --config deploy/kritis-signer/cloudbuild.yaml
   

Melihat kebijakan yang ada

Bagian ini menunjukkan contoh kebijakan Kritis Signer.

Kebijakan ini mengonfigurasi Kritis Signer untuk meminta Analisis Artefak guna memindai kerentanan pada image. Setelah pemindaian selesai, Kritis Signer akan memeriksa hasil kerentanan yang ditampilkan terhadap aturan penandatanganan kerentanan dalam kebijakan.

Anda dapat mengedit aturan penandatanganan kerentanan dalam kebijakan ini untuk membuat pengesahan berdasarkan hal berikut:

• Tingkat keparahan dari kerentanan yang teridentifikasi.
• Kerentanan spesifik.

Anda juga dapat menetapkan kebijakan untuk membuat (ALLOW_ALL) tanpa syarat atau tidak membuat pengesahan (BLOCK_ALL).

Untuk melihat kebijakan Kritis Signer, jalankan perintah berikut:

cat samples/signer/policy-strict.yaml

Kebijakan ini akan terlihat seperti berikut:

apiVersion: kritis.grafeas.io/v1beta1
kind: VulnzSigningPolicy
metadata:
  name: my-vsp
spec:
  imageVulnerabilityRequirements:
    maximumFixableSeverity: MEDIUM
    maximumUnfixableSeverity: MEDIUM
    allowlistCVEs:
    - projects/goog-vulnz/notes/CVE-2021-20305

Dengan keterangan:

• maximumUnfixableSeverity dan maximumFixableSeverity menentukan batas keparahan Kerentanan dan Eksposur Umum (CVE) yang digunakan Kritis Signer untuk membuat pengesahan. maximumUnfixableSeverity menentukan batas tingkat keparahan yang saat ini tidak memiliki perbaikan. maximumFixableSeverity menentukan batas tingkat keparahan yang saat ini perbaikannya tersedia. maximumUnfixableSeverity dan maximumFixableSeverity masing-masing dapat disetel ke salah satu tingkat keparahan berikut:

  • CRITICAL
  • HIGH
  • MEDIUM
  • LOW

  Untuk mengetahui informasi selengkapnya tentang tingkat keparahan, lihat Tingkat keparahan.

  Atau, Anda dapat menetapkan maximumUnfixableSeverity dan maximumFixableSeverity ke hal berikut:

  • BLOCK_ALL: Pengesahan tidak dibuat jika ada kerentanan yang teridentifikasi.
  • ALLOW_ALL: Pengesahan selalu dibuat.

• allowlistCVEs adalah daftar CVE tertentu yang diizinkan. Kritis Signer mengabaikan CVE dalam daftar ini saat mengevaluasi apakah akan membuat pengesahan. Setiap entri dalam daftar yang diizinkan harus sama persis dengan nama catatan Artifact Analysis untuk CVE. Pelajari Sumber kerentanan Analisis Artefak lebih lanjut. Untuk mengetahui informasi selengkapnya tentang catatan, lihat Penyimpanan Metadata.

Membuat kunci penandatanganan Cloud KMS

Kunci Cloud Key Management Service digunakan untuk membuat pengesahan.

1. Buat key ring Cloud KMS baru dengan nama KEY_RING:

   gcloud kms keyrings create KEY_RING \
      --location global
   

2. Buat kunci Cloud KMS baru yang disebut KEY_NAME di dalam key ring:

   gcloud kms keys create KEY_NAME \
       --keyring KEY_RING \
       --location global \
       --purpose "asymmetric-signing" \
       --default-algorithm "rsa-sign-pkcs1-2048-sha256"
   

3. Simpan algoritma digest dan Cloud KMS dalam variabel lingkungan untuk langkah-langkah mendatang:

   export KMS_DIGEST_ALG=SHA256
   export KMS_KEY_NAME=projects/$PROJECT_ID/locations/global/keyRings/KEY_RING/cryptoKeys/KEY_NAME/cryptoKeyVersions/1
   

Catatan: Untuk mempelajari algoritma penandatanganan lainnya, lihat Membuat kunci asimetris.

Menentukan nama catatan

Semua pengesahan merujuk catatan Analisis Artefak. Kritis Signer otomatis membuat catatan untuk nama tertentu. Anda juga dapat menggunakan kembali nama catatan yang ada.

export NOTE_ID=my-signer-note
export NOTE_NAME=projects/${PROJECT_ID}/notes/${NOTE_ID}

Membuat pengesahan dengan Kritis Signer di pipeline Cloud Build

Bagian ini menunjukkan cara menggunakan builder cloud kustom Kritis Signer untuk membuat pengesahan Otorisasi Biner berdasarkan hasil pemindaian kerentanan.

Langkah-langkah berikut menunjukkan cara kerja Kritis Signer menggunakan contoh file konfigurasi build di repositori Kritis Signer. Setiap contoh file konfigurasi berisi langkah-langkah build berikut:

1. Langkah docker build yang membangun image container Docker.
2. Langkah docker push yang mengirim image container yang baru di-build ke Container Registry.

3. Langkah vulnsign yang memeriksa dan menandatangani image container dengan:

   1. Menunggu Artifact Analysis menampilkan temuan kerentanan pada image container yang baru dibuat.
   2. Memeriksa temuan itu berdasarkan aturan penandatanganan kerentanan dalam kebijakan.
   3. Membuat pengesahan jika temuan memenuhi aturan kerentanan.

Anda mengirimkan setiap contoh build ke Cloud Build. Setiap build memberikan hasil kerentanan:

• Kasus kegagalan: hasil kerentanan melanggar aturan penandatanganan kerentanan. Build ini gagal dan tidak ada pengesahan yang dibuat.
• Kasus keberhasilan: hasil kerentanan memenuhi aturan penandatanganan kerentanan. Build ini berhasil dan pengesahan dibuat.

Mengirim build contoh kasus kegagalan

Di bagian ini, Anda akan membangun image container dan memindainya untuk mencari kerentanan. Build gagal karena image container didasarkan pada snapshot spesifik Debian 10, yang berisi sejumlah kerentanan dengan tingkat keparahan HIGH. Kerentanan ini melanggar aturan penandatanganan kerentanan. Akibatnya, builder tidak menghasilkan pengesahan.

1. (Opsional) Lihat file kebijakan penandatanganan kerentanan untuk kasus kegagalan.

   cat samples/signer/policy-strict.yaml
   

   Catatan: File konfigurasi build ini juga berisi substitusi yang ditentukan pengguna. Substitusi adalah variabel, yang digunakan dalam pipeline build, yang diteruskan melalui perintah gcloud builds submit dengan parameter --substitutions.

2. Kirim build:

   gcloud builds submit \
     --substitutions=_KMS_KEY_NAME=$KMS_KEY_NAME,_KMS_DIGEST_ALG=$KMS_DIGEST_ALG,_NOTE_NAME=$NOTE_NAME \
     --config=samples/signer/cloudbuild-bad.yaml samples/signer
   

   Anda akan melihat output seperti berikut:

   "ERROR: (gcloud.builds.submit) build BUILD_ID completed with status "FAILURE"
   

3. Simpan ID build dari build terakhir:

   export BUILD_ID=$(gcloud builds list --limit=1 --format="value('ID')")
   

4. Verifikasi hasilnya:

    gsutil cat gs://${PROJECT_NUMBER}.cloudbuild-logs.googleusercontent.com/log-${BUILD_ID}.txt | grep "does not pass VulnzSigningPolicy"
   

Mengirim build contoh kasus berhasil

Di bagian ini, Anda akan mem-build image container yang berisi kerentanan yang tidak melanggar aturan penandatanganan kerentanan. Dalam hal ini, builder kustom Kritis Signer membuat pengesahan.

Penting: Dalam contoh ini, pengesahan dibuat karena kebijakan penandatanganan kerentanan terkait dikonfigurasi agar sangat longgar, bukan karena image bebas dari kerentanan yang signifikan. Pendekatan ini hanya untuk tujuan ilustrasi dan tidak cocok untuk tujuan produksi.

Untuk mengirimkan build contoh kasus berhasil ke Cloud Build, lakukan langkah berikut:

1. (Opsional) Lihat file kebijakan penandatanganan kerentanan untuk kasus berhasil.

   cat samples/signer/policy-loose.yaml
   

   Catatan: File konfigurasi build ini juga berisi substitusi yang ditentukan pengguna. Substitusi adalah variabel, yang digunakan dalam pipeline build, yang diteruskan melalui perintah gcloud builds submit dengan parameter --substitutions.

2. Kirim build:

   gcloud builds submit \
     --substitutions=_KMS_KEY_NAME=$KMS_KEY_NAME,_KMS_DIGEST_ALG=$KMS_DIGEST_ALG,_NOTE_NAME=$NOTE_NAME \
     --config=samples/signer/cloudbuild-good.yaml samples/signer
   

3. Simpan ID build dari build terakhir:

   export BUILD_ID=$(gcloud builds list --limit=1 --format="value('ID')")
   

4. Verifikasi hasilnya:

   gcloud builds describe $BUILD_ID | grep status
   

Menggunakan Kritis Signer dalam mode hanya centang

Bagian ini menunjukkan cara menggunakan Kritis Signer dalam mode check-only. Dalam mode ini, Kritis Signer tidak membuat pengesahan. Fitur ini hanya memeriksa kerentanan pada image sebelum berhasil atau gagal dalam langkah build berdasarkan aturan penandatanganan kerentanan.

Mengirim build contoh kasus kegagalan

1. (Opsional) Lihat file kebijakan penandatanganan kerentanan untuk kasus kegagalan.

   cat samples/policy-check/policy-strict.yaml
   

   Pada langkah build Kritis Signer, perhatikan bahwa flag mode disetel ke check-only.

2. Kirim build:

   gcloud builds submit \
     --config=samples/policy-check/cloudbuild-bad.yaml samples/policy-check
   

   Perhatikan bahwa build gagal.

3. Simpan ID build dari build terakhir:

   export BUILD_ID=$(gcloud builds list --limit=1 --format="value('ID')")
   

4. Verifikasi hasilnya:

    gsutil cat gs://${PROJECT_NUMBER}.cloudbuild-logs.googleusercontent.com/log-${BUILD_ID}.txt | grep "does not pass VulnzSigningPolicy"
   

Mengirim build contoh kasus berhasil

1. (Opsional) Lihat file kebijakan penandatanganan kerentanan untuk kasus berhasil.

   cat samples/policy-check/policy-loose.yaml
   

2. Kirim build:

   gcloud builds submit \
    --config=samples/policy-check/cloudbuild-good.yaml samples/policy-check
   

3. Simpan ID build dari build terakhir:

   export BUILD_ID=$(gcloud builds list --limit=1 --format="value('ID')")
   

4. Verifikasi hasilnya:

   gcloud builds describe $BUILD_ID | grep status
   

Membuat attestor

Untuk membuat kebijakan yang memerlukan pengesahan yang Anda buat menggunakan metode yang dijelaskan dalam panduan ini, Anda harus membuat attestor terlebih dahulu.

Untuk membuat attestor, lakukan hal berikut:

1. Ambil materi kunci publik dari kunci Cloud KMS yang Anda buat sebelumnya dalam panduan ini:

   gcloud kms keys versions get-public-key 1 \
   --key KEY_NAME \
   --keyring KEY_RING \
   --location global \
   --output-file OUTPUT_PATH
   

   • KEY_NAME: adalah nama kunci
   • KEY_RING: nama key ring
   • OUTPUT_PATH: jalur file—misalnya, my-key.pem

2. Buat attestor menggunakan materi kunci publik dalam file dan catatan yang Anda buat sebelumnya dalam panduan ini. Anda dapat membuat attestor melalui Google Cloud Console atau gcloud CLI.

3. Buat kebijakan yang memerlukan pengesahan dan berikan attestor yang Anda buat di bagian ini. Anda dapat membuat kebijakan melalui Google Cloud Console atau gcloud CLI

Membuat pengesahan

Untuk membuat pengesahan menggunakan attestor, lihat Membuat pengesahan menggunakan Cloud KMS.

Pembersihan

Untuk membersihkan resource yang digunakan dalam dokumen ini, Anda dapat menghapus project:

gcloud projects delete ${PROJECT_ID}

Langkah selanjutnya

• Dokumentasi Critis Signer di GitHub
• Ringkasan Otorisasi Biner
• Buat attestor melalui Google Cloud Console atau alat command line
• Konfigurasi kebijakan untuk mewajibkan pengesahan melalui Google Cloud Console atau alat command line
• Membuat pengesahan dengan Voucher
• Analisis Artefak dan pemindaian kerentanan
• Komunitas Cloud Build dan builder cloud kustom