Aftur í örþjónustur með Istio. 3. hluti

Athugið. þýð.: Í fyrsta hluta þessari lotu var varið til að kynnast hæfileikum Istio og sýna þá í verki, Second - fínstillt leið og netumferðarstjórnun. Nú munum við tala um öryggi: til að sýna fram á helstu aðgerðir sem tengjast því, notar höfundurinn Auth0 auðkennisþjónustuna, en hægt er að stilla aðra veitendur á hliðstæðan hátt við hana.

Við settum upp Kubernetes klasa þar sem við settum upp Istio og sýnishorn af tilfinningagreiningu örþjónustuforriti til að sýna fram á getu Istio.

Með hjálp Istio tókst okkur að halda stærð þjónustu lítilla, þar sem þær þurfa ekki að innleiða „lög“ eins og endurtilraunir tenginga (Retries), timeouts (Timeouts), aflrofar (Circuit Breakers), tracing (Rakning) , eftirlit (Vöktun) . Að auki notuðum við háþróaða prófunar- og dreifingartækni: A/B prófun, speglun og útfærslur kanarífugla.

Í nýja efninu munum við takast á við síðustu lögin á leiðinni að viðskiptavirði: auðkenningu og heimild - og í Istio er þetta sönn ánægja!

Auðkenning og heimild í Istio

Ég hefði aldrei trúað því að ég yrði innblásin af auðkenningu og heimild. Hvað hefur Istio fram að færa frá tæknilegu sjónarhorni til að gera þessi efni spennandi og enn meira svo að þau hvetji þig líka?

Svarið er einfalt: Istio færir ábyrgðina á þessum möguleikum frá þjónustu þinni til umboðsmanns sendifulltrúa. Þegar beiðnirnar berast þjónustunni eru þær nú þegar staðfestar og heimilaðar, þannig að allt sem þú þarft að gera er að skrifa viðskiptalegan kóða.

Hljómar vel? Við skulum kíkja inn!

Auðkenning með Auth0

Við munum nota Auth0 sem netþjón fyrir auðkennis- og aðgangsstjórnun, sem er með prufuútgáfu, sem er leiðandi í notkun og elskar mig bara. Samt sem áður er hægt að beita sömu meginreglum um allar aðrar OpenID Connect útfærslur: KeyCloak, IdentityServer og fleira.

Til að byrja skaltu fara á Auth0 gátt með reikningnum þínum skaltu búa til leigjanda (leigjandi - "leigjandi", rökrétt einangrunareining, sjá nánar í skjöl - ca. þýðing.) og farðu til Forrit > Sjálfgefið forritað velja léneins og sýnt er á skjámyndinni hér að neðan:

Tilgreindu þetta lén í skránni resource-manifests/istio/security/auth-policy.yaml (heimild):

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

Með slíkt úrræði, flugmaður (einn af þremur grunnþáttum Control Plane í Istio - u.þ.b. þýðing) stillir Envoy til að sannvotta beiðnir áður en þær eru sendar til þjónustu: sa-web-app и sa-feedback. Á sama tíma er uppsetningin ekki notuð fyrir sendimenn þjónustu sa-frontend, sem gerir okkur kleift að skilja framendann eftir óvottaðan. Til að beita stefnunni (Stefna), keyrðu skipunina:

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

Farðu aftur á síðuna og gerðu beiðni - þú munt sjá að það endar með status 401 ósamþykkt. Nú skulum við beina framenda notendum til að auðkenna með Auth0.

Staðfestu beiðnir með Auth0

Til að sannvotta beiðnir notenda þarftu að búa til API í Auth0 sem mun tákna staðfestu þjónustuna (umsagnir, upplýsingar og einkunnir). Til að búa til API skaltu fara á Auth0 Portal > API > Búa til API og fylltu út eyðublaðið:

Mikilvægu upplýsingarnar hér eru Auðkenni, sem við munum síðar nota í handritinu. Við skulum skrifa þetta svona:

• Áhorfendur: {YOUR_AUDIENCE}

Eftirstöðvarnar sem við þurfum eru staðsettar á Auth0 gáttinni í hlutanum Umsóknir - veldu Próf umsókn (búið til sjálfkrafa með API).

Hér munum við skrifa:

• lén: {YOUR_DOMAIN}
• Auðkenni viðskiptavinar: {YOUR_CLIENT_ID}

