Como Proteger o Kuberntes de Maneira Facil Usando Cognito
Recentemente tive um desafio criar um ambiente de desenvolvimento que ficasse seguro e sem utilizar nenhum tipo de vpn, para muitos pode parecer impossível, pois a utilização de vpn é algo amplamente difundido e comum, contudo comecei a pesquisar alternativas para disponibilizar um ambiente seguro para todas as pessoas que vão acessar os algumas ui e dashboard.
O primeiro passo para isso foi segregar os acessos das UI, criando usuários por perfil. Com isso temos uma camada de segurança, que depende exclusivamente da ferramenta que você está utilizando, vamos a um cenário hipotético;
Suponha que você acabou de implementar uma nova ferramenta de CI/CD para a sua companhia, e com isso você solicita para o time de network uma nova entrada de DNS, jenkins.xxx.com aonde xxx é a sua empresa. o pessoal de network faz isso e agora você tem o seu jenkins acessível pela vpn da companhia, contudo você conversa com o pessoal de network e convence que a UI de login do jenkins é segura e eles colocam o dns acessível pela dmz.
porém ao fazer isso você não expõe somente o jenkins da sua companhia a um risco de ataque você potencializa isso, pois o jenkins é um hub de integração.
Existem vulnerabilidades de 2011 que não foram corrigidas, ou por que não existem maneiras de explorar ou porque ainda não vou interesse da própria ferramenta em resolver isso. sugiro que sempre pesquisem as vulnerabilidades antes de expor algo na DMZ.
Recomendo esses dois sites para fazer a pesquisas referentes a vulnerabilidades.
Jenkins Jenkins : List of security vulnerabilities CVE
Bom, após o storytelling acima temos o seguinte cenário, como proteger as urls que vamos expor no nosso cluster Kubernetes sem impactar ou implementar configurações extras nas aplicações e ferramentas ?
Avaliamos algumas alternativas, porém tínhamos como premissa ser algo rápido fácil e escalável, então fugimos de SSO’s muito complicados e optamos por utilizar annotations kubernetes e cognito.
No início pensávamos que faríamos isso em minutos, porém a tarefa se mostrou um pouco mais complicada do que imaginamos e por isso decidi escrever esse pequeno howto de como fazer isso.
Primeiro passo.
Recomendo esse tutorial aqui AWS Cognito | Amazon Cognito | AWS Tutorial for Beginners | AWS Training | Edureka se você já conhece a ferramenta recomendo pular para o minuto 14:37 que é onde a mágica acontece.
Feito isso acredito que o pulo do gato (ace in the hole) e o principal ponto de dúvida é qual url colocar de callback para que você não tenha impacto na suas aplicações e ferramentas.
Aí entra é oauth2-proxy:
Vou deixar aqui como ficou a configuração do nosso App Cliente, onde xxx será a entrada seu dns para o cluster kubernetes. notem que temos somentes as flags funcionam com o Oauth2, recomendo deixa exatamente igual.
para que toda essa magia funcione você terá que instalar 3 coisas no seu cluster kubernetes
- helm upgrade — install external-dns
- helm upgrade — install ingress-nginx
- helm upgrade — install oauth2-proxy k8s-at-home/oauth2-proxy -n ingress-nginx — values values-oauth2-proxy.yaml
Segue o yaml de exemplo , pois não achei em nenhum lugar da internet.
https://gist.github.com/randomk/9e8a1145820428f201ab277caf397790
E agora é só colocar a anotação no seu ingress que vai funcionar magicamente.
https://gist.github.com/randomk/93a65a5c9a380a0f7bde0c93781af1cb
Após tudo isso feito você terá um tela de login semelhante a essa:
Pro-tip: habilitamos o segundo fator de autenticação como obrigatório e enviamos um sms com um token a cada acesso, nosso token expira a cada 8 horas para aumentar ainda mais a segurança, o envio de sms tem um custo de 0,1 de dólar por sms, porém vale cada centavo.
Agradecimento ao @Felipe Barbosa , que não desistiu do meu sonho e embarcou nessa loucura que dava para deixar um urls mais segura de maneira prática e fácil.
