Membatasi Deployment dengan Autentikasi Biner

1. Pengantar

Otorisasi Biner merupakan kontrol keamanan waktu deployment yang memastikan hanya image container tepercaya yang di-deploy di Google Kubernetes Engine (GKE) atau Cloud Run. Dengan Otorisasi Biner, Anda dapat mewajibkan image untuk ditandatangani oleh otoritas tepercaya selama proses pengembangan, lalu menerapkan validasi tanda tangan saat melakukan deployment. Dengan menerapkan validasi, Anda dapat memperoleh kontrol yang lebih ketat atas lingkungan container dengan memastikan hanya image terverifikasi yang diintegrasikan ke proses build dan rilis.

Diagram berikut menunjukkan komponen dalam penyiapan Otorisasi Biner/Cloud Build:

**Gambar 1.**Pipeline Cloud Build yang membuat pengesahan Otorisasi Biner.

Dalam pipeline ini:

1. Kode untuk mem-build image container dikirim ke repositori sumber, seperti Cloud Source Repositories.
2. Alat continuous integration (CI), Cloud Build, mem-build dan menguji container.
3. Build mengirim image container ke Container Registry atau registry lain yang menyimpan image yang Anda build.
4. Cloud Key Management Service, yang menyediakan pengelolaan kunci untuk pasangan kunci kriptografis, menandatangani image container. Tanda tangan yang dihasilkan kemudian disimpan dalam pengesahan yang baru dibuat.
5. Pada waktu deployment, attestor memverifikasi pengesahan menggunakan kunci publik dari pasangan kunci. Otorisasi Biner menerapkan kebijakan dengan mewajibkan pengesahan bertanda tangan untuk men-deploy image container.

Dalam lab ini, Anda akan berfokus pada alat dan teknik untuk mengamankan artefak yang di-deploy. Lab ini berfokus pada artefak (container) setelah dibuat, tetapi tidak di-deploy ke lingkungan tertentu.

Yang akan Anda pelajari

• Penandatanganan Image
• Kebijakan Kontrol Penerimaan
• Penandatanganan Image yang Dipindai
• Pemberian Otorisasi Image Bertanda Tangan
• Image yang Diblokir dan Tidak Ditandatangani

2. Penyiapan dan Persyaratan

Penyiapan lingkungan mandiri

1. Login ke Google Cloud Console dan buat project baru atau gunakan kembali project yang sudah ada. Jika belum memiliki akun Gmail atau Google Workspace, Anda harus membuatnya.

• Project name adalah nama tampilan untuk peserta project ini. String ini adalah string karakter yang tidak digunakan oleh Google API. Anda dapat memperbaruinya kapan saja.
• Project ID bersifat unik di semua project Google Cloud dan tidak dapat diubah (tidak dapat diubah setelah ditetapkan). Cloud Console otomatis membuat string unik; biasanya Anda tidak mementingkan kata-katanya. Di sebagian besar codelab, Anda harus merujuk Project ID-nya (biasanya diidentifikasi sebagai PROJECT_ID). Jika tidak suka dengan ID yang dibuat, Anda dapat membuat ID acak lainnya. Atau, Anda dapat mencobanya sendiri dan melihat apakah ID tersebut tersedia. ID tidak dapat diubah setelah langkah ini dan akan tetap ada selama durasi project.
• Sebagai informasi, ada nilai ketiga, Project Number yang digunakan oleh beberapa API. Pelajari lebih lanjut ketiga nilai ini di dokumentasi.

Perhatian: Project ID bersifat unik secara global dan tidak dapat digunakan orang lain setelah Anda memilihnya. Anda adalah satu-satunya pengguna ID tersebut. Meskipun project sudah dihapus, ID tersebut tidak dapat digunakan lagi

Catatan: Jika menggunakan akun Gmail, Anda dapat menyetel lokasi default ke Tidak ada organisasi. Jika Anda menggunakan akun Google Workspace, pilih lokasi yang sesuai untuk organisasi Anda.

