Bermigrasi dari Pengontrol Kebijakan

Dokumen ini menjelaskan cara memigrasikan kebijakan penerimaan Anda dari Pengontrol Kebijakan untuk mengurangi risiko kesenjangan dalam penegakan kebijakan. Policy Controller tidak digunakan lagi mulai 12 November 2026, dan mencapai akhir dukungan pada 31 Desember 2027. Di versi 1.39 dan yang lebih baru, cluster Google Kubernetes Engine (GKE) tidak mendukung Pengontrol Kebijakan.

Anda dapat memigrasikan kebijakan penerimaan yang Anda terapkan menggunakan Pengontrol Kebijakan ke ValidatingAdmissionPolicies Kubernetes atau ke Gatekeeper Open Policy Agent (OPA) yang dikelola sendiri. Migrasi tidak memengaruhi workload yang sudah berjalan. Pengontrol Kebijakan mengevaluasi permintaan untuk membuat atau mengupdate resource, sehingga menghapusnya tidak akan memulai ulang atau mengubah workload yang sedang berjalan.

Dokumen ini ditujukan untuk operator dan pakar keamanan yang mengelola Pengontrol Kebijakan di seluruh fleet. Untuk mempelajari lebih lanjut peran umum dan contoh tugas yang kami referensikan dalam kontenGoogle Cloud , lihat Peran dan tugas pengguna GKE umum.

Upgrade yang diblokir ke GKE versi 1.39

GKE memblokir upgrade ke versi 1.39 dan yang lebih baru untuk cluster yang telah menginstal Pengontrol Kebijakan. Sebelum mengupgrade cluster ke versi 1.39, migrasikan kebijakan Anda dan hapus Pengontrol Kebijakan dari cluster tersebut. Jangan menghapus Pengontrol Kebijakan hanya untuk membatalkan pemblokiran upgrade sebelum Anda memigrasikan kebijakan, karena tindakan tersebut akan membuat cluster tidak memiliki penegakan kebijakan.

Pilih foto lain

Evaluasi setiap kebijakan penerimaan di Pengontrol Kebijakan dan pilih opsi pengganti untuk kebijakan tersebut dari tabel berikut. Anda tidak perlu memilih satu pengganti untuk seluruh cluster. Anda dapat menggabungkan opsi pada cluster yang sama berdasarkan persyaratan setiap kebijakan:

Perbandingan opsi penggantian Pengontrol Kebijakan
Opsi Kapan digunakan Operasi dan dukungan
ValidatingAdmissionPolicy (direkomendasikan) Kebijakan yang memeriksa satu resource saat dibuat atau diperbarui. Sebagian besar template di library template Pengontrol Kebijakan berfungsi seperti ini. ValidatingAdmissionPolicy diintegrasikan ke dalam Kubernetes dan tersedia di GKE versi 1.30 dan yang lebih baru tanpa biaya tambahan. Cloud Customer Care mendukung ValidatingAdmissionPolicies sebagai bagian dari GKE.
Pod Security Admission (direkomendasikan untuk paket keamanan Pod) Kontrol keamanan Pod yang telah ditetapkan dari paket pss-baseline-v2022, pss-restricted-v2022, atau psp-v2022. Untuk mengetahui informasi selengkapnya, lihat Menggunakan Pod Security Admission untuk paket keamanan Pod. Pod Security Admission diintegrasikan ke dalam Kubernetes dan diaktifkan secara default di GKE tanpa biaya tambahan. Layanan pelanggan mendukung Penerimaan Keamanan Pod sebagai bagian dari GKE.
Pemilah Komunikasi OPA yang dikelola sendiri Kebijakan yang tidak dapat dinyatakan oleh ValidatingAdmissionPolicies, seperti kebijakan referensial yang membaca resource lain dalam cluster, kebijakan yang ingin Anda pertahankan di Rego, dan audit resource yang ada. Anda juga dapat menambahkan aturan Common Expression Language (CEL) ke ConstraintTemplates Gatekeeper sehingga Gatekeeper membuat ValidatingAdmissionPolicies untuk penegakan server API, dan pengontrol auditnya memeriksa resource yang ada. Anda menginstal, mengupgrade, dan mengoperasikan Gatekeeper. Layanan Pelanggan tidak mendukung Gatekeeper open source. Komunitas Gatekeeper memberikan dukungan melalui GitHub.

Menginventarisasi dan mengklasifikasikan kebijakan Anda

Secara default, library template Pengontrol Kebijakan menginstal setiap template, dan paket kebijakan menginstal batasannya dengan tindakan penegakan kebijakan dryrun. Akibatnya, template dan batasan pada cluster tidak selalu cocok dengan kebijakan yang Anda terapkan. Untuk mengetahui apa yang Anda terapkan, ikuti langkah-langkah berikut:

  1. Identifikasi cluster di fleet Anda yang menjalankan Pengontrol Kebijakan:

    gcloud container fleet policycontroller describe \
    --project=PROJECT_ID

    Ganti PROJECT_ID dengan ID project host fleet Anda.

  2. Di setiap cluster yang Anda identifikasi, cantumkan batasan Anda:

    kubectl get constraints \
    -o custom-columns='KIND:.kind,NAME:.metadata.name,'\
