Praktik terbaik keamanan Anthos Service Mesh

Dokumen ini menjelaskan praktik terbaik untuk membuat dan mengatur konfigurasi Anthos Service Mesh aman yang berjalan di Google Kubernetes Engine (GKE). Panduan dalam dokumen ini lebih dari sekadar setelan yang digunakan untuk mengonfigurasi dan menginstal Anthos Service Mesh. Panduan ini juga menjelaskan cara menggunakan Anthos Service Mesh dengan produk dan fitur Google Cloud lainnya untuk memberikan perlindungan dari ancaman keamanan yang mungkin dihadapi aplikasi dalam mesh.

Audiens yang ditargetkan untuk dokumen ini mencakup administrator yang mengelola kebijakan di Anthos Service Mesh dan pengguna yang menjalankan layanan di Anthos Service Mesh. Langkah-langkah keamanan yang dijelaskan di sini juga berguna bagi organisasi yang perlu meningkatkan keamanan mesh layanan mereka untuk memenuhi persyaratan kepatuhan.

Dokumen ini disusun sebagai berikut:

• Pengantar
• Vektor serangan dan risiko keamanan
  • Vektor serangan
  • Risiko keamanan
• Tindakan untuk melindungi mesh layanan
  • Arsitektur keamanan
  • Keamanan cluster
    • Mengaktifkan TLS bersama yang ketat
    • Mengaktifkan kontrol akses
      • Menerapkan kebijakan autentikasi Anthos Service Mesh
      • Token Web JSON (JWT)
      • Autentikasi pengguna Anthos Service Mesh
      • Menerapkan kebijakan otorisasi
      • Menerapkan pertukaran token untuk mengakses layanan mesh
    • Menangani pengecualian kebijakan Anthos Service Mesh dengan aman
      • Menerapkan Kebijakan Jaringan Kubernetes
    • Akses bidang kontrol aman
    • Menerapkan batas namespace
      • Menerapkan kebijakan RBAC Kubernetes
  • Keamanan edge mesh
    • Kontrol akses masuk cluster
    • Mengatur traffic keluar cluster
    • Menggunakan cluster pribadi atau Kontrol Layanan VPC untuk mengunci akses eksternal
    • Melindungi dari serangan DDoS eksternal
  • Keamanan untuk administrasi dan otomatisasi mesh
    • Menyegmentasikan peran yang digunakan untuk operasi mesh
    • Memvalidasi konfigurasi kebijakan secara otomatis
      • Menggunakan pendekatan GitOps dengan Config Sync untuk mencegah penyimpangan konfigurasi
    • Menerapkan Logging Audit dan pemantauan
    • Melindungi certificate authority untuk sertifikat dalam cluster
  • Keamanan beban kerja
    • Membatasi hak istimewa Pod
    • Mengamankan image container
    • Memitigasi kerentanan mesh
    • Menggunakan Workload Identity untuk mengakses layanan Google dengan aman
    • Pantau status keamanan melalui dasbor keamanan dan telemetri
  • Keamanan untuk data dan kredensial pengguna yang sensitif

Pengantar

Anthos Service Mesh menyediakan fitur dan alat yang membantu Anda mengamati, mengelola, dan mengamankan layanan secara terpadu. Dibutuhkan pendekatan yang berpusat pada aplikasi dan menggunakan identitas aplikasi tepercaya, bukan pendekatan yang berfokus pada IP jaringan. Anda dapat men-deploy mesh layanan secara transparan tanpa perlu mengubah kode aplikasi yang ada. Anthos Service Mesh memberikan kontrol deklaratif atas perilaku jaringan, yang membantu memisahkan pekerjaan tim yang bertanggung jawab untuk mengirimkan dan merilis fitur aplikasi dari tanggung jawab administrator yang bertanggung jawab atas keamanan dan jaringan.

Anthos Service Mesh didasarkan pada mesh layanan Istio open source, yang memungkinkan konfigurasi dan topologi canggih. Bergantung pada struktur organisasi Anda, satu atau beberapa tim atau peran mungkin bertanggung jawab untuk menginstal dan mengonfigurasi mesh. Setelan Anthos Service Mesh default dipilih untuk melindungi aplikasi, tetapi dalam beberapa kasus, Anda mungkin memerlukan konfigurasi kustom atau memberikan pengecualian dengan mengecualikan aplikasi, port, atau alamat IP tertentu agar tidak berpartisipasi dalam mesh. Memiliki kontrol untuk mengatur konfigurasi mesh dan pengecualian keamanan sangatlah penting.

Catatan: Panduan ini melengkapi dokumentasi praktik terbaik keamanan Istio, yang mencakup rekomendasi konfigurasi mendetail untuk TLS bersama (mTLS), kebijakan otorisasi, gateway, dan konfigurasi keamanan lainnya. Anda harus memperlakukan rekomendasi ini sebagai dasar yang akan digunakan bersama dengan praktik terbaik yang dibahas dalam panduan ini. Panduan ini menjelaskan praktik terbaik tambahan untuk Anthos Service Mesh dan cara teknologi di Google Cloud dapat mengamankan semua lapisan, komponen, dan aliran informasi dalam mesh.

Vektor serangan dan risiko keamanan

Vektor serangan

Keamanan Anthos Service Mesh mengikuti model keamanan zero-trust yang mengasumsikan ancaman keamanan berasal dari dalam dan luar perimeter keamanan organisasi. Contoh jenis serangan keamanan yang dapat mengancam aplikasi dalam mesh layanan meliputi:

• Serangan pemindahan data yang tidak sah. Misalnya, serangan yang menyadap data atau kredensial sensitif dari traffic service-to-service.
• Serangan {i>man-in-the-middle<i}. Misalnya, layanan berbahaya yang menyamar sebagai layanan sah untuk mendapatkan atau memodifikasi komunikasi antarlayanan.
• Serangan eskalasi akses. Misalnya, serangan yang menggunakan akses terlarang ke hak istimewa yang ditingkatkan untuk menjalankan operasi dalam jaringan.
• Serangan {i>denial of service<i} (DoS).
• Serangan {i>botnet<i} yang mencoba menyusupi dan memanipulasi layanan untuk meluncurkan serangan pada layanan lain.