2. Selanjutnya, Anda harus mengaktifkan penagihan di Konsol Cloud untuk menggunakan resource/API Cloud. Menjalankan operasi dalam codelab ini seharusnya tidak memerlukan banyak biaya, bahkan mungkin tidak sama sekali. Guna mematikan resource agar tidak menimbulkan penagihan di luar tutorial ini, Anda dapat menghapus resource yang dibuat atau menghapus seluruh project. Pengguna baru Google Cloud memenuhi syarat untuk mengikuti program Uji Coba Gratis senilai $300 USD.

Penyiapan Lingkungan

Di Cloud Shell, tetapkan project ID dan nomor project untuk project Anda. Simpan sebagai variabel PROJECT_ID dan PROJECT_ID.

export PROJECT_ID=$(gcloud config get-value project)
export PROJECT_NUMBER=$(gcloud projects describe $PROJECT_ID \
    --format='value(projectNumber)')

Mengaktifkan layanan

Aktifkan semua layanan yang diperlukan:

gcloud services enable \
  cloudkms.googleapis.com \
  cloudbuild.googleapis.com \
  container.googleapis.com \
  containerregistry.googleapis.com \
  artifactregistry.googleapis.com \
  containerscanning.googleapis.com \
  ondemandscanning.googleapis.com \
  binaryauthorization.googleapis.com 

Buat Repositori Artifact Registry

Di lab ini, Anda akan menggunakan Artifact Registry untuk menyimpan dan memindai image. Buat repositori dengan perintah berikut.

gcloud artifacts repositories create artifact-scanning-repo \
  --repository-format=docker \
  --location=us-central1 \
  --description="Docker repository"

Konfigurasi Docker untuk menggunakan kredensial gcloud Anda saat mengakses Artifact Registry.

gcloud auth configure-docker us-central1-docker.pkg.dev

Buat dan ubah menjadi direktori kerja

mkdir vuln-scan && cd vuln-scan

Tentukan gambar sampel

Buat file bernama Dockerfile dengan konten berikut.

cat > ./Dockerfile << EOF
from python:3.8-slim  

# App
WORKDIR /app
COPY . ./

RUN pip3 install Flask==2.1.0
RUN pip3 install gunicorn==20.1.0

CMD exec gunicorn --bind :\$PORT --workers 1 --threads 8 main:app

EOF

Buat file bernama main.py dengan isi sebagai berikut

cat > ./main.py << EOF
import os
from flask import Flask

app = Flask(__name__)

@app.route("/")
def hello_world():
    name = os.environ.get("NAME", "Worlds")
    return "Hello {}!".format(name)

if __name__ == "__main__":
    app.run(debug=True, host="0.0.0.0", port=int(os.environ.get("PORT", 8080)))
EOF

Membangun dan Mengirim Image ke AR

Gunakan Cloud Build untuk mem-build dan secara otomatis mengirim container Anda ke Artifact Registry.

gcloud builds submit . -t us-central1-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image

3. Penandatanganan Image

Apa itu Attestor

Attestor

• Orang/proses ini bertanggung jawab atas satu link dalam rantai kepercayaan sistem.
• Attestor menyimpan kunci kriptografis, dan menandatangani image jika lulus proses persetujuan.
• Meskipun Pembuat Kebijakan menentukan kebijakan secara abstrak dan berlevel tinggi, Attestor bertanggung jawab untuk secara konkret menerapkan beberapa aspek kebijakan.
• Dapat berupa orang sungguhan, seperti penguji QA atau manajer, atau dapat berupa bot dalam sistem CI.
• Keamanan sistem bergantung pada kredibilitas mereka, sehingga penting agar kunci pribadi mereka tetap aman.

Setiap peran ini dapat mewakili satu orang atau tim di organisasi Anda. Dalam lingkungan produksi, peran-peran ini kemungkinan akan dikelola oleh project Google Cloud Platform (GCP) yang berbeda, dan akses ke resource akan dibagikan di antara peran-peran tersebut secara terbatas menggunakan Cloud IAM.

