Um guia para lidar com a sobrecarga de políticas nos sistemas distribuídos atuais

Eu desafio você a participar da KubeCon e ir a uma sessão sobre “política”. Quando você chegar lá, não se surpreenda se ficar se perguntando: “De que tipo de política se trata realmente isso?”

No recente KubeCon em Salt Lake City, eu me vi correndo entre as sessões em que “política” era proeminente nos títulos. Mas para cada orador, a palavra significava algo completamente diferente.

Como alguém focado em políticas de rede baseadas em rótulos, muitas vezes tive que falar com os palestrantes com antecedência para perguntar: “Esta sessão de política é sobre políticas de rede, controladores de admissão ou conformidade?”

Essas trocas revelam um problema crescente nos ecossistemas atuais de computação distribuída e nativa em nuvem. O termo “política” é usado de forma tão ampla que é praticamente uma abstração em si.

Para resolver isso, examinarei mais de perto os oito tipos diferentes de políticas frequentemente discutidos sob esse amplo termo e por que elas são cruciais para entender a infraestrutura, a segurança e a automação em sistemas distribuídos.

1. Políticas de rede

As políticas de rede são importantes para controlar e gerenciar como os sistemas em uma rede se comunicam entre si, especialmente em ambientes como o Kubernetes.

A maioria políticas de rede use uma abordagem de lista de permissões. Isso significa que as conexões são bloqueadas por padrão, a menos que sejam especificamente permitidas pela política. Essas políticas podem usar regras baseadas em endereços IP ou rótulos para decidir quais recursos podem se comunicar.

Como microsserviços e aplicativos baseados em contêineres se tornando cada vez mais comum, é ainda mais importante controlar cuidadosamente como os serviços se comunicam e mantê-los isolados quando necessário.

Por exemplo, as políticas de rede do Kubernetes são altamente personalizáveis. Eles podem definir regras de trânsito para tráfego interno (leste-oeste) e tráfego externo (norte-sul). Essa flexibilidade os torna ferramentas poderosas para manter os sistemas seguros, mas também os torna mais complicados de criar e gerenciar.

2. Políticas do controlador de admissão

Os controladores de admissão são políticas especializadas em Kubernetes. Eles avaliam as solicitações de API para decidir se devem ser permitidas ou alteradas. Eles são essencialmente guardiões. Eles impõem determinados padrões ou práticas de segurança em todo o cluster antes que uma solicitação de API possa prosseguir.

Por exemplo, as políticas do controlador de admissão podem:

• Imponha limites de recursos automaticamente

• Adicionar rótulos às implantações

• Bloqueie o uso de configurações inseguras

Esses tipos de políticas podem interceptar e alterar solicitações. Isso os torna cruciais para manter a segurança consistente nos clusters. Mas eles só abordam políticas no ciclo de vida de chamadas de API do Kubernetes.

3. Políticas de OPA e Kyverno

As políticas da OPA e da Kyverno são simplesmente controladoras de admissão ou são algo mais?

O Open Policy Agent (OPA) e o Kyverno oferecem mais do que os controladores de admissão tradicionais. Embora geralmente trabalhem como controladores de admissão no Kubernetes, eles introduzem uma linguagem de política mais flexível e abrangente. Isso permite que as organizações definam e apliquem regras complexas em vários sistemas.

• OPA (Agente de Política Aberta) é um mecanismo de políticas versátil que pode ser usado em todos os ambientes. Ele usa uma linguagem chamada Rego, que pode lidar com requisitos políticos complexos. Além do Kubernetes, o OPA pode gerenciar políticas para pipelines de CI/CD, microsserviços e até mesmo recursos em nuvem.

• Kyverno é um mecanismo de políticas feito especificamente para o Kubernetes. É uma maneira mais simples de definir políticas em YAML. Muitas pessoas o preferem para configurar o Kubernetes. Ele funciona bem com objetos nativos do Kubernetes, o que facilita a criação e a aplicação de políticas.

Essas ferramentas podem controlar o que dá acesso a um sistema, mas podem fazer muito mais em uma variedade de aplicativos e sistemas. Eles podem gerenciar:

• Gerenciamento do ciclo de vida

• Validação

• Verificações de conformidade personalizadas

4. Cotas de recursos e políticas de limite

As políticas de gerenciamento de recursos ajudam a controlar a quantidade de CPU, memória e armazenamento que um cluster Kubernetes pode usar. Essas políticas são importantes em ambientes compartilhados porque evitam que um aplicativo ou usuário use muitos recursos.

• Cotas geralmente são definidos para cada namespace. Eles limitam a quantidade total de recursos que um namespace pode usar, de forma que nenhum namespace único ocupe demais.

• Limites defina o menor e maior número de recursos que um contêiner ou pod pode usar. Isso garante que nenhuma carga de trabalho use muitos recursos e cause problemas para o resto do sistema.

Com essas políticas, os administradores podem equilibrar recursos, o que é especialmente importante em ambientes com muitos usuários ou aplicativos que escalam dinamicamente. Embora essas políticas ajudem a manter o sistema estável, elas também tornam as coisas mais complicadas à medida que interagem com outras camadas de políticas, como controles de automação e admissão.

Essas políticas ajudam os administradores a equilibrar recursos, o que é especialmente importante em sistemas com muitos usuários ou aplicativos que escalam dinamicamente. No entanto, gerenciar essas políticas pode ser um desafio. Eles geralmente se sobrepõem a outras políticas, como controles de automação e admissão.

5. Políticas de segurança de pods (PSPs)