'ACTION:.spec.enforcementAction,VIOLATIONS:.status.totalViolations,'\
'BUNDLE:.metadata.labels.policycontroller\.gke\.io/bundleName'

    Output-nya menampilkan tindakan penegakan kebijakan setiap batasan, jumlah pelanggarannya dari audit terbaru, dan paket apa pun yang menginstalnya. Batasan yang tidak memiliki nilai di kolom ACTION akan menggunakan tindakan penegakan kebijakan deny default.

  3. Cadangkan ConstraintTemplate dan batasan Anda ke file terpisah:

    kubectl get constrainttemplates -o yaml \
    > policy-controller-templates-backup.yaml
kubectl get constraints -o yaml \
    > policy-controller-constraints-backup.yaml

  4. Opsional: Lakukan operasi pencadangan tambahan berikut:

    • Jika Anda mengaktifkan aturan referensial di Pengontrol Kebijakan, cadangkan konfigurasi sinkronisasi Anda:

      kubectl get config.config.gatekeeper.sh -n gatekeeper-system -o yaml \
    > policy-controller-config-backup.yaml

    • Jika Anda mengaktifkan mutasi di Pengontrol Kebijakan, cadangkan mutator Anda:

      kubectl get assign,assignmetadata,assignimage,modifyset -o yaml \
    > policy-controller-mutators-backup.yaml

Simpan file cadangan ini di tempat yang aman. Menghapus Pengontrol Kebijakan akan menghapus setiap ConstraintTemplate, batasan, konfigurasi sinkronisasi, dan mutator di cluster, termasuk yang Anda buat. Anda memerlukan cadangan untuk menerjemahkan atau membuat ulang kebijakan.

Setelah mencadangkan kebijakan, tentukan jalur migrasi untuk setiap batasan dengan memeriksa jenis batasan dalam tabel berikut:

Jalur migrasi berdasarkan jenis batasan
Jenis batasan Jalur migrasi
Batasan resource tunggal Jika batasan mengevaluasi kolom hanya pada resource yang masuk tanpa membaca data.inventory atau termasuk dalam paket keamanan Pod, gunakan ValidatingAdmissionPolicy.
Batasan dryrun yang tidak diterapkan Jika batasan menggunakan tindakan penegakan kebijakan dryrun dan Anda tidak berencana untuk menerapkannya, hapus batasan tersebut.
Batasan paket keamanan pod Jika batasan berasal dari paket pss-baseline-v2022, pss-restricted-v2022, atau psp-v2022, gunakan Pod Security Admission. Gunakan ValidatingAdmissionPolicies untuk kontrol apa pun yang tidak tercakup dalam Pod Security Admission.
Batasan referensial Jika batasan menggunakan template referensial yang membaca resource lain dalam cluster, gunakan Gatekeeper yang dikelola sendiri. Untuk menemukan template referensial, telusuri file cadangan Anda untuk menemukan referensi data.inventory.
Cloud Service Mesh, Istio, atau batasan Google Cloud Tinjau batasan satu per satu untuk memeriksa apakah fitur GKE bawaan menggantikan kebijakan, atau apakah ConstraintTemplate dalam file cadangan Anda membaca data.inventory. Sebagian besar template ini hanya memeriksa resource yang masuk dan berfungsi di ValidatingAdmissionPolicies, kecuali template AsmAuthzPolicyDefaultDeny dan AsmPeerAuthnMeshStrictMtls referensial, yang memerlukan Gatekeeper yang dikelola sendiri. Untuk pengganti bawaan, aktifkan Otorisasi Biner, bukan menggunakan ConstraintTemplate K8sRequireBinAuthZ, dan konfigurasikan image node dari node pool Anda, bukan menggunakan ConstraintTemplate K8sRequireCosNodeImage.

Bermigrasi ke ValidatingAdmissionPolicy

ValidatingAdmissionPolicy berisi logika kebijakan, seperti ConstraintTemplate. ValidatingAdmissionPolicyBinding menerapkan kebijakan, seperti batasan. ValidatingAdmissionPolicy menggunakan ekspresi CEL, bukan Rego, dan server API mengevaluasi ekspresi secara langsung, tanpa webhook.

Contoh: repositori image yang diizinkan

Batasan Pengontrol Kebijakan berikut mengharuskan Pod menggunakan image dari satu repositori Artifact Registry. Namespace kube-system dikecualikan:

apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sAllowedRepos
metadata:
  name: allowed-repos
spec:
  enforcementAction: deny
  match:
    kinds:
    - apiGroups: [""]
      kinds: ["Pod"]
    excludedNamespaces: ["kube-system"]
  parameters:
    repos:
    - "us-docker.pkg.dev/example-project/example-repo/"

ValidatingAdmissionPolicy dan ValidatingAdmissionPolicyBinding berikut menerapkan aturan yang sama. ValidatingAdmissionPolicyBinding menggunakan tindakan Warn dan Audit sehingga Anda dapat membandingkan hasil sebelum menerapkan ValidatingAdmissionPolicy:

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingAdmissionPolicy
metadata:
  name: allowed-repos