Attestor di Otorisasi Biner diimplementasikan di atas Cloud Container Analysis API, jadi penting untuk menjelaskan cara kerjanya sebelum melanjutkan. Container Analysis API dirancang untuk memungkinkan Anda mengaitkan metadata dengan image container tertentu.

Sebagai contoh, Catatan dapat dibuat untuk melacak kerentanan Heartbleed. Kemudian, vendor keamanan akan membuat pemindai untuk menguji kerentanan image container, dan membuat Kemunculan yang terkait dengan setiap container yang disusupi.

Selain melacak kerentanan, Container Analysis dirancang sebagai API metadata generik. Otorisasi Biner menggunakan Container Analysis untuk mengaitkan tanda tangan dengan image container yang diverifikasinya**.** Catatan Container Analysis digunakan untuk merepresentasikan satu attestor, dan Kemunculan dibuat serta dikaitkan dengan setiap container yang telah disetujui attestor.

API Otorisasi Biner menggunakan konsep "attestor" dan "pengesahan", tetapi konsep ini diimplementasikan menggunakan Catatan dan Kemunculan yang sesuai di Container Analysis API.

Membuat Catatan Attestor

Catatan Attestor hanyalah sedikit data yang berfungsi sebagai label untuk jenis tanda tangan yang diterapkan. Misalnya, satu catatan mungkin menunjukkan pemindaian kerentanan, sementara catatan lain mungkin digunakan untuk persetujuan QA. Catatan akan dirujuk selama proses penandatanganan.

Membuat catatan

cat > ./vulnz_note.json << EOM
{
  "attestation": {
    "hint": {
      "human_readable_name": "Container Vulnerabilities attestation authority"
    }
  }
}
EOM

Simpan catatan

NOTE_ID=vulnz_note

curl -vvv -X POST \
    -H "Content-Type: application/json"  \
    -H "Authorization: Bearer $(gcloud auth print-access-token)"  \
    --data-binary @./vulnz_note.json  \
    "https://containeranalysis.googleapis.com/v1/projects/${PROJECT_ID}/notes/?noteId=${NOTE_ID}"

Verifikasi catatan

curl -vvv  \
    -H "Authorization: Bearer $(gcloud auth print-access-token)" \
    "https://containeranalysis.googleapis.com/v1/projects/${PROJECT_ID}/notes/${NOTE_ID}"

Catatan Anda kini disimpan dalam Container Analysis API.

Membuat Attestor

Attestor digunakan untuk melakukan proses penandatanganan image yang sebenarnya dan akan melampirkan kemunculan catatan ke image untuk verifikasi nanti. Untuk menggunakan attestor, Anda juga harus mendaftarkan catatan dengan Otorisasi Biner:

Buat Attestor

ATTESTOR_ID=vulnz-attestor

gcloud container binauthz attestors create $ATTESTOR_ID \
    --attestation-authority-note=$NOTE_ID \
    --attestation-authority-note-project=${PROJECT_ID}

Verifikasi Attestor

gcloud container binauthz attestors list

Perhatikan baris terakhir yang menunjukkan NUM_PUBLIC_KEYS: 0 Anda akan memberikan kunci di langkah berikutnya

Perhatikan juga bahwa Cloud Build secara otomatis membuat attestor built-by-cloud-build di project Anda saat Anda menjalankan build yang menghasilkan image. Jadi, perintah di atas menampilkan dua attestor, vulnz-attestor dan built-by-cloud-build. Setelah image berhasil di-build, Cloud Build akan otomatis menandatangani dan membuat pengesahan untuk image tersebut.

Menambahkan Peran IAM

Akun layanan Otorisasi Biner akan memerlukan hak untuk melihat catatan pengesahan. Berikan akses dengan panggilan API berikut

PROJECT_NUMBER=$(gcloud projects describe "${PROJECT_ID}"  --format="value(projectNumber)")

BINAUTHZ_SA_EMAIL="service-${PROJECT_NUMBER}@gcp-sa-binaryauthorization.iam.gserviceaccount.com"


