Segurança do AKS

Este artigo orienta você pelos aspectos da governança de segurança do Serviço de Kubernetes do Azure (AKS) a serem considerados antes de implementar qualquer solução.

O artigo se concentra em como implementar soluções usando o Azure e o software de código aberto. As decisões que você toma ao criar uma zona de aterrissagem em escala empresarial podem predefinir parcialmente sua governança. Para entender os princípios de governança, consulte Governança e conformidade de segurança em escala empresarial.

Superfícies de ataque

Considere as cinco superfícies de ataque a seguir ao criar uma estratégia de segurança para clusters do Kubernetes:

• Compilação
• Registro
• Cluster
• Nó
• Aplicativo

Para cada categoria, discutimos os principais riscos a serem considerados e contramedidas para esses riscos.

Promover a segurança

A segurança do build está relacionada ao uso adequado do DevSecOps com imagens de contêiner.

Principais riscos

Uma configuração de imagem deficiente pode levar a vulnerabilidades de segurança no pipeline. Por exemplo, você pode ter contêineres em execução com privilégios maiores do que o necessário. Os contêineres também podem ser configurados para permitir determinado tipo de acesso à rede, o que pode colocar o sistema em risco. Não limitar as chamadas de sistema permitidas às chamadas necessárias para a operação segura de contêineres pode aumentar o risco de um contêiner comprometido.

Outra vulnerabilidade pode ser permitir que o contêiner obtenha acesso a um diretório confidencial do host ou permitir que os contêineres alterem os locais que controlam a função básica do host.

Contêineres não autorizados são contêineres não planejados em um ambiente. Eles podem ser o resultado de desenvolvedores testando seu código em ambientes de teste. Esses contêineres podem não ter passado por uma verificação rigorosa em busca de vulnerabilidades ou estar configurados corretamente. Essas vulnerabilidades podem criar um ponto de entrada para invasores.

Usar imagens base que não são de fontes confiáveis ou não estão atualizadas com atualizações de segurança também pode levar a vulnerabilidades nos contêineres que eles usam para criar.

Contramedidas de risco

A segurança de build está relacionada à implementação de DevSecOps para antecipar a segurança e corrigir a maioria dos problemas antes que eles comecem a passar pelo pipeline. Não se trata de colocar toda a responsabilidade nos desenvolvedores, e sim de compartilhá-la com o setor de operações. Os desenvolvedores podem, assim, ver e corrigir vulnerabilidades e problemas de conformidade que eles podem de fato resolver.

Você pode criar um pipeline que examina e reprova builds por terem uma ou dez vulnerabilidades críticas. Uma abordagem melhor pode ser olhar para a próxima camada abaixo. Você pode começar a segmentar o ponto de responsabilidade com base no status do fornecedor.

Defina um limite na camada de status da vulnerabilidade. Qualquer coisa com um status de Aberto, Não será corrigido ou Adiado continua a fluir pelo pipeline onde o SecOps pode acessar o risco, como fazem hoje. Uma vulnerabilidade com o status de correções do fornecedor disponíveis é algo que um desenvolvedor pode resolver. O uso de períodos de carência dá tempo para os desenvolvedores corrigirem vulnerabilidades.

Junto com a avaliação de vulnerabilidade está a avaliação de conformidade. Por exemplo, permitir que uma imagem seja executada como raiz ou expor SSH quebra a postura de conformidade da maioria das empresas. Resolva esse problema durante a compilação em vez de durante a implantação.

Normalmente, você digitaliza suas imagens em relação ao benchmark do Docker CIS. Quando usa esses tipos de fluxos, você não interrompe o desenvolvimento introduzindo uma correção de segurança, mas pode aprimorar a postura de segurança geral da empresa em linha.

