컨테이너용 Defender 아키텍처

  • 10분

컨테이너용 Defender는 실행 중인 Kubernetes 환경에 관계없이 각 컨테이너 환경에 대해 다르게 설계됩니다.

  • AKS(Azure Kubernetes Service) - 컨테이너화된 애플리케이션 개발, 배포 및 관리를 위한 Microsoft의 관리형 서비스입니다.
  • 연결된 AWS(Amazon Web Services) 계정의 Amazon EKS(Elastic Kubernetes Service) - 자체 Kubernetes 컨트롤 플레인 또는 노드를 설치, 운영, 유지 관리할 필요 없이 AWS에서 Kubernetes를 실행하기 위한 Amazon 관리되는 서비스입니다.
  • 연결된 GCP(Google Cloud Platform) 프로젝트의 GKE(Google Kubernetes Engine) - GCP 인프라를 사용하여 애플리케이션을 배포, 관리 및 크기 조정하기 위한 Google의 관리 환경입니다.
  • 관리되지 않는 Kubernetes 배포(Azure Arc 지원 Kubernetes 사용) - 온-프레미스 또는 IaaS에서 호스트되는 CNCF(Cloud Native Computing Foundation) 인증 Kubernetes 클러스터입니다.

Kubernetes 컨테이너를 보호하기 위해 컨테이너용 Defender는 다음을 수신하고 분석합니다.

  • API 서버의 감사 로그 및 보안 이벤트
  • 컨트롤 플레인의 클러스터 구성 정보
  • Azure Policy의 워크로드 구성
  • 노드 수준의 보안 신호 및 이벤트

각 Kubernetes 환경별 아키텍처

클라우드용 Defender 및 AKS 클러스터의 아키텍처 다이어그램

클라우드용 Defender가 Azure Kubernetes Service에서 호스트되는 클러스터를 보호하는 경우 감사 로그 데이터 컬렉션은 에이전트 없이 이루어지며 추가 비용이나 구성 고려 사항 없이 Azure 인프라를 통해 자동으로 수집됩니다. 컨테이너용 Microsoft Defender에서 제공하는 전체 보호를 받기 위해 필요한 구성 요소는 다음과 같습니다.

  • Defender 에이전트: 각 노드에 배포되는 DaemonSet는 *eBPF(확장 버클리 패킷 필터) 기술*을 사용하여 호스트에서 신호를 수집하고 런타임 보호를 제공합니다. 에이전트는 Log Analytics 작업 영역에 등록되어 데이터 파이프라인으로 사용됩니다. 그러나 감사 로그 데이터는 Log Analytics 작업 영역에 저장되지 않습니다. Defender 에이전트는 AKS 보안 프로필로 배포됩니다.

    • *eBPF 배경 및 정보*: eBPF(확장 버클리 패킷 필터)는 Linux 커널내에서 네트워크 패킷 분석 및 필터링을 지원하는 강력한 다용도 프레임워크로, 그 외 다양한 시스템 수준 작업을 수행합니다. 원래 1990년대에 도입된 BPF(버클리 패킷 필터)를 토대로 한 eBPF는 커널 내에서 사용자 정의 프로그램을 실행할 수 있도록 기능을 확장하여 커널 자체를 수정하지 않고도 동적이고 효율적으로 패킷을 처리할 수 있게 합니다.
    • eBPF 프로그램은 C의 제한된 하위 집합으로 작성되고 커널에 로드되어 안전한 샌드박스 환경에서 실행됩니다. 이를 통해 커널 내에서 직접 패킷 필터링, 트래픽 모니터링, 보안 시행 및 사용자 지정 프로토콜 구문 분석과 같은 광범위한 네트워크 관련 작업을 수행할 수 있습니다.
    • eBPF의 주요 장점 중에는 다목적성과 성능이 있습니다. eBPF 프로그램은 커널 내에서 실행함으로써 네트워크 패킷에 직접 액세스하고 조작할 수 있어 기존의 사용자 공간 패킷 처리 방법에 비해 오버헤드를 크게 줄일 수 있습니다. 또한 eBPF 프로그램은 동적으로 로드하고 커널 내의 다양한 후크에 연결할 수 있어 변화하는 네트워크 조건에 실시간으로 대응하고 적응할 수 있습니다.
    • eBPF는 유연성과 효율성으로 인해 최신 네트워킹 및 보안 애플리케이션에서 점점 더 인기를 끌고 있습니다. eBPF는 네트워크 모니터링, 침입 탐지, 트래픽 분석 및 성능 튜닝을 위한 도구와 프레임워크에서 널리 사용됩니다. 또한 eBPF 기능은 네트워킹을 넘어 시스템 가시성과 제어라는 다른 영역으로 확장하여 광범위한 Linux 기반 애플리케이션 및 서비스의 기본 구성 요소가 됩니다.

  • Kubernetes에 대한 Azure Policy: 오픈 소스 Gatekeeper v3의 크기를 조정하고 Kubernetes 허용 제어에 대한 웹후크로 등록하여 중앙 집중적이고 일관된 방식으로 클러스터에 대규모 적용 및 보호 조치를 적용할 수 있는 Pod입니다. Kubernetes에 대한 Azure Policy Pod는 AKS 추가 기능으로 배포됩니다. 클러스터의 한 노드에만 설치됩니다.