cat > ./iam_request.json << EOM
{
  'resource': 'projects/${PROJECT_ID}/notes/${NOTE_ID}',
  'policy': {
    'bindings': [
      {
        'role': 'roles/containeranalysis.notes.occurrences.viewer',
        'members': [
          'serviceAccount:${BINAUTHZ_SA_EMAIL}'
        ]
      }
    ]
  }
}
EOM

Gunakan file untuk membuat Kebijakan IAM

curl -X POST  \
    -H "Content-Type: application/json" \
    -H "Authorization: Bearer $(gcloud auth print-access-token)" \
    --data-binary @./iam_request.json \
    "https://containeranalysis.googleapis.com/v1/projects/${PROJECT_ID}/notes/${NOTE_ID}:setIamPolicy"

Menambahkan Kunci KMS

Sebelum dapat menggunakan attestor ini, otoritas Anda harus membuat pasangan kunci kriptografis yang dapat digunakan untuk menandatangani image container. Hal ini dapat dilakukan melalui Google Cloud Key Management Service (KMS).

Pertama, tambahkan beberapa variabel lingkungan untuk mendeskripsikan kunci baru

KEY_LOCATION=global
KEYRING=binauthz-keys
KEY_NAME=codelab-key
KEY_VERSION=1

Membuat keyring untuk menyimpan sekumpulan kunci

gcloud kms keyrings create "${KEYRING}" --location="${KEY_LOCATION}"

Buat pasangan kunci penandatanganan asimetris baru untuk attestor

gcloud kms keys create "${KEY_NAME}" \
    --keyring="${KEYRING}" --location="${KEY_LOCATION}" \
    --purpose asymmetric-signing   \
    --default-algorithm="ec-sign-p256-sha256"

Anda akan melihat kunci Anda muncul di halaman KMS di Konsol Google Cloud.

Sekarang, kaitkan kunci dengan attestor Anda melalui perintah binauthz gcloud:

gcloud beta container binauthz attestors public-keys add  \
    --attestor="${ATTESTOR_ID}"  \
    --keyversion-project="${PROJECT_ID}"  \
    --keyversion-location="${KEY_LOCATION}" \
    --keyversion-keyring="${KEYRING}" \
    --keyversion-key="${KEY_NAME}" \
    --keyversion="${KEY_VERSION}"

Jika Anda mencetak daftar otoritas lagi, Anda akan melihat kunci yang terdaftar:

gcloud container binauthz attestors list

Membuat Pengesahan yang Ditandatangani

Pada tahap ini, Anda telah mengonfigurasi fitur yang memungkinkan Anda menandatangani image. Gunakan Attestor yang Anda buat sebelumnya untuk menandatangani Image Container yang telah Anda kerjakan.

Pengesahan harus menyertakan tanda tangan kriptografis untuk menyatakan bahwa attestor telah memverifikasi image container tertentu dan aman untuk dijalankan di cluster Anda. Untuk menentukan image container mana yang akan disahkan, Anda perlu menentukan ringkasannya.

CONTAINER_PATH=us-central1-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image

DIGEST=$(gcloud container images describe ${CONTAINER_PATH}:latest \
    --format='get(image_summary.digest)')

Sekarang, Anda dapat menggunakan gcloud untuk membuat pengesahan. Perintah ini hanya akan mengambil detail kunci yang ingin Anda gunakan untuk penandatanganan, dan image container tertentu yang ingin Anda setujui

gcloud beta container binauthz attestations sign-and-create  \
    --artifact-url="${CONTAINER_PATH}@${DIGEST}" \
    --attestor="${ATTESTOR_ID}" \
    --attestor-project="${PROJECT_ID}" \
    --keyversion-project="${PROJECT_ID}" \
    --keyversion-location="${KEY_LOCATION}" \
    --keyversion-keyring="${KEYRING}" \
    --keyversion-key="${KEY_NAME}" \
    --keyversion="${KEY_VERSION}"

