🥇Kembali ke perkhidmatan mikro dengan Istio. Bahagian 3

Catatan. terjemah: Bahagian pertama siri ini dikhaskan untuk mengenali keupayaan Istio dan menunjukkannya dalam tindakan, kedua — penghalaan yang ditala halus dan pengurusan trafik rangkaian. Sekarang kita akan bercakap tentang keselamatan: untuk menunjukkan fungsi asas yang berkaitan dengannya, pengarang menggunakan perkhidmatan identiti Auth0, tetapi pembekal lain boleh dikonfigurasikan dengan cara yang sama.

Kami menyediakan kluster Kubernetes di mana kami menggunakan Istio dan contoh aplikasi perkhidmatan mikro, Analisis Sentimen, untuk menunjukkan keupayaan Istio.

Dengan Istio, kami dapat memastikan perkhidmatan kami kecil kerana mereka tidak perlu melaksanakan lapisan seperti Cuba Semula, Tamat Masa, Pemutus Litar, Pengesanan, Pemantauan. . Selain itu, kami menggunakan teknik ujian dan penggunaan lanjutan: ujian A/B, pencerminan dan pelancaran kenari.

Dalam bahan baharu, kami akan menangani lapisan terakhir pada laluan ke nilai perniagaan: pengesahan dan kebenaran - dan di Istio ia adalah keseronokan yang sebenar!

Pengesahan dan kebenaran dalam Istio

Saya tidak akan pernah percaya bahawa saya akan diilhamkan oleh pengesahan dan kebenaran. Apakah yang boleh ditawarkan oleh Istio daripada perspektif teknologi untuk menjadikan topik ini menyeronokkan dan, lebih-lebih lagi, memberi inspirasi kepada anda?

Jawapannya mudah: Istio mengalihkan tanggungjawab untuk keupayaan ini daripada perkhidmatan anda kepada proksi Utusan. Pada masa permintaan sampai ke perkhidmatan, mereka telah pun disahkan dan dibenarkan, jadi anda hanya perlu menulis kod yang berguna untuk perniagaan.

Kedengaran bagus? Mari lihat dalam!

Pengesahan dengan Auth0

Sebagai pelayan untuk pengurusan identiti dan akses, kami akan menggunakan Auth0, yang mempunyai versi percubaan, intuitif untuk digunakan dan saya sukakannya. Walau bagaimanapun, prinsip yang sama boleh digunakan untuk mana-mana yang lain pelaksanaan OpenID Connect: KeyCloak, IdentityServer dan banyak lagi.

Pertama, pergi ke Portal Auth0 dengan akaun anda, buat penyewa (penyewa - "penyewa", unit logik pengasingan, untuk butiran lanjut lihat dokumentasi - lebih kurang terjemah.) dan pergi ke Aplikasi > Apl Lalaimemilih domain, seperti yang ditunjukkan dalam tangkapan skrin di bawah:

