Halaman ini diterjemahkan oleh Cloud Translation API.

Tutorial: Mengamankan GKE Enterprise

GKE Enterprise menyediakan platform yang konsisten untuk membangun dan memberikan layanan yang aman, dengan fitur keamanan bawaan di setiap tingkat yang bekerja secara terpisah dan bersama-sama untuk memberikan pertahanan mendalam terhadap masalah keamanan. Tutorial ini memperkenalkan beberapa fitur keamanan canggih GKE Enterprise menggunakan Deployment Contoh Anthos di Google Cloud. Anthos Sample Deployment men-deploy lingkungan langsung GKE Enterprise yang sebenarnya dengan cluster GKE, service mesh, dan aplikasi Bank of GKE Enterprise dengan beberapa microservice.

Tujuan

Dalam tutorial ini, Anda akan diperkenalkan dengan beberapa fitur keamanan GKE Enterprise melalui tugas-tugas berikut:

Terapkan TLS timbal balik (mTLS) di mesh layanan Anda menggunakan Config Sync untuk memastikan komunikasi yang aman end-to-end.
Siapkan pagar pengaman keamanan yang memastikan bahwa pod dengan container istimewa tidak secara tidak sengaja di-deploy menggunakan Pengontrol Kebijakan.

Biaya

Men-deploy aplikasi Bank of Anthos akan menimbulkan biaya bayar sesuai penggunaan untuk GKE Enterprise di Google Cloud seperti yang tercantum di halaman Harga kami, kecuali jika Anda telah membeli langganan.

Anda juga bertanggung jawab atas biaya Google Cloud lainnya yang dikeluarkan saat menjalankan aplikasi Bank of Anthos, seperti biaya untuk VM Compute Engine dan load balancer.

Sebaiknya lakukan pembersihan setelah menyelesaikan tutorial atau menjelajahi deployment untuk menghindari biaya lebih lanjut.

Sebelum memulai

Tutorial ini adalah lanjutan dari tutorial Explore Anthos. Sebelum memulai tutorial ini, ikuti petunjuk di halaman tersebut untuk menyiapkan project dan menginstal Anthos Sample Deployment.

Menyiapkan lingkungan Cloud Shell

Dalam tutorial ini, Anda akan menggunakan command line dan editor Cloud Shell untuk membuat perubahan pada konfigurasi cluster.

Untuk melakukan inisialisasi lingkungan shell untuk tutorial, Anthos Sample Deployment menyediakan skrip yang melakukan hal berikut:

Menginstal alat command line yang belum ada untuk bekerja secara interaktif dengan dan memverifikasi perubahan pada deployment:
Menetapkan konteks Kubernetes untuk anthos-sample-cluster1
Meng-clone repositori yang digunakan Config Sync untuk menyinkronkan perubahan konfigurasi ke cluster Anda. Perubahan yang Anda lakukan dan kirim ke repositori upstream disinkronkan ke infrastruktur Anda oleh Config Sync. Ini adalah praktik terbaik yang direkomendasikan untuk menerapkan perubahan pada infrastruktur Anda.

Untuk menyiapkan lingkungan Anda:

Pastikan Anda memiliki sesi Cloud Shell yang aktif. Anda dapat meluncurkan Cloud Shell dengan mengklik Activate Cloud Shell dari Google Cloud konsol di project tutorial Anda.
Buat direktori untuk digunakan:
```
mkdir tutorial
cd tutorial
```

Download skrip inisialisasi:

curl -sLO https://github.com/GoogleCloudPlatform/anthos-sample-deployment/releases/latest/download/init-anthos-sample-deployment.env

Lakukan inisialisasi skrip ke lingkungan Cloud Shell Anda:

source init-anthos-sample-deployment.env

Output:

/google/google-cloud-sdk/bin/gcloud
/google/google-cloud-sdk/bin/kubectl
Your active configuration is: [cloudshell-13605]
export PROJECT as anthos-launch-demo-1
export KUBECONFIG as ~/.kube/anthos-launch-demo-1.anthos-trial-gcp.config
Fetching cluster endpoint and auth data.
kubeconfig entry generated for anthos-sample-cluster1.
Copying gs://config-management-release/released/latest/linux_amd64/nomos...
\ [1 files][ 40.9 MiB/ 40.9 MiB]
Operation completed over 1 objects/40.9 MiB.
Installed nomos into ~/bin.
Cloned ACM config repo: ./anthos-sample-deployment-config-repo