Dalam istilah Container Analysis, tindakan ini akan membuat kemunculan baru, dan melampirkannya ke catatan attestor Anda. Untuk memastikan semuanya berfungsi seperti yang diharapkan, Anda dapat mencantumkan pengesahan Anda

gcloud container binauthz attestations list \
   --attestor=$ATTESTOR_ID --attestor-project=${PROJECT_ID}

4. Kebijakan Kontrol Penerimaan

Otorisasi Biner adalah fitur di GKE dan Cloud Run yang memberikan kemampuan untuk memvalidasi aturan sebelum image container diizinkan untuk dijalankan. Validasi dijalankan pada setiap permintaan untuk menjalankan image, baik dari pipeline CI/CD tepercaya maupun pengguna yang mencoba men-deploy image secara manual. Dengan kemampuan ini, Anda dapat mengamankan lingkungan runtime secara lebih efektif daripada hanya pemeriksaan pipeline CI/CD.

Untuk memahami kemampuan ini, Anda akan mengubah kebijakan GKE default untuk menerapkan aturan otorisasi yang ketat.

Buat Cluster GKE

Buat cluster GKE dengan otorisasi biner yang diaktifkan:

gcloud beta container clusters create binauthz \
    --zone us-central1-a  \
    --binauthz-evaluation-mode=PROJECT_SINGLETON_POLICY_ENFORCE

Izinkan Cloud Build men-deploy ke cluster ini:

gcloud projects add-iam-policy-binding ${PROJECT_ID} \
        --member="serviceAccount:${PROJECT_NUMBER}@cloudbuild.gserviceaccount.com" \
        --role="roles/container.developer"

Kebijakan Izinkan Semua

Pertama, verifikasi status kebijakan default dan kemampuan Anda untuk men-deploy image apa pun

1. Meninjau kebijakan yang ada

gcloud container binauthz policy export

2. Perhatikan bahwa kebijakan terkait proses penegakan kebijakan ditetapkan ke ALWAYS_ALLOW

evaluationMode: ALWAYS_ALLOW

3. Deploy Contoh untuk memverifikasi bahwa Anda dapat men-deploy apa pun

kubectl run hello-server --image gcr.io/google-samples/hello-app:1.0 --port 8080

4. Verifikasi bahwa deployment berfungsi

kubectl get pods

Anda akan melihat output berikut

5. Hapus deployment

kubectl delete pod hello-server

Kebijakan Tolak Semua

Sekarang, perbarui kebijakan untuk melarang semua image.

1. Mengekspor kebijakan saat ini ke file yang dapat diedit

gcloud container binauthz policy export  > policy.yaml

2. Ubah kebijakan

Di editor teks, ubah evaluationMode dari ALWAYS_ALLOW menjadi ALWAYS_DENY.

edit policy.yaml

File YAML kebijakan akan muncul sebagai berikut:

globalPolicyEvaluationMode: ENABLE
defaultAdmissionRule:
  evaluationMode: ALWAYS_DENY
  enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG
name: projects/PROJECT_ID/policy

Kebijakan ini relatif sederhana. Baris globalPolicyEvaluationMode menyatakan bahwa kebijakan ini memperluas kebijakan global yang ditentukan oleh Google. Hal ini memungkinkan semua container GKE resmi berjalan secara default. Selain itu, kebijakan ini mendeklarasikan defaultAdmissionRule yang menyatakan bahwa semua pod lainnya akan ditolak. Aturan penerimaan mencakup baris enforcementMode, yang menyatakan bahwa semua pod yang tidak sesuai dengan aturan ini harus diblokir agar tidak berjalan di cluster.

Untuk mengetahui petunjuk tentang cara mem-build kebijakan yang lebih kompleks, lihat dokumentasi Otorisasi Biner.

3. Buka Terminal, terapkan kebijakan baru, dan tunggu beberapa detik hingga perubahan diterapkan

gcloud container binauthz policy import policy.yaml

4. Mencoba deployment workload contoh

kubectl run hello-server --image gcr.io/google-samples/hello-app:1.0 --port 8080

5. Deployment gagal dengan pesan berikut

