Implementando a autenticação OpenID Connect no Kubernetes com Okta e o NGINX Ingress Controller

Amir RawdatEngenheiro de Soluções

Já escrevemos muitas vezes sobre a importância de proteger seus aplicativos e APIs no cenário atual de ataques de ransomware e ataques conduzidos por bots. Além de mecanismos como firewall de aplicações web (WAF), autenticar as identidades dos usuários e aplicar controles de autorização são medidas importantes para proteger as aplicações da sua empresa.

A maneira mais direta de implementar autenticação e autorização é nas próprias aplicações. Embora isso possa funcionar quando sua base de usuários é pequena e sua aplicação não exige atualizações frequentes, essa abordagem rapidamente se torna inviável em grande escala. Um dos motivos é que, quando os usuários precisam se lembrar de um nome de conta e uma senha diferentes para cada uma das várias aplicações, muitas vezes se deparam com mensagens frustrantes de “nome de usuário ou senha incorretos” ao tentar fazer login, o que os leva a recorrer a soluções inseguras, como senhas fáceis de adivinhar, a exemplo de “abc123”. E todos nós já vimos monitores cercados por uma auréola de notas Post-it® com lembretes de senhas!

As tecnologias de logon único (SSO) podem resolver parcialmente esses problemas, eliminando todos esses nomes de usuário e senhas separados em favor de um único conjunto de credenciais. Os usuários fazem login apenas uma vez por meio de um provedor de identidade (IdP) para acessar vários aplicativos. No entanto, os desenvolvedores ainda precisam incluir código em seus aplicativos para integrá-los ao sistema de SSO, o que pode ser bastante desafiador, especialmente à medida que os aplicativos se tornam mais complexos.

À medida que as organizações crescem e precisam atender às demandas de uma base de usuários em rápida expansão, torna-se essencial retirar da camada da aplicação os requisitos que não são específicos à funcionalidade do aplicativo, como autenticação e autorização. Um local ideal para centralizar a autenticação e a autorização no Kubernetes é o controlador de Ingress, que pode inspecionar todo o tráfego que entra no cluster e encaminhá-lo aos serviços apropriados. Isso livra os desenvolvedores da tarefa de criar, manter e replicar a lógica de autenticação, permitindo que aproveitem facilmente as tecnologias de SSO na camada de ingresso por meio da API nativa do Kubernetes.

Neste blog, mostramos como implementar uma solução completa de SSO com o NGINX Ingress Controller baseado no NGINX Plus atuando como parte intermediária e oferecendo suporte ao Fluxo de Código de Autorização OIDC com o Okta como provedor de identidade (IdP) pré-configurado.

Observação: Este recurso não está disponível no NGINX Ingress Controller baseado no NGINX Open Source.

Pré-requisitos

Este blog pressupõe que você tenha experiência trabalhando em ambientes Kubernetes. Além disso, você precisará do seguinte:

• Um ambiente Kubernetes – O NGINX Ingress Controller é compatível com o Kubernetes padrão e com diversas plataformas Kubernetes, incluindo Amazon Elastic Kubernetes (EKS), bare metal, Google Kubernetes Engine (GKE), Microsoft Azure Kubernetes Service (AKS), Rancher Kubernetes Engine e Red Hat OpenShift.
• NGINX Ingress Controller baseado no NGINX Plus – Você deve ter uma licença válida para a versão do NGINX Ingress Controller baseada no NGINX Plus. Para começar hoje mesmo, solicite uma avaliação gratuita de 30 dias. Para obter mais informações, consulte nossa documentação.
• Uma conta de desenvolvedor da Okta – Para configurar a Okta como seu IdP, primeiro crie uma conta de desenvolvedor. Como alternativa, baixe a Interface de Linha de Comando da Okta (CLI) e execute o comando okta register para criar uma nova conta. No momento da redação deste texto, a CLI da Okta está em versão beta e não é recomendada para uso em produção.

Pré-configurando o IdP

Os serviços de nuvem precisam saber onde obter e verificar as identidades dos usuários, e é nesse ponto que um IdP se torna necessário. Um IdP gerencia e armazena identidades digitais com segurança e impede que invasores roubem identidades para se passar por usuários.

