Parte 1…

A quem se destina…

Para administradores de sistema, devops operators e engineers, líderes técnicos e administrativos, curiosos e preguiçosos ;-)….

Nesse artigo foram aplicados jargões técnicos, linhas de comando, fragmentos de código e acesso a códigos fontes de minha autoria e de terceiros, com todos seus direitos e licenças reservados.

O começo…

Surgiu como uma necessidade de;

“ — Não temos uma plataforma robusta para orquestrar nossos containers/microserviços;
 — Precisamos dar acesso ao time de desenvolvimento aos serviços, logs e aplicações de cada namespace mas sem liberar acesso á console ou a todos os componentes core do kubernetes, inclusive queremos separar as equipes de cada sistema em seus respectivos namespaces;
 — Já temos um serviço de diretório, não quero mais um …
 —A criação de usuário e sua administração no Kubernetes é demasiada complexa …. (huhUAhuHAuHha, preguiçoso, vai estudar).”

Então, para você, DevOps Engineer, que precisa fazer essa integração ou quer testar como funciona e não implementar um Openshift/OKD ou Rancher, ou outra solução; pode ser que isso seja útil mais cedo ou mais tarde.

Não que as soluções PaaS não atendam as necessidades e/ou expectativas, mas que seu custo de suporte, linha de aprendizagem ou até mesmo as camadas de orquestração pesem no momento da administração e é preferido o bom e velho Kubernetes “roots” e puro, e sim, autenticando em algum lugar, mantendo meu SSO (single sign on).

O acesso á console dos servidores masters ou até mesmo o custo de uma maquina bastion só para essa finalidade, gerenciamento de componentes do kubernetes; é por muitas vezes cara, insegura com auditoria complexa, questionável entre outros pontos.

O assunto é pouco tratado e os resultados de busca pela internet nos trazem informações incompletas, nebulosas, com falta de opções para realidades distintas e que deixam a desejar no que tange a respostas e a questões e dúvidas dos leitores.

Caso você tenha alguma dúvida ou opinião, por favor, sinta-se a vontade para expressar e me contatar, no que puder e estiver ao meu alcance eu te ajudo :-)

Sem mais delongas, vamos ao que interessa... mão na massa, ops, mão no teclado (porque mouse é para preguiçoso)…

Opções disponíveis …

Depois de quase morrer por falta de algumas 3 noites sem dormir, consegui aplicar 2 soluções distintas mas que por dentro, utilizam-se dos mesmos componentes;

• Openunison da Tremolo Security

• DEX + Gangway + Oauth2-proxy

Confesso que as duas atendem completamente as necessidades, há diferenças na implementação e no entendimento mas funcionam.

O Openunison, pelo que pesquisei, é uma solução em java, escrita pela Tremolo Security com o DEX encapsulado para autenticação no AD e então manipula, cria token e libera acesso ao kubernetes.

A solução dex + gangway + oauth-proxy é mais leve, escrita em GO nas 3 camadas, ou seja, leve e simples mas que exige suor para personalização se você quiser implementar como portal de autenticação para seus usuários.

TL;DR;

Prereqs para implementar a solução Openunison

1 — Kubernetes instalado e com kube-apiserver configurado para autenticação utilizando RBAC (calma, vou te mostrar como fazer), Kubernetes Dashboard também implementado;

2 — Certificados SSL/TLS, auto assinados ou assinados por entidades “do céu” ( também chamados válidos ) para suas URLs;

• URL de acesso principal ( site onde os usuários vão se autenticar ), é o portal/aplicação Openunison, que vai gerar e gerenciar seu token de acesso ao kubernetes, tanto via kubectl num windows ou linux tanto via dashboard.

• URL do dashboard do Kubernetes. é a URL do seu dashboard

3 — Contas de usuários e respectivos grupos vinculados para validar a solução.

4 — Kubernetes Ingress Controller, dê preferencia ao NGINX, funciona, tem documentação vasta. Embora eu utilize profissionalmente o Traefik 2.0 , esse ainda não dá todas as facilidades do NGINX.

5 —quanto ao dashboard do kubernetes, já instalado e com ingress criado para seu acesso externo, como inseguro, na porta 80.