Error from server (VIOLATES_POLICY): admission webhook "imagepolicywebhook.image-policy.k8s.io" denied the request: Image gcr.io/google-samples/hello-app:1.0 denied by Binary Authorization default admission rule. Denied by always_deny admission rule

Mengembalikan kebijakan untuk mengizinkan semua

Sebelum melanjutkan ke bagian berikutnya, pastikan untuk mengembalikan perubahan kebijakan

1. Ubah kebijakan

Di editor teks, ubah evaluationMode dari ALWAYS_DENY menjadi ALWAYS_ALLOW.

edit policy.yaml

File YAML kebijakan akan muncul sebagai berikut:

globalPolicyEvaluationMode: ENABLE
defaultAdmissionRule:
  evaluationMode: ALWAYS_ALLOW
  enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG
name: projects/PROJECT_ID/policy

2. Terapkan kebijakan yang telah dikembalikan

gcloud container binauthz policy import policy.yaml

5. Penandatanganan Image yang Dipindai

Anda telah mengaktifkan Penandatanganan image dan secara manual menggunakan Attestor untuk menandatangani contoh image Anda. Dalam praktiknya, Anda akan ingin menerapkan Pengesahan selama proses otomatis, seperti pipeline CI/CD.

Di bagian ini, Anda akan mengonfigurasi Cloud Build untuk Mengesahkan image secara otomatis

Peran

Tambahkan peran Binary Authorization Attestor Viewer ke Akun Layanan Cloud Build:

gcloud projects add-iam-policy-binding ${PROJECT_ID} \
  --member serviceAccount:${PROJECT_NUMBER}@cloudbuild.gserviceaccount.com \
  --role roles/binaryauthorization.attestorsViewer

Tambahkan peran Cloud KMS CryptoKey Signer/Verifier ke Akun Layanan Cloud Build (Penandatanganan berbasis KMS):

gcloud projects add-iam-policy-binding ${PROJECT_ID} \
  --member serviceAccount:${PROJECT_NUMBER}@cloudbuild.gserviceaccount.com \
  --role roles/cloudkms.signerVerifier

Tambahkan peran Container Analysis Notes Attacher ke Akun Layanan Cloud Build:

gcloud projects add-iam-policy-binding ${PROJECT_ID} \
  --member serviceAccount:${PROJECT_NUMBER}@cloudbuild.gserviceaccount.com \
  --role roles/containeranalysis.notes.attacher

Sediakan akses untuk Akun Layanan Cloud Build

Cloud Build memerlukan hak untuk mengakses API pemindaian on-demand. Berikan akses dengan perintah berikut.

gcloud projects add-iam-policy-binding ${PROJECT_ID} \
        --member="serviceAccount:${PROJECT_NUMBER}@cloudbuild.gserviceaccount.com" \
        --role="roles/iam.serviceAccountUser"
        
gcloud projects add-iam-policy-binding ${PROJECT_ID} \
        --member="serviceAccount:${PROJECT_NUMBER}@cloudbuild.gserviceaccount.com" \
        --role="roles/ondemandscanning.admin"

Siapkan Langkah Custom Build Cloud Build

Anda akan menggunakan langkah Custom Build di Cloud Build untuk menyederhanakan proses pengesahan. Google menyediakan langkah Custom Build ini yang berisi fungsi bantuan untuk menyederhanakan proses. Sebelum digunakan, kode untuk langkah build kustom harus dibangun ke dalam container dan dikirim ke Cloud Build. Untuk melakukannya, jalankan perintah berikut:

git clone https://github.com/GoogleCloudPlatform/cloud-builders-community.git
cd cloud-builders-community/binauthz-attestation
gcloud builds submit . --config cloudbuild.yaml
cd ../..
rm -rf cloud-builders-community

Menambahkan langkah penandatanganan ke cloudbuild.yaml

Pada langkah ini, Anda akan menambahkan langkah pengesahan ke pipeline Cloud Build.

1. Tinjau langkah penandatanganan di bawah ini.

Hanya tinjau. Jangan Salin