Nesta seção, usamos a CLI da Okta para pré-configurar a Okta como IdP, criando o que a Okta chama de integração de aplicativo.

1. Execute o comando okta login para autenticar a CLI do Okta com sua conta de desenvolvedor do Okta. Quando solicitado, insira seu domínio do Okta e o token de API.

$ okta login Okta Org URL: https://your-okta-domain
Okta API token: your-api-token

1. Crie a integração do aplicativo:

$ okta apps create --app-name=mywebapp --redirect-uri=http[s]://ingress-controller-hostname/_codexch

1. onde
   • --app-name define o nome da aplicação (neste caso, mywebapp)
   • --redirect-uri define o URI para o qual os usuários são redirecionados após fazer login (neste caso, ingress-controller-hostname/_codexch)
2. Especifique o tipo de aplicativo em resposta às solicitações, primeiro com 1 (que representa um aplicativo Web) e depois com 5 (que representa um framework diferente dos listados).

Type of Application
(The Okta CLI only supports a subset of application types and properties):
> 1: Web
> 2: Single Page App
> 3: Native App (mobile)
> 4: Service (Machine-to-Machine)
Enter your choice [Web]: 1
Type of Application
> 1: Okta Spring Boot Starter
> 2: Spring Boot
> 3: JHipster
> 4: Quarkus
> 5: Other
Enter your choice [Other]: 5
Configuring a new OIDC Application, almost done:
Created OIDC application, client-id: 0oa1mi...OrfQAg5d7

Configurando o controlador de Ingress do NGINX

Configure a versão do NGINX Ingress Controller baseada no NGINX Plus como a parte intermediária que autentica os usuários.

Definindo um segredo de credenciais do cliente

Por motivos de segurança, não é permitido inserir diretamente o segredo do cliente no objeto de política OIDC. Em vez disso, criamos um Secret do Kubernetes com dados que contêm o valor do segredo do cliente codificado em base64.

apiVersion: v1
kind: Secret
metadata:
  name: oidc-secret
type: nginx.org/oidc
data:
  client-secret: base64-encoded-value-of-client-secret 

Em seguida, aplique o arquivo YAML que contém o Secret (neste caso, client-secret.yaml):

$ kubectl apply –f client-secret.yaml

Obtendo os endpoints de autenticação

Use a OAuth 2.0 e a API OpenID Connect para obter informações sobre os endpoints que a Okta disponibiliza em seus servidores de autorização.

Execute o comando a seguir em sua máquina local para exibir informações sobre seus endpoints da Okta. Anote os valores de authorization_endpoint, token_endpoint e jwks_uri conforme mostrado no exemplo de saída. Você os usará na próxima seção.

$ curl -i https://your-okta-domain/.well-known/openid-configuration
{
    "authorization_endpoint": "https://your-okta-domain/oauth2/v1/authorize",
    ...
    "jwks_uri": "https://your-okta-domain/oauth2/v1/keys",
    ...
    "token_endpoint": "https://your-okta-domain/oauth2/v1/token",
 ...
 }

Definindo a política OIDC do NGINX Ingress

O suporte à autenticação baseada em OIDC foi adicionado no NGINX Ingress Controller 1.10.0. Para obter mais detalhes, leia Single Sign-On fácil e robusto com OpenID Connect e NGINX Ingress Controller em nosso blog.

A implementação da autenticação OIDC do NGINX Ingress Controller usa um objeto Policy, um recurso personalizado do Kubernetes que define uma política OIDC no NGINX Ingress Controller.

1. Insira as informações obtidas na seção anterior nos campos authEndpoint, tokenEndpoint e jwksURI do objeto Policy.

apiVersion: k8s.nginx.org/v1
kind: Policy
metadata:
  name: oidc-policy
spec:
  oidc:
    clientID: client-id
    clientSecret: oidc-secret
    authEndpoint: https://your-okta-domain/oauth2/v1/authorize
    tokenEndpoint: https://your-okta-domain/oauth2/v1/token
    jwksURI: https://your-okta-domain/oauth2/v1/keys