Ubah direktori ke repositori konfigurasi dan gunakan sebagai direktori kerja untuk bagian tutorial ini selanjutnya:
```
cd anthos-sample-deployment-config-repo
```

Menerapkan mTLS di mesh layanan Anda

Untuk mengantisipasi ekspansi global, CIO Anda telah mewajibkan semua data pengguna dienkripsi dalam pengiriman untuk mengamankan informasi sensitif agar mematuhi hukum privasi dan enkripsi data regional.

Jadi, apakah semua traffic Anda saat ini aman?

Buka halaman Cloud Service Mesh di project tempat Anda men-deploy Anthos Sample Deployment:

Buka halaman Cloud Service Mesh
Klik transactionhistory dalam daftar layanan. Seperti yang Anda lihat di Mempelajari GKE Enterprise, halaman detail layanan menampilkan semua telemetri yang tersedia untuk layanan ini.
Di halaman transactionhistory, pada menu Navigation, pilih Connected Services. Di sini, Anda dapat melihat koneksi Masuk dan Keluar untuk layanan. Ikon gembok yang tidak terkunci menunjukkan bahwa beberapa traffic telah diamati di port ini yang tidak menggunakan TLS timbal balik (mTLS).

mTLS adalah protokol keamanan yang memastikan bahwa traffic aman dan tepercaya di kedua arah antara dua layanan. Setiap layanan hanya menerima traffic terenkripsi dari layanan terautentikasi. Seperti yang dapat Anda lihat, Cloud Service Mesh dengan jelas menunjukkan bahwa Anda memiliki traffic yang tidak dienkripsi di mesh Anda. Warna yang berbeda digunakan di Cloud Service Mesh untuk menunjukkan apakah traffic yang tidak dienkripsi memiliki campuran plaintext dan mTLS (oranye) atau hanya plaintext (merah).

Dengan GKE Enterprise, Anda hanya perlu melakukan beberapa langkah untuk mematuhi peraturan. Daripada membuat perubahan di tingkat kode sumber, membangun kembali, dan men-deploy ulang aplikasi untuk mengatasi situasi ini, Anda dapat menerapkan kebijakan enkripsi baru secara deklaratif melalui konfigurasi menggunakan Config Sync untuk men-deploy konfigurasi baru secara otomatis dari repositori Git pusat.

Di bagian ini, Anda akan melakukan hal berikut:

Sesuaikan konfigurasi kebijakan di repositori Git Anda untuk memastikan bahwa layanan menggunakan komunikasi terenkripsi melalui mTLS.
Mengandalkan Config Sync untuk otomatis mengambil perubahan kebijakan dari repositori dan menyesuaikan kebijakan Cloud Service Mesh.
Pastikan perubahan kebijakan terjadi pada cluster Anda yang dikonfigurasi untuk disinkronkan dengan repositori.

Mengonfirmasi penyiapan Config Sync

Perintah nomos adalah alat command line yang memungkinkan Anda berinteraksi dengan Operator Pengelolaan Konfigurasi dan melakukan tugas Config Sync berguna lainnya dari mesin lokal atau Cloud Shell. Untuk memverifikasi bahwa Config Sync telah diinstal dan dikonfigurasi dengan benar di cluster Anda, jalankan nomos status:
```
nomos status
```
Output:
```
Connecting to clusters...
Current   Context                  Sync Status  Last Synced Token   Sync Branch   Resource Status
-------   -------                  -----------  -----------------   -----------   ---------------
*         anthos-sample-cluster1   SYNCED       abef0b01            master        Healthy
```
Output mengonfirmasi bahwa Config Sync dikonfigurasi untuk menyinkronkan cluster Anda ke cabang utama repositori konfigurasi Anda. Tanda bintang di kolom pertama menunjukkan bahwa konteks saat ini ditetapkan ke anthos-sample-cluster1. Jika Anda tidak melihatnya, alihkan konteks saat ini ke anthos-sample-cluster1:
```
kubectl config use-context anthos-sample-cluster1
```
Output:
```
Switched to context "anthos-sample-cluster1".
```

