Segurança para AKS

Este artigo orienta você pelos aspetos da governança de segurança do Serviço 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 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 Kubernetes:

• Compilar
• Registo
• Cluster
• Nó
• Aplicação

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

Construa segurança

A segurança de compilação é sobre o uso adequado de DevSecOps com imagens de contêiner.

Principais riscos

Uma má configuração de imagem 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 eles precisam. Os contêineres também podem ser configurados para permitir determinado 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 tenha 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 abrir um ponto de entrada para invasores.

O uso de 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 compilação é sobre a implementação de DevSecOps para deslocar a segurança para a esquerda e corrigir a maioria dos problemas antes que eles comecem a se mover para o pipeline. Não se trata de colocar toda a propriedade nos desenvolvedores, mas de compartilhar a propriedade com as operações. Os desenvolvedores podem então ver e corrigir vulnerabilidades e problemas de conformidade que eles podem realmente resolver.

Você pode criar um pipeline que verifica e falha compilações porque ele tem uma ou 10 vulnerabilidades críticas. Uma abordagem melhor pode ser olhar para a próxima camada para baixo. 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 corrigirá, 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 de fornecedor disponíveis é algo que um desenvolvedor pode resolver. O uso de períodos de carência dá tempo para os desenvolvedores corrigirem vulnerabilidades.

Juntamente com a avaliação de vulnerabilidade está a avaliação de conformidade. Por exemplo, permitir que uma imagem seja executada como root 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ê verifica suas imagens em relação ao benchmark CIS do Docker. Ao usar esses tipos de fluxos, você não interromperá o desenvolvimento introduzindo a correção de segurança, mas poderá melhorar a postura de segurança da sua empresa em linha geral.

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

Essas ferramentas devem ter as seguintes propriedades:

• Integração com todo o tempo de vida das imagens, desde o início do processo de compilação até o registro e o tempo de execução.
• Visibilidade de vulnerabilidades em todas as camadas da imagem, incluindo a camada base da imagem, estruturas de aplicativos e software personalizado.
• 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 registo

A segurança do registo é sobre:

• Controle de deriva desde a 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 da sua organização. Imagens obsoletas com versões vulneráveis 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, redes e 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 decorrentes da utilização de imagens obsoletas:

• Remova imagens inseguras e vulneráveis que não devem mais ser usadas dos registros de contêiner.
• Imponha 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 tag mais recente ou uma versão específica das imagens. Uma etiqueta não garante frescura. 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 registos que contenham imagens sensíveis 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 no nível da linha de negócios. Por exemplo, você pode configurar seu pipeline de CI/CD para enviar imagens 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 artefatos, 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 fornecedores que estão disponíveis para hospedagem local ou privada em provedores de nuvem. O conteúdo é promovido dentro e entre registros, desde a compilação inicial até a implantação de produção.

Como você pode garantir que 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 do cluster

A segurança do cluster tem a ver com:

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

Principais riscos

Às vezes, um único cluster Kubernetes pode ser usado para executar diferentes aplicativos 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 suas necessidades, um usuário mal-intencionado ou descuidado pode 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ários 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 em cluster ou até mesmo em 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 estejam 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, disposições especiais podem ser necessárias para monitorar clusters do Kubernetes.

O tráfego de diferentes aplicativos que compartilham o mesmo cluster pode ter diferentes níveis de sensibilidade, 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 a dados confidenciais comprometidos. 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 vulnerabilidades e problemas de conformidade. Certifique-se de que você está executando na 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 de privilégios mínimos. Conceda apenas aos usuários acesso para executar ações específicas em hosts, contêineres e imagens específicos que são necessários para que eles realizem seus trabalhos. Os membros da equipe de teste devem ter acesso limitado ou nenhum acesso aos contêineres em 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 forte, como a 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 do logon único, em oposição às 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 adequadamente os dados, independentemente do 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, mesmo dentro do mesmo nó que não deveria ter acesso a eles.

Configure clusters Kubernetes para separar o tráfego de rede em redes virtuais ou sub-redes discretas 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 separadas daquelas 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 dentro do mesmo nó que as cargas de trabalho com sensibilidades mais baixas. Usar clusters gerenciados separados é uma opção mais segura.

