ProHoster > Блог > Administrado > Reen al mikroservoj kun Istio. Parto 3

Reen al mikroservoj kun Istio. Parto 3

Reen al mikroservoj kun Istio. Parto 3

Notu. transl.: Unua parto ĉi tiu serio estis dediĉita al koni la kapablojn de Istio kaj montri ilin en ago, dua — fajne agordita vojigo kaj rettrafika administrado. Nun ni parolos pri sekureco: por pruvi la bazajn funkciojn rilatajn al ĝi, la aŭtoro uzas la servon de identeco Auth0, sed aliaj provizantoj povas esti agorditaj simile.

Ni starigis Kubernetes-grupon en kiu ni deplojis Istio kaj ekzemplon de mikroserva aplikaĵo, Sentiment Analysis, por pruvi la kapablojn de Istio.

Kun Istio, ni povis teni niajn servojn malgrandajn ĉar ili ne bezonas efektivigi tavolojn kiel Reprovoj, Tempoforpasoj, Circuit Breakers, Spurado, Monitorado. . Krome, ni uzis altnivelajn testajn kaj deplojajn teknikojn: A/B-testado, spegulado kaj kanariaj landoj.

Reen al mikroservoj kun Istio. Parto 3

En la nova materialo, ni traktos la finajn tavolojn sur la vojo al komerca valoro: aŭtentikigo kaj rajtigo - kaj en Istio estas vera plezuro!

Aŭtentikigo kaj rajtigo en Istio

Mi neniam estus kredinta, ke mi estus inspirita de aŭtentikigo kaj rajtigo. Kion Istio povas oferti el teknologia perspektivo por fari ĉi tiujn temojn amuzaj kaj, eĉ pli, inspiraj por vi?

La respondo estas simpla: Istio ŝanĝas respondecon pri ĉi tiuj kapabloj de viaj servoj al la prokurilo Envoy. Kiam la petoj atingas la servojn, ili jam estis aŭtentikigitaj kaj rajtigitaj, do vi nur devas skribi komerc-utilan kodon.

Sonas bone? Ni rigardu enen!

Aŭtentikigo kun Auth0

Kiel servilo por identeco kaj aliradministrado, ni uzos Auth0, kiu havas provversion, estas intuicia uzi kaj mi simple ŝatas ĝin. Tamen, la samaj principoj povas esti aplikataj al iu ajn alia OpenID Connect efektivigoj: KeyCloak, IdentityServer kaj multaj aliaj.

Unue, iru al Auth0 Portal kun via konto, kreu luanton (luanto - "luanto", logika unuo de izolado, por pliaj detaloj vidu dokumentado - ĉ. traduk.) kaj iru al Aplikoj > Defaŭlta Apoelektante havaĵo, kiel montrite en la ekrankopio malsupre:

Reen al mikroservoj kun Istio. Parto 3

Indiku ĉi tiun domajnon en la dosiero resource-manifests/istio/security/auth-policy.yaml (fonto):

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

Kun tia rimedo, Piloto (unu el la tri bazaj komponantoj de Control Plane en Istio - ĉ. traduk.) agordas Envoy por aŭtentikigi petojn antaŭ plusendi ilin al servoj: sa-web-app и sa-feedback. Samtempe, la agordo ne estas aplikata al servaj Senditoj sa-frontend, permesante al ni lasi la fasadon neaŭtentikigita. Por apliki la Politikon, rulu la komandon:

$ kubectl apply -f resource-manifests/istio/security/auth-policy.yaml
policy.authentication.istio.io “auth-policy” created

Revenu al la paĝo kaj faru peton - vi vidos, ke ĝi finiĝas kun la stato 401 Ne rajtigita. Nun ni alidirektu uzantojn por aŭtentikigi kun Auth0.

Aŭtentikigi petojn kun Auth0

Por aŭtentikigi petojn de finuzanto, vi devas krei API en Auth0, kiu reprezentos la aŭtentikigitajn servojn (recenzoj, detaloj kaj taksoj). Por krei API, iru al Auth0 Portal > APIoj > Krei API kaj plenigu la formularon:

Reen al mikroservoj kun Istio. Parto 3

La grava informo ĉi tie estas Identigilo, kiun ni uzos poste en la skripto. Ni skribu ĝin tiel:

  • aŭdienco: {VIA_AUDIENCE}

La ceteraj detaloj, kiujn ni bezonas, troviĝas sur la Auth0 Portal en la sekcio aplikaĵoj — elektu Testa Apliko (kreita aŭtomate kune kun la API).

