Configurar o isolamento de rede para AKS (Serviço de Kubernetes do Azure)

Concluído

À medida que você gerencia clusters no Serviço de Kubernetes do Azure (AKS), geralmente é necessário isolar equipes e cargas de trabalho. O AKS permite flexibilidade na forma como você executa clusters multilocatários e isola recursos. Para maximizar seu investimento no Kubernetes, é importante entender os recursos de multilocação e de isolamento do Serviço de Kubernetes do Azure.

Design de clusters para multi locação

O Kubernetes permite isolar logicamente as equipes e as cargas de trabalho no mesmo cluster. A meta é fornecer o menor número de privilégios no escopo dos recursos de que cada equipe precisa. Um namespace no Kubernetes cria um limite de isolamento lógico. Outros recursos e considerações adicionais do Kubernetes para isolamento e multilocação incluem as seguintes áreas:

  • Práticas recomendadas para isolamento de cluster no Azure Kubernetes Service (AKS)
    • Projetar clusters para multilocação
      • Agendamento
      • Rede
      • Autenticação e autorização
      • Contêineres
  • Clusters isolados logicamente
  • Clusters isolados fisicamente

Agendamento

O agendamento usa recursos básicos, como cotas de recursos e orçamentos de interrupção de pod.

Os recursos mais avançados do agendador incluem:

  • Taints e tolerâncias.
  • Seletores de nó.
  • Afinidade ou antiafinidade de nó e Pod.

Rede

Rede usa políticas de rede para controlar o fluxo de tráfego para dentro e para fora dos pods.

Autenticação e autorização

Autenticação e autorização usa:

  • RBAC (controle de acesso bem função).
  • Integração do Microsoft Entra.
  • Identidades de pod.
  • Segredos no Azure Key Vault.

Contêineres

Os contêineres incluem:

  • O complemento do Azure Policy para o Serviço de Kubernetes do Azure para impor a segurança de pod.
  • Admissão de segurança de pod.
  • Verificação de imagens e do runtime em busca de vulnerabilidades.
  • Uso de Armadura de aplicativo ou Seccomp (Computação segura) para restringir o acesso de contêiner ao nó subjacente.

Clusters isolados logicamente

Diretrizes de melhores práticas: Separar equipes e projetos usando isolamento lógico. Minimize o número de clusters de Serviço de Kubernetes do Azure físicos que você implanta para isolar equipes ou aplicativos.

Com o isolamento lógico, você pode usar um único cluster do AKS para várias cargas de trabalho, equipes ou ambientes. Os namespaces do Kubernetes formam o limite de isolamento lógico para cargas de trabalho e recursos.

Diagrama mostrando um exemplo de clusters logicamente isolados.

A separação lógica de clusters geralmente fornece uma densidade mais alta de pod do que os clusters isolados fisicamente, com menos capacidade de computação em excesso colocada ociosa no cluster. Quando combinado com o auto escalador de cluster do Kubernetes, você pode dimensionar o número de nós para cima ou para baixo para atender às demandas. Essa abordagem recomendada para o dimensionamento automático minimiza os custos ao executar apenas o número de nós necessários.

Os ambientes do Kubernetes não são totalmente seguros para uso hostil multilocatário. Em um ambiente multilocatário, vários locatários trabalham em uma infraestrutura compartilhada. Se nenhum dos locatários for confiável, você precisará de um planejamento extra para impedir que os locatários afetem a segurança e o serviço de outros.

Outros recursos de segurança, como o RBAC do Kubernetes para nós, bloqueiam explorações com eficiência. Para a segurança verdadeira ao executar cargas de trabalho multilocatário hostis, você deve confiar apenas em um hipervisor. O domínio de segurança para o Kubernetes se torna o cluster inteiro e não um nó individual.

Para esses tipos de cargas de trabalho multilocatário hostis, você deve usar clusters fisicamente isolados.

Clusters isolados fisicamente

Diretrizes de melhores práticas: Minimize o uso do isolamento físico para cada implantação de equipe ou aplicativo separada e use o isolamento lógico.

A separação física de clusters AKS é uma abordagem comum ao isolamento de cluster. Neste modelo de isolamento, as equipes ou cargas de trabalho são atribuídas a seu próprio cluster AKS. Embora o isolamento físico possa parecer a maneira mais fácil de isolar cargas de trabalho ou equipes, ele adiciona gerenciamento e sobrecarga financeira. Com clusters isolados fisicamente, você precisa manter vários clusters e fornecer acesso e atribuir permissões individualmente. Você também é cobrado por cada nó individual.

Diagrama mostrando um exemplo de clusters fisicamente isolados.

Clusters isolados fisicamente geralmente têm uma baixa densidade de pod. Como cada equipe ou carga de trabalho possui seu próprio cluster AKS, o cluster geralmente é provisionado em excesso com recursos de computação. Geralmente, poucos pods são agendados nesses nós. A capacidade de nó não solicitada não pode ser usada para aplicativos ou serviços em desenvolvimento por outras equipes. Esses recursos em excesso contribuem para os custos adicionais em clusters isolados fisicamente.