Serangan juga dapat dikategorikan berdasarkan target serangan:

• Serangan jaringan internal mesh. Serangan yang bertujuan untuk merusak, menyadap, atau memalsukan komunikasi internal service-to-service atau service-to-control-plane.
• Kontrol serangan pesawat. Serangan yang bertujuan menyebabkan bidang kontrol malfungsi (seperti serangan DoS), atau memindahkan data sensitif dari bidang kontrol secara tidak sah.
• Serangan mesh edge. Serangan yang bertujuan untuk merusak, menyadap, atau memalsukan komunikasi melalui proses masuk atau keluar mesh.
• Serangan operasi mesh. Serangan yang ditujukan pada operasi mesh. Penyerang mungkin mencoba mendapatkan hak istimewa yang ditingkatkan untuk melakukan operasi berbahaya dalam mesh, seperti mengubah kebijakan keamanan dan image workload.

Risiko keamanan

Selain serangan keamanan, mesh juga menghadapi risiko keamanan lainnya. Daftar berikut menjelaskan beberapa kemungkinan risiko keamanan:

• Perlindungan keamanan yang tidak lengkap. Mesh layanan belum dikonfigurasi dengan kebijakan autentikasi dan otorisasi untuk melindungi keamanannya. Misalnya, tidak ada kebijakan autentikasi atau otorisasi yang ditentukan untuk layanan dalam mesh.
• Pengecualian kebijakan keamanan. Untuk mengakomodasi kasus penggunaan tertentu, pengguna dapat membuat pengecualian kebijakan keamanan untuk traffic tertentu (internal atau eksternal) agar dikecualikan dari kebijakan keamanan Anthos Service Mesh. Untuk menangani kasus tersebut dengan aman, lihat bagian Menangani pengecualian kebijakan dengan aman.
• Abaikan upgrade gambar. Kerentanan dapat ditemukan untuk gambar yang digunakan dalam mesh. Anda harus terus mengupdate komponen mesh dan gambar workload dengan perbaikan kerentanan terbaru.
• Kurangnya pemeliharaan (tanpa keahlian atau sumber daya). Software mesh dan konfigurasi kebijakan memerlukan pemeliharaan rutin untuk memanfaatkan mekanisme perlindungan keamanan terbaru.
• Kurangnya visibilitas. Kesalahan konfigurasi atau konfigurasi kebijakan mesh yang tidak aman dan traffic/operasi mesh yang tidak normal tidak akan diperhatikan oleh administrator mesh.
• Penyimpangan konfigurasi. Konfigurasi kebijakan dalam mesh menyimpang dari sumber tepercaya.

Langkah-langkah untuk melindungi mesh layanan

Bagian ini menyajikan panduan pengoperasian untuk mengamankan mesh layanan.

Arsitektur keamanan

Keamanan mesh layanan bergantung pada keamanan komponen di berbagai lapisan sistem mesh dan aplikasinya. Tujuan tingkat tinggi dari postur keamanan Anthos Service Mesh yang diusulkan adalah untuk mengamankan mesh layanan melalui integrasi beberapa mekanisme keamanan di berbagai lapisan, yang secara bersama-sama mencapai keamanan sistem keseluruhan dalam model keamanan zero-trust. Diagram berikut menunjukkan postur keamanan Anthos Service Mesh yang diusulkan.

Anthos Service Mesh memberikan keamanan di berbagai lapisan, termasuk:

• Keamanan edge mesh
  • Keamanan ingress Anthos Service Mesh memberikan kontrol akses untuk traffic eksternal dan mengamankan akses eksternal ke API yang diekspos oleh layanan di mesh.
  • Keamanan traffic keluar Anthos Service Mesh mengatur traffic keluar dari workload internal.
  • Anthos Service Mesh User Auth terintegrasi dengan infrastruktur Google untuk mengautentikasi panggilan eksternal dari browser web ke layanan yang menjalankan aplikasi web.
  • Pengelolaan sertifikat gateway Anthos Service Mesh melindungi dan merotasi kunci pribadi dan sertifikat X.509 yang digunakan oleh gateway masuk dan keluar Anthos Service Mesh menggunakan Certificate Authority Service.
  • Cloud Armor dapat memberikan pertahanan dari serangan external Distributed Denial of Service (DDoS) dan Lapisan 7. Fungsi ini berfungsi sebagai Web Application Firewall (WAF) untuk melindungi mesh dari serangan jaringan. Misalnya, serangan eksekusi kode jarak jauh dan injeksi.
  • Kontrol Layanan VPC dan VPC melindungi tepi mesh melalui kontrol akses jaringan pribadi.
• Keamanan cluster
  • TLS tim Anthos Service Mesh (mTLS) menerapkan enkripsi dan autentikasi traffic workload-ke-workload.
  • CA terkelola, seperti certificate authority Anthos Service Mesh (Mesh CA) dan Certificate Authority Service, dengan aman menyediakan dan mengelola sertifikat yang digunakan oleh workload.
  • Otorisasi Anthos Service Mesh menerapkan kontrol akses untuk layanan mesh berdasarkan identitas dan atribut lainnya.
  • Dasbor keamanan GKE Enterprise menyediakan pemantauan konfigurasi kebijakan keamanan dan Kebijakan Jaringan Kubernetes untuk workload.
  • Kebijakan Jaringan Kubernetes menerapkan kontrol akses Pod berdasarkan alamat IP, label Pod, namespace, dan lain-lain.
  • Keamanan pesawat kontrol melindungi dari serangan di bidang kontrol. Perlindungan ini mencegah penyerang memodifikasi, mengeksploitasi, atau membocorkan data konfigurasi mesh dan layanan.
