Arquitetura do Defender for Containers

Concluído

O Defender for Containers foi projetado de forma diferente para cada ambiente Kubernetes, independentemente de estarem sendo executados em:

• Azure Kubernetes Service (AKS) - o serviço gerenciado da Microsoft para desenvolver, implantar e gerenciar aplicativos em contêineres.
  
• Amazon Elastic Kubernetes Service (EKS) em uma conta conectada da Amazon Web Services (AWS) - o serviço gerenciado da Amazon para executar o Kubernetes na AWS sem a necessidade de instalar, operar e manter seu próprio plano ou nós de controle do Kubernetes.
  
• Google Kubernetes Engine (GKE) em um projeto conectado do Google Cloud Platform (GCP) - o ambiente gerenciado do Google para implantar, gerenciar e dimensionar aplicativos usando a infraestrutura GCP.
  
• Uma distribuição Kubernetes não gerenciada (usando o Kubernetes habilitado para Azure Arc) - clusters Kubernetes certificados pela Cloud Native Computing Foundation (CNCF) hospedados no local ou em IaaS.

Para proteger seus contêineres Kubernetes, o Defender for Containers recebe e analisa:

• Logs de auditoria e eventos de segurança do servidor de API
• Informações de configuração do cluster do plano de controle
• Configuração da carga de trabalho da Política do Azure
• Sinais e eventos de segurança do nível do nó

Arquitetura para cada ambiente Kubernetes

Diagrama de arquitetura de clusters Defender for Cloud e AKS

Quando o Defender for Cloud protege um cluster hospedado no Serviço Kubernetes do Azure, a coleta de dados de log de auditoria é sem agente e coletada automaticamente por meio da infraestrutura do Azure, sem custo adicional ou considerações de configuração. Estes são os componentes necessários para receber a proteção total oferecida pelo Microsoft Defender for Containers:

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

  • *eBPF Background and Information*: O Extended Berkeley Packet Filter (eBPF) é uma estrutura poderosa e versátil dentro do kernel Linux para analisar e filtrar programaticamente pacotes de rede, bem como executar várias outras tarefas no nível do sistema. Originalmente baseado no Berkeley Packet Filter (BPF) introduzido na década de 1990, o eBPF expande suas capacidades permitindo que programas definidos pelo usuário sejam executados dentro do kernel, permitindo o processamento dinâmico e eficiente de pacotes sem exigir 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 dentro de 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 personalizado.
  • Uma das principais vantagens do eBPF é a sua versatilidade e desempenho. Ao executar dentro do kernel, os programas eBPF podem acessar e manipular pacotes de rede diretamente, reduzindo significativamente a sobrecarga em comparação com os métodos tradicionais de processamento de pacotes de 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 a capacidade de resposta em tempo real e adaptabilidade às mudanças nas condições da rede.
  • O eBPF tem se tornado cada vez mais popular em redes modernas e aplicações de segurança devido à sua flexibilidade e eficiência. É amplamente utilizado em ferramentas e estruturas para monitoramento de rede, deteção de intrusão, análise de tráfego e ajuste de desempenho. Além disso, suas capacidades se estendem além da rede para outras áreas de observabilidade e controle do sistema, tornando-se um bloco de construção fundamental para uma ampla gama de aplicativos e serviços baseados em Linux.

• Política do Azure para Kubernetes: um pod que estende o Gatekeeper v3 de código aberto e se registra como um gancho da Web para o controle de admissão do Kubernetes, tornando possível aplicar imposições em escala e salvaguardas em seus clusters de maneira centralizada e consistente. O pod da Política do Azure para Kubernetes é implantado como um complemento AKS. Ele é instalado apenas em um nó no cluster.

Detalhes do componente do agente Defender

