Meningkatkan keamanan layanan microsoft dengan Istio

Halo! Nama saya Ilya, saya bekerja sebagai insinyur DevOps di tim pengembangan. Kami secara aktif menggunakan pendekatan layanan-mikro, dan, karena spesifik pekerjaan kami, keamanan interaksi antar-layanan penting bagi kami. Pada artikel ini, saya ingin menjelaskan cara kerja Istio dan menunjukkan kepada Anda cara menggunakan beberapa fitur keamanannya sebagai contoh. Saya harap ini bermanfaat untuk menyelesaikan masalah Anda. Selamat membaca!

Untuk apa jaringan layanan?

Jaring layanan, dalam hal ini Istio, adalah pengikat untuk semua yang diperlukan untuk mengelola dan mengkonfigurasi komunikasi antar-layanan: perutean, otentikasi, otorisasi, pelacakan, kontrol akses, dan banyak lagi. Dan meskipun ada banyak pustaka sumber terbuka untuk mengimplementasikan fungsi-fungsi ini secara langsung dalam kode layanan, dengan Istio Anda bisa mendapatkan semua yang sama tanpa menambahkan apa pun ke layanan itu sendiri.

Komponen 

Artikel ditulis untuk istio 1.6

Istio secara logis dibagi menjadi bidang data dan bidang kontrol.

Pesawat data adalah kumpulan server proxy (Utusan) yang ditambahkan ke pod dalam bentuk sidecars. Proxy ini menyediakan dan mengontrol semua komunikasi jaringan antara layanan microser dan dikonfigurasikan dari bidang kontrol.



Pesawat manajemen (istiod) menyediakan penemuan layanan, konfigurasi, dan manajemen sertifikat. Itu mengkonversi objek Istio menjadi konfigurasi yang Utusan mengerti dan mendistribusikannya di bidang data.







Komponen layanan mesh Istio



Anda dapat menambahkan utusan ke pod aplikasi baik secara manual atau dengan mengatur penambahan otomatis menggunakan webhook Mutating Admission, yang ditambahkan Istio selama instalasi. Untuk melakukan ini, letakkan tag istio-injection = diaktifkan di namespace yang diperlukan.



Selain sidecar proxy dengan utusan, Istio akan menambahkan wadah init khusus ke pod yang akan mengarahkan lalu lintas tempur ke wadah dengan utusan. Tetapi bagaimana ini dicapai? Dalam hal ini, tidak ada keajaiban, dan ini diterapkan dengan menetapkan aturan iptables tambahan di namespace jaringan pod.





Mari kita lihat dalam praktik bagaimana sespan menangkap lalu lintas masuk dan keluar dari sebuah wadah. Untuk melakukan ini, mari kita lihat ruang jaringan beberapa pod dengan sespan ditambahkan oleh Istio secara lebih rinci. 





Mari kita lihat daftar wadah aplikasi productpage:

kubectl -n default get pods productpage-v1-7df7cb7f86-ntwzz -o jsonpath="{.spec['containers','initContainers'][*].name}"
productpage 
istio-proxy 
istio-init

Selain halaman produk itu sendiri, sidecar istio-proxy (utusan yang sama) dan wadah init istio-init bekerja di pod.



Anda dapat melihat aturan iptables yang dikonfigurasi di ruang pod menggunakan utilitas nsenter. Untuk melakukan ini, kita perlu mengetahui pid dari proses wadah:

docker inspect k8s_productpage --format '{{ .State.Pid }}'
16286

Sekarang kita bisa melihat aturan iptables yang diatur dalam wadah ini.







Anda dapat melihat bahwa hampir semua lalu lintas masuk dan keluar sekarang dicegat dan dialihkan ke port yang sudah ditunggu utusannya. 

Aktifkan enkripsi lalu lintas bersama

Objek Policy dan MeshPolicy telah dihapus dari istio 1.6. Sebagai gantinya, mereka menyarankan menggunakan objek PeerAuthentication

Istio memungkinkan Anda untuk mengenkripsi semua lalu lintas antar kontainer, dan aplikasi itu sendiri bahkan tidak akan tahu bahwa mereka berkomunikasi melalui tls. Ini dilakukan oleh Istio sendiri di luar kotak dengan satu manifes, karena sertifikat klien sudah dipasang di sespan proxy. 



Algoritma adalah sebagai berikut: 

1. Proksi utusan sisi klien dan sisi server saling mengautentikasi sebelum mengirim permintaan;
   
   
2. Jika pemeriksaan berhasil, proksi klien mengenkripsi lalu lintas dan mengirimkannya ke proksi server;
   
   
3. Sisi server proxy mendekripsi lalu lintas dan mengarahkannya secara lokal ke layanan tujuan yang sebenarnya.
   
   

