Cloud Service Mesh dengan praktik terbaik keamanan Istio API

Dokumen ini menjelaskan praktik terbaik untuk membangun dan mengatur keamanan Mesh Layanan Cloud konfigurasi yang berjalan di Google Kubernetes Engine (GKE). Panduan dalam dokumen ini lebih dari sekadar setelan yang digunakan untuk mengonfigurasi dan menyediakan Cloud Service Mesh dan menjelaskan cara menggunakan Cloud Service Mesh dengan produk dan fitur untuk melindungi dari ancaman keamanan yang dalam jaring.

Audiens yang dituju untuk dokumen ini termasuk administrator yang mengelola kebijakan di Mesh Layanan Cloud dan pemilik layanan yang menjalankan layanan di dan Cloud Service Mesh. Langkah-langkah keamanan yang dijelaskan di sini juga berguna bagi organisasi yang perlu meningkatkan keamanan 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 aman 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 memodifikasi mesh yang ada pada kode aplikasi Anda. Cloud Service Mesh menyediakan kontrol deklaratif 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, yang memungkinkan konfigurasi dan topologi yang canggih. Tergantung dari strukturnya, organisasi Anda, satu atau beberapa tim atau peran mungkin bertanggung jawab untuk menginstal dan mengkonfigurasi {i>mesh<i}. Mesh Layanan Cloud default setelan dipilih untuk melindungi aplikasi, tetapi dalam beberapa kasus, Anda mungkin perlu konfigurasi kustom atau Anda mungkin perlu memberikan pengecualian dengan mengecualikan aplikasi, porta, atau alamat IP agar tidak berpartisipasi dalam mesh. Memiliki kontrol dalam untuk mengatur konfigurasi {i>mesh<i} dan pengecualian keamanan adalah penting.

Dokumen ini melengkapi Dokumentasi praktik terbaik keamanan Istio, yang mencakup rekomendasi konfigurasi mendetail untuk TLS bersama (mTLS), kebijakan otorisasi, {i>gateway<i}, dan konfigurasi keamanan lainnya. Perlakukan ini rekomendasi sebagai dasar untuk digunakan bersama dengan praktik terbaik yang dibahas dalam dokumen ini. Dokumen ini menjelaskan praktik terbaik tambahan untuk Cloud Service Mesh dan bagaimana teknologi di Google Cloud dapat mengamankan semua lapisan, komponen, dan informasi mengalir dalam sebuah jala.

Vektor serangan dan risiko keamanan

Vektor serangan

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

  • Serangan pemindahan data yang tidak sah. Misalnya, serangan yang menyadap data data atau kredensial dari traffic layanan-ke-layanan.
  • Serangan {i>man-in-the-middle<i}. Misalnya, layanan berbahaya yang menyamar sebagai layanan yang sah untuk mendapatkan atau memodifikasi komunikasi antara layanan IT perusahaan mereka.
  • Serangan eskalasi akses. Misalnya, serangan yang menggunakan akses terlarang hingga hak istimewa yang lebih tinggi untuk melakukan operasi di dalam jaringan.
  • Serangan {i>denial of service<i} (DoS).
  • Serangan {i>botnet<i} yang mencoba menyusupi dan memanipulasi layanan untuk meluncurkan serangan terhadap layanan lain.

Serangan ini juga dapat dikategorikan berdasarkan target serangan:

  • Serangan jaringan internal mesh. Serangan yang ditujukan untuk menyadap, menyadap, atau melakukan spoofing terhadap service-to-service internal mesh atau service-to-control-plane komunikasi antarlayanan.
  • Serangan bidang kontrol. Serangan yang bertujuan menyebabkan bidang kontrol malfungsi (seperti serangan DoS), atau pemindahan data sensitif yang bidang kontrol.
  • Serangan {i>mesh edge<i}. Serangan yang bertujuan untuk merusak, menyadap, atau spoofing komunikasi pada traffic masuk atau keluar mesh.
  • Serangan operasi mesh. Serangan yang ditujukan untuk operasi mesh. Penyerang mungkin mencoba mendapatkan hak istimewa yang ditingkatkan untuk melakukan operasi berbahaya di {i>mesh<i}, seperti mengubah kebijakan keamanan dan image workload.