1. Aplique a política (definida aqui em oidc.yaml):

$ kubectl apply -f oidc.yaml

1. (Opcional) Verifique a validade da política:

$ kubectl get policy 

NAME          STATE   AGE
oidc-policy   Valid   2m

Definindo o objeto VirtualServer

VirtualServer e VirtualServerRoute são recursos do NGINX Ingress que definem as regras para rotear o tráfego de entrada para as aplicações de backend no cluster do Kubernetes. Para que uma política OIDC entre em vigor, ela deve ser referenciada em um recurso VirtualServer ou VirtualServerRoute.

1. Faça referência a uma política OIDC no prefixo de caminho / para que os usuários que solicitarem caminhos correspondentes ao prefixo sejam autenticados antes que a solicitação seja encaminhada ao serviço app-server-payload.

apiVersion: k8s.nginx.org/v1
kind: VirtualServer
metadata:
  name: app-ingress
spec:
  host: unit-demo.linkpc.net
  upstreams:
  - name: app-server-payload
    service: app-server-svc
    port: 80
  routes:
  - path: /
    policies:
    - name: oidc-policy
    action:
      proxy: 
        upstream: app-server-payload

1. Aplique o recurso VirtualServer (definido aqui em app-virtual-server.yaml):

$ kubectl apply -f app-virtual-server.yaml

1. (Opcional.) Verifique a validade do recurso:

$ kubectl get vs

NAME          STATE   HOST                   IP    PORTS   AGE
app-ingress   Valid   unit-demo.linkpc.net                 2m

Testando o ambiente

Para testar se a integração OIDC com o Okta está funcionando corretamente, insira o nome do host do NGINX Ingress Controller na barra de endereços do navegador. Você será redirecionado para o portal de login do Okta, onde poderá inserir as credenciais da sua conta de desenvolvedor do Okta para acessar a aplicação de backend.

Após a autenticação bem-sucedida, você terá acesso ao serviço upstream app-server-payload.

Adicionando usuários ao aplicativo

Na maioria dos casos, vários usuários da sua organização precisam acessar seus aplicativos. Adicione cada usuário na página Pessoas da categoria Diretório no console de administração do Okta.

Como criar integrações de SSO para vários aplicativos

Transferimos o processo de autenticação de uma aplicação configurando o SSO com o Okta como IdP e o NGINX Ingress Controller como parte intermediária. Na prática, provavelmente será necessário permitir que os usuários acessem várias aplicações usando um único conjunto de credenciais. Talvez você também queira ter a flexibilidade de definir quais aplicações cada usuário pode acessar. Para isso, repita as instruções das seções acima:

• Pré-configurando o IdP para integrar outros aplicativos ao Okta
• Definição da política OIDC do NGINX Ingress para definir outras políticas OIDC
• Definição do objeto VirtualServer para referenciar políticas adicionais

No exemplo ilustrado no diagrama a seguir, há dois subdomínios, unit-demo.marketing.net e unit-demo.engineering.net, que são resolvidos para o endereço IP externo do NGINX Ingress Controller. O NGINX Ingress Controller encaminha as solicitações para o aplicativo de Marketing ou de Engenharia, de acordo com o subdomínio. Para conceder acesso a um usuário, na guia Atribuições da interface gráfica do Okta, associe o usuário a cada aplicativo apropriado. Em seguida, o Okta concede ao usuário autenticado um cookie de sessão de curta duração para acessar esses aplicativos.

Conclusão

Ao implementar o SSO baseado em OIDC no Kubernetes usando o NGINX Ingress Controller como parte intermediária e a Okta como IdP, você libera seus desenvolvedores das tarefas de autenticação e autorização, permitindo que eles se concentrem na otimização da lógica de negócios dos aplicativos. Para começar a usar o NGINX Ingress Controller baseado no NGINX Plus, solicite uma avaliação gratuita de 30 dias hoje mesmo ou entre em contato conosco para conversar sobre seus casos de uso.

Sobre o autor

Amir RawdatEngenheiro de Soluções

Mais publicações de Amir Rawdat