spec:
  failurePolicy: Fail
  matchConstraints:
    resourceRules:
    - apiGroups: [""]
      apiVersions: ["v1"]
      operations: ["CREATE", "UPDATE"]
      resources: ["pods", "pods/ephemeralcontainers"]
  variables:
  - name: repos
    expression: "['us-docker.pkg.dev/example-project/example-repo/']"
  - name: images
    expression: >-
      object.spec.containers.map(c, c.image) +
      (has(object.spec.initContainers) ?
        object.spec.initContainers.map(c, c.image) : []) +
      (has(object.spec.ephemeralContainers) ?
        object.spec.ephemeralContainers.map(c, c.image) : [])
  validations:
  - expression: >-
      variables.images.all(image,
        variables.repos.exists(repo, image.startsWith(repo)))
    messageExpression: >-
      'container images must come from one of these repositories: ' +
      variables.repos.join(', ')
    reason: Forbidden
---
apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingAdmissionPolicyBinding
metadata:
  name: allowed-repos
spec:
  policyName: allowed-repos
  validationActions: ["Warn", "Audit"]
  matchResources:
    namespaceSelector:
      matchExpressions:
      - key: kubernetes.io/metadata.name
        operator: NotIn
        values: ["kube-system", "gatekeeper-system"]

Dalam contoh ini, variabel repos menyimpan nilai dari kolom parameters batasan. Ekspresi validasi menampilkan nilai true untuk Pod yang mematuhi ValidatingAdmissionPolicy, yang merupakan kebalikan dari aturan pelanggaran Rego. Untuk menggunakan kembali satu ValidatingAdmissionPolicy di beberapa ValidatingAdmissionPolicyBinding yang menyediakan nilai berbeda, gunakan resource parameter, bukan variabel. Untuk mengetahui informasi selengkapnya tentang resource parameter, lihat Resource parameter dalam dokumentasi Kubernetes.

Tabel berikut menunjukkan cara kolom batasan dipetakan ke kolom ValidatingAdmissionPolicy dan ValidatingAdmissionPolicyBinding:

Pemetaan kolom batasan Pengontrol Kebijakan ke kolom ValidatingAdmissionPolicy dan ValidatingAdmissionPolicyBinding
Kolom batasan Kolom ValidatingAdmissionPolicy atau ValidatingAdmissionPolicyBinding
spec.enforcementAction Kolom validationActions di ValidatingAdmissionPolicyBinding, yang memetakan tindakan deny, warn, dan dryrun ke nilai ["Deny"], ["Warn"], dan ["Audit"]
spec.parameters Kolom variables di ValidatingAdmissionPolicy, atau resource parameter yang direferensikan ValidatingAdmissionPolicyBinding di kolom paramRef
spec.match.kinds Kolom matchConstraints.resourceRules di ValidatingAdmissionPolicy, yang menggunakan grup API dan nama resource, seperti resource pods, bukan jenis
spec.match.namespaces dan spec.match.excludedNamespaces Kolom matchResources.namespaceSelector di ValidatingAdmissionPolicyBinding, menggunakan operator In atau NotIn pada label kubernetes.io/metadata.name
spec.match.labelSelector Kolom matchResources.objectSelector di ValidatingAdmissionPolicyBinding
spec.match.namespaceSelector Kolom matchResources.namespaceSelector di ValidatingAdmissionPolicyBinding
spec.match.scope Kolom scope dari setiap aturan resource

Untuk mengetahui informasi selengkapnya tentang cara menulis ekspresi, lihat CEL di Kubernetes dalam dokumentasi Kubernetes.

Menguji kebijakan bersama Pengontrol Kebijakan

Untuk mengganti batasan tanpa celah dalam penerapan, jalankan ValidatingAdmissionPolicy di samping batasan sebelum Anda menerapkan ValidatingAdmissionPolicy:

  1. Terapkan ValidatingAdmissionPolicy dan ValidatingAdmissionPolicyBinding yang memiliki setelan validationActions: ["Warn", "Audit"]. Biarkan batasan Pengontrol Kebijakan tetap berlaku.
  2. Bandingkan hasilnya menggunakan kueri log audit di Mengganti pelaporan pelanggaran. Jika ValidatingAdmissionPolicy menandai permintaan yang diizinkan oleh Pengontrol Kebijakan, atau sebaliknya, perbaiki ValidatingAdmissionPolicy. Untuk ValidatingAdmissionPolicies yang cocok dengan Pod, jangan mengandalkan peringatan. Pengontrol membuat Pod untuk Deployment dan workload lainnya, sehingga pengontrol menerima peringatan.
  3. Setelah hasilnya cocok, ubah ValidatingAdmissionPolicyBinding untuk menggunakan setelan validationActions: ["Deny"].
  4. Hapus batasan Pengontrol Kebijakan.

Merencanakan perbedaan perilaku