Risiko keamanan

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

  • Perlindungan keamanan tidak lengkap. Mesh layanan belum dikonfigurasi dengan kebijakan otentikasi dan otorisasi untuk melindungi keamanannya. Sebagai misalnya, tidak ada kebijakan otentikasi atau otorisasi yang ditentukan untuk dan layanan dalam jaring.
  • Pengecualian kebijakan keamanan. Untuk mengakomodasi kasus penggunaan yang spesifik, para pengguna dapat membuat pengecualian kebijakan keamanan untuk lalu lintas tertentu (internal atau eksternal) untuk dikecualikan dari kebijakan keamanan Cloud Service Mesh. Untuk mengamankan menangani kasus semacam itu, Menangani pengecualian kebijakan dengan aman, dalam dokumen ini.
  • Mengabaikan upgrade gambar. Kerentanan mungkin ditemukan untuk gambar tersebut yang digunakan dalam jaring. Anda harus mempertahankan komponen mesh dan image workload pembaruan kerentanan terkini.
  • Kurangnya pemeliharaan (tidak ada keahlian atau sumber daya). Perangkat lunak {i>mesh<i} dan konfigurasi kebijakan memerlukan pemeliharaan rutin untuk memanfaatkan mekanisme perlindungan keamanan terbaru.
  • Kurangnya visibilitas. Kesalahan konfigurasi atau konfigurasi mesh yang tidak aman kebijakan dan traffic atau operasi mesh abnormal tidak ditujukan ke perhatian administrator mesh.
  • Penyimpangan konfigurasi. Konfigurasi kebijakan dalam mesh menyimpang dari sumber kebenaran.

Langkah-langkah untuk melindungi mesh layanan

Bagian ini menampilkan panduan pengoperasian untuk mengamankan mesh layanan.

Arsitektur keamanan

Keamanan mesh layanan bergantung pada keamanan komponen di berbagai lapisan sistem {i>mesh<i} dan penggunaannya. Tingkat tinggi tujuan dari postur keamanan Cloud Service Mesh yang diusulkan adalah untuk mengamankan layanan dengan mengintegrasikan beberapa mekanisme keamanan di berbagai lapisan, yang bersama-sama mencapai keamanan sistem secara keseluruhan dengan 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 memberikan kontrol akses untuk perangkat eksternal traffic dan mengamankan akses eksternal ke API yang diekspos oleh layanan di jala tersebut.
    • Keamanan keluar Cloud Service Mesh mengatur traffic keluar dari dan workload internal.
    • Autentikasi pengguna Cloud Service Mesh berintegrasi dengan infrastruktur Google untuk mengautentikasi panggilan eksternal dari {i>browser<i} 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 masuk dan keluar Cloud Service Mesh menggunakan Certificate Authority Service.
    • Kontrol Layanan VPC dan VPC melindungi tepian {i>mesh<i} melalui kontrol akses jaringan pribadi.
  • Keamanan cluster
    • Cloud Service Mesh mutual TLS (mTLS) menerapkan traffic workload ke workload enkripsi dan otentikasi.
    • Certificate authority Cloud Service Mesh menyediakan dan mengelola sertifikat yang digunakan dengan aman oleh beban kerja.
    • Otorisasi Cloud Service Mesh menerapkan kontrol akses untuk layanan mesh berdasarkan identitas mereka dan atribut lainnya.
    • Dasbor keamanan GKE Enterprise menyediakan pemantauan konfigurasi kebijakan keamanan dan NetworkPolicy Kubernetes untuk workload.
    • Kontrol akses Pod yang menerapkan kebijakan jaringan Kubernetes berdasarkan IP alamat, label Pod, namespace, dan lain-lain.
  • Keamanan workload
    • Dapatkan info terbaru terkait rilis keamanan Cloud Service Mesh untuk memastikan Biner Cloud Service Mesh yang berjalan di mesh Anda tidak diketahui publik kerentanan.
    • Workload Identity Federation untuk GKE memungkinkan workload mendapatkan kredensial untuk memanggil layanan Google dengan aman.
    • Cloud Key Management Service (Cloud KMS) mengamankan data sensitif atau kredensial melalui modul keamanan hardware (HSM). Misalnya, workload dapat menggunakan Cloud KMS untuk menyimpan kredensial, atau data sensitif lainnya. CA Service, yang merupakan yang digunakan untuk menerbitkan sertifikat untuk workload mesh, dukungan per pelanggan dan Kunci penandatanganan yang didukung HSM yang dikelola oleh Cloud KMS.
    • Kubernetes Container Network Interface (CNI) mencegah serangan eskalasi akses dengan menghilangkan kebutuhan akan init container Cloud Service Mesh.
  • 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.
    • Pengontrol Kebijakan GKE Enterprise memvalidasi dan mengaudit konfigurasi kebijakan di mesh untuk mencegah dan kesalahan konfigurasi.
    • Otorisasi Biner Google Cloud memastikan bahwa gambar beban kerja dalam mesh adalah gambar yang diizinkan oleh para administrator.
    • Cloud Audit Logs mengaudit operasi mesh.

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