Azure Kubernetes Service 아키텍처의 예시 다이어그램.

Defender 에이전트 구성 요소 세부 정보

Pod 이름 네임스페이스 종류 간단한 설명 Capabilities 리소스 한계 송신 필요
microsoft-defender-collector-ds-* kube-system DaemonSet Kubernetes 환경에서 인벤토리 및 보안 이벤트 수집에 중점을 둔 컨테이너 집합입니다. SYS_ADMIN,
SYS_RESOURCE,
SYS_PTRACE		 메모리: 296Mi

cpu: 360m		 아니요
microsoft-defender-collector-misc-* kube-system 배포 특정 노드에 바인딩되지 않은 Kubernetes 환경에서 인벤토리 및 보안 이벤트를 수집하는 데 중점을 둔 컨테이너 집합입니다. 해당 없음 메모리: 64Mi

cpu: 60m		 아니요
microsoft-defender-publisher-ds-* kube-system DaemonSet 수집된 데이터를 컨테이너용 Microsoft Defender 백 엔드 서비스에 게시하여 데이터를 처리하고 분석합니다. 해당 없음 메모리: 200Mi

cpu: 60m		 Https 443

Azure에서 Kubernetes에 대한 에이전트 없는 검색은 어떻게 작동하나요?

검색 프로세스는 다음과 같은 간격으로 생성된 스냅샷을 기반으로 합니다.

kubernetes 사용 권한 아키텍처의 예시 다이어그램. Kubernetes 확장에 대해 에이전트 없는 검색을 활성화하면 다음 프로세스가 발생합니다.

  • 만들기:

    • Defender CSPM에서 확장이 사용하도록 설정된 경우 클라우드용 Defender는 CloudPosture/securityOperator/DefenderCSPMSecurityOperator라는 고객 환경에서 ID를 만듭니다.
    • 컨테이너용 Defender에서 확장이 사용하도록 설정된 경우 클라우드용 Defender는 고객 환경에서 CloudPosture/securityOperator/DefenderForContainersSecurityOperator라는 ID를 만듭니다.
    • 할당: 클라우드용 Defender는 구독 범위의 해당 ID에 Kubernetes 에이전트 없는 운영자라는 기본 제공 역할을 할당합니다. 역할에는 다음 권한이 포함됩니다.
    • AKS 읽기(Microsoft.ContainerService/managedClusters/read)
    • AKS 신뢰할 수 있는 액세스 권한은 다음과 같습니다.
    • Microsoft.ContainerService/managedClusters/trustedAccessRoleBindings/write
    • Microsoft.ContainerService/managedClusters/trustedAccessRoleBindings/read
    • Microsoft.ContainerService/managedClusters/trustedAccessRoleBindings/delete

  • 검색: 클라우드용 Defender는 시스템 할당 ID를 사용하여 AKS의 API 서버에 대한 API 호출을 사용하여 사용자 환경에서 AKS 클러스터 검색을 수행합니다.

  • 바인딩: AKS 클러스터가 검색되면 클라우드용 Defender는 생성된 ID와 Kubernetes ClusterRole aks:trustedaccessrole:defender-containers:microsoft-defender-operator 간에 ClusterRoleBinding을 만들어 AKS 바인딩 작업을 수행합니다. ClusterRole은 API를 통해 표시되며 클러스터 내부에서 클라우드용 Defender 데이터 평면 읽기 권한을 부여합니다.

