Gerenciamento de configurações mais seguro com o NGINX Controller

Brian EhlertDiretor de Gestão de Produtos

Em conversas com nossos clientes ao longo do último ano, observamos alguns temas recorrentes que os levam a avaliar produtos de orquestração, como o NGINX Controller:

• Complexidade – Gerenciar, manter, validar e aplicar grandes conjuntos de objetos de configuração individuais provenientes de diferentes fontes não é uma tarefa fácil.
• Fragilidade – A expansão pode acontecer rapidamente, muitas vezes em resposta a um evento. Às vezes, ela é estratégica, mas, como costuma ocorrer em todos os departamentos de operações, acontece de forma não planejada e orgânica.
• Segurança – Evitar erros e identificar problemas antes da implantação em produção são pilares da metodologia ágil. Essas práticas também ajudam a reduzir a complexidade e a fragilidade.

Essas não são preocupações que os clientes geralmente enfrentam ao implantar um aplicativo pela primeira vez. Na verdade, elas surgem com o passar do tempo, à medida que o aplicativo se torna bem-sucedido e precisa ser dimensionado. Constatamos que o dimensionamento – ou, mais precisamente, o dimensionamento não planejado – é a causa raiz comum das preocupações listadas acima.

Felizmente, o modelo de objetos de configuração do NGINX Controller aborda todas as três questões:

• Ela reduz a complexidade da implantação ao reunir em um único local todos os componentes de configuração que podem afetar um conjunto específico de instâncias do NGINX Plus.
• Ela reduz a fragilidade ao permitir que as equipes validem e testem as configurações antes de colocá-las em produção, facilitando a detecção rápida de falhas e garantindo que o tráfego dos usuários em produção continue fluindo.
• Ele promove a segurança por ser altamente flexível. Em vez de obrigar você a ajustar seus processos ao modelo, o modelo de objetos de configuração foi projetado para se alinhar aos fluxos de trabalho da sua empresa e à divisão de responsabilidades – você pode conceder a diferentes unidades de negócios o nível adequado de controle sobre os elementos de configuração, conforme necessário.

Objetos de configuração do Controller

Vamos nos aprofundar um pouco em alguns dos principais objetos de configuração para que você entenda melhor como funciona o modelo de Controller.

Ambientes

Na maioria das organizações, o software passa por várias etapas antes do lançamento: desenvolvimento, aceitação do usuário, pré-produção, produção e outras etapas de verificação da qualidade. Essas etapas correspondem ao objeto do NGINX Controller chamado Ambiente.

Um Ambiente é uma zona de isolamento para elementos de configuração no Controller. Geralmente, é nesse nível que o controle de acesso baseado em função (RBAC) é definido. Os Ambientes podem manter artefatos de configuração idênticos ao longo das várias etapas, fazendo apenas as alterações mínimas necessárias em itens como servidores de destino, data centers e outros objetos de infraestrutura que normalmente diferem entre os Ambientes.

Gateways

Um Gateway é um objeto de configuração dentro de um Ambiente, geralmente usado como o nível superior para definir como os aplicativos são disponibilizados aos clientes — com configurações como nome do host, protocolo e comportamento de TLS/SSL — embora essas configurações também possam ser feitas em um nível inferior. Na prática, as equipes de operações de rede (NetOps), responsáveis por gerenciar dispositivos de rede de borda ou a DMZ, geralmente são as proprietárias dos objetos Gateway. Os Gateways também utilizam o conceito de “Placement”, que é a forma de vincular o Controller às instâncias do NGINX Plus que recebem as configurações e realizam o trabalho propriamente dito.

Aplicativos

O próximo nível abaixo é o objeto de configuração App, no qual você começa a modelar aplicações e agrupar comportamentos de controle de tráfego. Você pode usar quantos Apps forem necessários para atender às necessidades da sua organização. O único requisito é que cada App seja único dentro de um Environment.

Componentes

Em um App, os Componentes descrevem o comportamento desejado de direcionamento de tráfego. No caso mais simples, todo o tráfego de um determinado caminho é enviado ao mesmo grupo de servidores. No entanto, os Componentes também controlam configurações mais avançadas, como manipulação de cabeçalhos, reescrita de URLs, comportamentos de balanceamento de carga no backend, gerenciamento de cookies e outras opções. O comportamento do nome do host e de TLS/SSL também pode ser definido nesse nível.

Juntando Tudo

Veja uma representação visual da relação entre os objetos de configuração:

Observe que há apenas dois grupos interagindo com o Controller – neste caso, duas equipes de desenvolvimento, Indicações e Transferências. Na realidade, sabemos que o número de pessoas envolvidas na entrega e na segurança de aplicações provavelmente é muito maior, abrangendo redes e segurança (Operações de Plataforma), DevOps, desenvolvimento de aplicações e muito mais. As equipes com mais conhecimento podem definir políticas e criar fluxos de trabalho de autoatendimento alinhados às práticas recomendadas, além de estabelecer limites de segurança para as equipes que trabalham com Aplicações, Componentes e Gateways no Ambiente “Dev”, que abrange os data centers da organização nas regiões Leste e Oeste.

Vamos analisar isso de uma maneira um pouco diferente, mais sob a perspectiva da linha de negócios (LOB). Os responsáveis pelas LOBs estão cada vez mais tomando decisões sobre aplicações modernas.

O diagrama a seguir ilustra um cenário mais próximo da realidade, com um grupo muito maior de usuários, incluindo várias equipes de linhas de negócios (LOB) e Shawn, responsável por gerenciar todas as renovações de certificados.

Agora, temos mais atores individuais e pipelines afetando o fluxo de dados resultante.

À medida que cada pipeline individual passa pelas diversas alterações de objetos, desde o controle de código-fonte (como o GitHub) até o Controller, os objetos de configuração são validados no Controller e, em seguida, combinados com quaisquer objetos relacionados antes que as alterações sejam enviadas às instâncias do NGINX Plus.

É assim que o Controller pode ajudar a tornar o gerenciamento de configurações mais seguro: garantindo que as alterações mais recentes sejam compatíveis com as configurações anteriores e com as configurações de outros proprietários de aplicações e linhas de negócios (LOB).

Sabemos que, na prática, todas as configurações aplicadas a uma única instância do NGINX Plus devem ser viáveis, mas não podem entrar em conflito, se sobrepor ou ser incompatíveis entre si. Também é importante identificar os conflitos antecipadamente e informar as pessoas responsáveis por fornecer a configuração de cada componente individual.

No exemplo acima, quando o Componente Indicações tenta usar o mesmo padrão de expressão regular que o Componente Transferências já implementou, um conflito de caminho é detectado imediatamente, e a equipe de Indicações pode ser notificada muito antes de tentar implantar essa configuração em produção – evitando as muitas dores de cabeça associadas a uma configuração incorreta.

Com relação aos certificados, Shawn tem permissão — por meio da funcionalidade de RBAC do Controller — para implementar alterações nos certificados imediatamente. Os responsáveis pela manutenção do Gateway e dos Components só precisam referenciar os certificados corretos, e Shawn pode gerenciá-los com segurança ao longo de todo o ciclo de vida. Se Shawn atualizar um certificado no Controller, ele será distribuído às instâncias corretas, evitando o pânico associado à expiração de um certificado.

Agora que o NGINX Controller tem todos os seus objetos de configuração e uma associação de Placement com uma ou mais instâncias do NGINX Plus, ele pode executar as etapas finais: aplicar a configuração.

Segurança na prática

Em última análise, o objetivo do gerenciamento de configurações com o Controller é aplicar a configuração correta às instâncias corretas do NGINX Plus no local adequado. Garantir que Aplicativos, Componentes, Gateways e todos os certificados e instâncias associados estejam configurados corretamente resulta em implantações mais seguras e escaláveis.

Essa verificação final é a última etapa do processo de gerenciamento de configuração que o Controller torna mais fácil e seguro. Toda a configuração é verificada à medida que é aplicada a uma instância do NGINX Plus que teve alguma alteração em um objeto associado — como a persistência de sessão em um grupo de cargas de trabalho da Web para o NGINX Plus implantado como proxy —, garantindo que a instância seja compatível com a configuração desejada. Se essa condição for atendida, a configuração será aplicada. E, como última medida de segurança, se ocorrer alguma falha durante a aplicação da configuração, o Controller reverterá para uma configuração anterior.

Além de garantir que as configurações sejam aprovadas, o Controller também pode aproveitar recursos avançados do NGINX, como a drenagem de sessões, quando uma nova configuração é aplicada – garantindo que os sites mantenham a disponibilidade e o desempenho durante as alterações.

Para as equipes de operações, os conceitos e os modelos de fluxo de trabalho descritos acima contribuem para a segurança que o NGINX Controller oferece no gerenciamento de configurações. Essas proteções ajudam a alinhar os fluxos de trabalho e as diversas equipes que trabalham com aplicações modernas, além de atender às necessidades da empresa.

Para experimentar o NGINX Controller, inicie sua avaliação gratuita de 30 dias hoje mesmo ou entre em contato conosco para conversar sobre seus casos de uso.

Sobre o autor

Brian EhlertDiretor de Gestão de Produtos

Mais publicações de Brian Ehlert