6 — acesso root, claaaaro…

Criando base de configuração

No seu servidor Master ou onde tiver o kubectl operacional e com a configuração pro seu cluster, crie duas pastas ; orchestra-configmaps e orchestra-secrets.

[root@server1]# mkdir deploy && cd deploy
[root@server1 deploy]# mkdir orchestra-configmaps orchestra-secrets

Na pasta orchestra-configmaps, crie um arquivo input.props com o seguinte conteúdo:

[root@server1 deploy/orchestra-configmaps]# cat input.props
OU_HOST=portaldousuario.meudominio.net
K8S_DASHBOARD_HOST=dash-k8s.meudominio.net
K8S_URL=https://k8s-master1.meudominio.net:6443
AD_BASE_DN=cn=users,dc=ent2k12,dc=domain,dc=com
AD_HOST=192.168.2.75
AD_PORT=636
AD_BIND_DN=cn=Administrator,cn=users,dc=ent2k12,dc=domain,dc=com
AD_CON_TYPE=ldaps
SRV_DNS=false
OU_CERT_OU=k8s
OU_CERT_O=Minha Empresa
OU_CERT_L=Atlantida
OU_CERT_ST=Bahia
OU_CERT_C=BR
USE_K8S_CM=true
SESSION_INACTIVITY_TIMEOUT_SECONDS=900
MYVD_CONFIG_PATH=WEB-INF/myvd.conf
[root@server1 deploy/orchestra-configmaps]#

Dentro de orchestra-secrets crie outro arquivo input.props com o conteúdo a seguir;

[root@server1 deploy/orchestra-secrets]# cat input.props
AD_BIND_PASSWORD=password
unisonKeystorePassword=start123
[root@server1 deploy/orchestra-secrets]#

Sendo que [root@server1 deploy/orchestra-configmaps]# cat input.props

Propriedade — — — — — — — —Descrição
OU_HOST ……………………….A URL para acessar o sistema de geração de token. O usuário vai acessar essa URL inicial.
K8S_DASHBOARD_HOST …….A URL do seu dashboard do kubernetes. é a URL que outrora cadastrou no seu ingress para acessar a dash do k8s externamente. NOTE: OU_HOST e K8S_DASHBOARD_HOST DEVEM compartilhar o mesmo dominio DNS. Ambos OU_HOST eK8S_DASHBOARD_HOST direcionarão para o deploy do Openunison no mesmo ingress.
K8S_URL ……………………….A URL do seu kubernetes, kube-apiserver.
AD_BASE_DN ………………….Ponto inicial de busca do seu AD.
AD_HOST ………………………O hostname ou IP ou o VIP do seu AD. Se está usando SRV records para apontar para os hosts, este hostname deve ser o fqdn, hostname-vip.dominio.
AD_PORT………………………. A porta TCP do AD, 636 para SSL.
AD_BIND_DN …………………..A conta criada que possa fazer busca no AD.
AD_CON_TYPE.….….….….…..ldaps para SSL, ldap para plain text
SRV_DNS ……………………….Se true, OpenUnison vai procurar no DNS a entrada para o domain SRV DNS.
OU_CERT_OU ………………….OU é o atributo de exibição do certificado interno da aplicação Openunison.
OU_CERT_O ……………………O é mais um atributo do certificado interno.
OU_CERT_L …………………….L é mais um atributo do certificado interno.
OU_CERT_ST…………………...ST é mais um atributo do certificado.
OU_CERT_C……………………..C é mais um atributo do certificado.
USE_K8S_CM……………………Se true, para usar seu certificado buitin do kubernetes. false se a sua instalação for Rancher ou Canonical.
SESSION_INACTIVITY_TIMEOUT_SECONDS…….Quantos segundos de inatividade para a sessão ser finalizada, dentro da aplicação de Openunison, não no dashboard do kubernetes.
MYVD_CONFIG_PATH…………Para multiplos ADs, ou LDAP edite esse arquivo, mais informaçãoes no site da Tremolo Security.
K8S_DASHBOARD_NAMESPACE…..Qual o namespace do seu dashboard. Para versão 1.x de dashboard é kube-system, para versão 2.x é kubernetes-dashboard
K8S_CLUSTER_NAME…………Opcional Se especificado, o nome do seu cluster kubernetes dentro do ./kube-config. O padrão é kubernetes.

