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 diperkenalkan dengan beberapa fitur keamanan GKE Enterprise melalui tugas berikut:

  • Terapkan TLS bersama (mTLS) di mesh layanan Anda menggunakan Config Sync untuk memastikan komunikasi end-to-end yang aman.

  • Menyiapkan pagar pembatas keamanan yang memastikan bahwa pod dengan container dengan hak istimewa tidak di-deploy secara tidak sengaja dengan 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 terhadap biaya Google Cloud lainnya yang timbul saat menjalankan aplikasi Bank of Anthos, seperti biaya untuk load balancer dan VM Compute Engine.

Sebaiknya hapus setelah menyelesaikan tutorial atau mengeksplorasi deployment untuk menghindari timbulnya biaya 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 perintah Cloud Shell baris dan editor untuk membuat perubahan pada konfigurasi cluster Anda.

Untuk menginisialisasi lingkungan shell tutorial, Deployment Contoh Anthos menyediakan skrip yang melakukan hal berikut:

  • Menginstal alat baris perintah apa pun yang hilang untuk bekerja secara interaktif dan memverifikasi perubahan pada deployment:

  • Menetapkan konteks Kubernetes untuk anthos-sample-cluster1

  • Meng-clone repositori yang digunakan Config Sync menyinkronkan perubahan konfigurasi ke cluster Anda. Perubahan yang Anda dan mengirimkan ke repositori upstream disinkronkan ke infrastruktur Anda oleh Config Sync. Ini adalah praktik terbaik yang direkomendasikan untuk menerapkan perubahan pada infrastruktur IT.

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 dalam 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 untuk 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 harus dienkripsi saat transit untuk mengamankan informasi sensitif kepatuhan terhadap 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 transactionhistory 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 Layanan Terhubung. Di sini Anda dapat melihat Masuk dan Keluar koneksi jarak jauh untuk layanan. Ikon gembok terbuka menunjukkan bahwa ada lalu lintas diamati pada porta ini yang tidak menggunakan TLS bersama (mTLS).

mTLS adalah protokol keamanan yang memastikan bahwa lalu lintas aman dan terpercaya di kedua arah antara dua layanan IT perusahaan mereka. 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. Berbeda warna 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 dapat kepatuhan. Daripada membuat perubahan pada level kode sumber lalu membangun ulang dan men-deploy ulang aplikasi Anda untuk mengatasi situasi ini, Anda dapat menerapkan kebijakan enkripsi secara deklaratif melalui konfigurasi menggunakan Sinkronisasi Konfigurasi untuk men-deploy konfigurasi baru Anda secara otomatis dari repositori Git pusat.

Di bagian ini, Anda akan melakukan hal berikut:

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

  2. Mengandalkan Config Sync untuk mengambil kebijakan secara otomatis ubah dari repositori dan sesuaikan kebijakan Cloud Service Mesh.

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

Mengonfirmasi penyiapan Config Sync

  1. Perintah nomos adalah alat command line yang memungkinkan Anda berinteraksi dengan Config Management Operator dan lakukan tugas Config Sync berguna lainnya 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

    Outputnya mengonfirmasi bahwa Config Sync dikonfigurasi untuk disinkronkan cluster Anda ke cabang master repositori konfigurasi Anda. Tujuan tanda bintang di kolom pertama menunjukkan bahwa konteks saat ini diatur ke anthos-sample-cluster1. Jika Anda tidak melihatnya, alihkan ke instance konteks 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, dan jalankan perintah berikut untuk memeriksa pengaturan git Anda. Fungsi bantuan ini ditaruh ke dalam lingkungan Anda oleh skrip inisialisasi, dan menjalankan Perintah git config untuk memeriksa user.email dan konfigurasi git Anda yang ada user.name nilai. Jika nilai ini tidak dikonfigurasi, fungsi akan mengatur default di tingkat 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

