Geekly articles weekly

Kembali ke layanan microser dengan Istio. Bagian 3



Catatan perev. : Bagian pertama dari seri ini dikhususkan untuk memperkenalkan kemampuan Istio dan mendemonstrasikan mereka dalam aksi, yang kedua untuk perutean yang diatur dengan baik dan manajemen lalu lintas jaringan. Sekarang kita akan berbicara tentang keamanan: untuk menunjukkan fungsi dasar yang terkait dengannya, penulis menggunakan layanan identitas Auth0, tetapi penyedia lain dapat dikonfigurasikan secara analogi dengannya.

Kami membuat kluster Kubernetes di mana Istio dan aplikasi microservice Analisis Sentimen dikerahkan, yang merupakan cara Istio ditunjukkan.

Dengan menggunakan Istio, kami dapat menjaga layanan dalam ukuran kecil karena mereka tidak perlu menerapkan "lapisan" seperti retries, Retouts, Timeout, Pemutus Sirkuit, Pelacakan, Pemantauan . Selain itu, kami menggunakan pengujian lanjutan dan teknik penyebaran: pengujian A / B, mirroring dan peluncuran kenari.



Dalam materi baru, kita akan membahas lapisan terakhir dalam perjalanan ke nilai bisnis: otentikasi dan otorisasi - dan di Istio ini adalah kesenangan nyata!

Otentikasi dan Otorisasi dalam Istio


Saya tidak akan pernah percaya bahwa saya akan terinspirasi oleh otentikasi dan otorisasi. Apa yang secara teknologi dapat ditawarkan oleh Istio untuk membuat topik-topik ini menarik dan bahkan lebih menginspirasi Anda?

Jawabannya sederhana: Istio mentransfer tanggung jawab untuk fitur-fitur ini dari layanan Anda ke proxy Utusan. Pada saat permintaan mencapai layanan, mereka sudah dikonfirmasi dan disahkan, jadi Anda hanya perlu menulis kode yang berguna untuk bisnis.

Kedengarannya bagus? Ayo lihat ke dalam!

Otentikasi dengan Auth0


Kami akan menggunakan Auth0 sebagai server untuk identitas dan manajemen akses, yang memiliki versi percobaan, yang intuitif untuk digunakan dan saya hanya menyukainya. Namun, prinsip yang sama dapat diterapkan untuk implementasi OpenID Connect lainnya : KeyCloak, IdentityServer, dan banyak lainnya.

Pertama, pergi ke Portal Auth0 dengan akun Anda, buat penyewa (penyewa - "penyewa", unit isolasi logis, untuk lebih jelasnya lihat dokumentasi - kira-kira Transfer) dan buka Aplikasi> Aplikasi Default , pilih Domain , seperti yang ditunjukkan pada tangkapan layar di bawah ini :



Tentukan domain ini dalam file resource-manifests/istio/security/auth-policy.yaml sumber daya ( sumber ):

 apiVersion: authentication.istio.io/v1alpha1 kind: Policy metadata: name: auth-policy spec: targets: - name: sa-web-app - name: sa-feedback origins: - jwt: issuer: "https://{YOUR_DOMAIN}/" jwksUri: "https://{YOUR_DOMAIN}/.well-known/jwks.json" principalBinding: USE_ORIGIN

Memiliki sumber daya seperti itu, Pilot (salah satu dari tiga komponen dasar Control Plane di Istio - approx. Transl.) Mengkonfigurasi Utusan untuk mengotentikasi permintaan sebelum mengarahkan mereka ke layanan: sa-web-app dan sa-feedback . Pada saat yang sama, konfigurasi tidak berlaku untuk Utusan dari layanan sa-frontend , memungkinkan kita untuk membiarkan frontend tidak terauthentikasi. Untuk menerapkan kebijakan, jalankan perintah:

 $ kubectl apply -f resource-manifests/istio/security/auth-policy.yaml policy.authentication.istio.io โ€œauth-policyโ€ created

Kembali ke halaman dan buat permintaan - Anda akan melihat bahwa itu berakhir pada 401 Status tidak sah . Sekarang kami mengarahkan pengguna front-end ke otentikasi dengan Auth0.

Minta Otentikasi dengan Auth0


