ማስታወሻ. ትርጉም:
የኢስቲዮ አቅሞችን ለማሳየት ኢስቲዮ እና የናሙና ስሜት ትንተና ማይክሮ ሰርቪስ መተግበሪያን ያሰማራበት የኩበርኔትስ ክላስተር አዘጋጅተናል።
እንደ የግንኙነት ድግግሞሽ (እንደገና መሞከር) ፣ የጊዜ ማብቂያዎች (የጊዜ ማብቂያዎች) ፣ የወረዳ የሚላተም (የወረዳ ሰባሪዎች) ፣ መከታተያ (ክትትል) ያሉ “ንብርብሮችን” መተግበር ስለማያስፈልጋቸው በኢስቲዮ እገዛ የአገልግሎቶቹን መጠን አነስተኛ ለማድረግ ችለናል። ክትትል (ክትትል) . በተጨማሪም፣ የላቀ የፍተሻ እና የማሰማራት ቴክኒኮችን ተጠቀምን-A/B ሙከራ፣ ማንጸባረቅ እና የካናሪ ልቀትን።
በአዲሱ ማቴሪያል ውስጥ, ወደ ንግድ ዋጋ በሚወስደው መንገድ ላይ የመጨረሻዎቹን ንብርብሮች እንይዛለን-ማረጋገጫ እና ፍቃድ - እና በ Istio ውስጥ ይህ እውነተኛ ደስታ ነው!
በ Istio ውስጥ ማረጋገጫ እና ፍቃድ
በማረጋገጫ እና በፈቃድ አነሳሽነት እነሳሳለሁ ብዬ በፍጹም አላምንም ነበር። ኢስቲዮ እነዚህን ርዕሶች አስደሳች እና እርስዎንም እንዲያነሳሱ ለማድረግ ከቴክኖሎጂ አንጻር ምን ያቀርባል?
መልሱ ቀላል ነው፡ ኢስቲዮ ለእነዚህ ችሎታዎች ኃላፊነቱን ከአገልግሎቶችዎ ወደ መልዕክተኛው ተኪ ይለውጠዋል። ጥያቄዎቹ አገልግሎቶቹ ሲደርሱ፣ የተረጋገጡ እና የተፈቀደላቸው ናቸው፣ ስለዚህ እርስዎ ማድረግ ያለብዎት የንግድ-ጠቃሚ ኮድ መጻፍ ብቻ ነው።
ያምራል? ወደ ውስጥ እንይ!
በ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
በእንደዚህ አይነት ምንጭ, አብራሪ (በኢስቲዮ ውስጥ ካሉት የቁጥጥር ፕላን ሶስት መሠረታዊ ክፍሎች አንዱ - በግምት። ተርጓሚ።) ወደ አገልግሎቶች ከማስተላለፉ በፊት መልእክተኛን እንዲያረጋግጡ ያዋቅራል፡- 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 ውስጥ የተረጋገጡ አገልግሎቶችን (ግምገማዎች፣ ዝርዝሮች እና ደረጃዎች) የሚወክል ኤፒአይ መፍጠር አለቦት። ኤፒአይ ለመፍጠር ወደ ይሂዱ Auth0 ፖርታል > APIs > API ፍጠር እና ቅጹን ይሙሉ፡-
እዚህ ላይ አስፈላጊው መረጃ ነው መለየት, በኋላ ላይ በስክሪፕቱ ውስጥ የምንጠቀመው. እንዲህ እንጽፈው፡-
- ተመልካች: {YOUR_AudiENCE}
የምንፈልጋቸው ቀሪ ዝርዝሮች በክፍሉ ውስጥ ባለው Auth0 ፖርታል ላይ ይገኛሉ መተግበሪያዎች - ይምረጡ የሙከራ መተግበሪያ (በኤፒአይ በራስ ሰር የተፈጠረ)።
እዚህ እንጽፋለን፡-
- የጎራ: {YOUR_DOMAIN}
- የደንበኛ መታወቂያ: {YOUR_CLIENT_ID}
ሸብልል ወደ የሙከራ መተግበሪያ ወደ የጽሑፍ መስክ የተፈቀዱ መልሶ መደወል ዩአርኤሎች (ለመልሶ ጥሪ የተፈቀዱ ዩአርኤሎች)፣ ማረጋገጫው ከተጠናቀቀ በኋላ ጥሪው የሚላክበትን ዩአርኤል እንገልፃለን። በእኛ ሁኔታ ይህ ነው፡-
http://{EXTERNAL_IP}/callback
እና ለ የተፈቀደ ውጣ ዩአርኤሎች (ለመውጣት የተፈቀዱ ዩአርኤሎች) ያክሉ፡
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 ጋር
ማረጋገጥ ተጠቃሚው ማን እንደሆነ እንድንገነዘብ ያስችለናል፣ ነገር ግን ምን መዳረሻ እንዳለው ለማወቅ ፍቃድ ያስፈልጋል። ኢስቲዮ ለዚህ መሳሪያ ያቀርባል.
እንደ ምሳሌ፣ ሁለት የተጠቃሚ ቡድኖችን እንፍጠር (ከዚህ በታች ያለውን ሥዕላዊ መግለጫ ተመልከት)
- ተጠቃሚዎች (ተጠቃሚዎች) - ወደ SA-WebApp እና SA-Frontent አገልግሎቶች መዳረሻ ብቻ;
- አወያዮች (አወያዮች) - ለሦስቱም አገልግሎቶች ተደራሽነት።
የፍቃድ ጽንሰ-ሀሳብ
እነዚህን ቡድኖች ለመፍጠር የAuth0 ፍቃድ ማራዘሚያን እንጠቀማለን እና የተለያዩ የመዳረሻ ደረጃዎችን ለመስጠት ኢስቲኦን እንጠቀማለን።
Auth0 ፍቃድን መጫን እና ማዋቀር
በAuth0 ፖርታል ውስጥ፣ ወደ ቅጥያዎች ይሂዱ (ቅጥያዎች) እና ጫን Auth0 ፍቃድ. አንዴ ከተጫነ ወደ ይሂዱ የፈቃድ ማራዘሚያ, እና እዚያ - ከላይ በቀኝ በኩል ጠቅ በማድረግ እና ተገቢውን ምናሌ በመምረጥ ወደ ተከራይው ውቅር (ውቅር). ቡድኖችን አግብር (ቡድኖች) እና የህትመት ደንብ ቁልፍን ጠቅ ያድርጉ (ህግ አትም).
ቡድኖችን ይፍጠሩ
በፈቃድ ማራዘሚያ ውስጥ ወደ ይሂዱ ቡድኖች እና ቡድን ይፍጠሩ አወያዮች. ሁሉንም የተረጋገጡ ተጠቃሚዎችን እንደ መደበኛ ተጠቃሚ ስለምንይዝ ለእነሱ ተጨማሪ ቡድን መፍጠር አያስፈልግም።
ቡድን ይምረጡ አወያዮች, ይጫኑ አባላትን አክልዋና መለያህን ጨምር። መዳረሻ መከልከላቸውን ለማረጋገጥ አንዳንድ ተጠቃሚዎችን ያለ ቡድን ይተውዋቸው። (አዲስ ተጠቃሚዎች በእጅ ሊፈጠሩ ይችላሉ 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-ፈቃድ-ቅጥያ
- የቡድን ይገባኛል ጥያቄን ያክሉ
ትዕዛዙ አስፈላጊ ነው ምክንያቱም የቡድን መስክ ደንቡን በተመሳሳይ መልኩ ስለሚያገኝ ነው። auth0-ፈቃድ-ቅጥያ እና ከዚያ በኋላ በሁለተኛው ደንብ እንደ የይገባኛል ጥያቄ ተጨምሯል. ውጤቱ የሚከተለው የመዳረሻ ማስመሰያ ነው።
{
"https://sa.io/group": "Moderators",
"iss": "https://sentiment-analysis.eu.auth0.com/",
"sub": "google-oauth2|196405271625531691872"
// [сокращено для наглядности]
}
አሁን የተጠቃሚውን ተደራሽነት ለመፈተሽ የኢንጄይ ፕሮክሲውን ማዋቀር ያስፈልግዎታል ፣ ለዚህም ቡድኑ ከይገባኛል ጥያቄው ይወጣል (https://sa.io/group
) በተመለሰው የመዳረሻ ማስመሰያ ውስጥ። ይህ የጽሁፉ ቀጣይ ክፍል ርዕስ ነው።
በ 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 - ይህ የአገልግሎት ሚና የማን እንደሆነ ይገልጻል።
ለተራ ተጠቃሚዎች የተወሰኑ አገልግሎቶችን እንዲደርሱ እንፈቅዳለን (
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) ብቻ ያስፈልጋሉ።
በተጨማሪም፣ እነዚህን ጉዳዮች በማሳካት ከልዑካን አገልግሎታችን ውጪ ወስደናል፡-
- የደህንነት ችግሮችን እና ስህተቶችን ሊይዝ የሚችለውን የአጠቃላይ ኮድ መጠን መቀነስ;
- አንድ የመጨረሻ ነጥብ ከውጭ የሚገኝበትን እና እሱን ሪፖርት ለማድረግ የረሱትን የሞኝ ሁኔታዎች ብዛት መቀነስ ፣
- አዲስ ሚና ወይም መብት በተጨመረ ቁጥር ሁሉንም አገልግሎቶች የማዘመን አስፈላጊነትን ያስወግዱ;
- አዳዲስ አገልግሎቶች ቀላል፣ደህንነታቸው የተጠበቀ እና ፈጣን እንደሆኑ ይቆያሉ።
መደምደሚያ
ኢስቲዮ ቡድኖች ከአገልግሎቶች ላይ ተጨማሪ ክፍያ ሳይጨምሩ ሀብታቸውን በንግድ-ወሳኝ ተግባራት ላይ እንዲያተኩሩ ያስችላቸዋል፣ ይህም ወደ ጥቃቅን ደረጃ ያመጣቸዋል።
ጽሑፉ (በሶስት ክፍሎች) በእውነተኛ ፕሮጀክቶች ውስጥ ከኢስቲዮ ጋር ለመጀመር መሰረታዊ እውቀትን እና ዝግጁ የሆኑ ተግባራዊ መመሪያዎችን አቅርቧል.
PS ከተርጓሚ
በብሎጋችን ላይ ያንብቡ፡-
- "ከኢስቲዮ ጋር ወደ ማይክሮ አገልግሎቶች ተመለስ"፡-
ክፍል 1 (የዋና ዋና ባህሪያት መግቢያ) ,ክፍል 2 (ማዘዋወር ፣ የትራፊክ ቁጥጥር) ; - «
ኮንዱይት - ለኩበርኔትስ ቀላል ክብደት ያለው የአገልግሎት መረብ "; - «
የአገልግሎት መረብ ምንድን ነው እና ለምን አስፈለገኝ [ከማይክሮ አገልግሎቶች ጋር ለደመና መተግበሪያ]? ».
ምንጭ: hab.com