Segmente os contêineres por finalidade, sensibilidade e postura de rosca para fornecer proteção extra para cargas de trabalho sensíveis. Ao segmentar contêineres dessa forma, é 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 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.
• Ter identidades persistentes para ajudar a garantir a segurança durante todo o seu ciclo de vida.
• Forneça informações precisas e em tempo real sobre o estado do cluster, incluindo a rede e os nós dentro dele.

Deve ser fácil para um nó comprometido ser isolado e removido do cluster sem afetar o desempenho do cluster. A AKS simplifica isso.

Defina padrões de configuração de tempo de execução do 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 aplicá-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 RBAC (controle de acesso baseado em função) para gerenciamento de contêineres. Associe toda a criação de contêiner a identidades de usuário individuais e ela deve ser registrada para auditoria. Esta configuração ajuda a reduzir o risco de contentores não autorizados.

Segurança do nó

A segurança do nó é sobre:

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

Principais riscos

Um nó de trabalho tem acesso privilegiado a todos os componentes no nó. Os atacantes 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 ao seu sistema operacional.

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

Os sistemas operacionais host fornecem componentes fundamentais do sistema que podem ter vulnerabilidades e risco de conformidade. Como são componentes de baixo nível, suas vulnerabilidades e configuração podem afetar todos os contêineres que estão sendo hospedados. O AKS protege os usuários garantindo que essas vulnerabilidades sejam atendidas por meio de atualizações regulares do sistema operacional nos nós em execução 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. Entrar diretamente pode permitir que o usuário faça alterações em aplicativos além daqueles aos quais deveria ter acesso.

Além disso, contêineres mal-intencionados podem levar à adulteração do sistema de arquivos do sistema operacional 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 Azure aplica automaticamente patches de segurança do SO a nós Linux e Windows todas as noites. Se uma atualização de segurança do sistema operacional Linux exigir uma reinicialização do host, ela não será reinicializada automaticamente. O AKS fornece mecanismos de reinicialização para aplicar esses patches específicos.

O Microsoft Defender for Servers não é aplicável para nós AKS Linux e Windows porque a Microsoft gerencia seu sistema operacional. Se nenhuma outra máquina virtual estiver na assinatura onde 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 aplicações

A segurança do aplicativo é sobre:

• Proteção em tempo de execução.
• Gestão 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, pois os desenvolvedores de pacotes identificam regularmente vulnerabilidades de segurança. Faça atualizações de contêiner ainda mais upstream atualizando as imagens usadas para criar os contêineres, ao contrário 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 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. Esta prática pode causar um risco de segurança porque qualquer pessoa com acesso à imagem pode ter acesso aos segredos.

Pode haver falhas nos próprios aplicativos, como aplicativos vulneráveis a scripts entre sites ou injeção de SQL. Quando existem falhas, a vulnerabilidade pode ser usada para permitir o acesso não autorizado a informações confidenciais em outros contêineres ou até mesmo no sistema operacional 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 vários recursos de segurança de rede e AKS.

Por padrão, os agendadores do Kubernetes se concentram em aumentar a escala e maximizar a densidade de cargas de trabalho executadas em 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 potencialmente levar a incidentes de segurança quando os invasores usam o 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 verificar a rede para encontrar outras vulnerabilidades que o invasor pode explorar.

Contramedidas de risco

Nunca armazene segredos no código do aplicativo ou em sistemas de arquivos. Os segredos devem ser armazenados em armazenamentos de chaves e fornecidos aos contêineres em tempo de execução, conforme necessário. O AKS pode garantir que apenas contêineres que precisam de acesso a determinadas chaves tenham acesso a eles e que esses segredos não persistam no disco. Por exemplo, o Azure Key Vault pode armazenar esses segredos com segurança e fornecê-los ao cluster AKS conforme necessário. Também é simples garantir que esses segredos sejam criptografados tanto no armazenamento quanto em trânsito.

Evite o uso de imagens e registros não confiáveis e garanta que apenas imagens de conjuntos confiáveis possam ser executadas em seus clusters. Para uma abordagem multicamadas:

• Controle centralmente exatamente quais imagens e registros são confiáveis.
• Identifique discretamente cada imagem por assinatura criptográfica.
• Coloque políticas em vigor que garantam que todos os hosts executem apenas imagens que sejam do conjunto aprovado.
• Valide essas assinaturas antes da execução.
• Monitore e atualize essas imagens e registros à medida que vulnerabilidades e requisitos de configuração mudam.

Perfis de computação seguros devem ser usados para restringir contêineres e ser alocados em tempo de execução. Perfis personalizados podem ser criados e passados para tempos de execução de contêiner 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 automáticos de aplicativos usando a aprendizagem comportamental e detetar anomalias. Você pode usar soluções de terceiros para detetar anomalias em tempo de execução. As anomalias podem incluir eventos como:

• Execução de processos ou chamadas de sistema inválidas ou inesperadas.
• 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.

O Microsoft Defender for Kubernetes está atualmente investindo nessa á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 violação nesses locais específicos. Eles podem ser facilmente separados do resto da aplicação.

Considerações de 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 destes serviços requer uma atenção especial durante a fase de planeamento. O AKS também adiciona complexidade extra que exige que você considere a aplicação dos mesmos mecanismos e controles de segurança, governança e conformidade que no resto do seu cenário de infraestrutura.

Aqui estão algumas outras considerações de design para governança e conformidade de segurança do 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 apenas 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 grupo de gerenciamento terá uma Política do Azure associada que força os Corp 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.
• Avalie o uso do módulo de segurança AppArmor Linux integrado para limitar as ações que os contêineres podem executar, como ler, gravar, executar ou funções do sistema, como montar 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 o uso seccomp (computação segura) no nível do processo para limitar as chamadas de processo que os contêineres podem executar. Por exemplo, a Política do Azure foi aplicada como parte da implementação genérica da zona de aterrissagem em escala empresarial no grupo de gerenciamento de zonas de aterrissagem para impedir o escalonamento de privilégios de contêiner para usos seccomp raiz por meio de políticas do Azure para Kubernetes.
• Decida se o seu registo de contentores está acessível através da Internet ou apenas numa rede virtual específica. A desativação do acesso à Internet em um registro de contêiner pode ter efeitos negativos em outros sistemas que dependem da conectividade pública para acessá-lo. Os exemplos incluem pipelines de integração contínua ou o Microsoft Defender para digitalização de imagens. Para obter mais informações, consulte Conectar-se de forma privada a um registro de contêiner usando o Azure Private Link.
• Decida se seu registro de contêiner privado é compartilhado em várias zonas de destino ou se você implanta um registro de contêiner dedicado para cada assinatura de zona de destino.
• Considere o uso de uma solução de segurança como o Microsoft Defender for Kubernetes para deteção de ameaças.
• Considere a verificação de suas imagens de contêiner em busca de vulnerabilidades.
• Considere desativar o Microsoft Defender for Servers na assinatura do AKS se não houver máquinas virtuais não-AKS, para evitar custos desnecessários.

Recomendações de design

• Limite o acesso ao arquivo de configuração de cluster do Kubernetes usando o Azure RBAC.
• Acesso seguro do pod aos recursos. Forneça o menor número de permissões e evite o uso de escalonamento raiz ou privilegiado.
• Use a ID de Carga de Trabalho do Entra com o AKS e o provedor do Cofre de Chaves do Azure para o Driver CSI do Repositório de Segredos para proteger segredos, certificados e cadeias de conexão.
• Use a atualização de imagem do nó AKS para atualizar as imagens do nó do cluster AKS, se possível, ou kured para automatizar as reinicializações do nó depois de aplicar as atualizações.
• Monitore e imponha a configuração usando o complemento de Política do Azure 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 do AKS no Microsoft Defender for Cloud.
• 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 em cada assinatura de zona de aterrissagem.
• Use o Private Link for Container Registry para conectá-lo ao AKS.
• Analise suas imagens em busca de vulnerabilidades com o Gerenciamento de Vulnerabilidades do Microsoft Defender ou qualquer outra solução de verificação de imagens.

Importante

A verificação de imagens do Microsoft Defender for Cloud não é compatível com 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 Link privado.