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:
- Kode untuk membangun image container dikirim ke repositori sumber, seperti Cloud Source Repositories.
- Alat continuous integration (CI), Cloud Build, akan membangun dan menguji container.
- Build akan mengirim image container ke Container Registry atau registry lain yang menyimpan image yang telah dibangun.
- 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.
- Pada waktu deployment, attestor memverifikasi pengesahan menggunakan kunci publik dari pasangan kunci. Otorisasi Biner menerapkan kebijakan dengan mewajibkan pengesahan yang ditandatangani untuk men-deploy image container.
Di 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 Gambar
- Kebijakan Kontrol Penerimaan
- Menandatangani Gambar yang Dipindai
- Mengizinkan Gambar Bertanda Tangan
- Gambar yang tidak ditandatangani diblokir
2. Penyiapan dan Persyaratan
Penyiapan lingkungan mandiri
- 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
peduli tentang apa itu. Di sebagian besar codelab, Anda harus mereferensikan Project ID (biasanya diidentifikasi sebagai
PROJECT_ID). Jika Anda tidak menyukai ID yang dihasilkan, Anda dapat membuat ID acak lainnya. Atau, Anda dapat mencobanya sendiri dan lihat 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.
- 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. Untuk 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
Membuat Artifact Registry Repository
Di lab ini, Anda akan menggunakan Artifact Registry untuk menyimpan dan memindai image Anda. Buat repositori dengan perintah berikut.
gcloud artifacts repositories create artifact-scanning-repo \
--repository-format=docker \
--location=us-central1 \
--description="Docker repository"
Konfigurasi Docker untuk memanfaatkan kredensial gcloud saat mengakses Artifact Registry.
gcloud auth configure-docker us-central1-docker.pkg.dev
Membuat dan mengubah menjadi direktori kerja
mkdir vuln-scan && cd vuln-scan
Menentukan gambar contoh
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 konten 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 membangun dan mengirim container secara otomatis ke Artifact Registry.
gcloud builds submit . -t us-central1-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image
3. Penandatanganan Gambar
Apa itu Attestor
Attestor
- Orang/proses ini bertanggung jawab atas satu tautan dalam rantai kepercayaan sistem.
- Mereka memegang kunci kriptografis, dan menandatangani gambar jika lolos proses persetujuan.
- Meskipun Pembuat Kebijakan menetapkan kebijakan secara garis besar dan abstrak, Attestor bertanggung jawab untuk menegakkan beberapa aspek kebijakan secara konkret.
- Mungkin orang sungguhan, seperti penguji atau manajer QA, atau mungkin bot dalam sistem CI.
- Keamanan sistem bergantung pada kredibilitasnya, sehingga kunci pribadi harus dijaga agar tetap aman.
Masing-masing peran ini dapat mewakili orang perorangan atau tim di organisasi Anda. Dalam lingkungan produksi, peran ini kemungkinan akan dikelola oleh project Google Cloud Platform (GCP) yang terpisah, dan akses ke resource akan dibagikan di antara peran tersebut secara terbatas menggunakan Cloud IAM.
Attestor di Otorisasi Biner diimplementasikan di atas Cloud Container Analysis API, sehingga penting untuk menjelaskan cara kerjanya sebelum melanjutkan. Container Analysis API didesain agar Anda dapat mengaitkan metadata dengan image container tertentu.
Sebagai contoh, Catatan mungkin dibuat untuk melacak kerentanan Heartbleed. Vendor keamanan kemudian akan membuat pemindai guna menguji image container untuk kerentanan, dan membuat Kejadian yang terkait dengan setiap container yang disusupi.
Bersama dengan pelacakan kerentanan, Container Analysis juga dirancang agar menjadi API metadata generik. Otorisasi Biner menggunakan Container Analysis untuk mengaitkan tanda tangan dengan image container yang diverifikasi.** Catatan Container Analysis digunakan untuk mewakili satu attestor, dan Kejadian dibuat serta dikaitkan dengan setiap penampung yang telah disetujui oleh attestor.
Binary Authorization API menggunakan konsep "attestors" dan "pengesahan", tetapi hal ini diterapkan menggunakan Catatan dan Kejadian 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 lainnya 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
Menyimpan 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 gambar yang sebenarnya dan akan melampirkan kemunculan catatan ke gambar untuk verifikasi nanti. Untuk menggunakan attestor, Anda juga harus mendaftarkan catatan ke 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 bahwa baris terakhir menunjukkan NUM_PUBLIC_KEYS: 0 bahwa Anda akan memberikan kunci di langkah berikutnya
Perhatikan juga bahwa Cloud Build secara otomatis membuat attestor built-by-cloud-build di project saat Anda menjalankan build yang menghasilkan gambar. Jadi, perintah di atas akan menampilkan dua attestor, vulnz-attestor dan built-by-cloud-build. Setelah image berhasil dibangun, Cloud Build secara otomatis menandatangani dan membuat pengesahan untuk image tersebut.
Menambahkan Peran IAM
Akun layanan Otorisasi Biner akan memerlukan hak untuk melihat catatan pengesahan. Sediakan 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
Menggunakan file tersebut 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 Anda dapat menggunakan attestor ini, otoritas Anda perlu membuat pasangan kunci kriptografis yang dapat digunakan untuk menandatangani image container. Tindakan 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
Buat keyring untuk menyimpan serangkaian 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 Konsol Google Cloud.
Sekarang, kaitkan kunci dengan attestor Anda melalui perintah gcloud binauthz:
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 mencetak daftar otoritas lagi, Anda sekarang 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 digunakan.
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 Anda. Perintah ini hanya 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 berjalan. Validasi dijalankan pada semua 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 dengan lebih efektif daripada pemeriksaan pipeline CI/CD saja.
Untuk memahami kemampuan ini, Anda akan mengubah kebijakan GKE default untuk menerapkan aturan otorisasi yang ketat.
Membuat 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"
Izinkan Semua Kebijakan
Pertama-tama, verifikasi status kebijakan default dan kemampuan Anda untuk men-deploy image apa pun
- Tinjau kebijakan yang ada
gcloud container binauthz policy export
- Perhatikan bahwa kebijakan penerapan disetel ke
ALWAYS_ALLOW
evaluationMode: ALWAYS_ALLOW
- Deploy Sample untuk memverifikasi bahwa Anda dapat men-deploy apa pun
kubectl run hello-server --image gcr.io/google-samples/hello-app:1.0 --port 8080
- Memverifikasi bahwa deployment berfungsi
kubectl get pods
Anda akan melihat output berikut
- Hapus deployment
kubectl delete pod hello-server
Tolak Semua Kebijakan
Sekarang perbarui kebijakan untuk melarang semua gambar.
- Mengekspor kebijakan saat ini ke file yang dapat diedit
gcloud container binauthz policy export > policy.yaml
- Ubah kebijakan
Di editor teks, ubah integrationMode 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 mendeklarasikan bahwa kebijakan ini memperluas kebijakan global yang ditentukan oleh Google. Dengan begitu, semua container GKE resmi dapat dijalankan 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 petunjuk tentang cara membuat kebijakan yang lebih kompleks, lihat dokumentasi Otorisasi Biner.
- Buka Terminal dan terapkan kebijakan baru, lalu tunggu beberapa detik agar perubahan diterapkan
gcloud container binauthz policy import policy.yaml
- Mencoba contoh deployment workload
kubectl run hello-server --image gcr.io/google-samples/hello-app:1.0 --port 8080
- 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
Kembalikan kebijakan untuk mengizinkan semua
Sebelum melanjutkan ke bagian berikutnya, pastikan Anda mengembalikan perubahan kebijakan
- Ubah kebijakan
Di editor teks, ubah exportMode 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
- Menerapkan kebijakan yang dikembalikan
gcloud container binauthz policy import policy.yaml
5. Menandatangani Gambar yang Dipindai
Anda telah mengaktifkan penandatanganan Gambar dan menggunakan Attestor secara manual untuk menandatangani gambar contoh. Dalam praktiknya, Anda sebaiknya 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 Cloud Build Service Account:
gcloud projects add-iam-policy-binding ${PROJECT_ID} \
--member serviceAccount:${PROJECT_NUMBER}@cloudbuild.gserviceaccount.com \
--role roles/binaryauthorization.attestorsViewer
Tambahkan peran Penanda/Pemverifikasi Cloud KMS CryptoKey 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 Notes Attacher Container Analysis ke Cloud Build Service Account:
gcloud projects add-iam-policy-binding ${PROJECT_ID} \
--member serviceAccount:${PROJECT_NUMBER}@cloudbuild.gserviceaccount.com \
--role roles/containeranalysis.notes.attacher
Memberikan 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"
Menyiapkan Langkah Cloud Build Custom Build
Anda akan menggunakan langkah Custom Build di Cloud Build untuk menyederhanakan proses pengesahan. Google menyediakan langkah Pembuatan Khusus 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 dalam pipeline Cloud Build.
- Tinjau langkah penandatanganan di bawah.
Hanya ulasan. 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'
- Tulis file cloudbuild.yaml dengan pipeline lengkap di bawah ini.
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
Meninjau build di Histori Cloud Build
Buka Konsol Cloud ke halaman Cloud Build History dan tinjau build terbaru tersebut dan keberhasilan eksekusi langkah build.
6. Mengizinkan Gambar Bertanda Tangan
Di bagian ini, Anda akan mengupdate GKE untuk menggunakan Otorisasi Biner untuk memvalidasi image yang memiliki tanda tangan dari pemindaian Kerentanan sebelum mengizinkan image untuk dijalankan.
Memperbarui Kebijakan GKE untuk Mewajibkan Pengesahan
Wajibkan gambar ditandatangani oleh Attestor Anda dengan menambahkan clusterAdmissionRules ke Kebijakan GKE BinAuth Anda
Saat ini, cluster Anda menjalankan kebijakan dengan satu aturan: izinkan container dari repositori resmi, dan tolak yang lainnya.
Timpa kebijakan dengan konfigurasi yang diperbarui menggunakan perintah di bawah.
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
Sekarang Anda akan memiliki file baru di disk bernama updated_policy.yaml. Sekarang, sebagai ganti aturan default yang menolak semua gambar, aturan ini akan memeriksa attestor Anda terlebih dahulu untuk mengetahui verifikasi.
Upload kebijakan baru ke Otorisasi Biner:
gcloud beta container binauthz policy import binauth_policy.yaml
Men-deploy image yang ditandatangani
Mendapatkan ringkasan gambar untuk mendapatkan gambar 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)')
Menggunakan digest 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
Men-deploy aplikasi ke GKE
kubectl apply -f deploy.yaml
Tinjau beban kerja di konsol dan catat keberhasilan deployment image.
7. Gambar yang tidak ditandatangani diblokir
Membuat Gambar
Pada langkah ini, Anda akan menggunakan Docker lokal untuk membangun image ke cache lokal.
docker build -t us-central1-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image:bad .
Mengirim image yang tidak ditandatangani ke repo
docker push us-central1-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image:bad
Mendapatkan ringkasan gambar untuk gambar 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)')
Menggunakan digest 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
Mencoba men-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 Gambar
- Kebijakan Kontrol Penerimaan
- Menandatangani Gambar yang Dipindai
- Mengizinkan Gambar Bertanda Tangan
- Gambar yang tidak ditandatangani diblokir
Langkah berikutnya:
- Mengamankan deployment image ke 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, atau simpan project dan hapus resource satu per satu.
Menghapus project
Cara termudah untuk menghilangkan penagihan adalah dengan menghapus project yang Anda buat untuk tutorial.
—
Terakhir diperbarui: 21/3/23