Como Proteger Serviços Privados do Kubernetes por meio de um Login do GitHub com oauth2_proxy

Introdução

O Kubernetes ingress facilita a exposição de web services para a internet. Quando se trata de serviços privados, no entanto, você provavelmente desejará limitar quem pode acessá-los. O oauth2_proxy pode servir como uma barreira entre a Internet pública e os serviços privados. O oauth2_proxy é um servidor e proxy reverso que fornece autenticação usando diferentes provedores, como o GitHub, e valida os usuários pelo seu endereço de email ou outras propriedades.

Neste tutorial, você usará o oauth2_proxy com o GitHub para proteger seus serviços. Quando terminar, você terá um sistema de autorização semelhante ao do diagrama a seguir:

Pré-requisitos

Para concluir este tutorial, você precisará de:

• Um cluster Kubernetes com dois web services em execução com Nginx Ingress e Let’s Encrypt. Este tutorial baseia-se no tutorial How to Set Up an Nginx Ingress with Cert-Manager on DigitalOcean Kubernetes. Certifique-se de segui-lo até o final, a fim de concluir este tutorial.
• Um conta no GitHub.
• Python instalado em sua máquina local. Se você não o tiver instalado, siga as instruções de instalação do seu sistema operacional.

Passo 1 — Configurando seus Domínios

Após seguir o tutorial indicado na seção Pré-requisitos, você terá dois web services em execução no cluster: echo1 e echo2. Você também terá um ingress que mapeia echo1.seu_domínio e echo2.seu_domínio aos seus serviços correspondentes.

Neste tutorial, usaremos as seguintes convenções:

• Todos os serviços privados se enquadram no subdomínio .int.seu_domínio, como service.int.seu_domínio. O agrupamento de serviços privados em um subdomínio é ideal porque o cookie de autenticação será compartilhado por todos os subdomínios *.int.seu_domínio
• O portal de login será exibido em auth.int.seu_domínio.

Para começar, atualize a definição atual do ingress para mover os serviços echo1 e echo2 em .int.seu_domínio. Abra echo_ingress.yaml em seu editor de textos para poder alterar os domínios:

nano echo_ingress.yaml

Renomeie todas as instâncias de echo1.seu_domínio para echo1.int.seu_domínio, e substitua todas as instâncias de echo2.seu_domínio com echo2.int.seu_domínio:

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: echo-ingress
  annotations:  
    kubernetes.io/ingress.class: nginx
    certmanager.k8s.io/cluster-issuer: letsencrypt-prod
spec:
  tls:
  - hosts:
    - echo1.int.seu_domínio
    - echo2.int.seu_domínio
    secretName: letsencrypt-prod
  rules:
  - host: echo1.int.seu_domínio
    http:
      paths:
      - backend:
          serviceName: echo1
          servicePort: 80
  - host: echo2.int.seu_domínio
    http:
      paths:
      - backend:
          serviceName: echo2
          servicePort: 80

Salve o arquivo e aplique as alterações:

kubectl apply -f echo_ingress.yaml

Isso atualizará os certificados TLS para seus serviços echo1 e echo2 também.

Agora atualize sua configuração de DNS para refletir as alterações que você fez. Primeiro, procure o endereço IP de seu ingress Nginx executando o seguinte comando para imprimir seus detalhes:

kubectl get svc --namespace=ingress-nginx

Você verá o endereço IP abaixo de EXTERNAL-IP na saída:

Output
NAME            TYPE           CLUSTER-IP      EXTERNAL-IP       PORT(S)                      AGE
ingress-nginx   LoadBalancer   10.245.247.67   203.0.113.0   80:32486/TCP,443:32096/TCP   20h

Copie o endereço IP externo para a sua área de transferência. Navegue até o seu serviço de gerenciamento de DNS e localize os registros A para echo1-2.seu_domínio para apontar para esse endereço IP externo. Se você estiver usando a DigitalOcean para gerenciar seus registros DNS, veja How to Manage DNS Records para instruções.

Delete os registros para echo1 e echo2. Adicione um novo registro A para o hostname *.int.seu_domínio e o aponte para o endereço IP externo do ingress.

Agora, qualquer solicitação para qualquer subdomínio em *.int.seu_domínio será roteada para o ingress Nginx, para que você possa usar esses subdomínios no seu cluster.

Em seguida, você irá configurar o GitHub como seu provedor de login.

Passo 2 — Criando uma Aplicação GitHub OAuth

O oauth2_proxy suporta vários provedores de login. Neste tutorial, você usará o provedor GitHub. Para começar, crie uma nova aplicação GitHub OAuth.

Na guia OAuth Apps da página de configurações do desenvolvedor da sua conta, clique no botão New OAuth App.

Os campos Application name e Homepage URL podem ser qualquer coisa que você quiser. No campo Authorization callback URL, digite https://auth.int.seu_domínio/oauth2/callback.

Depois de registrar a aplicação, você receberá um Client ID e um Secret. Tome nota dos dois, pois você precisará deles no próximo passo.

