Defender for Containers (CWPP)

If you’re managing production-grade workloads on a major cloud platform, it’s essential to assess your security framework, particularly as you shift towards microservices and orchestration. A key yet often overlooked solution in this space is Microsoft Defender for Containers. Part of the broader Microsoft Defender for Cloud, this tool provides critical visibility and protection for your Kubernetes environments, ensuring a robust defense as part of your Cloud Native Protection Platform. Exploring how Defender for Containers integrates into your security strategy can significantly enhance your cluster’s resilience.

What are the core components?

In a listing of the areas you can break these down with the following key points and I’ll also show some of these off in the console.

Security Posture Management – as like any resource that is deployed via an API it’s important to measure the activity of these resources, this includes monitoring your kubernetes cluster such as misconfiguration detections and assist in threat hunting.
Vulnerability Assessment – this comes into the area of agentless scanning for container images across different cloud platforms if you use Elastic Container Registry this has integration with that as well.
Run-time Threat Protection – when we think of the existing threats that occur most of the time this can be heavily reduced with run-time threat protection. This leverages the existing Threat Intelligence and integration with SIEM/XDR Systems. (For example various integrations are native to Microsoft Sentinel for Analytic Rules).
Deployment & Monitoring – this is monitoring your cluster for missing sensors the sensors play a role as a collector to your cluster configuration and this also offers native Kubernetes monitoring tools, and management of unmonitored resources.

To toggle this service on/off is dependent on the Subscription Settings if we navigate to Defender for Cloud -> Environment Settings.

You’ll notice in the visual the Containers I’ve enabled this and it created a trial so this won’t incur charges if you view Details.

This will tell you the protections for the service in Defender as spoken on briefly this is displayed like the following.

Once you have this updated and activated this will change the view to the following as shown.

To get the full functionality this will have the toggle on On for the demonstration I’m going to run a privileged pod to test the detection mechanism.

Testing out Defender for Containers

To learn anything in-depth its important to dive into the uses and configurations to also test the alerting mechanism. For this specific blog I’m using Azure CLI for access to a kubernetes cluster in AKS that has Defender for Containers plan activated. Note this will incur costs as the AKS Cluster is running as a resource if you want the cost to stop feel free to delete the resource shortly after.

kubectl get pods -A

This command should retrieve all pods that are currently running if you look specifically at the kube-system namespace this reveals the Daemon set running and publisher.

Now remember if we are testing the cluster against anything we have a few ways of interception I’ve noted in Threat Modeling on Kubernetes the use of Admission Controllers.

Credit for architecture retrieved from documentation

So its also broken down visually to understand the pods we are seeing running currently reside on the nodes if I run a kubectl get nodes -o wide

So from this visual we can make the understanding that the confines of the Defender for Containers sits on all three nodes once enabled its also important to note how Agentless discovery works discussed later in this post.

For this specific alerting I’m going to run a privileged pod that has some added capabilities I’m using a demo YAML manifest located here.

apiVersion: v1
kind: Pod
metadata:
  name: security-context-demo-4
spec:
  containers:
  - name: sec-ctx-4
    image: gcr.io/google-samples/node-hello:1.0
    securityContext:
      capabilities:
        add: ["NET_ADMIN", "SYS_TIME"]

So this pod in reality should have a interception of the Admission Controller to validate that this YAML manifest is defined with a proper alignment of permissions, while of course exceptions can be managed this would be the first step. So I’ve sent this running a following.

kubectl apply -f https://raw.githubusercontent.com/kubernetes/website/main/content/en/examples/pods/security/security-context-4.yaml

For the alerts to update which they will it will show these elevated pods are detected and give you a action alert while the time appears to update on that the visuals shown here on a sample alert.

If we’ve toggled the Take Action this is shown on the context of the finding and actions or rules you’ve configured such as notification or automated response based on the finding.

While this just scratches the surface the items located below are the affected resources by the finding this will always tie in MITRE ATT&CK tactics to assist you with identification and how it can be leveraged.

Agentless Discovery for Kubernetes in Azure

Similar to the de facto perspective of using a host-based sensor perhaps that might be to much for a organization to commit to this is where you can consider the use of Agentless Discovery. The way this work is a managed identity is created with a built in role known as Kubernetes Agentless Operator this then looks for AKS clusters in your environment and uses Trusted Access to bind the Managed Identity to your AKS Cluster. Once this occurs it will run checks on the various uses of API’s using API calls to the API server of AKS.

Enablement of Agentless Discovery does the following

Creation of CloudPosture/securityOperator/DefenderCSPMSecurityOperator is created as a identity in your environment, when enabled by Defender CSPM.
If the extension is enabled from Defender for Containers, this service will create a identity with a similar syntax. CloudPosture/securityOperator/DefenderForContainersSecurityOperator.
Assignment. Defender for Cloud relies on the Kubernetes Agentless Operator this will have the following permissions
- AKS Read (Microsoft.ContainerService/managedClusters/read)
- AKS Trusted Access with the following permissions
  - Microsoft.ContainerService/managedClusters/trustedAccessRoleBindings/write
  - Microsoft.ContainerService/managedClusters/trustedAccessRoleBindings/read
  - Microsoft.ContainerService/managedClusters/trustedAccessRoleBindings/delete

Discover as mentioned above once the role is able to be binding into the cluster is where the API calls to the API Server of AKS occur to understand the clusters configuration.
Bind once the discovery of the AKS cluster, this will perform a operation of creating a ClusterRoleBinding between the identity and the Kubernetes Cluster Role this will be seen as aks:trustedaccessrole:defender-containers:microsoft-defender-operator. This cluster role acts as the intermediary to send the data and provide this read permission in the cluster.

Summary

Microsoft Defender for Containers, natively integrated with Microsoft Azure, offers comprehensive protection for your container orchestration and includes image scanning capabilities for Azure Container Registry and Elastic Container Registry. Importantly, it supports extensions to multi-cloud environments, allowing for a unified security strategy across different cloud providers. This is touched on for other service providers with a depiction on architecture to how the data is collected and achieved here. Costs like anything play a pivotal role so evaluation of these tools should require the use and discipline of Tier 0 assets for effective resource allocation and protection.