Mengonfigurasi autentikasi pengguna Cloud Service Mesh
Autentikasi pengguna Cloud Service Mesh adalah solusi terintegrasi untuk autentikasi pengguna akhir berbasis browser dan kontrol akses ke beban kerja yang di-deploy. Fitur ini memungkinkan Anda berintegrasi dengan Penyedia Identitas (IdP) yang ada untuk autentikasi pengguna dan menggunakan API Istio dan kebijakan otorisasi untuk pengelolaan akses. Ini adalah alternatif yang mudah digunakan untuk autentikasi Token Web JSON (JWT) Istio.
Kasus penggunaan yang umum adalah saat organisasi menggunakan Cloud Service Mesh untuk menghosting aplikasi web agar dapat diakses oleh tenaga kerjanya melalui browser web. Selain itu, organisasi harus menggunakan penyedia identitas yang ada untuk mengelola identitas pengguna. Autentikasi pengguna Cloud Service Mesh memudahkan pengguna untuk melakukan autentikasi menggunakan alur izin dan login OpenID Connect (OIDC) berbasis web standar. Saat pengguna melakukan autentikasi, Cloud Service Mesh akan menerapkan kebijakan otorisasi Istio, dan setelah otorisasi berhasil, Cloud Service Mesh akan mengirimkan identitas ke workload dalam format kredensial yang aman.
Cara kerjanya
Autentikasi pengguna Cloud Service Mesh memperkenalkan komponen baru, authservice
.
Komponen ini terintegrasi dengan ingress berbasis Envoy sebagai layanan otorisasi eksternal yang mencegat semua permintaan masuk untuk autentikasi. authservice
menerapkan sisi klien protokol OIDC
dan memungkinkan akses pengguna ke aplikasi melalui browser, tempat pengguna menyelesaikan
alur autentikasi dan izin interaktif untuk membuat sesi berumur pendek.
authservice
menerapkan protokol standar industri untuk berintegrasi dengan penyedia identitas apa pun yang dapat bertindak sebagai server otorisasi OIDC. Saat pengguna
diautentikasi, informasi akun utama dienkapsulasi dalam RCToken
dalam format JWT, ditandatangani oleh authservice
yang diteruskan ke lapisan otorisasi
Istio di ingress. Model ini menyediakan kontrol akses perimeter untuk traffic
ke dalam mesh. Jika pengguna diberi otorisasi untuk mengakses resource, RCToken ini juga diteruskan ke microservice untuk mendapatkan informasi akun utama dan menerapkan kontrol akses terperinci.
Diagram berikut menunjukkan lokasi authservice
dalam mesh dan hubungannya
dengan bagian mesh lainnya, seperti ingress, beban kerja, browser
pengguna, dan IDP yang ada.
Administrator dapat menginstal authservice
sebagai add-on melalui penginstalan Cloud Service Mesh. Saat diinstal, authservice
membaca konfigurasi endpoint OIDC
dan setelan terkait lainnya yang ditentukan dalam resource kustom
UserAuth
. Administrator dapat menggunakan Cloud Service Mesh ExternalAuthorization
API
untuk mengonfigurasi auth_server
sebagai filter di ingress.
Menginstal layanan autentikasi pengguna
Langkah-langkah berikut menjelaskan cara mengonfigurasi authservice
.
Prasyarat
Ikuti langkah-langkah di bagian Menginstal alat dependen dan memvalidasi cluster untuk:- Menginstal alat yang diperlukan
- Download
asmcli
- Memberikan izin admin cluster
- Memvalidasi project dan cluster Anda
Jika Anda menggunakan Cloud Service Mesh terkelola di cluster pribadi, pastikan cluster tersebut dapat mengirim traffic keluar ke IDP.
Dapatkan paket
kpt
:kpt pkg get https://github.com/GoogleCloudPlatform/asm-user-auth.git/@v1.2.3 . cd asm-user-auth/
Perintah ini mengambil paket kpt dengan konfigurasi
authservice
yang direkomendasikan dari repositori publik. Paket berisi manifes untuk men-deploy penampungauthservice
sebagai Pod di namespaceasm-user-auth
. Langkah ini juga mengonfigurasi gateway traffic masuk agar memerlukan otorisasi untuk semua permintaan.
Mengonfigurasi penyedia otorisasi eksternal dan men-deploy gateway traffic masuk
Untuk menginstal layanan autentikasi pengguna, Anda akan menyesuaikan penginstalan Cloud Service Mesh untuk menambahkan penyedia otorisasi eksternal. Langkah-langkah yang diperlukan bergantung pada apakah Anda menggunakan Cloud Service Mesh terkelola atau dalam cluster.
Terkelola
Update konfigurasi mesh di ConfigMap Istio untuk menambahkan penyedia otorisasi eksternal. Dalam perintah berikut, gunakan
REVISION_LABEL
yang sama dengan yang Anda gunakan saat menyediakan Cloud Service Mesh terkelola (seperti,asm-managed
,asm-managed-rapid
, atauasm-managed-stable
):kubectl edit configmap istio-REVISION_LABEL -n istio-system
Tambahkan penyedia ekstensi di kolom
mesh
:mesh: |- ... extensionProviders: - name: "asm-userauth-grpc" envoyExtAuthzGrpc: service: "authservice.asm-user-auth.svc.cluster.local" port: "10003"
Buat dan beri label pada namespace
asm-user-auth
.kubectl create namespace asm-user-auth kubectl label namespace asm-user-auth istio.io/rev=REVISION_LABEL --overwrite
Instal gateway traffic masuk di namespace
asm-user-auth
.kubectl apply -n asm-user-auth -f DIR_PATH/samples/gateways/istio-ingressgateway
Dalam cluster
Dapatkan contoh overlay autentikasi pengguna dan perbarui jika ada penyesuaian di mesh Anda. Sebaiknya pertahankan file overlay ini di kontrol sumber Anda.
curl https://raw.githubusercontent.com/GoogleCloudPlatform/asm-user-auth/v1.2.3/overlay/user-auth-overlay.yaml > user-auth-overlay.yaml
Ikuti menginstal Cloud Service Mesh dengan overlay untuk menggunakan skrip yang disediakan Google guna menginstal Cloud Service Mesh dengan overlay autentikasi pengguna. Contoh:
./asmcli install \ --project_id PROJECT_ID \ --cluster_name CLUSTER_NAME \ --cluster_location CLUSTER_LOCATION \ --fleet_id FLEET_PROJECT_ID \ --output_dir DIR_PATH \ --enable_all \ --custom_overlay user-auth-overlay.yaml
Paket
kpt
autentikasi pengguna membuatAuthorizationPolicy
untuk mereferensikan penyedia otorisasi eksternal yang ditentukan olehpkg/ext-authz.yaml
.Buat dan beri label namespace
asm-user-auth
.kubectl create namespace asm-user-auth kubectl label namespace asm-user-auth istio.io/rev=REVISION --overwrite
Anda dapat menemukan nilai label
REVISION
dengan memeriksakubectl get pod -n istio-system -L istio.io/rev
Instal gateway Istio di namespace
asm-user-auth
.kubectl apply -n asm-user-auth -f DIR_PATH/samples/gateways/istio-ingressgateway
Menyiapkan konfigurasi klien OIDC
Tetapkan konfigurasi klien OIDC Anda menggunakan langkah-langkah berikut. Panduan ini menggunakan Google sebagai IdP, tetapi Anda dapat menggunakan IdP apa pun yang mendukung autentikasi OIDC.
Di konsol Google Cloud, buka API & Services > Credentials.
Buka Create Credentials, lalu pilih OAuth client ID. Jika diperlukan, tetapkan opsi Layar izin OAuth, lalu konfigurasikan opsi berikut:
- Tetapkan Application type ke Web application.
- Tetapkan Authorized redirect URI ke
https://REDIRECT_HOST/REDIRECT_PATH
. Misalnya, untuk localhost, Anda dapat menetapkan kehttps://localhost:8443/_gcp_asm_authenticate
.
Selanjutnya, klik Save.
Selain itu, simpan konfigurasi klien OIDC untuk digunakan nanti.
export OIDC_CLIENT_ID=CLIENT_ID export OIDC_CLIENT_SECRET=CLIENT_SECRET export OIDC_ISSUER_URI=ISSUER_URI export OIDC_REDIRECT_HOST=REDIRECT_HOST export OIDC_REDIRECT_PATH=REDIRECT_PATH
Menetapkan URL pengalihan dan secret untuk gateway masuk
OAuth2
memerlukan URL pengalihan yang dihosting di endpoint yang dilindungi HTTPS. Perintah
ini adalah contoh dan menyederhanakan penyiapan dengan membuat sertifikat
yang ditandatangani sendiri untuk gateway traffic masuk Istio.
Buat sertifikat yang ditandatangani sendiri:
openssl req -x509 -newkey rsa:4096 -keyout key.pem -out cert.pem \ -days 365 -nodes -subj '/CN=localhost'
Buat secret untuk gateway masuk guna menghosting traffic HTTPS:
kubectl create -n asm-user-auth secret tls userauth-tls-cert --key=key.pem \ --cert=cert.pem
Menerapkan kunci enkripsi dan penandatanganan
authservice
memerlukan dua kumpulan kunci agar dapat beroperasi dengan sukses. Yang pertama adalah
kunci simetris untuk enkripsi dan dekripsi. Kunci ini digunakan untuk mengenkripsi
status sesi sebelum menetapkannya sebagai cookie.
Kumpulan kunci kedua adalah pasangan kunci publik/pribadi. Kunci ini digunakan untuk menandatangani informasi pengguna terautentikasi dalam format JWT sebagai RCToken. Kunci publik dari pasangan ini dipublikasikan di endpoint standar yang dapat digunakan sidecar untuk memvalidasi JWT.
Paket kpt
autentikasi pengguna berisi dua contoh kunci untuk penyiapan cepat.
Namun, Anda dapat menggunakan sistem pengelolaan kunci pilihan Anda untuk membuat kunci ini.
Siapkan kunci enkripsi sesi dengan format berikut atau gunakan contoh dari pkg, yang dapat Anda lihat dengan
cat ./samples/cookie_encryption_key.json
.{ "keys":[ { "kty":"oct", "kid":"key-0", "k":"YOUR_AES_KEY", "useAfter": 1612813735 } ] }
Anda dapat membuat kunci AES pengujian dengan perintah berikut:
openssl rand -base64 32
Siapkan kunci penandatanganan RCToken dengan format berikut atau gunakan contoh dari pkg, yang dapat Anda lihat dengan
cat ./samples/rctoken_signing_key.json
.{ "keys":[ { "kty":"RSA", "kid":"rsa-signing-key", "k":"YOUR_AES_KEY", # k contains a Base64 encoded PEM format RSA signing key. "useAfter": 1612813735 # unix timestamp } ] }
Anda dapat membuat kunci pribadi RSA 256-bit pengujian dengan perintah berikut:
openssl genpkey -algorithm RSA -out rsa_private.pem -pkeyopt rsa_keygen_bits:256
Buat secret kubernetes, yang akan dipasang
authservice
ke dalam sistem filenya sendiri.kubectl create secret generic secret-key \ --from-file="session_cookie.key"="./samples/cookie_encryption_key.json" \ --from-file="rctoken.key"="./samples/rctoken_signing_key.json" \ --namespace=asm-user-auth
Men-deploy layanan autentikasi pengguna
Perintah berikut membuat Layanan dan Deployment autentikasi pengguna di
namespace asm-user-auth
.
Tetapkan nilai yang diperlukan untuk konfigurasi Autentikasi Pengguna. Client ID dan secret disimpan sebagai secret Kubernetes, jadi kita menggunakan Base64 untuk mengenkodenya. Buka repositori publik untuk melihat semua penyetel yang tersedia.
kpt fn eval pkg --image gcr.io/kpt-fn/apply-setters:v0.2 --truncate-output=false -- \
client-id="$(echo -n ${OIDC_CLIENT_ID} | base64 -w0)" \
client-secret="$(echo -n ${OIDC_CLIENT_SECRET} | base64 -w0)" \
issuer-uri="${OIDC_ISSUER_URI}" \
redirect-host="${OIDC_REDIRECT_HOST}" \
redirect-path="${OIDC_REDIRECT_PATH}"
Terapkan paket kpt
:
# Remove the potential alpha version CRD if exists.
kubectl delete crd userauthconfigs.security.anthos.io
kubectl apply -f ./pkg/asm_user_auth_config_v1beta1.yaml
kubectl apply -f ./pkg
authservice
menggunakan CRD UserAuthConfig
untuk memberikan autentikasi pengguna akhir. UserAuthConfig
dapat dikonfigurasi pada waktu proses, dan Anda dapat
memperbaruinya untuk mengubah perilaku authservice
dan mengonfigurasinya dengan endpoint
untuk server otorisasi OIDC apa pun.
Anda dapat melihat file dengan cat pkg/user_auth_config.yaml
, yang berisi kolom berikut:
apiVersion: security.anthos.io/v1beta1
kind: UserAuthConfig
metadata:
name: user-auth-config
namespace: asm-user-auth
spec:
authentication:
oidc:
certificateAuthorityData: "" # kpt-set: ${ca-cert}
issuerURI: "<your issuer uri>" # kpt-set: ${issuer-uri}
proxy: "" # kpt-set: ${proxy}
oauthCredentialsSecret:
name: "oauth-secret" # kpt-set: ${secret-name}
namespace: "asm-user-auth" # kpt-set: ${secret-namespace}
redirectURIHost: "" # kpt-set: ${redirect-host}
redirectURIPath: "/_gcp_asm_authenticate" # kpt-set: ${redirect-path}
scopes: "" # kpt-set: ${scopes}
groupsClaim: "" # kpt-set: ${groups}
outputJWTAudience: "test_audience" # kpt-set: ${jwt-audience}
Lihat
detail konfigurasi autentikasi pengguna
untuk deskripsi mendetail tentang kolom user_auth_config.yaml
.
Melakukan tugas pasca-penginstalan
Tugas berikut diperlukan setelah Anda menyelesaikan langkah-langkah penginstalan.
Mengaktifkan autentikasi pengguna untuk aplikasi
Bagian ini menunjukkan cara mengaktifkan autentikasi pengguna, dengan menggunakan
contoh aplikasi httpbin
sebagai contoh.
Autentikasi pengguna Cloud Service Mesh menggunakan kebijakan otorisasi berjenis
CUSTOM
untuk memicu alur OIDC.
Setelah Anda
menginstal gateway Istio,
konfigurasi gateway untuk menyalurkan traffic HTTPS menggunakan sertifikat TLS userauth-tls-cert
yang Anda buat di atas. Berikut adalah konfigurasi pkg/gateway.yaml
yang baru saja Anda
instal.
apiVersion: networking.istio.io/v1beta1
kind: Gateway
metadata:
name: userauth
namespace: asm-user-auth
spec:
selector:
istio: ingressgateway
servers:
- hosts:
- '*'
port:
name: https
number: 443
protocol: HTTPS
tls:
mode: SIMPLE
credentialName: userauth-tls-cert
---
# This ensures the OIDC endpoint has at least some route defined.
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
name: userauth-oidc
namespace: asm-user-auth
spec:
gateways:
- userauth
hosts:
- '*'
http:
- match:
- uri:
prefix: /status
- uri:
prefix: "your-oidc-redirect-path"
name: user-auth-route
route:
- destination:
host: authservice
port:
number: 10004
Beri label namespace
default
untuk mengaktifkan injeksi otomatisistio-proxy
untuk deployment.kubectl label namespace default istio.io/rev=REVISION --overwrite
Deploy
httpbin
ke namespacedefault
.kubectl apply -f https://raw.githubusercontent.com/istio/istio/master/samples/httpbin/httpbin.yaml -n default
Perbarui
httpbin
untuk menggunakan gateway ini guna menyalurkan traffic HTTPS, dan gunakan penerusan port untuk mengakses aplikasi secara lokal:kubectl apply -f./samples/httpbin-route.yaml -n default kubectl port-forward service/istio-ingressgateway 8443:443 -n asm-user-auth
Gateway masuk di port 8443 akan diteruskan ke
localhost
agar aplikasi dapat diakses secara lokal.Deploy
samples/rctoken-authz.yaml
untuk mengaktifkan RequestAuthentication dan AuthorizationPolicy guna memverifikasi RCToken untuk permintaan.kubectl apply -f ./samples/rctoken-authz.yaml -n asm-user-auth
Contoh
samples/rctoken-authz.yaml
:apiVersion: security.istio.io/v1beta1 kind: RequestAuthentication metadata: name: require-rc-token spec: selector: matchLabels: istio: ingressgateway jwtRules: - issuer: "authservice.asm-user-auth.svc.cluster.local" audiences: - "test_audience" jwksUri: "http://authservice.asm-user-auth.svc.cluster.local:10004/_gcp_user_auth/jwks" fromHeaders: - name: X-ASM-RCTOKEN forwardOriginalToken: true --- apiVersion: security.istio.io/v1beta1 kind: AuthorizationPolicy metadata: name: require-rc-token spec: selector: matchLabels: istio: ingressgateway action: ALLOW rules: - when: - key: request.auth.claims[iss] values: - authservice.asm-user-auth.svc.cluster.local - key: request.auth.claims[aud] values: - test_audience
Memverifikasi autentikasi pengguna
httpbin
menyediakan dua jalur, /ip
dapat diakses secara publik dan /headers
memerlukan pengguna akhir untuk login melalui IdP yang dikonfigurasi.
Pastikan Anda dapat mengakses
/ip
secara langsung dengan membukahttps://localhost:8443/ip
.Pastikan Anda melihat halaman login OIDC dengan membuka
https://localhost:8443/headers
.Setelah login, klik Berikutnya dan pastikan Anda dialihkan ke halaman
/headers
.
Mengonfigurasi kebijakan otorisasi
Setelah Anda menyelesaikan konfigurasi di langkah sebelumnya, setiap pengguna akan
dialihkan melalui alur autentikasi berbasis web. Saat alur selesai, authservice
akan menghasilkan RCToken
dalam format JWT, yang digunakan untuk
mengirim informasi pengguna yang diautentikasi.
Tambahkan kebijakan otorisasi Istio di ingress untuk memastikan bahwa pemeriksaan otorisasi terjadi untuk setiap pengguna yang diautentikasi:
kubectl apply -f ./samples/httpbin-authz.yaml -n asm-user-auth
File
httpbin-authz.yaml
mengonfigurasi gateway masuk untuk memvalidasi token RC yang diterbitkan oleh authservice, dan hanya memberikan otorisasi jika JWT berisi kolom yang diinginkan, seperti audiens dan penerbit.Lihat contoh kebijakan otorisasi berikut:
apiVersion: security.istio.io/v1beta1 kind: AuthorizationPolicy metadata: name: require-rc-token spec: selector: matchLabels: istio: ingressgateway action: ALLOW rules: - to: - operation: paths: ["/ip"] - to: when: - key: request.auth.claims[iss] values: - authservice.asm-user-auth.svc.cluster.local - key: request.auth.claims[aud] values: - test_audience - key: request.auth.claims[sub] values: - allowed_user_sub_1 # Change this with the "sub" claim in the RC token. Wildcard '*' will match everything.
Mengonfigurasi setelan khusus lingkungan
Langkah-langkah sebelumnya menggunakan localhost
dan sertifikat HTTPS yang ditandatangani sendiri untuk penyiapan
cepat. Untuk penggunaan produksi yang sebenarnya, gunakan domain Anda sendiri, seperti example.com
.
Selain itu, pastikan certificateAuthorityData
memiliki konten root
yang diinginkan. Misalnya, jika IDP dipercaya dengan root cert sistem, Anda dapat
meninggalkannya kosong. Jika ada proxy HTTPS yang menghentikan koneksi HTTPS, proxy tersebut
harus disetel ke root cert proxy.
Mengelola dan merotasi kunci
Ada dua kumpulan kunci yang digunakan oleh authservice
. Anda dapat memutar setiap tombol
secara terpisah. Namun, sebelum memutar kunci, Anda harus memahami
cara kerja rotasi.
Kedua kunci tersebut dalam format JSON. Kolom useAfter
menentukan stempel waktu sejak
kunci akan dipertimbangkan untuk digunakan. Selama rotasi kunci, Anda harus menyertakan kunci lama dan baru dalam JSON. Misalnya, dalam contoh
berikut, new-key
hanya akan digunakan setelah stempel waktu 1712813735
.
{
"keys":[
{
"kty":"RSA",
"kid":"old-key",
"K":"...", # k contains a Base64 encoded PEM format RSA signing key.
"useAfter": 1612813735, # unix timestamp
}
{
"kty":"RSA",
"kid":"new-key",
"K":"...", # k contains a Base64 encoded PEM format RSA signing key.
"useAfter": 1712813735, # unix timestamp
}
]
}
Cloud Service Mesh menggunakan kunci simetris untuk mengenkripsi data sesi yang disimpan
di cookie browser. Untuk memastikan validitas sesi yang ada, authservice
mencoba dekripsi dengan semua kunci dalam kumpulan kunci. Saat rotasi, authservice
akan menggunakan kunci baru untuk mengenkripsi sesi baru, dan akan terus mencoba
dekripsi dengan kunci lama.
Pasangan kunci publik/pribadi digunakan untuk menandatangani RCToken
. Kunci publik
dikirim ke sidecar oleh istiod
untuk verifikasi JWT. Sidecar harus menerima kunci publik baru sebelum authservice
mulai menggunakan kunci pribadi baru untuk menandatangani RCToken
. Untuk itu, authservice
mulai memublikasikan
kunci publik segera setelah kunci ditambahkan, tetapi menunggu selama
waktu yang signifikan sebelum mulai menggunakannya untuk menandatangani RCToken
.
Untuk meringkas, saat melakukan rotasi kunci, sebaiknya:
- Lakukan rotasi kunci secara rutin atau sesuai permintaan sesuai kebutuhan Anda.
- Dalam format JSON, sertakan kunci saat ini dan kunci baru. Kunci baru harus dikaitkan dengan stempel waktu pada masa mendatang. Sebaiknya tentukan stempel waktu setidaknya beberapa jam lebih awal dari waktu saat ini.
- Pantau dan pastikan bahwa layanan masih berfungsi setelah kunci baru digunakan. Tunggu minimal satu hari setelah kunci baru digunakan sebelum melanjutkan ke langkah berikutnya.
- Hapus kunci lama dari entri JSON. Fungsi tersebut tidak diperlukan lagi.
Deployment Multi-Cluster
Autentikasi Pengguna Cloud Service Mesh mendukung deployment multi-cluster. Anda perlu men-deploy autentikasi pengguna di setiap cluster seperti yang dijelaskan di atas. Konfigurasi autentikasi pengguna seperti resource kustom UserAuth, secret klien OIDC, kunci enkripsi, semuanya perlu direplikasi di setiap cluster.
Secara default, gateway masuk akan melakukan load balancing permintaan autentikasi ke salah satu instance authservice
. Anda dapat menggunakan aturan tujuan untuk mengonfigurasi gateway masuk agar mengirim permintaan ke authservice
di cluster yang sama, dan hanya melakukan failover ke authservice
cluster lain.
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
name: authservice-fail-over
namespace: asm-user-auth
spec:
host: authservice.asm-user-auth.svc.cluster.local
trafficPolicy:
loadBalancer:
localityLbSetting:
enabled: true
failover:
- from: us-east
to: us-west
- from: us-west
to: us-east
Sama seperti konfigurasi lainnya, konfigurasi ini perlu dikonfigurasi di setiap cluster.
Pemetaan klaim kustom
Untuk mengonfigurasi pemetaan klaim kustom, konfigurasikan spec.authentication.oidc.attributeMapping
untuk menentukan pemetaan dari IDToken penyedia identitas asli. Kuncinya adalah nama
klaim di RCToken dan nilainya adalah ekspresi CEL tentang cara mengurai klaim dari IDToken,
gunakan assertion
untuk mereferensikan IDToken.
Contoh:
spec:
authentication:
oidc:
attributeMapping:
aud_copy: assertion.aud
decision: 'assertion.sub.startsWith("123") ? "success" : "fail"'
Di RCToken, attributes
klaim bertingkat berisi klaim yang telah dikonfigurasi:
"attributes": {
"aud_copy": "foo.googleusercontent.com",
"decision": "success"
}
Jika ekspresi CEL gagal mengurai nilai dari IDToken, ekspresi tersebut akan mengabaikan klaim tanpa membuat alur autentikasi gagal.
Upgrade Autentikasi Pengguna
Instal ulang paket autentikasi pengguna karena berisi biner yang diupdate untuk versi autentikasi pengguna baru:
kpt pkg get https://github.com/GoogleCloudPlatform/asm-user-auth.git/@v1.2.3 . cd asm-user-auth/
Simpan konfigurasi klien OIDC Anda:
export OIDC_CLIENT_ID=CLIENT_ID export OIDC_CLIENT_SECRET=CLIENT_SECRET export OIDC_ISSUER_URI=ISSUER_URI export OIDC_REDIRECT_HOST=REDIRECT_HOST export OIDC_REDIRECT_PATH=REDIRECT_PATH
Deploy layanan autentikasi pengguna untuk mengupgrade ke versi baru.
Detail konfigurasi autentikasi pengguna
Tabel berikut menjelaskan setiap kolom dalam CRD:
Nama kolom | Deskripsi |
---|---|
authentication.oidc |
Bagian ini menyimpan konfigurasi endpoint OIDC dan parameter yang digunakan dalam alur OIDC. |
authentication.oidc.certificateAuthorityData |
Ini adalah sertifikat root SSL dari domain server otorisasi OIDC atau proxy HTTPS jika ada. |
authentication.oidc.oauthCredentialsSecret |
Referensi secret ke secret jenis Opaque Kubernetes yang berisi client_id dan client_secret OIDC OAuth2 dalam payload JSON. |
authentication.oidc.issuerURI |
URI yang akan digunakan sebagai penerbit di RCToken output. |
authentication.oidc.proxy |
Server proxy ke IdP OIDC, jika ada. Dengan format http://user:password@10.10.10.10:8888. |
authentication.oidc.redirectURIHost |
Host yang akan digunakan untuk URI penghentian OAuth. Jika Anda mengosongkannya, host dari URL target akan digunakan dan URI pengalihan akan disusun secara dinamis. Nilai ini dapat digunakan jika sesi SSO autentikasi pengguna diinginkan di domain tingkat yang lebih tinggi. Misalnya, untuk mengaktifkan SSO antara profile.example.com/ dan admin.example.com/, nilai ini dapat ditetapkan ke example.com. Tindakan ini akan memungkinkan sesi autentikasi pengguna dibuat di example.com yang akan dibagikan di antara semua subdomain. Catatan: Jika beberapa domain ditayangkan dari mesh yang sama, example1.com dan example2.com, fitur ini tidak dapat digunakan, dan direkomendasikan untuk dibiarkan kosong. |
authentication.oidc.redirectURIPath |
Jalur endpoint tempat authservice akan menghentikan alur OAuth. Anda
harus mendaftarkan jalur URI ini beserta host sebagai URI pengalihan yang sah di
server otorisasi untuk authentication.oidc.clientID .Selain itu, URI ini harus ditayangkan dari mesh layanan dan ingres yang sama tempat authservice diaktifkan. |
authentication.oidc.scopes |
Cakupan OAuth yang harus diminta dalam permintaan autentikasi. Daftar ID yang dipisahkan koma yang digunakan untuk menentukan hak istimewa akses yang diminta selain cakupan "openid", misalnya. "groups,allatclaim". |
authentication.oidc.groupsClaim |
Jika idtoken berisi klaim grup, gunakan kolom ini untuk menunjukkan namanya. Jika ditentukan, layanan akan meneruskan data dalam
klaim ini ke klaim groups dalam RCToken output. Klaim ini harus berisi
daftar string yang dipisahkan koma, misalnya. ["group1", "group2"]. |
authentication.oidc.attributeMapping |
Berisi satu atau beberapa pemetaan klaim dari idtoken diikuti ekspresi CEL. Semua klaim
harus dirujuk oleh assertion.X , assertion dirujuk
ke IDToken asli, misalnya aud_copy: assertion.aud |
authentication.outputJWTAudience |
Audiens RCToken yang dihasilkan oleh authservice . Sidecar dapat
memvalidasi RCToken yang masuk berdasarkan nilai audiens ini. |
Memecahkan masalah
Aksesibilitas jaringan ke IDP.
Kemungkinan log:
error: TLS handshake failed.
.Verifikasi dengan menjalankan
curl
dari penampungistio-proxy
ke URI penerbit IdP. Jika tidak dapat terhubung, pengguna dapat memeriksa aturan firewall atau konfigurasi jaringan lainnya untuk cluster.Sertifikat Root CA.
Log yang mungkin:
error: The server's TLS certificate did not match expectations.
atauerror: TLS handshake failed.
.Pastikan
certificateAuthorityData
memiliki sertifikat root CA yang benar. Jika tidak ada proxy HTTPS yang menghentikan traffic HTTPS, proxy ini akan menyimpan sertifikat CA root untuk IDP. Jika ada, proxy akan disimpan di sini.Konfigurasi jalur pengalihan.
Kemungkinan pengamatan: menerima halaman error 404 selama alur autentikasi OIDC.
User Auth menampilkan header "Set-Cookie" tanpa menggunakan atribut jalur, yang secara default browser menggunakan direktori URL permintaan sebagai jalur cookie (cakupan cookie yang terkait dengan jalur). Jadi, sebaiknya jangan sertakan "/" di jalur pengalihan kecuali jika Anda memang ingin melakukannya.
Sidecar tidak dapat mengambil jwksUri.
Dalam beberapa skenario, pembatasan sidecar dapat menyebabkan kegagalan pengambilan jwksUri. Jika namespace tidak ada menggunakan karakter pengganti (misalnya,
./*
atauistio-system/*
), hal ini tidak akan berfungsi. Anda harus menambahkan namespace-nya secara manual di sidecar ekspor.
FAQ
Bagaimana cara mengupgrade Cloud Service Mesh dengan mengaktifkan User Auth?
Jika Anda menggunakan Cloud Service Mesh dalam cluster, ikuti proses upgrade Cloud Service Mesh dan tentukan file overlay dengan menambahkan
--custom_overlay user-auth-overlay.yaml
di command line keasmcli install
.Cloud Service Mesh Terkelola diupgrade secara otomatis.
Berapa banyak CPU dan memori yang harus saya sediakan untuk
authservice
? Dan berapa banyak permintaan per detik yang dapat ditanganinya?Secara default,
authservice
dikonfigurasi dengan 2,0 vCPU, memori 256 Mi. Dengan konfigurasi tersebut,authservice
dapat menangani 500 permintaan per detik. Untuk menangani permintaan dalam jumlah yang lebih besar, Anda harus menyediakan lebih banyak CPU, yang kira-kira sebanding dengan kapasitas penanganan permintaannya. Anda juga dapat mengonfigurasi beberapa replika authservice untuk meningkatkan skalabilitas horizontal.