arus traffic keamanan

Keamanan cluster

Bagian ini menjelaskan praktik terbaik terkait keamanan cluster.

Mengaktifkan TLS bersama yang ketat

Serangan {i>man-in-the-middle<i} (MitM) mencoba memasukkan entitas jahat di antara dua pihak yang berkomunikasi untuk menyadap atau memanipulasi komunikasi. Cloud Service Mesh melindungi dari MitM dan serangan pemindahan data yang tidak sah dengan menerapkan enkripsi dan autentikasi mTLS untuk semua pihak yang berkomunikasi. Mode permisif menggunakan mTLS saat kedua sisi mendukung itu tetapi mengizinkan koneksi tanpa mTLS. Sebaliknya, mTLS yang ketat mengharuskan lalu lintas dienkripsi dan diotentikasi dengan mTLS dan tidak mengizinkan teks biasa kemacetan.

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

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

Mengaktifkan kontrol akses

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

Kontrol akses layanan sangat penting untuk mencegah akses yang tidak sah ke layanan IT perusahaan mereka. Penerapan mTLS mengenkripsi dan mengotentikasi permintaan tetapi mesh tetap kebutuhan Kebijakan otorisasi Cloud Service Mesh untuk menegakkan kontrol akses pada layanan—misalnya, dengan menolak permintaan yang berasal dari klien yang telah diotentikasi.

Kebijakan otorisasi Cloud Service Mesh menyediakan cara yang fleksibel untuk mengonfigurasi akses untuk melindungi layanan Anda dari akses yang tidak sah. Mesh Layanan Cloud kebijakan otorisasi akan ditegakkan berdasarkan identitas yang telah diotentikasi yang berasal dari hasil otentikasi; Berbasis mTLS- atau JSON Web Token (JWT) autentikasi dapat digunakan bersama sebagai bagian dari Cloud Service Mesh kebijakan otorisasi.

Menerapkan kebijakan autentikasi Cloud Service Mesh

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

Token Web JSON (JWT)

Selain otentikasi mTLS, administrator mesh dapat meminta 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 masuk untuk traffic eksternal atau ke layanan internal untuk in-mesh kemacetan. Autentikasi JWT dapat dikombinasikan dengan otentikasi mTLS saat sebuah JWT digunakan sebagai kredensial untuk mewakili pemanggil akhir dan layanan yang diminta memerlukan bukti bahwa penelepon dipanggil atas nama pemanggil akhir. Menegakkan Autentikasi JWT melindungi jaringan dari serangan yang mengakses layanan tanpa kredensial, dan atas nama pengguna akhir yang sebenarnya.

Autentikasi pengguna Cloud Service Mesh

Autentikasi pengguna Cloud Service Mesh adalah solusi terintegrasi untuk autentikasi dan akses pengguna akhir berbasis browser mengontrol beban kerja Anda. Alat ini mengintegrasikan mesh layanan dengan Identity yang ada Penyedia (IdP) untuk menerapkan login OpenID Connect (OIDC) berbasis web standar dan alur izin, serta menggunakan otorisasi Cloud Service Mesh kebijakan 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 yang serbaguna untuk mengkonfigurasi kontrol akses berdasarkan identitas aktual yang dijalankan layanan sebagai lapisan aplikasi (lapisan 7) properti traffic (misalnya header permintaan), dan lapisan jaringan (lapisan 3 dan lapisan 4) seperti rentang IP dan porta.

