Service Mesh (ASM) mendukung otorisasi eksternal yang mendelegasikan keputusan kontrol akses ke layanan gRPC kustom yang Anda sebarkan dan kelola. Fitur ini berguna ketika kebijakan otorisasi bawaan tidak memenuhi kebutuhan Anda—misalnya, saat mengintegrasikan dengan sistem autentikasi internal atau menerapkan aturan bisnis khusus.
Tutorial ini menyebarkan layanan otorisasi gRPC contoh, mendaftarkannya ke ASM, membuat kebijakan otorisasi, dan memverifikasi alur end-to-end. Layanan contoh ini mengizinkan permintaan yang menyertakan header x-ext-authz: allow dan menolak semua permintaan lainnya.
Cara kerja
Saat Anda mengaktifkan otorisasi eksternal di ASM, alur permintaan bekerja sebagai berikut:
Klien mengirim permintaan ke layanan target (misalnya, httpbin).
Proxy sidecar mencegat permintaan tersebut dan mengirim permintaan pemeriksaan otorisasi ke layanan gRPC eksternal Anda.
Layanan eksternal mengevaluasi permintaan dan mengembalikan keputusan izinkan atau tolak.
Jika diizinkan, permintaan dilanjutkan ke layanan target. Jika ditolak, proxy segera mengembalikan error ke klien.
Pemeriksaan otorisasi hanya dipicu untuk permintaan yang sesuai dengan aturan yang didefinisikan dalam kebijakan otorisasi Anda. Permintaan ke path atau layanan yang tidak tercakup oleh kebijakan akan dilewatkan tanpa pemeriksaan eksternal.
Prasyarat
Sebelum memulai, pastikan Anda telah memiliki:
Kluster Container Service for Kubernetes (ACK) yang ditambahkan ke instans ASM Anda. Untuk informasi lebih lanjut, lihat Tambahkan kluster ke instans ASM.
kubectl yang telah dikonfigurasi untuk terhubung ke kluster ACK Anda. Untuk informasi lebih lanjut, lihat Dapatkan file kubeconfig kluster dan gunakan kubectl untuk terhubung ke kluster.
Langkah 1: Sebarkan layanan otorisasi eksternal
Sebarkan layanan otorisasi berbasis gRPC di kluster ACK Anda. Layanan ini mengimplementasikan API Envoy ext_authz dan menangani pemeriksaan otorisasi untuk permintaan masuk.
Layanan contoh yang digunakan di sini mengizinkan permintaan yang membawa header x-ext-authz: allow dan menolak semua permintaan lainnya. Gunakan contoh ini apa adanya atau sesuaikan dengan logika Anda sendiri. Kode sumber tersedia di GitHub.
Buat file bernama ext-authz.yaml dengan konten berikut:
Layanan ini mengekspos dua port: HTTP pada port 8000 dan gRPC pada port 9000. Tutorial ini menggunakan port gRPC (9000).
Sebarkan layanan tersebut:
kubectl apply -f ext-authz.yamlOutput yang diharapkan:
service/ext-authz created deployment.apps/ext-authz createdVerifikasi bahwa layanan sedang berjalan:
kubectl logs "$(kubectl get pod -l app=ext-authz -n default -o jsonpath={.items..metadata.name})" -n default -c ext-authzOutput yang diharapkan:
2023/12/20 08:15:39 Starting gRPC server at [::]:9000 2023/12/20 08:15:39 Starting HTTP server at [::]:8000Server gRPC dan HTTP keduanya harus berjalan. Jika tidak ada output, tunggu beberapa detik hingga pod dimulai dan coba lagi.
Konfirmasi port gRPC untuk layanan ext-authz:
Masuk ke Konsol ACK. Di panel navigasi kiri, klik Clusters.
Di halaman Clusters, temukan kluster dan klik namanya. Di panel kiri, pilih Network > Services.
Di halaman Services, klik ext-authz.
Di bagian Endpoint, port gRPC ditampilkan. Dalam contoh ini, port tersebut adalah 9000.
Langkah 2: Sebarkan aplikasi contoh
Sebarkan aplikasi httpbin dan sleep. httpbin berfungsi sebagai layanan target yang menerima permintaan, sedangkan sleep berfungsi sebagai klien yang mengirim permintaan.
Buat file bernama httpbin.yaml dengan konten berikut:
Sebarkan httpbin:
kubectl apply -f httpbin.yamlBuat file bernama sleep.yaml dengan konten berikut:
Deploy sleep:
kubectl apply -f sleep.yaml
Langkah 3: Daftarkan layanan otorisasi eksternal di ASM
Daftarkan layanan ext-authz yang disebarkan pada Langkah 1 sebagai penyedia otorisasi kustom di instans ASM Anda. Hal ini memberi tahu lapisan kontrol mesh ke mana harus mengarahkan pemeriksaan otorisasi.
Masuk ke Konsol ASM. Di panel navigasi kiri, pilih Service Mesh > Mesh Management.
Pada halaman Mesh Management, klik nama instance ASM Anda. Di panel navigasi sebelah kiri, pilih Mesh Security Center > Custom Authorization Service, lalu klik Define Custom Authorization Service.
Di halaman Register Custom Authorization Service, klik tab Custom authorization service (HTTP or gRPC protocol) implemented based on envoy.ext_authz. Konfigurasikan parameter berikut dan klik Create.
Parameter wajib
Parameter Deskripsi Nilai contoh Protocol Protokol yang digunakan oleh layanan otorisasi. GRPC Name Nama untuk pendaftaran layanan otorisasi ini. testService Address Titik akhir layanan dalam format <Service name>.<Namespace>.svc.<Cluster domain>.ext-authz.default.svc.cluster.localPort(1 - 65535) Port gRPC dari layanan otorisasi. 9000Timeout(second) Waktu maksimum menunggu respons otorisasi. Jika layanan tidak merespons dalam periode ini, permintaan dianggap tidak sah (kecuali jika Anda mengaktifkan opsi skip di bawah). 10Parameter opsional
Parameter Deskripsi Skip authentication while authorization service is unavailable Jika diaktifkan, permintaan diizinkan jika layanan otorisasi tidak dapat dijangkau. Jika dinonaktifkan, permintaan ditolak. Error code returned by asm proxy while Auth-Service is not available Kode error HTTP kustom yang dikembalikan kepada pemanggil saat layanan otorisasi tidak tersedia. Hanya tersedia jika Skip authentication while authorization service is unavailable dinonaktifkan. Carry origin request body within auth request Jika diaktifkan, badan permintaan asli diteruskan ke layanan otorisasi. Tetapkan panjang maksimum badan. Jika Allow send incomplete message to Auth-Service juga diaktifkan, badan yang melebihi panjang maksimum akan dipotong, bukan ditolak.
Langkah 4: Buat kebijakan otorisasi
Buat kebijakan otorisasi untuk menentukan permintaan mana yang memerlukan pemeriksaan otorisasi eksternal.
Masuk ke Konsol ASM. Di panel navigasi kiri, pilih Service Mesh > Mesh Management.
Di halaman Mesh Management, klik nama instans ASM Anda. Di panel navigasi kiri, pilih Mesh Security Center > AuthorizationPolicy. Klik Create.
Di halaman Create, konfigurasikan parameter berikut dan klik Create.
Parameter Deskripsi Nilai contoh Name Nama untuk kebijakan otorisasi. test1Policy Type Jenis kebijakan otorisasi. Custom Authorization Service Custom Authorization Service Layanan otorisasi eksternal yang akan digunakan. grpcextauth-test(GRPC) Namespace Namespace tempat kebijakan berlaku. Atur di tab Workload Scope. defaultEffective Scope Apakah kebijakan berlaku untuk layanan tertentu atau seluruh namespace. Service Workload Beban kerja target untuk kebijakan ini. httpbinRequest Matching Rules Kondisi permintaan yang memicu pemeriksaan otorisasi. Aktifkan Paths di bagian Add Request Target. /headersDengan konfigurasi ini, hanya permintaan ke path
/headerspada layanan httpbin yang menjalani pemeriksaan otorisasi eksternal. Permintaan ke path lain (seperti/ip) tidak terpengaruh.
Langkah 5: Verifikasi alur otorisasi
Uji pengaturan dengan mengirim permintaan dari pod sleep ke layanan httpbin. Tiga skenario berikut mengonfirmasi bahwa otorisasi berfungsi dengan benar.
Skenario 1: Permintaan ke path yang tidak dilindungi
Kirim permintaan ke /ip, yang tidak tercakup oleh kebijakan otorisasi:
kubectl exec "$(kubectl get pod -l app=sleep -n default -o jsonpath={.items..metadata.name})" -c sleep -n default -- curl "http://httpbin.default:8000/ip" -s -o /dev/null -w "%{http_code}\n"Output yang diharapkan:
200Kode status 200 mengonfirmasi bahwa pemeriksaan otorisasi eksternal tidak dipicu untuk path ini.
Skenario 2: Permintaan ditolak oleh layanan otorisasi
Kirim permintaan ke /headers dengan header x-ext-authz: deny:
kubectl exec "$(kubectl get pod -l app=sleep -n default -o jsonpath={.items..metadata.name})" -c sleep -n default -- curl "http://httpbin.default:8000/headers" -H "x-ext-authz: deny" -sOutput yang diharapkan:
denied by ext_authz for not found header `x-ext-authz: allow` in the requestPermintaan mencapai layanan otorisasi eksternal, tetapi layanan tersebut menolaknya karena header x-ext-authz: allow yang diperlukan tidak ada.
Skenario 3: Permintaan diizinkan oleh layanan otorisasi
Kirim permintaan ke /headers dengan header x-ext-authz: allow:
kubectl exec "$(kubectl get pod -l app=sleep -n default -o jsonpath={.items..metadata.name})" -c sleep -n default -- curl "http://httpbin.default:8000/headers" -H "x-ext-authz: allow" -sOutput yang diharapkan:
{
"headers": {
"Accept": "*/*",
"Host": "httpbin.default:8000",
"User-Agent": "curl/8.5.0",
"X-Envoy-Attempt-Count": "1",
"X-Ext-Authz": "allow",
"X-Ext-Authz-Check-Result": "allowed",
"X-Forwarded-Client-Cert": "By=spiffe://cluster.local/ns/default/sa/httpbin;Hash=c3e5364e87add0f4f69e6b0d029f5961b404c8f209bf9004b3d21a82cf67****;Subject=\"\";URI=spiffe://cluster.local/ns/default/sa/sleep"
}
}Header X-Ext-Authz-Check-Result: allowed dalam respons mengonfirmasi bahwa layanan otorisasi menyetujui permintaan tersebut. Respons ini juga menyertakan identitas SPIFFE dari klien (sleep) dan server (httpbin), yang menunjukkan bahwa mutual TLS aktif antara layanan-layanan tersebut.
Ketiga skenario ini mengonfirmasi bahwa kebijakan otorisasi berfungsi sesuai harapan: hanya permintaan ke /headers dengan header x-ext-authz: allow yang diizinkan.