O uso de uma ferramenta que habilita esses recursos é essencial para implementar efetivamente a estratégia certa para a empresa. As ferramentas tradicionais muitas vezes não conseguem detectar vulnerabilidades dentro de contêineres, o que pode levar a uma falsa sensação de segurança. Ferramentas que levam em consideração a abordagem de construção baseada em pipeline e a natureza imutável e declarativa das tecnologias de contêiner são necessárias para proteger adequadamente seu ecossistema de contêiner.

Essas ferramentas devem ter as seguintes propriedades:

• Integração com toda a vida útil das imagens, desde o início do processo de compilação até o registro e o tempo de execução.
• Visibilidade das vulnerabilidades em todas as camadas da imagem, incluindo a camada de base da imagem, as estruturas do aplicativo e softwares personalizados.
• Aplicação orientada por políticas com o nível certo de granularidade, o que permite que sua organização crie portas de qualidade em cada estágio dos processos de compilação e implantação.

Segurança do registro

A segurança do registro tem como prioridade:

• Controle de deriva da construção.
• Prevenção de empurrar/puxar imagens contaminadas.
• Assinatura de imagem.

Principais riscos

As imagens geralmente contêm informações proprietárias, incluindo o código-fonte de uma organização. Se as conexões com registros não forem adequadamente seguras, o conteúdo de uma imagem pode representar riscos de confidencialidade tão graves quanto qualquer outra forma de dados transmitidos dentro de sua organização. Imagens obsoletas com versões vulneráveis e desatualizadas no Registro podem aumentar os riscos de segurança se forem implantadas acidentalmente.

Outra vulnerabilidade de segurança pode incluir restrições insuficientes de autenticação e autorização para registros de contêiner. Esses registros podem abrigar ativos proprietários confidenciais nas imagens.

À medida que o conteúdo é criado e implantado, a distribuição desse conteúdo é um dos muitos vetores de ataque. Como você garante que o conteúdo preparado para distribuição seja o mesmo conteúdo entregue a um ponto de extremidade pretendido?

Contramedidas de risco

Configure processos de implantação para garantir que as ferramentas de desenvolvimento, as redes e os tempos de execução de contêiner estejam conectados a registros somente por canais criptografados. Além disso, certifique-se de que o conteúdo vem de uma fonte confiável. Para reduzir os riscos do uso de imagens obsoletas:

• Remova imagens vulneráveis e inseguras que não devem mais ser usadas dos registros de contêiner.
• Impor o acesso a imagens usando nomes imutáveis que especificam versões específicas de imagens a serem usadas. Você pode implementar essa configuração usando uma marca mais recente ou uma versão específica das imagens. Uma marca não garante a atualização. Por esse motivo, coloque um processo em prática para garantir que o orquestrador do Kubernetes esteja usando os números exclusivos mais recentes ou que a tag mais recente represente as versões mais atualizadas.

O acesso a registros que contenham imagens confidenciais deve exigir autenticação e autorização. Todo o acesso de gravação também deve exigir autenticação. Por exemplo, sua política pode permitir que os desenvolvedores enviem imagens apenas para os repositórios específicos pelos quais são responsáveis.

O acesso a esses registros deve ser federado e aproveitar as políticas de acesso em nível de linha de negócios. Por exemplo, você pode configurar seu pipeline de CI/CD para enviar imagens por push para repositórios somente depois que elas passarem nos testes de verificação de vulnerabilidade, avaliação de conformidade e controle de qualidade.

Os registros de contêiner agora considerados registros de artefato estão se tornando um meio principal para implantar qualquer tipo de conteúdo, não apenas imagens de contêiner. Cada nuvem fornece um registro com projetos de código aberto e produtos de fornecedor que estão disponíveis para hospedagem local ou privada em provedores de nuvem. O conteúdo é promovido dentro e entre registros do build inicial até a implantação de produção.

Como você pode garantir a integridade do conteúdo que entrou no registro é o mesmo conteúdo que sai do registro? A adoção de uma solução de assinatura de imagem garante que as implantações sejam provenientes apenas de registros confiáveis e estejam implantando conteúdo confiável.

