Membuat pengesahan dengan Kritis Signer

Tutorial ini menjelaskan cara mem-build Kritis Signer dan menggunakannya untuk memeriksa kerentanan image container sebelum membuat pengesahan Otorisasi Biner.

Ringkasan

Kritis Signer adalah alat command line open source yang dapat membuat atestasi Otorisasi Biner berdasarkan kebijakan yang Anda konfigurasikan. Anda juga dapat menggunakan Kritis Signer untuk membuat pengesahan setelah memeriksa image untuk menemukan kerentanan yang diidentifikasi oleh Artifact Analysis.

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

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

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

Pada langkah build periksa dan tanda tangani 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 diidentifikasi memenuhi aturan penandatanganan kerentanan, Kritis Signer akan membuat pengesahan.
   2. Jika salah satu kerentanan yang diidentifikasi melanggar aturan penandatanganan kerentanan, Kritis Signer tidak akan membuat pengesahan.

Pada waktu deployment, penegak Binary Authorization akan memeriksa pengesahan yang dapat diverifikasi. Tanpa tag, penegak tidak mengizinkan deployment image.

Tutorial ini juga menjelaskan cara menjalankan Kritis Signer dalam mode khusus pemeriksaan di pipeline Cloud Build. Dalam mode ini, Kritis Signer tidak membuat pengesahan, tetapi hanya memeriksa apakah hasil kerentanan memenuhi aturan penandatanganan kerentanan dalam kebijakan. Jika berhasil, langkah build Kritis Signer akan berhasil dan pipeline akan terus berjalan. Jika tidak, langkah tersebut 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. Melihat kebijakan yang berisi aturan penandatanganan kerentanan.
3. Jalankan Kritis Signer dalam membuat pengesahan berdasarkan hasil pemindaian kerentanan.
4. Jalankan Kritis Signer dalam mode hanya periksa.

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 Anda proyeksikan.

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 seluruh tutorial ini.

   export PROJECT_ID=PROJECT_ID
   

   Ganti PROJECT_ID dengan project Google Cloud Anda.

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

   gcloud config set project $PROJECT_ID
   

3. Simpan nomor project dalam variabel lingkungan untuk langkah selanjutnya:

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

4. Aktifkan 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 Editor Catatan Analisis Artefak untuk mengelola penanda tangan.
• containeranalysis.notes.occurrences.viewer: menambahkan peran Kejadian Analisis Artefak untuk Catatan guna mengelola kejadian kerentanan dan pengesahan.
• roles/containeranalysis.occurrences.editor: menambahkan peran Editor Peristiwa Artifact Analysis untuk membuat peristiwa pengesahan di Artifact Analysis.

• cloudkms.signer: menambahkan peran Cloud KMS CryptoKey Signer 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, mem-build, dan mendorong Kritis Signer, aplikasi tersebut dapat digunakan di pipeline Cloud Build mana pun.

Bagian ini menunjukkan cara:

• Clone repositori Kritis.
• Build builder kustom Cloud Build Kritis Signer.
• Kirim 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 berikut:

   • Kode sumber untuk Kritis yang juga menyertakan Kritis Signer.
   • File konfigurasi Cloud Build yang digunakan oleh Cloud Build untuk mem-build 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. Mem-build dan mendaftarkan builder kustom Kritis Signer.

   Langkah penyiapan satu kali ini mem-build 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 Penanda Tangan Kritis.

Kebijakan ini mengonfigurasi Kritis Signer untuk meminta Artifact Analysis 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 kerentanan yang teridentifikasi.
• Kerentanan tertentu.

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

Untuk melihat kebijakan Penanda Tangan Kritis, jalankan perintah berikut:

cat samples/signer/policy-strict.yaml

Kebijakannya 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 nilai minimum keparahan Common Vulnerabilities and Exposures (CVE) saat Kritis Signer membuat pengesahan. maximumUnfixableSeverity menentukan nilai minimum untuk tingkat keparahan yang perbaikannya tidak tersedia saat ini. maximumFixableSeverity menentukan nilai minimum untuk tingkat keparahan yang perbaikannya sudah tersedia saat ini. maximumUnfixableSeverity dan maximumFixableSeverity masing-masing dapat disetel ke salah satu tingkat keparahan berikut:

  • CRITICAL
  • HIGH
  • MEDIUM
  • LOW

  Untuk 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 diidentifikasi.
  • 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 Analisis Artefak untuk CVE. Pelajari lebih lanjut Sumber kerentanan Artifact Analysis. 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 bernama KEY_NAME 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 ringkasan dan Cloud KMS dalam variabel lingkungan untuk langkah-langkah selanjutnya:

   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 mereferensikan catatan Analisis Artefak. Kritis Signer secara 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 mem-build image container Docker.
2. Langkah docker push yang mendorong image container yang baru dibuat 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 terhadap aturan penandatanganan kerentanan dalam kebijakan.
   3. Membuat pengesahan jika temuan memenuhi aturan kerentanan.

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

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

Mengirim build contoh kasus kegagalan

Di bagian ini, Anda akan mem-build image container dan memindainya untuk menemukan kerentanan. Build gagal karena image container didasarkan pada snapshot tertentu dari 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 penggantian 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:

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

Kirim build contoh kasus keberhasilan

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 akan 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 sukses ke Cloud Build, lakukan hal berikut:

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

   cat samples/signer/policy-loose.yaml
   

   Catatan: File konfigurasi build ini juga berisi penggantian 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 periksa

Bagian ini menunjukkan cara menggunakan Kritis Signer dalam mode check-only. Dalam mode ini, Kritis Signer tidak membuat pengesahan. Langkah 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 tanda 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:

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

Kirim build contoh kasus keberhasilan

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

   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 pengesah terlebih dahulu.

Untuk membuat pengautentikasi, 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 pengautentikasi menggunakan materi kunci publik dalam file dan catatan yang Anda buat sebelumnya dalam panduan ini. Anda dapat membuat pengautentikasi melalui konsol Google Cloud atau gcloud CLI.

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

Membuat pengesahan

Untuk membuat pengesahan menggunakan pengautentikasi, 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 Kritis Signer di GitHub
• Ringkasan Otorisasi Biner
• Membuat pengautentikasi melalui konsol Google Cloud atau alat command line
• Konfigurasikan kebijakan untuk mewajibkan pengesahan melalui konsol Google Cloud atau alat command line
• Membuat pengesahan dengan Voucher
• Artifact Analysis dan pemindaian kerentanan
• Komunitas Cloud Build dan builder cloud kustom