Sebaiknya terapkan kebijakan otorisasi Cloud Service Mesh berdasarkan identitas yang diotentikasi yang berasal dari hasil otentikasi untuk mempertahankan terhadap akses tidak sah ke layanan atau data.

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

Kebijakan otorisasi dimaksudkan untuk membatasi kepercayaan sebanyak mungkin. Sebagai misalnya, akses ke layanan dapat ditentukan berdasarkan jalur URL individual 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 pada lapisan jaringan (lapisan 3 dan lapisan 4) dan mengontrol akses jaringan untuk alamat IP dan port di Pod Kubernetes dan Kubernetes namespace.

Menerapkan pertukaran token untuk mengakses layanan mesh

Untuk bertahan dari serangan replay token, yang mencuri token dan menggunakan kembali token yang dicuri untuk mengakses layanan mesh, pastikan bahwa token dalam permintaan dari luar mesh ditukar dengan token internal mesh berjangka pendek di tepi mesh.

Permintaan dari luar mesh untuk mengakses layanan mesh perlu menyertakan token, seperti JWT atau cookie, untuk diotentikasi dan diotorisasi oleh jaringan. Token dari luar mesh mungkin berumur panjang. Untuk bertahan melawan serangan replay token, menukar token dari luar {i>mesh<i} dengan token internal mesh berumur pendek dengan cakupan terbatas saat traffic masuk mesh. Layanan mesh mengautentikasi token internal mesh dan mengizinkan akses permintaan berdasarkan token internal mesh.

Dukungan Cloud Service Mesh integrasi dengan Identity-Aware Proxy (IAP), yang menghasilkan RequestContextToken (token internal mesh berumur pendek dipertukarkan dari token eksternal) yang digunakan dalam Cloud Service Mesh untuk otorisasi. Dengan pertukaran token, penyerang tidak dapat menggunakan token yang dicuri di {i>mesh<i} untuk mengakses layanan IT perusahaan mereka. Cakupan dan masa pakai token yang dipertukarkan sangat terbatas kemungkinan terjadinya serangan replay token.

Menangani pengecualian kebijakan Cloud Service Mesh dengan aman

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

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

Menghindari kebijakan keamanan Cloud Service Mesh akan berdampak negatif keamanan sistem secara keseluruhan. Misalnya, jika Cloud Service Mesh mTLS dan kebijakan otorisasi diabaikan untuk porta jaringan melalui anotasi, namun tidak ada akses mengendalikan lalu lintas di pelabuhan, dan penyadapan atau modifikasi lalu lintas memungkinkan. Selain itu, mengabaikan kebijakan Cloud Service Mesh juga memengaruhi kebijakan non-keamanan, seperti kebijakan jaringan.

Saat kebijakan keamanan Cloud Service Mesh dilewati untuk sebuah port atau Alamat IP (baik sengaja atau tidak), kami sangat menyarankan agar Anda menempatkan langkah-langkah keamanan untuk mengamankan {i>mesh<i} dan memantau pengecualian keamanan, potensi celah keamanan, dan status penegakan keamanan secara keseluruhan. Kepada mengamankan mesh dalam skenario seperti ini, Anda dapat:

  • Pastikan traffic yang melewati file bantuan dienkripsi secara native dan diotentikasi untuk mencegah serangan MitM.
  • Menerapkan kebijakan jaringan Kubernetes untuk membatasi konektivitas porta dengan pengecualian kebijakan—misalnya, membatasi port dengan pengecualian kebijakan untuk hanya mengizinkan traffic dari layanan di namespace yang sama—atau hanya mengizinkan traffic melewati port yang memberlakukan 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 sumbernya. Anda dapat menggunakan Config Sync untuk mencegah penyimpangan konfigurasi.

Menerapkan Cloud Audit Logs dan pemantauan

Sebaiknya administrator mesh memantau hal berikut:

Administrator dapat menggunakan sumber daya kemampuan observasi ini untuk memverifikasi bahwa keamanan konfigurasi berjalan seperti yang diharapkan dan untuk memantau setiap pengecualian terhadap keamanan penegakan kebijakan. Misalnya, akses yang tidak melalui file sespan, akses yang tidak memiliki kredensial yang valid tetapi dapat mengakses layanan.