Segurança de cluster

A segurança do cluster tem como prioridade:

• Autenticação e autorização.
• Segurança de rede.
• Gerenciamento de vulnerabilidades e conformidade.

Principais riscos

Às vezes, um único cluster do Kubernetes pode ser usado para executar aplicativos diferentes gerenciados por equipes diferentes com requisitos de nível de acesso diferentes. Se o acesso for fornecido a indivíduos sem restrições ou apenas de acordo com as necessidades deles, um usuário mal intencionado ou desatento poderá comprometer as cargas de trabalho às quais tem acesso e outros ativos no cluster.

Outra vulnerabilidade de segurança pode ocorrer quando o próprio diretório de usuário do cluster gerencia a autorização e a autenticação. Um diretório de autenticação organizacional geralmente é controlado com mais rigor. Como essas contas são altamente privilegiadas e, mais frequentemente, órfãs, as chances de uma conta comprometida aumentam.

Esse cenário pode levar a vulnerabilidades de cluster ou até mesmo de todo o sistema. Os dados armazenados por volumes de contêiner são gerenciados por orquestradores, que devem ter acesso aos dados, independentemente do nó em que estão hospedados.

Os filtros de rede tradicionais podem ter uma cegueira de segurança devido a uma sobreposição de rede projetada para criptografar dados em trânsito. Esse design dificulta o monitoramento do tráfego dentro do cluster, portanto, podem ser necessárias disposições especiais para monitorar clusters do Kubernetes.

O tráfego de aplicativos diferentes que compartilham o mesmo cluster pode ter níveis de sensibilidade diferentes, como um site voltado para o público e um aplicativo interno executando processos de negócios confidenciais críticos. Compartilhar a mesma rede virtual dentro do cluster pode levar ao comprometimento de dados confidenciais. Por exemplo, um invasor pode usar a rede compartilhada exposta à Internet para atacar os aplicativos internos.

Proteja os componentes que executam o próprio cluster contra problemas de vulnerabilidades e de conformidade. Certifique-se de que você está executando a versão mais recente possível do Kubernetes para aproveitar a correção.

Contramedidas de risco

O acesso de usuário do cluster Kubernetes deve usar um modelo de acesso com privilégios mínimos. Conceda aos usuários acesso somente para executar ações específicas em hosts, contêineres e imagens específicos necessários para que eles façam seu trabalho. Membros da equipe de teste devem ter acesso limitado, ou nenhum acesso, aos contêineres de produção. As contas de usuário com acesso em todo o cluster devem ser rigorosamente controladas e usadas com moderação.

Use métodos de autenticação fortes, como autenticação multifator, para proteger o acesso a essas contas. Um diretório de usuário da organização deve ser usado para gerenciar clusters por meio de logon único, em vez de contas de usuário específicas do cluster que podem não ter o mesmo nível de políticas e controles.

Use métodos de criptografia que permitam que os contêineres acessem corretamente os dados, seja qual for o host em que os contêineres estejam sendo executados. Essas ferramentas de criptografia devem impedir o acesso não autorizado a dados por outros contêineres que não deveriam ter acesso a eles, mesmo estando no mesmo nó.

Configure clusters Kubernetes para separar o tráfego de rede em redes virtuais discretas ou sub-redes por nível de sensibilidade. A segmentação por aplicativo também pode ser possível, mas definir redes por níveis de sensibilidade pode ser suficiente. Por exemplo, redes virtuais para aplicativos voltados para o cliente separados daqueles que atendem aplicativos internos com tráfego confidencial devem ser implementadas, no mínimo.

Você pode usar manchas e tolerâncias para isolar implantações em conjuntos específicos de nós por níveis de sensibilidade. Evite hospedar cargas de trabalho altamente confidenciais no mesmo nó que as cargas de trabalho com sensibilidades mais baixas. O uso de clusters gerenciados separados é uma opção mais segura.