Nome do pod	Espaço de nomes	Variante	Breve Descrição	Capacidades	Limites de recursos	Saída Necessária
microsoft-defender-colecionador-ds-*	kube-system	DaemonSet	Um conjunto de contêineres que se concentram na coleta de inventário e eventos de segurança do ambiente Kubernetes.	SYS_ADMIN, SYS_RESOURCE, SYS_PTRACE	memória: 296Mi CPU: 360m	Não
microsoft-defender-colecionador-misc-*	kube-system	Implementação	Um conjunto de contêineres que se concentram na coleta de eventos de inventário e segurança do ambiente Kubernetes que não estão vinculados a um nó específico.	N/A	memória: 64Mi CPU: 60m	Não
microsoft-defender-editor-ds-*	kube-system	DaemonSet	Publique os dados coletados no serviço de back-end do Microsoft Defender for Containers, onde os dados serão processados e analisados.	N/A	memória: 200Mi CPU: 60m	Disponível em: 443

Como funciona a descoberta sem agente para Kubernetes no Azure?

O processo de descoberta é baseado em instantâneos tirados em intervalos:

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

• Criar:

  • Se a extensão estiver habilitada no Defender CSPM, o Defender for Cloud criará uma identidade em ambientes de cliente chamada CloudPosture/securityOperator/DefenderCSPMSecurityOperator.
    
  • Se a extensão estiver habilitada no Defender for Containers, o Defender for Cloud criará uma identidade em ambientes de clientes chamada CloudPosture/securityOperator/DefenderForContainersSecurityOperator.
  • Atribuir: o Defender for Cloud 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 ler (Microsoft.ContainerService/managedClusters/read)
    
  • AKS Trusted Access com as seguintes permissões:
  • Microsoft.ContainerService/managedClusters/trustedAccessRoleBindings/write
  • Microsoft.ContainerService/managedClusters/trustedAccessRoleBindings/read
  • Microsoft.ContainerService/managedClusters/trustedAccessRoleBindings/delete

• Descubra: Usando a identidade atribuída ao sistema, o Defender for Cloud realiza uma descoberta dos clusters AKS em seu ambiente usando chamadas de API para o servidor de API do AKS.

• Bind: Após a descoberta de um cluster AKS, o Defender for Cloud executa uma operação de ligação AKS criando um ClusterRoleBinding entre a identidade criada e o Kubernetes ClusterRole aks:trustedaccessrole:defender-containers:microsoft-defender-operator. O ClusterRole é visível via API e dá permissão de leitura do plano de dados do Defender for Cloud dentro do cluster.

Obtenha acesso seguro para recursos do Azure no Serviço Kubernetes do Azure usando o Acesso Confiável (visualização)

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

Esse 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 ao sistema para autenticar com os serviços gerenciados e aplicativos que você deseja usar com seus clusters AKS.

Importante

Os recursos de visualização do AKS estão disponíveis em uma base de autosserviço e opt-in. As visualizações prévias são fornecidas "como estão" e "conforme disponíveis" e são excluídas dos contratos de nível de serviço e da garantia limitada. As visualizações do AKS são parcialmente cobertas pelo suporte ao cliente com base no melhor esforço.

Nota

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

Visão geral do recurso 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.
• Conceder a um administrador de serviço do Azure acesso à API do Kubernetes não segue as práticas recomendadas de acesso com 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 elevados, 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 AKS usando um recurso do Azure chamado associação de função. Os seus recursos do Azure acedem a clusters AKS através do gateway regional AKS através da autenticação de identidade gerida atribuída pelo sistema. As permissões apropriadas do Kubernetes são atribuídas por meio de um recurso do Azure chamado função. Através do Acesso Fidedigno, pode aceder a clusters AKS com diferentes configurações, incluindo, entre outros, clusters privados, clusters com contas locais desativadas, clusters Microsoft Entra e clusters de intervalo IP autorizados.

Pré-requisitos

• Uma conta do Azure com uma subscrição ativa. Crie uma conta gratuitamente.

• Tipos de recursos que suportam a identidade gerenciada atribuída ao sistema.

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

• 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
  • O que é o Azure Kubernetes Service?
  • Ativar uma postura de recipiente sem agente

Diagrama de arquitetura de clusters Kubernetes habilitados para Defender for Cloud e Arc

Esses componentes são necessários para receber a proteção total oferecida pelo Microsoft Defender for Containers:

• 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 for Cloud. O Defender for Cloud é então capaz de implantar os dois agentes a seguir como extensões Arc:
• Agente 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 tempo de execução. O agente é registrado em um espaço de trabalho do Log Analytics e usado 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 agente Defender é implantado como uma extensão do Kubernetes habilitada para Arc.
• Política do Azure para Kubernetes: um pod que estende o Gatekeeper v3 de código aberto e se registra como um gancho da Web para o controle de admissão do Kubernetes, tornando possível aplicar imposições em escala e salvaguardas em seus clusters de maneira centralizada e consistente. O pod da Política do Azure para Kubernetes é implantado como uma extensão do Kubernetes habilitada para Arc. Ele é instalado apenas em um nó no cluster. Para obter mais informações, consulte Proteja suas cargas de trabalho do Kubernetes e Entenda a Política do Azure para clusters do Kubernetes.
  

Diagrama de arquitetura de clusters Defender for Cloud e EKS

Quando o Defender for Cloud protege um cluster hospedado no Elastic Kubernetes Service, a coleta de dados de log de auditoria é sem agente. Estes são os componentes necessários para receber a proteção total oferecida pelo Microsoft Defender for Containers:

• Logs de auditoria do Kubernetes – o CloudWatch da conta da 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 for Cloud 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 for Cloud. O Defender for Cloud é então capaz de implantar os dois agentes a seguir como extensões Arc:
• Agente Defender: O DaemonSet que é implantado em cada nó, coleta sinais de hosts usando a tecnologia eBPF e fornece proteção de tempo de execução. O agente é registrado em um espaço de trabalho do Log Analytics e usado 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 agente Defender é implantado como uma extensão do Kubernetes habilitada para Arc.
• Política do Azure para Kubernetes: um pod que estende o Gatekeeper v3 de código aberto e se registra como um gancho da Web para o controle de admissão do Kubernetes, tornando possível aplicar imposições em escala e salvaguardas em seus clusters de maneira centralizada e consistente. O pod da Política do Azure para Kubernetes é implantado como uma extensão do Kubernetes habilitada para Arc. Ele é instalado apenas em um nó no cluster.

Como funciona a descoberta sem agente para Kubernetes na AWS?

O processo de descoberta é baseado em instantâneos tirados em intervalos:

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

• Criar:

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

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

  • eks:UpdateClusterConfig
    
  • eks:DescribeCluster

• Descubra: Usando a identidade atribuída ao sistema, o Defender for Cloud realiza uma descoberta dos clusters EKS em seu ambiente usando chamadas de API para o servidor de API do EKS.

Diagrama de arquitetura de clusters Defender for Cloud e GKE

Quando o Defender for Cloud protege um cluster hospedado no Google Kubernetes Engine, a coleta de dados de log de auditoria é sem agente. Estes são os componentes necessários para receber a proteção total oferecida pelo Microsoft Defender for Containers:

• 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 for Cloud 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 for Cloud. O Defender for Cloud é então capaz de implantar os dois agentes a seguir como extensões Arc:
• Agente Defender: O DaemonSet que é implantado em cada nó, coleta sinais de hosts usando a tecnologia eBPF e fornece proteção de tempo de execução. O agente é registrado em um espaço de trabalho do Log Analytics e usado 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 agente Defender é implantado como uma extensão do Kubernetes habilitada para Arc.
• Política do Azure para Kubernetes: um pod que estende o Gatekeeper v3 de código aberto e se registra como um gancho da Web para o controle de admissão do Kubernetes, tornando possível aplicar imposições em escala e salvaguardas em seus clusters de maneira centralizada e consistente. O pod da Política do Azure para Kubernetes é implantado como uma extensão do Kubernetes habilitada para Arc. Ele só precisa ser instalado em um nó no cluster.

Como funciona a descoberta sem agente para o Kubernetes no GCP?

O processo de descoberta é baseado em instantâneos tirados em intervalos:

Quando você habilita a descoberta sem agente para a extensã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 for Cloud 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

• Descubra: Usando a identidade atribuída ao sistema, o Defender for Cloud realiza uma descoberta dos clusters GKE em seu ambiente usando chamadas de API para o servidor de API do GKE.