Praktik terbaik keamanan Cloud Service Mesh

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 menginstal 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 pengguna yang menjalankan layanan di Mesh Layanan Cloud. Tujuan langkah-langkah keamanan yang dijelaskan di sini juga berguna bagi organisasi yang perlu meningkatkan keamanan mesh layanannya untuk memenuhi persyaratan kepatuhan.

Dokumen ini disusun sebagai berikut:

• Pengantar
• Vektor serangan dan risiko keamanan
  • Vektor serangan
  • Risiko keamanan
• Mengukur untuk melindungi mesh layanan
  • Arsitektur keamanan
  • Keamanan cluster
    • Mengaktifkan TLS bersama yang ketat
    • Mengaktifkan kontrol akses
      • Menerapkan kebijakan autentikasi Cloud Service Mesh
      • Token Web JSON (JWT)
      • Autentikasi pengguna Cloud Service Mesh
      • Menerapkan kebijakan otorisasi
      • Menerapkan pertukaran token untuk mengakses layanan mesh
    • Menangani pengecualian kebijakan Cloud Service Mesh dengan aman
      • Menerapkan Kebijakan Jaringan Kubernetes
    • Akses bidang kontrol aman
    • Menerapkan batas namespace
      • Menerapkan kebijakan RBAC Kubernetes
  • Keamanan mesh
    • Kontrol akses masuk cluster
    • Mengatur traffic keluar cluster
    • Menggunakan cluster pribadi atau Kontrol Layanan VPC untuk mengunci akses eksternal
    • Bertahan dari serangan DDoS eksternal
  • Keamanan untuk administrasi dan otomatisasi mesh
    • Segmentasikan 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
    • Image container aman
    • Mengurangi kerentanan mesh
    • Menggunakan Workload Identity Federation for GKE untuk mengakses layanan Google dengan aman
    • Memantau status keamanan melalui telemetri dan dasbor keamanan
  • Keamanan untuk kredensial dan data pengguna yang sensitif

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 atas jaringan perilaku, 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}. Setelan Cloud Service Mesh default dipilih untuk melindungi aplikasi, tetapi dalam beberapa kasus, Anda mungkin perlu konfigurasi khusus atau untuk memberikan pengecualian dengan mengecualikan aplikasi, porta, atau alamat IP agar tidak berpartisipasi dalam sebuah jala. Memiliki kontrol untuk mengatur konfigurasi mesh dan pengecualian keamanan penting.

Catatan: Panduan 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. Anda seharusnya memperlakukan rekomendasi ini sebagai dasar untuk digunakan bersama dengan rekomendasi praktik yang dibahas dalam panduan ini. Panduan ini menjelaskan tambahan untuk Cloud Service Mesh dan bagaimana teknologi di Google Cloud dapat mengamankan semua lapisan, komponen, dan aliran informasi dalam mesh.

Vektor serangan dan risiko keamanan

Vektor serangan

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

• 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 tersebut, baca bagian Menangani pengecualian kebijakan dengan aman.
• Mengabaikan upgrade gambar. Kerentanan dapat 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 dan traffic/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.

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.
  • Cloud Armor dapat melindungi dari serangan {i>external denial-of-service<i} (DDoS) dan lapisan 7. Ini berfungsi sebagai {i>Web Application Firewall<i} (WAF) untuk melindungi {i>mesh<i} dari serangan jaringan. Misalnya, eksekusi kode injeksi dan jarak jauh serangan.
  • 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.
  • CA terkelola, seperti certificate authority Cloud Service Mesh, Certificate Authority Service, 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 Kebijakan Jaringan Kubernetes untuk workload.
  • Kebijakan Jaringan Kubernetes menerapkan kontrol akses Pod berdasarkan IP alamat, label Pod, namespace, dan lain-lain.
  • Keamanan bidang kontrol melindungi dari serangan di bidang kontrol. Perlindungan ini mencegah penyerang untuk memodifikasi, mengeksploitasi, atau membocorkan data konfigurasi mesh dan layanan.
• 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 atau kredensial sensitif melalui Hardware Security Modules (HSM). Misalnya, workload dapat menggunakan Cloud KMS untuk menyimpan kredensial, atau data sensitif lainnya. CA Service—digunakan untuk menerbitkan sertifikat ke beban kerja mesh—mendukung per-pelanggan dan Kunci penandatanganan yang didukung HSM yang dikelola oleh Cloud KMS.
  • CNI Kubernetes (Antarmuka Jaringan Container) mencegah hak istimewa serangan eskalasi 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.
  • Google Cloud Audit Logging mengaudit operasi mesh.

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

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