Segmente contêineres por finalidade, sensibilidade e postura de thread para fornecer proteção extra para cargas de trabalho confidenciais. Ao segmentar contêineres dessa maneira, é mais difícil para um invasor que obteve acesso a um segmento obter acesso a outros segmentos. Essa configuração tem a vantagem adicional de garantir que dados residuais, como caches ou montagens de volume, sejam isolados por nível de sensibilidade.

Os clusters do Kubernetes devem ser configurados para:

• Forneça um ambiente seguro para aplicativos que são executados neles.
• Verifique se os nós são adicionados com segurança ao cluster.
• Tenha identidades persistentes para ajudar a garantir a segurança durante todo o seu ciclo de vida.
• Fornecer informações dinâmicas e precisas sobre o estado do cluster, incluindo a rede e os nós dentro dele.

Deve ser fácil isolar e remover um nó comprometido do cluster sem afetar o desempenho dele. O AKS simplifica isso.

Defina padrões de configuração de tempo de execução de contêiner para garantir automaticamente a conformidade. Há muitas políticas no Azure que facilitam esse processo, e os usuários também podem criar suas próprias políticas. Use os recursos de segurança do Azure para avaliar continuamente as definições de configuração em todo o ambiente e impô-las ativamente.

Certifique-se automaticamente de que as vulnerabilidades dos componentes do Kubernetes estão sendo resolvidas. Use ambientes separados para desenvolvimento, teste e produção, cada um com seus próprios controles e controle de acesso baseado em função (RBAC) para gerenciamento de contêiner. Associe toda a criação de contêiner a identidades de usuário individuais e ela deve ser registrada para auditoria. Essa configuração ajuda a reduzir o risco de contêineres não autorizados.

Segurança do nó

A segurança do nó tem como prioridade:

• Proteção em tempo de execução.
• Gerenciamento de vulnerabilidades e conformidade.

Principais riscos

Um nó de trabalho tem acesso privilegiado a todos os componentes do nó. Os invasores podem usar qualquer serviço acessível pela rede como ponto de entrada, portanto, fornecer acesso ao host a partir de vários pontos pode aumentar seriamente sua superfície de ataque. Quanto maior a superfície de ataque, mais chances de um invasor obter acesso ao nó e seu sistema operacional.

Além disso, sistemas operacionais específicos de contêineres, como os que são usados em nós do AKS, têm uma superfície de ataque menor porque não contêm bibliotecas que permitem que sistemas operacionais regulares executem bancos de dados e servidores Web diretamente. O uso de um kernel compartilhado resulta em uma superfície de ataque maior para contêineres em execução no mesmo ambiente do que contêineres em máquinas virtuais separadas. Esse é o caso mesmo quando sistemas operacionais específicos de contêiner executados em nós AKS estão em uso.

Os sistemas operacionais do host fornecem componentes de sistema fundamentais que podem ter vulnerabilidades e riscos de conformidade. Como são componentes de baixo nível, suas vulnerabilidades e configuração podem afetar todos os contêineres hospedados. O AKS protege os usuários garantindo que essas vulnerabilidades sejam resolvidas por meio de atualizações regulares do sistema operacional em nós executados no AKS, e a postura de conformidade do nó de trabalho seja mantida.

Direitos de acesso de usuário inadequados também podem levar a riscos de segurança quando os usuários entram diretamente nos nós para gerenciar os contêineres, em vez de através do plano de controle AKS. A entrada direta pode permitir que o usuário faça alterações em aplicativos além daqueles a que ele deve ter acesso.

Além disso, contêineres mal-intencionados podem levar à adulteração do sistema de arquivos do SO host. Por exemplo, se um contêiner tiver permissão para montar um diretório confidencial no sistema operacional host, esse contêiner poderá fazer alterações nos arquivos. As alterações podem afetar a segurança de outros contêineres em execução no host.

