Praktik terbaik keamanan Cloud Service Mesh dengan Istio API

Dokumen ini menjelaskan praktik terbaik untuk membuat dan mengatur konfigurasi Cloud Service Mesh yang aman yang berjalan di Google Kubernetes Engine (GKE). Panduan dalam dokumen ini tidak hanya membahas setelan yang digunakan untuk mengonfigurasi dan menyediakan Cloud Service Mesh, tetapi juga menjelaskan cara menggunakan Cloud Service Mesh dengan produk dan fitur lain untuk melindungi dari ancaman keamanan yang mungkin dihadapi aplikasi dalam mesh. Google Cloud

Audiens yang dituju untuk dokumen ini mencakup administrator yang mengelola kebijakan di Cloud Service Mesh dan pemilik layanan yang menjalankan layanan di Cloud Service Mesh. Tindakan 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

Cloud Service Mesh menyediakan fitur dan alat yang membantu Anda mengamati, mengelola, dan mengamankan layanan secara terpadu. Pendekatan ini berfokus 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. Cloud 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.

Cloud Service Mesh didasarkan pada mesh layanan Istio open source, yang memungkinkan konfigurasi dan topologi yang canggih. Bergantung pada struktur organisasi Anda, satu atau beberapa tim atau peran mungkin bertanggung jawab untuk menginstal dan mengonfigurasi mesh. Setelan Cloud Service Mesh default dipilih untuk melindungi aplikasi, tetapi dalam beberapa kasus, Anda mungkin memerlukan konfigurasi kustom atau Anda mungkin perlu 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.

Dokumen ini melengkapi dokumentasi praktik terbaik keamanan Istio, yang mencakup rekomendasi konfigurasi mendetail untuk TLS bersama (mTLS), kebijakan otorisasi, gateway, dan konfigurasi keamanan lainnya. Anggap rekomendasi ini sebagai dasar yang akan digunakan bersama dengan praktik terbaik yang dibahas dalam dokumen ini. Dokumen ini menjelaskan praktik terbaik tambahan untuk Cloud Service Mesh dan cara teknologi di Google Cloud dapat mengamankan semua lapisan, komponen, dan alur informasi dalam mesh.

Vektor serangan dan risiko keamanan

Vektor serangan

Keamanan Cloud Service Mesh mengikuti model keamanan zero-trust, yang mengasumsikan bahwa ancaman keamanan berasal dari dalam dan luar perimeter keamanan organisasi. Berikut adalah contoh jenis serangan keamanan yang dapat mengancam aplikasi dalam mesh layanan:

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

Serangan juga dapat dikategorikan berdasarkan target serangan:

  • Serangan jaringan internal Mesh. Serangan yang ditujukan untuk merusak, menguping, atau memalsukan komunikasi internal layanan ke layanan atau layanan ke panel kontrol mesh.
  • Serangan bidang kontrol. Serangan yang bertujuan menyebabkan bidang kontrol berfungsi tidak semestinya (seperti serangan DoS), atau mencuri data sensitif dari bidang kontrol.
  • Serangan tepi mesh. Serangan yang bertujuan untuk merusak, menyadap, atau memalsukan komunikasi di ingress atau egress mesh.
  • Serangan operasi Mesh. Serangan yang ditujukan pada operasi mesh. Penyerang dapat mencoba mendapatkan hak istimewa yang ditingkatkan untuk melakukan operasi berbahaya di mesh, seperti mengubah kebijakan keamanan dan image workload-nya.