Kebijakan keamanan Cloud Service Mesh (seperti autentikasi dan otorisasi kebijakan) harus diberlakukan pada semua lalu lintas masuk dan keluar dari {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 rentang IP. Misalnya, untuk membuat koneksi native dengan layanan yang tidak dikelola oleh Cloud Service Mesh. Kepada Cloud Service Mesh yang aman dalam kasus penggunaan tersebut. 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 menerapkan kontrol akses pada layanan. Misalnya, menolak penawaran 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 harus ditegakkan berdasarkan identitas otentikasi yang berasal dari hasil autentikasi - berbasis mTLS atau JSON Web Token (JWT) autentikasi harus digunakan bersama sebagai bagian dari otorisasi Cloud Service Mesh kebijakan izin yang relevan.

Menerapkan kebijakan autentikasi Cloud Service Mesh

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 digabungkan dengan otentikasi mTLS saat koneksi 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 kebijakan otorisasi Cloud Service Mesh untuk akses kontrol.

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 oleh layanan, lapisan aplikasi (Lapisan 7) properti lalu lintas (misalnya tajuk permintaan), dan lapisan jaringan (Lapisan 3 dan Lapisan 4) seperti rentang IP dan porta.

Kebijakan otorisasi Cloud Service Mesh harus diterapkan berdasarkan autentikasi identitas yang diperoleh dari hasil otentikasi untuk melindungi diri dari akses tidak sah ke layanan atau data.

Secara {i>default<i}, akses ke layanan harus ditolak kecuali 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 harus 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 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.

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

Menerapkan pertukaran token untuk mengakses layanan mesh

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

Permintaan dari luar mesh untuk mengakses layanan mesh perlu menyertakan tertentu, seperti JWT atau cookie, agar dapat diotentikasi dan diotorisasi oleh jaringan. Token dari luar mesh mungkin berumur panjang. Untuk bertahan melawan serangan ulang token, token dari luar {i>mesh<i} harus ditukarkan dengan token internal mesh berumur singkat 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 terbatas sangat mengurangi kemungkinan terjadinya serangan replay token.

Catatan: Pertukaran token IAP berbeda dengan autentikasi pengguna Cloud Service Mesh dalam IAP mempertukarkan token eksternal dengan token internal berumur pendek untuk mempertahankan terhadap serangan replay token, sedangkan web autentikasi pengguna Cloud Service Mesh panggilan eksternal berbasis browser ke layanan aplikasi web.

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 ini, Anda terkadang perlu membuat pengecualian untuk 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, excludeOutboundIPRanges) ke Pod untuk mengecualikan traffic agar tidak ditangani oleh Envoy bantuan. Selain anotasi untuk mengecualikan traffic, Anda dapat mengabaikan mesh dengan men-deploy aplikasi beserta injeksi file bantuan dinonaktifkan. Misalnya, dengan menambahkan label sidecar.istio.io/inject="false" ke bagian Pod aplikasi.

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

Saat kebijakan keamanan Cloud Service Mesh dilewati untuk satu port atau IP (baik secara sengaja atau tidak sengaja), harus ada langkah-langkah keamanan lain di untuk mengamankan {i>mesh<i} dan memantau pengecualian keamanan, potensi keamanan celah keamanan, dan status penegakan keamanan secara keseluruhan. Untuk mengamankan {i>mesh<i} Anda sedemikian skenario, Anda dapat:

• Pastikan traffic yang mengabaikan 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 dalam namespace yang sama) atau hanya mengizinkan traffic melalui port dengan kebijakan keamanan Cloud Service Mesh yang diterapkan.
• Terapkan Pengontrol Kebijakan Perusahaan GKE untuk otomatis memvalidasi kebijakan Mesh Layanan Cloud. Misalnya, terapkan agar file bantuan Cloud Service Mesh selalu dimasukkan ke sebagian besar workload standar dan berbasis cloud.

Menerapkan Kebijakan Jaringan Kubernetes

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

Untuk membentuk postur keamanan yang kuat bagi mesh layanan, mekanisme keamanan platform dasar harus diterapkan agar dapat bekerja sama dengan Cloud Service Mesh kebijakan keamanan.

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

