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

Já escrevemos muitas vezes sobre a importância de proteger seus aplicativos e APIs no clima atual de ransomware e ataques de bots. Junto com mecanismos como o firewall de aplicativo da web (WAF), autenticar identidades de usuários e impor controles de autorização são maneiras importantes de proteger seus aplicativos comerciais.

A maneira mais direta de implementar autenticação e autorização é nos próprios aplicativos. Embora isso possa funcionar quando sua base de usuários é pequena e seu aplicativo não requer atualizações frequentes, rapidamente se torna insustentável em escala. Por um lado, quando seus usuários precisam lembrar de um nome de conta e senha diferentes para cada um dos muitos aplicativos, eles geralmente são recebidos com mensagens frustrantes de "nome de usuário ou senha incorretos" ao tentar fazer login, levando-os a recorrer a soluções inseguras, como senhas "abc123" fáceis de adivinhar. E todos nós já vimos monitores adornados com um halo de notas Post‑it® com lembretes de senha!

As tecnologias de logon único (SSO) podem resolver parcialmente esses problemas eliminando todos os nomes de usuário e senhas separados em favor de um conjunto de credenciais. Os usuários fazem login apenas uma vez com um Provedor de Identidade (IdP) para obter acesso a muitos aplicativos. Mas os desenvolvedores ainda precisam incluir código em seus aplicativos para interagir com o sistema SSO, o que pode ser muito desafiador, especialmente à medida que os aplicativos aumentam em complexidade.

À medida que as organizações crescem e precisam atender aos requisitos de uma base de usuários crescente, torna-se essencial descarregar requisitos que não são específicos da funcionalidade de um aplicativo — como autenticação e autorização — da camada de aplicativo. Um local ideal para autenticação e autorização centralizadas no Kubernetes é o controlador Ingress , que pode examinar todo o tráfego que entra no cluster e encaminhá-lo para os serviços apropriados. Isso libera os desenvolvedores do fardo de criar, manter e replicar a lógica de autenticação e eles podem facilmente aproveitar as tecnologias SSO na camada de entrada usando a API nativa do Kubernetes.

Neste blog, mostramos como implementar uma solução SSO completa com o NGINX Ingress Controller baseado no NGINX Plus operando como a parte de retransmissão, dando suporte ao fluxo de código de autorização OIDC com o Okta como o provedor de identidade pré-configurado (IdP).

Observação:  Este recurso não está disponível com o NGINX Ingress Controller baseado em código aberto NGINX.

Pré-requisitos

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

• Um ambiente Kubernetes – O NGINX Ingress Controller é compatível com o Kubernetes vanilla, bem como com várias 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 em NGINX Plus – Você deve ter uma licença válida para a versão do NGINX Ingress Controller baseada em NGINX Plus . Você pode começar a usar uma licença hoje mesmo solicitando um teste gratuito de 30 dias . Para obter informações adicionais, consulte nossa documentação .
• Uma conta de desenvolvedor Okta – Para configurar o Okta como seu IdP, comece inscrevendo-se para uma conta de desenvolvedor. Como alternativa, baixe a Interface de Linha de Comando (CLI) do Okta e execute o comando okta register para criar uma nova conta. No momento em que este artigo foi escrito, o Okta CLI estava em beta e não era recomendado para uso em produção.

Pré-configurando o IdP

Os serviços de nuvem precisam saber onde recuperar e verificar as identidades dos usuários, e é aí que um IdP se torna necessário. Um IdP gerencia e armazena identidades digitais com segurança e garante que invasores não possam roubar identidades para se passar por usuários.

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

1. Execute o comando okta login para autenticar o Okta CLI com sua conta de desenvolvedor do Okta. Insira seu domínio Okta e token de API nos prompts.

   $ okta login URL da organização Okta: https:// seu-domínio-okta Token da API Okta: seu-token-api
   

2. Crie a integração do aplicativo:

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

   onde

   • --app-name define o nome do aplicativo (aqui, mywebapp )
   • --redirect-uri define o URI para o qual os logins são redirecionados (aqui, ingress-controller-hostname /_codexch )

3. Especifique o tipo de aplicação em resposta aos prompts, primeiro com1 (representando uma aplicação web) e então5 (representando uma estrutura diferente das listadas).

   Tipo de aplicativo
   (O Okta CLI suporta apenas um subconjunto de tipos de aplicativos e propriedades):
   > 1: Rede
   > 2: Aplicativo de página única
   > 3: Aplicativo nativo (móvel)
   > 4: Serviço (Máquina-a-Máquina)
   Digite sua escolha [Web]: 1
   Tipo de Aplicação
   > 1: Inicializador de Bota de Mola Okta
   > 2: Bota de Mola
   > 3: JHipster
   > 4: Quarkus
   > 5: Outro
   Digite sua escolha [Outro]: 5
   Configurando um novo aplicativo OIDC, quase pronto:
   Aplicativo OIDC criado, client-id: 0oa1mi...OrfQAg5d7
   