Ĉi tie ni skribos:

  • havaĵo: {VIA_DOMENO}
  • Kliento Id: {YOUR_CLIENT_ID}

Rulumu al Testa Apliko al tekstkampo Permesitaj Revokaj URLoj (solvitaj URLoj por la revoko), en kiuj ni specifigas la URL, kie la voko devus esti sendita post aŭtentikigo estas kompletigita. En nia kazo ĝi estas:

http://{EXTERNAL_IP}/callback

Kaj por Permesitaj elsaluti URLoj (permesitaj URL-oj por elsaluti) aldonu:

http://{EXTERNAL_IP}/logout

Ni transiru al la fasado.

Frontend ĝisdatigo

Ŝanĝu al branĉo auth0 deponejo [istio-mastery]. En ĉi tiu branĉo, la fasanta kodo estas ŝanĝita por redirekti uzantojn al Auth0 por aŭtentigo kaj uzi la JWT-ĵetonon en petoj al aliaj servoj. Ĉi-lasta estas efektivigita jene (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));
}

Por ŝanĝi la fasadon por uzi datumojn pri luanto en Auth0, malfermu sa-frontend/src/services/Auth.js kaj anstataŭigu en ĝi la valorojn, kiujn ni skribis supre (Auth.js):

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

La aplikaĵo estas preta. Specifu vian Docker-ID en la subaj komandoj dum konstruado kaj deplojado de la faritaj ŝanĝoj:

$ 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

Provu la apon! Vi estos redirektita al Auth0, kie vi devas ensaluti (aŭ registriĝi), post kio vi estos resendita al la paĝo de kiu jam aŭtentikigitaj petoj estos faritaj. Se vi provas la komandojn menciitajn en la unuaj partoj de la artikolo kun buklo, vi ricevos la kodon 401 Statusa Kodo, signalante ke la peto ne estas rajtigita.

Ni faru la sekvan paŝon - rajtigu petojn.

Rajtigo kun Auth0

Aŭtentikigo permesas al ni kompreni kiu estas uzanto, sed rajtigo estas postulata por scii al kio ili havas aliron. Istio ankaŭ ofertas ilojn por ĉi tio.

Ekzemple, ni kreu du uzantgrupojn (vidu la diagramon sube):

  • Uzantoj (uzantoj) — kun aliro nur al SA-WebApp kaj SA-Frontend-servoj;
  • Moderigantoj (moderigantoj) — kun aliro al ĉiuj tri servoj.

Reen al mikroservoj kun Istio. Parto 3
Koncepto de Rajtigo

Por krei ĉi tiujn grupojn, ni uzos la etendon Auth0 Authorization kaj uzos Istio por provizi ilin per malsamaj niveloj de aliro.

Instalado kaj agordo de Auth0 Authorization

En la portalo Auth0, iru al etendoj (Etendaĵoj) kaj instali Auth0 Rajtigo. Post instalado, iru al Rajtigo-Etendaĵo, kaj tie - al la agordo de la luanto klakante supre dekstre kaj elektante la taŭgan menuopcion (Agordo). Aktivigi grupojn (Grupoj) kaj alklaku la butonon pri publikigi regulon (Publigu regulon).

Reen al mikroservoj kun Istio. Parto 3

Kreante grupojn

En Rajtigo-Etendaĵo iru al Grupoj kaj krei grupon Moderantoj. Ĉar ni traktos ĉiujn aŭtentikigitajn uzantojn kiel kutimajn uzantojn, ne necesas krei plian grupon por ili.

Elektu grupon Moderantoj, Gazetaro Aldoni membrojn, aldonu vian ĉefan konton. Lasu kelkajn uzantojn sen iu ajn grupo por certigi, ke ili estas rifuzitaj aliro. (Novaj uzantoj povas esti kreitaj permane per Auth0 Portal > Uzantoj > Krei Uzanton.)

Aldonu Grupan Aserton al Access Token

Uzantoj estis aldonitaj al grupoj, sed ĉi tiuj informoj ankaŭ devas esti reflektitaj en alirĵetonoj. Por plenumi OpenID Connect kaj samtempe redoni la grupojn, kiujn ni bezonas, la ĵetono devos aldoni sian propran kutima aserto. Efektivigite per Auth0-reguloj.

Por krei regulon, iru al Auth0 Portal al reguloj, Gazetaro Kreu Regulon kaj elektu malplenan regulon el la ŝablonoj.

Reen al mikroservoj kun Istio. Parto 3

Kopiu la kodon sube kaj konservu ĝin kiel nova regulo Aldonu Grupo-Aserton (namespacedGroup.js):

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