#Sign the image only if the previous severity check passes
- id: 'create-attestation'
  name: 'gcr.io/${PROJECT_ID}/binauthz-attestation:latest'
  args:
    - '--artifact-url'
    - 'us-central1-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image'
    - '--attestor'
    - 'projects/${PROJECT_ID}/attestors/$ATTESTOR_ID'
    - '--keyversion'
    - 'projects/${PROJECT_ID}/locations/$KEY_LOCATION/keyRings/$KEYRING/cryptoKeys/$KEY_NAME/cryptoKeyVersions/$KEY_VERSION'

2. Tulis file cloudbuild.yaml dengan pipeline lengkap di bawah.

cat > ./cloudbuild.yaml << EOF
steps:

# build
- id: "build"
  name: 'gcr.io/cloud-builders/docker'
  args: ['build', '-t', 'us-central1-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image', '.']
  waitFor: ['-']

#Run a vulnerability scan at _SECURITY level
- id: scan
  name: 'gcr.io/cloud-builders/gcloud'
  entrypoint: 'bash'
  args:
  - '-c'
  - |
    (gcloud artifacts docker images scan \
    us-central1-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image \
    --location us \
    --format="value(response.scan)") > /workspace/scan_id.txt

#Analyze the result of the scan
- id: severity check
  name: 'gcr.io/cloud-builders/gcloud'
  entrypoint: 'bash'
  args:
  - '-c'
  - |
      gcloud artifacts docker images list-vulnerabilities \$(cat /workspace/scan_id.txt) \
      --format="value(vulnerability.effectiveSeverity)" | if grep -Fxq CRITICAL; \
      then echo "Failed vulnerability check for CRITICAL level" && exit 1; else echo "No CRITICAL vulnerability found, congrats !" && exit 0; fi

#Retag
- id: "retag"
  name: 'gcr.io/cloud-builders/docker'
  args: ['tag',  'us-central1-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image', 'us-central1-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image:good']


#pushing to artifact registry
- id: "push"
  name: 'gcr.io/cloud-builders/docker'
  args: ['push',  'us-central1-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image:good']


#Sign the image only if the previous severity check passes
- id: 'create-attestation'
  name: 'gcr.io/${PROJECT_ID}/binauthz-attestation:latest'
  args:
    - '--artifact-url'
    - 'us-central1-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image:good'
    - '--attestor'
    - 'projects/${PROJECT_ID}/attestors/$ATTESTOR_ID'
    - '--keyversion'
    - 'projects/${PROJECT_ID}/locations/$KEY_LOCATION/keyRings/$KEYRING/cryptoKeys/$KEY_NAME/cryptoKeyVersions/$KEY_VERSION'



images:
  - us-central1-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image:good
EOF

Menjalankan Build

gcloud builds submit

Tinjau build di Histori Cloud Build

Buka Konsol Cloud ke halaman Cloud Build History, lalu tinjau build terbaru dan keberhasilan eksekusi langkah-langkah build.

6. Pemberian Otorisasi Image Bertanda Tangan

Di bagian ini, Anda akan mengupdate GKE untuk menggunakan Otorisasi Biner dalam memvalidasi bahwa image memiliki tanda tangan dari Pemindaian kerentanan sebelum mengizinkan image berjalan.

Memperbarui Kebijakan GKE untuk Mewajibkan Pengesahan

Mewajibkan penandatanganan image oleh Attestor Anda dengan menambahkan clusterAdmissionRules ke Kebijakan BinAuth GKE Anda

Saat ini, cluster Anda menjalankan kebijakan dengan satu aturan: izinkan container dari repositori resmi, dan tolak semua yang lain.

Ganti kebijakan dengan konfigurasi yang diperbarui menggunakan perintah di bawah ini.

COMPUTE_ZONE=us-central1-a

cat > binauth_policy.yaml << EOM
defaultAdmissionRule:
  enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG
  evaluationMode: ALWAYS_DENY
