Habilitando multilocação e isolamento de namespace no Kubernetes com NGINX

[ Editor – Este post é um extrato do nosso eBook abrangente, Managing Kubernetes Traffic with F5 NGINX: Um guia prático . Baixe gratuitamente hoje mesmo .]

À medida que as organizações crescem, os fluxos de trabalho de desenvolvimento e operação no Kubernetes se tornam mais complexos. Geralmente é mais econômico – e pode ser mais seguro – para as equipes compartilhar clusters e recursos do Kubernetes, em vez de cada equipe obter seu próprio cluster. Mas pode haver danos críticos em suas implantações se as equipes não compartilharem esses recursos de maneira segura ou se hackers explorarem suas configurações.

Práticas de multilocação e isolamento de namespace no nível de rede e de recursos ajudam as equipes a compartilhar recursos do Kubernetes com segurança. Você também pode reduzir significativamente a magnitude das violações isolando aplicativos por locatário. Esse método ajuda a aumentar a resiliência porque apenas subseções de aplicativos pertencentes a equipes específicas podem ser comprometidas, enquanto os sistemas que fornecem outras funcionalidades permanecem intactos.

O NGINX Ingress Controller oferece suporte a vários modelos de multilocação, mas vemos dois padrões principais. O padrão do provedor de serviços de infraestrutura normalmente inclui várias implantações do NGINX Ingress Controller com isolamento físico, enquanto o padrão corporativo normalmente usa uma implantação compartilhada do NGINX Ingress Controller com isolamento de namespace. Nesta seção, exploramos o padrão empresarial em profundidade; para obter informações sobre como executar vários controladores de entrada NGINX, consulte nossa documentação .

Delegação com o NGINX Ingress Controller

O NGINX Ingress Controller oferece suporte ao recurso Ingress padrão do Kubernetes e aos recursos personalizados do NGINX Ingress, o que permite um gerenciamento de tráfego mais sofisticado e a delegação de controle sobre a configuração para várias equipes. Os recursos personalizados são VirtualServer, VirtualServerRoute , GlobalConfiguration , TransportServer e Policy .

Com o NGINX Ingress Controller, os administradores de cluster usam recursos do VirtualServer para provisionar regras de domínio (nome do host) do Ingress que roteiam tráfego externo para aplicativos de back-end, e recursos do VirtualServerRoute para delegar o gerenciamento de URLs específicos aos proprietários de aplicativos e equipes de DevOps.

Há dois modelos que você pode escolher ao implementar multilocação no seu cluster Kubernetes: autoatendimento completo e autoatendimento restrito .

Implementando o autoatendimento completo

Em um modelo de autoatendimento completo, os administradores não estão envolvidos em alterações diárias na configuração do NGINX Ingress Controller. Eles são responsáveis apenas por implantar o NGINX Ingress Controller e o Kubernetes Service , que expõe a implantação externamente. Os desenvolvedores então implantam aplicativos dentro de um namespace atribuído sem envolver o administrador. Os desenvolvedores são responsáveis por gerenciar segredos TLS, definir a configuração de balanceamento de carga para nomes de domínio e expor seus aplicativos criando recursos VirtualServer ou Ingress padrão.

Para ilustrar esse modelo, replicamos o aplicativo bookinfo de exemplo (originalmente criado pelo Istio) com dois subdomínios, a.bookinfo.com e b.bookinfo.com , conforme ilustrado no diagrama a seguir. Depois que o administrador instala e implanta o NGINX Ingress Controller no namespace nginx-ingress (destacado em verde), as equipes DevA (rosa) e DevB (roxo) criam seus próprios recursos do VirtualServer e implantam aplicativos isolados em seus namespaces ( A e B , respectivamente).

As equipes DevA e DevB definem regras de entrada para seus domínios para rotear conexões externas para seus aplicativos.

A equipe DevA aplica o seguinte objeto de recurso VirtualServer para expor aplicativos para o domínio a.bookinfo.com no namespace A.

Da mesma forma, a equipe DevB aplica o seguinte recurso VirtualServer para expor aplicativos para o domínio b.bookinfo.com no namespace B.

Implementando o autoatendimento restrito

Em um modelo de autoatendimento restrito, os administradores configuram os recursos do VirtualServer para rotear o tráfego que entra no cluster para o namespace apropriado, mas delegam a configuração dos aplicativos nos namespaces às equipes de desenvolvimento responsáveis. Cada uma dessas equipes é responsável apenas por sua sub-rota de aplicativo, conforme instanciada no recurso VirtualServer, e usa recursos do VirtualServerRoute para definir regras de tráfego e expor sub-rotas de aplicativo dentro de seu namespace.

Conforme ilustrado no diagrama, o administrador do cluster instala e implanta o NGINX Ingress Controller no namespace nginx-ingress (destacado em verde) e define um recurso VirtualServer que define regras baseadas em caminho que fazem referência às definições de recursos VirtualServerRoute.