Pastikan Anda berada di cabang master:

git checkout master

Output:

Already on 'master'
Your branch is up to date with 'origin/master'.

Verifikasi repositori konfigurasi upstream Anda:

git remote -v

Output:

origin  https://source.developers.google.com/.../anthos-sample-deployment-config-repo (fetch)
origin  https://source.developers.google.com/.../anthos-sample-deployment-config-repo (push)

Pastikan Anda masih berada di direktori anthos-sample-deployment-config-repo, dan jalankan perintah berikut untuk memeriksa penyiapan git Anda. Fungsi helper ini disertakan ke lingkungan Anda oleh skrip inisialisasi, dan menjalankan perintah git config untuk memeriksa nilai user.email dan user.name yang ada di konfigurasi git Anda. Jika nilai ini tidak dikonfigurasi, fungsi akan menetapkan nilai default di tingkat repositori berdasarkan akun Google Cloud yang aktif saat ini.
```
init_git
```
Output (contoh):
```
Configured local git user.email to user@example.com
Configured local git user.name to user
```

Sekarang Anda siap untuk melakukan perubahan kebijakan ke repositori Anda. Saat Anda mengirim commit ini ke repositori upstream (origin), Config Sync memastikan bahwa perubahan ini diterapkan ke cluster yang telah Anda konfigurasi untuk dikelola.

Memperbarui kebijakan untuk mengenkripsi semua traffic layanan

Konfigurasi untuk Cloud Service Mesh ditentukan secara deklaratif menggunakan file YAML. Untuk mengenkripsi semua traffic layanan, Anda perlu mengubah YAML yang menentukan jenis traffic yang dapat diterima layanan, dan YAML yang menentukan jenis traffic yang dikirim layanan ke tujuan tertentu.

File YAML pertama yang perlu Anda lihat adalah namespaces/istio-system/peer-authentication.yaml, yang merupakan kebijakan autentikasi tingkat mesh yang menentukan jenis traffic yang diterima semua layanan di mesh Anda secara default.
```
cat namespaces/istio-system/peer-authentication.yaml
```
Output:
```
apiVersion: "security.istio.io/v1beta1"
kind: "PeerAuthentication"
metadata:
  name: "default"
  namespace: "istio-system"
spec:
  mtls:
    mode: PERMISSIVE
```
Seperti yang dapat Anda lihat, mode mTLS PeerAuthentication adalah PERMISSIVE, yang berarti layanan menerima traffic HTTP plaintext dan mTLS.

Ubah namespaces/istio-system/peer-authentication.yaml untuk mengizinkan hanya komunikasi terenkripsi antar-layanan dengan menyetel mode mTLS ke STRICT:

cat <<EOF> namespaces/istio-system/peer-authentication.yaml
apiVersion: "security.istio.io/v1beta1"
kind: "PeerAuthentication"
metadata:
  name: "default"
  namespace: "istio-system"
spec:
  mtls:
    mode: STRICT
EOF

Selanjutnya, lihat Aturan Tujuan di namespaces/istio-system/destination-rule.yaml. Bagian ini menentukan aturan untuk mengirim traffic ke tujuan yang ditentukan, termasuk apakah traffic dienkripsi atau tidak. Perhatikan bahwa TLSmode adalah DISABLE, yang berarti traffic dikirim dalam teks biasa ke semua host yang cocok.

cat namespaces/istio-system/destination-rule.yaml

Output:

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  annotations:
    meshsecurityinsights.googleapis.com/generated: "1561996419000000000"
  name: default
  namespace: istio-system
spec:
  host: '*.local'
  trafficPolicy:
    tls:
      mode: DISABLE

Ubah namespaces/istio-system/destination-rule.yaml agar Istio menetapkan kebijakan traffic yang mengaktifkan TLS untuk semua host yang cocok di cluster dengan menggunakan TLSmode ISTIO_MUTUAL:

cat <<EOF> namespaces/istio-system/destination-rule.yaml
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  annotations:
    meshsecurityinsights.googleapis.com/generated: "1561996419000000000"
  name: default
  namespace: istio-system
spec:
  host: '*.local'
  trafficPolicy:
    tls:
      mode: ISTIO_MUTUAL
EOF

Kirim perubahan Anda ke repositori

