Arquitetura do Defender for Containers

O Microsoft Defender for Containers utiliza múltiplos caminhos de conectividade para recolher sinais de segurança e fornecer proteção entre registos de contentores e ambientes Kubernetes. A conectividade necessária depende das funcionalidades ativadas e do ambiente onde os seus contentores funcionam.

Os detalhes de implementação variam entre Azure Kubernetes Service (AKS), Amazon Elastic Kubernetes Service (EKS), Google Kubernetes Engine (GKE) e clusters Kubernetes habilitados por Arc.

Saiba mais sobre requisitos de rede, permissões e configurações suportadas na referência de acesso à rede e permissões para o Defender for Containers.

Visão geral do modelo de capacidades

A tabela seguinte mostra como as principais capacidades do Defender for Containers são implementadas e se requerem componentes dentro do cluster:

Capability Sem agente Requer componentes dentro do cluster
Avaliação da vulnerabilidade da imagem Yes No
Avaliação da postura de Kubernetes Yes No
Deteção de ameaças em tempo de execução No Yes
Deteção de ameaças no plano de controlo Yes No

Ligação a registos de contentores

A avaliação da vulnerabilidade das imagens é ativada quando as imagens são enviadas para registos suportados e periodicamente com base na configuração do registo. O Defender para a Cloud analisa os metadados das imagens e as camadas necessárias para a avaliação de vulnerabilidades. Em cenários suportados, os resultados da avaliação de vulnerabilidades podem ser publicados de volta ao registo sem modificar a imagem original do contentor. Estas capacidades não exigem que quaisquer componentes sejam implementados nos seus clusters Kubernetes.

Ligação aos clusters Kubernetes

O Microsoft Defender para a Cloud liga-se ao endpoint da API Kubernetes para descobrir clusters, recolher dados de configuração e realizar análises de postura e risco. Dependendo das funcionalidades ativadas e do ambiente, esta conectividade pode exigir acesso de leitura aos metadados do cluster e, em alguns cenários, operações limitadas de escrita para configurar as ligações ou extensões de acesso necessárias.

Dados de execução enviados a partir de clusters do Kubernetes

Os clusters do Kubernetes enviam dados de segurança em tempo de execução dos nós de trabalho para a infraestrutura de back-end do Microsoft Defender para a Cloud. Estes dados são recolhidos pelos componentes do Defender for Containers que correm no cluster e enviados para análise externa. Este caminho de conectividade suporta a deteção de ameaças em tempo de execução e outras capacidades baseadas em sensores.

Ligação a APIs de fornecedores de cloud

O Microsoft Defender para a Cloud liga-se às APIs dos fornecedores de cloud para descobrir recursos e realizar análises de segurança como parte do processo de ligação ao ambiente cloud. Este caminho de conectividade é estabelecido quando liga o seu ambiente cloud ao Microsoft Defender para a Cloud.

Registos de auditoria Kubernetes enviados a partir da infraestrutura cloud

A infraestrutura cloud envia registos de auditoria do Kubernetes para o Microsoft Defender para a Cloud para deteção de ameaças no plano de controlo e análise de segurança. O método utilizado para recolher e enviar registos de auditoria depende do fornecedor da cloud e do ambiente onde os clusters Kubernetes funcionam.

Esta arquitetura também permite a deteção de eventos relacionados com a exposição, como Serviço Kubernetes exposto detetado, quando um Serviço Kubernetes do tipo LoadBalancer é criado ou atualizado e expõe publicamente cargas de trabalho. Estes sinais são normalmente priorizados quando a exposição à internet é não intencional ou quando os controlos de autenticação são fracos ou faltam.

Suporte a proxy e conectividade privada

Os componentes do Defender for Containers suportam conectividade de saída através de proxies configurados e configurações de conectividade privada.

Arquitetura para cada ambiente Kubernetes

Componentes de arquitetura

Quando o Defender para a Cloud protege um cluster alojado no Azure Kubernetes Service, recolhe dados de registo de auditoria Kubernetes nativamente através da infraestrutura Azure, sem necessidade de agentes ou configurações adicionais. Para obter a proteção total oferecida pelo Microsoft Defender para Containers, precisa destes componentes:

  • sensor do Defender: Um DaemonSet leve implementado nos nós do AKS que recolhe telemetria em tempo de execução (eventos do Kubernetes, processos e dados de rede) através da tecnologia eBPF. Envia a telemetria de forma segura para o Defender para a Cloud para proteção contra ameaças em tempo de execução. O sensor regista-se num espaço de trabalho de Log Analytics e atua como um pipeline de dados. No entanto, os dados do log de auditoria não são armazenados no espaço de trabalho do Log Analytics. O sensor Defender é implementado como um perfil de segurança AKS, integrado nativamente no AKS Resource Provider (RP).

