සටහන. පරිවර්තනය.:
අපි Kubernetes පොකුරක් පිහිටුවමු එහි අපි Istio යෙදවූ අතර Istio ගේ හැකියාවන් ප්රදර්ශනය කිරීම සඳහා Sentiment Analysis වැනි උදාහරණ ක්ෂුද්ර සේවා යෙදුමක් පිහිටුවමු.
Istio සමඟින්, අපට අපගේ සේවාවන් කුඩාව තබා ගැනීමට හැකි වූයේ ඔවුන්ට නැවත උත්සාහ කිරීම්, කල් ඉකුත්වීම්, පරිපථ කඩනයන්, ලුහුබැඳීම, අධීක්ෂණය වැනි ස්ථර ක්රියාත්මක කිරීමට අවශ්ය නොවන බැවිනි. ඊට අමතරව, අපි උසස් පරීක්ෂණ සහ යෙදවීමේ තාක්ෂණික ක්රම භාවිතා කළෙමු: A/B පරීක්ෂාව, දර්පණය සහ කැනරි රෝල්අවුට්.
නව ද්රව්යයේ, අපි ව්යාපාරික වටිනාකමට යන මාවතේ අවසාන ස්ථර සමඟ කටයුතු කරන්නෙමු: සත්යාපනය සහ අවසරය - සහ ඉස්ටියෝ හි එය සැබෑ සතුටකි!
Istio හි සත්යාපනය සහ අවසරය
සත්යාපනය සහ අවසරය මගින් මා ආස්වාදයක් ලබනු ඇතැයි මම කිසි විටෙකත් විශ්වාස නොකරමි. මෙම මාතෘකා විනෝදජනක කිරීමට සහ ඊටත් වඩා ඔබට ප්රබෝධමත් කිරීමට තාක්ෂණික ඉදිරිදර්ශනයකින් Istio ඉදිරිපත් කළ හැක්කේ කුමක්ද?
පිළිතුර සරලයි: Istio විසින් මෙම හැකියාවන් සඳහා වගකීම ඔබේ සේවාවන් වෙතින් Envoy proxy වෙත මාරු කරයි. ඉල්ලීම් සේවාවන් වෙත ළඟා වන විට, ඒවා දැනටමත් සත්යාපනය කර අවසර දී ඇත, එබැවින් ඔබ කළ යුත්තේ ව්යාපාරයට ප්රයෝජනවත් කේතයක් ලිවීමයි.
හොදයි වගේ දැනෙනවා? අපි ඇතුලට බලමු!
Auth0 සමඟ සත්යාපනය
අනන්යතාවය සහ ප්රවේශ කළමනාකරණය සඳහා සේවාදායකයක් ලෙස, අපි Auth0 භාවිතා කරන්නෙමු, එය අත්හදා බැලීමේ අනුවාදයක් ඇත, එය භාවිතා කිරීමට බුද්ධිමත් වන අතර මම එයට කැමතියි. කෙසේ වෙතත්, එකම මූලධර්ම වෙනත් ඕනෑම කෙනෙකුට යෙදිය හැකිය
ආරම්භ කිරීමට, යන්න
ගොනුවේ මෙම වසම සඳහන් කරන්න resource-manifests/istio/security/auth-policy.yaml
(
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
එවැනි සම්පතක් සමඟ, නියමු (Istio හි මූලික Control Plane සංරචක තුනෙන් එකක් - දළ වශයෙන්. පරිවර්තනය.) සේවාවන් වෙත යොමු කිරීමට පෙර ඉල්ලීම් සත්යාපනය කිරීමට එන්වෝයි වින්යාස කරයි: sa-web-app
и sa-feedback
. ඒ අතරම, වින්යාසය සේවා එන්වෝස් වෙත අදාළ නොවේ sa-frontend
, අපට ඉදිරිපස අනවසරයෙන් තැබීමට ඉඩ සලසයි. ප්රතිපත්තිය යෙදීම සඳහා, විධානය ක්රියාත්මක කරන්න:
$ kubectl apply -f resource-manifests/istio/security/auth-policy.yaml
policy.authentication.istio.io “auth-policy” created
පිටුවට ආපසු ගොස් ඉල්ලීමක් කරන්න - එය තත්ත්වයෙන් අවසන් වන බව ඔබට පෙනෙනු ඇත 401 අනවසර. දැන් අපි Auth0 සමඟින් සත්යාපනය කිරීමට ඉදිරිපස පරිශීලකයන් යළි යොමු කරමු.
Auth0 සමඟ ඉල්ලීම් සත්යාපනය කිරීම
අවසාන පරිශීලක ඉල්ලීම් සත්යාපනය කිරීමට, ඔබ Auth0 තුළ API එකක් සෑදිය යුතු අතර එය සත්යාපනය කළ සේවාවන් (සමාලෝචන, විස්තර සහ ශ්රේණිගත කිරීම්) නියෝජනය කරයි. API එකක් සෑදීමට, යන්න Auth0 Portal > APIs > Create API සහ පෝරමය පුරවන්න:
මෙහි ඇති වැදගත් තොරතුරු වන්නේ හැඳුනුම්පත, අපි පසුව පිටපතේ භාවිතා කරනු ඇත. අපි එය මෙසේ ලියමු.
- ප්රේක්ෂකයන්: {YOUR_AUDIENCE}
අපට අවශ්ය ඉතිරි තොරතුරු කොටසේ Auth0 ද්වාරයෙහි පිහිටා ඇත අයදුම්පත් - තෝරන්න පරීක්ෂණ අයදුම්පත (API සමඟින් ස්වයංක්රීයව සාදන ලදී).
මෙන්න අපි ලියන්නෙමු:
- වසම්: {YOUR_DOMAIN}
- සේවාලාභී හැඳුනුම්පත: {YOUR_CLIENT_ID}
වෙත අනුචලනය කරන්න පරීක්ෂණ අයදුම්පත පෙළ ක්ෂේත්රයට අවසර ලත් ආපසු ඇමතුම් URL (ඇමතුම සඳහා විසඳන ලද URL), සත්යාපනය සම්පූර්ණ කිරීමෙන් පසු ඇමතුම යැවිය යුතු URL එක අපි සඳහන් කරමු. අපගේ නඩුවේදී එය:
http://{EXTERNAL_IP}/callback
සහ සඳහා අවසර ලත් ලොග්අවුට් URL (පිටවීම සඳහා අවසර ලත් URL) එකතු කරන්න:
http://{EXTERNAL_IP}/logout
අපි ඉස්සරහට යමු.
ඉදිරිපස යාවත්කාලීන කිරීම
ශාඛාව වෙත මාරු වන්න auth0
ගබඩාව [istio-mastery]
. මෙම ශාඛාව තුළ, පරිශීලකයන් සත්යාපනය සඳහා Auth0 වෙත හරවා යැවීමට ඉදිරිපස කේතය වෙනස් කර ඇති අතර අනෙකුත් සේවාවන් සඳහා වන ඉල්ලීම්වලදී JWT ටෝකනය භාවිතා කරයි. දෙවැන්න පහත පරිදි ක්රියාත්මක වේ (
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));
}
Auth0 හි කුලී නිවැසියන්ගේ දත්ත භාවිතා කිරීමට ඉදිරිපස කොටස වෙනස් කිරීමට, විවෘත කරන්න sa-frontend/src/services/Auth.js
අපි ඉහත ලියා ඇති අගයන් එහි ප්රතිස්ථාපනය කරන්න (
const Config = {
clientID: '{YOUR_CLIENT_ID}',
domain:'{YOUR_DOMAIN}',
audience: '{YOUR_AUDIENCE}',
ingressIP: '{EXTERNAL_IP}' // Используется для редиректа после аутентификации
}
අයදුම්පත සූදානම්. සිදු කරන ලද වෙනස්කම් ගොඩනඟන විට සහ යෙදවීමේදී පහත විධානයන් තුළ ඔබේ ඩොකර් හැඳුනුම්පත සඳහන් කරන්න:
$ 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
යෙදුම උත්සාහ කරන්න! ඔබව Auth0 වෙත හරවා යවනු ඇත, එහිදී ඔබට පුරනය වීමට (හෝ ලියාපදිංචි වීමට) අවශ්ය වේ, ඉන්පසු ඔබව දැනටමත් සත්යාපනය කර ඇති ඉල්ලීම් කරනු ලබන පිටුවට ආපසු යවනු ලැබේ. ලිපියේ මුල් කොටස්වල සඳහන් කර ඇති විධානයන් curl සමඟ උත්සාහ කළහොත් ඔබට කේතය ලැබෙනු ඇත 401 තත්ව කේතය, ඉල්ලීමට අවසර දී නොමැති බවට සංඥා කිරීම.
අපි ඊළඟ පියවර ගනිමු - ඉල්ලීම් අනුමත කරන්න.
Auth0 සමඟ අවසරය
සත්යාපනය මඟින් පරිශීලකයෙකු යනු කවුරුන්ද යන්න තේරුම් ගැනීමට අපට ඉඩ සලසයි, නමුත් ඔවුන්ට ප්රවේශය ඇති දේ දැන ගැනීමට අවසරය අවශ්ය වේ. Istio මේ සඳහා මෙවලම් ද ඉදිරිපත් කරයි.
උදාහරණයක් ලෙස, අපි පරිශීලක කණ්ඩායම් දෙකක් නිර්මාණය කරමු (පහත රූප සටහන බලන්න):
- පරිශීලකයින් (පරිශීලකයින්) - SA-WebApp සහ SA-Frontend සේවා සඳහා පමණක් ප්රවේශය සහිතව;
- Moderators (මධ්යපතීන්) - සේවා තුනටම ප්රවේශය සහිතව.
අවසර සංකල්පය
මෙම කණ්ඩායම් සෑදීමට, අපි Auth0 Authorization දිගුව භාවිතා කරන අතර ඔවුන්ට විවිධ මට්ටමේ ප්රවේශයන් ලබා දීමට Istio භාවිතා කරන්නෙමු.
Auth0 අවසරය ස්ථාපනය කිරීම සහ වින්යාස කිරීම
Auth0 ද්වාරයෙහි, දිගු වෙත යන්න (වලංගු කාලය දීර්ඝ කර) සහ ස්ථාපනය කරන්න Auth0 අවසරය. ස්ථාපනය කිරීමෙන් පසු, වෙත යන්න අවසර දීමේ දිගුව, සහ එහි - ඉහළ දකුණේ ක්ලික් කර සුදුසු මෙනු විකල්පය තේරීමෙන් කුලී නිවැසියන්ගේ වින්යාසය වෙත (වින්යාසය). කණ්ඩායම් සක්රිය කරන්න (කණ්ඩායම්) සහ ප්රකාශන රීති බොත්තම ක්ලික් කරන්න (නීතිය ප්රකාශ කරන්න).
කණ්ඩායම් නිර්මාණය කිරීම
Authorization Extension එකේ යන්න කණ්ඩායම් සහ කණ්ඩායමක් සාදන්න Moderators. අපි සියලුම සත්යාපිත පරිශීලකයින් සාමාන්ය පරිශීලකයන් ලෙස සලකන බැවින්, ඔවුන් සඳහා අමතර කණ්ඩායමක් සෑදීමට අවශ්ය නොවේ.
කණ්ඩායමක් තෝරන්න Moderators, මුද්රණාලය සාමාජිකයන් එකතු කරන්න, ඔබේ ප්රධාන ගිණුම එක් කරන්න. සමහර පරිශීලකයින්ට ප්රවේශය ප්රතික්ෂේප කර ඇති බව සහතික කර ගැනීමට කිසිදු කණ්ඩායමක් නොමැතිව තබන්න. (නව පරිශීලකයන් හරහා අතින් නිර්මාණය කළ හැක Auth0 ද්වාරය > පරිශීලකයන් > පරිශීලකයා සාදන්න.)
ප්රවේශ ටෝකනයට කණ්ඩායම් හිමිකම් එක් කරන්න
පරිශීලකයින් කණ්ඩායම් වලට එකතු කර ඇත, නමුත් මෙම තොරතුරු ප්රවේශ ටෝකන් වලද පිළිබිඹු විය යුතුය. OpenID Connect සමඟ අනුකූල වීමට සහ ඒ සමඟම අපට අවශ්ය කණ්ඩායම් ආපසු ලබා දීමට, ටෝකනයට එයම එකතු කිරීමට අවශ්ය වනු ඇත.
රීතියක් සෑදීමට, Auth0 Portal වෙත යන්න නීති, මුද්රණාලය රීතියක් සාදන්න සහ සැකිලි වලින් හිස් රීතියක් තෝරන්න.
පහත කේතය පිටපත් කර එය නව රීතියක් ලෙස සුරකින්න කණ්ඩායම් හිමිකම් එකතු කරන්න (
function (user, context, callback) {
context.accessToken['https://sa.io/group'] = user.groups[0];
return callback(null, user, context);
}
අදහස් දැක්වීම්: මෙම කේතය බලය පැවරීමේ දිගුවේ අර්ථ දක්වා ඇති පළමු පරිශීලක කණ්ඩායම ගෙන එය අභිරුචි හිමිකම් පෑමක් ලෙස ප්රවේශ ටෝකනයට එක් කරයි (එහි නාම අවකාශය යටතේ, Auth0 ට අවශ්ය පරිදි).
පිටුවට ආපසු යන්න නීති පහත දැක්වෙන අනුපිළිවෙලින් ඔබට නීති දෙකක් ලියා තිබේදැයි පරීක්ෂා කරන්න:
- auth0-authorization-extension
- කණ්ඩායම් හිමිකම් එකතු කරන්න
සමූහ ක්ෂේත්රයට රීතිය අසමමුහුර්තව ලැබෙන නිසා අනුපිළිවෙල වැදගත් වේ auth0-authorization-extension ඉන්පසු එය දෙවන රීතිය මගින් හිමිකම් පෑමක් ලෙස එකතු කරනු ලැබේ. ප්රතිඵලය වන්නේ මෙවැනි ප්රවේශ ටෝකනයකි:
{
"https://sa.io/group": "Moderators",
"iss": "https://sentiment-analysis.eu.auth0.com/",
"sub": "google-oauth2|196405271625531691872"
// [сокращено для наглядности]
}
දැන් ඔබට පරිශීලක ප්රවේශය පරීක්ෂා කිරීමට එන්වෝයි ප්රොක්සිය වින්යාස කිරීමට අවශ්ය වේ, ඒ සඳහා සමූහය හිමිකම් පෑමෙන් ඉවත් කරනු ලැබේ (https://sa.io/group
) ආපසු ප්රවේශ ටෝකනය තුළ. ලිපියේ ඊළඟ කොටස සඳහා මාතෘකාව මෙයයි.
Istio හි අවසර වින්යාසය
වැඩ කිරීමට අනුමැතිය සඳහා, ඔබ Istio සඳහා RBAC සබල කළ යුතුය. මෙය සිදු කිරීම සඳහා, අපි පහත වින්යාසය භාවිතා කරමු:
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"
පැහැදිලි කිරීම්:
- 1 — ක්ෂේත්රයේ ලැයිස්තුගත කර ඇති සේවා සහ නාම අවකාශයන් සඳහා පමණක් RBAC සබල කරන්න
Inclusion
; - 2 - අපි අපගේ සේවාවන් ලැයිස්තුවක් ලැයිස්තුගත කරමු.
පහත විධානය සමඟ වින්යාසය යොදමු:
$ kubectl apply -f resource-manifests/istio/security/enable-rbac.yaml
rbacconfig.rbac.istio.io/default created
සියලුම සේවාවන්ට දැන් භූමිකාව පදනම් වූ ප්රවේශ පාලනය අවශ්ය වේ. වෙනත් වචන වලින් කිවහොත්, සියලුම සේවාවන් වෙත ප්රවේශය තහනම් කර ඇති අතර ප්රතිචාරයක් ලැබෙනු ඇත RBAC: access denied
. දැන් අපි බලයලත් පරිශීලකයින්ට ප්රවේශයට ඉඩ දෙමු.
සාමාන්ය පරිශීලකයින් සඳහා ප්රවේශ වින්යාසය
සියලුම පරිශීලකයින්ට SA-Frontend සහ SA-WebApp සේවාවන් වෙත ප්රවේශය තිබිය යුතුය. පහත Istio සම්පත් භාවිතයෙන් ක්රියාත්මක කර ඇත:
- සේවා භූමිකාව - පරිශීලකයාට ඇති අයිතිවාසිකම් තීරණය කරයි;
- ServiceRoleBinding — මෙම ServiceRole අයිති කාටද යන්න තීරණය කරයි.
සාමාන්ය පරිශීලකයින් සඳහා අපි ඇතැම් සේවාවන් වෙත ප්රවේශය ලබා දෙන්නෙමු (
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: ["*"]
සහ හරහා regular-user-binding
සියලුම පිටු නරඹන්නන් සඳහා ServiceRole යොදන්න (
apiVersion: "rbac.istio.io/v1alpha1"
kind: ServiceRoleBinding
metadata:
name: regular-user-binding
namespace: default
spec:
subjects:
- user: "*"
roleRef:
kind: ServiceRole
name: "regular-user"
"සියලු පරිශීලකයින්" යන්නෙන් අදහස් කරන්නේ සත්යාපනය නොකළ පරිශීලකයින්ට SA WebApp වෙත ප්රවේශය ඇති බව ද? නැත, ප්රතිපත්තිය JWT ටෝකනයේ වලංගුභාවය පරීක්ෂා කරනු ඇත.
අපි සැකසුම් යොදමු:
$ 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
පරිපාලකයින් සඳහා ප්රවේශ වින්යාසය
පරිපාලකයින් සඳහා, අපට සියලු සේවාවන් වෙත ප්රවේශය සබල කිරීමට අවශ්යයි (
apiVersion: "rbac.istio.io/v1alpha1"
kind: ServiceRole
metadata:
name: mod-user
namespace: default
spec:
rules:
- services: ["*"]
paths: ["*"]
methods: ["*"]
නමුත් අපට එවැනි හිමිකම් අවශ්ය වන්නේ ප්රවේශ ටෝකනයේ හිමිකම් ඇති පරිශීලකයින් සඳහා පමණි https://sa.io/group
තේරුමක් ඇතුව Moderators
(
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"
අපි සැකසුම් යොදමු:
$ 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
නියෝජිතයන් තුළ හැඹිලිගත වීම හේතුවෙන්, අවසර දීමේ නීති බලාත්මක වීමට මිනිත්තු කිහිපයක් ගත විය හැක. එවිට ඔබට පරිශීලකයින්ට සහ පරිපාලකයින්ට විවිධ මට්ටමේ ප්රවේශයන් ඇති බව සහතික කළ හැක.
මෙම කොටස පිළිබඳ නිගමනය
බැරෑරුම් ලෙස, සත්යාපනය සහ අවසරය සඳහා සරල, වෙහෙසකින් තොරව, පරිමාණය කළ හැකි සහ ආරක්ෂිත ප්රවේශයක් ඔබ කවදා හෝ දැක තිබේද?
සේවා සඳහා අවසාන පරිශීලක ප්රවේශය සත්යාපනය සහ අවසරය පිළිබඳ සියුම් පාලනයක් ලබා ගැනීමට අවශ්ය වූයේ Istio සම්පත් තුනක් (RbacConfig, ServiceRole, සහ ServiceRoleBinding) පමණි.
ඊට අමතරව, අපි අපගේ නියෝජිත සේවාවන්ගෙන් මෙම ගැටළු ගැන සැලකිලිමත් වී, සාක්ෂාත් කර ගෙන ඇත:
- ආරක්ෂක ගැටළු සහ දෝෂ අඩංගු විය හැකි සාමාන්ය කේතයේ ප්රමාණය අඩු කිරීම;
- එක් අන්ත ලක්ෂ්යයක් පිටතින් ප්රවේශ විය හැකි බවට පත් වූ සහ එය වාර්තා කිරීමට අමතක වූ මෝඩ තත්වයන් සංඛ්යාව අඩු කිරීම;
- නව භූමිකාවක් හෝ අයිතියක් එක් කරන සෑම අවස්ථාවකම සියලුම සේවාවන් යාවත්කාලීන කිරීමේ අවශ්යතාවය ඉවත් කිරීම;
- නව සේවාවන් සරල, ආරක්ෂිත සහ වේගවත් පවතින බව.
නිගමනය
Istio කණ්ඩායම්වලට ඔවුන්ගේ සම්පත් ක්ෂුද්ර තත්ත්වයට ප්රතිවර්තනය කරමින් සේවා සඳහා පොදු කාර්ය එකතු නොකර ව්යාපාරික-විවේචනාත්මක කාර්යයන් වෙත යොමු කිරීමට ඉඩ සලසයි.
ලිපිය (කොටස් තුනකින්) සැබෑ ව්යාපෘතිවල ඉස්ටියෝ සමඟ ආරම්භ කිරීම සඳහා මූලික දැනුම සහ සූදානම් කළ ප්රායෝගික උපදෙස් සපයන ලදී.
පරිවර්තකගෙන් PS
අපගේ බ්ලොග් අඩවියේ ද කියවන්න:
- "ඉස්ටියෝ සමඟ ක්ෂුද්ර සේවා වෙත ආපසු":
1 කොටස (ප්රධාන අංගයන් හැඳින්වීම) ,2 කොටස (මාර්ගගත කිරීම, රථවාහන පාලනය) ; - «
Conduit - Kubernetes සඳහා සැහැල්ලු සේවා දැලක් »; - «
සේවා දැලක් යනු කුමක්ද සහ මට එය [ක්ෂුද්ර සේවා සහිත වලාකුළු යෙදුමක් සඳහා] අවශ්ය වන්නේ ඇයි? ".
මූලාශ්රය: www.habr.com