• Keamanan workload
  • Dapatkan info terbaru tentang rilis keamanan Anthos Service Mesh untuk memastikan biner Anthos Service Mesh yang berjalan di mesh Anda bebas dari kerentanan yang diketahui publik.
  • Workload Identity memungkinkan beban kerja mendapatkan kredensial untuk memanggil layanan Google dengan aman.
  • Cloud Key Management Service (Cloud KMS) mengamankan data atau kredensial sensitif melalui Hardware Security Modules (HSM). Misalnya, beban kerja dapat menggunakan Cloud KMS untuk menyimpan kredensial atau data sensitif lainnya. CA Service—yang digunakan untuk menerbitkan sertifikat workload mesh—mendukung kunci penandatanganan per pelanggan dan yang didukung HSM yang dikelola oleh Cloud KMS.
  • Kubernetes CNI (Container Network Interface) mencegah serangan eskalasi hak istimewa dengan menghilangkan kebutuhan akan container init Anthos Service Mesh dengan hak istimewa.
• Keamanan operator
  • Role-based access control (RBAC) Kubernetes membatasi akses ke resource Kubernetes dan membatasi izin operator untuk mengurangi serangan yang berasal dari operator berbahaya atau peniruan identitas operator.
  • GKE Enterprise Policy Controller memvalidasi dan mengaudit konfigurasi kebijakan dalam mesh untuk mencegah kesalahan konfigurasi.
  • Otorisasi Biner Google Cloud memastikan bahwa image workload di mesh adalah image yang diberi otorisasi oleh administrator.
  • Google Cloud Audit Logging mengaudit operasi mesh.

Diagram di bawah menunjukkan alur komunikasi dan konfigurasi dengan solusi keamanan terintegrasi di Anthos Service Mesh.

Keamanan cluster

Mengaktifkan TLS bersama yang ketat

Serangan man-in-the-middle (MitM) mencoba memasukkan entitas berbahaya di antara dua pihak yang berkomunikasi untuk menyadap atau memanipulasi komunikasi. Anthos Service Mesh melindungi dari serangan MitM dan pemindahan data yang tidak sah dengan menerapkan autentikasi dan enkripsi mTLS untuk semua pihak yang berkomunikasi. Mode permisif menggunakan mTLS jika kedua belah pihak mendukungnya, tetapi mengizinkan koneksi tanpa mTLS. Sebaliknya, mTLS yang ketat mengharuskan traffic dienkripsi dan diautentikasi dengan mTLS dan tidak mengizinkan traffic teks biasa.

Anthos Service Mesh memungkinkan Anda mengonfigurasi versi TLS minimum untuk koneksi TLS di antara workload Anda guna memenuhi persyaratan keamanan dan kepatuhan.

Untuk informasi selengkapnya, lihat Anthos Service Mesh melalui contoh: mTLS | Menegakkan mTLS di seluruh mesh.

Mengaktifkan kontrol akses

Kebijakan keamanan Anthos Service Mesh (seperti kebijakan autentikasi dan otorisasi) harus diterapkan pada semua traffic masuk dan keluar mesh kecuali jika ada justifikasi yang kuat untuk mengecualikan layanan atau Pod dari kebijakan keamanan Anthos Service Mesh. Dalam beberapa kasus, pengguna mungkin memiliki alasan yang sah untuk mengabaikan kebijakan keamanan Anthos Service Mesh untuk beberapa port dan rentang IP. Misalnya, untuk membuat koneksi native dengan layanan yang tidak dikelola oleh Anthos Service Mesh. Untuk mengamankan Anthos Service Mesh dalam kasus penggunaan tersebut, lihat Menangani pengecualian kebijakan Anthos Service Mesh dengan aman.

Kontrol akses layanan sangat penting untuk mencegah akses tidak sah ke layanan. Penerapan mTLS mengenkripsi dan mengautentikasi permintaan, tetapi mesh masih memerlukan kebijakan otorisasi Anthos Service Mesh untuk menerapkan kontrol akses pada layanan. Misalnya, menolak permintaan tidak sah yang berasal dari klien yang telah diautentikasi.

Kebijakan otorisasi Anthos Service Mesh menyediakan cara yang fleksibel untuk mengonfigurasi kontrol akses untuk melindungi layanan Anda dari akses yang tidak sah. Kebijakan otorisasi Anthos Service Mesh harus diterapkan berdasarkan identitas terautentikasi yang berasal dari hasil autentikasi - autentikasi berbasis mTLS atau JSON Web Token (JWT) harus digunakan bersama sebagai bagian dari kebijakan otorisasi Anthos Service Mesh.

Menerapkan kebijakan autentikasi Anthos Service Mesh

Token Web JSON (JWT)

Selain autentikasi mTLS, administrator mesh dapat mewajibkan layanan untuk mengautentikasi dan mengizinkan permintaan berdasarkan JWT. Anthos Service Mesh tidak bertindak sebagai penyedia JWT, tetapi mengautentikasi JWT berdasarkan endpoint set kunci web JSON (JWKS) yang dikonfigurasi. Autentikasi JWT dapat diterapkan ke gateway masuk untuk traffic eksternal atau ke layanan internal untuk traffic dalam mesh. Autentikasi JWT dapat digabungkan dengan autentikasi mTLS jika JWT digunakan sebagai kredensial untuk mewakili pemanggil akhir dan layanan yang diminta memerlukan bukti bahwa JWT dipanggil atas nama pemanggil akhir. Menerapkan autentikasi JWT akan melindungi dari serangan yang mengakses layanan tanpa kredensial yang valid dan atas nama pengguna akhir yang sebenarnya.

Autentikasi pengguna Anthos Service Mesh

Autentikasi pengguna Anthos Service Mesh adalah solusi terintegrasi untuk autentikasi pengguna akhir berbasis browser dan kontrol akses ke workload Anda. Alat ini mengintegrasikan mesh layanan dengan Identity Provider (IdP) yang ada untuk menerapkan alur izin dan login OpenID Connect (OIDC) berbasis web standar, serta menggunakan kebijakan otorisasi Anthos Service Mesh untuk kontrol akses.