Já no [root@server1 deploy/orchestra-configmaps]# cat input.props

Propriedade — — — — — — — — — — Descrição
AD_BIND_PASSWORD.…………….A senha do AD_BIND_DN.
unisonKeystorePassword…..……..A senha, a seu gosto, para o keystore java da aplicação.

Com isso pronto, agora é preciso copiar os certificados das URLs acima para a pasta orchestra-configmaps, no formato .pem (que é uma cópia com extensão .pem de um certificado .crt. Ou seja, copie o arquivo .crt do seu certificado auto assinado para o arquivo com mesmo nome, mas com extensão .pem, pra quem não entendeu segue o comando, preguiçoso ;-)

[root@server1]# cat portaldousuario.meudominio.net.crt
-----BEGIN CERTIFICATE-----
LKlkJHopoipiASAsaasakjhJKLhakJASSAAdd.........
.............bla bla bla
-----END CERTIFICATE-----
[root@server1]#
[root@server1]# cp portaldousuario.meudominio.net.crt deploy/orchestra-configmaps/portaldousuario.meudominio.net.pem
[root@server1]#
[root@server1]# cp dash-k8s.meudominio.net.crt deploy/orchestra-configmaps/dash-k8s.meudominio.net.pem

É isso mesmo, o .pem é igual ao .crt, sem .key, sem conversão, sem frescura ;-)

Caso não seja familiarizado com certificados, criei um script que faz isso, pode baixa-lo no meu github. Se for um pouco mais atento, verificará a lógica desse script é fácil , o que torna o entendimento da utilização do openssl para geração e manutenção de certificados uma tarefa trivial.

Deploy do Openunison by Tremolo Security

Execute dentro do diretório deploy;

[root@server1]# curl https://raw.githubusercontent.com/TremoloSecurity/kubernetes-artifact-deployment/master/src/main/bash/deploy_openunison.sh | bash -s /path/to/orchestra-configmaps /path/to/orchestra-secrets https://raw.githubusercontent.com/OpenUnison/openunison-k8s-login-activedirectory/master/src/main/yaml/artifact-deployment.yaml

@#$% Não pressione ENTER. Vamos prestar atenção no comando;

Perceba aqui, que o caminho para os diretórios configmaps e secrets DEVEM SER O CAMINHO COMPLETO, e sem “/” no fim.

:-) Pode pressionar o ENTER …. ;-)

Vamos lá analisar o que o pessoal da Tremolo fez; criou um java script que ;

• lê as configurações, os input.props e os certificados,

• cria um namespace, openunison-deploy

• cria secrets para as configurações, os certificados, a chave interna da aplicação,

• a partir da execução desse javascript, com todos esses parametros, é criado um novo namespace, openunison.

• cria os configmaps, secrets, users, tokens, roles, rolebindings, apiservices, deployments e mais outros componentes para o namespace openunison,

• carrega as imagens do hub.docker deles. ( eu scaneei por medida de segurança e não houve problemas sérios ) Caso se sinta mais seguro, recompile a imagem removendo os shells, mas mantendo os ports, endpoints e se possível, mantenha os labels para dar os devidos créditos á Tremolo. Afinal, foram eles que criaram. ;-)

Sua console vai ficar mais ou menos assim;

namespace/openunison-deploy created
configmap/extracerts created
secret/input created
clusterrolebinding.rbac.authorization.k8s.io/artifact-deployment created
job.batch/artifact-deployment created
NAME READY STATUS RESTARTS AGE
artifact-deployment-jzmnr 0/1 Pending 0 0s
artifact-deployment-jzmnr 0/1 Pending 0 0s
artifact-deployment-jzmnr 0/1 ContainerCreating 0 0s
artifact-deployment-jzmnr 1/1 Running 0 4s
artifact-deployment-jzmnr 0/1 Completed 0 15s