globalPolicyEvaluationMode: ENABLE
clusterAdmissionRules:
  ${COMPUTE_ZONE}.binauthz:
    evaluationMode: REQUIRE_ATTESTATION
    enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG
    requireAttestationsBy:
    - projects/${PROJECT_ID}/attestors/vulnz-attestor
EOM

Anda kini akan memiliki file baru di disk, yang disebut updated_policy.yaml. Sekarang, alih-alih menolak semua image dengan aturan default, aturan tersebut akan memeriksa attestor Anda terlebih dahulu untuk melakukan verifikasi.

Upload kebijakan baru ke Otorisasi Biner:

gcloud beta container binauthz policy import binauth_policy.yaml

Men-deploy image yang ditandatangani

Dapatkan ringkasan image yang bagus

CONTAINER_PATH=us-central1-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image


DIGEST=$(gcloud container images describe ${CONTAINER_PATH}:good \
    --format='get(image_summary.digest)')

Gunakan ringkasan dalam konfigurasi Kubernetes

cat > deploy.yaml << EOM
apiVersion: v1
kind: Service
metadata:
  name: deb-httpd
spec:
  selector:
    app: deb-httpd
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: deb-httpd
spec:
  replicas: 1
  selector:
    matchLabels:
      app: deb-httpd
  template:
    metadata:
      labels:
        app: deb-httpd
    spec:
      containers:
      - name: deb-httpd
        image: ${CONTAINER_PATH}@${DIGEST}
        ports:
        - containerPort: 8080
        env:
          - name: PORT
            value: "8080"

EOM

Deploy aplikasi ke GKE

kubectl apply -f deploy.yaml

Tinjau workload di konsol dan perhatikan keberhasilan deployment image.

7. Image yang Diblokir dan Tidak Ditandatangani

Mem-build Image

Pada langkah ini, Anda akan menggunakan Docker lokal untuk mem-build image ke cache lokal Anda.

docker build -t us-central1-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image:bad .

Kirim image yang tidak ditandatangani ke repo

docker push us-central1-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image:bad

Dapatkan ringkasan image yang buruk

CONTAINER_PATH=us-central1-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image


DIGEST=$(gcloud container images describe ${CONTAINER_PATH}:bad \
    --format='get(image_summary.digest)')

Gunakan ringkasan dalam konfigurasi Kubernetes

cat > deploy.yaml << EOM
apiVersion: v1
kind: Service
metadata:
  name: deb-httpd
spec:
  selector:
    app: deb-httpd
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: deb-httpd
spec:
  replicas: 1
  selector:
    matchLabels:
      app: deb-httpd
  template:
    metadata:
      labels:
        app: deb-httpd
    spec:
      containers:
      - name: deb-httpd
        image: ${CONTAINER_PATH}@${DIGEST}
        ports:
        - containerPort: 8080
        env:
          - name: PORT
            value: "8080"

EOM

Coba deploy aplikasi ke GKE

kubectl apply -f deploy.yaml

Tinjau workload di konsol dan perhatikan error yang menyatakan bahwa deployment ditolak:

No attestations found that were valid and signed by a key trusted by the attestor

8. Selamat!

Selamat, Anda telah menyelesaikan codelab!

Yang telah kita bahas:

• Penandatanganan Image
• Kebijakan Kontrol Penerimaan
• Penandatanganan Image yang Dipindai
• Pemberian Otorisasi Image Bertanda Tangan
• Image yang Diblokir dan Tidak Ditandatangani

Langkah berikutnya:

• Mengamankan deployment image di Cloud Run dan Google Kubernetes Engine | Dokumentasi Cloud Build
• Panduan memulai: Mengonfigurasi kebijakan Otorisasi Biner dengan GKE | Google Cloud

Pembersihan

Agar tidak menimbulkan biaya pada akun Google Cloud Anda untuk resource yang digunakan dalam tutorial ini, hapus project yang berisi resource tersebut, atau simpan project dan hapus setiap resource.

Menghapus project

Cara termudah untuk menghilangkan penagihan adalah dengan menghapus project yang Anda buat untuk tutorial.

—

Terakhir diperbarui: 21/3/23