Misalnya, administrator mesh dapat mengonfigurasi Kebijakan Jaringan Kubernetes untuk hanya mengizinkan traffic untuk menggunakan port dengan kebijakan keamanan Cloud Service Mesh yang diterapkan. Jika semua traffic harus diterapkan dengan Cloud Service Mesh mTLS, administrator dapat mengonfigurasi kebijakan jaringan Kubernetes agar hanya mengizinkan traffic pada port yang dikonfigurasi dengan kebijakan mTLS Cloud Service Mesh. Administrator {i>mesh<i} juga dapat mengonfigurasi Kebijakan Jaringan Kubernetes untuk membatasi konektivitas port dengan kebijakan setiap pengecualian. Misalnya, batasi konektivitas porta tersebut pada namespace.

Catatan: Batasan kebijakan jaringan Kubernetes. Meskipun Anda dapat menggunakan Kubernetes kebijakan jaringan untuk mencegah konektivitas yang tidak diinginkan dan membatasi celah keamanan dari porta dengan kebijakan keamanan yang diabaikan, ini bukanlah pengganti Kebijakan keamanan Cloud Service Mesh karena tidak menawarkan kontrol akses berdasarkan pada identitas aplikasi atau properti Lapisan 7 lainnya. Selain itu, hanya penggunaan pemilih Pod dan namespace untuk kebijakan jaringan Kubernetes cluster tunggal. Rentang IP pod dapat digunakan dengan mesh multi-cluster kebijakan tersebut bersifat umum dan memeliharanya rentan terhadap error.

Akses bidang kontrol aman

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

Selain mekanisme autentikasi, untuk Cloud Service Mesh dalam cluster, Kubernetes kebijakan jaringan dapat di-deploy untuk mengisolasi namespace sistem Cloud Service Mesh (secara default istio-system) dari namespace yang tidak dikelola dan klien di luar sementara memungkinkan bidang data untuk mengakses bidang kontrol. Aturan firewall VPC dapat mencegah traffic di luar cluster menjangkau Istiod. Dengan langkah-langkah isolasi jaringan tersebut, penyerang dari luar {i>mesh<i} akan tidak dapat mengakses bidang kontrol, bahkan jika penyerang memiliki kredensial yang valid. Sebagai bidang kontrol terkelola, Google menangani keamanan bidang kontrol dan isolasi jaringan tersebut kebijakan untuk bidang kontrol tidak diperlukan.

Menerapkan batas namespace

Untuk mencegah pengguna dengan satu namespace mengakses/memperbarui sumber daya di namespace tidak sah:

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

Menerapkan kebijakan RBAC Kubernetes

Administrator {i>mesh<i} harus menerapkan Kebijakan RBAC Kubernetes untuk mengontrol siapa yang diizinkan mengakses dan mengupdate resource Kubernetes. Kubernetes yang aman dapat memitigasi risiko keamanan di jala. Misalnya, pengguna yang tidak berhak tidak diizinkan untuk mengubah deployment Kubernetes dan mengabaikan penerapan kebijakan Cloud Service Mesh. Peran pengguna harus terikat ke namespace sehingga pengguna tidak diizinkan untuk mengakses namespace lagi yang tidak mereka butuhkan. Untuk panduan dan contoh konfigurasi RBAC, rujuk ke Mengonfigurasi kontrol akses berbasis peran. Setelah mengaktifkan Workload Identity Federation untuk GKE, Anda juga dapat memungkinkan akun layanan Kubernetes bertindak sebagai akun layanan IAM.

Keamanan edge mesh

Karena sebagian besar serangan juga dapat berasal dari luar cluster, di tepi jala sangat penting.

Kontrol akses masuk cluster

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

Ingress harus menerapkan otentikasi dan otorisasi untuk layanan yang terekspos pemanggil eksternal.

• Menerapkan kebijakan keamanan traffic masuk cluster. Kapan cluster perlu menerima traffic eksternal, administrator mesh harus menerapkan keamanan masuk kebijakan kami, termasuk Cloud Service Mesh gateway TLS, autentikasi, dan kebijakan otorisasi, untuk mengautentikasi eksternal dan memverifikasi bahwa permintaan eksternal diotorisasi untuk mengakses layanan diekspos oleh gateway masuknya. Menegakkan kebijakan keamanan masuk melindungi terhadap serangan dari luar {i>mesh<i} yang mencoba mengakses layanan tanpa kredensial atau izin yang valid.
• Menggunakan Cloud Armor untuk berfungsi sebagai Web Firewall Aplikasi (WAF) untuk memberikan pertahanan dari serangan berbasis web (misalnya, serangan injection dan serangan eksekusi jarak jauh). Untuk informasi selengkapnya, lihat Dari edge ke mesh: Mengekspos aplikasi mesh layanan melalui GKE Ingress.

