Arquitetura do Microsoft Defender para Contêineres

Concluído

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.

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ó

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:

• Agente do Defender: O DaemonSet, que é implantado em cada nó, coleta sinais de hosts usando a *tecnologia eBPF (Extended Berkeley Packet Filter)* e fornece proteção de runtime. O agente é 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 agente do Defender é implantado como um agente de Segurança do AKS.

  • *Informações e conceitos do eBPF: O eBPF (Extended Berkeley Packet Filter) é uma estrutura poderosa e versátil no kernel do Linux para analisar programaticamente e filtrar pacotes de rede, além de executar várias outras tarefas no nível do sistema. Originalmente baseado no BPF (Berkeley Packet Filter) que foi introduzido na anos 1990, o eBPF expande suas funcionalidades permitindo que programas definidos pelo usuário sejam executados no kernel, permitindo o processamento dinâmico e eficiente de pacotes sem a necessidade de modificações no próprio kernel.
  • Os programas eBPF são escritos em um subconjunto restrito de C e são carregados no kernel, onde são executados em um ambiente seguro e em área restrita. Isso permite que uma ampla gama de tarefas relacionadas à rede sejam executadas diretamente no kernel, como filtragem de pacotes, monitoramento de tráfego, imposição de segurança e até mesmo análise de protocolo personalizada.
  • Uma das principais vantagens do eBPF é sua versatilidade e desempenho. Ao executar dentro do kernel, os programas eBPF podem acessar e manipular pacotes de rede diretamente, reduzindo a sobrecarga significativamente em comparação com métodos tradicionais de processamento de pacotes do espaço do usuário. Além disso, os programas eBPF podem ser carregados dinamicamente e anexados a vários ganchos dentro do kernel, permitindo capacidade de resposta em tempo real e adaptabilidade para as condições de rede em alteração.
  • O eBPF tornou-se cada vez mais popular em aplicativos modernos de sistema de rede e segurança devido à sua flexibilidade e eficiência. Ele é amplamente usado em ferramentas e estruturas para monitoramento de rede, detecção de intrusão, análise de tráfego e ajuste de desempenho. Além disso, seus recursos vão além do sistema de rede para outras áreas de observabilidade e controle do sistema, tornando-o um bloco de construção fundamental para uma ampla gama de aplicativos e serviços baseados em Linux.

• 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. Ele só é instalado em um nó no cluster.

Detalhes do componente do agente 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

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 descoberta sem agente para a extensão do Kubernetes, ocorre o seguinte processo:

• Criar:

  • Se a extensão for ativada a partir do Defender CSPM, o Defender para Nuvem criará uma identidade nos ambientes do cliente chamada CloudPosture/securityOperator/DefenderCSPMSecurityOperator.
    
  • Se a extensão for ativada no Defender para Contêineres, o Defender para Nuvem criará uma identidade nos ambientes do cliente chamada CloudPosture/securityOperator/DefenderForContainersSecurityOperator.
  • Atribuir: o Defender para Nuvem atribui uma função interna chamada operador do Kubernetes sem agente a essa identidade no escopo da assinatura. A função contém as seguintes permissões:
  • Leitura do AKS (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

• 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.

• Associar: Após a descoberta de um cluster do AKS, o Defender para Nuvem executa uma operação de associação do AKS criando um ClusterRoleBinding entre a identidade criada e o ClusterRole do Kubernetes aks:trustedaccessrole:defender-containers:microsoft-defender-operator. O ClusterRole é visível por meio da API e dá ao Defender para Nuvem permissão de leitura do plano de dados dentro do cluster.

Obtenha acesso seguro aos recursos do Azure no Serviço de Kubernetes do Azure usando o acesso confiável (visualização)

Muitos serviços do Azure que se integram com o Serviço de Kubernetes do Azure (AKS) precisam de acesso ao servidor de API do Kubernetes. Para evitar conceder acesso a esses serviços de administrador ou tornar seus clusters do AKS públicos para acesso à rede, você pode usar o recurso Acesso Confiável do AKS.

Este recurso fornece aos serviços acesso seguro ao AKS e ao Kubernetes usando o back-end do Azure sem exigir um ponto de extremidade privado. Em vez de depender de identidades que têm permissões do Microsoft Entra, esse recurso pode usar sua identidade gerenciada atribuída pelo sistema para autenticar com os serviços e aplicativos gerenciados que você deseja usar com seus clusters do AKS.

Importante

As versões prévias do recurso AKS estão disponíveis em uma base de autoatendimento e aceitação. As visualizações são fornecidas "como estão" e "conforme disponíveis" e estão excluídas dos acordos de nível de serviço e da garantia limitada. As versões prévias do AKS são parcialmente cobertas pelo suporte ao cliente em uma base de melhor esforço.

Observação

A API de Acesso Confiável está disponível para o público geral. Fornecemos suporte a GA (disponibilidade geral) para a CLI do Azure, mas ela ainda está em versão prévia e requer o uso da extensão aks-preview.

Visão geral do recurso de acesso confiável

O Acesso Confiável aborda os seguintes cenários:

• Se um intervalo de IP autorizado estiver definido ou em um cluster privado, os serviços do Azure talvez não consigam acessar o servidor de API do Kubernetes, a menos que você implemente um modelo de acesso de ponto de extremidade privado.
• Dar a um administrador de serviços do Azure acesso à API do Kubernetes não segue a melhor prática de acesso a privilégios mínimos e pode levar a escalonamentos de privilégios ou risco de vazamento de credenciais. Por exemplo, talvez seja necessário implementar permissões de serviço a serviço com privilégios altos e elas não são ideais em uma revisão de auditoria.

Você pode usar o Acesso Confiável para dar consentimento explícito à sua identidade gerenciada atribuída pelo sistema de recursos permitidos para acessar seus clusters do AKS usando um recurso do Azure chamado associação de função. Os recursos do Azure acessam os clusters do AKS por meio do gateway regional do AKS via autenticação de identidade gerenciada atribuída pelo sistema. As permissões apropriadas do Kubernetes são atribuídas por meio de um recurso do Azure chamado função. Por meio do Acesso Confiável, você pode acessar clusters do AKS com configurações diferentes, incluindo, entre outros, clusters privados, clusters que têm contas locais desativadas, clusters do Microsoft Entrae clusters de intervalo de IP autorizados.

Pré-requisitos

• Uma conta do Azure com uma assinatura ativa. Crie uma conta gratuitamente.

• Tipos de recurso que suportam a identidade gerenciada atribuída pelo sistema.

  • Se você estiver usando a CLI do Azure, a extensão aks-preview versão 0.5.74 ou posterior será exigida.

• Para saber quais funções usar em diferentes cenários, consulte estes artigos:

  • Acesso do Azure Machine Learning a clusters AKS com configurações especiais
  • What is Azure Kubernetes Service backup?
  • Ativar uma postura de contêiner sem agente

Diagrama de arquitetura dos clusters do Kubernetes habilitados para Defender para Nuvem e Arc

Esses componentes são necessários para receber a proteção completa oferecida pelo Microsoft Defender para Contêineres:

• Kubernetes habilitado para Azure Arc — Kubernetes habilitado para Azure Arc — Uma solução baseada em agente, instalada em um nó no cluster, que conecta seus clusters ao Defender para Nuvem. Em seguida, o Defender para Nuvem pode implantar os dois agentes a seguir como extensões do Arc:
• Agente do Defender: O DaemonSet, que é implantado em cada nó, coleta sinais de host usando a tecnologia eBPF e logs de auditoria do Kubernetes para fornecer proteção de runtime. O agente é 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 agente do Defender é implantado como uma extensão do Kubernetes habilitada para Arc.
• Azure Policy para Kubernetes: Um pod que estende o Gatekeeper v3 de software livre e se registra como um web hook 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 pod do Kubernetes é implantado como uma extensão do Kubernetes habilitada para Arc. 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.
  

Diagrama de arquitetura dos clusters do Defender para Nuvem e do EKS

Quando o Defender para Nuvem protege um cluster hospedado no Serviço de Kubernetes Elástico, a coleção de dados de log de auditoria é sem agente. Estes são os componentes necessários para receber a proteção completa oferecida pelo Microsoft Defender para contêineres:

• Logs de auditoria do Kubernetes - O CloudWatch da conta AWS ativa e coleta dados de log de auditoria por meio de um coletor sem agente e envia as informações coletadas para o back-end do Microsoft Defender para Nuvem para análise posterior.
• Kubernetes habilitado para Azure Arc — Kubernetes habilitado para Azure Arc — Uma solução baseada em agente, instalada em um nó no cluster, que conecta seus clusters ao Defender para Nuvem. Em seguida, o Defender para Nuvem pode implantar os dois agentes a seguir como extensões do Arc:
• Defender agent: o DaemonSet implantado em cada nó, que coleta sinais de hosts usando a tecnologia eBPF e fornece proteção em tempo de execução. O agente é 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 agente do Defender é implantado como uma extensão do Kubernetes habilitada para Arc.
• Azure Policy para Kubernetes: Um pod que estende o Gatekeeper v3 de software livre e se registra como um web hook 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 pod do Kubernetes é implantado como uma extensão do Kubernetes habilitada para Arc. Só está instalado em um nó no cluster.

Como funciona a descoberta sem agente para Kubernetes na AWS?

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:

  • A função do Defender para Nuvem MDCContainersAgentlessDiscoveryK8sRole deve ser adicionada ao ConfigMap aws-auth dos clusters EKS. O nome pode ser personalizado.
    

• Atribuir: o Defender para Nuvem atribui à função MDCContainersAgentlessDiscoveryK8sRole as seguintes permissões:

  • eks:UpdateClusterConfig
    
  • eks:DescribeCluster

• Descobrir: por meio da identidade atribuída pelo sistema, o Defender para Nuvem executa uma descoberta dos clusters do EKS em seu ambiente usando chamadas à API para o servidor de API do EKS.

Diagrama de arquitetura dos clusters do Defender para Nuvem e do GKE

Quando o Defender para Nuvem protege um cluster hospedado no Mecanismo de Kubernetes do Google, a coleção de dados de log de auditoria é sem agente. Estes são os componentes necessários para receber a proteção completa oferecida pelo Microsoft Defender para contêineres:

• Logs de auditoria do Kubernetes - O GCP Cloud Logging habilita e coleta dados de log de auditoria por meio de um coletor sem agente e envia as informações coletadas para o back-end do Microsoft Defender para Nuvem para análise posterior.
• Kubernetes habilitado para Azure Arc — Kubernetes habilitado para Azure Arc — Uma solução baseada em agente, instalada em um nó no cluster, que conecta seus clusters ao Defender para Nuvem. Em seguida, o Defender para Nuvem pode implantar os dois agentes a seguir como extensões do Arc:
• Defender agent: o DaemonSet implantado em cada nó, que coleta sinais de hosts usando a tecnologia eBPF e fornece proteção em tempo de execução. O agente é 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 agente do Defender é implantado como uma extensão do Kubernetes habilitada para Arc.
• Azure Policy para Kubernetes: Um pod que estende o Gatekeeper v3 de software livre e se registra como um web hook 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 pod do Kubernetes é implantado como uma extensão do Kubernetes habilitada para Arc. Só precisa ser instalado em um nó no cluster.

Como funciona a descoberta sem agente para Kubernetes no GCP?

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:

  • A conta de serviço mdc-containers-k8s-operator é criada. O nome pode ser personalizado.

• Atribuir: o Defender para Nuvem anexa as seguintes funções à conta de serviço mdc-containers-k8s-operator:

  • A função personalizada MDCGkeClusterWriteRole, que tem a permissão container.clusters.update
  • A função interna container.viewer

• Descobrir: por meio da identidade atribuída pelo sistema, o Defender para Nuvem executa uma descoberta dos clusters do GKE em seu ambiente usando chamadas à API para o servidor de API do GKE.