Примечание: Ĉi tiu kodo prenas la unuan uzantgrupon difinitan en la Rajtigo-Etendaĵo kaj aldonas ĝin al la alirĵetono kiel kutima aserto (sub ĝia nomspaco, kiel postulas Auth0).

Reiru al paĝo reguloj kaj kontrolu, ke vi havas du regulojn skribitajn en la sekva ordo:

  • auth0-rajtigo-etendo
  • Aldonu Grupo-Aserton

La ordo estas grava ĉar la grupkampo ricevas la regulon nesinkrone auth0-rajtigo-etendo kaj post tio ĝi estas aldonita kiel aserto per la dua regulo. La rezulto estas alirĵetono kiel ĉi tio:

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

Nun vi devas agordi la Envoy-prokurilon por kontroli uzantan aliron, por kiu la grupo estos eltirita de reklamo (https://sa.io/group) en la resendita alirĵetono. Ĉi tiu estas la temo por la sekva sekcio de la artikolo.

Rajtiga agordo en Istio

Por ke rajtigo funkciu, vi devas ebligi RBAC por Istio. Por fari tion, ni uzos la sekvan agordon:

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"

Klarigoj:

  • 1 — ebligu RBAC nur por servoj kaj nomspacoj listigitaj en la kampo Inclusion;
  • 2 — ni listigas liston de niaj servoj.

Ni apliku la agordon per la sekva komando:

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

Ĉiuj servoj nun postulas Rol-Bazitan Alirkontrolon. Alivorte, aliro al ĉiuj servoj estas malpermesita kaj rezultigos respondon RBAC: access denied. Nun ni permesu aliron al rajtigitaj uzantoj.

Agordo de aliro por kutimaj uzantoj

Ĉiuj uzantoj devas havi aliron al la servoj SA-Frontend kaj SA-WebApp. Efektivigite uzante la sekvajn Istio-resursojn:

  • Servorolo — determinas la rajtojn kiujn la uzanto havas;
  • ServiceRoleBinding — determinas al kiu apartenas ĉi tiu Servorolo.

Por ordinaraj uzantoj ni permesos aliron al iuj servoj (servorolo.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: ["*"]

Kaj tra regular-user-binding apliki ServiceRole al ĉiuj paĝvizitantoj (regula-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"

Ĉu "ĉiuj uzantoj" signifas, ke neaŭtentikigitaj uzantoj ankaŭ havos aliron al la SA Retejo? Ne, la politiko kontrolos la validecon de la JWT-ĵetono.

Ni apliku la agordojn:

$ 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

Agordo de aliro por moderigaĵoj

Por moderigaĵoj, ni volas ebligi aliron al ĉiuj servoj (mod-service-role.yaml):

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

Sed ni volas tiajn rajtojn nur por tiuj uzantoj, kies alirĵetono enhavas reklamon https://sa.io/group kun signifo 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"

Ni apliku la agordojn:

$ 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

Pro kaŝmemoro en senditoj, povas daŭri kelkajn minutojn por rajtigaj reguloj efiki. Vi povas tiam certigi, ke uzantoj kaj moderigaĵoj havas malsamajn nivelojn de aliro.

Konkludo ĉi-flanke

Serioze tamen, ĉu vi iam vidis pli simplan, senpene, skaleblan kaj sekuran aliron al aŭtentikigo kaj rajtigo?

Nur tri Istio-resursoj (RbacConfig, ServiceRole, kaj ServiceRoleBinding) estis postulataj por atingi fajnan kontrolon de aŭtentigo kaj rajtigo de finuzantaliro al servoj.

Krome, ni prizorgis ĉi tiujn aferojn el niaj senditaj servoj, atingante:

  • reduktante la kvanton de ĝenerala kodo, kiu povas enhavi sekurecproblemojn kaj cimojn;
  • redukti la nombron da stultaj situacioj, en kiuj unu finpunkto montriĝis alirebla de ekstere kaj forgesis raporti ĝin;
  • forigante la bezonon ĝisdatigi ĉiujn servojn ĉiufoje kiam nova rolo aŭ rajto estas aldonita;
  • ke novaj servoj restas simplaj, sekuraj kaj rapidaj.

konkludo

Istio permesas al teamoj enfokusigi siajn rimedojn sur komercaj kritikaj taskoj sen aldoni superkozon al servoj, revenante ilin al mikrostatuso.

La artikolo (en tri partoj) disponigis bazajn sciojn kaj pretajn praktikajn instrukciojn por komenci kun Istio en realaj projektoj.

PS de tradukisto

Legu ankaŭ en nia blogo:

fonto: www.habr.com

Aldoni komenton