Untuk mengotentikasi permintaan pengguna akhir, Anda perlu membuat API di Auth0 yang akan mewakili layanan yang diautentikasi (ulasan, detail, dan peringkat). Untuk membuat API, buka Auth0 Portal> APIs> Buat API dan isi formulir:



Informasi penting di sini adalah Identifier , yang akan kita gunakan nanti dalam skrip. Mari kita tuliskan untuk diri kita sendiri seperti ini:

  • Pemirsa : {YOUR_AUDIENCE}

Rincian lainnya yang kami butuhkan ada di Portal Auth0 di bagian Aplikasi - pilih Aplikasi Uji (dibuat secara otomatis dengan API).

Di sini kami menulis:

  • Domain : {YOUR_DOMAIN}
  • Id Klien : {YOUR_CLIENT_ID}

Gulir dalam Aplikasi Tes ke kotak teks URL Panggilan Balik yang Diizinkan (URL yang diizinkan untuk panggilan balik), di mana kami menunjukkan URL tempat panggilan harus dikirim setelah otentikasi selesai. Dalam kasus kami, itu adalah:

 http://{EXTERNAL_IP}/callback

Dan untuk URL Logout yang Diizinkan (URL yang diizinkan untuk keluar), tambahkan:

 http://{EXTERNAL_IP}/logout

Mari kita beralih ke frontend.

Pembaruan Frontend