ValidatingAdmissionPolicies berperilaku berbeda dari Pengontrol Kebijakan dengan cara berikut, yang dapat memblokir permintaan atau meninggalkan celah dalam penegakan:

  • Kebijakan kegagalan: webhook Pengontrol Kebijakan gagal terbuka, yang berarti server API menerima permintaan jika Pengontrol Kebijakan tidak merespons. ValidatingAdmissionPolicy yang memiliki setelan failurePolicy: Fail akan menolak permintaan jika ekspresi menampilkan error atau melebihi batas biaya CEL. ValidatingAdmissionPolicy juga menolak permintaan jika resource parameter yang direferensikan tidak ada dan nilai kolom paramRef.parameterNotFoundAction di ValidatingAdmissionPolicyBinding adalah Deny. Jika nilainya adalah Allow, server API akan melewati resource parameter yang tidak ada, terlepas dari setelan failurePolicy. Uji setiap ValidatingAdmissionPolicy dan pilih nilai untuk kedua kolom.
  • Kolom tidak ada: Rego memperlakukan kolom yang tidak ada sebagai tidak ada pelanggaran, tetapi CEL menampilkan error. Sebelum membaca kolom opsional, gunakan makro has() untuk memeriksa apakah kolom tersebut ada.
  • Pengecualian: ValidatingAdmissionPolicy tidak mengecualikan namespace secara default atau menggunakan label admission.gatekeeper.sh/ignore. Di cluster GKE Standard, ValidatingAdmissionPolicyBinding berlaku untuk setiap namespace dalam cluster, termasuk namespace sistem seperti namespace kube-system, kecuali jika Anda mengecualikannya di kolom matchResources.namespaceSelector pada ValidatingAdmissionPolicyBinding atau di kolom matchConstraints.namespaceSelector atau matchConditions pada ValidatingAdmissionPolicy. Di cluster Autopilot, GKE mengecualikan namespace terkelola secara otomatis dan menolak ValidatingAdmissionPolicy yang cocok dengan resource nodes, persistentVolumes, certificatesigningrequests, atau tokenreviews. Untuk mengetahui informasi selengkapnya, lihat Langkah-langkah keamanan GKE Autopilot.
  • Subresource: Pengontrol Kebijakan memeriksa update Pod yang menambahkan container sementara. Untuk mempertahankan cakupan tersebut, sertakan subresource pods/ephemeralcontainers dalam aturan resource Anda, seperti yang dilakukan dalam contoh.
  • Tidak ada audit resource yang ada: ValidatingAdmissionPolicy hanya mengevaluasi permintaan server API yang masuk. ValidatingAdmissionPolicy tidak melaporkan resource yang ada yang melanggar ValidatingAdmissionPolicy.
  • Satu pesan untuk setiap permintaan: ValidatingAdmissionPolicy melaporkan validasi pertama yang gagal, bukan setiap pelanggaran.

Menggunakan Pod Security Admission untuk paket keamanan Pod

Jika Anda menggunakan paket pss-baseline-v2022 atau pss-restricted-v2022, ganti paket tersebut dengan Pod Security Admission, bukan menerjemahkan setiap batasan. Pod Security Admission menggunakan pengontrol penerimaan PodSecurity bawaan Kubernetes untuk menerapkan aturan yang telah ditetapkan dari Standar Keamanan Pod Kubernetes berdasarkan label namespace. Paket pss-baseline-v2022 sesuai dengan level baseline, dan paket pss-restricted-v2022 sesuai dengan level restricted.

Pod Security Admission tidak mencakup setiap kontrol dalam paket psp-v2022, seperti daftar yang diizinkan untuk jalur host, pengguna, kemampuan, dan sysctl. Gunakan ValidatingAdmissionPolicies untuk kontrol tersebut. Pod Security Admission juga tidak dapat mengecualikan image tertentu, seperti batasan Pengontrol Kebijakan yang menggunakan parameter exemptImages. GKE tidak mendukung konfigurasi pengecualian Pod Security Admission. Jika Anda memerlukan pengecualian, gunakan ValidatingAdmissionPolicies untuk kebijakan yang terpengaruh.

Untuk mengetahui informasi selengkapnya tentang cara mengonfigurasi Pod Security Admission, lihat Menerapkan kebijakan keamanan level Pod yang telah ditetapkan sebelumnya menggunakan PodSecurity.

Bermigrasi ke Pemilah Komunikasi OPA yang dikelola sendiri

Pilih Gatekeeper untuk kebijakan yang tidak dapat dinyatakan oleh ValidatingAdmissionPolicies. Pengontrol Kebijakan didasarkan pada Gatekeeper, sehingga ConstraintTemplate dan batasan Anda menggunakan API yang sama di Gatekeeper. Semua template di library template Pengontrol Kebijakan berfungsi di Gatekeeper tanpa perubahan pada logikanya. Namun, Gatekeeper menggunakan mesin Rego yang lebih baru dan validasi yang lebih ketat yang dapat menolak ConstraintTemplate kustom.

Saat menggunakan Gatekeeper yang dikelola sendiri, Anda bertanggung jawab atas tugas yang dilakukanGoogle Cloud untuk Pengontrol Kebijakan, seperti menginstal, mengupgrade, menskalakan, dan memantau Gatekeeper di setiap cluster. Layanan Pelanggan tidak mendukung Gatekeeper open source. Untuk mendapatkan bantuan, gunakan Issue tracker GitHub Gatekeeper.