Menerapkan kebijakan otorisasi

Kebijakan otorisasi Anthos Service Mesh mengontrol:

• Siapa atau apa yang diizinkan untuk mengakses layanan.
• Resource mana yang dapat diakses.
• Operasi mana yang dapat dilakukan pada resource yang diizinkan.

Kebijakan otorisasi adalah cara serbaguna untuk mengonfigurasi kontrol akses berdasarkan identitas aktual yang dijalankan layanan, properti lapisan aplikasi (Lapisan 7), traffic (misalnya header permintaan), dan properti lapisan jaringan (Lapisan 3 dan Lapisan 4) seperti port dan rentang IP.

Kebijakan otorisasi Anthos Service Mesh harus diterapkan berdasarkan identitas terautentikasi yang diperoleh dari hasil autentikasi untuk memberikan perlindungan dari akses tidak sah ke layanan atau data.

Secara default, akses ke layanan seharusnya ditolak kecuali jika kebijakan otorisasi ditentukan secara eksplisit untuk mengizinkan akses ke layanan tersebut. Lihat Praktik Terbaik Kebijakan Otorisasi untuk mengetahui contoh kebijakan otorisasi yang menolak permintaan akses.

Kebijakan otorisasi harus membatasi kepercayaan sebanyak mungkin. Misalnya, akses ke layanan dapat ditentukan berdasarkan setiap jalur URL yang diekspos oleh layanan sehingga hanya layanan A yang dapat mengakses jalur /admin layanan B.

Kebijakan otorisasi dapat digunakan bersama dengan Kebijakan Jaringan Kubernetes, yang hanya beroperasi pada lapisan jaringan (Lapisan 3 dan Lapisan 4) serta mengontrol akses jaringan untuk alamat IP dan port di Pod Kubernetes dan namespace Kubernetes.

Catatan: Anthos Service Mesh tidak menangani traffic non-TCP (misalnya UDP), sehingga tidak dapat dikontrol oleh kebijakan otorisasi. Administrator Mesh dapat menggunakan Kebijakan Jaringan Kubernetes guna menentukan kebijakan traffic UDP. Misalnya, jika layanan mesh tidak menggunakan UDP, administrator mesh dapat menentukan kebijakan jaringan Kubernetes untuk memblokir traffic UDP.

Menerapkan pertukaran token untuk mengakses layanan mesh

Untuk melindungi dari serangan replay token yang mencuri token dan menggunakan kembali token yang dicuri untuk mengakses layanan mesh, token dalam permintaan dari luar mesh harus ditukar dengan token internal mesh berumur singkat di edge mesh.

Permintaan dari luar mesh untuk mengakses layanan mesh harus menyertakan token, seperti JWT atau cookie, agar dapat diautentikasi dan diberi otorisasi oleh layanan mesh. Token dari luar mesh dapat bertahan lama. Untuk melindungi dari serangan replay token, token dari luar mesh harus ditukar dengan token internal mesh berumur singkat dengan cakupan terbatas saat masuk mesh. Layanan mesh mengautentikasi token internal mesh dan mengizinkan permintaan akses berdasarkan token internal mesh.

Anthos Service Mesh mendukung integrasi dengan Identity-Aware Proxy (IAP), yang menghasilkan RequestContextToken (token internal mesh berumur singkat yang ditukar dari token eksternal) yang digunakan di Anthos Service Mesh untuk otorisasi. Dengan pertukaran token, penyerang tidak dapat menggunakan token yang dicuri di mesh untuk mengakses layanan. Cakupan terbatas dan masa aktif token yang dipertukarkan sangat mengurangi kemungkinan serangan replay token.

Catatan: Pertukaran token IAP berbeda dengan autentikasi pengguna Anthos Service Mesh, di mana IAP menukar token eksternal dengan token internal jangka pendek untuk melindungi dari serangan replay token, sedangkan panggilan eksternal berbasis browser web autentikasi pengguna Anthos Service Mesh ke layanan aplikasi web.

Menangani pengecualian kebijakan Anthos Service Mesh dengan aman

Anda mungkin memiliki kasus penggunaan khusus untuk mesh layanan Anda. Misalnya, Anda mungkin perlu mengekspos porta jaringan tertentu untuk lalu lintas teks biasa. Untuk mengakomodasi skenario penggunaan tertentu, terkadang Anda mungkin perlu membuat pengecualian untuk mengizinkan traffic internal atau eksternal tertentu dikecualikan dari kebijakan keamanan Anthos Service Mesh, yang menimbulkan masalah keamanan.

Anda mungkin memiliki alasan yang sah untuk mengabaikan kebijakan keamanan Anthos Service Mesh untuk beberapa port dan rentang IP. Anda dapat menambahkan anotasi (seperti, excludeInboundPorts, excludeOutboundPorts, excludeOutboundIPRanges) ke Pod untuk mengecualikan traffic agar tidak ditangani oleh sidecar Envoy. Selain anotasi untuk mengecualikan traffic, Anda dapat mengabaikan mesh bersama-sama dengan men-deploy aplikasi dengan injeksi file bantuan dinonaktifkan. Misalnya, dengan menambahkan label sidecar.istio.io/inject="false" ke Pod aplikasi.

Mengabaikan kebijakan keamanan Anthos Service Mesh akan berdampak negatif terhadap keamanan sistem secara keseluruhan. Misalnya, jika mTLS dan kebijakan otorisasi Anthos Service Mesh diabaikan untuk port jaringan dengan cara anotasi, tidak akan ada kontrol akses untuk traffic di port dan penyadapan atau modifikasi traffic mungkin dapat dilakukan. Selain itu, mengabaikan kebijakan Anthos Service Mesh juga memengaruhi kebijakan non-keamanan, seperti kebijakan jaringan.

Saat kebijakan keamanan Anthos Service Mesh untuk port atau IP (baik secara sengaja maupun tidak), harus ada tindakan keamanan lain untuk mengamankan mesh dan memantau pengecualian keamanan, potensi celah keamanan, dan status penerapan keamanan secara keseluruhan. Untuk mengamankan mesh dalam skenario tersebut, Anda dapat:

• Pastikan traffic yang melewati sidecar telah dienkripsi secara native dan diautentikasi untuk mencegah serangan MitM.
• Terapkan Kebijakan Jaringan Kubernetes untuk membatasi konektivitas port dengan pengecualian kebijakan (misalnya, membatasi port dengan pengecualian kebijakan agar hanya mengizinkan traffic dari layanan lain di namespace yang sama) atau hanya mengizinkan traffic yang melewati port yang menerapkan kebijakan keamanan Anthos Service Mesh.
• Terapkan GKE Enterprise Policy Controller untuk memvalidasi kebijakan Anthos Service Mesh secara otomatis. Misalnya, terapkan agar file bantuan Anthos Service Mesh selalu dimasukkan ke workload.

Menerapkan Kebijakan Jaringan Kubernetes

Anthos Service Mesh dibangun berdasarkan platform yang mendasarinya (misalnya, Kubernetes). Dengan demikian, keamanan Anthos Service Mesh bergantung pada keamanan platform yang mendasarinya. Misalnya, tanpa kontrol atas siapa yang dapat mengupdate resource Kubernetes, pengguna dapat mengubah deployment Kubernetes suatu layanan untuk mengabaikan bantuan layanan.

Guna membentuk postur keamanan yang kuat untuk mesh layanan, mekanisme keamanan platform dasar harus diterapkan agar dapat bekerja sama dengan kebijakan keamanan Anthos Service Mesh.

Kebijakan Jaringan Kubernetes beroperasi di Lapisan jaringan (L3 dan L4) untuk alamat IP dan port di Pod dan namespace Kubernetes. Kebijakan jaringan Kubernetes dapat diterapkan bersama dengan kebijakan Anthos Service Mesh untuk meningkatkan keamanan mesh.

Misalnya, administrator mesh dapat mengonfigurasi Kebijakan Jaringan Kubernetes agar hanya mengizinkan traffic untuk menggunakan port dengan menerapkan kebijakan keamanan Anthos Service Mesh. Jika semua traffic harus diterapkan dengan Anthos Service Mesh mTLS, administrator dapat mengonfigurasi kebijakan jaringan Kubernetes agar hanya mengizinkan traffic di port yang dikonfigurasi dengan kebijakan mTLS Anthos Service Mesh. Administrator mesh juga dapat mengonfigurasi Kebijakan Jaringan Kubernetes untuk membatasi konektivitas port dengan pengecualian kebijakan. Misalnya, batasi konektivitas port tersebut agar berada dalam namespace.

Catatan: Batasan kebijakan jaringan Kubernetes. Meskipun Anda dapat menggunakan kebijakan jaringan Kubernetes untuk mencegah konektivitas yang tidak diinginkan dan membatasi celah keamanan dari port yang mengabaikan kebijakan keamanan, kebijakan ini bukanlah pengganti kebijakan keamanan Anthos Service Mesh karena tidak menawarkan kontrol akses berdasarkan identitas aplikasi atau properti Lapisan 7 lainnya. Selain itu, Anda hanya dapat menggunakan pemilih Pod dan namespace untuk kebijakan jaringan Kubernetes dalam satu cluster. Rentang IP pod dapat digunakan dengan mesh multi-cluster, tetapi kebijakannya akan bersifat terperinci dan mempertahankannya akan rentan terhadap error.

Akses bidang kontrol yang aman

Bidang kontrol Anthos Service Mesh mengautentikasi klien apa pun yang terhubung. Dengan demikian, hanya pemanggil dengan kredensial yang valid (sertifikat Kubernetes JWT atau X.509 yang diterbitkan oleh CA yang diizinkan) yang dapat mengakses bidang kontrol Anthos Service Mesh. TLS mengenkripsi koneksi antara workload dan bidang kontrol Anthos Service Mesh.

Selain mekanisme autentikasi, untuk Anthos Service Mesh dalam cluster, kebijakan jaringan Kubernetes dapat di-deploy untuk mengisolasi namespace sistem Anthos Service Mesh (secara default istio-sistem) dari namespace dan klien yang tidak dikelola di luar mesh sekaligus mengizinkan pesawat data untuk mengakses bidang kontrol. Aturan firewall VPC dapat mencegah traffic di luar cluster mencapai Istiod. Dengan tindakan isolasi jaringan tersebut, penyerang dari luar mesh tidak akan dapat mengakses bidang kontrol, meskipun jika penyerang memiliki kredensial yang valid. Untuk bidang kontrol terkelola, Google menangani keamanan untuk bidang kontrol, sehingga kebijakan isolasi jaringan untuk bidang kontrol tidak diperlukan.

Menerapkan batas namespace

Untuk mencegah pengguna dengan satu namespace mengakses/mengupdate resource di namespace tidak resmi:

• Menerapkan kontrol akses.
• Menerapkan Kebijakan Jaringan Kubernetes. Jika layanan dalam namespace tidak memiliki traffic di luar namespace, administrator mesh harus men-deploy kebijakan jaringan Kubernetes yang hanya mengizinkan traffic di dalam namespace: tidak boleh masuk atau keluar dari namespace.
• Menerapkan kebijakan RBAC Kubernetes.
  • Peran administrator aplikasi harus terikat dengan namespace.
  • Hanya izinkan administrator mesh memiliki ClusterRole.

Menerapkan kebijakan RBAC Kubernetes

Administrator mesh harus menerapkan kebijakan Kubernetes RBAC untuk mengontrol siapa yang diizinkan untuk mengakses dan mengupdate resource Kubernetes. Kontrol akses Kubernetes dapat memitigasi risiko keamanan di mesh. Misalnya, pengguna yang tidak memiliki izin tidak boleh diizinkan mengubah deployment Kubernetes dan mengabaikan penerapan kebijakan Anthos Service Mesh. Peran pengguna harus terikat dengan namespace sehingga pengguna tidak diizinkan untuk mengakses namespace lebih dari yang dibutuhkan. Untuk panduan terperinci dan contoh cara mengonfigurasi RBAC, lihat Mengonfigurasi kontrol akses berbasis peran. Setelah mengaktifkan Workload Identity, Anda juga dapat mengizinkan akun layanan Kubernetes untuk bertindak sebagai akun layanan IAM.