Mengatur traffic keluar cluster

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

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

Kebijakan traffic keluar dapat memitigasi serangan berikut:

• Serangan pemindahan data yang tidak sah.
• Pod Layanan dapat dieksploitasi oleh penyerang jika CVE-nya 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 diizinkan untuk mengirim lalu lintas ke {i>host<i} tertentu di luar jalanya. Sementara itu, untuk traffic yang keluar dari mesh, bukan menangani TLS di tiap file bantuan, TLS dapat berasal dari gateway keluar. Cara ini memberikan cara yang seragam dan lebih aman untuk memulai lalu lintas TLS karena sertifikat klien untuk mTLS dapat diisolasi dari namespace aplikasi berjalan.

Gunakan cluster pribadi atau Kontrol Layanan VPC untuk mengunci akses eksternal

Selain menerapkan kebijakan keamanan traffic masuk dan keluar, kunci eksternal akses menggunakan cluster pribadi atau Kontrol Layanan VPC di mana pun sebaik mungkin. Sementara kebijakan keamanan dikontrol oleh keamanan mesh administrator, konfigurasi cluster pribadi atau Kontrol Layanan VPC dapat diberlakukan oleh administrator keamanan organisasi.

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

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

Kontrol Layanan VPC membantu melindungi dari serangan pemindahan data yang tidak sah dan mencegah penyerang eksternal agar tidak mengakses layanan di dalam jala.

Melindungi Anda dari serangan DDoS eksternal

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

Keamanan untuk administrasi dan otomatisasi mesh

Penting untuk mempertimbangkan keamanan untuk operasi administratif dan setiap otomatisasi yang Anda bangun di sekitar mesh Anda, misalnya CI/CD. Hal berikut tujuan untuk memastikan bahwa {i>mesh<i} dapat dioperasikan dengan aman tanpa risiko mengekspos layanan ke serangan tambahan.

Menyegmentasikan peran yang digunakan untuk operasi mesh

Mengikuti prinsip yang sama seperti kontrol akses berbasis peran, pengguna mesh harus diklasifikasikan sesuai dengan peran mereka. Setiap peran hanya boleh diberikan kumpulan hak istimewa minimum yang diperlukan oleh peran tersebut.

Misalnya, kumpulan pengguna yang melakukan penyebaran layanan seharusnya tidak memiliki hak istimewa untuk memperbarui kebijakan otentikasi dan otorisasi.

Ada berbagai kategori operator. Misalnya, operator cluster dan operator namespace. Penting untuk mencegah eskalasi akses dari yang dapat menimbulkan akses terlarang ke sumber daya yang tidak sah.

Kebijakan RBAC Kubernetes memungkinkan mesh administrator untuk membatasi akses sumber daya hanya untuk pengguna yang diotorisasi.

Memvalidasi konfigurasi kebijakan secara otomatis

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

Menghindari terlalu banyak kepercayaan pada individu dengan izin untuk memperbarui Kebijakan keamanan Cloud Service Mesh dan untuk mengotomatiskan validasi Cloud Service Mesh kebijakan, administrator mesh harus menerapkan batasan pada Cloud Service Mesh kebijakan menggunakan Pengontrol Kebijakan.

Pengontrol Kebijakan didasarkan pada open source Gatekeeper dan dapat dijalankan sebagai pengontrol penerimaan Kubernetes untuk menolak resource yang tidak valid agar tidak diterapkan atau dalam mode audit sehingga administrator dapat diberi tahu tentang pelanggaran data. Pengontrol Kebijakan dapat otomatis memvalidasi deployment dalam mesh, seperti memvalidasi bahwa anotasi pada deployment tidak mengabaikan kebijakan Cloud Service Mesh, memvalidasi bahwa kebijakan Cloud Service Mesh seperti yang diharapkan, dan memvalidasi bahwa deployment tidak menyertakan kemampuan root (seperti, NET_ADMIN dan NET_RAW).

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

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

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

Tujuan library template batasan yang diberikan di Pengontrol Kebijakan berisi serangkaian {i>template<i} batasan yang dapat untuk digunakan dengan perangkat Paket batasan keamanan Cloud Service Mesh untuk menerapkan praktik terbaik keamanan Cloud Service Mesh tertentu, misalnya autentikasi, otorisasi, dan kebijakan lalu lintas data. Berikut ini adalah beberapa contoh batasan yang disertakan dalam paket:

• Menerapkan tingkat mesh mTLS ketat PeerAuthentication.
• Penerapan semua PeerAuthentication tidak dapat menimpa mTLS yang ketat.
• Menerapkan tingkat mesh tolak default AuthorizationPolicy.
• Menerapkan AuthorizationPolicy pola aman.
• Terapkan file sampingan Cloud Service Mesh selalu dimasukkan ke workload.

Untuk menangani pengecualian dan situasi akses darurat, administrator mesh dapat:

• Mengecualikan namespace dari penegakan webhook penerimaan Pengontrol Kebijakan, tetapi setiap pelanggaran masih dilaporkan di audit.
• Menetapkan Constraint spec.enforcementAction ke uji coba. Webhook penerimaan tidak akan mencegah perubahan, tetapi pelanggaran apa pun tetap dilaporkan di audit.
• Menambahkan logika pengecualian ke dalam Template Batasan (contoh).

Menggunakan pendekatan GitOps dengan Config Sync untuk mencegah penyimpangan konfigurasi

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

Menerapkan Logging Audit dan pemantauan

Administrator mesh harus memantau hal berikut:

• Logging Audit Cloud
• Logging Audit Cloud Service Mesh
• Logging Audit untuk batasan kebijakan
• Sinkronisasi Konfigurasi Anthos
• Log akses
• Metrik tingkat layanan
• Mengakses rekaman aktivitas

Resource kemampuan observasi ini dapat digunakan untuk memverifikasi bahwa keamanan konfigurasi berjalan seperti yang diharapkan dan memantau jika ada pengecualian 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 Google Cloud Observability (sebelumnya bernama Stackdriver). Solusi kemampuan observasi bawaan untuk Google Cloud menyediakan logging, pengumpulan, pemantauan, dan pemberitahuan metrik, yang terkelola sepenuhnya dan mudah gunakan.

Melindungi certificate authority untuk sertifikat dalam cluster

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

Jika Anda menggunakan certificate authority (CA) Istio yang tidak dikelola, yang dihosting sebagai bagian dari Istiod, kunci penandatanganan CA disimpan dalam rahasia Kubernetes dan dapat diakses oleh operator yang memiliki akses ke sumber daya rahasia di Namespace istio-system. Hal ini berisiko, karena operator mungkin dapat menggunakan Kunci CA secara terpisah dari CA Istiod dan berpotensi menandatangani workload sertifikatnya secara independen. Ada juga risiko bahwa penandatangan CA yang dikelola sendiri kunci dapat secara tidak sengaja bocor karena error operasional.

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

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.
• Pod Kubernetes yang berjalan dalam mode hak istimewa dapat memanipulasi stack jaringan dan kemampuan {i>kernel<i} lainnya pada {i>host<i}. Pengontrol Kebijakan Perusahaan GKE dapat digunakan untuk mencegah Pod menjalankan container dengan hak istimewa.
• Cloud Service Mesh dapat dikonfigurasi agar menggunakan container init untuk mengonfigurasi pengalihan lalu lintas iptables ke file bantuan. Hal ini mengharuskan pengguna untuk membuat deployment workload agar 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 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 yang dikerahkan di dalam jala tersebut.

Melakukan mitigasi terhadap kerentanan mesh

• Container Analysis. Analisis Penampung dapat memindai dan memunculkan kerentanan pada workload GKE.
• Penanganan CVE (Kerentanan dan Eksposur Umum). Setelah kerentanan ditemukan dalam image container, administrator mesh harus memperbaiki kerentanan sesegera mungkin. Sebagai Cloud Layanan Cloud terkelola dengan bidang data terkelola, Google akan otomatis menangani patching 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. 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 mesh administrator untuk mengamati perilaku layanan (seperti SLO, traffic, pemadaman layanan, topologi).

Dasbor keamanan GKE Enterprise menganalisis dan memvisualisasikan 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

Data atau kredensial pengguna yang sensitif menjadi rentan terhadap serangan yang berasal dari Pod atau operasi berbahaya jika disimpan di cluster secara persisten penyimpanan, seperti menggunakan secret Kubernetes atau langsung di Pod. Mereka juga rentan terhadap serangan jaringan jika mereka ditransfer melalui jaringan untuk 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.

Langkah selanjutnya

• Meninjau praktik terbaik untuk menggunakan gateway keluar Cloud Service Mesh di cluster GKE
• Mengonfigurasi keamanan transportasi
• Memperbarui kebijakan otorisasi