Hvordan konfigurere tjenestekontoer i Kubernetes

En oversikt over tjenestekontoer og hvordan de opererer er gitt i denne artikkelen. En avgjørende del av Kubernetes som gir sikker tilgang til API -serveren er tjenestekontoen. En interaksjon med en Kubernetes -klynge krever kommunikasjon med API -serveren. Forespørsler fremmes til API -serveren om å kommunisere. Når en API -server mottar en forespørsel, prøver den først å autentisere den. Hvis denne autentiseringen mislykkes, anses forespørselen som anonym. Dette betyr at hver prosess, enten det er en del av klyngen eller ikke, må autentisere før du sender en forespørsel til API -serveren, inkludert en bruker som skriver Kubectl på skrivebordet og Kubelet -prosessen som kjører på en node. Denne konteksten beskriver hvilke typer Kubernetes -kontoer og hvordan du konfigurerer en tjenestekonto med grunnleggende eksempler.

Kontotyper i Kubernetes

I Kubernetes er det to typer kontoer som er nevnt i følgende:

Brukerkonto

Det brukes av mennesker som kan være administrator- eller utviklerbrukere som prøver å få tilgang til ressursene på klyngenivå og få tilgang til Kubernetes Cluster. Disse brukerne kan administrere det eksterne av klyngen, men Kubernetes -klyngen er klar over det. Brukerkontoen har ikke et spesifikt navneområde.

Servicekonto

Dette er maskinnivåkontoer. Prosessene som er aktive i klyngens pods er representert av tjenestekontoer. API -serveren autentiserer POD ved hjelp av en tjenestekonto før den får tilgang til klyngen.

Hva er en Kubernetes servicekonto?

Det brukes for å autentisere prosessene på maskinnivå for å gi dem tilgang til Kubernetes Cluster. API -serveren har ansvaret for å gjøre slik autentisering for prosessene som kjøres i POD. Kubernetes -klyngen administrerer tjenestekontoer. Tjenestekontoer har et spesifikt navneområde. Disse genereres enten automatisk av API -serveren eller manuelt via API -anrop.

Hvordan fungerer Kubernetes servicekonto?

Vi vil forklare hvordan det fungerer i et scenario der en applikasjon fra en tredjepart prøver å koble seg til Kubernetes Cluster API -servere.

La oss si at det er et nettsted, min webside, som må hente dataene fra en API -server som ligger i Kubernetes -klyngen, som illustrert i forrige figur, for å vise en liste over objekter. For å få tilgang til dataene fra klyngeserverne og autentisere dem, krever vi en tjenestekonto som fungerer som broen som er gjort tilgjengelig av Cluster API -serverne.

Forutsetninger

Før du jobber med oppstartssonden, er forutsetninger en Kubernetes-klynge med to noder som ikke fungerer som verter og Kubectl-kommandolinjeprogramvare som må konfigureres for å kommunisere mellom klynger. Hvis du ikke har opprettet en klynge, kan du bruke Minikube til å lage en klynge. Det er andre Kubernetes lekeplasser tilgjengelig på nettet som du kan bruke til å lage klyngen.

Opprett tjenestekonto

Vi må nå opprette en tjenestekonto ved å følge trinn-for-trinn-instruksjonene for å få tilgang til Kubernetes-klyngen. La oss begynne!

Trinn 1: Start Minikube

Først må du starte Minikube -klyngen slik at du kan bruke KUBECTL -kommandoene og kjøre søknaden din. Minikube -klyngen lar deg distribuere nodene, belgene og til og med klyngen i Kubernetes -miljøet. Derfor er det viktig å holde Minikube i aktiv modus ved å bruke følgende kommando:

> Minikube Start

Dette aktiverer Minikube -klyngen og gjør Kubernetes -miljøet klart.

Trinn 2: Bruk standard servicekonto for å få tilgang til API -tjenesten

Pods autentiserer som en bestemt tjenestekonto når de kommuniserer med API -serveren. Standard tjenestekonto for hvert Kubernetes navneområde, som standard, er til stede i hvert navneområde og utgjør minimum antall tjenestekontoer. Når du bygger en pod, tildeler Kubernetes automatisk tjenestekontoen som kalles standard i det navneområdet hvis du ikke spesifiserer en.

Du kan hente informasjonen for en generert pod ved å utføre følgende kommando:

> Kubectl Få ServiceacCounts