Keamanan edge mesh

Karena sebagian besar serangan juga dapat berasal dari luar cluster, sangatlah penting untuk memastikan keamanan di edge mesh.

Kontrol akses masuk cluster

Anthos Service Mesh menerima traffic eksternal yang masuk melalui gateway masuk. Layanan yang diekspos oleh gateway masuk berpotensi menghadapi serangan dari sumber eksternal. Administrator keamanan harus selalu memastikan bahwa layanan yang terekspos ke traffic eksternal melalui gateway masuk cukup aman untuk melindungi dari serangan.

Ingress harus menerapkan autentikasi dan otorisasi untuk layanan yang diekspos ke pemanggil eksternal.

• Menerapkan kebijakan keamanan masuknya cluster. Saat cluster perlu menerima traffic eksternal, administrator mesh harus menerapkan kebijakan keamanan masuk, termasuk gateway TLS Anthos Service Mesh, autentikasi, dan kebijakan otorisasi, untuk mengautentikasi permintaan eksternal dan memverifikasi bahwa permintaan eksternal diotorisasi untuk mengakses layanan yang diekspos oleh gateway masuk. Menerapkan kebijakan keamanan masuk akan melindungi dari serangan dari luar mesh yang mencoba mengakses layanan tanpa kredensial atau izin yang valid.
• Gunakan Cloud Armor agar berfungsi sebagai Firewall Aplikasi Web (WAF) guna memberikan pertahanan dari serangan berbasis web (misalnya, serangan injeksi dan serangan eksekusi jarak jauh). Untuk mengetahui informasi selengkapnya, lihat Dari tepi ke mesh: Mengekspos aplikasi mesh layanan melalui GKE Ingress.

Mengatur traffic keluar cluster

Keamanan traffic keluar cluster sangat penting untuk keamanan mesh karena kebijakan keamanan keluar dapat melindungi dari serangan pemindahan data yang tidak sah, menerapkan pemfilteran traffic keluar, dan menerapkan origin TLS untuk traffic keluar. Administrator keamanan harus mengatur dan mengaudit traffic keluar cluster.

Selain menggunakan dinding firewall VPC untuk membatasi traffic keluar, administrator mesh juga harus menerapkan kebijakan keamanan keluar untuk cluster dan mengonfigurasi traffic keluarnya agar melewati gateway keluar.

Kebijakan keluar dapat memitigasi serangan berikut:

• Serangan pemindahan data yang tidak sah.
• Pod Layanan dapat dieksploitasi oleh penyerang jika CVE mereka tidak di-patch. Pod yang disusupi dapat menjadi botnet yang dikontrol oleh penyerang untuk mengirim spam atau meluncurkan serangan DoS.

Kebijakan otorisasi yang diterapkan ke gateway keluar dapat memastikan bahwa hanya layanan resmi yang diizinkan untuk mengirim traffic ke host tertentu di luar mesh. Sementara itu, untuk traffic yang keluar dari mesh, alih-alih menangani asal TLS di file bantuan individual, TLS dapat berasal dari gateway keluar. Hal ini memberikan cara yang seragam dan lebih aman untuk memulai traffic TLS karena sertifikat klien untuk mTLS dapat diisolasi dari namespace tempat aplikasi dijalankan.

Gunakan cluster pribadi atau Kontrol Layanan VPC untuk mengunci akses eksternal

Selain menerapkan kebijakan keamanan masuk dan keluar, kunci akses eksternal menggunakan cluster pribadi atau Kontrol Layanan VPC jika memungkinkan. Meskipun kebijakan keamanan dikontrol oleh administrator keamanan mesh, konfigurasi cluster pribadi atau Kontrol Layanan VPC dapat diterapkan oleh administrator keamanan organisasi.

Kontrol Layanan VPC dapat diterapkan guna menentukan perimeter keamanan untuk layanan guna:

• Membatasi layanan agar tidak mengakses resource dari luar.
• Membatasi pihak luar agar tidak mengakses layanan di perimeter keamanan.

Kontrol Layanan VPC membantu memberikan pertahanan dari serangan pemindahan data yang tidak sah dan mencegah penyerang eksternal mengakses layanan di dalam mesh.

Melindungi dari serangan DDoS eksternal

Serangan DDoS eksternal dapat membebani gateway masuk dan layanan backend, sehingga mencegah penanganan permintaan yang sah. Cloud Armor dapat digunakan untuk memberikan pertahanan dari serangan DDoS. Cloud Armor tidak hanya melindungi dari serangan DDoS lapisan jaringan (L3 dan L4), tetapi juga serangan DDoS lapisan aplikasi (L7).

Keamanan untuk administrasi dan otomatisasi mesh

Penting untuk mempertimbangkan keamanan untuk operasi administratif dan otomatisasi apa pun yang Anda bangun di sekitar mesh, misalnya CI/CD. Praktik berikut bertujuan untuk memastikan bahwa mesh dapat dioperasikan dengan aman tanpa risiko mengekspos layanan terhadap serangan tambahan.

Menyegmentasikan peran yang digunakan untuk operasi mesh

Dengan mengikuti prinsip yang sama seperti kontrol akses berbasis peran, pengguna mesh harus diklasifikasikan sesuai dengan perannya. Setiap peran hanya boleh diberikan rangkaian hak istimewa minimum yang diperlukan oleh peran tersebut.

Misalnya, kumpulan pengguna yang melakukan deployment layanan tidak boleh memiliki hak istimewa untuk mengupdate kebijakan autentikasi dan otorisasi.

Ada berbagai kategori operator. Misalnya, operator cluster dan operator namespace. Penting untuk mencegah eskalasi hak istimewa dari operator, yang dapat mengakibatkan akses ilegal ke resource tidak sah.

