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:
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
, comoservice.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
.
Nota: Certifique-se de substituir seu_domínio
pelo seu próprio nome de domínio onde quer que ele apareça neste tutorial.
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:
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
:
echo_ingress.yaml
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
eecho2
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 oauth2proxy 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 oauth2proxy.
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:
oauth2-proxy-config.yaml
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: |-
[email protected]
[email protected]
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:
- Instrui o oauth2_proxy a usar o secret que você criou.
- Define o nome do domínio e o tipo de provedor.
- 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.
- 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:
Adicione essas duas anotações adicionais ao arquivo para exigir autenticação:
echo_ingress.yaml
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.