Arquitetura do Microsoft Defender para Contêineres
O Defender para Contêineres foi projetado de forma diferente para cada ambiente de Kubernetes, independentemente de ser executado em:
AKS (Serviço de Kubernetes do Azure) - serviço gerenciado da Microsoft para desenvolvimento, implantação e gerenciamento de aplicativos conteinerizados.
Amazon Elastic Kubernetes Service (EKS) em uma conta conectada do Amazon Web Services (AWS) - serviço gerenciado do Amazon para execução de Kubernetes no AWS sem precisar instalar, operar e manter um painel de controle ou nós de Kubernetes.
GKE (Google Kubernetes Engine) em um projeto GCP (Google Cloud Platform) conectado – o ambiente gerenciado do Google para implantar, gerenciar e dimensionar aplicativos usando a infraestrutura GCP.
Uma distribuição não gerenciada de Kubernetes (usando Kubernetes habilitados para Azure Arc) - clusters de Kubernetes certificados pela Cloud Native Computing Foundation (CNCF) hospedados no local ou na IaaS.
Observação
O suporte do Defender para Contêineres para clusters de Kubernetes habilitados para Arc (EKS do AWS e GKE de GCP) é uma versão prévia do recurso.
Para proteger os contêineres do Kubernetes, o Defender para Contêineres recebe e analisa:
- Logs de auditoria e eventos de segurança do servidor de API
- Informações de configuração de cluster do plano de controle
- Configuração da carga de trabalho Azure Policy
- Sinais de segurança e eventos do nível do nó
Para saber mais sobre os sistemas operacionais compatíveis, disponibilidade de recursos, proxy de saída e muito mais, confira Disponibilidade de recursos do Microsoft Defender para Contêineres.
Arquitetura para cada ambiente de Kubernetes
Diagrama de arquitetura dos clusters do Defender para Nuvem e do AKS
Quando o Defender para Nuvem protege um cluster hospedado no Serviço de Kubernetes do Azure, a coleta de dados de log de auditoria é sem agente e coletada automaticamente por meio da infraestrutura do Azure sem considerações adicionais de custo ou configuração. Estes são os componentes necessários para receber a proteção completa oferecida pelo Microsoft Defender para contêineres:
- Sensor do Defender: o DaemonSet implantado em cada nó coleta sinais de hosts usando a tecnologia eBPF e fornece proteção de runtime. O sensor é registrado em um workspace do Log Analytics e é usado como um pipeline de dados. No entanto, os dados de log de auditoria não são armazenados no workspace do Log Analytics. O sensor do Defender é implantado como um perfil de Segurança do AKS.
- Azure Policy para Kubernetes: um pod que estende o Gatekeeper v3 de software livre e se registra como um webhook para o controle de admissão do Kubernetes, possibilitando a aplicação de imposição em escala e proteções em seus clusters de maneira centralizada e consistente. O Azure Policy para o pod do Kubernetes é implantado como um complemento do AKS. Só está instalado em um nó no cluster. Para obter mais informações, confira Proteger suas cargas de trabalho do Kubernetes e Entender o Azure Policy para clusters do Kubernetes.
Detalhes do componente de sensor do Defender
Nome do pod | Namespace | Kind | Descrição breve | Funcionalidades | Limites de recursos | Saída necessária |
---|---|---|---|---|---|---|
microsoft-defender-collector-ds-* | kube-system | DaemonSet | Um conjunto de contêineres concentrado na coleta de eventos de inventário e de segurança no ambiente do Kubernetes. | SYS_ADMIN, SYS_RESOURCE, SYS_PTRACE |
memória: 296 Mi cpu: 360m |
Não |
microsoft-defender-collector-misc-* | kube-system | Implantação | Um conjunto de contêineres concentrado na coleta de eventos de inventário e de segurança no ambiente do Kubernetes que não estão limitados a um nó específico. | N/D | memória: 64Mi cpu: 60m |
Não |
microsoft-defender-publisher-ds-* | kube-system | DaemonSet | Publique os dados coletados no serviço de back-end do Microsoft Defender para Contêineres no qual os dados serão processados e analisados. | N/D | memória: 200Mi cpu: 60m |
Https 443 Saiba mais sobre os pré-requisitos de acesso de saída |
* Os limites de recursos não são configuráveis. Saiba mais sobre Limites de recursos do Kubernetes.
Como funciona a descoberta sem agente para Kubernetes no Azure?
O processo de descoberta se baseia em instantâneos feitos em intervalos:
Quando você habilita a extensão descoberta sem agente para o Kubernetes, ocorre o seguinte processo:
Criar:
- Se a extensão estiver habilitada no Defender CSPM, o Defender para Nuvem criará uma identidade nos ambientes do cliente chamada
CloudPosture/securityOperator/DefenderCSPMSecurityOperator
. - Se a extensão estiver habilitada no Defender para Contêineres, o Defender para Nuvem criará uma identidade nos ambientes do cliente chamada
CloudPosture/securityOperator/DefenderForContainersSecurityOperator
.
- Se a extensão estiver habilitada no Defender CSPM, o Defender para Nuvem criará uma identidade nos ambientes do cliente chamada
Atribuir: o Defender para Nuvem atribui uma função interna chamada Operador Sem Agente do Kubernetes a essa identidade no escopo da assinatura. A função contém as seguintes permissões:
- AKS read (Microsoft.ContainerService/managedClusters/read)
- Acesso Confiável do AKS com as seguintes permissões:
- Microsoft.ContainerService/managedClusters/trustedAccessRoleBindings/write
- Microsoft.ContainerService/managedClusters/trustedAccessRoleBindings/read
- Microsoft.ContainerService/managedClusters/trustedAccessRoleBindings/delete
Saiba mais sobre o Acesso Confiável do AKS.
Descobrir: por meio da identidade atribuída pelo sistema, o Defender para Nuvem executa uma descoberta dos clusters do AKS em seu ambiente usando chamadas à API para o servidor de API do AKS.
Vinculação: após a descoberta de um cluster do AKS, o Defender para Nuvem executa uma operação de vinculação ao AKS criando uma
ClusterRoleBinding
entre a identidade criada e aClusterRole
aks:trustedaccessrole:defender-containers:microsoft-defender-operator do Kubernetes. AClusterRole
é visível por meio da API e concede ao Defender para Nuvem uma permissão de leitura do plano de dados dentro do cluster.
Observação
O instantâneo copiado permanece na mesma região que o cluster.
Próximas etapas
Nesta visão geral, você aprendeu sobre a arquitetura da segurança de contêineres no Microsoft Defender para Nuvem. Para habilitar o plano, consulte:
Comentários
https://aka.ms/ContentUserFeedback.
Em breve: Ao longo de 2024, eliminaremos os problemas do GitHub como o mecanismo de comentários para conteúdo e o substituiremos por um novo sistema de comentários. Para obter mais informações, consulteEnviar e exibir comentários de