Skrunaðu til Próf umsókn í textareit Leyfilegar hringingarvefslóðir (leyfðar vefslóðir fyrir svarhringingu), þar sem við tilgreinum slóðina sem símtalið á að senda eftir að auðkenningunni er lokið. Í okkar tilviki er þetta:

http://{EXTERNAL_IP}/callback

Og fyrir Leyfðar útskráningarslóðir (leyfðar vefslóðir til að skrá þig út) bæta við:

http://{EXTERNAL_IP}/logout

Við skulum halda áfram að framhliðinni.

Frontend uppfærsla

Skiptu yfir í útibú auth0 geymsla [istio-mastery]. Í þessari grein hefur framendakóðanum verið breytt til að beina notendum til Auth0 til auðkenningar og nota JWT táknið í beiðnum til annarra þjónustu. Hið síðarnefnda er útfært sem hér segir (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));
}

Til að breyta framendanum til að nota leigjandagögn í Auth0, opnaðu sa-frontend/src/services/Auth.js og skiptu í það gildin sem við skrifuðum hér að ofan (Auth.js):

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

Umsóknin er tilbúin. Tilgreindu Docker auðkenni þitt í skipunum hér að neðan þegar þú byggir og innleiðir breytingarnar:

$ 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

Prófaðu appið! Þér verður vísað á Auth0, þar sem þú þarft að skrá þig inn (eða skrá þig), eftir það verður þú sendur aftur á síðuna sem þegar staðfestar beiðnir verða gerðar frá. Ef þú prófar skipanirnar sem nefndar eru í fyrstu hlutum greinarinnar með curl færðu kóðann 401 stöðukóðiAn sem gefur til kynna að beiðnin sé ekki samþykkt.

Við skulum taka næsta skref - heimila beiðnir.

Heimild með Auth0

Auðkenning gerir okkur kleift að skilja hver notandinn er, en til að vita að hverju hann hefur aðgang þarf heimild. Istio býður einnig upp á verkfæri fyrir þetta.

Sem dæmi skulum við búa til tvo notendahópa (sjá skýringarmyndina hér að neðan):

• Notendur (notendur) — með aðgangi eingöngu að SA-WebApp og SA-Frontend þjónustu;
• Fundarstjórar (stjórnendur) — með aðgang að öllum þremur þjónustum.

Heimildarhugtak

Til að búa til þessa hópa munum við nota Auth0 Authorization viðbótina og nota Istio til að veita þeim mismunandi aðgangsstig.

Að setja upp og stilla Auth0 Authorization

Í Auth0 gáttinni skaltu fara í viðbætur (Eftirnafn) og settu upp Auth0 heimild. Þegar það hefur verið sett upp skaltu fara á Framlenging heimildar, og þar - að uppsetningu leigjanda með því að smella efst til hægri og velja viðeigandi valmynd (Stillingar). Virkjaðu hópa (Hópar) og smelltu á birtingarregluhnappinn (Birta reglu).

Búa til hópa

Í heimildarframlengingu farðu til hópar og stofna hóp Stjórnendur. Þar sem við munum meðhöndla alla staðfesta notendur sem venjulega notendur, þá er engin þörf á að búa til viðbótarhóp fyrir þá.

Veldu hóp Stjórnendur, Ýttu á Bættu við meðlimum, bættu við aðalreikningnum þínum. Skildu suma notendur eftir án nokkurs hóps til að tryggja að þeim sé meinaður aðgangur. (Hægt er að búa til nýja notendur handvirkt í gegnum Auth0 Portal > Notendur > Búa til notanda.)

Bæta hópkröfu við aðgangslykil

Notendum er bætt við hópa, en þessar upplýsingar verða einnig að endurspeglast í aðgangslyklum. Til að passa við OpenID Connect og skila um leið þeim hópum sem við þurfum þarf táknið að bæta við sérsniðin krafa. Útfært með Auth0 reglum.

Til að búa til reglu, farðu í Auth0 Portal til Reglur, Ýttu á Búðu til reglu og veldu tóma reglu úr sniðmátum.

Afritaðu kóðann hér að neðan og vistaðu hann sem nýja reglu Bæta við hópkröfu (namespacedGroup.js):

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

Athugið: Þessi kóði tekur fyrsta notendahópinn sem er skilgreindur í heimildarviðbótinni og bætir honum við aðgangslykilinn sem sérsniðna kröfu (undir eigin nafnrými, eins og krafist er af Auth0).

Til baka á síðu Reglur og athugaðu hvort þú sért með tvær reglur skrifaðar í eftirfarandi röð:

• auth0-heimild-framlenging
• Bæta við hópkröfu