Note

Quando configuras o sensor Defender num cluster AKS, isso desencadeia um processo de reconciliação. Este processo ocorre como parte do plano Defender for Containers e é um comportamento esperado.

  • Política Azure para Kubernetes: Um pod que estende o Gatekeeper v3 open-source e se regista como um webhook para o controlo de admissão do Kubernetes. Com este pod, pode aplicar fiscalização e salvaguardas em larga escala nos seus clusters de forma centralizada e consistente. O pod do Azure Policy for Kubernetes é implementado como uma extensão AKS e só precisa de ser instalado num único nó do cluster. Oferece a opção de aplicar regras de configuração. Saiba mais sobre a proteção de cargas de trabalho do Kubernetes e o Azure Policy for Kubernetes.
  • Integração com ACR: Varredura de imagens acionada por push e periódica para o Azure Container Registry, fornecendo avaliação de vulnerabilidades sem necessidade de componentes adicionais.
  • Descoberta sem agente: Proporciona visibilidade dos seus clusters Kubernetes sem necessidade de agentes, utilizando capacidades nativas do Azure para descobrir e avaliar configurações de clusters.
  • Análise sem agente para máquinas: Capturas instantâneas periódicas dos discos dos nós do Kubernetes para uma análise aprofundada, fora de banda, da configuração do sistema operativo e do sistema de ficheiros. Esta funcionalidade não necessita de agentes instalados nem de ligação à rede, e não afeta o desempenho da máquina.
  • Integração Microsoft XDR: Integra-se com a plataforma alargada de deteção e resposta da Microsoft para operações de segurança unificadas e resposta a incidentes.

Diagrama da arquitetura de alto nível da interação entre o Microsoft Defender for Containers, o Serviço Kubernetes do Azure e a Política do Azure.

Note

Estes componentes não requerem ligações de entrada aos seus clusters e utilizam a infraestrutura de segurança nativa do Azure. Todos os componentes utilizam conectividade apenas de saída (sem necessidade de acesso de entrada).

Detalhes do componente do sensor Defender

Nome do pod Namespace Variante Breve descrição Capacidades Limites de recursos Saída necessária
microsoft-defender-collector-ds-* sistema kube DaemonSet Recolhe telemetria em tempo de execução (eventos, processos e dados de rede Kubernetes) dos nós utilizando tecnologia eBPF e envia-a de forma segura para o Defender para a Cloud. SYS_ADMIN,
SYS_RESOURCE,
SYS_PTRACE		 memória: 296Mi

CPU: 360m		 No
microsoft-defender-colecionador-misc-* sistema kube Implementação Recolhe inventário ao nível do cluster e eventos de segurança que não estão ligados a nós específicos. N/A memória: 64Mi

CPU: 60m		 No
microsoft-defender-publicador-ds-* sistema kube DaemonSet Publica a telemetria recolhida para o serviço de backend Microsoft Defender for Containers para processamento e análise. N/A memória: 200Mi

CPU: 60m		 Https 443

Saiba mais sobre os pré-requisitos de acesso de saída

* Não podes configurar limites de recursos. Saiba mais sobre os limites de recursos do Kubernetes.

Como funciona a descoberta sem agente para Kubernetes no Azure?

O processo de descoberta utiliza instantâneos tirados em intervalos:

Diagrama da arquitetura de permissões.

Quando você habilita a descoberta sem agente para a extensão Kubernetes, ocorre o seguinte processo:

  • Criar:
    • Se ativar a extensão do GPSC do Defender, o Defender para a Cloud cria uma identidade no seu ambiente chamada CloudPosture/securityOperator/DefenderCSPMSecurityOperator.
    • Se ativar a extensão do Defender for Containers, o Defender para a Cloud cria uma identidade no seu ambiente chamada CloudPosture/securityOperator/DefenderForContainersSecurityOperator.
  • Atribuir: O Defender para a Cloud atribui uma função incorporada chamada Kubernetes Agentless Operator a essa identidade ao nível da subscrição. O papel contém as seguintes permissões:
    • AKS leitura (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 AKS Trusted Access.
  • Descubra: Usando a identidade atribuída ao sistema, o Defender para a Cloud descobre os clusters AKS no seu ambiente através de chamadas API para o servidor API do AKS.
  • Associar: Após descobrir um cluster do AKS, o Defender para a Cloud executa uma operação de associação do AKS ao criar um ClusterRoleBinding entre a identidade criada e a função do Kubernetes ClusterRoleaks:trustedaccessrole:defender-containers:microsoft-defender-operator. O ClusterRole é visível através da API e permite a leitura do plano de dados do Defender para a Cloud dentro do cluster.

Note

O snapshot copiado mantém-se na mesma região do cluster.

Conteúdo relacionado

  • Last updated on