Contramedidas de risco

Restrinja o acesso ao nó limitando o acesso SSH.

O uso do sistema operacional específico do contêiner em nós AKS normalmente reduz as superfícies de ataque porque outros serviços e funcionalidades estão desativados. Eles também têm sistemas de arquivos somente leitura e empregam outras práticas de proteção de cluster por padrão.

A plataforma do Azure aplica automaticamente patches de segurança do sistema operacional aos nós do Linux e do Windows todas as noites. Se uma atualização de segurança do sistema operacional Linux exigir uma reinicialização do host, essa reinicialização não será executada automaticamente. O AKS fornece mecanismos de reinicialização para aplicar esses patches específicos.

O Microsoft Defender for Servers não é aplicável aos nós AKS Linux e Windows porque a Microsoft gerencia seu sistema operacional. Se nenhuma outra máquina virtual estiver na assinatura em que o AKS está implantado, você poderá desabilitar com segurança o Microsoft Defender for Servers.

Se o ambiente tiver sido implantado, incluindo as políticas recomendadas do Azure para a zona de aterrissagem em escala empresarial, você poderá configurar uma exclusão para a atribuição de política no grupo de gerenciamento que habilita automaticamente o Microsoft Defender for Servers para evitar custos desnecessários.

Segurança de aplicativo

A segurança do aplicativo tem como prioridade:

• Proteção em tempo de execução.
• Gerenciamento de vulnerabilidades e conformidade.

Principais riscos

Imagens são arquivos que incluem todos os componentes necessários para executar um aplicativo. Quando as versões mais recentes desses componentes são usadas para criar imagens, elas podem estar livres de vulnerabilidades conhecidas no momento, mas podem mudar rapidamente.

Você deve manter esses arquivos atualizados com as versões mais recentes porque os desenvolvedores de pacotes identificam regularmente vulnerabilidades de segurança. Faça atualizações dos contêineres mais upstream atualizando as imagens usadas para criá-los, diferente dos aplicativos tradicionais, que normalmente são atualizados no host.

Arquivos maliciosos também podem ser incorporados em uma imagem, que pode ser usada para atacar outros contêineres ou componentes do sistema. Contêineres de terceiros podem ser um possível vetor de ataque. Detalhes específicos podem ser desconhecidos sobre eles e eles podem vazar dados. Talvez os contêineres não tenham sido mantidos atualizados com as atualizações de segurança necessárias.

Outro vetor de ataque é o uso de incorporar segredos como senhas e cadeias de conexão diretamente em um sistema de arquivos de imagem. Essa prática pode causar um risco de segurança, pois qualquer pessoa com acesso à imagem pode ter acesso aos segredos.

Pode haver falhas nos próprios aplicativos, como aplicativos que são vulneráveis a cross-site scripting ou injeção de SQL. Quando há falhas, a vulnerabilidade pode ser usada para habilitar o acesso não autorizado a informações confidenciais em outros contêineres ou até mesmo no sistema operacional do host.

O tempo de execução do contêiner AKS facilita o monitoramento de vulnerabilidades usando as várias ferramentas de segurança disponíveis no Azure. Para obter mais informações, consulte Introdução ao Microsoft Defender para Kubernetes.

Você também deve controlar o tráfego de rede de saída enviado para contêineres para garantir que os contêineres não sejam capazes de enviar tráfego entre redes de diferentes níveis de sensibilidade, como ambientes que hospedam dados seguros ou para a Internet. O Azure facilita esse controle com seus diversos recursos de segurança de rede e do AKS.

Por padrão, os agendadores do Kubernetes se concentram em controlar a escala e maximizar a densidade das cargas de trabalho em execução nos nós. Eles podem colocar pods de diferentes níveis de sensibilidade no mesmo nó apenas porque esse host tem a maioria dos recursos disponíveis. Esse cenário pode levar a incidentes de segurança quando invasores usam acesso a cargas de trabalho voltadas para o público para atacar contêineres que executam processos mais confidenciais no mesmo host. Um contêiner comprometido também pode ser usado para examinar a rede para encontrar outras vulnerabilidades que o invasor pode explorar.