Quando o pod artifact-deployment ficar “Completed”, pode sair com Ctrl+C.

Vamos ver os logs e fazer o que manda o maestro;

[root@server1 ~]# kubectl get po -n openunison-deploy
NAME READY STATUS RESTARTS AGE
artifact-deployment-jzmnr 0/1 Completed 0 2d1h
[root@server1 ~]# kubectl logs artifact-deployment-jzmnr -n openunison-deploy
Processing - '/etc/extracerts/........blablabla.....
Artifacts Created, to configure the API server run 'kubectl describe configmap api-server-config -n openunison'
[root@server1 ~]#
[root@server1 ~]# kubectl describe configmap api-server-config -n openunison
Name: api-server-config
Namespace: openunison
Labels: <none>
Annotations: <none>

Data
====
oidc-api-server-flags:
----
--oidc-issuer-url=https://portaldousuario.meudominio.net/auth/idp/k8sIdp
--oidc-client-id=kubernetes
--oidc-username-claim=sub
--oidc-groups-claim=groups
--oidc-ca-file=/etc/kubernetes/pki/ou-ca.pem
Events: <none>
[root@bastion-0 ~]#

Confira o novo namespace e se tem os dois Pods openunison-orchestra e openunison-operator no ar, veja seus logs….

[root@server1 ]# kubectl get pod -n openunison
NAME READY STATUS RESTARTS AGE
openunison-operator-757cf446d9-dzkml 1/1 Running 0 20s
openunison-orchestra-58cd55577d-9n5c9 1/1 Running 0 20s
[root@server1 ]#

Dentro de uma secret, ou-tls-certificate, há um certificado e uma chave privada, criados baseado nos outros dois .pem das URLs que serão acessíveis, o dashboard do kubernetes em si e o portal de autenticação e geração de token que foram disponibilizados no passo anterior.

É preciso resgata-los e disponibiliza-los para uso do kube-apiserver.

Há duas chaves nessa secret, tls.crt e tls.key, copie, echo e decodifique, salvando o tls.crt já com extensão .pem, como a seguir ;

[root@server1 ~]# kubectl get secret ou-tls-certificate -n openunison -o yaml
apiVersion: v1
data:
tls.crt: LS0tLS1CRUdJ...blablabla 0tLS0tCg==
tls.key: LS0tLS1CRUd....blablabla...LS0tLS0K
kind: Secret
metadata:
creationTimestamp: "2019-and smokeZ"
labels:
operated-by: openunison-operator
tremolo_operator_created: "true"
name: ou-tls-certificate
namespace: openunison
resourceVersion: "1479068"
selfLink: /api/v1/namespaces/openunison/secrets/ou-tls-certificate
uid: 1020959cxxxxxxxxxxxxxxxxx572af
type: kubernetes.io/tls
[root@server1 ~]# echo "LS0tLS...blablabla....RVJ0FURS0tLS0tCg==" | base64 -d > /etc/kubernetes/pki/ou-ca.pem
[root@server1 ~]#
[root@server1 ~]# echo "LS0tLS1CR....blablabla.....BVS0VZLS0tLS0K" | base64 -d > /etc/kubernetes/pki/ou-ca.key
[root@server1 ~]# chmod 0600 /etc/kubernetes/pki/ou-ca.key
[root@server1 ~]# ls -la /etc/kubernetes/pki/ou-ca.*
-rw------- 1 root root 1704 Feb 31 15:57 ou-ca.key
-rw-r--r-- 1 root root 1498 Feb 31 15:56 ou-ca.pem
[root@server1 ~]#

Caso queira verificar o que esta no certificado, execute;

[root@server1 ~]# openssl x509 -in /etc/kubernetes/pki/ou-ca.pem -text -noout
(...) saida omitida
seus certificados, quem assinou, validade, emitido em, etc...
(...)
[root@server1 ~]#

Tudo ok, vamos fazer com que o kubernetes reconheça o seu novo autenticador, isso vai gerar uma indisponibilidade de alguns segundos para o kubectl, faça com cuidado, os serviços continuarão a funcionar, as aplicações também, so, do that ...

[root@server1 ~]# vi /etc/kubernetes/manifests/kube-apiserver.yaml