Políticas de segurança de pods (PSPs) em Kubernetes defina as configurações de segurança no nível do pod. Isso inclui impedir que os contêineres sejam executados como root ou exijam determinados recursos do Linux.

Mas os PSPs estão sendo eliminados gradualmente no Kubernetes. Eles estão sendo substituídos por opções mais novas, como os Pod Security Standards (PSS) e ferramentas externas, como OPA e Kyverno.

Os PSPs foram projetados para adicionar configurações de segurança granulares que evitam que cargas de trabalho sejam executadas com configurações excessivamente permissivas. Embora sejam úteis, gerenciar PSPs junto com outras políticas pode ser confuso. As ferramentas mais recentes oferecem formas mais flexíveis de reforçar a segurança, geralmente sob o termo geral de “políticas de segurança”.

6. Políticas de service mesh

Em ambientes de microsserviços, malhas de serviço como o Istio ou o Linkerd, adicionam outra camada de política que protege e monitora a comunicação entre os serviços. Essas políticas geralmente:

• Autentique e autorize o tráfego: As malhas de serviço usam mTLS (TLS mútuo) para criptografar a comunicação entre serviços. Eles também permitem que você defina políticas para quais serviços podem se comunicar entre si, adicionando outra camada de controle de acesso.

• Gerencie o tráfego: As políticas de service mesh controlam o roteamento, o balanceamento de carga e o failover. Isso torna mais fácil fazer coisas como testes A/B, lançamentos canários ou direcionar o tráfego para diferentes versões do serviço.

Diferentemente das políticas de rede, as políticas de service mesh funcionam na camada do aplicativo, afetando a forma como os serviços interagem. Essas políticas são cruciais para gerenciar o tráfego de serviço a serviço. Mas às vezes elas podem ser confusas porque se sobrepõem às políticas de rede.

7. Políticas de conformidade

Políticas de conformidade pode abranger padrões operacionais, de acesso e de gerenciamento de dados para garantir que os sistemas atendam aos requisitos legais ou internos de conformidade, como GDPR, HIPAA ou SOC 2. Essas políticas podem desempenhar um papel importante em muitas partes de um sistema, afetando a segurança, o registro e o armazenamento de dados.

Por exemplo, uma política de conformidade pode exigir que os dados sejam armazenados somente em locais específicos (residência de dados) ou que os registros de auditoria sejam mantidos por um determinado período de tempo. No Kubernetes, ferramentas como OPA e Kyverno costumam ser usadas para aplicar essas políticas, monitorando e auditando continuamente os sistemas em tempo real para garantir que atendam aos padrões.

As políticas de conformidade são especialmente importantes em setores com regulamentações rígidas, como saúde e finanças. Como eles funcionam em várias partes de um sistema e geralmente se sobrepõem às políticas de segurança, gerenciá-los pode se tornar complexo. Apesar disso, eles são cruciais para garantir que os sistemas permaneçam seguros, organizados e compatíveis.

8. Políticas de automação e ciclo de vida

As políticas de automação controlam quando e como os recursos de infraestrutura são criados, atualizados ou removidos. Essas políticas são uma parte importante da Infraestrutura como Código (IaC), na qual as configurações de recursos são escritas como código e gerenciadas por meio de pipelines de CI/CD.

Por exemplo, as políticas de automação podem lidar com tarefas como escalar automaticamente os recursos, limpar os não utilizados ou gerenciar as etapas do ciclo de vida de uma implantação. Eles também podem se integrar aos pipelines de CI/CD para acionar compilações, executar testes e gerenciar implantações. Isso cria ambientes autogerenciáveis que podem se ajustar às mudanças da carga de trabalho em tempo real.

As políticas de automação podem simplificar o gerenciamento de recursos e garantir as melhores práticas em ambientes nativos da nuvem. Mas elas interagem estreitamente com outras políticas, como as de gerenciamento de recursos e controle de admissão, o que pode aumentar a complexidade.

Você ainda está seguindo? A sobreposição de “política” continua...

Se você ainda não está sobrecarregado, aqui está a diferença. Muitas organizações agora têm políticas de política.

Elas são chamadas de “metapolíticas”. Eles atuam como barreiras, definindo regras para quem pode criar, gerenciar ou aplicar outras políticas.

Por exemplo, uma metapolítica pode decidir quais equipes podem criar políticas de rede específicas ou quem está autorizado a criar políticas de controle de admissão. Essas políticas geralmente dependem do controle de acesso baseado em funções (RBAC).

Em sistemas grandes, Políticas do RBAC pois as políticas são essenciais. Eles garantem que somente administradores ou equipes específicos possam fazer alterações nas políticas. Ao aplicar controles rígidos do RBAC, essas “políticas de política” garantem que outras políticas não ultrapassem ou interfiram na infraestrutura crítica.

Considerações finais: Um roteiro para superar a sobrecarga de políticas

À medida que os ambientes distribuídos e nativos da nuvem crescerem, a ideia de “política” continuará mudando. Eles se tornarão mais complicados, especializados e, às vezes, até contraditórios.

Para evitar a sobrecarga de políticas, é importante usar convenções de nomenclatura claras, criar documentação que defina cada tipo de política e fazer bom uso das ferramentas de política.

E da próxima vez que você estiver em uma conferência de tecnologia e ouvir “política”, reserve um momento para perguntar: “Qual delas?!” Isso pode te salvar de muita confusão, ou até mesmo de uma corrida entre corredores!

Entre em contato conosco hoje para saber como a Illumio pode simplificar suas políticas de segurança de rede em ambientes de nuvem, endpoint e data center.