Tutorial: Mengamankan GKE Enterprise

GKE Enterprise menyediakan platform yang konsisten untuk membangun dan memberikan layanan yang aman, dengan fitur keamanan bawaan di setiap level yang bekerja secara terpisah dan bersama-sama untuk memberikan pertahanan mendalam terhadap masalah keamanan. Tutorial ini memperkenalkan Anda pada beberapa fitur keamanan canggih GKE Enterprise menggunakan Deployment Contoh Anthos di Google Cloud. Deployment Sampel Anthos men-deploy lingkungan interaktif GKE Enterprise yang sesungguhnya 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 yang aman secara menyeluruh.

  • Siapkan pagar pembatas keamanan yang memastikan bahwa pod dengan container dengan hak istimewa tidak di-deploy secara tidak sengaja menggunakan Pengontrol Kebijakan.

Biaya

Men-deploy aplikasi Bank of Anthos akan dikenai 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 timbul saat menjalankan aplikasi Bank of Anthos, seperti biaya untuk VM Compute Engine dan load balancer.

Sebaiknya hapus setelah menyelesaikan tutorial atau pelajari 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 Anda 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 menginisialisasi lingkungan shell tutorial, Deployment Contoh Anthos menyediakan skrip yang melakukan hal berikut:

  • Menginstal alat command line yang tidak ada untuk bekerja secara interaktif dan memverifikasi perubahan pada deployment:

  • Menetapkan konteks Kubernetes untuk anthos-sample-cluster1

  • Meng-clone repositori yang digunakan Config Sync untuk menyinkronkan perubahan konfigurasi dengan cluster Anda. 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:

  1. Pastikan Anda memiliki sesi Cloud Shell yang aktif. Anda dapat meluncurkan Cloud Shell dengan mengklik Activate Cloud Shell Tombol Activate Shell dari Konsol Google Cloud di project tutorial Anda.

  2. Buat direktori untuk bekerja di:

    mkdir tutorial
cd tutorial

  3. Download skrip inisialisasi:

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

  4. Sumber skrip inisialisasi ke dalam 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

  5. Ubah direktori ke repositori konfigurasi dan gunakan sebagai direktori kerja selama sisa tutorial ini:

    cd anthos-sample-deployment-config-repo

Menerapkan mTLS di mesh layanan Anda

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

Jadi, apakah semua traffic Anda saat ini aman?

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

    Buka halaman Cloud Service Mesh

  2. Klik histori transaksi dalam daftar layanan. Seperti yang Anda lihat di Jelajahi GKE Enterprise, halaman detail layanan menampilkan semua telemetri yang tersedia untuk layanan ini.

  3. Di halaman transactionhistory, pada menu Navigation, pilih Terhubung Services. Di sini, Anda dapat melihat koneksi Masuk dan Keluar untuk layanan. Ikon gembok tidak terkunci menunjukkan bahwa beberapa traffic telah diamati di port ini yang tidak menggunakan TLS bersama (mTLS).

mTLS adalah protokol keamanan yang memastikan traffic aman dan tepercaya di kedua arah di antara dua layanan. Setiap layanan hanya menerima traffic terenkripsi dari layanan yang diautentikasi. Seperti yang Anda lihat, Cloud Service Mesh dengan jelas menunjukkan bahwa Anda memiliki traffic yang tidak dienkripsi di mesh Anda. Warna yang berbeda-beda 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 tinggal beberapa langkah lagi untuk mematuhi kebijakan. Daripada membuat perubahan pada tingkat kode sumber serta membangun ulang dan men-deploy ulang aplikasi Anda untuk mengatasi situasi ini, Anda dapat menerapkan kebijakan enkripsi baru secara deklaratif melalui konfigurasi menggunakan Config Sync untuk secara otomatis men-deploy konfigurasi baru Anda dari repositori Git pusat.

Di bagian ini, Anda akan melakukan hal berikut:

  1. Sesuaikan konfigurasi kebijakan di repositori Git Anda untuk menerapkan layanan menggunakan komunikasi terenkripsi melalui mTLS.

  2. Mengandalkan Config Sync untuk otomatis mengambil perubahan kebijakan dari repositori dan menyesuaikan kebijakan Cloud Service Mesh.

  3. Pastikan bahwa perubahan kebijakan terjadi di cluster Anda yang dikonfigurasi untuk disinkronkan dengan repositori.

Mengonfirmasi penyiapan Config Sync

  1. Perintah nomos adalah alat command line yang dapat digunakan untuk berinteraksi dengan Operator Config Management dan melakukan tugas Config Sync yang berguna lainnya dari mesin lokal atau Cloud Shell. Untuk memastikan bahwa Config Sync diinstal dengan benar dan dikonfigurasi 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 ini mengonfirmasi bahwa Config Sync dikonfigurasi untuk menyinkronkan cluster Anda ke cabang master repositori konfigurasi Anda. Tanda bintang di kolom pertama menunjukkan bahwa konteks saat ini disetel ke anthos-sample-cluster1. Jika Anda tidak melihatnya, ganti konteks saat ini ke anthos-sample-cluster1:

    kubectl config use-context anthos-sample-cluster1

    Output:

    Switched to context "anthos-sample-cluster1".

  2. Pastikan Anda berada di cabang master:

    git checkout master

    Output:

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

  3. 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)

  4. Pastikan Anda masih berada di direktori anthos-sample-deployment-config-repo, lalu jalankan perintah berikut untuk memeriksa konfigurasi git Anda. Fungsi helper ini disumberkan ke dalam lingkungan Anda oleh skrip inisialisasi, dan menjalankan perintah git config untuk memeriksa nilai user.email dan user.name pada konfigurasi git Anda yang sudah ada. Jika nilai ini tidak dikonfigurasi, fungsi akan menetapkan setelan default di level repo 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