Anda dapat mengaktifkan mTLS di berbagai tingkatan:

• Di tingkat seluruh jaringan;
  
  
• Di tingkat namespace;
  
  
• Pada level pod tertentu. 
  
  

Mode operasi:

• IZIN: baik lalu lintas teks terenkripsi dan polos diizinkan;
  
  
• STRICT: hanya TLS yang diizinkan;
  
  
• DISABLE: hanya teks biasa yang diizinkan.
  
  

Mari kita akses layanan detail dari pod halaman produk menggunakan curl tanpa TLS diaktifkan dan lihat apa yang muncul dengan tcpdump untuk detail:



Permintaan:







Lalu lintas penumpukan:







Semua badan dan header dapat dibaca dengan sempurna dalam teks biasa.



Mari aktifkan tls. Untuk melakukan ini, buat objek bertipe PeerAuthentication di namespace dengan pod kami.

apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: default
  namespace: default
spec:
  mtls:
    mode: STRICT

Mari jalankan permintaan dari halaman produk ke detail lagi dan lihat apa yang kita dapatkan:







Lalu lintas dienkripsi

Otorisasi

Objek ClusterRbacConfig, ServiceRole, dan ServiceRoleBinding telah dihapus bersama dengan implementasi kebijakan otorisasi baru. Disarankan untuk menggunakan objek AuthorizationPolicy sebagai gantinya.

Menggunakan kebijakan otorisasi, Istio dapat mengonfigurasi satu aplikasi untuk mengakses yang lain. Selain itu, tidak seperti kebijakan jaringan Kubernetes murni, ini bekerja di tingkat L7. Misalnya, untuk lalu lintas http, Anda dapat mengontrol metode dan jalur permintaan dengan halus.



Seperti yang kita lihat pada contoh sebelumnya, secara default, akses terbuka untuk semua pod di seluruh cluster.



Sekarang kita akan mencekal semua aktivitas di namespace default menggunakan file yaml ini:

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: deny-all
  namespace: default
spec:
  {}

Dan mari kita coba untuk mencapai layanan detail:

curl details:9080
RBAC: access denied

Hebat, sekarang permintaan kami gagal.



Sekarang, mari kita konfigurasikan akses sehingga hanya permintaan GET yang lewat dan hanya di sepanjang jalur / details, dan semua permintaan lainnya ditolak. Ada beberapa opsi untuk ini:

• Anda dapat mengonfigurasi permintaan itu dengan pass tajuk spesifik;
  
  
• Dengan akun layanan aplikasi;
  
  
• Dengan alamat IP keluar;
  
  
• Dengan namespace keluar;
  
  
• Dengan klaim dalam token JWT.
  
  

Hal termudah untuk dipertahankan adalah mengatur akses ke akun layanan aplikasi, karena tidak ada konfigurasi awal yang diperlukan untuk ini, karena aplikasi demo bookinfo sudah dilengkapi dengan akun layanan yang dibuat dan dimonitor.

Untuk menggunakan kebijakan otorisasi berdasarkan akun layanan, Anda harus mengaktifkan otentikasi mutual TLS.

Menyiapkan kebijakan akses baru:

apiVersion: "security.istio.io/v1beta1"
kind: "AuthorizationPolicy"
metadata:
  name: "details-viewer"
  namespace: default
spec:
  selector:
    matchLabels:
      app: details
  rules:
  - from:
    - source:
        principals: ["cluster.local/ns/default/sa/bookinfo-productpage"]
    to:
    - operation:
        methods: ["GET"]
        paths: ["/details/*"]

Dan kami mencoba menjangkau lagi:

root@productpage-v1-6b64c44d7c-2fpkc:/# curl details:9080/details/0
{"id":0,"author":"William Shakespeare","year":1595,"type":"paperback","pages":200,"publisher":"PublisherA","language":"English","ISBN-10":"1234567890","ISBN-13":"123-1234567890"}

Semuanya berfungsi. Mari kita coba metode dan cara lain:

root@productpage-v1-6b64c44d7c-2fpkc:/# curl -XPOST details:9080/details/0
RBAC: access denied
root@productpage-v1-6b64c44d7c-2fpkc:/# 
root@productpage-v1-6b64c44d7c-2fpkc:/# curl -XGET details:9080/ping
RBAC: access denied

Kesimpulan

Sebagai kesimpulan, saya perhatikan bahwa fitur yang dipertimbangkan hanya sebagian kecil dari apa yang Istio dapat lakukan. Out of the box, kami menerima dan mengkonfigurasi enkripsi dan otorisasi lalu lintas antar-layanan, meskipun dengan biaya menambahkan komponen tambahan dan, karenanya, konsumsi sumber daya tambahan. 



Terimakasih untuk semua!