Defender for Containers is designed differently for each Kubernetes environment whether they're running in:
Azure Kubernetes Service (AKS) - Microsoft's managed service for developing, deploying, and managing containerized applications.
Amazon Elastic Kubernetes Service (EKS) in a connected Amazon Web Services (AWS) account - Amazon's managed service for running Kubernetes on AWS without needing to install, operate, and maintain your own Kubernetes control plane or nodes.
Google Kubernetes Engine (GKE) in a connected Google Cloud Platform (GCP) project - Google’s managed environment for deploying, managing, and scaling applications using GCP infrastructure.
An unmanaged Kubernetes distribution (using Azure Arc-enabled Kubernetes) - Cloud Native Computing Foundation (CNCF) certified Kubernetes clusters hosted on-premises or on IaaS.
Note
Defender for Containers support for Arc-enabled Kubernetes clusters (AWS EKS and GCP GKE) is a preview feature.
To protect your Kubernetes containers, Defender for Containers receives and analyzes:
Audit logs and security events from the API server
Cluster configuration information from the control plane
Architecture diagram of Defender for Cloud and AKS clusters
When Defender for Cloud protects a cluster hosted in Azure Kubernetes Service, the collection of audit log data is agentless and collected automatically through Azure infrastructure with no additional cost or configuration considerations. These are the required components in order to receive the full protection offered by Microsoft Defender for Containers:
Defender sensor: The DaemonSet that is deployed on each node, collects signals from hosts using eBPF technology, and provides runtime protection. The sensor is registered with a Log Analytics workspace, and used as a data pipeline. However, the audit log data isn't stored in the Log Analytics workspace. The Defender sensor is deployed as an AKS Security profile.
Azure Policy for Kubernetes: A pod that extends the open-source Gatekeeper v3 and registers as a web hook to Kubernetes admission control making it possible to apply at-scale enforcements, and safeguards on your clusters in a centralized, consistent manner. The Azure Policy for Kubernetes pod is deployed as an AKS add-on. It's only installed on one node in the cluster. For more information, see Protect your Kubernetes workloads and Understand Azure Policy for Kubernetes clusters.
How does agentless discovery for Kubernetes in Azure work?
The discovery process is based on snapshots taken at intervals:
When you enable the agentless discovery for Kubernetes extension, the following process occurs:
Create:
If the extension is enabled from Defender CSPM, Defender for Cloud creates an identity in customer environments called CloudPosture/securityOperator/DefenderCSPMSecurityOperator.
If the extension is enabled from Defender for Containers, Defender for Cloud creates an identity in customer environments called CloudPosture/securityOperator/DefenderForContainersSecurityOperator.
Assign: Defender for Cloud assigns a built-in role called Kubernetes Agentless Operator to that identity on subscription scope. The role contains the following permissions:
AKS read (Microsoft.ContainerService/managedClusters/read)
AKS Trusted Access with the following permissions:
Discover: Using the system assigned identity, Defender for Cloud performs a discovery of the AKS clusters in your environment using API calls to the API server of AKS.
Bind: Upon discovery of an AKS cluster, Defender for Cloud performs an AKS bind operation by creating a ClusterRoleBinding between the created identity and the Kubernetes ClusterRoleaks:trustedaccessrole:defender-containers:microsoft-defender-operator. The ClusterRole is visible via API and gives Defender for Cloud data plane read permission inside the cluster.
Note
The copied snapshot remains in the same region as the cluster.
Architecture diagram of Defender for Cloud and Arc-enabled Kubernetes clusters
These components are required in order to receive the full protection offered by Microsoft Defender for Containers:
Azure Arc-enabled Kubernetes - Azure Arc-enabled Kubernetes - A sensor based solution, installed on one node in the cluster, that connects your clusters to Defender for Cloud. Defender for Cloud is then able to deploy the following two agents as Arc extensions:
Defender sensor: The DaemonSet that is deployed on each node, collects host signals using eBPF technology and Kubernetes audit logs, to provide runtime protection. The sensor is registered with a Log Analytics workspace, and used as a data pipeline. However, the audit log data isn't stored in the Log Analytics workspace. The Defender sensor is deployed as an Arc-enabled Kubernetes extension.
Azure Policy for Kubernetes: A pod that extends the open-source Gatekeeper v3 and registers as a web hook to Kubernetes admission control making it possible to apply at-scale enforcements, and safeguards on your clusters in a centralized, consistent manner. It's only installed on one node in the cluster. For more information, see Protect your Kubernetes workloads and Understand Azure Policy for Kubernetes clusters.
Note
Defender for Containers support for Arc-enabled Kubernetes clusters is a preview feature.
Architecture diagram of Defender for Cloud and EKS clusters
When Defender for Cloud protects a cluster hosted in Elastic Kubernetes Service, the collection of audit log data is agentless. These are the required components in order to receive the full protection offered by Microsoft Defender for Containers:
Kubernetes audit logs – AWS account’s CloudWatch enables, and collects audit log data through an agentless collector, and sends the collected information to the Microsoft Defender for Cloud backend for further analysis.
Azure Arc-enabled Kubernetes - Azure Arc-enabled Kubernetes - A sensor based solution, installed on one node in the cluster, that connects your clusters to Defender for Cloud. Defender for Cloud is then able to deploy the following two agents as Arc extensions:
Defender sensor: The DaemonSet that is deployed on each node, collects signals from hosts using eBPF technology, and provides runtime protection. The sensor is registered with a Log Analytics workspace, and used as a data pipeline. However, the audit log data isn't stored in the Log Analytics workspace. The Defender sensor is deployed as an Arc-enabled Kubernetes extension.
Azure Policy for Kubernetes: A pod that extends the open-source Gatekeeper v3 and registers as a web hook to Kubernetes admission control making it possible to apply at-scale enforcements, and safeguards on your clusters in a centralized, consistent manner. The Azure Policy for Kubernetes pod is deployed as an Arc-enabled Kubernetes extension. It's only installed on one node in the cluster. For more information, see Protect your Kubernetes workloads and Understand Azure Policy for Kubernetes clusters.
How does agentless discovery for Kubernetes in AWS work?
The discovery process is based on snapshots taken at intervals:
When you enable the agentless discovery for Kubernetes extension, the following process occurs:
Create:
The Defender for Cloud role MDCContainersAgentlessDiscoveryK8sRole must be added to the aws-auth ConfigMap of the EKS clusters. The name can be customized.
Assign: Defender for Cloud assigns the MDCContainersAgentlessDiscoveryK8sRole role the following permissions:
eks:UpdateClusterConfig
eks:DescribeCluster
Discover: Using the system assigned identity, Defender for Cloud performs a discovery of the EKS clusters in your environment using API calls to the API server of EKS.
Note
The copied snapshot remains in the same region as the cluster.
Architecture diagram of Defender for Cloud and GKE clusters
When Defender for Cloud protects a cluster hosted in Google Kubernetes Engine, the collection of audit log data is agentless. These are the required components in order to receive the full protection offered by Microsoft Defender for Containers:
Kubernetes audit logs – GCP Cloud Logging enables, and collects audit log data through an agentless collector, and sends the collected information to the Microsoft Defender for Cloud backend for further analysis.
Azure Arc-enabled Kubernetes - Azure Arc-enabled Kubernetes - A sensor based solution, installed on one node in the cluster, that enables your clusters to connect to Defender for Cloud. Defender for Cloud is then able to deploy the following two agents as Arc extensions:
Defender sensor: The DaemonSet that is deployed on each node, collects signals from hosts using eBPF technology, and provides runtime protection. The sensor is registered with a Log Analytics workspace, and used as a data pipeline. However, the audit log data isn't stored in the Log Analytics workspace.
Azure Policy for Kubernetes: A pod that extends the open-source Gatekeeper v3 and registers as a web hook to Kubernetes admission control making it possible to apply at-scale enforcements, and safeguards on your clusters in a centralized, consistent manner. The Azure Policy for Kubernetes pod is deployed as an Arc-enabled Kubernetes extension. It only needs to be installed on one node in the cluster. For more information, see Protect your Kubernetes workloads and Understand Azure Policy for Kubernetes clusters.
How does agentless discovery for Kubernetes in GCP work?
The discovery process is based on snapshots taken at intervals:
When you enable the agentless discovery for Kubernetes extension, the following process occurs:
Create:
The service account mdc-containers-k8s-operator is created. The name can be customized.
Assign: Defender for Cloud attaches the following roles to the service account mdc-containers-k8s-operator:
The custom role MDCGkeClusterWriteRole, which has the container.clusters.update permission
The built-in role container.viewer
Discover: Using the system assigned identity, Defender for Cloud performs a discovery of the GKE clusters in your environment using API calls to the API server of GKE.
Note
The copied snapshot remains in the same region as the cluster.
Next steps
In this overview, you learned about the architecture of container security in Microsoft Defender for Cloud. To enable the plan, see: