Així és, després del llançament a principis de maig de 2019, Consul pot autoritzar de forma nativa aplicacions i serveis que s'executen a Kubernetes.
En aquest tutorial, crearem pas a pas (Prova de concepte, PoC) que demostra aquesta nova funció. S'espera que tingueu coneixements bàsics de Kubernetes i el cònsol de Hashicorp. I tot i que podeu utilitzar qualsevol plataforma al núvol o entorn local, en aquest tutorial, farem servir la plataforma al núvol de Google.
visió de conjunt
Si anem a , obtindrem una breu visió general del seu propòsit i cas d'ús, així com alguns detalls tècnics i una visió general de la lògica. Recomano molt llegir-lo almenys una vegada abans de continuar, ja que ara ho explicaré i ho faré.
Esquema 1: Vista general oficial del mètode d'autorització del cònsol
Mirem-hi .
Per descomptat, hi ha informació útil, però no hi ha cap guia sobre com utilitzar-ho realment tot. Així, com qualsevol persona sensata, recorreu Internet per guiar-vos. I després... Ser derrotat. Això passa. Arreglem això.
Abans de passar a crear el nostre POC, tornem a la visió general dels mètodes d'autorització de cònsols (Diagrama 1) i refiem-lo en el context de Kubernetes.
arquitectura
En aquest tutorial, crearem un servidor Consul en una màquina independent que interactuarà amb un clúster de Kubernetes amb el client Consul instal·lat. Aleshores, crearem la nostra aplicació simulada al pod i utilitzarem el nostre mètode d'autorització configurat per llegir des de la nostra botiga de claus/valors de Cònsol.
El diagrama següent mostra amb detall l'arquitectura que creem en aquest tutorial, així com la lògica del mètode d'autorització, que s'explicarà més endavant.
Diagrama 2: visió general del mètode d'autorització de Kubernetes
Una nota ràpida: el servidor Consul no necessita viure fora del clúster de Kubernetes perquè això funcioni. Però sí, pot de qualsevol manera.
Per tant, prenent l'esquema general de Consul (esquema 1) i aplicant-hi Kubernetes, obtenim l'esquema anterior (esquema 2), i aquí la lògica serà la següent:
- Cada pod tindrà un compte de servei adjunt, que conté un testimoni JWT generat i conegut per Kubernetes. Aquest testimoni també s'insereix al pod de manera predeterminada.
- La nostra aplicació o servei dins d'un pod iniciarà una ordre d'inici de sessió al nostre client Cònsol. La sol·licitud d'inici de sessió també inclourà el nostre testimoni i nom creat especialment mètode d'autorització (com Kubernetes). Aquest pas #2 correspon al pas 1 del circuit Cònsol (Diagrama 1).
- El nostre client Cònsol reenviarà aquesta sol·licitud al nostre servidor Cònsol.
- MÀGIA! Aquí és on el servidor Cònsol autentica la sol·licitud, recull la identitat de la sol·licitud i la compara amb qualsevol regla predefinida associada. A continuació es mostra un altre diagrama per il·lustrar-ho. Aquest pas correspon als passos 3, 4 i 5 del diagrama general de Cònsol (Diagrama 1).
- El nostre servidor Cònsol genera un testimoni Cònsol amb permisos d'acord amb les regles del mètode d'autorització que hem especificat (que hem definit) pel que fa a la identitat del sol·licitant. Aleshores enviarà aquest testimoni. Això correspon al pas 6 de l'esquema Cònsol (Diagrama 1).
- El nostre client Cònsol reenvia el testimoni a l'aplicació o servei sol·licitant.
La nostra aplicació o servei ara pot utilitzar aquest testimoni de cònsol per comunicar-se amb les nostres dades de cònsol, tal com defineixen els privilegis del testimoni.
La màgia es revela!
Per a aquells de vosaltres que no esteu contents amb només un conillet fora d'un barret i voleu saber com funciona... deixeu-me "ensenyar-vos a quina profunditat forat del conill».
Com s'ha esmentat anteriorment, el nostre pas "màgic" (Esquema 2: Pas 4) és que el servidor Cònsol autentiqui la sol·licitud, reculli informació sobre la sol·licitud i la compare amb qualsevol regla predefinida associada. Aquest pas correspon als passos 3, 4 i 5 del diagrama general de Cònsol (Diagrama 1). A continuació es mostra un diagrama (esquema 3), el propòsit del qual és mostrar clarament el que està passant sota el capó mètode d'autorització de Kubernetes específic.
Diagrama 3: La màgia es revela!
- Com a punt de partida, el nostre client Cònsol reenvia la sol·licitud d'inici de sessió al nostre servidor Cònsol amb el testimoni del compte de Kubernetes i el nom de la instància específica del mètode d'autorització que hem creat anteriorment. Aquest pas correspon al pas 3 de l'explicació del diagrama anterior.
- Ara el servidor Cònsol (o líder) ha de verificar l'autenticitat del testimoni rebut. Per tant, consultarà amb el clúster Kubernetes (a través del client Cònsol) i, amb els permisos corresponents, esbrinarem si el testimoni és autèntic i qui n'és el propietari.
- A continuació, la sol·licitud validada es retorna al líder del Cònsol i es cerca al servidor Cònsol una instància del mètode d'autorització amb el nom especificat de la sol·licitud d'inici de sessió (i el tipus de Kubernetes).
- El líder del cònsol determina la instància del mètode d'autorització especificada (si es troba) i llegeix el conjunt de regles vinculants que s'hi adjunten. A continuació, llegeix aquestes regles i les compara amb els atributs d'identitat verificats.
- TA-dah! Aneu al pas 5 de l'explicació del circuit anterior.
Executeu Consul-server en una màquina virtual normal
A partir d'ara, donaré principalment instruccions per crear aquest POC, sovint en paràgrafs, sense frases senceres explicatives. A més, com s'ha indicat anteriorment, utilitzaré GCP per crear tota la infraestructura, però podeu crear la mateixa infraestructura en qualsevol altre lloc.
- Inicieu la màquina virtual (instància/servidor).
- Creeu una regla de tallafoc (un grup de seguretat a AWS):
- M'agrada assignar el mateix nom de màquina a la regla i a l'etiqueta de xarxa, en aquest cas "skywiz-consul-server-poc".
- Cerqueu l'adreça IP del vostre ordinador local i afegiu-la a la llista d'adreces IP d'origen perquè puguem accedir a la interfície d'usuari (UI).
- Obre el port 8500 per a la IU. Feu clic a Crear. Tornarem a canviar aquest tallafoc aviat [].
- Afegiu una regla de tallafoc a la instància. Torneu al tauler de VM al servidor Cònsol i afegiu "skywiz-consul-server-poc" al camp d'etiquetes de xarxa. Feu clic a Desa.
- Instal·leu Consul en una màquina virtual, comproveu aquí. Recordeu que necessiteu la versió Consul ≥ 1.5 [enllaç]
- Creem un sol node Cònsol: la configuració és la següent.
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- Per obtenir una guia més detallada sobre la instal·lació de Consul i la configuració d'un clúster de 3 nodes, vegeu .
- Creeu el fitxer /etc/consul.d/agent.json com aquest []:
### /etc/consul.d/agent.json
{
"acl" : {
"enabled": true,
"default_policy": "deny",
"enable_token_persistence": true
}
}- Inicieu el nostre servidor Cònsol:
consul agent
-server
-ui
-client 0.0.0.0
-data-dir=/var/lib/consul
-bootstrap-expect=1
-config-dir=/etc/consul.d- Hauríeu de veure un munt de resultats i, finalment, "... actualització bloquejada per ACL".
- Cerqueu l'adreça IP externa del servidor Cònsol i obriu un navegador amb aquesta adreça IP al port 8500. Assegureu-vos que s'obre la interfície d'usuari.
- Proveu d'afegir un parell clau/valor. Hi ha d'haver un error. Això es deu al fet que vam carregar el servidor Cònsol amb una ACL i vam negar totes les regles.
- Torneu al vostre intèrpret d'ordres al servidor de Cònsol i inicieu el procés en segon pla o d'una altra manera perquè funcioni i escriviu el següent:
consul acl bootstrap- Cerqueu el valor "SecretID" i torneu a la IU. A la pestanya ACL, introduïu l'ID de testimoni secret que acabeu de copiar. Copieu el SecretID en un altre lloc, el necessitarem més tard.
- Ara afegiu un parell clau/valor. Per a aquest POC, afegiu el següent: clau: "custom-ns/test_key", valor: "Estic a la carpeta custom-ns!"
Inici d'un clúster de Kubernetes per a la nostra aplicació amb el client Consul com a Daemonset
- Creeu un clúster K8s (Kubernetes). El crearem a la mateixa zona que el servidor per a un accés més ràpid i així podem utilitzar la mateixa subxarxa per connectar fàcilment amb les IP internes. L'anomenarem "skywiz-app-with-consul-client-poc".
- Com a nota al marge, aquí teniu una bona guia que vaig trobar quan vaig configurar un clúster de Consul POC amb Consul Connect.
- També utilitzarem el gràfic Hashicorp amb un fitxer de valors estès.
- Instal·leu i configureu Helm. Passos de configuració:
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- gràfic del timó:
- Utilitzeu el fitxer de valors següent (nota que he desactivat la majoria):
### 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- Aplica el gràfic del timó:
./helm install -f poc-helm-consul-values.yaml ./consul-helm - name skywiz-app-with-consul-client-poc- Quan intenti executar-se, necessitarà permisos per al servidor Cònsol, així que anem a afegir-los.
- Observeu l'"Interval d'adreces del pod" que es troba al tauler de control del clúster i torneu a la nostra regla de tallafocs "skywiz-consul-server-poc".
- Afegiu l'interval d'adreces del pod a la llista d'adreces IP i els ports oberts 8301 i 8300.
- Aneu a la interfície d'usuari de Cònsol i en uns minuts veureu que el nostre clúster apareix a la pestanya dels nodes.
Personalització del mètode d'autorització mitjançant la integració de Consul amb Kubernetes
- Torneu a l'intèrpret d'ordres del servidor Consul i exporteu el testimoni que heu desat anteriorment:
export CONSUL_HTTP_TOKEN=<SecretID>- Necessitem informació del nostre clúster de Kubernetes per crear una instancia del mètode d'autenticació:
- amfitrió de kubernetes
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:- El testimoni està codificat en base64, així que desxifra-lo amb la vostra eina preferida []
- kubernetes-ca-cert
kubectl get secret <secret_name_from_prev_command> -o yaml | grep ca.crt:- Agafeu el certificat "ca.crt" (després de la descodificació base64) i poseu-lo al fitxer "ca.crt".
- Ara instanciïu el mètode d'autenticació, substituint els marcadors de posició amb els valors que acabeu de rebre.
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>"- A continuació, hem de crear una regla i adjuntar-la al nou rol. Per a aquesta part, podeu utilitzar la interfície d'usuari de Consul, però farem servir la línia d'ordres.
- Escriu una regla
### kv-custom-ns-policy.hcl
key_prefix "custom-ns/" {
policy = "write"
}- Aplicar la regla
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- Cerqueu l'ID de la regla que acabeu de crear a la sortida.
- Creeu un rol amb una regla nova.
consul acl role create
-name "custom-ns-role"
-description "This is an example role for custom-ns namespace"
-policy-id <policy_id>- Ara associarem el nostre nou rol amb la instància del mètode auth. Tingueu en compte que el senyalador "selector" determina si la nostra sol·licitud d'inici de sessió rebrà aquesta funció. Consulteu aquí altres opcions de selecció:
consul acl binding-rule create
-method=auth-method-skywiz-consul-poc
-bind-type=role
-bind-name='custom-ns-role'
-selector='serviceaccount.namespace=="custom-ns"'Configuracions al final
Drets d'accés
- Crea permisos. Hem de donar permís a Consul per verificar i identificar la identitat del testimoni del compte de servei K8s.
- Escriu el següent al fitxer :
###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- Creem drets d'accés
kubectl create -f skywiz-poc-consul-server_rbac.yamlConnexió al client Cònsol
- Com ja s'ha mencionat , hi ha diverses opcions per connectar-se al conjunt de dimonis, però passarem a la següent solució senzilla:
- Aplica el següent fitxer [].
### 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- A continuació, utilitzeu la següent comanda integrada per crear un mapa de configuració []. Tingueu en compte que ens referim al nom del nostre servei, canvieu-lo si cal.
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}')"]}
EOFProva el mètode d'autenticació
Ara veiem la màgia en acció!
- Creeu unes quantes carpetes de claus més amb la mateixa clau de nivell superior (és a dir, /sample_key) i un valor que escolliu. Crear les polítiques i els rols adequats per als nous camins clau. Les enquadernacions les farem més tard.
Prova d'espai de noms personalitzada:
- Creem el nostre propi espai de noms:
kubectl create namespace custom-ns- Creem un pod al nostre nou espai de noms. Escriu la configuració del pod.
###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- Crea a sota:
kubectl create -f poc-ubuntu-custom-ns.yaml- Un cop el contenidor estigui en funcionament, aneu-hi i instal·leu curl.
kubectl exec poc-ubuntu-custom-ns -n custom-ns -it /bin/bash
apt-get update && apt-get install curl -y- Ara enviarem una sol·licitud d'inici de sessió al Consul mitjançant el mètode d'autorització que hem creat anteriorment [].
- Per veure el testimoni introduït des del vostre compte de servei:
cat /run/secrets/kubernetes.io/serviceaccount/token- Escriu el següent en un fitxer dins del contenidor:
### payload.json
{
"AuthMethod": "auth-method-test",
"BearerToken": "<jwt_token>"
}- Iniciar Sessió!
curl
--request POST
--data @payload.json
consul-ds-client.default.svc.cluster.local/v1/acl/login- Per executar els passos anteriors en una línia (ja que farem diverses proves), podeu fer el següent:
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- Funciona! Hauria, almenys. Ara agafeu el SecretID i proveu d'accedir a la clau/valor al qual hem de tenir accés.
curl
consul-ds-client.default.svc.cluster.local/v1/kv/custom-ns/test_key --header “X-Consul-Token: <SecretID_from_prev_response>”- Podeu descodificar "Value" base64 i veure que coincideix amb el valor de custom-ns/test_key a la interfície d'usuari. Si utilitzeu el mateix valor que es va indicar anteriorment en aquesta guia, el vostre valor codificat seria IkknbSBpbiB0aGUgY3VzdG9tLW5zIGZvbGRlciEi.
Prova del compte del servei d'usuari:
- Creeu un compte de servei personalitzat amb l'ordre següent [].
kubectl apply -f - <<EOF
apiVersion: v1
kind: ServiceAccount
metadata:
name: custom-sa
EOF- Creeu un fitxer de configuració nou per al pod. Tingueu en compte que vaig incloure la instal·lació de curl per estalviar mà d'obra :)
###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- Després d'això, inicieu una closca dins del recipient.
kubectl exec -it poc-ubuntu-custom-sa /bin/bash- Iniciar Sessió!
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- Permís denegat. Ah, ens hem oblidat d'afegir una nova vinculació de regles amb els permisos adequats, fem-ho ara.
Repetiu els passos anteriors anteriors:
a) Creeu una política idèntica per al prefix "custom-sa/".
b) Creeu un rol, anomeneu-lo "custom-sa-role"
c) Adjuntar la Política al Rol.
- Creeu una unió de regles (només possible des de cli/api). Observeu el valor diferent de la bandera del selector.
consul acl binding-rule create
-method=auth-method-skywiz-consul-poc
-bind-type=role
-bind-name='custom-sa-role'
-selector='serviceaccount.name=="custom-sa"'- Torneu a iniciar sessió des del contenidor "poc-ubuntu-custom-sa". Èxit!
- Comproveu el nostre accés a la ruta de la clau personalitzada-sa/.
curl
consul-ds-client.default.svc.cluster.local/v1/kv/custom-sa/test_key --header “X-Consul-Token: <SecretID>”- També podeu assegurar-vos que aquest testimoni no atorgui accés a kv a "custom-ns/". Només heu de repetir l'ordre anterior després de substituir "custom-sa" pel prefix "custom-ns".
Permís denegat.
Exemple de superposició:
- Val la pena assenyalar que totes les coincidències vinculants de regles s'afegiran al testimoni amb aquests drets.
- El nostre contenidor "poc-ubuntu-custom-sa" es troba a l'espai de noms predeterminat, així que utilitzem-lo per a una altra vinculació de regles.
- Repetiu els passos anteriors:
a) Creeu una política idèntica per al prefix de clau "predeterminat/".
b) Creeu un rol, anomeneu-lo "default-ns-role"
c) Adjuntar la Política al Rol. - Creeu una unió de regles (només possible des de 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"'- Torneu al nostre contenidor "poc-ubuntu-custom-sa" i intenteu accedir al camí kv "predeterminat/".
- Permís denegat.
Podeu veure les credencials especificades per a cada testimoni a la interfície d'usuari a ACL > Fitxes. Com podeu veure, només hi ha un "rol personalitzat" adjunt al nostre testimoni actual. El testimoni que estem utilitzant actualment es va generar quan vam iniciar la sessió i només hi havia una vinculació de regles que coincidia. Hem de tornar a iniciar sessió i utilitzar el nou testimoni. - Assegureu-vos que podeu llegir els camins kv "custom-sa/" i "default/".
Èxit!
Això es deu al fet que el nostre "poc-ubuntu-custom-sa" coincideix amb els enllaços de regles "custom-sa" i "default-ns".
Conclusió
Gestió de testimonis TTL?
En el moment d'escriure aquest article, no hi ha cap manera integrada de determinar el TTL dels testimonis generats per aquest mètode d'autorització. Seria una oportunitat fantàstica per proporcionar una automatització segura d'autoritzacions per al cònsol.
Hi ha una opció per crear manualment un testimoni amb TTL:
Temps de caducitat: el temps que es revocarà aquest testimoni. (Opcional; afegit a Cònsol 1.5.0)- Només existeix per a la creació/actualització manual
Amb sort, aviat podrem controlar com es generen els tokens (per a cada regla o mètode d'autorització) i afegir TTL.
Fins aleshores, es recomana utilitzar el punt final de tancament de sessió a la vostra lògica.
Llegiu també altres articles al nostre blog:
Font: www.habr.com