Sementara software kemampuan observasi open source (misalnya, Prometheus) dapat sebaiknya gunakan dengan Cloud Service Mesh, sebaiknya gunakan Kemampuan Observasi Google Cloud. Solusi kemampuan observasi bawaan untuk Google Cloud ini menyediakan logging, pengumpulan, pemantauan, dan pemberitahuan metrik, yang dikelola sepenuhnya.

Keamanan workload

Keamanan workload melindungi dari serangan yang membahayakan Pod workload dan dan menggunakan Pod yang telah disusupi untuk meluncurkan serangan terhadap cluster (untuk misalnya, serangan {i>botnet<i}).

Membatasi hak istimewa Pod

Pod Kubernetes mungkin memiliki hak istimewa yang berdampak pada Pod lain di node atau . Pembatasan keamanan pada Pod workload perlu diterapkan untuk mencegah Pod yang disusupi meluncurkan serangan terhadap cluster.

Untuk menerapkan prinsip hak istimewa terendah untuk workload pada Pod:

  • Layanan yang di-deploy di mesh harus berjalan dengan hak istimewa yang sesedikit sebaik mungkin.
  • Anda dapat mengonfigurasi Cloud Service Mesh agar menggunakan container init untuk atur pengalihan lalu lintas iptables ke file bantuan. Hal ini mengharuskan pengguna untuk membuat workload yang memiliki hak istimewa untuk men-deploy container Kemampuan NET_ADMIN dan NET_RAW. Untuk menghindari risiko menjalankan container dengan hak istimewa yang ditingkatkan, administrator mesh dapat aktifkan plugin Istio CNI untuk mengonfigurasi pengalihan traffic menjadi file bantuan.

Image container yang aman

Penyerang mungkin 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 yang dikerahkan di dalam jala tersebut.

Melakukan mitigasi terhadap kerentanan mesh

  • Analisis Artefak dapat memindai dan memunculkan kerentanan pada workload GKE.
  • Penanganan kerentanan dan eksposur umum (CVE). Setelah kerentanan ditemukan dalam image container, administrator mesh dapat memperbaiki kerentanan sesegera mungkin. Google menangani patching secara otomatis CVE yang memengaruhi image mesh.

Gunakan Workload Identity Federation for GKE untuk mengakses layanan Google dengan aman

Workload Identity Federation untuk GKE adalah cara yang direkomendasikan bagi workload mesh untuk mengakses layanan Google dengan aman. Alternatif untuk menyimpan kunci akun layanan di secret Kubernetes dan menggunakan kunci akun layanan untuk mengakses tidak aman karena risiko kebocoran kredensial, eskalasi akses, pengungkapan informasi, dan anti-penyangkalan.

Memantau status keamanan melalui telemetri dan dasbor keamanan

Mesh layanan mungkin memiliki pengecualian keamanan dan potensi celah. Penting sangat penting untuk memunculkan dan memantau status keamanan {i>mesh<i}, yang mencakup kebijakan keamanan yang diberlakukan, pengecualian keamanan, dan potensi keamanan celah pada jala tersebut. Anda dapat menggunakan dasbor keamanan GKE Enterprise dan telemetri untuk memunculkan dan memantau status keamanan mesh.

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

Dasbor keamanan GKE Enterprise menampilkan berbagai kebijakan keamanan diterapkan ke beban kerja di mesh layanan, termasuk kebijakan kontrol akses (Kebijakan Jaringan Kubernetes, kebijakan Otorisasi Biner, dan akses layanan {i>control policy<i}), dan kebijakan autentikasi (mTLS).

Keamanan untuk kredensial dan data pengguna yang sensitif

Jika Anda menyimpan kredensial atau data pengguna yang sensitif di persisten cluster data, kredensial, dan penyimpanan secara langsung di Pod. menjadi rentan terhadap serangan yang berasal dari Pod atau operasi berbahaya. Data juga rentan terhadap serangan jaringan jika data tersebut ditransfer melalui jaringan untuk melakukan otentikasi ke layanan.

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