Anda hampir siap untuk mengirimkan perubahan konfigurasi; namun, sebaiknya lakukan beberapa pemeriksaan sebelum Anda akhirnya menerapkan pembaruan.

Jalankan nomos vet untuk memastikan konfigurasi Anda valid:
```
nomos vet
```
Tidak ada output yang menunjukkan bahwa tidak ada error validasi.
Segera setelah Anda menerapkan perubahan, Config Sync akan mengambilnya dan menerapkannya ke sistem Anda. Untuk menghindari hasil yang tidak terduga, sebaiknya periksa apakah status aktif konfigurasi Anda saat ini tidak berubah sejak Anda melakukan pengeditan. Gunakan kubectl untuk memeriksa apakah destinationrule mencerminkan bahwa mTLS dinonaktifkan untuk cluster:
```
kubectl get destinationrule default -n istio-system -o yaml
```
Output:
```
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
...
spec:
  host: '*.local'
  trafficPolicy:
    tls:
      mode: DISABLE
```
Sekarang, lakukan commit dan kirim perubahan ini ke repositori upstream. Perintah berikut menggunakan fungsi helper bernama watchmtls yang dimasukkan ke dalam lingkungan Anda oleh skrip init. Fungsi bantuan ini menjalankan kombinasi nomos status dan perintah kubectl yang Anda coba sebelumnya. Aplikasi ini memantau perubahan cluster hingga Anda menekan Ctrl+C untuk keluar. Pantau tampilan hingga Anda melihat bahwa perubahan diterapkan dan disinkronkan di cluster.
```
git commit -am "enable mtls"
git push origin master && watchmtls
```
Anda juga dapat melihat perubahan yang ditampilkan di halaman Cloud Service Mesh di GKE Enterprise.

Buka halaman Cloud Service Mesh

Anda akan melihat bahwa ikon gembok merah tidak terkunci telah berubah. Ikon gembok tampak berwarna oranye (traffic campuran), bukan hijau (traffic terenkripsi sepenuhnya) karena secara default kita melihat satu jam terakhir dengan campuran mTLS dan plaintext. Jika Anda memeriksanya kembali setelah satu jam, Anda akan melihat ikon gembok hijau yang menunjukkan bahwa Anda telah berhasil mengenkripsi semua traffic layanan.

Menggunakan Pengontrol Kebijakan untuk menyiapkan pembatas

Tim keamanan Anda khawatir tentang potensi serangan root yang mungkin terjadi saat menjalankan pod dengan container istimewa (container dengan akses root). Meskipun konfigurasi saat ini tidak men-deploy container istimewa, Anda harus mewaspadai sebanyak mungkin vektor ancaman yang dapat membahayakan performa atau, lebih buruk lagi, data pelanggan.

Meskipun tim telah berupaya keras, masih ada risiko bahwa Anda dapat rentan terhadap serangan root secara tidak sengaja dari update konfigurasi mendatang melalui proses pengiriman berkelanjutan Anda. Anda memutuskan untuk menyiapkan pembatasan keamanan untuk melindungi dari bahaya ini.

Menerapkan perlindungan

Pembatasan adalah kontrol administratif otomatis yang dimaksudkan untuk menerapkan kebijakan yang melindungi lingkungan Anda. Pengontrol Kebijakan mencakup dukungan untuk menentukan dan menerapkan aturan kustom yang tidak dicakup oleh objek Kubernetes native. Pengontrol Kebijakan memeriksa, mengaudit, dan menerapkan pembatasan yang Anda terapkan yang sesuai dengan persyaratan keamanan, kepatuhan terhadap peraturan, dan tata kelola unik organisasi Anda.

Menggunakan Pengontrol Kebijakan

Pengontrol Kebijakan dibangun di mesin kebijakan open source yang disebut Gatekeeper yang digunakan untuk menerapkan kebijakan setiap kali resource di cluster dibuat, diupdate, atau dihapus. Kebijakan ini ditentukan dengan menggunakan batasan dari template Pengontrol Kebijakan library atau dari template batasan Gatekeeper lainnya.

Anthos Sample Deployment di Google Cloud sudah memiliki Policy Controller yang terinstal dan juga mengaktifkan template library Policy Controller. Anda dapat memanfaatkan hal ini saat menerapkan pembatasan dengan menggunakan batasan yang ada untuk container istimewa dari library.