adicione essas linhas nos argumentos do apiserver

containers:
- command:
- kube-apiserver
- --advertise-address=172.28.39.11
- --oidc-issuer-url=https://portaldousuario.meudominio.net/auth/idp/k8sIdp
- --oidc-client-id=kubernetes
- --oidc-username-claim=sub
- --oidc-groups-claim=groups
- --oidc-ca-file=/etc/kubernetes/pki/ou-ca.pem

Aguarde o retorno do kube-apiserver;

[root@server1 ~]# watch -n1 kubectl get pod -n kube-system

Every 1.0s: kubectl get po -n kube-system Thu Feb 31 17:19:42 2019

NAME READY STATUS RESTARTS AGE
coredns-584795fc57-cxctl 1/1 Running 9 10w
coredns-584795fc57-rv5ql 1/1 Running 9 10w
etcd-bastion-0 1/1 Running 0 14w
kube-apiserver-bastion-0 1/1 Running 0 2s
kube-controller-manager-bastion-0 1/1 Running 7 14w
kube-proxy-nswkh 1/1 Running 0 14w
kube-scheduler-bastion-0 1/1 Running 7 14w
metrics-server-6dcf9864f6-xzhn4 1/1 Running 0 6d2h
weave-net-k84rs 2/2 Running 0 14w
[root@server1 ~]#

Primeiro acesso… quase lá…

Antes de tentar seu acesso, tenha certeza que foi preparado o terreno no AD.

• um grupo de usuários o qual será um dos configurados no kubernetes para acesso, ex. k8s-admins

• um usuário que faz parte do grupo acima, ex. usr_euzinho

Verifique se o seu ingress para o Openunison foi criado e esta operacional;

[root@server1 ~]# kubectl get ingress -n openunison
NAME HOSTS ADDRESS PORTS AGE
openunison portaldousuario.meudominio.net,dash-k8s.meudominio.net 10.105.115.198 80, 443 12m
[root@server1 ~]#

Acesse a URL ; https://portaldosuario.meudominio.net

Deverá fornecer seu usuário e senha do AD. Mas ainda não conseguirá acesso, falta a criação das regras dentro do kubernetes, mas já é possível ver o seu token e os complementos para criar seu ./kube/config ou kubectl windows command se quiser acessar o k8s através de sua estação.

Tem um problema ai, e precisamos resolve-lo antes de continuar, esse ingress openunison, criou uma entrada para o seu dashboard que ja existe, remova-a , editando o ingress.

[root@server1 ~]# kubectl create -f << EOF
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: activedirectory-cluster-admins
subjects:
- kind: Group
name: "CN=k8s-admins,CN=Users,DC=ent2k12,DC=domain,DC=com"
roleRef:
kind: ClusterRole
name: cluster-admin
apiGroup: rbac.authorization.k8s.io
EOF
Sucesso!!! ClusterRoleBinding activediretory-cluster-admin created.
[root@server1 ~]#

• No portal, efetue logout e acesse novamente.

• Clique em Kubernetes Tokens.

• Copie o id_token , volte à página principal e clique em Kubernetes Dashboard.

• Já na página de login do Kubernetes Dashboard, selecione token e cole seu id_token, pronto, acesso total aos recursos.

Viu que nada funcionou? ;-) É porque ainda não criamos as regras de acesso para esse grupo/usuário do AD.

Nesse momento, só funciona a criação do token, certificados e comandos periféricos, mas não são válidos pois não existe a co-relação de acesso dentro do kubernetes. Então vamos entender para criá-los.

Limitar usuários e grupos

Para isso é preciso, no AD, criar os grupos com nomes compreensíveis e vincular os usuários á eles. ex: k8s-admins, k8s-ns-site-a-views, k8s-ns-app-b-admins, etc…

Não é necessária a inicialização do grupo com k8s, basta que saiba quais os grupos que se deseja liberar os acessos. Portanto podem ser os que ja existam, desde que haja coerência na sua organização.

Feito isso, precisamos decidir qual a maneira mais lazy de se administrar o kubernetes.