Sekarang Anda siap untuk melakukan perubahan kebijakan pada repositori Anda. Saat Anda mendorong commit ini ke repositori upstream (origin), Config Sync memastikan bahwa perubahan ini diterapkan pada cluster yang Anda mengonfigurasinya 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 memodifikasi YAML yang menentukan jenis traffic yang dapat diterima layanan, 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, yaitu kebijakan otentikasi tingkat {i>mesh<i} yang menentukan jenis yang diterima secara {i>default<i} oleh semua layanan di {i>mesh<i} 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 PERMISSIVE, yang berarti bahwa layanan menerima lalu lintas HTTP dan mTLS teks biasa.

  2. Mengubah 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. Berikutnya, lihat Tujuan Aturan di namespaces/istio-system/destination-rule.yaml. Ini menentukan aturan untuk mengirim traffic ke tujuan yang ditentukan, termasuk apakah lalu lintas dienkripsi. Perhatikan bahwa TLSmode adalah DISABLE, artinya 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 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 beberapa pemeriksaan sebelum Anda akhirnya melakukan commit untuk pembaruan Anda.

  1. Jalankan nomos vet untuk memastikan konfigurasi Anda valid:

    nomos vet

    Tidak ada output yang menunjukkan bahwa tidak ada error validasi.

  2. Setelah Anda mengirim perubahan, Config Sync akan mengambilnya dan menerapkannya ke sistem Anda. Untuk menghindari hasil yang tidak diharapkan, sebaiknya memeriksa apakah status live konfigurasi Anda saat ini tidak berubah sejak Anda melakukan pengeditan. Gunakan kubectl untuk memeriksa bahwa 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

  3. Sekarang, commit dan kirim perubahan ini ke repositori upstream. Hal berikut menggunakan fungsi bantuan yang disebut watchmtls yang bersumber ke dalam dengan skrip init. Fungsi bantuan ini menjalankan kombinasi nomos status dan perintah kubectl yang Anda sudah coba sebelumnya. Menonton cluster untuk perubahan sampai Anda menekan Ctrl+C untuk keluar. Memantau hingga Anda melihat bahwa perubahan diterapkan dan disinkronkan pada gugus ini.

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

    Anda juga dapat melihat perubahan yang tercermin 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 tampak oranye (lalu lintas campuran), bukan hijau (traffic yang sepenuhnya terenkripsi) karena kita melihat secara {i>default<i} pada jam terakhir dengan campuran mTLS dan teks biasa. Jika Anda 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 {i>root<i} 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 ingin berlindung dari sebanyak mungkin vektor ancaman yang dapat menyusupi performa atau, lebih buruk lagi, data pelanggan.

Terlepas dari ketekunan tim, masih ada risiko bahwa Anda akan mendapati diri Anda rentan terhadap serangan {i>root<i} secara tidak sengaja dari pembaruan konfigurasi mendatang melalui proses continuous delivery. Anda memutuskan untuk menyiapkan keamanan pagar pembatas untuk melindungi dari bahaya ini.

Menerapkan pembatas

Pengaman adalah kontrol administratif otomatis yang dimaksudkan untuk menegakkan 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 batasan yang Anda terapkan sesuai dengan keamanan unik, kepatuhan terhadap peraturan, dan persyaratan tata kelola organisasi.

Menggunakan Pengontrol Kebijakan

Pengontrol Kebijakan dibuat berdasarkan kebijakan open source mesin bernama Gatekeeper yang digunakan untuk menegakkan kebijakan setiap kali sumber daya di cluster dibuat, diperbarui, atau dihapus. Kebijakan ini ditentukan dengan menggunakan dari template Pengontrol Kebijakan library atau dari {i>template<i} batasan Gatekeeper lainnya.

Deployment Sampel Anthos di Google Cloud telah Pengontrol Kebijakan diinstal dan juga mengaktifkan library template Pengontrol Kebijakan. Anda dapat mengambil memanfaatkan hal ini saat menerapkan batasan Anda dengan menggunakan untuk container dengan hak istimewa dari library.

Menerapkan batasan kebijakan untuk penampung dengan hak istimewa

Untuk mengatasi kekhawatiran tim keamanan Anda, 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 diterapkan pada . 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 dalam tutorial nginx-privileged.yaml, dengan isi 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}

    Kesalahan ini menunjukkan bahwa pengontrol penerimaan Gatekeeper memantau Lingkungan Kubernetes menerapkan kebijakan baru Anda. Hal ini mencegah pod karena adanya container dengan hak istimewa di pod spesifikasi pendukung.

Konsep kebijakan yang dikontrol versi yang dapat Anda terapkan untuk menyiapkan pagar pembatas dengan Pengontrol Kebijakan adalah alat yang ampuh karena menstandarkan, menyatukan, dan memusatkan tata kelola klaster Anda, dengan kebijakan Anda melalui pemantauan aktif terhadap lingkungan Anda pasca-deployment.

Anda dapat menemukan berbagai jenis kebijakan lain untuk digunakan sebagai pagar pembatas untuk lingkungan Anda di repositori Gatekeeper.

Mempelajari deployment lebih lanjut

Meskipun tutorial ini telah menunjukkan cara menggunakan beberapa fitur keamanan GKE Enterprise, ada masih banyak hal yang dapat dilihat dan dilakukan di GKE Enterprise dengan deployment kami. Jangan ragu untuk mencoba tutorial lain atau melanjutkan sendiri tentang 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 Anda buat di Google Cloud agar tidak menghabiskan kuota dan Anda tidak ditagih untuk hal tersebut di masa mendatang.

  • Opsi 1. Anda dapat menghapus project. Namun, jika Anda ingin mempertahankan proyek, 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 lebih lanjut GKE Enterprise