Halaman ini diterjemahkan oleh Cloud Translation API.

Tutorial: Mengamankan GKE Enterprise

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

Tujuan

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

Terapkan TLS bersama (mTLS) di mesh layanan Anda menggunakan Config Sync untuk memastikan komunikasi aman menyeluruh.
Siapkan pembatasan keamanan yang memastikan bahwa pod dengan penampung dengan hak istimewa tidak di-deploy secara tidak sengaja menggunakan Pengontrol Kebijakan.

Biaya

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

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

Sebaiknya bersihkan setelah menyelesaikan tutorial atau menjelajahi deployment untuk menghindari tagihan lebih lanjut.

Sebelum memulai

Tutorial ini adalah tindak lanjut dari Tutorial Jelajahi Anthos. Sebelum memulai tutorial ini, ikuti petunjuk di halaman tersebut untuk menyiapkan project dan menginstal Deployment Contoh Anthos.

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, Deployment Contoh Anthos menyediakan skrip yang melakukan hal berikut:

Menginstal alat command line yang tidak ada untuk berinteraksi 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. Perubahan yang Anda commit dan kirim ke repositori upstream akan 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 Aktifkan Cloud Shell dari konsol Google Cloud 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

Sumberkan skrip inisialisasi 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 sisa tutorial ini:
```
cd anthos-sample-deployment-config-repo
```

Menerapkan mTLS di mesh layanan Anda

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

Jadi, apakah semua traffic Anda saat ini aman?

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

Buka halaman Cloud Service Mesh
Klik transactionhistory dalam daftar layanan. Seperti yang Anda lihat di Menjelajahi 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 traffic aman dan tepercaya di kedua arah antara dua layanan. Setiap layanan hanya menerima traffic terenkripsi dari layanan yang diautentikasi. Seperti yang dapat Anda lihat, Cloud Service Mesh dengan jelas menunjukkan bahwa Anda memiliki traffic yang tidak dienkripsi di mesh. Warna yang berbeda digunakan di Cloud Service Mesh untuk menunjukkan apakah traffic yang tidak dienkripsi memiliki campuran teks biasa dan mTLS (oranye) atau hanya teks biasa (merah).