Beralih ke cabang auth0 dari [istio-mastery] . Di utas ini, kode front-end diubah untuk mengarahkan pengguna ke Auth0 untuk otentikasi dan menggunakan token JWT dalam permintaan untuk layanan lain. Yang terakhir diimplementasikan sebagai berikut ( App.js ):

 analyzeSentence() { fetch('/sentiment', { method: 'POST', headers: { 'Content-Type': 'application/json', 'Authorization': `Bearer ${auth.getAccessToken()}` // Access Token }, body: JSON.stringify({ sentence: this.textField.getValue() }) }) .then(response => response.json()) .then(data => this.setState(data)); }

Untuk mengonversi frontend untuk menggunakan data tenant di Auth0, buka sa-frontend/src/services/Auth.js dan ganti nilai yang kami tulis di atas ( Auth.js ) di dalamnya:

 const Config = { clientID: '{YOUR_CLIENT_ID}', domain:'{YOUR_DOMAIN}', audience: '{YOUR_AUDIENCE}', ingressIP: '{EXTERNAL_IP}' //      }

Aplikasi sudah siap. Tunjukkan ID Docker Anda dalam perintah di bawah ini saat membuat dan menggunakan perubahan yang dibuat:

 $ docker build -f sa-frontend/Dockerfile \ -t $DOCKER_USER_ID/sentiment-analysis-frontend:istio-auth0 \ sa-frontend $ docker push $DOCKER_USER_ID/sentiment-analysis-frontend:istio-auth0 $ kubectl set image deployment/sa-frontend \ sa-frontend=$DOCKER_USER_ID/sentiment-analysis-frontend:istio-auth0

Coba aplikasinya! Anda akan dialihkan ke Auth0, di mana Anda harus masuk (atau mendaftar), setelah itu Anda akan dikirim kembali ke halaman dari mana permintaan yang sudah dikonfirmasi akan dibuat. Jika Anda mencoba perintah ikal yang disebutkan di bagian pertama artikel, Anda akan menerima Kode Status 401 , yang menunjukkan bahwa permintaan tersebut tidak diotorisasi.

Mari kita mengambil langkah selanjutnya - otorisasi permintaan.

Otorisasi dengan Auth0


Otentikasi memungkinkan kita untuk memahami siapa pengguna itu, tetapi untuk mengetahui apa yang dia miliki akses, diperlukan otorisasi. Istio juga menawarkan alat untuk ini.

Sebagai contoh, kami akan membuat dua grup pengguna (lihat diagram di bawah):

  • Pengguna (pengguna) - dengan akses hanya ke layanan SA-WebApp dan SA-Frontend;
  • Moderator - dengan akses ke ketiga layanan.


Konsep otorisasi

Untuk membuat grup ini, kami akan menggunakan ekstensi Auth0 Authorization dan menggunakan Istio untuk memberi mereka tingkat akses yang berbeda.

Instalasi dan konfigurasi Otorisasi Auth0


Pada portal Auth0, buka Extensions dan instal Auth0 Authorization . Setelah instalasi, buka Ekstensi Otorisasi , dan di sana - ke konfigurasi penyewa dengan mengklik di kanan atas dan memilih opsi menu yang sesuai (Konfigurasi) . Aktifkan Grup dan klik tombol Terbitkan aturan .



Pembuatan grup


Di Ekstensi Otorisasi, buka Grup dan buat grup Moderator . Karena kami akan menganggap semua pengguna yang diautentikasi sebagai biasa, tidak perlu membuat grup tambahan untuk mereka.

Pilih grup Moderator , klik Tambah Anggota , tambahkan akun utama Anda. Tinggalkan beberapa pengguna tanpa grup apa pun untuk memastikan bahwa akses ditolak untuk mereka. (Pengguna baru dapat dibuat secara manual melalui Portal Auth0> Pengguna> Buat Pengguna .)

Tambahkan Klaim Grup untuk Mengakses Token


Pengguna ditambahkan ke grup, tetapi informasi ini harus tercermin dalam token akses. Untuk mematuhi OpenID Connect dan pada saat yang sama mengembalikan grup yang kita butuhkan, token perlu menambahkan klaim khusus . Ini diimplementasikan melalui aturan Auth0.

Untuk membuat aturan, buka Auth0 Portal to Rules , klik Buat Aturan dan pilih aturan kosong dari templat.



Salin kode di bawah ini dan simpan sebagai aturan Tambah Klaim Grup baru ( namespacedGroup.js ):

 function (user, context, callback) { context.accessToken['https://sa.io/group'] = user.groups[0]; return callback(null, user, context); }

Catatan : kode ini mengambil grup pengguna pertama yang ditentukan dalam Ekstensi Otorisasi dan menambahkannya ke token akses sebagai klaim khusus (di bawah namespace-nya, seperti yang disyaratkan oleh Auth0).

Kembali ke halaman Aturan dan verifikasi bahwa Anda memiliki dua aturan yang ditulis dalam urutan berikut:

  • auth0-otorisasi-ekstensi
  • Tambahkan Klaim Grup

Urutan ini penting karena bidang grup secara asinkron menerima aturan auth0-authorization-extension dan kemudian ditambahkan sebagai klaim oleh aturan kedua. Hasilnya adalah token akses seperti itu:

 { "https://sa.io/group": "Moderators", "iss": "https://sentiment-analysis.eu.auth0.com/", "sub": "google-oauth2|196405271625531691872" // [  ] }

Sekarang Anda perlu mengonfigurasi proxy Utusan untuk memeriksa akses pengguna, di mana grup tersebut akan ditarik dari klaim ( https://sa.io/group ) di token akses yang dikembalikan. Ini adalah topik untuk bagian artikel selanjutnya.

Konfigurasi otorisasi Istio


Agar otorisasi berfungsi, Anda harus mengaktifkan RBAC untuk Istio. Untuk melakukan ini, gunakan konfigurasi berikut:

 apiVersion: "rbac.istio.io/v1alpha1" kind: RbacConfig metadata: name: default spec: mode: 'ON_WITH_INCLUSION' # 1 inclusion: services: # 2 - "sa-frontend.default.svc.cluster.local" - "sa-web-app.default.svc.cluster.local" - "sa-feedback.default.svc.cluster.local"

Penjelasan:
  • 1 - aktifkan RBAC hanya untuk layanan dan ruang nama yang terdaftar di bidang Inclusion ;
  • 2 - daftar daftar layanan kami.


Kami menerapkan konfigurasi dengan perintah ini:

 $ kubectl apply -f resource-manifests/istio/security/enable-rbac.yaml rbacconfig.rbac.istio.io/default created

Sekarang semua layanan memerlukan Kontrol Akses Berbasis Peran. Dengan kata lain, akses ke semua layanan ditolak dan akan menghasilkan respons RBAC: access denied . Sekarang izinkan akses ke pengguna yang berwenang.

Konfigurasi akses untuk pengguna biasa


Semua pengguna harus memiliki akses ke layanan SA-Frontend dan SA-WebApp. Diimplementasikan menggunakan sumber daya Istio berikut:

  • ServiceRole - mendefinisikan hak yang dimiliki pengguna;
  • ServiceRoleBinding - Menentukan milik siapa ServiceRole ini.

Untuk pengguna biasa, izinkan akses ke layanan tertentu ( servicerole.yaml ):

 apiVersion: "rbac.istio.io/v1alpha1" kind: ServiceRole metadata: name: regular-user namespace: default spec: rules: - services: - "sa-frontend.default.svc.cluster.local" - "sa-web-app.default.svc.cluster.local" paths: ["*"] methods: ["*"]

Dan melalui regular-user-binding terapkan Peran Layanan untuk semua pengunjung ke halaman ( regular-user-binding -peran-layanan-pengguna reguler.yaml ):

 apiVersion: "rbac.istio.io/v1alpha1" kind: ServiceRoleBinding metadata: name: regular-user-binding namespace: default spec: subjects: - user: "*" roleRef: kind: ServiceRole name: "regular-user"

Apakah "semua pengguna" berarti bahwa pengguna yang tidak diauthentikasi akan mendapatkan akses ke SA WebApp? Tidak, kebijakan akan memverifikasi validitas token JWT.

Terapkan konfigurasi:

 $ kubectl apply -f resource-manifests/istio/security/user-role.yaml servicerole.rbac.istio.io/regular-user created servicerolebinding.rbac.istio.io/regular-user-binding created

Konfigurasi akses untuk moderator


Untuk moderator, kami ingin mengaktifkan akses ke semua layanan ( mod-service-role.yaml ):

 apiVersion: "rbac.istio.io/v1alpha1" kind: ServiceRole metadata: name: mod-user namespace: default spec: rules: - services: ["*"] paths: ["*"] methods: ["*"]

Tetapi kami menginginkan hak tersebut hanya untuk pengguna yang token aksesnya memiliki klaim https://sa.io/group dengan nilai Moderators ( mod-service-role-binding.yaml ):

 apiVersion: "rbac.istio.io/v1alpha1" kind: ServiceRoleBinding metadata: name: mod-user-binding namespace: default spec: subjects: - properties: request.auth.claims[https://sa.io/group]: "Moderators" roleRef: kind: ServiceRole name: "mod-user"

Terapkan konfigurasi:

 $ kubectl apply -f resource-manifests/istio/security/mod-role.yaml servicerole.rbac.istio.io/mod-user created servicerolebinding.rbac.istio.io/mod-user-binding created

Karena caching di utusan, mungkin diperlukan beberapa menit untuk menerapkan aturan otorisasi. Setelah itu, Anda dapat memastikan bahwa pengguna dan moderator memiliki tingkat akses yang berbeda.

Kesimpulan bagian ini


Nah, serius: apakah Anda pernah melihat pendekatan yang lebih sederhana, mudah, terukur, dan aman untuk otentikasi dan otorisasi?

Hanya tiga sumber daya Istio (RbacConfig, ServiceRole, dan ServiceRoleBinding) yang diperlukan untuk mencapai kontrol yang baik atas otentikasi dan otorisasi akses pengguna akhir ke layanan.

Selain itu, kami menangani masalah ini dari layanan kami di utusan, mencapai:

  • Mengurangi jumlah kode sampel yang mungkin termasuk masalah keamanan dan bug;
  • mengurangi jumlah situasi bodoh di mana satu titik akhir ternyata dapat diakses dari luar dan lupa melaporkannya;
  • menghilangkan kebutuhan untuk memperbarui semua layanan setiap kali peran atau hak baru ditambahkan;
  • bahwa layanan baru tetap sederhana, aman dan cepat.

Kesimpulan


Istio memungkinkan tim untuk memfokuskan sumber daya mereka pada tugas-tugas penting bisnis tanpa menambahkan overhead ke layanan, mengembalikannya ke status mikro.

Artikel (dalam tiga bagian) memberikan pengetahuan dasar dan instruksi praktis siap pakai untuk memulai bekerja dengan Istio dalam proyek nyata.

PS dari penerjemah


Baca juga di blog kami:

Source: https://habr.com/ru/post/id443668/

More articles:


All Articles