Esta definição de recurso VirtualServer define duas regras baseadas em caminho que se referem às definições de recurso VirtualServerRoute para duas sub-rotas, /productpage-A e /productpage-B .

As equipes de desenvolvedores responsáveis pelos aplicativos nos namespaces A e B definem então os recursos VirtualServerRoute para expor sub-rotas de aplicativos dentro de seus namespaces. As equipes são isoladas por namespace e restritas à implantação de sub-rotas de aplicativos definidas pelos recursos do VirtualServer provisionados pelo administrador:

• A equipe DevA (rosa no diagrama) aplica o seguinte recurso VirtualServerRoute para expor a regra de sub-rota do aplicativo definida pelo administrador para /productpage-A .

• A equipe DevB (roxa) aplica o seguinte recurso VirtualServerRoute para expor a regra de sub-rota do aplicativo definida pelo administrador para /productpage-B .

Para obter mais informações sobre os recursos que você pode configurar nos recursos VirtualServer e VirtualServerRoute, consulte a documentação do NGINX Ingress Controller .

Observação:  Você pode usar tipos de Ingress mescláveis para configurar o roteamento entre namespaces, mas em um modelo de delegação de autoatendimento restrito, essa abordagem tem três desvantagens em comparação aos recursos VirtualServer e VirtualServerRoute:

1. É menos seguro.
2. À medida que sua implantação do Kubernetes cresce, se torna maior e mais complexa, ela se torna cada vez mais propensa a modificações acidentais, porque os tipos de Ingress mescláveis não impedem que os desenvolvedores definam regras de Ingress para nomes de host dentro de seu namespace.
3. Ao contrário dos recursos VirtualServer e VirtualServerRoute, os tipos Ingress mescláveis não permitem que o recurso Ingress primário (“mestre”) controle os caminhos dos recursos Ingress “minion”.

Aproveitando o Kubernetes RBAC em um modelo de autoatendimento restrito

Você pode usar o controle de acesso baseado em função (RBAC) do Kubernetes para regular o acesso de um usuário a namespaces e recursos do NGINX Ingress com base nas funções atribuídas ao usuário.

Por exemplo, em um modelo de autoatendimento restrito, apenas administradores com privilégios especiais podem ter acesso seguro aos recursos do VirtualServer – como esses recursos definem o ponto de entrada para o cluster Kubernetes, o uso indevido pode levar a interrupções em todo o sistema.

Os desenvolvedores usam recursos do VirtualServerRoute para configurar regras de entrada para as rotas de aplicativos que eles possuem, então os administradores definem políticas RBAC que permitem que os desenvolvedores criem apenas esses recursos. Eles podem até restringir essa permissão a namespaces específicos se precisarem regular ainda mais o acesso do desenvolvedor.

Em um modelo de autoatendimento completo, os desenvolvedores podem receber acesso com segurança aos recursos do VirtualServer, mas, novamente, o administrador pode restringir essa permissão a namespaces específicos.

Para obter mais informações sobre autorização RBAC, consulte a documentação do Kubernetes .

Adicionando Políticas

Os recursos da política NGINX são outra ferramenta para permitir que equipes distribuídas configurem o Kubernetes em implantações de multilocação. Os recursos de política permitem funcionalidades como autenticação usando OAuth e OpenID Connect (OIDC), limitação de taxa e firewall de aplicativo da web (WAF). Os recursos de política são referenciados nos recursos VirtualServer e VirtualServerRoute para entrarem em vigor na configuração do Ingress.

Por exemplo, uma equipe responsável pelo gerenciamento de identidade em um cluster pode definir políticas JSON Web Token (JWT) ou OIDC como a seguinte, que usa o Okta como provedor de identidade OIDC (IdP).

As equipes de NetOps e DevOps podem usar os recursos VirtualServer ou VirtualServerRoute para referenciar essas políticas, como neste exemplo.

Juntos, os recursos NGINX Policy, VirtualServer e VirtualServerRoute permitem arquiteturas de configuração distribuídas, onde os administradores podem facilmente delegar a configuração a outras equipes. As equipes podem montar módulos em namespaces e configurar o NGINX Ingress Controller com casos de uso sofisticados de forma segura, escalável e gerenciável.

Para obter mais informações sobre recursos de política, consulte a documentação do NGINX Ingress Controller .

Esta postagem é um extrato do nosso e-book abrangente, Gerenciando o tráfego do Kubernetes com NGINX: Um guia prático . Baixe gratuitamente hoje mesmo .

Experimente o NGINX Ingress Controller baseado no NGINX Plus hoje mesmo em um teste gratuito de 30 dias ou entre em contato conosco para discutir seus casos de uso .