Gatekeeper tidak menyertakan library template atau paket kebijakan Pengontrol Kebijakan. File cadangan Anda berisi ConstraintTemplates dan batasan dari cluster Anda. Untuk template yang berasal dari library Gatekeeper open source, Anda dapat menggunakan template di library kebijakan Gatekeeper. Nama template tetap sama, tetapi parameter dan pesan dapat berbeda antar-versi.

Untuk memindahkan kebijakan ke Gatekeeper, ikuti langkah-langkah berikut:

  1. Opsional: Jika Anda tidak dapat menerima kesenjangan dalam penerapan saat mengganti Policy Controller, migrasikan kebijakan yang paling penting ke ValidatingAdmissionPolicies terlebih dahulu. Pastikan ValidatingAdmissionPolicyBindings tersebut mengecualikan namespace gatekeeper-system agar tidak memblokir Tugas penginstalan Gatekeeper. Setelah Anda menghapus Pengontrol Kebijakan, cluster Anda akan berhenti menerapkan kebijakan Gatekeeper hingga Anda menerapkan batasan Gatekeeper yang sesuai. ValidatingAdmissionPolicies terus diterapkan karena tidak bergantung pada Pengontrol Kebijakan atau Gatekeeper.

  2. Jika Anda menggunakan ConstraintTemplate kustom, uji setiap manifes template kustom menggunakan alat command line gator dari versi Gatekeeper yang ingin Anda instal:

    gator test --filename=TEMPLATE_FILE

    Ganti TEMPLATE_FILE dengan jalur ke file manifes ConstraintTemplate Anda. Sebelum menghapus Pengontrol Kebijakan, perbaiki ConstraintTemplate kustom yang ditolak Gatekeeper.

  3. Jika Anda men-deploy batasan dari repositori Git menggunakan alat GitOps, siapkan ConstraintTemplate yang digunakan batasan Anda dan tambahkan ke repositori saat Anda menginstal Gatekeeper. Jika tidak, batasan Anda akan gagal diterapkan setelah Anda menghapus Pengontrol Kebijakan karena ConstraintTemplates-nya tidak ada lagi.

  4. Hapus Pengontrol Kebijakan dengan mengikuti langkah-langkah di Menghapus Pengontrol Kebijakan. Jangan instal Gatekeeper di cluster yang masih menjalankan Pengontrol Kebijakan. Keduanya menggunakan namespace gatekeeper-system, CustomResourceDefinition yang sama, dan nama webhook yang sama.

  5. Instal Gatekeeper menggunakan Helm, menggunakan setelan yang Anda pilih dari tabel di bagian berikutnya, Setelan Gatekeeper yang berbeda dari Pengontrol Kebijakan. Untuk mengetahui informasi selengkapnya tentang cara menginstal Gatekeeper, lihat Penginstalan dalam dokumentasi Gatekeeper.

    Di cluster Autopilot, penginstalan diagram Helm default gagal karena GKE menolak aturan karakter pengganti dalam webhook mutasi. Tetapkan nilai Helm disableMutation: true, atau tetapkan nilai Helm mutatingWebhookCustomRules untuk mencantumkan hanya resource tertentu yang ditargetkan oleh mutator Anda. Jangan sertakan resource nodes, persistentvolumes, certificatesigningrequests, atau tokenreviews.

  6. Dalam file cadangan, hapus kolom, label, dan anotasi berikut dari setiap resource yang ingin Anda terapkan kembali:

    • Kolom status.
    • Kolom resourceVersion, uid, creationTimestamp, generation, managedFields, dan ownerReferences di bagian metadata.
    • Anotasi kubectl.kubernetes.io/last-applied-configuration.
    • Label app.kubernetes.io/managed-by: anthospolicycontroller.googleapis.com. Jika Pengontrol Kebijakan diaktifkan lagi di cluster, misalnya melalui konfigurasi default tingkat fleet, Pengontrol Kebijakan akan mengelola resource yang memiliki label ini dan dapat mengubah atau menghapusnya.
    • Label dan anotasi yang kuncinya memiliki awalan policycontroller..

  7. Terapkan ConstraintTemplate yang digunakan batasan Anda, lalu periksa apakah Gatekeeper membuat CustomResourceDefinition untuk setiap template:

    kubectl get constrainttemplates \
    -o custom-columns='NAME:.metadata.name,CREATED:.status.created'

    Jika setiap template menampilkan nilai true di kolom CREATED, terapkan batasan Anda.

Setelan Gatekeeper yang berbeda dari Pengontrol Kebijakan

Sebelum menginstal Gatekeeper, tinjau setelan dalam tabel berikut yang menunjukkan perbedaan antara default diagram Helm Gatekeeper dan Pengontrol Kebijakan:

Perbandingan default Pengontrol Kebijakan dan default diagram Helm Gatekeeper
Setelan Default Pengontrol Kebijakan Default diagram Helm Gatekeeper Rekomendasi
Mutasi Nonaktif kecuali jika Anda mengaktifkannya Aktif Jika Anda tidak menggunakan mutasi, tetapkan nilai Helm disableMutation: true. Pada cluster Autopilot, Anda harus menetapkan nilai Helm disableMutation: true atau mengonfigurasi nilai Helm mutatingWebhookCustomRules tanpa karakter pengganti atau resource yang dibatasi. Jika Anda tidak menentukan salah satu nilai ini, GKE akan menolak penginstalan.
Namespace yang dikecualikan Namespace gatekeeper-system dan namespace dalam daftar exemptableNamespaces Anda Namespace tempat Gatekeeper diinstal Tambahkan namespace yang dikecualikan ke nilai Helm controllerManager.exemptNamespaces. Gatekeeper menolak perubahan pada namespace yang memiliki label admission.gatekeeper.sh/ignore kecuali jika namespace tersebut dikecualikan.
Data referensial Disinkronkan secara otomatis untuk paket referensial Tidak disinkronkan Buat Config atau SyncSet Gatekeeper yang mencantumkan jenis yang dibaca oleh template referensial Anda. Hingga jenis tersebut disinkronkan ke dalam objek data.inventory, pemeriksaan konflik akan mengizinkan permintaan yang melanggar, dan pemeriksaan keberadaan, seperti K8sRequireNamespaceNetworkPolicies ConstraintTemplate, akan menolak setiap permintaan yang cocok meskipun resource yang diperlukan ada.
Pembuatan ValidatingAdmissionPolicy Tidak tersedia Aktif untuk template yang berisi kode CEL Template Pengontrol Kebijakan hanya berisi Rego, sehingga Gatekeeper hanya akan membuat ValidatingAdmissionPolicies jika Anda menambahkan CEL ke ConstraintTemplates. Untuk mempertahankan penerapan di webhook, tetapkan nilai Helm defaultCreateVAPForTemplates: false dan defaultCreateVAPBindingForConstraints: false. Untuk mengetahui informasi selengkapnya, lihat Integrasi dengan Kebijakan Penerimaan Validasi Kubernetes dalam dokumentasi Gatekeeper.
Replika dan resource Satu replika untuk setiap komponen, dengan batas memori 1.024 MiB Tiga replika webhook, dengan batas resource yang berbeda Konfigurasikan jumlah replika dan batas resource berdasarkan penggunaan Anda saat ini.
Gambar Diambil dari registry yang dikelola Google Diambil dari Docker Hub (image openpolicyagent/gatekeeper, openpolicyagent/gatekeeper-crds, dan curlimages/curl) Untuk cluster pribadi atau cluster yang menerapkan Otorisasi Biner, duplikasi ketiga image ke Artifact Registry dan ganti nilai image-nya dalam diagram. Jika Anda tidak mencerminkan image curlimages/curl, nonaktifkan Tugas pemeriksaan webhook.

Secara default, Gatekeeper hanya mengekspos metrik Prometheus, dan nama metriknya berbeda dengan nama yang dikirim Pengontrol Kebijakan ke Cloud Monitoring. Perbarui dasbor dan pemberitahuan yang menggunakan metrik Pengontrol Kebijakan.

Memigrasikan kebijakan mutasi

Jika Anda mengaktifkan mutasi di Pengontrol Kebijakan, cantumkan mutator Anda:

kubectl get assign,assignmetadata,assignimage,modifyset

Untuk setiap mutator, pilih salah satu opsi berikut:

  • MutatingAdmissionPolicy: Anda dapat menggunakan MutatingAdmissionPolicy di GKE versi 1.36 dan yang lebih baru. Seperti ValidatingAdmissionPolicy, MutatingAdmissionPolicy menggunakan ekspresi CEL dan berjalan di server API tanpa webhook. Kubernetes menjalankan semua MutatingAdmissionPolicy sebelum ValidatingAdmissionPolicy, jadi uji keduanya bersama-sama untuk memastikan bahwa mutasi tidak menyebabkan ValidatingAdmissionPolicy menolak manifes yang valid. Di cluster Autopilot, GKE mengecualikan namespace terkelola dari MutatingAdmissionPolicies. Untuk mengetahui informasi selengkapnya tentang kebijakan mutasi, lihat Kebijakan Penerimaan Mutasi dalam dokumentasi Kubernetes.
  • Gatekeeper yang dikelola sendiri: di cluster Standard, mutator Anda berfungsi tanpa perubahan karena Gatekeeper mengaktifkan mutasi secara default. Di cluster Autopilot, Anda harus menetapkan nilai Helm mutatingWebhookCustomRules di diagram Gatekeeper untuk mencantumkan resource tertentu yang ditargetkan oleh mutator, bukan aturan karakter pengganti. Untuk mengetahui informasi selengkapnya, lihat Langkah-langkah keamanan GKE Autopilot. Setelah menginstal Gatekeeper, hapus metadata Pengontrol Kebijakan dari file cadangan mutator dan terapkan kembali mutator, seperti yang Anda lakukan untuk batasan.

Memperbarui pemeriksaan kebijakan di pipeline build

Pipeline build Anda mungkin memeriksa manifes terhadap batasan Pengontrol Kebijakan sebelum deployment. Misalnya, pipeline mungkin menggunakan fungsi gatekeeper di kpt atau alat command line gator. Untuk mengetahui informasi selengkapnya, lihat Memvalidasi aplikasi berdasarkan kebijakan perusahaan di pipeline CI.