• Através da concessão de acesso aos grupos do AD, evitando o trabalho de criar uma regra para cada usuário — ESSA É A MANEIRA RECOMENDADA, ou;

• Através da concessão para cada novo usuário do ambiente, obrigando a ser criada uma regra (clusterrolebinding para todo cluster ou rolebinding para namespaces ) para cada um deles, além de ter o cuidado de remover seus acessos em caso de desligamento, promoção, abdução extraterrestre, entre outros.

Caso não saiba, veja como funciona o RBAC do kubernetes, se já sabe, pode pular essa parte.

Por fim quando se deseja dar acesso a usuários, grupos etc, via RBAC claro, é preciso vinculá-los á uma regra ( role ) e a sua permissão efetiva ( binding ). Isso pode ser feito no escopo de namespace ou para o cluster como um todo.

Em resumo, 3 exemplos de como criar os acessos;

- Concessão por Grupo do AD.

Ja criou um grupo chamado k8s-app-loja, e outro grupo k8s-noc-viewers. Para dar os devidos acessos aos usuários desses grupo, crie os arquivos abaixo e aplique-os.

[root@server1 ~]# kubectl create -f << EOF
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: k8s-noc-viewers
subjects:
- kind: Group
name: "CN=k8s-noc-viewers,CN=Users,DC=ent2k12,DC=domain,DC=com"
roleRef:
kind: ClusterRole
name: view
apiGroup: rbac.authorization.k8s.io
EOF
clusterrolebinding.rbac.authorization.k8s.io/k8s-noc-viewers created
[root@server1 ~]#
[root@server1 ~]#
[root@server1 ~]# kubectl create -f << EOF
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: k8s-app-loja-viewers
namespace: app-loja
subjects:
- kind: Group
name: "CN=k8s-app-loja-viewers,CN=Users,DC=ent2k12,DC=domain,DC=com"
roleRef:
kind: Role
name: viewer-app-loja
apiGroup: rbac.authorization.k8s.io
EOF
rolebinding.rbac.authorization.k8s.io/k8s-app-loja-viewers created
[root@server1 ~]#

A partir do exemplo acima consegue-se ter uma ideia do que precisa para seus acessos, seja criativo, registre suas mudanças e documente em seu repositório, compartilhe.

- Concessão por Usuários do AD.

Da mesma maneira que acima, mas ao invés de grupos, especificaremos usuários;

[root@server1 ~]# kubectl create -f << EOF
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: raimundo-cluster-admin
subjects:
- kind: User
name: https://kubectl-auth-dev.cip-core.local/auth/idp/k8sIdp#RAIMUNDO.NONATO
roleRef:
kind: ClusterRole
name: cluster-admin
apiGroup: rbac.authorization.k8s.io
EOF
clusterrolebinding.rbac.authorization.k8s.io/raimundo-cluster-admin created
[root@server1 ~]#
[root@server1 ~]#
[root@server1 ~]#kubectl create -f << EOF
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: antonio-app-loja-admin
namespace: app-loja
subjects:
- kind: User
name: https://kubectl-auth-dev.cip-core.local/auth/idp/k8sIdp#ANTONIO.AUGUSTO
roleRef:
kind: Role
name: app-loja-admin
apiGroup: rbac.authorization.k8s.io
EOF
rolebinding.rbac.authorization.k8s.io/antonio-app-loja-admin created
[root@server1 ~]#

Agora pode testar seu acesso. Há alguns segredos quanto à solução Tremolo, se precisarem de ajuda, pode me chamar que eu revelo como quebrar "algumas das barreiras".

Na segunda parte , continuarei com a implementação do DEX+Gangway+Oauth2, fiquem ligados.

Thanks for knowlegde share and support

support.ssl.com

tremolosecurity.com

kubernetes.io

heptiolabs, now is VMware

nginx.com, now is F5

DISCLOSURE STATEMENT: These opinions are those of the author. Unless noted otherwise in this post, Kubernetes, Tremolo Security, Heptio Labs or VMware is not affiliated with, nor is it endorsed by, any of the companies mentioned. All trademarks and other intellectual property used or displayed are the ownership of their respective owners. This article is © Adonai Costa.