Así é, despois da liberación a principios de maio de 2019, en Consul podes autorizar aplicacións e servizos que se executan en Kubernetes de forma nativa.
Neste tutorial imos crear paso a paso (Proof of concept, PoC) que demostra esta nova función. Espérase que teñas coñecementos básicos sobre Kubernetes e o Consul de Hashicorp. Aínda que podes usar calquera plataforma na nube ou ambiente local, neste tutorial utilizaremos a plataforma na nube de Google.
Comentar
Se imos a , teremos unha visión xeral rápida do seu propósito e caso de uso, así como algúns detalles técnicos e unha visión xeral da lóxica. Recomendo encarecidamente lelo polo menos unha vez antes de continuar, xa que agora vou explicar e mastigar todo.
Diagrama 1: Panorámica oficial do método de autorización Cónsul
Imos mirar dentro .
Por suposto, hai información útil alí, pero non hai unha guía sobre como usalo todo. Entón, como calquera persoa sensata, percorres Internet en busca de orientación. E entón... Fallas. Ocorre. Imos arranxar isto.
Antes de pasar á creación do noso POC, volvamos á visión xeral dos métodos de autorización de Consul (Diagrama 1) e perfeccionemos no contexto de Kubernetes.
Arquitectura
Neste tutorial, crearemos un servidor Consul nunha máquina separada que se comunicará cun clúster de Kubernetes co cliente Consul instalado. A continuación, crearemos a nosa aplicación ficticia no pod e utilizaremos o noso método de autorización configurado para ler desde a nosa tenda de claves/valores Consul.
O diagrama a continuación detalla a arquitectura que estamos a crear neste tutorial, así como a lóxica detrás do método de autorización, que se explicará máis adiante.
Diagrama 2: Visión xeral do método de autorización de Kubernetes
Unha nota rápida: o servidor Consul non necesita vivir fóra do clúster de Kubernetes para que isto funcione. Pero si, pode facelo deste xeito e do outro.
Entón, tomando o diagrama de visión xeral de Consul (Diagrama 1) e aplicando Kubernetes a el, obtemos o diagrama anterior (Diagrama 2), e a lóxica aquí é a seguinte:
- Cada pod terá unha conta de servizo anexa a el que contén un token JWT xerado e coñecido por Kubernetes. Este token tamén se insire no pod de forma predeterminada.
- A nosa aplicación ou servizo dentro do pod inicia un comando de inicio de sesión para o noso cliente Consul. A solicitude de inicio de sesión tamén incluirá o noso token e nome especialmente creado método de autorización (tipo Kubernetes). Este paso #2 corresponde ao paso 1 do diagrama Cónsul (Esquema 1).
- O noso cliente Cónsul reenviará esta solicitude ao noso servidor Cónsul.
- MAXIA! Aquí é onde o servidor Consul verifica a autenticidade da solicitude, recolle información sobre a identidade da solicitude e compáraa con calquera regras predefinidas asociadas. A continuación tes outro diagrama para ilustralo. Este paso corresponde aos pasos 3, 4 e 5 do diagrama xeral de Consul (Diagrama 1).
- O noso servidor Cónsul xera un token Cónsul con permisos segundo as nosas regras de método de autorización especificadas (que definimos) sobre a identidade do solicitante. Despois enviará ese token de volta. Isto corresponde ao paso 6 do diagrama Cónsul (Diagrama 1).
- O noso cliente Cónsul envía o token á aplicación ou servizo solicitante.
A nosa aplicación ou servizo agora pode usar este token de Cónsul para comunicarse cos datos dos nosos Cónsules, segundo o determinen os privilexios do token.
Revélase a maxia!
Para aqueles de vostedes que non están contentos con só un coello fóra dun sombreiro e queren saber como funciona... déixame "mostrarvos o profundo coello».
Como se mencionou anteriormente, o noso paso "máxico" (Figura 2: Paso 4) é onde o servidor Consul autentica a solicitude, recolle información sobre a solicitude e compáraa coas regras predefinidas asociadas. Este paso corresponde aos pasos 3, 4 e 5 do diagrama xeral de Consul (Diagrama 1). A continuación móstrase un diagrama (Diagrama 3), cuxo propósito é mostrar claramente o que realmente está a suceder debaixo do capó método de autorización específico de Kubernetes.
Diagrama 3: Revélase a maxia!
- Como punto de partida, o noso cliente Consul reenvía a solicitude de inicio de sesión ao noso servidor Consul co token da conta de Kubernetes e o nome de instancia específico do método de autorización que se creou anteriormente. Este paso corresponde ao paso 3 da explicación do circuíto anterior.
- Agora o servidor Consul (ou líder) debe verificar a autenticidade do token recibido. Por iso, consultará o clúster de Kubernetes (a través do cliente Consul) e, cos permisos adecuados, descubriremos se o token é xenuíno e a quen pertence.
- A solicitude validada devólvese entón ao líder de Consul e o servidor de Consul busca a instancia do método de autorización co nome especificado da solicitude de inicio de sesión (e do tipo de Kubernetes).
- O líder cónsul identifica a instancia do método de autorización especificado (se se atopa) e le o conxunto de regras vinculantes que se anexan a ela. Despois le estas regras e compáraas cos atributos de identidade verificados.
- TA-dah! Pasemos ao paso 5 da explicación do circuíto anterior.
Executa Consul-server nunha máquina virtual normal
A partir de agora, principalmente estarei dando instrucións sobre como crear este POC, moitas veces en viñetas, sen explicacións completas das frases. Ademais, como se indicou anteriormente, usarei GCP para crear toda a infraestrutura, pero podes crear a mesma infraestrutura en calquera outro lugar.
- Inicie a máquina virtual (instancia/servidor).
- Cree unha regra para o firewall (grupo de seguridade en AWS):
- Gústame asignar o mesmo nome de máquina tanto á regra como á etiqueta de rede, neste caso "skywiz-consul-server-poc".
- Busca o enderezo IP do teu ordenador local e engádeo á lista de enderezos IP de orixe para que poidamos acceder á interface de usuario (UI).
- Abre o porto 8500 para a IU. Fai clic en Crear. Cambiaremos de novo este firewall pronto [].
- Engade unha regra de firewall á instancia. Volva ao panel de control de VM en Consul Server e engade "skywiz-consul-server-poc" ao campo de etiquetas de rede. Fai clic en Gardar.
- Instala Consul nunha máquina virtual, consulta aquí. Lembra que necesitas a versión Consul ≥ 1.5 [link]
- Imos crear un único nodo Consul - a configuración é a seguinte.
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- Para obter unha guía máis detallada sobre a instalación de Consul e a configuración dun grupo de 3 nodos, consulte .
- Cree un ficheiro /etc/consul.d/agent.json do seguinte xeito []:
### /etc/consul.d/agent.json
{
"acl" : {
"enabled": true,
"default_policy": "deny",
"enable_token_persistence": true
}
}- Inicia o noso servidor Cónsul:
consul agent
-server
-ui
-client 0.0.0.0
-data-dir=/var/lib/consul
-bootstrap-expect=1
-config-dir=/etc/consul.d- Deberías ver unha morea de saídas e acabar con "... actualización bloqueada polas ACL".
- Busca o enderezo IP externo do servidor Consul e abre un navegador con este enderezo IP no porto 8500. Asegúrate de que se abra a IU.
- Proba a engadir un par clave/valor. Debe haber un erro. Isto ocorre porque cargamos o servidor Consul cunha ACL e desactivamos todas as regras.
- Volve ao teu shell no servidor Consul e inicia o proceso en segundo plano ou dalgún outro xeito de facelo funcionar e introduce o seguinte:
consul acl bootstrap- Busca o valor "SecretID" e volve á IU. Na pestana ACL, introduce o ID secreto do token que acabas de copiar. Copia SecretID noutro lugar, necesitarémolo máis tarde.
- Agora engade un par clave/valor. Para este POC, engade o seguinte: clave: "custom-ns/test_key", valor: "Estou no cartafol custom-ns!"
Lanzamento dun clúster de Kubernetes para a nosa aplicación co cliente Consul como Daemonset
- Crea un clúster K8s (Kubernetes). Crearémolo na mesma zona que o servidor para un acceso máis rápido, e así poderemos usar a mesma subrede para conectarnos facilmente cos enderezos IP internos. Chamámoslle "skywiz-app-with-consul-client-poc".
- Como nota lateral, aquí tes un bo tutorial que atopei ao configurar un clúster POC Consul con Consul Connect.
- Tamén usaremos o gráfico de timón de Hashicorp cun ficheiro de valores estendidos.
- Instalar e configurar Helm. Pasos de configuración:
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áfica de timón:
- Use o seguinte ficheiro de valores (ten en conta que a maioría desactivei):
### 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- Aplicar gráfico de timón:
./helm install -f poc-helm-consul-values.yaml ./consul-helm - name skywiz-app-with-consul-client-poc- Cando intente executarse, necesitará permisos para o servidor Consul, así que engadímolos.
- Teña en conta o "Intervalo de enderezos de pod" situado no panel de control do clúster e consulte a nosa regra de firewall "skywiz-consul-server-poc".
- Engade o intervalo de enderezos para o pod á lista de enderezos IP e abra os portos 8301 e 8300.
- Vaia á IU de Cónsul e despois duns minutos verá o noso clúster aparecer na pestana de nós.
Configurar un método de autorización integrando Consul con Kubernetes
- Volve ao shell do servidor Consul e exporta o token que gardou anteriormente:
export CONSUL_HTTP_TOKEN=<SecretID>- Necesitaremos información do noso clúster de Kubernetes para crear unha instancia do método de autenticación:
- kubernetes-host
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:- O token está codificado en base64, así que descifralo usando a túa ferramenta favorita []
- kubernetes-ca-cert
kubectl get secret <secret_name_from_prev_command> -o yaml | grep ca.crt:- Colle o certificado "ca.crt" (despois da decodificación base64) e escríbeo no ficheiro "ca.crt".
- Agora instancie o método de autenticación, substituíndo os marcadores de posición polos valores que acaba de recibir.
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ón, necesitamos crear unha regra e anexala ao novo rol. Para esta parte podes usar Consul UI, pero usaremos a liña de comandos.
- Escribe unha regra
### kv-custom-ns-policy.hcl
key_prefix "custom-ns/" {
policy = "write"
}- Aplica a regra
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- Busca o ID da regra que acabas de crear a partir da saída.
- Crea un rol cunha nova regra.
consul acl role create
-name "custom-ns-role"
-description "This is an example role for custom-ns namespace"
-policy-id <policy_id>- Agora asociaremos o noso novo rol coa instancia do método de autenticación. Teña en conta que o indicador "selector" determina se a nosa solicitude de inicio de sesión recibirá este rol. Consulta aquí outras opcións de selección:
consul acl binding-rule create
-method=auth-method-skywiz-consul-poc
-bind-type=role
-bind-name='custom-ns-role'
-selector='serviceaccount.namespace=="custom-ns"'Por último configuracións
Dereitos de acceso
- Crear dereitos de acceso. Necesitamos dar permiso a Consul para verificar e identificar a identidade do token da conta de servizo K8s.
- Escribe o seguinte no ficheiro :
###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- Imos crear dereitos de acceso
kubectl create -f skywiz-poc-consul-server_rbac.yamlConectando co cliente Consul
- Como se sinala Hai varias opcións para conectarse a daemonset, pero pasaremos á seguinte solución sinxela:
- Aplica o seguinte ficheiro [].
### 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ón, use o seguinte comando integrado para crear un mapa de configuración []. Teña en conta que nos referimos ao nome do noso servizo, substitúeo se é necesario.
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}')"]}
EOFProbando o método de autenticación
Agora imos ver a maxia en acción!
- Cree varios cartafoles de claves máis coa mesma clave de nivel superior (por exemplo, /sample_key) e un valor que elixas. Crear políticas e roles axeitados para novos camiños clave. Faremos as ataduras máis tarde.
Proba de espazo de nomes personalizado:
- Imos crear o noso propio espazo de nomes:
kubectl create namespace custom-ns- Imos crear un pod no noso novo espazo de nomes. Escriba a configuración para o 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- Crear baixo:
kubectl create -f poc-ubuntu-custom-ns.yaml- Unha vez que o contedor estea funcionando, vai alí e instala Curl.
kubectl exec poc-ubuntu-custom-ns -n custom-ns -it /bin/bash
apt-get update && apt-get install curl -y- Agora enviaremos unha solicitude de inicio de sesión a Consul usando o método de autorización que creamos anteriormente [].
- Para ver o token introducido desde a túa conta de servizo:
cat /run/secrets/kubernetes.io/serviceaccount/token- Escribe o seguinte nun ficheiro dentro do contedor:
### payload.json
{
"AuthMethod": "auth-method-test",
"BearerToken": "<jwt_token>"
}- Acceder!
curl
--request POST
--data @payload.json
consul-ds-client.default.svc.cluster.local/v1/acl/login- Para completar os pasos anteriores nunha liña (xa que faremos varias probas), podes facer o seguinte:
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! Polo menos debería. Agora tome o SecretID e intente acceder á chave/valor ao que deberíamos ter acceso.
curl
consul-ds-client.default.svc.cluster.local/v1/kv/custom-ns/test_key --header “X-Consul-Token: <SecretID_from_prev_response>”- Podes decodificar "Value" en base64 e ver que coincide co valor de custom-ns/test_key na IU. Se utilizaches o mesmo valor anterior neste tutorial, o teu valor codificado sería IkknbSBpbiB0aGUgY3VzdG9tLW5zIGZvbGRlciEi.
Proba da conta de servizo de usuario:
- Crea unha conta de servizo personalizada usando o seguinte comando [].
kubectl apply -f - <<EOF
apiVersion: v1
kind: ServiceAccount
metadata:
name: custom-sa
EOF- Crea un novo ficheiro de configuración para o pod. Teña en conta que incluín a instalación de rizos para aforrar traballo :)
###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- Despois diso, execute unha cuncha dentro do recipiente.
kubectl exec -it poc-ubuntu-custom-sa /bin/bash- Acceder!
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- Permiso denegado. Ah, esquecémonos de engadir novas regras vinculantes cos permisos adecuados, imos facelo agora.
Repita os pasos anteriores anteriores:
a) Cree unha política idéntica para o prefixo “custom-sa/”.
b) Crea un rol, chámao "custom-sa-role"
c) Anexar a Política ao Rol.
- Crear unha vinculación de regras (só é posible desde cli/api). Teña en conta o significado diferente da bandeira de selección.
consul acl binding-rule create
-method=auth-method-skywiz-consul-poc
-bind-type=role
-bind-name='custom-sa-role'
-selector='serviceaccount.name=="custom-sa"'- Inicie sesión de novo desde o contedor "poc-ubuntu-custom-sa". Éxito!
- Consulte o noso acceso ao camiño personalizado-sa/key.
curl
consul-ds-client.default.svc.cluster.local/v1/kv/custom-sa/test_key --header “X-Consul-Token: <SecretID>”- Tamén podes asegurarte de que este token non concede acceso a kv en "custom-ns/". Só tes que repetir o comando anterior despois de substituír "custom-sa" polo prefixo "custom-ns".
Permiso denegado.
Exemplo de superposición:
- Paga a pena ter en conta que todas as asignacións de vinculación de regras engadiranse ao token con estes dereitos.
- O noso contedor "poc-ubuntu-custom-sa" está no espazo de nomes predeterminado, así que utilímolo para unha vinculación de regras diferente.
- Repita os pasos anteriores:
a) Cree unha política idéntica para o prefixo da chave "predeterminado/".
b) Crea un rol, nomeao "default-ns-role"
c) Anexar a Política ao Rol. - Crear un enlace de regras (só posible desde 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"'- Volve ao noso contedor "poc-ubuntu-custom-sa" e tenta acceder á ruta kv "predeterminada/".
- Permiso denegado.
Podes ver as credenciais especificadas para cada token na IU en ACL > Tokens. Como podes ver, o noso token actual só ten un "papel personalizado". O token que estamos a usar actualmente foi xerado cando iniciamos sesión e só había unha vinculación de regras que coincidía entón. Necesitamos iniciar sesión de novo e usar o novo token. - Asegúrate de poder ler tanto as rutas kv "custom-sa/" como "default/".
Éxito!
Isto débese a que o noso "poc-ubuntu-custom-sa" coincide cos enlaces de regras "custom-sa" e "default-ns".
Conclusión
Xestión de tokens TTL?
No momento de escribir este artigo, non existe un xeito integrado de determinar o TTL dos tokens xerados por este método de autorización. Sería unha oportunidade fantástica para proporcionar unha automatización segura da autorización Cónsul.
Hai unha opción para crear manualmente un token con TTL:
Tempo de caducidade: o momento no que se revogará este token. (Opcional; engadido en Consul 1.5.0)- Existe só para a creación/actualización manual
Esperemos que nun futuro próximo poidamos controlar como se xeran os tokens (por regra ou método de autorización) e engadir TTL.
Ata entón, suxírese que use un punto final de saída na súa lóxica.
Lea tamén outros artigos no noso blog:
Fonte: www.habr.com