Menerapkan batasan kebijakan untuk container dengan hak istimewa

Untuk mengatasi kekhawatiran tim keamanan Anda, Anda menerapkan batasan K8sPSPPrivilegedContainer. Batasan ini menolak pod agar tidak berjalan dengan container istimewa.

Dengan menggunakan terminal Cloud Shell, buat file constraint.yaml baru dengan teks dari batasan library, sebagai berikut:

cat <<EOF> ~/tutorial/anthos-sample-deployment-config-repo/cluster/constraint.yaml
apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sPSPPrivilegedContainer
metadata:
  name: psp-privileged-container
spec:
  match:
    kinds:
      - apiGroups: [""]
        kinds: ["Pod"]
    excludedNamespaces: ["kube-system"]
EOF

Gunakan nomos vet untuk memverifikasi bahwa konfigurasi yang diperbarui valid sebelum Anda menerapkannya.
```
nomos vet
```
Perintah akan ditampilkan tanpa pemberitahuan selama tidak ada error.

Lakukan commit dan kirim perubahan untuk menerapkan kebijakan. Anda dapat menggunakan nomos status dengan perintah watch untuk mengonfirmasi bahwa perubahan diterapkan ke cluster Anda. Tekan Ctrl+C untuk keluar dari perintah smartwatch setelah selesai.

git add .
git commit -m "add policy constraint for privileged containers"
git push && watch nomos status

Output:

Connecting to clusters...
Current   Context                  Sync Status  Last Synced Token   Sync Branch   Resource Status
-------   -------                  -----------  -----------------   -----------   ---------------
*         anthos-sample-cluster1   SYNCED       f2898e92            master        Healthy

Menguji kebijakan Anda

Setelah menerapkan kebijakan, Anda dapat mengujinya dengan mencoba menjalankan pod dengan penampung yang memiliki hak istimewa.

Di terminal Cloud Shell, gunakan perintah berikut untuk membuat file baru di direktori tutorial, nginx-privileged.yaml, dengan konten dari spesifikasi contoh ini:

cat <<EOF> ~/tutorial/nginx-privileged.yaml
apiVersion: v1
kind: Pod
metadata:
  name: nginx-privileged-disallowed
  labels:
    app: nginx-privileged
spec:
  containers:
  - name: nginx
    image: nginx
    securityContext:
      privileged: true
EOF

Coba luncurkan pod dengan kubectl apply.

kubectl apply -f ~/tutorial/nginx-privileged.yaml

Output:

Error from server ([denied by psp-privileged-container] Privileged container is not allowed: nginx, securityContext: {"privileged": true}): error when creating "~/nginx-privileged.yaml": admission webhook "validation.gatekeeper.sh" denied the request: [denied by psp-privileged-container] Privileged container is not allowed: nginx, security
Context: {"privileged": true}

Error ini menunjukkan bahwa pengontrol penerimaan Gatekeeper yang memantau lingkungan Kubernetes Anda menerapkan kebijakan baru Anda. Hal ini mencegah eksekusi pod karena adanya container dengan hak istimewa dalam spesifikasi pod.

Konsep kebijakan yang dikontrol versi yang dapat Anda terapkan untuk menyiapkan batas pengamanan dengan Pengontrol Kebijakan sangat efektif karena menstandardisasi, menyatukan, dan memusatkan tata kelola cluster Anda, serta menerapkan kebijakan Anda melalui pemantauan aktif lingkungan Anda setelah deployment.

Anda dapat menemukan banyak jenis kebijakan lain untuk digunakan sebagai pembatas bagi lingkungan Anda di repositori Gatekeeper.

Mempelajari deployment lebih lanjut

Meskipun tutorial ini telah menunjukkan cara menggunakan beberapa fitur keamanan GKE Enterprise, masih banyak hal yang dapat dilihat dan dilakukan di GKE Enterprise dengan deployment kita. Jangan ragu untuk mencoba tutorial lain atau terus menjelajahi Deployment Sampel Anthos sendiri sebelum mengikuti petunjuk penonaktifan di bagian berikutnya. Google Cloud

Pembersihan