Trinn 3: Output av API -legitimasjon

Tjenestekontoen YAML Manifest -filen skal åpnes først.

> Nano Serviceaccount.Yaml

I stedet for at Kubelet automatisk monterer en ServiceAccounts API -legitimasjon, kan du velge å endre den normale oppførselen.

Trinn 4: Opprett en ekstra tjenestekonto

Ytterligere objekter for tjenestekontoer kan opprettes på følgende måte som nevnt:

> KUBECTL Søk -f ServiceacCount.Yaml

Trinn 5: Bruk flere tjenestekontoer

I denne sammenhengen produserer hver pod som genereres i Kubernetes -klyngen med et spesifikt navneområde en tjenestekonto som standard med standard standard. Tjenestetokenet og nødvendig hemmelig objekt opprettes automatisk av standard tjenestekonto.

Ved å kjøre følgende kommando kan du liste opp hver ServiceAccount -ressurs i ditt nåværende navneområde:

> Kubectl Få ServiceacCounts

Trinn 6: Få en dump av tjenestekontoen

Hvis tjenestekontobjektet er fullstendig dumpet, ser det ut som følgende skjermbilde. Det gjøres med den vedlagte kommandoen her:

> Kubectl Få ServiceacCounts/Build -Robot -o Yaml

Trinn 7: Opprydding Tjenestekontoen

Slett kjørekontoen før du konfigurerer Build-Robot-tjenestekontoen med følgende kommando:

> Kubectl Delete ServiceacCount/Build-Robot

Trinn 8: Opprett et API -token

Anta at du allerede har "Build-Robot" -tjenestekontonavnet som nevnt i forrige eksempel. Ved å bruke følgende kommando kan du få et kort API -token for den tjenestekontoen:

> Kubectl Create Token Demo1

Utgangen fra den forrige kommandoen blir tatt til autentisering for den tjenestekontoen. Ved å bruke kommandoen innebærer -Durasjon, kan du generere en unik tokenvarighet.

Trinn 9: Opprett et manuelt langvarig API-token for servicekonto

Opprett en ny hemmelighet med en unik merknad hvis du vil få et API -token for en tjenestekonto. Her er følgende kommando:

> Nano hemmelighet.Yaml

Her er den komplette konfigurasjonsfilen:

I vedlagte skjermbilde kan du se at det opprettes en tjenestekonto.

Trinn 10: Se de hemmelige objektdetaljene

Du må bruke følgende kommando for å gjøre innholdet i et hemmelig element synlig:

> Kubectl beskriv hemmeligheter/demo1

Som du kan se, er "build-robot" Serviceaccounts API-token nå til stede i det hemmelige objektet.

Ved å kjøre den nevnte kommandoen, kan du se tokens kodede hash-tast-verdi som vises i forrige bilde.

Derfor kan dette standardhemmelige objektet brukes til å gi en tilgang til API -serverne som er lokalisert i samme klyngeområde for vår applikasjon, som er distribuert i poden til samme navneområde.

Trinn 11: Legg ImagePullSecrets til en tjenestekonto

Lag et ImagePullSecret. Sørg for at den ble generert. For det er kommandoen som følger:

> Kubectl Create Secret Docker-Registry MyRegistryKey--Docker-Server = Dummy_Server \--Docker-brukernavn = Dummy_Username-Docker-Password = Dummy_Docker_Password \-docker-e-post = dummy_docker_email

Forsikre deg om at den er opprettet. Du kan sjekke dette med den gitte kommandoen her:

> Kubectl Få hemmeligheter MyRegistrykey

Trinn 12: Legg ImagePullSecret til en tjenestekonto

Endre navnefeltets standardtjenestekonto slik at den bruker denne hemmeligheten som et ImagePullSecret. Kommandoen er gitt som følger:

> KUBECTL PATCH SERVICEACCOUNT standard -p '“ImagePullSecrets”: [“name”: ”MyRegistryKey”]

Konklusjon

Vi lærte om tjenestekontoen som ved å tilby autentisering, autorisasjon og administrasjonskontroll gjør API -serveren i å gjøre applikasjonen sikker. For å autentisere kommunikasjonen mellom eksterne programmer og API -er, fungerer tjenestekontoen som en lenke til en prosess som kjører i en pod. Praksiseksemplet for å opprette tjenestekontoen og for å konfigurere det med et enkelt eksempel implementeres i denne artikkelen.