Dengan GKE Enterprise, Anda hanya perlu beberapa langkah lagi untuk mematuhi persyaratan. Daripada membuat perubahan di tingkat kode sumber dan mem-build ulang serta men-deploy ulang aplikasi untuk mengatasi situasi ini, Anda dapat menerapkan kebijakan enkripsi baru secara deklaratif melalui konfigurasi dengan 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 mewajibkan layanan tersebut menggunakan komunikasi terenkripsi melalui mTLS.
Andalkan Config Sync untuk otomatis mengambil perubahan kebijakan dari repositori dan menyesuaikan kebijakan Cloud Service Mesh.
Pastikan perubahan kebijakan terjadi di 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 lainnya yang berguna dari komputer lokal atau Cloud Shell. Untuk memverifikasi bahwa Config Sync 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 akan mengonfirmasi bahwa Config Sync dikonfigurasi untuk menyinkronkan cluster Anda ke cabang master repositori konfigurasi. 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 diambil ke dalam 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 default di tingkat repo berdasarkan akun Google Cloud yang saat ini aktif.
```
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. Saat Anda mendorong commit ini ke repositori upstream (asal), Config Sync memastikan bahwa perubahan ini diterapkan ke cluster yang telah Anda konfigurasikan 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 oleh layanan, dan YAML yang menentukan jenis traffic yang dikirim oleh 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 teks biasa dan mTLS.

Ubah namespaces/istio-system/peer-authentication.yaml untuk mengizinkan komunikasi terenkripsi hanya antarlayanan dengan menetapkan 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. Aturan ini menentukan aturan untuk mengirim traffic ke tujuan yang ditentukan, termasuk apakah traffic dienkripsi. 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

Mengirim perubahan ke repositori

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

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 live konfigurasi Anda saat ini belum berubah sejak Anda melakukan pengeditan. Gunakan kubectl untuk memeriksa apakah destinationrule menunjukkan 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, commit dan kirim perubahan ini ke repositori upstream. Perintah berikut menggunakan fungsi bantuan yang disebut watchmtls yang diambil ke dalam lingkungan Anda oleh skrip init. Fungsi bantuan ini menjalankan kombinasi nomos status dan perintah kubectl yang Anda coba sebelumnya. Alat ini memantau perubahan cluster hingga Anda menekan Ctrl+C untuk keluar. Pantau layar 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 diterapkan di halaman Cloud Service Mesh di GKE Enterprise.

Buka halaman Cloud Service Mesh

Anda akan melihat bahwa ikon gembok merah terbuka telah berubah. Ikon gembok akan berwarna oranye (traffic campuran) dan bukan hijau (traffic yang sepenuhnya dienkripsi) karena secara default kami melihat traffic selama satu jam terakhir dengan campuran mTLS dan teks biasa. Jika memeriksa kembali setelah satu jam, Anda akan melihat gembok hijau yang menunjukkan bahwa Anda telah berhasil mengenkripsi semua traffic layanan.

Menggunakan Pengontrol Kebijakan untuk menyiapkan pembatasan

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

Meskipun tim telah bekerja keras, masih ada risiko bahwa Anda dapat secara tidak sengaja rentan terhadap serangan root dari update konfigurasi mendatang melalui proses continuous delivery. Anda memutuskan untuk menyiapkan pengamanan untuk melindungi dari bahaya ini.

Menerapkan pembatasan

Pembatasan adalah kontrol administratif otomatis yang dimaksudkan untuk menerapkan kebijakan yang melindungi lingkungan Anda. Pengontrol Kebijakan menyertakan 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 peraturan, dan tata kelola unik organisasi Anda.

Menggunakan Pengontrol Kebijakan

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

Deployment Contoh Anthos di Google Cloud sudah menginstal Policy Controller dan juga mengaktifkan library template Policy Controller. Anda dapat memanfaatkannya saat menerapkan guardrail dengan menggunakan batasan yang ada untuk penampung dengan hak istimewa dari library.

Menerapkan batasan kebijakan untuk penampung dengan hak istimewa

Untuk mengatasi masalah tim keamanan, Anda menerapkan batasan K8sPSPPrivilegedContainer. Batasan ini menolak pod agar tidak berjalan dengan container dengan hak 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 secara otomatis selama tidak ada error.

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

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

Di terminal Cloud Shell, gunakan perintah berikut untuk membuat file baru di direktori tutorial, nginx-privileged.yaml, dengan konten dari contoh spesifikasi 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 akses Gatekeeper yang memantau lingkungan Kubernetes Anda menerapkan kebijakan baru Anda. Hal ini mencegah eksekusi pod karena adanya penampung dengan hak istimewa dalam spesifikasi pod.

Konsep kebijakan yang dikontrol versi yang dapat Anda terapkan untuk menyiapkan pembatasan dengan Pengontrol Kebijakan adalah konsep yang efektif karena menstandarkan, menyatukan, dan memusatkan tata kelola cluster Anda, menerapkan kebijakan melalui pemantauan aktif lingkungan Anda setelah deployment.

Anda dapat menemukan banyak jenis kebijakan lain yang dapat digunakan sebagai pembatasan untuk lingkungan Anda di repositori Gatekeeper.

Mempelajari deployment lebih lanjut

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

Pembersihan

Setelah selesai menjelajahi aplikasi Bank of Anthos, Anda dapat membersihkan resource yang dibuat di Google Cloud sehingga resource tersebut 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 dan cluster Bank of Anthos, 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 sampel dan cluster:
```
terraform destroy
```
Masukkan project ID saat diminta.

Jika Anda berencana men-deploy ulang, pastikan semua persyaratan terpenuhi seperti yang dijelaskan di bagian Sebelum memulai.

Langkah selanjutnya

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 GKE Enterprise lebih lanjut

Pelajari GKE Enterprise lebih lanjut di ringkasan teknis kami.
Cari tahu cara menyiapkan GKE Enterprise di lingkungan produksi yang sebenarnya dalam panduan penyiapan kami.
Cari tahu cara melakukan lebih banyak hal dengan Cloud Service Mesh di dokumentasi Cloud Service Mesh.
Cari tahu lebih lanjut Pengontrol Kebijakan di panduan Pengontrol Kebijakan
Cari tahu lebih lanjut tentang pengelolaan kebijakan dan konfigurasi terpusat deklaratif di dokumentasi Config Sync dan dokumentasi Pengontrol Kebijakan