Agora que você criou uma aplicação GitHub OAuth, você pode instalar e configurar o oauth2_proxy.

Passo 3 – Configurando o Portal de Login

Você usará o Helm para instalar o oauth2_proxy no cluster. Primeiro, você criará um secret do Kubernetes para armazenar o Client ID e o Secret da aplicação GitHub, bem como um secret de criptografia para os cookies do navegador definidos pelo oauth2_proxy.

Execute o seguinte comando para gerar um secret de cookie seguro:

python -c 'import os,base64; print base64.b64encode(os.urandom(16))'

Copie o resultado para sua área de transferência.

Em seguida, crie o secret do Kubernetes, substituindo os valores destacados pelo seu secret de cookie, seu ID de cliente GitHub e sua chave secreta do GitHub:

kubectl -n default create secret generic oauth2-proxy-creds \
--from-literal=cookie-secret=SEU_COOKIE_SECRET \
--from-literal=client-id=SEU_GITHUB_CLIENT_ID \
--from-literal=client-secret=SEU_GITHUB_SECRET

Você verá a seguinte saída:

Output
secret/oauth2-proxy-creds created

Em seguida, crie um novo arquivo chamado oauth2-proxy-config.yaml que conterá a configuração para o oauth2_proxy:

nano oauth2-proxy-config.yaml

Os valores que você definir neste arquivo substituirão os valores padrão do Helm. Adicione o seguinte código ao arquivo:

config:
  existingSecret: oauth2-proxy-creds

extraArgs:
  whitelist-domain: .int.seu_domínio
  cookie-domain: .int.seu_domínio
  provider: github

authenticatedEmailsFile:
  enabled: true
  restricted_access: |-
    permitido@user1.com
    permitido@user2.com

ingress:
  enabled: true
  path: /
  hosts:
    - auth.int.seu_domínio
  annotations:
    kubernetes.io/ingress.class: nginx
    certmanager.k8s.io/cluster-issuer: letsencrypt-prod
  tls:
    - secretName: oauth2-proxy-https-cert
      hosts:
        - auth.int.seu_domínio

Este código faz o seguinte:

1. Instrui o oauth2_proxy a usar o secret que você criou.
2. Define o nome do domínio e o tipo de provedor.
3. Define uma lista de endereços de email permitidos. Se uma conta do GitHub estiver associada a um desses endereços de e-mail, será permitido o acesso aos serviços privados.
4. Configura o ingress que servirá o portal de login em auth.int.seu_domínio com um certificado TLS da Let’s Encrypt.

Agora que você tem o secret e o arquivo de configuração prontos, você pode instalar o oauth2_proxy. Execute o seguinte comando:

helm repo update \
&& helm upgrade oauth2-proxy --install stable/oauth2-proxy \
--reuse-values \
--values oauth2-proxy-config.yaml

Pode levar alguns minutos para que o certificado Let’s Encrypt seja emitido e instalado.

Para testar se o deploy foi bem-sucedido, navegue até https://auth.int.seu_domínio. Você verá uma página que solicita que você efetue login no GitHub.

Com oauth2_proxy configurado e em execução, tudo o que falta é exigir autenticação nos seus serviços.

Passo 4 — Protegendo os Serviços Privados

Para proteger um serviço, configure seu Nginx ingress para forçar a autenticação via oauth2_proxy. O Nginx e o nginx-ingress suportam essa configuração nativamente, portanto, você só precisa adicionar algumas anotações à definição do ingress.

Vamos proteger os serviços echo1 e echo2 que você configurou no tutorial de pré-requisito. Abra echo_ingress.yaml em seu editor:

nano echo_ingress.yaml

Adicione essas duas anotações adicionais ao arquivo para exigir autenticação:

   annotations:
     kubernetes.io/ingress.class: nginx
     certmanager.k8s.io/cluster-issuer: letsencrypt-prod
     nginx.ingress.kubernetes.io/auth-url: "https://auth.int.seu_domínio/oauth2/auth"
     nginx.ingress.kubernetes.io/auth-signin: "https://auth.int.seu_domínio/oauth2/start?rd=https%3A%2F%2F$host$request_uri"

Salve o arquivo e aplique as alterações:

kubectl apply -f echo_ingress.yaml

Agora, quando você navega até https://echo1.int.seu_domínio, você será solicitado a fazer login usando o GitHub para acessá-lo. Após fazer o login com uma conta válida, você será redirecionado de volta ao serviço echo1. O mesmo vale para echo2.

Conclusão

Neste tutorial, você configurou o oauth2_proxy no seu cluster Kubernetes e protegeu um serviço privado atrás de um login do GitHub. Para qualquer outro serviço que você precise proteger, basta seguir as instruções descritas no Passo 4.

O oauth2_proxy suporta muitos provedores diferentes, além do GitHub. Para saber mais sobre diferentes provedores, consulte a documentação oficial.

Além disso, existem muitos parâmetros de configuração que você pode precisar ajustar, embora os padrões adotados sejam adequados à maioria das necessidades. Para uma lista de parâmetros, consulte a documentação do Helm charts e a documentação do oauth2_proxy.