Tentukan domain ini dalam fail resource-manifests/istio/security/auth-policy.yaml (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

Dengan sumber sedemikian, Pilot (salah satu daripada tiga komponen Satah Kawalan asas dalam Istio - lebih kurang transl.) mengkonfigurasi Utusan untuk mengesahkan permintaan sebelum memajukannya kepada perkhidmatan: sa-web-app и sa-feedback. Pada masa yang sama, konfigurasi tidak digunakan untuk perkhidmatan Utusan sa-frontend, membolehkan kami membiarkan bahagian hadapan tidak disahkan. Untuk menggunakan Dasar, jalankan arahan:

$ 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 bahawa ia berakhir dengan status 401 tidak dibenarkan. Sekarang mari kita ubah hala pengguna bahagian hadapan untuk mengesahkan dengan Auth0.

Mengesahkan permintaan dengan Auth0

Untuk mengesahkan permintaan pengguna akhir, anda perlu membuat API dalam Auth0 yang akan mewakili perkhidmatan yang disahkan (ulasan, butiran dan penilaian). Untuk membuat API, pergi ke Portal Auth0 > API > Cipta API dan isi borang:

Maklumat penting di sini ialah Pengecam, yang akan kami gunakan kemudian dalam skrip. Mari kita tuliskan seperti ini:

Penonton: {YOUR_AUDIENCE}

Butiran selebihnya yang kami perlukan terletak pada Portal Auth0 dalam bahagian tersebut Aplikasi - pilih Permohonan Ujian (dicipta secara automatik bersama-sama dengan API).

Di sini kami akan menulis:

domain: {DOMAIN_ANDA}
Id Pelanggan: {YOUR_CLIENT_ID}

Tatal ke Permohonan Ujian ke medan teks URL Panggilan Balik Dibenarkan (URL yang diselesaikan untuk panggilan balik), di mana kami menentukan URL tempat panggilan harus dihantar selepas pengesahan selesai. Dalam kes kami ialah:

http://{EXTERNAL_IP}/callback

Dan untuk URL Log Keluar Dibenarkan (URL yang dibenarkan untuk log keluar) tambah:

http://{EXTERNAL_IP}/logout

Mari kita beralih ke bahagian hadapan.

Kemas kini bahagian hadapan

Tukar kepada cawangan auth0 repositori [istio-mastery]. Dalam cawangan ini, kod bahagian hadapan ditukar untuk mengubah hala pengguna ke Auth0 untuk pengesahan dan menggunakan token JWT dalam permintaan kepada perkhidmatan lain. Yang terakhir ini dilaksanakan seperti 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 menukar bahagian hadapan untuk menggunakan data penyewa dalam Auth0, buka sa-frontend/src/services/Auth.js dan gantikan di dalamnya nilai yang kami tulis di atas (Auth.js):

const Config = {
    clientID: '{YOUR_CLIENT_ID}',
    domain:'{YOUR_DOMAIN}',
    audience: '{YOUR_AUDIENCE}',
    ingressIP: '{EXTERNAL_IP}' // Используется для редиректа после аутентификации
}

Permohonan sudah sedia. Tentukan ID Docker anda dalam arahan di bawah semasa membina 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

Cuba aplikasinya! Anda akan dialihkan ke Auth0, di mana anda perlu log masuk (atau mendaftar), selepas itu anda akan dihantar semula ke halaman dari mana permintaan yang telah disahkan akan dibuat. Jika anda mencuba arahan yang dinyatakan dalam bahagian pertama artikel dengan curl, anda akan mendapat kod tersebut 401 Kod Status, menandakan bahawa permintaan itu tidak dibenarkan.

Mari kita ambil langkah seterusnya - izinkan permintaan.

Keizinan dengan Auth0

Pengesahan membolehkan kami memahami siapa pengguna, tetapi kebenaran diperlukan untuk mengetahui apa yang mereka ada akses. Istio juga menawarkan alat untuk ini.

Sebagai contoh, mari kita buat dua kumpulan pengguna (lihat rajah di bawah):

Ahli (pengguna) — dengan akses hanya kepada perkhidmatan SA-WebApp dan SA-Frontend;
Moderator (moderator) — dengan akses kepada ketiga-tiga perkhidmatan.

Konsep kebenaran

Untuk membuat kumpulan ini, kami akan menggunakan sambungan Keizinan Auth0 dan menggunakan Istio untuk memberikan mereka tahap akses yang berbeza.

Pemasangan dan konfigurasi Auth0 Authorization

Dalam portal Auth0, pergi ke sambungan (Extensions) dan pasang Keizinan Auth0. Selepas pemasangan, pergi ke Sambungan Keizinan, dan di sana - ke konfigurasi penyewa dengan mengklik di bahagian atas sebelah kanan dan memilih pilihan menu yang sesuai (Konfigurasi). Aktifkan kumpulan (Kumpulan) dan klik pada butang terbitkan peraturan (Terbitkan peraturan).

Mencipta kumpulan

Dalam Sambungan Kebenaran pergi ke kumpulan dan buat kumpulan Moderators. Memandangkan kami akan menganggap semua pengguna yang disahkan sebagai pengguna biasa, tidak perlu membuat kumpulan tambahan untuk mereka.

Pilih kumpulan Moderators, Tekan Tambah Ahli, tambah akaun utama anda. Biarkan sesetengah pengguna tanpa sebarang kumpulan untuk memastikan mereka dinafikan akses. (Pengguna baharu boleh dibuat secara manual melalui Portal Auth0 > Pengguna > Cipta Pengguna.)

Tambahkan Tuntutan Kumpulan pada Token Akses

Pengguna telah ditambahkan pada kumpulan, tetapi maklumat ini juga mesti ditunjukkan dalam token akses. Untuk mematuhi OpenID Connect dan pada masa yang sama mengembalikan kumpulan yang kami perlukan, token itu perlu menambahnya sendiri tuntutan tersuai. Dilaksanakan melalui peraturan Auth0.

Untuk membuat peraturan, pergi ke Portal Auth0 ke peraturan, Tekan Buat Peraturan dan pilih peraturan kosong daripada templat.

Salin kod di bawah dan simpan sebagai peraturan baharu Tambah Tuntutan Kumpulan (namespacedGroup.js):

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

Nota: Kod ini mengambil kumpulan pengguna pertama yang ditakrifkan dalam Sambungan Kebenaran dan menambahkannya pada token akses sebagai tuntutan tersuai (di bawah ruang namanya, seperti yang dikehendaki oleh Auth0).

Kembali ke halaman peraturan dan pastikan anda mempunyai dua peraturan yang ditulis dalam susunan berikut:

sambungan-keizinan-0
Tambah Tuntutan Kumpulan

Tertib itu penting kerana medan kumpulan menerima peraturan secara tidak segerak sambungan-keizinan-0 dan selepas itu ia ditambah sebagai tuntutan oleh peraturan kedua. Hasilnya ialah token akses seperti ini:

{
 "https://sa.io/group": "Moderators",
 "iss": "https://sentiment-analysis.eu.auth0.com/",
 "sub": "google-oauth2|196405271625531691872"
 // [сокращено для наглядности]
}

Kini anda perlu mengkonfigurasi proksi Utusan untuk menyemak akses pengguna, yang mana kumpulan itu akan ditarik daripada tuntutan (https://sa.io/group) dalam token akses yang dikembalikan. Ini adalah topik untuk bahagian seterusnya artikel.

Konfigurasi kebenaran dalam Istio

Untuk kebenaran berfungsi, anda mesti mendayakan RBAC untuk Istio. Untuk melakukan ini, kami akan menggunakan 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 — dayakan RBAC hanya untuk perkhidmatan dan ruang nama yang disenaraikan dalam medan Inclusion;
2 — kami menyenaraikan senarai perkhidmatan kami.

Mari gunakan konfigurasi dengan arahan berikut:

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

Semua perkhidmatan kini memerlukan Kawalan Akses Berasaskan Peranan. Dengan kata lain, akses kepada semua perkhidmatan adalah dilarang dan akan menghasilkan tindak balas RBAC: access denied. Sekarang mari kita benarkan akses kepada pengguna yang dibenarkan.

Konfigurasi akses untuk pengguna biasa

Semua pengguna mesti mempunyai akses kepada perkhidmatan SA-Frontend dan SA-WebApp. Dilaksanakan menggunakan sumber Istio berikut:

Peranan Perkhidmatan — menentukan hak yang dimiliki oleh pengguna;
ServiceRoleBinding — menentukan milik siapa ServiceRole ini.

Bagi pengguna biasa kami akan membenarkan akses kepada perkhidmatan 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 selepas itu regular-user-binding gunakan ServiceRole kepada semua pelawat halaman (regular-user-service-role-binding.yaml):

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

Adakah "semua pengguna" bermakna pengguna yang tidak disahkan juga akan mempunyai akses kepada SA WebApp? Tidak, polisi akan menyemak kesahihan token JWT.

Mari gunakan 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 penyederhana

Untuk penyederhana, kami ingin mendayakan akses kepada semua perkhidmatan (mod-service-role.yaml):

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

Tetapi kami mahukan hak sedemikian hanya untuk pengguna yang token aksesnya mengandungi tuntutan https://sa.io/group dengan makna 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"

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

Disebabkan caching dalam utusan, ia mungkin mengambil masa beberapa minit untuk peraturan kebenaran berkuat kuasa. Anda kemudiannya boleh memastikan bahawa pengguna dan moderator mempunyai tahap akses yang berbeza.

Kesimpulan pada bahagian ini

Secara serius, adakah anda pernah melihat pendekatan yang lebih mudah, mudah, berskala dan selamat untuk pengesahan dan kebenaran?

Hanya tiga sumber Istio (RbacConfig, ServiceRole dan ServiceRoleBinding) diperlukan untuk mencapai kawalan terperinci ke atas pengesahan dan kebenaran akses pengguna akhir kepada perkhidmatan.

Di samping itu, kami telah menangani isu-isu ini daripada perkhidmatan utusan kami, mencapai:

mengurangkan jumlah kod generik yang mungkin mengandungi masalah keselamatan dan pepijat;
mengurangkan bilangan situasi bodoh di mana satu titik akhir ternyata boleh diakses dari luar dan terlupa untuk melaporkannya;
menghapuskan keperluan untuk mengemas kini semua perkhidmatan setiap kali peranan atau hak baharu ditambah;
bahawa perkhidmatan baharu kekal mudah, selamat dan pantas.

Output

Istio membolehkan pasukan memfokuskan sumber mereka pada tugas kritikal perniagaan tanpa menambah overhed pada perkhidmatan, mengembalikannya kepada status mikro.

Artikel itu (dalam tiga bahagian) menyediakan pengetahuan asas dan arahan praktikal sedia untuk bermula dengan Istio dalam projek sebenar.

Kembali ke perkhidmatan mikro dengan Istio. Bahagian 3