Röðin er mikilvæg vegna þess að hópreiturinn fær regluna ósamstillt auth0-heimild-framlenging og þar á eftir bætist sem krafa með annarri reglu. Niðurstaðan er eftirfarandi aðgangslykill:

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

Nú þarftu að stilla umboð sendifulltrúa til að athuga notendaaðgang, en hópurinn verður dreginn út úr kröfunni (https://sa.io/group) í skilaða aðgangslyklinum. Þetta er efni í næsta hluta greinarinnar.

Heimildarstillingar í Istio

Til að fá leyfi til að vinna þarftu að virkja RBAC fyrir Istio. Til að gera þetta notum við eftirfarandi stillingar:

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" 

Útskýring:

• 1 - virkjaðu RBAC aðeins fyrir þjónustu og nafnrými sem skráð eru í reitnum Inclusion;
• 2 - skráðu lista yfir þjónustu okkar.

Notaðu stillinguna með eftirfarandi skipun:

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

Öll þjónusta krefst nú hlutverkataðrar aðgangsstýringar. Með öðrum orðum, aðgangi að allri þjónustu er hafnað og mun leiða til svars RBAC: access denied. Nú skulum við leyfa viðurkenndum notendum aðgang.

Aðgangsstillingar fyrir almenna notendur

Allir notendur verða að hafa aðgang að SA-Frontend og SA-WebApp þjónustum. Útfært með því að nota eftirfarandi Istio auðlindir:

• Þjónustuhlutverk - skilgreinir réttindi sem notandinn hefur;
• ÞjónustaHlutverkabinding - skilgreinir hverjum þetta Þjónustuhlutverk tilheyrir.

Fyrir venjulega notendur munum við leyfa aðgang að ákveðnum þjónustum (þjónustuhlutverk.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: ["*"]

Og eftir regular-user-binding notaðu þjónustuhlutverkið á alla síðugesti (regular-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"

Þýðir „allir notendur“ að notendur sem ekki eru auðkenndir munu einnig hafa aðgang að SA WebApp? Nei, stefnan mun athuga gildi JWT táknsins.

Notaðu stillingar:

$ 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

Aðgangsstillingar fyrir stjórnendur

Fyrir stjórnendur viljum við gera aðgang að allri þjónustu (mod-service-role.yaml):

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

En við viljum slík réttindi aðeins fyrir þá notendur sem hafa kröfu um aðgangslykilinn https://sa.io/group með merkingu 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" 

Notaðu stillingar:

$ 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

Vegna skyndiminni í sendimönnum gætu liðið nokkrar mínútur þar til heimildarreglurnar öðlast gildi. Þú getur síðan staðfest að notendur og stjórnendur hafi mismunandi aðgangsstig.

Niðurstaða um þennan þátt

Í alvöru, hefur þú einhvern tíma séð einfaldari, áreynslulausa, stigstærða og örugga nálgun við auðkenningu og heimild?

Aðeins þrjú Istio auðlindir (RbacConfig, ServiceRole og ServiceRoleBinding) voru nauðsynlegar til að ná fínni stjórn á auðkenningu og heimild notendaaðgangs að þjónustu.

Að auki höfum við séð um þessi mál úr sendiráðsþjónustu okkar með því að ná:

• draga úr magni almenns kóða sem gæti innihaldið öryggisvandamál og villur;
• að fækka heimskulegum aðstæðum þar sem einn endapunktur var tiltækur að utan og gleymdi að tilkynna það;
• útrýma þörfinni á að uppfæra alla þjónustu í hvert sinn sem nýju hlutverki eða rétti er bætt við;
• að ný þjónusta haldist einföld, örugg og hröð.

Output

Istio gerir teymum kleift að einbeita sér að auðlindum sínum að mikilvægum verkefnum án þess að bæta kostnaði við þjónustuna og færa þá aftur í örstöðu.

Greinin (í þremur hlutum) gaf grunnþekkingu og tilbúnar hagnýtar leiðbeiningar til að byrja með Istio í raunverulegum verkefnum.

PS frá þýðanda

Lestu líka á blogginu okkar:

• "Aftur í örþjónustur með Istio": hluti 1 (kynning á helstu eiginleikum), hluti 2 (leiðaráætlun, umferðareftirlit);
• «Conduit - léttur þjónustunet fyrir Kubernetes»;
• «Hvað er þjónustunet og hvers vegna þarf ég það [fyrir skýjaforrit með örþjónustu]?'.

Heimild: www.habr.com