신뢰할 수 있는 액세스(미리 보기)를 사용하여 Azure Kubernetes Service에서 Azure 리소스에 대한 보안 액세스 권한 가져오기

AKS(Azure Kubernetes Service)와 통합되는 많은 Azure 서비스를 사용하려면 Kubernetes API 서버에 액세스해야 합니다. 이러한 서비스 관리자 액세스 권한을 부여하거나 네트워크에 액세스하기 위해 AKS 클러스터를 공용으로 설정하지 않으려면, AKS 신뢰할 수 있는 액세스 기능을 사용하면 됩니다.

이 기능은 프라이빗 엔드포인트 없이 Azure 백 엔드를 사용하여 AKS 및 Kubernetes에 대한 보안 액세스 권한을 서비스에 제공합니다. 이 기능은 Microsoft Entra 권한이 있는 ID를 사용하는 대신 시스템이 할당한 관리 ID를 사용하여 AKS 클러스터에서 이용하려는 관리되는 서비스와 애플리케이션을 인증합니다.

Important

AKS 미리 보기 기능은 셀프 서비스에서 사용할 수 있습니다(옵트인 방식). 미리 보기는 "있는 그대로" 및 "사용 가능한 상태로" 제공되며 서비스 수준 계약 및 제한적 보증에서 제외됩니다. AKS 미리 보기의 일부는 고객 지원팀에서 최선을 다해 지원합니다.

참고 항목

신뢰할 수 있는 액세스 API는 일반 공급됩니다. Azure CLI에 대한 GA(일반 공급) 지원을 제공하지만 아직 미리 보기 상태이며 aks-preview 확장을 사용해야 합니다.

신뢰할 수 있는 액세스 기능 개요

신뢰할 수 있는 액세스에서는 다음 시나리오를 다룹니다.

  • 권한 있는 IP 범위가 설정되거나 프라이빗 클러스터에 있는 경우, 프라이빗 엔드포인트 액세스 모델을 구현하지 않으면 Azure 서비스에서 Kubernetes API 서버에 액세스하지 못할 수도 있습니다.
  • Azure 서비스 관리자에게 Kubernetes API에 대한 액세스 권한을 부여할 때 최소 권한 액세스 모범 사례를 따르지 않으면 권한 상승 또는 자격 증명 유출 위험이 발생할 수 있습니다. 예를 들어 높은 권한의 서비스 대 서비스 권한을 구현해야 할 수도 있는데, 이는 감사 검토에 적합하지 않습니다.

신뢰할 수 있는 액세스를 사용하여 역할 바인딩이라는 Azure 리소스를 사용하면 AKS 클러스터에 액세스하도록 허용된 리소스의 시스템이 할당한 관리 ID에 명시적으로 동의하게 될 수 있습니다. Azure 리소스는 시스템이 할당한 관리 ID 인증을 사용하여 AKS 지역 게이트웨이를 통해 AKS 클러스터에 액세스합니다. 적절한 Kubernetes 권한은 역할이라는 Azure 리소스를 통해 할당됩니다. 신뢰할 수 있는 액세스를 통해 프라이빗 클러스터, 로컬 계정이 비활성화된 클러스터, Microsoft Entra 클러스터, 권한 있는 IP 범위 클러스터를 포함하나 이에 국한되지 않는 다양한 구성으로 AKS 클러스터에 액세스할 수 있습니다.

필수 조건

  • 활성 구독이 있는 Azure 계정. 체험 계정을 만듭니다.

  • 시스템이 할당한 관리 ID를 지원하는 리소스 종류입니다.

    • Azure CLI를 사용하는 경우 aks-preview 확장 버전 0.5.74 이상이 필요합니다.

  • 다양한 시나리오에서 어떤 역할을 사용해야 하는지 알아보려면 다음 문서를 참조하세요.

    • AzureML access to AKS clusters with special configurations(특수 구성을 사용하는 AKS 클러스터에 대한 Azure Machine Learning 액세스)
    • Azure Kubernetes Service 백업이란?
    • 에이전트 없는 컨테이너 상태 활성화