Configurando o controlador de entrada NGINX

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

Definindo um segredo de credencial do cliente

Por motivos de segurança, a codificação do segredo do cliente no Objeto de Política OIDC não é suportada. Em vez disso, criamos um segredo do Kubernetes com dados contendo o valor codificado em base64 do segredo do cliente.

apiVersion: v1 tipo: Metadados secretos: nome: oidc-secret tipo: nginx.org/oidc dados: client-secret: base64-encoded-value-of-client-secret 

Em seguida, aplique o arquivo YAML contendo o segredo (aqui, client-secret.yaml ):

$ kubectl apply –f cliente-secret.yaml

Obtendo os pontos de extremidade de autenticação

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

Execute o seguinte comando na sua máquina local para gerar informações sobre seus endpoints do Okta. Observe os valores de authorization_endpoint , token_endpoint e jwks_uri conforme mostrado na saída de exemplo. Você os utilizará na próxima seção .

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

Definindo a política OIDC de entrada do NGINX

O suporte para autenticação baseada em OIDC foi adicionado no NGINX Ingress Controller 1.10.0. Para mais detalhes, leia Logon único 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 tipo: Metadados da política: nome: oidc-policy especificação: 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
   

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

   $ kubectl aplicar -f oidc.yaml
   

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

   $ kubectl obter política NOME ESTADO IDADE oidc-policy Válido 2m
   

Definindo o objeto VirtualServer

VirtualServer e VirtualServerRoute são recursos do NGINX Ingress que provisionam as regras para roteamento de tráfego de entrada para os aplicativos 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 sob o prefixo de caminho / para que os usuários que solicitarem caminhos que correspondam ao prefixo sejam autenticados antes que a solicitação seja enviada por proxy para o serviço app-server-payload .

   apiVersão: k8s.nginx.org/v1
   tipo: VirtualServer
   metadados:
   nome: app-ingress
   especificação:
   host: unit-demo.linkpc.net
   upstreams:
   -nome: app-server-payload
   serviço: app-server-svc
   porta: 80
   rotas:
   - caminho: /
   políticas:
   - nome: oidc-policy
   ação:
   proxy: 
   upstream: app-server-payload
   

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

   $ kubectl aplicar -f aplicativo-servidor-virtual.yaml
   

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

   $ kubectl get vs NOME ESTADO HOST IP PORTAS IDADE app-ingress Unidade válida-demo.linkpc.net 2m
   

Testando o ambiente

Para testar se a integração do OIDC Okta está funcionando corretamente, digite o nome do host do NGINX Ingress Controller na barra de endereços do seu navegador. Você será redirecionado para o portal de login do Okta, onde poderá inserir as credenciais da sua conta de desenvolvedor do Okta para obter acesso ao aplicativo de back-end.

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

Adicionando usuários ao aplicativo

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

Criando integrações SSO para vários aplicativos

Descarregamos o processo de autenticação de um aplicativo configurando o SSO com o Okta como IdP e o NGINX Ingress Controller como a parte de retransmissão. Na prática, você provavelmente desejará permitir que os usuários acessem muitos aplicativos usando um único conjunto de credenciais. Você também pode querer ter a flexibilidade de variar quais aplicativos um usuário pode acessar. Você pode fazer isso repetindo as instruções nas seções acima:

• Pré-configurando o IdP para integrar outros aplicativos com o Okta
• Definindo a política OIDC de entrada do NGINX para definir outras políticas OIDC
• Definindo o objeto VirtualServer para referenciar políticas adicionais

No exemplo descrito no diagrama a seguir, há dois subdomínios, unit-demo.marketing.net e unit-demo.engineering.net , que resolvem para o endereço IP externo do NGINX Ingress Controller. O NGINX Ingress Controller roteia solicitações para o aplicativo de marketing ou para o aplicativo de engenharia com base no subdomínio. Para conceder acesso a um usuário, na guia Atribuições da GUI do Okta, você associa o usuário a cada aplicativo apropriado. O Okta então concede ao usuário autenticado um cookie de sessão de curta duração para acesso a esses aplicativos.

Conclusão

Ao implementar o SSO baseado em OIDC no Kubernetes usando o NGINX Ingress Controller como a parte de retransmissão e o Okta como o IdP, você alivia a autenticação e a autorização dos seus desenvolvedores, liberando-os para se concentrarem na otimização da lógica de negócios em seus aplicativos. Para começar a usar o NGINX Ingress Controller baseado no NGINX Plus , solicite hoje mesmo um teste gratuito de 30 dias ou entre em contato conosco para discutir seus casos de uso .