Jika pipeline Anda memeriksa manifes, perbarui pipeline tersebut untuk penggantian Anda:

  • Jika Anda menggunakan Gatekeeper, Anda dapat mempertahankan pipeline Anda. Perbarui jalur file atau direktori dalam perintah gator atau kpt untuk mereferensikan repositori atau direktori yang berisi ConstraintTemplate dan manifes batasan Gatekeeper yang telah dibersihkan.

  • Jika Anda menggunakan ValidatingAdmissionPolicies, alat tersebut tidak akan mengevaluasi kebijakan Anda. Sebagai gantinya, jalankan uji coba sisi server terhadap cluster pengujian yang memiliki ValidatingAdmissionPolicy dan ValidatingAdmissionPolicyBinding yang menggunakan tindakan Deny:

    kubectl apply --dry-run=server -f MANIFEST_DIRECTORY

    Ganti MANIFEST_DIRECTORY dengan direktori yang berisi manifes Anda. Perintah akan gagal jika ValidatingAdmissionPolicy menolak manifes.

Mengganti pelaporan pelanggaran

ValidatingAdmissionPolicy tidak menyertakan dasbor, dan tidak mengaudit resource yang sudah ada di cluster Anda. Gunakan metode berikut:

  • Peringatan: jika ValidatingAdmissionPolicyBinding menggunakan tindakan Warn, server API akan menampilkan peringatan kepada klien yang mengirim permintaan, seperti alat command line kubectl. Untuk Pod yang dibuat oleh pengontrol, seperti Pod dalam Deployment, pengontrol akan menerima peringatan.

  • Log audit: jika ValidatingAdmissionPolicyBinding menggunakan tindakan Audit, server API akan menganotasi entri log audit untuk setiap validasi yang gagal. GKE menulis permintaan pembuatan, pembaruan, dan penghapusan ke log audit Aktivitas Admin di Cloud Logging. Untuk menemukan validasi yang gagal, jalankan kueri berikut di Logs Explorer:

    resource.type="k8s_cluster"
logName:"cloudaudit.googleapis.com%2Factivity"
labels."validation.policy.admission.k8s.io/validation_failure":*

Jika Anda menggunakan batasan yang memiliki tindakan penerapan dryrun sebagai laporan kepatuhan pada resource yang ada, ValidatingAdmissionPolicies tidak dapat menggantikan laporan tersebut. Pertahankan kebijakan tersebut di Gatekeeper yang dikelola sendiri, yang pengontrol auditnya memeriksa resource yang ada sesuai jadwal.

Menghapus Pengontrol Kebijakan

Sebelum Anda menghapus Pengontrol Kebijakan dari cluster, selesaikan tugas-tugas berikut:

  • Pastikan kebijakan apa pun yang Anda migrasikan ke ValidatingAdmissionPolicies atau Pod Security Admission diterapkan dan Anda memiliki cadangan ConstraintTemplate, batasan, dan mutator. Menghapus Pengontrol Kebijakan akan menghapus CustomResourceDefinition-nya, yang akan menghapus setiap ConstraintTemplate, batasan, dan mutator di cluster, termasuk yang Anda buat.
  • Jika Anda men-deploy batasan dari repositori Git menggunakan alat GitOps seperti Config Sync atau Argo CD, hapus batasan yang diganti dari repositori. Pastikan batasan telah dihapus dari cluster Anda.
  • Opsional: Untuk mengonfirmasi bahwa tidak ada yang bergantung pada webhook Pengontrol Kebijakan, tangguhkan Pengontrol Kebijakan terlebih dahulu. Penangguhan hanya menghapus konfigurasi webhook, dan Anda dapat memulihkannya.

Untuk menghapus Pengontrol Kebijakan, ikuti langkah-langkah berikut:

  1. Uninstal Pengontrol Kebijakan dari cluster Anda:

    gcloud container fleet policycontroller disable \
    --memberships=MEMBERSHIP_NAME \
    --project=PROJECT_ID

    Ganti kode berikut:

    • MEMBERSHIP_NAME: nama keanggotaan cluster terdaftar yang ingin Anda uninstal Pengontrol Kebijakan-nya. Untuk meng-uninstal Pengontrol Kebijakan dari beberapa cluster, tentukan comma separated list nama keanggotaan, atau ganti flag --memberships=MEMBERSHIP_NAME dengan flag --all-memberships.
    • PROJECT_ID: ID project host fleet Anda.

  2. Pastikan Policy Controller telah selesai di-uninstal dari cluster Anda:

    gcloud container fleet policycontroller describe \
    --memberships=MEMBERSHIP_NAME \
    --project=PROJECT_ID \
    --format="yaml(membershipStates)"

    Tunggu hingga nilai kolom policycontroller.state level teratas untuk setiap keanggotaan adalah NOT_INSTALLED, bukan DECOMMISSIONING. Entri componentStates individual mencapai status NOT_INSTALLED sebelum pembersihan CustomResourceDefinition selesai.

    Jika Anda berencana menginstal Gatekeeper yang dikelola sendiri, pastikan namespace gatekeeper-system sudah tidak ada:

    kubectl get namespace gatekeeper-system

    Tunggu hingga output melaporkan bahwa namespace gatekeeper-system tidak ditemukan.

  3. Opsional: Untuk mencegah cluster yang Anda daftarkan nanti mendapatkan Pengontrol Kebijakan, hapus konfigurasi default tingkat fleet:

    gcloud container fleet policycontroller enable \
    --no-fleet-default-member-config \
    --project=PROJECT_ID

    Perintah ini hanya menghapus konfigurasi default. Paket ini tidak menginstal Pengontrol Kebijakan di cluster mana pun.