Risiko keamanan

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

  • Perlindungan keamanan tidak lengkap. Service mesh 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 Cloud Service Mesh. Untuk menangani kasus tersebut dengan aman, lihat bagian Menangani pengecualian terhadap kebijakan dengan aman dalam dokumen ini.
  • Mengabaikan upgrade gambar. Kerentanan mungkin ditemukan untuk gambar yang digunakan dalam mesh. Anda harus terus memperbarui komponen mesh dan image workload dengan perbaikan kerentanan terbaru.
  • Kurangnya pemeliharaan (tidak ada keahlian atau sumber daya). Konfigurasi kebijakan dan software mesh memerlukan pemeliharaan rutin untuk memanfaatkan mekanisme perlindungan keamanan terbaru.
  • Kurangnya visibilitas. Konfigurasi yang salah atau tidak aman pada kebijakan mesh dan traffic atau operasi mesh yang tidak normal tidak diketahui oleh administrator mesh.
  • Penyimpangan konfigurasi. Konfigurasi kebijakan dalam mesh berbeda dari sumber tepercaya.

Tindakan 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. Maksud umum postur keamanan Cloud Service Mesh yang diusulkan adalah mengamankan mesh layanan dengan mengintegrasikan beberapa mekanisme keamanan di berbagai lapisan, yang secara bersama-sama mencapai keamanan sistem secara keseluruhan dalam model keamanan zero trust. Diagram berikut menunjukkan postur keamanan Cloud Service Mesh yang diusulkan.

postur keamanan Cloud Service Mesh

Cloud Service Mesh memberikan keamanan di beberapa lapisan, termasuk:

  • Keamanan edge mesh
    • Keamanan ingress Cloud Service Mesh menyediakan kontrol akses untuk traffic eksternal dan mengamankan akses eksternal ke API yang diekspos oleh layanan di mesh.
    • Keamanan keluar Cloud Service Mesh mengatur traffic keluar dari workload internal.
    • Autentikasi pengguna Cloud Service Mesh terintegrasi dengan infrastruktur Google untuk mengautentikasi panggilan eksternal dari browser web ke layanan yang menjalankan aplikasi web.
    • Pengelolaan sertifikat gateway Cloud Service Mesh melindungi dan merotasi kunci pribadi dan sertifikat X.509 yang digunakan oleh gateway ingress dan egress Cloud Service Mesh menggunakan Certificate Authority Service.
    • VPC dan Kontrol Layanan VPC melindungi edge mesh melalui kontrol akses jaringan pribadi.
  • Keamanan cluster
    • TLS timbal balik (mTLS) Cloud Service Mesh menerapkan enkripsi dan autentikasi traffic workload-ke-workload.
    • Certificate Authority Cloud Service Mesh menyediakan dan mengelola sertifikat yang digunakan oleh workload dengan aman.
    • Otorisasi Cloud Service Mesh menerapkan kontrol akses untuk layanan mesh berdasarkan identitas dan atribut lainnya.
    • Dasbor keamanan GKE Enterprise menyediakan pemantauan konfigurasi kebijakan keamanan dan NetworkPolicy Kubernetes untuk workload.
    • Kontrol akses Pod yang diterapkan kebijakan jaringan Kubernetes berdasarkan alamat IP, label Pod, namespace, dan lainnya.
  • Keamanan workload
    • Selalu ikuti rilis keamanan Cloud Service Mesh terbaru untuk memastikan biner Cloud Service Mesh yang berjalan di mesh Anda bebas dari kerentanan yang diketahui publik.
    • Workload Identity Federation for GKE memungkinkan workload mendapatkan kredensial untuk memanggil layanan Google secara aman.
    • Cloud Key Management Service (Cloud KMS) mengamankan data atau kredensial sensitif melalui modul keamanan hardware (HSM). Misalnya, workload dapat menggunakan Cloud KMS untuk menyimpan kredensial atau data sensitif lainnya. CA Service, yang digunakan untuk menerbitkan sertifikat ke workload mesh, mendukung kunci penandatanganan per pelanggan dan yang didukung HSM yang dikelola oleh Cloud KMS.
    • Antarmuka Jaringan Kontainer (CNI) Kubernetes mencegah serangan eskalasi hak istimewa dengan menghilangkan kebutuhan akan container init Cloud Service Mesh yang memiliki hak istimewa.
  • Keamanan operator
    • Kontrol akses berbasis peran (RBAC) Kubernetes membatasi akses ke resource Kubernetes dan membatasi izin operator untuk memitigasi serangan yang berasal dari operator berbahaya atau peniruan identitas operator.
    • GKE Enterprise Policy Controller memvalidasi dan mengaudit konfigurasi kebijakan di mesh untuk mencegah kesalahan konfigurasi.
    • Google Cloud Otorisasi Biner memastikan bahwa image beban kerja dalam mesh adalah image yang diizinkan oleh administrator.
    • Cloud Audit Logs mengaudit operasi mesh.

