Como adicionar autenticação básica HTTP a uma entrada Kubernetes NGINX

O NGINX Ingress é um popular controlador de entrada do Kubernetes para rotear o tráfego em seu cluster. Um recurso Ingress padrão permite mapear solicitações HTTP para seus serviços Kubernetes. Veja como proteger suas rotas com autenticação básica HTTP.

Criando um arquivo HTPasswd

Certifique-se de ter um arquivo htpasswd disponível antes de iniciar a configuração do Kubernetes. Você pode criar um novo usuário único htpasswd em seu terminal:

apt install apache2-utils
htpasswd -c auth example-user

Você será solicitado a inserir a senha. Um novo arquivo chamado auth será criado em seu diretório de trabalho.

Em seguida, você precisa codificar em base64 sua string de credenciais para que ela possa ser usada como um valor em um segredo do Kubernetes:

cat auth | base64

Copie a string codificada em base64 para a área de transferência. Vamos usá-lo na próxima seção para criar um segredo do Kubernetes contendo suas credenciais.

Adicionando um segredo do Kubernetes

O NGINX Ingress faz referência a arquivos htpasswd como segredos do Kubernetes. O conteúdo do arquivo deve ser armazenado na chave auth de um segredo Opaque. O Kubernetes também possui um tipo de segredo basic-auth integrado, mas isso não é adequado para o NGINX Ingress.

Crie um novo manifesto secreto e aplique-o ao seu cluster com o Kubectl:

apiVersion: v1
kind: Secret
type: Opaque
metadata:
  name: htpasswd
data:
  auth: <base64-encoded htpasswd file>

Adicione seu arquivo htpasswd codificado em base64 como o valor da chave auth.

Modificando sua entrada

O NGINX Ingress oferece suporte a várias anotações personalizadas que permitem anexar comportamento extra aos seus recursos do Ingress. Para usar a autenticação básica HTTP, você precisa definir a anotação auth-type e fornecer uma referência ao seu segredo.

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: example-ingress
  annotations:
    nginx.ingress.kubernetes.io/auth-type: basic
    nginx.ingress.kubernetes.io/auth-secret: htpasswd
    nginx.ingress.kubernetes.io/auth-realm: "Enter your credentials"
spec:
  rules:
    - host: example.com
      http:
        paths:
         - path: /
           backend:
            serviceName: example-service
            servicePort: 80

As três anotações configuram o NGINX para exigir autenticação em todas as solicitações correspondentes ao seu recurso Ingress. O tipo de autenticação basic é usado com as credenciais do segredo htpasswd criado anteriormente. A anotação auth-realm define a mensagem exibida aos usuários quando eles são solicitados a inserir suas credenciais.

As solicitações correspondidas por este Ingress agora exigirão que o usuário faça login antes de continuar. O desafio de autenticação é exibido como uma caixa de diálogo pop-up na maioria dos navegadores da web. Insira o nome de usuário e a senha fornecidos ao comando htpasswd para se autenticar.

Formulário Secreto Alternativo

O segredo mostrado acima usa o formato auth-file. Isso significa que ele tem um campo auth contendo a saída codificada em base64 do comando htpasswd.

O NGINX Ingress também oferece suporte a outro formulário denominado auth-map. Nesta variação, o campo auth é substituído por um conjunto de chaves que fornecem a senha para um usuário individual.

apiVersion: v1
kind: Secret
type: Opaque
metadata:
  name: htpasswd
data:
  user1: <base64-encoded password hash from htpasswd>
  user2: <base64-encoded password hash from htpasswd>

Adicione seus nomes de usuário ao arquivo e use htpasswd para gerar credenciais com hash. Inspecione a saída htpasswd; terá o seguinte formato:

username:<hashed password>

Pegue a parte da senha, codifique-a com o comando base64 e adicione o resultado ao seu segredo do Kubernetes.

O NGINX aceitará logins de qualquer combinação válida de nome de usuário e senha definida no segredo. Essa abordagem pode facilitar a configuração de várias contas de usuário e ajuda você a ver exatamente quem tem acesso.

Autenticação mais avançada

O NGINX Ingress pode se integrar a provedores de autenticação externos se você precisar de mais controle, mas quiser uma experiência de configuração igualmente direta. O uso de um provedor de autenticação externo redirecionará os usuários para esse site antes que eles possam acessar o serviço por trás do seu Ingress. Isso permite impor uma rotina de autenticação completa sem tocar no código de back-end.

A anotação nginx.ingress.kubernetes.io/auth-url define a URL de um serviço de autenticação externa a ser usado. O Kubernetes encaminhará cada solicitação recebida para o serviço. O acesso só será concedido ao usuário quando o serviço retornar um código de status 200 OK. O fluxo normal continua com a solicitação em seu serviço Kubernetes.

Quando o serviço de autenticação indicar um erro, os usuários serão redirecionados para a página indicada pela URL nginx.ingress.kubernetes.io/auth-signin. Isso receberá a URL original para redirecionar voltar após uma tentativa de autenticação bem-sucedida como um parâmetro de URL definido com a anotação auth-signin-redirect-param.

Várias outras anotações permitem ajustar o comportamento do NGINX ao se comunicar com a plataforma de autenticação. Você pode alterar o método HTTP usado para fazer solicitações de autenticação, adicionar cabeçalhos adicionais e configurar o cache para respostas de autenticação. O último garante que você não acesse continuamente a plataforma externa se um usuário fizer várias solicitações ao seu serviço em um curto período de tempo.

Resumo

A autenticação básica HTTP é a maneira mais simples de proteger um site. É ideal para sistemas internos e sites de teste onde você trabalha com uma pequena lista de usuários e não precisa de gerenciamento centralizado de credenciais.

Use o Basic Auth com o NGINX Ingress fornecendo credenciais em um segredo do Kubernetes e definindo anotações em seus recursos do Ingress. Em um caso de uso do mundo real, você não deve codificar credenciais em seus manifestos do Kubernetes. Use o Helm ou um sistema de CI/CD para fornecer valores com segurança no momento em que você aplicar os recursos ao seu cluster.