Setelah selesai menjelajahi aplikasi Bank of Anthos, Anda dapat membersihkan resource yang dibuat di Google Cloud agar tidak menggunakan kuota dan Anda tidak ditagih untuk resource tersebut di masa mendatang.

Opsi 1. Anda dapat menghapus project. Namun, jika ingin mempertahankan project, Anda dapat menggunakan Opsi 2 untuk menghapus deployment.
Opsi 2. Jika ingin mempertahankan project saat ini, Anda dapat menggunakan terraform destroy untuk menghapus aplikasi dan cluster contoh.

Menghapus project (opsi 1)

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

Perhatian: Menghapus project memiliki efek berikut:

Semua hal dalam project akan dihapus. Jika menggunakan project yang sudah ada untuk tugas dalam dokumen ini, saat Anda menghapusnya, pekerjaan lain yang telah Anda lakukan dalam project tersebut juga akan terhapus.
Project ID kustom hilang. Saat membuat project ini, Anda mungkin telah membuat project ID kustom yang ingin digunakan di masa mendatang. Untuk mempertahankan URL yang menggunakan project ID, seperti URL appspot.com, hapus resource yang dipilih di dalam project, bukan menghapus seluruh project.

Jika Anda berencana mempelajari beberapa arsitektur, tutorial atau panduan memulai, dengan menggunakan kembali project dapat membantu Anda agar tidak melampaui batas kuota project.

In the Google Cloud console, go to the Manage resources page.
Go to Manage resources
In the project list, select the project that you want to delete, and then click Delete.
In the dialog, type the project ID, and then click Shut down to delete the project.

Menghapus deployment (opsi 2)

Pendekatan ini akan menghapus aplikasi Bank of Anthos dan cluster, tetapi tidak menghapus project. Jalankan perintah berikut di Cloud Shell:

Ubah ke direktori yang menghosting skrip penginstalan:
```
cd bank-of-anthos/iac/tf-anthos-gke
```
Hapus contoh dan cluster:
```
terraform destroy
```
Masukkan project ID saat diminta.

Jika Anda berencana untuk men-deploy ulang, verifikasi bahwa semua persyaratan telah dipenuhi seperti yang dijelaskan di bagian Sebelum memulai.

Langkah berikutnya

Ada banyak hal lain yang dapat dijelajahi dalam dokumentasi GKE Enterprise kami.

Mencoba tutorial lainnya

Pelajari pengelolaan layanan dengan Deployment Contoh Anthos di Mengelola layanan dengan GKE Enterprise.
Pelajari arsitektur referensi, diagram, dan praktik terbaik tentang Google Cloud. Lihat Cloud Architecture Center kami.

Pelajari lebih lanjut GKE Enterprise

Pelajari lebih lanjut GKE Enterprise dalam ringkasan teknis kami.
Cari tahu cara menyiapkan GKE Enterprise di lingkungan produksi yang sebenarnya dalam panduan penyiapan kami.
Cari tahu cara mendapatkan hasil yang maksimal dengan Cloud Service Mesh di dokumentasi Cloud Service Mesh.
Cari tahu lebih lanjut Policy Controller dalam panduan Policy Controller
Cari tahu lebih lanjut konfigurasi dan pengelolaan kebijakan deklaratif dan terpusat dalam dokumentasi Config Sync dan dokumentasi Policy Controller

Tutorial: Mengamankan GKE Enterprise Tetap teratur dengan koleksi Simpan dan kategorikan konten berdasarkan preferensi Anda.

Tujuan

Biaya

Sebelum memulai

Menyiapkan lingkungan Cloud Shell

Menerapkan mTLS di mesh layanan Anda

Mengonfirmasi penyiapan Config Sync

Memperbarui kebijakan untuk mengenkripsi semua traffic layanan

Kirim perubahan Anda ke repositori

Menggunakan Pengontrol Kebijakan untuk menyiapkan pembatas

Menerapkan perlindungan

Menggunakan Pengontrol Kebijakan

Menerapkan batasan kebijakan untuk container dengan hak istimewa

Menguji kebijakan Anda

Mempelajari deployment lebih lanjut

Pembersihan

Menghapus project (opsi 1)

Menghapus deployment (opsi 2)

Langkah berikutnya

Mencoba tutorial lainnya

Pelajari lebih lanjut GKE Enterprise

Tutorial: Mengamankan GKE Enterprise