Diagram berikut menunjukkan alur komunikasi dan konfigurasi dengan solusi keamanan terintegrasi di Cloud Service Mesh.

alur traffic keamanan

Keamanan cluster

Bagian ini menjelaskan praktik terbaik terkait keamanan cluster.

Mengaktifkan TLS bersama yang ketat

Serangan man-in-the-middle (MitM) mencoba menyisipkan entitas berbahaya di antara dua pihak yang berkomunikasi untuk menyadap atau memanipulasi komunikasi. Cloud Service Mesh memberikan pertahanan terhadap serangan MitM dan pemindahan data yang tidak sah dengan menerapkan enkripsi dan autentikasi mTLS untuk semua pihak yang berkomunikasi. Mode permisif menggunakan mTLS jika kedua sisi mendukungnya, tetapi mengizinkan koneksi tanpa mTLS. Sebaliknya, mTLS ketat mewajibkan agar traffic dienkripsi dan diautentikasi dengan mTLS serta tidak mengizinkan traffic teks biasa.

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

Untuk mengetahui informasi selengkapnya, lihat Cloud Service Mesh menurut contoh: mTLS | Menerapkan mTLS di seluruh mesh.

Mengaktifkan kontrol akses

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

Kontrol akses layanan sangat penting untuk mencegah akses tidak sah ke layanan. Penerapan mTLS mengenkripsi dan mengautentikasi permintaan, tetapi mesh tetap memerlukan kebijakan otorisasi Cloud Service Mesh untuk menerapkan kontrol akses pada layanan—misalnya, dengan menolak permintaan tidak sah yang berasal dari klien yang diautentikasi.

Kebijakan otorisasi Cloud Service Mesh menyediakan cara yang fleksibel untuk mengonfigurasi kontrol akses guna melindungi layanan Anda dari akses yang tidak sah. Kebijakan otorisasi Cloud Service Mesh akan diterapkan berdasarkan identitas yang diautentikasi yang berasal dari hasil autentikasi; autentikasi berbasis mTLS atau Token Web JSON (JWT) dapat digunakan bersama sebagai bagian dari kebijakan otorisasi Cloud Service Mesh.

Menerapkan kebijakan autentikasi Cloud Service Mesh

Saat mempertimbangkan kebijakan autentikasi Cloud Service Mesh, pertimbangkan poin-poin berikut.

Token Web JSON (JWT)

Selain autentikasi mTLS, administrator mesh dapat mewajibkan layanan untuk mengautentikasi dan mengizinkan permintaan berdasarkan JWT. Cloud 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 ingress untuk traffic eksternal atau ke layanan internal untuk traffic dalam mesh. Autentikasi JWT dapat digabungkan dengan autentikasi mTLS saat JWT digunakan sebagai kredensial untuk merepresentasikan pemanggil akhir dan layanan yang diminta memerlukan bukti bahwa layanan tersebut 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 Cloud Service Mesh

Autentikasi pengguna Cloud Service Mesh adalah solusi terintegrasi untuk autentikasi pengguna akhir berbasis browser dan kontrol akses ke beban kerja Anda. Layanan ini mengintegrasikan service mesh dengan Penyedia Identitas (IdP) yang ada untuk menerapkan alur izin dan login OpenID Connect (OIDC) berbasis web standar, serta menggunakan kebijakan otorisasi Cloud Service Mesh untuk kontrol akses.