Contramedidas de risco

Nunca armazene segredos no código do aplicativo nem em sistemas de arquivos. Segredos devem ser armazenados em repositórios de chaves e fornecidos aos contêineres em runtime conforme necessário. O AKS pode garantir que somente contêineres que precisam de acesso a determinadas chaves tenham acesso a elas e que esses segredos não sejam mantidos no disco. Por exemplo, o Azure Key Vault pode armazenar esses segredos com segurança e fornecê-los ao cluster do AKS conforme necessário. Também é simples garantir que os segredos sejam criptografados no armazenamento e em trânsito.

Evite o uso de imagens e registros não confiáveis e garanta que apenas imagens de conjuntos confiáveis tenham permissão para serem executadas em seus clusters. Para uma abordagem de várias camadas:

• Controlar centralmente exatamente quais imagens e registros são confiáveis.
• Identifique de modo discreto cada imagem por assinatura criptográfica.
• Estabelecer políticas para garantir que todos os hosts executem apenas imagens do conjunto aprovado.
• Validar as assinaturas antes da execução.
• Monitorar e atualizar essas imagens e registros à medida que as vulnerabilidades e os requisitos de configuração mudarem.

Os perfis de computação segura devem ser usados para restringir contêineres e ser alocados em tempo de execução. Perfis personalizados podem ser criados e transmitidos para os runtimes dos contêineres para limitar ainda mais seus recursos. No mínimo, certifique-se de que os contêineres sejam executados com os perfis padrão. Considere o uso de perfis personalizados e mais restritos para contêineres que executam aplicativos de alto risco.

As ferramentas podem criar perfis de aplicativos automaticamente usando aprendizado comportamental e detectar anomalias. Você pode usar soluções de terceiros para detectar anomalias em tempo de execução. As anomalias podem incluir eventos como:

• Execução de processo inválido ou inesperado ou chamadas do sistema.
• Alterações em arquivos de configuração protegidos e binários.
• Grava em locais e tipos de arquivo inesperados.
• Criação de ouvintes de rede inesperados.
• Tráfego enviado para destinos de rede inesperados.
• Armazenamento e execução de malware.

Atualmente, o Microsoft Defender para Kubernetes está investindo nesta área.

Os contêineres devem ser executados com seu sistema de arquivos raiz no modo somente leitura para isolar gravações em diretórios definidos, que essas ferramentas podem monitorar facilmente. Essa configuração torna os contêineres mais resistentes ao comprometimento porque você isola a adulteração nesses locais específicos. Eles podem ser facilmente separados do resto da aplicação.

Considerações sobre o design

O AKS tem várias interfaces para outros serviços do Azure, como o Microsoft Entra ID, o Armazenamento do Azure e a Rede Virtual do Azure. A utilização desses serviços requer atenção especial durante a fase de planejamento. O AKS também acrescenta mais complexidade ao exigir que você considere a aplicação dos mesmos mecanismos e controles de conformidade e governança aplicados no restante de seu cenário de infraestrutura.

Estas são algumas outras considerações de design com relação à conformidade e à governança de segurança no AKS:

• Se você criar um cluster AKS em uma assinatura implantada de acordo com as práticas recomendadas de zona de aterrissagem em escala empresarial, familiarize-se com as políticas do Azure que os clusters herdarão. Para obter mais informações, consulte Políticas incluídas em implementações de referência de zonas de aterrissagem do Azure.
• Decida se o plano de controle do cluster deve ser acessível pela Internet (recomendamos restrições de IP), que é o padrão, ou somente de dentro de sua rede privada no Azure ou local como um cluster privado. Se sua organização estiver seguindo as práticas recomendadas de zona de aterrissagem em escala empresarial, o Corp grupo de gerenciamento terá uma Política do Azure associada que força os clusters a serem privados. Para obter mais informações, consulte Políticas incluídas em implementações de referência de zonas de aterrissagem do Azure.
• Considere a possibilidade de usar o módulo de segurança interno AppArmor do Linux para limitar as ações que os contêineres podem executar, como leitura, gravação e execução, ou funções do sistema, como a montagem de sistemas de arquivos. Por exemplo, todas as assinaturas têm políticas do Azure que impedem que pods em todos os clusters AKS criem contêineres privilegiados. Para obter mais informações, consulte Políticas incluídas em implementações de referência de zonas de aterrissagem do Azure.
• Avalie usar seccomp (computação segura) no nível do processo para limitar as chamadas de processo que os contêineres podem executar. Por exemplo, a Azure Policy aplicada como parte da implementação da zona de destino de escala empresarial genérica no grupo de gerenciamento de zonas de destino para evitar a elevação de privilégio do contêiner para a raiz usa seccomp por meio das políticas do Azure para Kubernetes.
• Decida se o registro do contêiner está acessível pela Internet ou apenas em uma rede virtual específica. Desabilitar o acesso à Internet em um registro de contêiner pode ter efeitos negativos em outros sistemas que dependem da conectividade pública para acessá-lo. Exemplos incluem pipelines de integração contínua ou Microsoft Defender para varredura de imagens. Para obter mais informações, consulte Conectar-se de forma privada a um registro de contêiner usando o Link Privado do Azure.
• Decida se o registro de contêiner privado é compartilhado em várias zonas de aterrissagem ou se você implanta um registro de contêiner dedicado em cada assinatura de zona de pouso.
• Considere usar uma solução de segurança como o Microsoft Defender para Kubernetes para detecção de ameaças.
• Considere examinar suas imagens de contêiner para detectar vulnerabilidades.
• Considere desabilitar o Microsoft Defender for Servers na assinatura AKS se não houver máquinas virtuais não-AKS, para evitar custos desnecessários.

Recomendações sobre design

• Limite o acesso ao arquivo de configuração do cluster Kubernetes usando o RBAC do Azure.
• Proteja o acesso do pod aos recursos. Forneça o menor número de permissões e evite o uso da raiz ou da elevação de privilégio.
• Use a ID de Carga de Trabalho do Entra com AKS e o provedor do Cofre de Chaves do Azure para o Driver CSI do Armazenamento de Segredos para proteger segredos, certificados e cadeias de conexão.
• Use a atualização de imagem de nó AKS para atualizar imagens de nó de cluster AKS, se possível, ou kured para automatizar reinicializações de nó depois de aplicar atualizações.
• Monitore e imponha a configuração usando o complemento do Azure Policy para Kubernetes. Em assinaturas implantadas de acordo com as práticas recomendadas de zonas de aterrissagem em escala empresarial, essa configuração acontece automaticamente por meio de uma Política do Azure implantada no nível do grupo de gerenciamento.
• Veja as recomendações para o AKS em Microsoft Defender para Nuvem.
• Use o Microsoft Defender for Containers, a solução nativa da nuvem para melhorar, monitorar e manter a segurança de seus clusters, contêineres e seus aplicativos.
• Implante uma instância dedicada e privada do Registro de Contêiner do Azure para cada assinatura de zona de destino.
• Use Private Link for Container Registry para conectá-lo ao AKS.
• Analise as suas imagens em busca de vulnerabilidades com o Microsoft Defender Vulnerability Management ou qualquer outra solução de análise de imagens.

Importante

A varredura de imagens do Microsoft Defender for Cloud não é compatível com os pontos de extremidade do Registro de Contêiner. Para obter mais informações, consulte Conectar-se de forma privada a um registro de contêiner usando o Link Privado.