Kebijakan Kubernetes RBAC memungkinkan administrator mesh membatasi akses resource hanya kepada pengguna yang diotorisasi.

Memvalidasi konfigurasi kebijakan secara otomatis

Operator dapat secara tidak sengaja salah mengonfigurasi kebijakan Anthos Service Mesh, yang dapat mengakibatkan insiden keamanan serius. Untuk mencegah kesalahan konfigurasi dan memvalidasi kebijakan Anthos Service Mesh secara otomatis, administrator mesh dapat menggunakan Pengontrol Kebijakan untuk menerapkan batasan pada konfigurasi kebijakan.

Agar tidak terlalu memercayai individu yang memiliki izin untuk memperbarui kebijakan keamanan Anthos Service Mesh dan mengotomatiskan validasi kebijakan Anthos Service Mesh, administrator mesh harus menerapkan batasan pada kebijakan Anthos Service Mesh menggunakan Pengontrol Kebijakan.

Pengontrol Kebijakan didasarkan pada project Gatekeeper open source dan dapat dijalankan sebagai pengontrol penerimaan Kubernetes untuk menolak penerapan resource yang tidak valid atau dalam mode audit, sehingga administrator dapat diberi tahu jika terjadi pelanggaran. Pengontrol Kebijakan dapat otomatis memvalidasi deployment resource di mesh, seperti memvalidasi bahwa anotasi pada deployment tidak mengabaikan kebijakan Anthos Service Mesh, memvalidasi bahwa kebijakan Anthos Service Mesh sesuai dengan yang diharapkan, dan memvalidasi bahwa deployment tidak menyertakan kemampuan root (seperti, NET_ADMIN dan NET_RAW).

Pengontrol Kebijakan juga dapat mengaudit resource Anthos Service Mesh yang ada terhadap batasan untuk mendeteksi kesalahan konfigurasi kebijakan.

Berikut adalah beberapa contoh Pengontrol Kebijakan GKE Enterprise yang menerapkan kebijakan keamanan:

• Mencegah Pod menjalankan container dengan hak istimewa.
• Hanya izinkan penggunaan image dari repositori tertentu untuk mencegah berjalannya image container yang tidak sah.
• Melarang penonaktifan TLS untuk semua host dan subset host di Istio DestinationRules.
• Melarang akun utama dan namespace di aturan Istio AuthorizationPolicy agar tidak memiliki awalan dari daftar tertentu.
• Melarang pembuatan resource umum yang mengekspos beban kerja ke IP eksternal.
• Mewajibkan resource Ingress hanya untuk HTTPS.
• Mewajibkan sistem file root hanya baca di penampung.

Library template batasan yang disediakan dengan Pengontrol Kebijakan berisi kumpulan template batasan yang dapat digunakan dengan paket batasan keamanan Anthos Service Mesh siap pakai untuk menerapkan praktik terbaik keamanan Anthos Service Mesh tertentu, misalnya, kebijakan autentikasi, otorisasi, dan traffic. Berikut adalah beberapa contoh batasan yang disertakan dalam paket:

• Terapkan PeerAuthentication mTLS tingkat mesh.
• Terapkan semua PeerAuthentications tidak dapat menimpa mTLS yang ketat.
• Terapkan menolak default AuthorizationPolicy level mesh.
• Terapkan pola aman AuthorizationPolicy.
• Terapkan file bantuan Anthos Service Mesh selalu dimasukkan ke workload.

Untuk menangani pengecualian dan situasi kaca pecah, administrator mesh dapat:

• Mengecualikan namespace dari penerapan webhook masuk Pengontrol Kebijakan, tetapi pelanggaran apa pun masih dilaporkan di audit.
• Tetapkan Constraint spec.enforcementAction ke dryrun. Webhook penerimaan tidak akan mencegah perubahan, tetapi pelanggaran apa pun masih dilaporkan di audit. Security Command Center dapat digunakan untuk membuat pelanggaran audit terlihat oleh tim keamanan.
• Tambahkan logika pengecualian ke Template Batasan (contoh).

Menggunakan pendekatan GitOps dengan Config Sync untuk mencegah penyimpangan konfigurasi

Penyimpangan konfigurasi terjadi saat konfigurasi kebijakan dalam mesh menyimpang dari sumber tepercayanya. Config Sync dapat digunakan untuk mencegah penyimpangan konfigurasi.

Terapkan Logging Audit dan pemantauan

Administrator mesh harus memantau hal berikut:

• Logging Audit Cloud
• Log Audit Mesh Layanan Anthos
• Log Audit Batasan kebijakan
• Sinkronisasi Konfigurasi Anthos
• Mengakses log
• Metrik tingkat layanan
• Mengakses rekaman aktivitas

Resource kemampuan observasi ini dapat digunakan untuk memverifikasi bahwa konfigurasi keamanan berfungsi seperti yang diharapkan dan memantau setiap pengecualian untuk penerapan kebijakan keamanan. Misalnya, akses yang tidak melalui file bantuan, akses yang tidak memiliki kredensial yang valid, tetapi terhubung ke layanan.

Meskipun software kemampuan observasi open source (misalnya Prometheus) dapat digunakan dengan Anthos Service Mesh, sebaiknya gunakan Kemampuan Observasi Google Cloud (sebelumnya bernama Stackdriver). Solusi kemampuan observasi bawaan untuk Google Cloud menyediakan logging, pengumpulan metrik, pemantauan, dan pemberitahuan, yang terkelola sepenuhnya dan mudah digunakan.

Melindungi certificate authority untuk sertifikat dalam cluster

Secara default, Anthos Service Mesh menggunakan certificate authority (CA) yang dikelola Google, yang disebut certificate authority Anthos Service Mesh (Mesh CA).