Anda sekarang siap untuk melakukan perubahan kebijakan pada repositori Anda. Saat Anda mengirim commit ini ke repositori upstream (asal), Config Sync akan 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, dan YAML yang menentukan jenis traffic yang dikirim oleh layanan ke tujuan tertentu.

  1. 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 secara default oleh semua layanan di mesh Anda.

    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 dan mTLS teks biasa.

  2. Ubah namespaces/istio-system/peer-authentication.yaml agar hanya mengizinkan komunikasi terenkripsi antarlayanan 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

  3. Selanjutnya, lihat Aturan Tujuan di namespaces/istio-system/destination-rule.yaml. Kolom 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

  4. 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; tetapi, sebaiknya lakukan beberapa pemeriksaan sebelum akhirnya melakukan commit untuk update Anda.

  1. Jalankan nomos vet untuk memastikan konfigurasi Anda valid:

    nomos vet

    Tidak ada output yang menunjukkan bahwa tidak ada error validasi.

  2. Segera setelah Anda mengirim perubahan, Config Sync akan mengambilnya dan menerapkannya ke sistem Anda. Untuk menghindari hasil yang tidak diharapkan, sebaiknya periksa bahwa status live konfigurasi Anda saat ini belum 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

  3. Sekarang, commit dan kirim perubahan ini ke repositori upstream. Perintah berikut menggunakan fungsi bantuan yang disebut watchmtls yang bersumber ke lingkungan Anda oleh skrip init. Fungsi bantuan ini menjalankan kombinasi nomos status dan perintah kubectl yang Anda coba sebelumnya. Fungsi ini memantau cluster untuk melihat perubahan sampai Anda menekan Ctrl+C untuk keluar. Pantau tampilan sampai Anda melihat bahwa perubahan telah diterapkan dan disinkronkan pada cluster.

    git commit -am "enable mtls"
git push origin master && watchmtls

    Anda juga dapat melihat perubahan yang dilakukan pada halaman Cloud Service Mesh di GKE Enterprise.

    Buka halaman Cloud Service Mesh

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

Menggunakan Pengontrol Kebijakan untuk menyiapkan pagar pembatas

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

Terlepas dari kerja keras tim, masih ada risiko bahwa Anda dapat rentan terhadap serangan root secara tidak sengaja dari update konfigurasi mendatang melalui proses continuous delivery. Anda memutuskan untuk menyiapkan pagar pembatas keamanan untuk melindungi dari bahaya ini.

Menerapkan pembatas

Pagar 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 tercakup oleh objek Kubernetes native. Pengontrol Kebijakan memeriksa, mengaudit, dan menerapkan batasan 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, diperbarui, atau dihapus. Kebijakan ini ditentukan menggunakan batasan dari library template Pengontrol Kebijakan atau dari template batasan Gatekeeper lainnya.

Deployment Contoh Anthos di Google Cloud telah menginstal Pengontrol Kebijakan dan juga mengaktifkan library template Pengontrol Kebijakan. Anda dapat memanfaatkan hal ini saat menerapkan batasan menggunakan batasan yang ada untuk container 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 dijalankan dengan container dengan hak istimewa.

  1. 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

  2. Gunakan nomos vet untuk memverifikasi bahwa konfigurasi yang diperbarui valid sebelum Anda menerapkannya.

    nomos vet

    Perintah tersebut akan kembali secara otomatis selama tidak ada error.

  3. Commit dan kirim perubahan untuk menerapkan kebijakan. Anda dapat menggunakan nomos status dengan perintah watch untuk mengonfirmasi bahwa perubahan telah diterapkan pada 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 container dengan hak istimewa.

  1. 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

  2. Mencoba meluncurkan 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. Pod tersebut mencegah eksekusi pod karena adanya container dengan hak istimewa dalam spesifikasi pod.

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

Anda dapat menemukan berbagai jenis kebijakan lainnya untuk digunakan sebagai pagar 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 lain yang dapat dilihat dan dilakukan di GKE Enterprise dengan deployment kami. Jangan ragu untuk mencoba tutorial lain atau melanjutkan sendiri mempelajari Deployment Contoh Anthos di Google Cloud, sebelum mengikuti petunjuk pembersihan di bagian berikutnya.

Pembersihan

Setelah selesai menjelajahi aplikasi Bank of Anthos, Anda dapat membersihkan resource yang dibuat di Google Cloud agar tidak menghabiskan kuota dan Anda tidak akan dikenai biayanya di masa mendatang.

  • Opsi 1. Anda dapat menghapus project. Namun, jika ingin mempertahankan project ini, Anda dapat menggunakan Opsi 2 untuk menghapus deployment.

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

Menghapus project (opsi 1)

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

  1. Di konsol Google Cloud, buka halaman Manage resource.

    Buka Manage resource

  2. Pada daftar project, pilih project yang ingin Anda hapus, lalu klik Delete.
  3. Pada dialog, ketik project ID, lalu klik Shut down untuk menghapus 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 Anda:

  1. Ubah ke direktori yang menghosting skrip penginstalan:

    cd bank-of-anthos/iac/tf-anthos-gke

  2. Hapus sampel dan cluster:

    terraform destroy

  3. Masukkan project ID saat diminta.

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

Langkah selanjutnya

Masih banyak lagi yang dapat dijelajahi dalam dokumentasi GKE Enterprise kami.

Coba tutorial lainnya

Pelajari GKE Enterprise lebih lanjut