Menerapkan kebijakan otorisasi

Kebijakan otorisasi Cloud 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 sebenarnya yang dijalankan layanan sebagai properti traffic lapisan aplikasi (lapisan 7) (misalnya, header permintaan), dan properti lapisan jaringan (lapisan 3 dan lapisan 4) seperti rentang IP dan port.

Sebaiknya kebijakan otorisasi Cloud Service Mesh diterapkan berdasarkan identitas yang diautentikasi yang berasal dari hasil autentikasi untuk melindungi dari akses tidak sah ke layanan atau data.

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

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

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

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, pastikan token dalam permintaan dari luar mesh ditukar dengan token internal mesh yang memiliki masa aktif singkat di edge mesh.

Permintaan dari luar mesh untuk mengakses layanan mesh harus menyertakan token, seperti JWT atau cookie, agar diautentikasi dan diberi otorisasi oleh layanan mesh. Token dari luar mesh mungkin memiliki masa berlaku yang lama. Untuk mempertahankan diri dari serangan replay token, tukar token dari luar mesh dengan token internal mesh jangka pendek dengan cakupan terbatas di ingress mesh. Layanan mesh mengautentikasi token internal mesh dan mengizinkan permintaan akses berdasarkan token internal mesh.

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

Menangani pengecualian kebijakan Cloud Service Mesh dengan aman

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

Anda mungkin memiliki alasan yang sah untuk melewati kebijakan keamanan Cloud Service Mesh untuk beberapa port dan rentang IP. Anda dapat menambahkan anotasi, seperti, excludeInboundPorts, excludeOutboundPorts, dan excludeOutboundIPRanges ke Pod untuk mengecualikan traffic agar tidak ditangani oleh Envoy sidecar. Selain anotasi untuk mengecualikan traffic, Anda dapat melewati mesh sepenuhnya dengan men-deploy aplikasi dengan penyisipan sidecar dinonaktifkan—misalnya, dengan menambahkan label sidecar.istio.io/inject="false" ke Pod aplikasi.

Melewati kebijakan keamanan Cloud Service Mesh akan berdampak negatif pada keamanan sistem secara keseluruhan. Misalnya, jika mTLS dan kebijakan otorisasi Cloud Service Mesh dilewati untuk port jaringan melalui anotasi, tidak ada kontrol akses untuk traffic di port tersebut, dan penyadapan atau modifikasi traffic mungkin terjadi. Selain itu, melewati kebijakan Cloud Service Mesh juga memengaruhi kebijakan non-keamanan, seperti kebijakan jaringan.

Jika kebijakan keamanan Cloud Service Mesh dilewati untuk port atau alamat IP (baik secara sengaja maupun tidak sengaja), sebaiknya Anda menerapkan langkah keamanan lain untuk mengamankan mesh dan memantau pengecualian keamanan, potensi celah keamanan, dan status penegakan keamanan secara keseluruhan. Untuk mengamankan jaringan mesh Anda dalam skenario tersebut, Anda dapat:

  • Pastikan traffic yang melewati sidecar dienkripsi dan diautentikasi secara native untuk mencegah serangan MitM.
  • Terapkan kebijakan jaringan Kubernetes untuk membatasi konektivitas port dengan pengecualian kebijakan—misalnya, batasi port dengan pengecualian kebijakan agar hanya mengizinkan traffic dari layanan lain dalam namespace yang sama—atau agar hanya mengizinkan traffic melewati port yang menerapkan kebijakan keamanan Cloud Service Mesh.

Menggunakan pendekatan GitOps dengan Config Sync untuk mencegah penyimpangan konfigurasi

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

Menerapkan Cloud Audit Logs dan pemantauan

