Det stemmer, etter utgivelsen i begynnelsen av mai 2019, i Consul kan du autorisere applikasjoner og tjenester som kjører i Kubernetes.
I denne opplæringen vil vi lage trinn for trinn (Proof of concept, PoC) som demonstrerer denne nye funksjonen. Du forventes å ha grunnleggende kunnskap om Kubernetes og Hashicorps konsul. Mens du kan bruke hvilken som helst skyplattform eller lokalt miljø, vil vi i denne opplæringen bruke Googles nettskyplattform.
Gjennomgå
Hvis vi går til , får vi en rask oversikt over formålet og brukstilfellet, samt noen tekniske detaljer og en generell oversikt over logikken. Jeg anbefaler på det sterkeste å lese den minst én gang før du fortsetter, da jeg nå skal forklare og tygge på det hele.
Diagram 1: Offisiell oversikt over Consul-autorisasjonsmetoden
La oss se inn .
Jada, det er nyttig informasjon der, men det er ingen veiledning om hvordan du faktisk bruker alt. Så, som enhver tilregnelig person, leter du rundt på Internett for å få veiledning. Og så... Du mislykkes. Det skjer. La oss fikse dette.
Før vi går videre til å lage vår POC, la oss gå tilbake til oversikten over Consuls autorisasjonsmetoder (Diagram 1) og avgrense den i sammenheng med Kubernetes.
arkitektur
I denne opplæringen vil vi lage en Consul-server på en egen maskin som vil kommunisere med en Kubernetes-klynge med Consul-klienten installert. Vi vil da lage vår dummy-applikasjon i poden og bruke vår konfigurerte autorisasjonsmetode for å lese fra vår Consul-nøkkel-/verdilager.
Diagrammet nedenfor beskriver arkitekturen vi lager i denne opplæringen, samt logikken bak autorisasjonsmetoden, som vil bli forklart senere.
Diagram 2: Kubernetes autorisasjonsmetodeoversikt
En rask merknad: Consul-serveren trenger ikke å bo utenfor Kubernetes-klyngen for at dette skal fungere. Men ja, han kan gjøre det sånn og sånn.
Så, tar vi Consul-oversiktsdiagrammet (Diagram 1) og bruker Kubernetes på det, får vi diagrammet ovenfor (Diagram 2), og logikken her er som følger:
- Hver pod vil ha en tjenestekonto knyttet til seg som inneholder et JWT-token generert og kjent av Kubernetes. Dette tokenet er også satt inn i poden som standard.
- Vår applikasjon eller tjeneste inne i poden starter en påloggingskommando til vår Consul-klient. Påloggingsforespørselen vil også inkludere vårt token og navn spesielt laget autorisasjonsmetode (Kubernetes-type). Dette trinn #2 tilsvarer trinn 1 i Consul-diagrammet (skjema 1).
- Vår Consul-klient vil deretter videresende denne forespørselen til vår Consul-server.
- MAGI! Det er her Consul-serveren verifiserer ektheten av forespørselen, samler inn informasjon om identiteten til forespørselen og sammenligner den med eventuelle tilhørende forhåndsdefinerte regler. Nedenfor er et annet diagram for å illustrere dette. Dette trinnet tilsvarer trinn 3, 4 og 5 i Consul-oversiktsdiagrammet (Diagram 1).
- Vår Consul-server genererer et Consul-token med tillatelser i henhold til våre spesifiserte autorisasjonsmetoderegler (som vi har definert) angående identiteten til forespørselen. Den vil da sende det tokenet tilbake. Dette tilsvarer trinn 6 i Consul-diagrammet (Diagram 1).
- Vår Consul-klient videresender tokenet til søknaden eller tjenesten som ber om.
Vår applikasjon eller tjeneste kan nå bruke dette Consul-tokenet til å kommunisere med våre Consul-data, som bestemt av tokenets privilegier.
Magien avsløres!
For de av dere som ikke er fornøyd med bare en kanin ut av hatten og vil vite hvordan det fungerer... la meg "vise dere hvor dypt kaninhull'.
Som nevnt tidligere, er vårt "magiske" trinn (Figur 2: Trinn 4) der Consul-serveren autentiserer forespørselen, samler inn informasjon om forespørselen og sammenligner den med tilknyttede forhåndsdefinerte regler. Dette trinnet tilsvarer trinn 3, 4 og 5 i Consul-oversiktsdiagrammet (Diagram 1). Nedenfor er et diagram (Diagram 3), hvis formål er å tydelig vise hva som faktisk skjer under panseret spesifikk Kubernetes-autorisasjonsmetode.
Diagram 3: Magien avsløres!
- Som et utgangspunkt videresender vår Consul-klient påloggingsforespørselen til vår Consul-server med Kubernetes-kontotoken og spesifikt forekomstnavn til autorisasjonsmetoden som ble opprettet tidligere. Dette trinnet tilsvarer trinn 3 i den forrige kretsforklaringen.
- Nå må Consul-serveren (eller lederen) bekrefte ektheten til det mottatte tokenet. Derfor vil den konsultere Kubernetes-klyngen (via Consul-klienten), og med de nødvendige tillatelsene vil vi finne ut om tokenet er ekte og hvem det tilhører.
- Den validerte forespørselen returneres deretter til Consul-lederen, og Consul-serveren slår opp autorisasjonsmetodeforekomsten med det angitte navnet fra påloggingsforespørselen (og Kubernetes-typen).
- Konsullederen identifiserer den spesifiserte autorisasjonsmetodeforekomsten (hvis funnet) og leser settet med bindende regler som er knyttet til den. Den leser deretter disse reglene og sammenligner dem med de verifiserte identitetsattributtene.
- TA-dah! La oss gå videre til trinn 5 i den forrige kretsforklaringen.
Kjør Consul-server på en vanlig virtuell maskin
Fra nå av vil jeg for det meste gi instruksjoner om hvordan du lager denne POC-en, ofte i punkttegn, uten fullsetningsforklaringer. Også, som nevnt tidligere, vil jeg bruke GCP til å lage all infrastrukturen, men du kan lage den samme infrastrukturen hvor som helst ellers.
- Start den virtuelle maskinen (instans/server).
- Opprett en regel for brannmuren (sikkerhetsgruppe i AWS):
- Jeg liker å tildele samme maskinnavn til både regelen og nettverkskoden, i dette tilfellet "skywiz-consul-server-poc".
- Finn din lokale datamaskins IP-adresse og legg den til listen over kilde-IP-adresser slik at vi får tilgang til brukergrensesnittet (UI).
- Åpne port 8500 for UI. Klikk på Opprett. Vi vil snart endre denne brannmuren igjen [].
- Legg til en brannmurregel i forekomsten. Gå tilbake til VM-dashbordet på Consul Server og legg til "skywiz-consul-server-poc" i nettverksetikettfeltet. Klikk Lagre.
- Installer Consul på en virtuell maskin, sjekk her. Husk at du trenger Consul-versjon ≥ 1.5 [lenke]
- La oss lage en enkelt node Consul - konfigurasjonen er som følger.
groupadd --system consul
useradd -s /sbin/nologin --system -g consul consul
mkdir -p /var/lib/consul
chown -R consul:consul /var/lib/consul
chmod -R 775 /var/lib/consul
mkdir /etc/consul.d
chown -R consul:consul /etc/consul.d- For en mer detaljert veiledning om installasjon av Consul og oppsett av en klynge med 3 noder, se .
- Opprett en fil /etc/consul.d/agent.json som følger []:
### /etc/consul.d/agent.json
{
"acl" : {
"enabled": true,
"default_policy": "deny",
"enable_token_persistence": true
}
}- Start vår Consul-server:
consul agent
-server
-ui
-client 0.0.0.0
-data-dir=/var/lib/consul
-bootstrap-expect=1
-config-dir=/etc/consul.d- Du bør se en haug med utdata og ende opp med "... oppdatering blokkert av tilgangskontrollister."
- Finn den eksterne IP-adressen til Consul-serveren og åpne en nettleser med denne IP-adressen på port 8500. Pass på at brukergrensesnittet åpnes.
- Prøv å legge til et nøkkel/verdi-par. Det må være en feil. Dette er fordi vi lastet Consul-serveren med en ACL og deaktiverte alle regler.
- Gå tilbake til skallet ditt på Consul-serveren og start prosessen i bakgrunnen eller på en annen måte for å få den til å kjøre og skriv inn følgende:
consul acl bootstrap- Finn "SecretID"-verdien og gå tilbake til brukergrensesnittet. I ACL-fanen skriver du inn den hemmelige ID-en til tokenet du nettopp kopierte. Kopier SecretID et annet sted, vi trenger det senere.
- Legg nå til et nøkkel/verdi-par. For denne POC, legg til følgende: nøkkel: "custom-ns/test_key", verdi: "Jeg er i custom-ns-mappen!"
Lansering av en Kubernetes-klynge for applikasjonen vår med Consul-klienten som en Daemonset
- Opprett en K8s (Kubernetes)-klynge. Vi oppretter den i samme sone som serveren for raskere tilgang, og slik at vi kan bruke samme subnett for enkelt å koble til interne IP-adresser. Vi vil kalle det "skywiz-app-med-konsul-klient-poc".
- Som en sidenotat, her er en god opplæring jeg kom over mens jeg satte opp en POC Consul-klynge med Consul Connect.
- Vi vil også bruke Hashicorp rorkart med en utvidet verdifil.
- Installer og konfigurer Helm. Konfigurasjonstrinn:
kubectl create serviceaccount tiller --namespace kube-system
kubectl create clusterrolebinding tiller-admin-binding
--clusterrole=cluster-admin --serviceaccount=kube-system:tiller
./helm init --service-account=tiller
./helm update- rordiagram:
- Bruk følgende verdifil (merk at jeg har deaktivert de fleste):
### poc-helm-consul-values.yaml
global:
enabled: false
image: "consul:latest"
# Expose the Consul UI through this LoadBalancer
ui:
enabled: false
# Allow Consul to inject the Connect proxy into Kubernetes containers
connectInject:
enabled: false
# Configure a Consul client on Kubernetes nodes. GRPC listener is required for Connect.
client:
enabled: true
join: ["<PRIVATE_IP_CONSUL_SERVER>"]
extraConfig: |
{
"acl" : {
"enabled": true,
"default_policy": "deny",
"enable_token_persistence": true
}
}
# Minimal Consul configuration. Not suitable for production.
server:
enabled: false
# Sync Kubernetes and Consul services
syncCatalog:
enabled: false- Bruk rordiagram:
./helm install -f poc-helm-consul-values.yaml ./consul-helm - name skywiz-app-with-consul-client-poc- Når den prøver å kjøre, vil den trenge tillatelser for Consul-serveren, så la oss legge dem til.
- Legg merke til "Pod Address Range" som ligger på klyngedashbordet og se tilbake til vår "skywiz-consul-server-poc" brannmurregel.
- Legg til adresseområdet for poden til listen over IP-adresser og åpne portene 8301 og 8300.
- Gå til Consul UI og etter noen minutter vil du se klyngen vår vises i nodefanen.
Konfigurere en autorisasjonsmetode ved å integrere Consul med Kubernetes
- Gå tilbake til Consul-serverskallet og eksporter tokenet du lagret tidligere:
export CONSUL_HTTP_TOKEN=<SecretID>- Vi trenger informasjon fra Kubernetes-klyngen for å opprette en forekomst av autentiseringsmetoden:
- kubernetes-vert
kubectl get endpoints | grep kubernetes- kubernetes-service-account-jwt
kubectl get sa <helm_deployment_name>-consul-client -o yaml | grep "- name:"
kubectl get secret <secret_name_from_prev_command> -o yaml | grep token:- Tokenet er base64-kodet, så dekrypter det med ditt favorittverktøy []
- kubernetes-ca-cert
kubectl get secret <secret_name_from_prev_command> -o yaml | grep ca.crt:- Ta "ca.crt"-sertifikatet (etter base64-dekoding) og skriv det inn i "ca.crt"-filen.
- Instantier nå autentiseringsmetoden, og bytt ut plassholderne med verdiene du nettopp mottok.
consul acl auth-method create
-type "kubernetes"
-name "auth-method-skywiz-consul-poc"
-description "This is an auth method using kubernetes for the cluster skywiz-app-with-consul-client-poc"
-kubernetes-host "<k8s_endpoint_retrieved earlier>"
[email protected]
-kubernetes-service-account-
jwt="<decoded_token_retrieved_earlier>"- Deretter må vi lage en regel og knytte den til den nye rollen. For denne delen kan du bruke Consul UI, men vi vil bruke kommandolinjen.
- Skriv en regel
### kv-custom-ns-policy.hcl
key_prefix "custom-ns/" {
policy = "write"
}- Bruk regelen
consul acl policy create
-name kv-custom-ns-policy
-description "This is an example policy for kv at custom-ns/"
-rules @kv-custom-ns-policy.hcl- Finn ID-en til regelen du nettopp opprettet fra utdataene.
- Opprett en rolle med en ny regel.
consul acl role create
-name "custom-ns-role"
-description "This is an example role for custom-ns namespace"
-policy-id <policy_id>- Nå vil vi knytte vår nye rolle til auth-metodeforekomsten. Merk at "velger"-flagget bestemmer om vår påloggingsforespørsel vil motta denne rollen. Sjekk her for andre velgeralternativer:
consul acl binding-rule create
-method=auth-method-skywiz-consul-poc
-bind-type=role
-bind-name='custom-ns-role'
-selector='serviceaccount.namespace=="custom-ns"'Til slutt konfigurasjoner
Tilgangsrettigheter
- Opprett tilgangsrettigheter. Vi må gi Consul tillatelse til å bekrefte og identifisere identiteten til K8s tjenestekontotoken.
- Skriv følgende til filen :
###skywiz-poc-consul-server_rbac.yaml
---
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: review-tokens
namespace: default
subjects:
- kind: ServiceAccount
name: skywiz-app-with-consul-client-poc-consul-client
namespace: default
roleRef:
kind: ClusterRole
name: system:auth-delegator
apiGroup: rbac.authorization.k8s.io
---
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: service-account-getter
namespace: default
rules:
- apiGroups: [""]
resources: ["serviceaccounts"]
verbs: ["get"]
---
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: get-service-accounts
namespace: default
subjects:
- kind: ServiceAccount
name: skywiz-app-with-consul-client-poc-consul-client
namespace: default
roleRef:
kind: ClusterRole
name: service-account-getter
apiGroup: rbac.authorization.k8s.io- La oss opprette tilgangsrettigheter
kubectl create -f skywiz-poc-consul-server_rbac.yamlKobler til Consul Client
- Som notert Det er flere alternativer for å koble til daemonset, men vi går videre til følgende enkle løsning:
- Bruk følgende fil [].
### poc-consul-client-ds-svc.yaml
apiVersion: v1
kind: Service
metadata:
name: consul-ds-client
spec:
selector:
app: consul
chart: consul-helm
component: client
hasDNS: "true"
release: skywiz-app-with-consul-client-poc
ports:
- protocol: TCP
port: 80
targetPort: 8500- Bruk deretter følgende innebygde kommando for å lage et konfigurasjonskart []. Vær oppmerksom på at vi refererer til navnet på tjenesten vår, bytt det ut om nødvendig.
cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: ConfigMap
metadata:
labels:
addonmanager.kubernetes.io/mode: EnsureExists
name: kube-dns
namespace: kube-system
data:
stubDomains: |
{"consul": ["$(kubectl get svc consul-ds-client -o jsonpath='{.spec.clusterIP}')"]}
EOFTester autentiseringsmetoden
La oss nå se magien i aksjon!
- Opprett flere nøkkelmapper med samme toppnivånøkkel (dvs. /sample_key) og en verdi etter eget valg. Lag passende retningslinjer og roller for nye nøkkelbaner. Vi gjør bindingene senere.
Test av egendefinert navneområde:
- La oss lage vårt eget navneområde:
kubectl create namespace custom-ns- La oss lage en pod i vårt nye navneområde. Skriv konfigurasjonen for poden.
###poc-ubuntu-custom-ns.yaml
apiVersion: v1
kind: Pod
metadata:
name: poc-ubuntu-custom-ns
namespace: custom-ns
spec:
containers:
- name: poc-ubuntu-custom-ns
image: ubuntu
command: ["/bin/bash", "-ec", "sleep infinity"]
restartPolicy: Never- Opprett under:
kubectl create -f poc-ubuntu-custom-ns.yaml- Når beholderen er i gang, gå dit og installer curl.
kubectl exec poc-ubuntu-custom-ns -n custom-ns -it /bin/bash
apt-get update && apt-get install curl -y- Nå vil vi sende en påloggingsforespørsel til Consul ved å bruke autorisasjonsmetoden vi opprettet tidligere [].
- For å se det angitte tokenet fra tjenestekontoen din:
cat /run/secrets/kubernetes.io/serviceaccount/token- Skriv følgende til en fil inne i beholderen:
### payload.json
{
"AuthMethod": "auth-method-test",
"BearerToken": "<jwt_token>"
}- Logg Inn!
curl
--request POST
--data @payload.json
consul-ds-client.default.svc.cluster.local/v1/acl/login- For å fullføre trinnene ovenfor på én linje (siden vi skal kjøre flere tester), kan du gjøre følgende:
echo "{
"AuthMethod": "auth-method-skywiz-consul-poc",
"BearerToken": "$(cat /run/secrets/kubernetes.io/serviceaccount/token)"
}"
| curl
--request POST
--data @-
consul-ds-client.default.svc.cluster.local/v1/acl/login- Virker! Det burde i hvert fall. Ta nå SecretID og prøv å få tilgang til nøkkelen/verdien vi skal ha tilgang til.
curl
consul-ds-client.default.svc.cluster.local/v1/kv/custom-ns/test_key --header “X-Consul-Token: <SecretID_from_prev_response>”- Du kan base64 dekode "Value" og se at den samsvarer med verdien i custom-ns/test_key i brukergrensesnittet. Hvis du brukte samme verdi ovenfor i denne opplæringen, ville den kodede verdien din være IkknbSBpbiB0aGUgY3VzdG9tLW5zIGZvbGRlciEi.
Brukertjenestekontotest:
- Opprett en tilpasset tjenestekonto ved å bruke følgende kommando [].
kubectl apply -f - <<EOF
apiVersion: v1
kind: ServiceAccount
metadata:
name: custom-sa
EOF- Opprett en ny konfigurasjonsfil for poden. Vær oppmerksom på at jeg inkluderte krøllinstallasjon for å spare arbeidskraft :)
###poc-ubuntu-custom-sa.yaml
apiVersion: v1
kind: Pod
metadata:
name: poc-ubuntu-custom-sa
namespace: default
spec:
serviceAccountName: custom-sa
containers:
- name: poc-ubuntu-custom-sa
image: ubuntu
command: ["/bin/bash","-ec"]
args: ["apt-get update && apt-get install curl -y; sleep infinity"]
restartPolicy: Never- Etter det, kjør et skall inne i beholderen.
kubectl exec -it poc-ubuntu-custom-sa /bin/bash- Logg Inn!
echo "{
"AuthMethod": "auth-method-skywiz-consul-poc",
"BearerToken": "$(cat /run/secrets/kubernetes.io/serviceaccount/token)"
}"
| curl
--request POST
--data @-
consul-ds-client.default.svc.cluster.local/v1/acl/login- Tillatelse avslått. Åh, vi glemte å legge til nye regler som er bindende med de riktige tillatelsene, la oss gjøre det nå.
Gjenta de foregående trinnene ovenfor:
a) Opprett en identisk policy for prefikset "custom-sa/".
b) Opprett en rolle, kall den "custom-sa-rolle"
c) Legg ved policyen til rollen.
- Lag en regelbinding (kun mulig fra cli/api). Legg merke til den forskjellige betydningen av velgerflagget.
consul acl binding-rule create
-method=auth-method-skywiz-consul-poc
-bind-type=role
-bind-name='custom-sa-role'
-selector='serviceaccount.name=="custom-sa"'- Logg på igjen fra "poc-ubuntu-custom-sa"-beholderen. Suksess!
- Sjekk ut vår tilgang til den tilpassede sa/nøkkelbanen.
curl
consul-ds-client.default.svc.cluster.local/v1/kv/custom-sa/test_key --header “X-Consul-Token: <SecretID>”- Du kan også sørge for at dette tokenet ikke gir tilgang til kv i "custom-ns/". Bare gjenta kommandoen ovenfor etter å ha erstattet "custom-sa" med prefikset "custom-ns".
Tillatelse avslått.
Eksempel på overlegg:
- Det er verdt å merke seg at alle regelbindende tilordninger vil bli lagt til tokenet med disse rettighetene.
- Vår container "poc-ubuntu-custom-sa" er i standard navneområde - så la oss bruke den til en annen regelbinding.
- Gjenta forrige trinn:
a) Opprett en identisk policy for "standard/"-nøkkelprefikset.
b) Opprett en rolle, gi den navnet "default-ns-rolle"
c) Legg ved policyen til rollen. - Lag en regelbinding (kun mulig fra cli/api)
consul acl binding-rule create
-method=auth-method-skywiz-consul-poc
-bind-type=role
-bind-name='default-ns-role'
-selector='serviceaccount.namespace=="default"'- Gå tilbake til vår "poc-ubuntu-custom-sa"-beholder og prøv å få tilgang til "default/" kv-banen.
- Tillatelse avslått.
Du kan se den angitte legitimasjonen for hvert token i brukergrensesnittet under ACL > Tokens. Som du kan se, har vårt nåværende token bare en "custom-sa-rolle" knyttet til seg. Tokenet vi bruker for øyeblikket ble generert da vi logget på, og det var bare en regelbinding som stemte da. Vi må logge på igjen og bruke det nye tokenet. - Sørg for at du kan lese fra både "custom-sa/" og "default/" kv banene.
Suksess!
Dette er fordi vår "poc-ubuntu-custom-sa" samsvarer med regelbindingene "custom-sa" og "default-ns".
Konklusjon
TTL token håndtering?
Når dette skrives, er det ingen integrert måte å bestemme TTL for tokens generert av denne autorisasjonsmetoden. Det ville være en fantastisk mulighet til å gi sikker automatisering av Consul-autorisasjon.
Det er et alternativ for å manuelt lage et token med TTL:
Utløpstid - Tidspunktet da dette tokenet vil bli opphevet. (Valgfritt; lagt til i Consul 1.5.0)- Eksisterer kun for manuell opprettelse/oppdatering
Forhåpentligvis vil vi i nær fremtid kunne kontrollere hvordan tokens genereres (per regel eller autorisasjonsmetode) og legge til TTL.
Inntil da foreslås det at du bruker et utloggingsendepunkt i logikken din.
Les også andre artikler på bloggen vår:
Kilde: www.habr.com