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

Azure (AKS)

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.

• 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 a ClusterRoleaks:trustedaccessrole:defender-containers:microsoft-defender-operator do Kubernetes. A ClusterRole é 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.

Local/IaaS (Arc)

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 sensor, 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:

• Sensor do Defender: o DaemonSet implantado em cada nó coleta sinais de hosts usando a tecnologia eBPF e logs de auditoria do Kubernetes para fornecer 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 uma extensão do Kubernetes habilitado para Arc.

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

Observação

O suporte do Defender para Contêineres para clusters de Kubernetes habilitados para AR é uma versão prévia do recurso.

AWS (EKS)

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 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 sensor, 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:
• 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 uma extensão do Kubernetes habilitado para Arc.
• 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 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.

Como funciona a descoberta sem agente do 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.

Observação

O instantâneo copiado permanece na mesma região que o cluster.

GCP (GKE)

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 Registro em Log da Nuvem do GCP 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 sensor, instalada em um nó no cluster, que permite que os clusters se conectem ao Defender para Nuvem. Em seguida, o Defender para Nuvem pode implantar os dois agentes a seguir como extensões do Arc:

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

• 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 pod do Kubernetes é implantado como uma extensão do Kubernetes habilitada para Arc. Só precisa ser 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.

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.

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:

Habilitar o Defender para Contêineres