Menghapus Pengontrol Kebijakan dari cluster di luar fleet

Perintah gcloud container fleet policycontroller disable hanya menghapus Pengontrol Kebijakan dari cluster yang dikelola fleet. Cluster dapat menjalankan Pengontrol Kebijakan tanpa pengelolaan fleet dalam kasus berikut:

  • Anda telah menginstal Pengontrol Kebijakan menggunakan Operator ConfigManagement.
  • Anda membatalkan pendaftaran cluster dari fleet-nya, atau menjalankan perintah gcloud container fleet policycontroller detach, sebelum Pengontrol Kebijakan selesai di-uninstal.

Untuk menghapus Pengontrol Kebijakan dari cluster ini, tempatkan cluster di bawah pengelolaan fleet, lalu uninstal Pengontrol Kebijakan:

  1. Cadangkan ConstraintTemplate, batasan, konfigurasi sinkronisasi, dan mutator Anda, seperti yang dijelaskan dalam Menginventarisasi dan mengklasifikasikan kebijakan Anda. Saat Anda membersihkan metadata dari cadangan yang diambil dari penginstalan Operator ConfigManagement, hapus juga label configmanagement.gke.io/* dan k8s-app: kubernetes-config-management selain kolom ownerReferences dan metadata policycontroller.*.

  2. Jika Anda menginstal Pengontrol Kebijakan menggunakan ConfigManagement Operator, hapus kolom policyController dari resource kustom ConfigManagement pada cluster. Tunggu hingga rekonsiliasi selesai. Rekonsiliasi dapat memerlukan waktu sekitar dua menit. Kemudian, periksa apakah namespace gatekeeper-system masih ada:

    kubectl get namespace gatekeeper-system

    Di ConfigManagement Operator versi 1.17 dan yang lebih lama, menghapus kolom policyController akan otomatis meng-uninstal Pengontrol Kebijakan. Jika namespace gatekeeper-system tidak ditemukan, lewati langkah-langkah yang tersisa di bagian ini. Di ConfigManagement Operator versi 1.18 dan yang lebih baru, namespace gatekeeper-system tetap berada di cluster, jadi lanjutkan ke langkah berikutnya.

  3. Jika cluster belum terdaftar ke fleet, daftarkan cluster tersebut. Untuk mengetahui informasi selengkapnya, lihat Mendaftarkan cluster di Google Cloud ke fleet Anda.

  4. Periksa apakah mutasi diaktifkan di cluster:

    kubectl get mutatingwebhookconfiguration \
    gatekeeper-mutating-webhook-configuration

  5. Aktifkan Pengontrol Kebijakan pada keanggotaan cluster sehingga fleet mengambil alih pengelolaan penginstalan yang ada. Jika perintah sebelumnya menampilkan resource gatekeeper-mutating-webhook-configuration, sertakan flag --mutation agar fleet mengadopsi dan nantinya menghapus resource mutasi cakupan cluster:

    gcloud container fleet policycontroller enable \
    --memberships=MEMBERSHIP_NAME \
    --project=PROJECT_ID

    Ganti kode berikut:

    • MEMBERSHIP_NAME: nama keanggotaan cluster terdaftar Anda.
    • PROJECT_ID: ID project host fleet Anda.

  6. Tunggu hingga nilai kolom policycontroller.state untuk keanggotaan adalah ACTIVE:

    gcloud container fleet policycontroller describe \
    --memberships=MEMBERSHIP_NAME \
    --project=PROJECT_ID \
    --format="yaml(membershipStates)"

  7. Uninstal Pengontrol Kebijakan dengan mengikuti langkah-langkah di bagian Menghapus Pengontrol Kebijakan. Jika Anda tidak menginstal Gatekeeper yang dikelola sendiri, hapus CustomResourceDefinitions batasan yang tersisa setelah namespace gatekeeper-system dihapus:

    kubectl get crd -o name \
    | grep '\.constraints\.gatekeeper\.sh$' \
    | xargs -r kubectl delete

  8. Opsional: Jika Anda mendaftarkan cluster hanya untuk menyelesaikan prosedur ini, batalkan pendaftarannya setelah perintah describe menampilkan status NOT_INSTALLED untuk keanggotaan. Untuk cluster yang Anda daftarkan menggunakan flag --enable-fleet, jalankan perintah gcloud container clusters update dengan flag --clear-fleet-project, bukan perintah gcloud container fleet memberships unregister. Untuk mengetahui informasi selengkapnya, lihat Membatalkan pendaftaran cluster.

Langkah berikutnya