클라우드용 Defender 및 Arc 지원 Kubernetes 클러스터의 아키텍처 다이어그램

컨테이너용 Microsoft Defender가 제공하는 전체 보호를 받으려면 이러한 구성 요소가 필요합니다.

  • Azure Arc 지원 Kubernetes - Azure Arc 지원 Kubernetes - 클러스터의 한 노드에 설치되어 클러스터를 클라우드용 Defender에 연결하는 에이전트 기반 솔루션입니다. 그러면 클라우드용 Defender는 다음 두 에이전트를 Arc 확장으로 배포할 수 있습니다.
  • Defender 에이전트: 각 노드에 배포되는 DaemonSet는 eBPF 기술 및 Kubernetes 감사 로그를 사용하여 호스트 신호를 수집하고 런타임 보호를 제공합니다. 에이전트는 Log Analytics 작업 영역에 등록되어 데이터 파이프라인으로 사용됩니다. 그러나 감사 로그 데이터는 Log Analytics 작업 영역에 저장되지 않습니다. Defender 에이전트는 Arc 지원 Kubernetes 확장으로 배포됩니다.
  • Kubernetes용 Azure Policy: 오픈 소스 Gatekeeper v3를 확장하고 Kubernetes 허용 제어에 웹후크로 등록하여 중앙 집중식의 일관된 방식으로 클러스터에 대규모 실행 및 보호 장치를 적용할 수 있도록 하는 Pod입니다. Kubernetes에 대한 Azure Policy Pod는 Arc 지원 Kubernetes 확장으로 배포됩니다. 클러스터의 한 노드에만 설치됩니다. 자세한 내용은 Kubernetes 워크로드 보호 및 Kubernetes에 대한 Azure Policy 클러스터 이해를 참조하세요.

Azure Arc 지원 아키텍처의 예시 다이어그램.

클라우드용 Defender 및 EKS 클러스터의 아키텍처 다이어그램

클라우드용 Defender가 Elastic Kubernetes Service에서 호스트되는 클러스터를 보호하는 경우 감사 로그 데이터 컬렉션에는 에이전트가 없습니다. 컨테이너용 Microsoft Defender에서 제공하는 전체 보호를 받기 위해 필요한 구성 요소는 다음과 같습니다.

  • Kubernetes 감사 로그 – AWS 계정의 CloudWatch는 에이전트 없는 수집기를 통해 감사 로그 데이터를 사용하도록 설정 및 수집하고, 추가 분석을 위해 수집된 정보를 클라우드용 Microsoft Defender 백 엔드로 보냅니다.
  • Azure Arc 지원 Kubernetes - Azure Arc 지원 Kubernetes - 클러스터의 한 노드에 설치되어 클러스터를 클라우드용 Defender에 연결하는 에이전트 기반 솔루션입니다. 그러면 클라우드용 Defender는 다음 두 에이전트를 Arc 확장으로 배포할 수 있습니다.
  • Defender 에이전트: 각 노드에 배포되는 DaemonSet는 eBPF 기술을 사용하여 호스트로부터 신호를 수집하고 런타임 보호를 제공합니다. 에이전트는 Log Analytics 작업 영역에 등록되어 데이터 파이프라인으로 사용됩니다. 그러나 감사 로그 데이터는 Log Analytics 작업 영역에 저장되지 않습니다. Defender 에이전트는 Arc 지원 Kubernetes 확장으로 배포됩니다.
  • Kubernetes용 Azure Policy: 오픈 소스 Gatekeeper v3를 확장하고 Kubernetes 허용 제어에 웹후크로 등록하여 중앙 집중식의 일관된 방식으로 클러스터에 대규모 실행 및 보호 장치를 적용할 수 있도록 하는 Pod입니다. Kubernetes에 대한 Azure Policy Pod는 Arc 지원 Kubernetes 확장으로 배포됩니다. 클러스터의 한 노드에만 설치됩니다.

