Tetap teratur dengan koleksi
Simpan dan kategorikan konten berdasarkan preferensi Anda.
Halaman ini menjelaskan cara men-deploy image container ke cluster GKE (diGoogle Cloud atau Google Distributed Cloud) tempat Otorisasi Biner diaktifkan.
Perintah kubectl yang Anda gunakan untuk men-deploy image sama dengan perintah yang Anda gunakan untuk men-deploy image ke cluster yang tidak menggunakan Otorisasi Biner.
Anda harus mengupdate file kubeconfig lokal untuk penginstalan kubectl Anda.
Hal ini memberikan informasi endpoint dan kredensial yang diperlukan untuk mengakses
cluster di GKE atau Distributed Cloud.
Untuk mengonfigurasi kubectl, jalankan perintah gcloud berikut:
GKE
gcloud container clusters get-credentials \
--zone ZONE \
CLUSTER_NAME
Ganti kode berikut:
ZONE: nama zona GKE tempat cluster berjalan, misalnya, us-central1-a
Untuk mempelajari cara mendapatkan ringkasan image di Artifact Registry, lihat
Mengelola image.
Deploy image Anda menggunakan perintah kubectl run.
Anda harus men-deploy image menggunakan ringkasan, bukan tag seperti 1.0 atau
latest, karena Otorisasi Biner menggunakan ringkasan untuk mencari
pengesahan.
Untuk men-deploy image, jalankan perintah kubectl berikut:
kubectl run ${POD_NAME} \
--image ${IMAGE_PATH}@${IMAGE_DIGEST}
Sekarang, verifikasi bahwa deployment diblokir oleh Otorisasi Biner:
kubectl get pods
Anda akan melihat Pod Anda tercantum.
Fail open
Jika GKE tidak dapat menghubungi server Otorisasi Biner karena alasan apa pun, atau jika server menampilkan error, GKE tidak dapat menentukan apakah Otorisasi Biner akan mengizinkan atau menolak image. Dalam hal ini, GKE gagal terbuka: secara default, GKE mengizinkan image di-deploy, tetapi membuat entri log di
Cloud Audit Logs untuk mencatat alasan image diizinkan.
Penerapan GKE gagal terbuka karena kompromi antara keandalan dan keamanan. GKE mengirimkan permintaan ke
Binary Authorization setiap kali Pod dibuat atau diupdate. Hal ini mencakup skenario saat Pod dibuat atau diupdate secara otomatis oleh pengontrol workload Kubernetes tingkat yang lebih tinggi, seperti ReplicaSet dan StatefulSet. Jika
GKE gagal ditutup, bukan dibuka, setiap
gangguan Binary Authorization akan menghentikan Pod ini agar tidak berjalan. Selain itu,
jika Pod ditolak, failover dapat menyebabkan kegagalan beruntun karena traffic yang dialihkan
membebani Pod yang masih berjalan. Setiap gangguan Otorisasi Biner dapat memicu gangguan total untuk cluster Anda, bahkan tanpa men-deploy image baru.
Men-deploy image yang melanggar kebijakan
Otorisasi Biner mendukung fitur yang dikenal sebagai breakglass yang memungkinkan image
di-deploy, meskipun melanggar kebijakan.
[[["Mudah dipahami","easyToUnderstand","thumb-up"],["Memecahkan masalah saya","solvedMyProblem","thumb-up"],["Lainnya","otherUp","thumb-up"]],[["Sulit dipahami","hardToUnderstand","thumb-down"],["Informasi atau kode contoh salah","incorrectInformationOrSampleCode","thumb-down"],["Informasi/contoh yang saya butuhkan tidak ada","missingTheInformationSamplesINeed","thumb-down"],["Masalah terjemahan","translationIssue","thumb-down"],["Lainnya","otherDown","thumb-down"]],["Terakhir diperbarui pada 2025-09-04 UTC."],[[["\u003cp\u003eThis guide explains how to deploy container images to a GKE cluster with Binary Authorization enabled, using the same \u003ccode\u003ekubectl\u003c/code\u003e commands as clusters without this feature.\u003c/p\u003e\n"],["\u003cp\u003eBefore deploying, you must have the Binary Authorization API enabled and a GKE cluster with Binary Authorization enabled, as well as have updated the local \u003ccode\u003ekubeconfig\u003c/code\u003e to interact with the cluster.\u003c/p\u003e\n"],["\u003cp\u003eDeploying the image requires specifying the image path and digest, not a tag, to enable Binary Authorization's attestation verification process.\u003c/p\u003e\n"],["\u003cp\u003eIn the event that the GKE cannot reach the Binary Authorization server or encounters an error, it defaults to allowing the image deployment but logs the occurrence in Cloud Audit Logs, this is known as fail open.\u003c/p\u003e\n"],["\u003cp\u003eBinary Authorization has a breakglass feature that allows deployment of images that are in violation of the set policy.\u003c/p\u003e\n"]]],[],null,["# Deploy containers (GKE, Distributed Cloud)\n\nThis page explains how to deploy a container image to a GKE cluster (on\nGoogle Cloud or Google Distributed Cloud) where Binary Authorization is enabled.\nThe `kubectl` commands you use to deploy the image are the same as the ones you\nuse to deploy images to clusters that don't use Binary Authorization.\n\nBefore you begin\n----------------\n\nMake sure you have the Binary Authorization API enabled in your project and a\nGKE cluster with Binary Authorization enabled. See\n[setting up on Google Kubernetes Engine](/binary-authorization/docs/setting-up) or\n[setting up on Distributed Cloud](/binary-authorization/docs/setting-up-on-prem).\n\nInstall [`kubectl`](https://kubernetes.io/docs/tasks/tools/install-kubectl) for interacting with GKE.\n\nConfigure `kubectl`\n-------------------\n\nYou must update the local `kubeconfig` file for your `kubectl` installation.\nThis provides the credentials and endpoint information required to access the\ncluster in GKE or Distributed Cloud.\n\nTo configure `kubectl`, run the following `gcloud` command: \n\n### GKE\n\n```\ngcloud container clusters get-credentials \\\n --zone ZONE \\\n CLUSTER_NAME\n```\n\nReplace the following:\n\n- \u003cvar translate=\"no\"\u003eZONE\u003c/var\u003e: the name of the GKE zone where the cluster is running, for example, `us-central1-a`\n- \u003cvar translate=\"no\"\u003eCLUSTER_NAME\u003c/var\u003e: the name of the cluster\n\n### Distributed Cloud\n\n```\ngcloud container fleet memberships get-credentials \\\n --location LOCATION \\\n MEMBERSHIP_NAME\n```\n\nReplace the following:\n\n- \u003cvar translate=\"no\"\u003eLOCATION\u003c/var\u003e: the location of the fleet membership of the GKE cluster, for example, `global`\n- \u003cvar translate=\"no\"\u003eMEMBERSHIP_NAME\u003c/var\u003e: the name of the fleet membership of the GKE cluster\n\nDeploy the container image\n--------------------------\n\nDeploy your container image as follows:\n\n1. Configure environment variables:\n\n POD_NAME=\u003cvar translate=\"no\"\u003ePOD_NAME\u003c/var\u003e\n IMAGE_PATH=\u003cvar translate=\"no\"\u003eIMAGE_PATH\u003c/var\u003e\n IMAGE_DIGEST=\u003cvar translate=\"no\"\u003eIMAGE_DIGEST\u003c/var\u003e\n\n Replace the following:\n - \u003cvar translate=\"no\"\u003ePOD_NAME\u003c/var\u003e: the name you want to use for the GKE workload\n - \u003cvar translate=\"no\"\u003eIMAGE_PATH\u003c/var\u003e: path of the image in [Artifact Registry](/artifact-registry/docs), or another registry.\n - \u003cvar translate=\"no\"\u003eIMAGE_DIGEST\u003c/var\u003e: the digest of the image manifest.\n Example is as follows:\n\n - Artifact Registry:\n - Path: `us-docker.pkg.dev/google-samples/containers/gke/hello-app`\n - Digest: `sha256:37e5287945774f27b418ce567cd77f4bbc9ef44a1bcd1a2312369f31f9cce567`\n\n To learn how to get the digest of an image in Artifact Registry, see\n [Managing images](/artifact-registry/docs/docker/manage-images#gcloud).\n2. Deploy your image using the `kubectl run` command.\n\n You must deploy the image using the digest rather than a tag like `1.0` or\n `latest`, as Binary Authorization uses the digest to look up\n [attestations](/binary-authorization/docs/key-concepts#attestations).\n\n To deploy the image, run the following `kubectl` command: \n\n ```\n kubectl run ${POD_NAME} \\\n --image ${IMAGE_PATH}@${IMAGE_DIGEST}\n ```\n\n Now, verify that the deployment was blocked by Binary Authorization: \n\n ```\n kubectl get pods\n ```\n\n You see your Pod listed.\n\nFail open\n---------\n\n\u003cbr /\u003e\n\nIf GKE is unable to reach the Binary Authorization\nserver for any reason, or if the server returns an error,\nGKE cannot determine whether Binary Authorization\nwould allow or deny the image. In this case, GKE fails open: it defaults to allowing the image to be deployed, but creates a log entry in\nCloud Audit Logs to record why the image was allowed.\n\nGKE enforcement fails open because of a tradeoff between\nreliability and security. GKE sends a request to the\nBinary Authorization whenever a Pod is created or updated. This includes\nscenarios where Pods are automatically created or updated by higher level\nKubernetes workload controllers, like ReplicaSets and StatefulSets. If\nGKE failed closed instead of open, any\nBinary Authorization outage would stop these Pods from running. Moreover,\nwhen Pods are denied, failover can lead to cascading failures as redirected\ntraffic overloads Pods that are still running. Any Binary Authorization\noutage could trigger a complete outage for your cluster, even without\ndeploying any new images.\n| **Note:** Operations that send enough requests to Binary Authorization to exceed the per-project, per-user, per-minute [quota](/binary-authorization/quotas) will trigger fail open. For example, testing whether Binary Authorization denies an image by trying to rapidly deploy that image repeatedly will cause the image to be allowed when the quota is exceeded. It is possible to [request additional\n| quota](/binary-authorization/quotas#quota_increases), if needed.\n\nDeploy images that violate the policy\n-------------------------------------\n\nBinary Authorization supports a feature known as *breakglass* that allows an image\nto be deployed, even if it violates the policy.\n\nFor more information, see [Using breakglass](/binary-authorization/docs/using-breakglass)\n\nClean up\n--------\n\nTo clean up, delete the Pod by executing the following command:\n\n\u003cbr /\u003e\n\n```\n kubectl delete pod ${POD_NAME}\n \n```\n\n\u003cbr /\u003e\n\nWhat's next\n-----------\n\n- Learn about [dry-run mode](/binary-authorization/docs/enabling-dry-run).\n- Learn how to [use CV](/binary-authorization/docs/overview-cv).\n- Learn how to [use legacy continuous validation](/binary-authorization/docs/using-cv) ([deprecated](/binary-authorization/docs/deprecations/cv-project-singleton-policy)).\n- Learn how to [use image digests in Kubernetes manifests](/architecture/using-container-image-digests-in-kubernetes-manifests)."]]