Sebaiknya administrator mesh memantau hal berikut:

Administrator dapat menggunakan resource kemampuan pengamatan ini untuk memverifikasi bahwa konfigurasi keamanan berfungsi seperti yang diharapkan dan untuk memantau pengecualian apa pun terhadap penerapan kebijakan keamanan. Misalnya, akses yang tidak melalui sidecar, akses yang tidak memiliki kredensial yang valid tetapi mencapai layanan.

Meskipun software kemampuan observasi open source (misalnya, Prometheus) dapat digunakan dengan Cloud Service Mesh, sebaiknya gunakan Google Cloud Observability. Solusi pemantauan bawaan untuk Google Cloud ini menyediakan pencatatan log, pengumpulan metrik, pemantauan, dan pemberitahuan, yang dikelola sepenuhnya.

Keamanan workload

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

Membatasi hak istimewa Pod

Pod Kubernetes mungkin memiliki hak istimewa yang memengaruhi Pod lain di node atau cluster. Penting untuk menerapkan batasan keamanan pada Pod workload untuk mencegah Pod yang disusupi 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.
  • Anda dapat mengonfigurasi Cloud Service Mesh agar menggunakan init container untuk mengonfigurasi pengalihan traffic iptables ke sidecar. Hal ini mengharuskan pengguna membuat deployment beban kerja yang 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 mengaktifkan plugin CNI Istio untuk mengonfigurasi pengalihan traffic ke sidecar.

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

  • Artifact Analysis dapat memindai dan menampilkan kerentanan pada workload GKE.
  • Penanganan kerentanan dan eksposur umum (CVE). Setelah kerentanan ditemukan dalam image container, administrator mesh dapat memperbaiki kerentanan tersebut sesegera mungkin. Google secara otomatis menangani patch CVE yang memengaruhi image mesh.

Menggunakan Workload Identity Federation for GKE untuk mengakses layanan Google secara aman

Workload Identity Federation for GKE adalah cara yang direkomendasikan agar beban kerja mesh dapat mengakses layanan Google dengan aman. Alternatif untuk menyimpan kunci akun layanan dalam secret Kubernetes dan menggunakan kunci akun layanan untuk mengakses layanan Google tidak seaman karena risiko kebocoran kredensial, eskalasi hak istimewa, pengungkapan informasi, dan penyangkalan.

Memantau status keamanan melalui dasbor keamanan dan telemetri

Service mesh mungkin memiliki pengecualian keamanan dan potensi celah. Sangat penting untuk menampilkan dan memantau status keamanan mesh, yang mencakup kebijakan keamanan yang diterapkan, pengecualian keamanan, dan potensi celah keamanan dalam mesh. Anda dapat menggunakan dasbor keamanan GKE Enterprise dan telemetri 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 tidak normal, gangguan layanan, topologi).

Dasbor keamanan GKE Enterprise menampilkan kebijakan keamanan yang diterapkan pada workload di service mesh, termasuk kebijakan kontrol akses (Kebijakan Jaringan Kubernetes, kebijakan Otorisasi Biner, dan kebijakan kontrol akses layanan), serta kebijakan autentikasi (mTLS).

Keamanan untuk kredensial dan data pengguna yang sensitif

Jika Anda menyimpan data atau kredensial pengguna yang sensitif di penyimpanan persisten cluster, seperti secret Kubernetes atau langsung di Pod, data atau kredensial tersebut dapat rentan terhadap serangan yang berasal dari Pod atau operasi berbahaya. Data juga rentan terhadap serangan jaringan jika ditransfer melalui jaringan untuk autentikasi ke layanan.

  • Jika memungkinkan, simpan data dan kredensial 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. Segmenkan peran yang digunakan untuk operasi dan terapkan batas namespace.
  • Terapkan pertukaran token untuk mencegah eksfiltrasi token dengan hak istimewa tinggi dan masa aktif yang lama.