Amazon Elastic Kubernetes 서비스 아키텍처의 예시 다이어그램. AWS에서 Kubernetes에 대한 에이전트 없는 검색은 어떻게 작동하나요?

검색 프로세스는 다음과 같은 간격으로 생성된 스냅샷을 기반으로 합니다.

Kubernetes에 대한 에이전트 없는 검색 확장을 사용하도록 설정하면 다음 프로세스가 발생합니다.

  • 생성:

    • 클라우드용 Defender 역할 MDCContainersAgentlessDiscoveryK8sRole을 EKS 클러스터의 aws-auth ConfigMap에 추가해야 합니다. 이름은 사용자 지정할 수 있습니다.

  • 할당: 클라우드용 Defender는 MDCContainersAgentlessDiscoveryK8sRole 역할에 다음 권한을 할당합니다.

    • eks:UpdateClusterConfig
    • eks:DescribeCluster

  • 검색: 클라우드용 Defender는 시스템 할당 ID를 사용하여 EKS의 API 서버에 대한 API 호출을 사용하여 사용자 환경에서 EKS 클러스터 검색을 수행합니다.

클라우드용 Defender 및 GKE 클러스터의 아키텍처 다이어그램

클라우드용 Defender가 Google Kubernetes Engine에서 호스트되는 클러스터를 보호하는 경우 감사 로그 데이터 컬렉션에는 에이전트가 없습니다. 컨테이너용 Microsoft Defender에서 제공하는 전체 보호를 받기 위해 필요한 구성 요소는 다음과 같습니다.

  • Kubernetes 감사 로그 – GCP Cloud Logging은 에이전트 없는 수집기를 통해 감사 로그 데이터를 사용하도록 설정 및 수집하고 수집된 정보를 추가 분석을 위해 클라우드용 Microsoft Defender 백 엔드로 보냅니다.
  • Azure Arc 지원 Kubernetes - Azure Arc 지원 Kubernetes - 클러스터의 한 노드에 설치되어 클러스터를 클라우드용 Defender에 연결하는 에이전트 기반 솔루션입니다. 그러면 클라우드용 Defender는 다음 두 에이전트를 Arc 확장으로 배포할 수 있습니다.
  • Defender 에이전트: 각 노드에 배포되는 DaemonSet는 eBPF 기술을 사용하여 호스트로부터 신호를 수집하고 런타임 보호를 제공합니다. 에이전트는 Log Analytics 작업 영역에 등록되어 데이터 파이프라인으로 사용됩니다. 그러나 감사 로그 데이터는 Log Analytics 작업 영역에 저장되지 않습니다. Defender 에이전트는 Arc 지원 Kubernetes 확장으로 배포됩니다.
  • Kubernetes용 Azure Policy: 오픈 소스 Gatekeeper v3를 확장하고 Kubernetes 허용 제어에 웹후크로 등록하여 중앙 집중식의 일관된 방식으로 클러스터에 대규모 실행 및 보호 장치를 적용할 수 있도록 하는 Pod입니다. Kubernetes에 대한 Azure Policy Pod는 Arc 지원 Kubernetes 확장으로 배포됩니다. 클러스터의 한 노드에만 설치하면 됩니다.

Google Kubernetes Engine 아키텍처 클러스터의 예시 다이어그램.

GCP에서 Kubernetes에 대한 에이전트 없는 검색은 어떻게 작동하나요?

검색 프로세스는 다음과 같은 간격으로 생성된 스냅샷을 기반으로 합니다.

Kubernetes에 대한 에이전트 없는 검색 확장을 사용하도록 설정하면 다음 프로세스가 발생합니다.

  • 생성:

    • 서비스 계정 mdc-containers-k8s-operator가 만들어집니다. 이름은 사용자 지정할 수 있습니다.

  • 할당: 클라우드용 Defender는 서비스 계정 mdc-containers-k8s-operator에 다음 역할을 연결합니다.

    • container.clusters.update 권한이 있는 사용자 지정 역할 MDCGkeClusterWriteRole
    • 기본 제공 역할 container.viewer

  • 검색: 클라우드용 Defender는 시스템 할당 ID를 사용하여 GKE의 API 서버에 대한 API 호출을 사용하여 사용자 환경에서 GKE 클러스터 검색을 수행합니다.