Jika Anda menggunakan certificate authority (CA) Istio yang tidak dikelola, yang dihosting sebagai bagian dari Istiod, kunci penandatanganan CA akan disimpan dalam rahasia Kubernetes dan dapat diakses oleh operator yang memiliki akses ke resource rahasia di namespace istio-system. Hal ini merupakan risiko karena operator mungkin dapat menggunakan kunci CA secara terpisah dari CA Istiod dan berpotensi menandatangani sertifikat beban kerja secara independen. Ada juga risiko bahwa kunci penandatanganan CA yang dikelola sendiri mungkin bocor secara tidak sengaja karena error operasional.

Untuk melindungi kunci penandatanganan CA, administrator mesh dapat mengupgrade mesh untuk menggunakan Mesh CA atau Certificate Authority Service (CA Service), yang dilindungi dan dikelola oleh Google. Dibandingkan dengan Mesh CA, CA Service mendukung kunci penandatanganan per pelanggan melalui Cloud KMS yang didukung oleh Cloud HSM. CA Service juga mendukung workload yang teregulasi, sedangkan Mesh CA tidak.

Keamanan workload

Keamanan workload melindungi dari serangan yang membahayakan Pod workload, lalu menggunakan Pod yang disusupi untuk meluncurkan serangan terhadap cluster (misalnya, serangan botnet).

Membatasi hak istimewa Pod

Pod Kubernetes dapat memiliki hak istimewa yang memengaruhi Pod lain pada node atau cluster. Penting untuk menerapkan batasan keamanan pada Pod beban kerja untuk mencegah Pod yang disusupi agar tidak meluncurkan serangan terhadap cluster.

Untuk menerapkan prinsip hak istimewa terendah bagi workload di Pod:

• Layanan yang di-deploy dalam mesh harus berjalan dengan hak istimewa sesedikit mungkin.
• Pod Kubernetes yang berjalan dalam mode hak istimewa dapat memanipulasi stack jaringan dan kemampuan kernel lainnya di host. Pengontrol Kebijakan GKE Enterprise dapat digunakan untuk mencegah Pod menjalankan container dengan hak istimewa.
• Anthos Service Mesh dapat dikonfigurasi untuk menggunakan container init guna mengonfigurasi pengalihan traffic iptables ke file bantuan. Hal ini mengharuskan pengguna yang membuat deployment workload memiliki hak istimewa untuk men-deploy container dengan kemampuan NET_ADMIN dan NET_RAW. Untuk menghindari risiko menjalankan container dengan hak istimewa yang ditingkatkan, administrator mesh dapat enable plugin Istio CNI untuk mengonfigurasi pengalihan traffic ke file bantuan.

Mengamankan image container

Penyerang dapat meluncurkan serangan dengan mengeksploitasi image container yang rentan. Administrator harus menerapkan Otorisasi Biner untuk memverifikasi integritas image container dan memastikan hanya image container tepercaya yang di-deploy di mesh.

Memitigasi kerentanan mesh

• Container Analysis. Container Analysis dapat memindai dan menampilkan kerentanan di workload GKE.
• Penanganan CVE (Kerentanan dan Eksposur Umum). Setelah kerentanan ditemukan di image container, administrator mesh harus memperbaiki kerentanan tersebut sesegera mungkin. Untuk Anthos Service Mesh terkelola dengan bidang data terkelola, Google otomatis menangani patching CVE yang memengaruhi gambar mesh.

Menggunakan Workload Identity untuk mengakses layanan Google dengan aman

Workload Identity adalah cara yang direkomendasikan bagi beban kerja mesh untuk mengakses layanan Google dengan aman. Alternatif untuk menyimpan kunci akun layanan dalam rahasia Kubernetes dan menggunakan kunci akun layanan untuk mengakses layanan Google tidak terlalu aman karena dapat menimbulkan risiko kebocoran kredensial, eskalasi akses, pengungkapan informasi, dan non-penyangkalan.

Pantau status keamanan melalui dasbor keamanan dan telemetri

Mesh layanan mungkin memiliki pengecualian keamanan dan potensi celah. Penting untuk menampilkan dan memantau status keamanan mesh, yang mencakup kebijakan keamanan yang diterapkan, pengecualian keamanan, dan potensi celah keamanan di mesh tersebut. Dasbor keamanan GKE Enterprise dan telemetri dapat digunakan untuk menampilkan dan memantau status keamanan mesh.

Telemetri memantau kondisi dan performa layanan dalam mesh, yang memungkinkan administrator mesh mengamati perilaku layanan (seperti SLO, traffic abnormal, pemadaman layanan, topologi).

Dasbor keamanan GKE Enterprise menganalisis dan memvisualisasikan kebijakan keamanan yang diterapkan pada beban kerja dalam mesh layanan, termasuk kebijakan kontrol akses (Kebijakan Jaringan Kubernetes, kebijakan Otorisasi Biner, dan kebijakan kontrol akses layanan), serta kebijakan autentikasi (mTLS).

Keamanan untuk data dan kredensial pengguna yang sensitif

Kredensial atau data pengguna yang sensitif dapat rentan terhadap serangan yang berasal dari Pod atau operasi berbahaya jika disimpan di penyimpanan persisten cluster, seperti menggunakan secret Kubernetes atau langsung di Pod. Perangkat tersebut juga rentan terhadap serangan jaringan jika ditransfer melalui jaringan untuk autentikasi ke layanan.

• Jika memungkinkan, simpan kredensial dan data pengguna yang sensitif di penyimpanan yang dilindungi, seperti Secret Manager dan Cloud KMS.
• Tentukan namespace terpisah untuk Pod Kubernetes yang mengakses data sensitif dan tentukan kebijakan Kubernetes agar tidak dapat diakses dari namespace lain. Menyegmentasikan peran yang digunakan untuk operasi dan menerapkan batas namespace.
• Terapkan pertukaran token untuk mencegah pemindahan token yang berumur panjang dan memiliki hak istimewa tinggi.

Langkah selanjutnya

• Tinjau praktik terbaik untuk menggunakan gateway keluar Anthos Service Mesh di cluster GKE
• Mengonfigurasi keamanan transport
• Memperbarui kebijakan otorisasi