Microsoft Sentinel is a cloud-native SIEM, enriched with AI and automation to provide expansive visibility across your digital environment.

When evaluating various solutions, your peers value hearing from people like you who’ve used the product. Review Microsoft Sentinel by filling out a Gartner Peer Insights survey and receive a $25 USD gift card (for customers only). Here are the Privacy/Guideline links: Microsoft Privacy Statement, Gartner’s Community Guidelines & Gartner Peer Insights Review Guide.

A guide to using Microsoft Sentinel for monitoring the security of your containerized applications and orchestration platforms.

Part 3 of 3 part series about security monitoring of your Kubernetes Clusters and CI/CD pipelines by Abhi Singh and Umesh Nagdev, Security GBB

Link to Part 1

Link to Part 2

A guide to using Microsoft Sentinel for monitoring the security of your containerized applications and orchestration platforms.

Part 3 of 3 part series about security monitoring of your Kubernetes Clusters and CI/CD pipelines by singhabhi  and Umesh_Nagdev , Security GBB

Link to Part 1

Link to Part 2

Introduction 

In part 1 and part 2 of this series, we discussed the type of log sources you should consider for monitoring the security of your Kubernetes environment, most pertinent risks (and corresponding use cases) in your AKS environment, and log sources to ingest data. This blog will demonstrate how to configure Microsoft Sentinel to derive identify the risks.

More specifically we will show: 

\n
1. Mapping of container security risks with Microsoft Defender for Cloud  
\n
2. Data connectors to ingest AKS data 
\n
3. Container Security Workbooks in Sentinel 
\n
4. Search queries to mine specific log tables for more pressing risks
\n

How Microsoft Defender for Cloud addresses container risks 

Microsoft Defender for Containers is a security solution designed specifically for containerized environments. Microsoft Defender for Containers provides several key capabilities to enhance container security: 

\n
• Real-time protection: Defender for Containers offers real-time protection by continuously monitoring container activities, network traffic, and system events. It uses machine learning algorithms and heuristics to detect and respond to potential threats promptly. 
\n
• Vulnerability management: The solution helps identify vulnerabilities in container images and runtime environments. It can scan container images for known vulnerabilities, misconfigurations, and insecure dependencies, allowing organizations to address these issues before deploying containers into production.
\n
• Malware detection: Defender for Containers can detect and block malicious code, malware, and suspicious activities within containers. It leverages signature-based detection, behavioral analysis, and sandboxing techniques to identify and mitigate threats. 
\n
• File integrity monitoring: The solution includes file integrity monitoring capabilities to detect unauthorized changes or tampering within containerized environments. It monitors critical system files, configuration files, and application binaries for any suspicious modifications.
\n
• Network security: Defender for Containers helps secure container network traffic by enforcing access controls, segmenting network traffic, and detecting anomalies or suspicious network behavior. It can detect and block malicious network activities, such as port scanning, denial-of-service attacks, and lateral movement attempts.
\n
• Integration with Microsoft Defender for Cloud: Defender for Containers integrates seamlessly with Microsoft Defender for Cloud, providing centralized visibility, monitoring, and management of container security across hybrid and multi-cloud environments. It leverages Azure's cloud-native security capabilities and threat intelligence to enhance container security posture.
\n
• Incident response and remediation: In case of security incidents or suspicious activities, Defender for Containers provides tools for incident investigation, threat hunting, and automated remediation actions. It helps security teams quickly respond to security incidents and mitigate potential risks.
\n

There are several alerts https://learn.microsoft.com/en-us/azure/defender-for-cloud/alerts-reference#alerts-for-containers---kubernetes-clusters that you get out of the box.

Additionally, you can secure the Kubernetes Control Plane using Azure Policy (https://learn.microsoft.com/en-us/azure/aks/use-azure-policy).

This resource https://techcommunity.microsoft.com/t5/microsoft-defender-for-cloud/leveraging-defender-for-containers-to-simplify-policy-management/ba-p/3755757 provides additional background on how Azure Policies work to protect your Kubernetes Control Plane.

There are several out of the box policies that can quickly get you started https://learn.microsoft.com/en-us/azure/aks/policy-reference

The table below shows a mapping of container risks to MDC alerts and Azure Policies. You will see that with the help of Defender for Containers you will get a great coverage across several risks that we discussed in blog part 2

AKS Security Workbook 

There is an out of the box work that you can enable once you deploy the AKS Connector from Content Hub. If you are not familiar with Sentinel workbooks please refer to this resource https://techcommunity.microsoft.com/t5/microsoft-sentinel-blog/azure-sentinel-workbooks-101-with-sample-workbook/ba-p/1409216 to learn about how to enable and leverage workbooks.  

Let’s do a walkthrough of the AKS Security Workbook

Understanding the security coverage  

As we showcased above, Defender for Cloud provides a great coverage for your container security related risks.  

The first part would be to understand where you might have some blind spots that is the AKS clusters that are currently not being monitored by Defender for Cloud. The workbook allows you to look at the data across different subscriptions and the coverage table provides insights into where coverage is lacking. 

Note: The is a drop down for selecting the Time Range so you can see the items like alerts, recommendations etc. for that time period. 

\n   \n

Looking at the Overview of security alerts 

For the given time period as we discussed earlier, you will see the security state of your clusters. This dashboard helps you understand where you have the most exposure across container image repos and clusters. 

You can also see how alerts have changed over period of time.

\n   \n

Diving deeper into specific alerts 

Now that we understand our AKS Cluster coverage and areas of risk exposures, this next section shows you security alerts that exists in your environment. This way you can quickly prioritize where it would make sense to start to close most gaps.

\n   \n

Search queries for security monitoring

In this section we will talk about building custom content to search for common use cases.

1. Identifying the Users and IPs who have most number of denies 

You would want to understand who is trying to get situational awareness of your AKS environment. This can be an existing user or a script that’s trying to query your cluster. 

//API Authorization Deny by User, Source IP 
AKSAudit 
| where TimeGenerated > ago (1h) 
| extend authorizationDecision = parse_json(Annotations) 
| extend user = parse_json(User) 
| extend sourceIps = parse_json(SourceIps) 
| project TimeGenerated, PodName, Verb, sourceIps[0],user.username, authorizationDecision[\"authorization.k8s.io/decision\"], RequestUri 
| order by TimeGenerated asc 

2. Users that are assigned to Cluster Roles 

A ClusterRole can be used to grant the same permissions as a Role. Because ClusterRoles are cluster-scoped, you can also use them to grant access to: 

\n
• cluster-scoped resources (like nodes)
\n
• non-resource endpoints (like /healthz)
\n
• namespaced resources (like Pods), across all namespaces 
\n

You should not assign users to cluster roles. The following query shows you the users are aligned to a Cluster Role 

AKSAudit 
| where TimeGenerated > ago (1h) 
| where RequestObject.kind == \"ClusterRoleBinding\" 
| where ResponseObject.subjects[0].name != \"aks-support\" 
| project TimeGenerated, PodName, Verb, SourceIP=SourceIps[0],User=ResponseObject.subjects[0].name,ClusterRoleBinding=ResponseObject.metadata.name,ClusterRole=RequestObject.roleRef.name 
| order by TimeGenerated asc 

3. Users that have Admin Access 

Users should not be part of system:masters and system:accounts. Any user who is a member of this group bypasses all RBAC rights checks and will always have unrestricted superuser access, which cannot be revoked by removing RoleBindings or ClusterRoleBindings.

//Users part of system:masters or Users that are part of system:accounts 
AKSAudit 
| where TimeGenerated > ago (1h) 
| extend authorizationDecision = parse_json(Annotations) 
| extend user = parse_json(User) 
| extend sourceIps = parse_json(SourceIps) 
| where user.groups[0] in (\"system:masters\",\"system:accounts\") or user.groups[1] in (\"system:masters\",\"system:accounts\") 
| where user.username !in (\"aksService\",\"system:apiserver\",\"aksProblemDetector\") 
| project TimeGenerated, PodName, Verb, SourceIP=sourceIps[0],Username=user.username, AuthorizationDecision=authorizationDecision[\"authorization.k8s.io/decision\"], AuthorizationDecisionReason=authorizationDecision[\"authorization.k8s.io/reason\"], RequestUri 
| order by TimeGenerated asc

4. Resources that can run unauthenticated and anonymous API calls 

You would want to know who is part of system:unauthenticated group and remove them where possible, as this gives access to anyone who can contact the API server at a network level. 

/Bindings of system:unauthenticated and system:anonymous group 
AKSAudit 
| where TimeGenerated > ago (1h) 
| where PodName !startswith \"kube-apiserver\" 
| extend authorizationDecision = parse_json(Annotations) 
| extend user = parse_json(User) 
| extend sourceIps = parse_json(SourceIps) 
| extend ObjectRef = parse_json(ObjectRef) 
| where user.groups[0] in (\"system:unauthenticated\",\"system:anonymous\") or user.groups[1] in (\"system:unauthenticated\",\"system:anonymous\") 
| project TimeGenerated, PodName, Verb, Resource=ObjectRef.resource, SourceIP=sourceIps[0],Username=user.username, AuthorizationDecision=authorizationDecision[\"authorization.k8s.io/decision\"], AuthorizationDecisionReason=authorizationDecision[\"authorization.k8s.io/reason\"], RequestUri 
| order by TimeGenerated asc 

5. Users that are trying to get secrets  

There are not many common use cases where a user is getting Kubernetes secrets.

//Users that have executed 'kubectl get secrets' 
AKSAudit 
| where TimeGenerated > ago (1h) 
| where Verb == \"get\" 
| extend authorizationDecision = parse_json(Annotations) 
| extend user = parse_json(User) 
| extend sourceIps = parse_json(SourceIps) 
| extend ObjectRef = parse_json(ObjectRef) 
| where ObjectRef.resource == \"secrets\" 
| where user.username !startswith \"system:serviceaccount\" 
| project TimeGenerated, PodName, Verb, SourceIP=sourceIps[0],Username=user.username, AuthorizationDecision=authorizationDecision[\"authorization.k8s.io/decision\"], AuthorizationDecisionReason=authorizationDecision[\"authorization.k8s.io/reason\"], RequestUri 
| order by TimeGenerated asc 

6. Users that are trying to bind to Cluster Admin roles 

Like we discussed above Cluster Admin roles should be used sparingly. You would want to know who is trying to bind to Cluster Roles

//Users that have executed Cluster Role Binding on cluster admin 
AKSAudit 
| where TimeGenerated > ago (1h)
| where Verb == \"create\" 
| extend authorizationDecision = parse_json(Annotations) 
| extend user = parse_json(User) 
| extend sourceIps = parse_json(SourceIps) 
| extend ObjectRef = parse_json(ObjectRef) 
| where user.username != \"aksService\" 
| where ObjectRef.resource startswith \"clusterrole\" 
| project TimeGenerated, PodName, Verb, Resource=ObjectRef.resource, SourceIP=sourceIps[0],Username=user.username, AuthorizationDecision=authorizationDecision[\"authorization.k8s.io/decision\"], AuthorizationDecisionReason=authorizationDecision[\"authorization.k8s.io/reason\"], RequestUri 
| order by TimeGenerated asc

7. Pods that are in default namespace  

In Kubernetes, namespaces provides a mechanism for isolating groups of resources within a single cluster. Namespaces are a way to divide cluster resources between multiple users. Kubernetes includes the default namespace so that you can start using your new cluster without first creating a namespace. Unless a namespace is specified when creating a resource Kubernetes assumes the default namespace. As a result users will deploy their resources in Default Namespace and can make potentially malicious changes to running applications in the default namespace. 

ContainerLogV2 
| where TimeGenerated > ago (1h) 
| where LogSource == \"stdout\" 
| where PodNamespace == \"default\" 
| extend ContainerHostName1 = tostring(LogMessage.hostname) 
| join ContainerInventory on $left.ContainerHostName1 == $right.ContainerHostname 
| summarize dcount(Image) by ContainerHostname, Repository, Image 
| project ContainerHostname, Repository, Image 

Conclusion

In this document we showed you: 

\n
• \n

  How to set up Microsoft Sentinel to monitor security risks in Azure Kubernetes Services (AKS) clusters. It also discusses the container security risks and how Microsoft Defender for Cloud addresses them. 

  \n
\n

\n
• \n

  Provide you a map of 32 container risks and how Microsoft Defender for Cloud alerts and Azure Policies provide a great coverage. It covers the areas of pod security, network security, container image security, kubelet activity, API server security, RBAC monitoring, secrets and ConfigMap access, audit logging, compliance monitoring, container runtime security, and incident response and forensics. 

  \n
\n

\n
• \n

  Showed you how to configure your environment to monitor AKS. The data connectors to ingest AKS data, setting up the diagnostic settings for the AKS cluster and enabling Container Insights to get the pod level data. Showed you how to enable the AKS Connector from Content Hub, which provides a workbook, hunting queries, and a data connector. 

  \n
\n

\n
• \n

  We show how to use the out-of-the-box workbook that comes with the AKS Connector. The workbook helps to understand the AKS cluster coverage, the security state, the security alerts, and the security recommendations. It also provides filters and drill-downs for further analysis. 

  \n
\n

\n
• \n

  Provide some examples of custom search queries that can be used to mine the log tables for more pressing risks. The queries can help to identify unauthorized or suspicious pods, privilege escalation attempts, changes to pod security policies, unexpected network traffic patterns, unauthorized access to secrets, and more.

  \n
\n

A guide to using Microsoft Sentinel for monitoring the security of your containerized applications and orchestration platforms.

Part 3 of 3 part series about security monitoring of your Kubernetes Clusters and CI/CD pipelines by   and  , Security GBB

Link to Part 1

Link to Part 2

Introduction 

In part 1 and part 2 of this series, we discussed the type of log sources you should consider for monitoring the security of your Kubernetes environment, most pertinent risks (and corresponding use cases) in your AKS environment, and log sources to ingest data. This blog will demonstrate how to configure Microsoft Sentinel to derive identify the risks.

More specifically we will show: 

\n
1. Mapping of container security risks with Microsoft Defender for Cloud  
\n
2. Data connectors to ingest AKS data 
\n
3. Container Security Workbooks in Sentinel 
\n
4. Search queries to mine specific log tables for more pressing risks
\n

How Microsoft Defender for Cloud addresses container risks 

Microsoft Defender for Containers is a security solution designed specifically for containerized environments. Microsoft Defender for Containers provides several key capabilities to enhance container security: 

\n
• Real-time protection: Defender for Containers offers real-time protection by continuously monitoring container activities, network traffic, and system events. It uses machine learning algorithms and heuristics to detect and respond to potential threats promptly. 
\n
• Vulnerability management: The solution helps identify vulnerabilities in container images and runtime environments. It can scan container images for known vulnerabilities, misconfigurations, and insecure dependencies, allowing organizations to address these issues before deploying containers into production.
\n
• Malware detection: Defender for Containers can detect and block malicious code, malware, and suspicious activities within containers. It leverages signature-based detection, behavioral analysis, and sandboxing techniques to identify and mitigate threats. 
\n
• File integrity monitoring: The solution includes file integrity monitoring capabilities to detect unauthorized changes or tampering within containerized environments. It monitors critical system files, configuration files, and application binaries for any suspicious modifications.
\n
• Network security: Defender for Containers helps secure container network traffic by enforcing access controls, segmenting network traffic, and detecting anomalies or suspicious network behavior. It can detect and block malicious network activities, such as port scanning, denial-of-service attacks, and lateral movement attempts.
\n
• Integration with Microsoft Defender for Cloud: Defender for Containers integrates seamlessly with Microsoft Defender for Cloud, providing centralized visibility, monitoring, and management of container security across hybrid and multi-cloud environments. It leverages Azure's cloud-native security capabilities and threat intelligence to enhance container security posture.
\n
• Incident response and remediation: In case of security incidents or suspicious activities, Defender for Containers provides tools for incident investigation, threat hunting, and automated remediation actions. It helps security teams quickly respond to security incidents and mitigate potential risks.
\n

There are several alerts https://learn.microsoft.com/en-us/azure/defender-for-cloud/alerts-reference#alerts-for-containers---kubernetes-clusters that you get out of the box.

Additionally, you can secure the Kubernetes Control Plane using Azure Policy (https://learn.microsoft.com/en-us/azure/aks/use-azure-policy).

This resource https://techcommunity.microsoft.com/t5/microsoft-defender-for-cloud/leveraging-defender-for-containers-to-simplify-policy-management/ba-p/3755757 provides additional background on how Azure Policies work to protect your Kubernetes Control Plane.

There are several out of the box policies that can quickly get you started https://learn.microsoft.com/en-us/azure/aks/policy-reference

The table below shows a mapping of container risks to MDC alerts and Azure Policies. You will see that with the help of Defender for Containers you will get a great coverage across several risks that we discussed in blog part 2

AKS Security Workbook 

There is an out of the box work that you can enable once you deploy the AKS Connector from Content Hub. If you are not familiar with Sentinel workbooks please refer to this resource https://techcommunity.microsoft.com/t5/microsoft-sentinel-blog/azure-sentinel-workbooks-101-with-sample-workbook/ba-p/1409216 to learn about how to enable and leverage workbooks.  

Let’s do a walkthrough of the AKS Security Workbook

Understanding the security coverage  

As we showcased above, Defender for Cloud provides a great coverage for your container security related risks.  

The first part would be to understand where you might have some blind spots that is the AKS clusters that are currently not being monitored by Defender for Cloud. The workbook allows you to look at the data across different subscriptions and the coverage table provides insights into where coverage is lacking. 

Note: The is a drop down for selecting the Time Range so you can see the items like alerts, recommendations etc. for that time period. 

Looking at the Overview of security alerts 

For the given time period as we discussed earlier, you will see the security state of your clusters. This dashboard helps you understand where you have the most exposure across container image repos and clusters. 

You can also see how alerts have changed over period of time.

Diving deeper into specific alerts 

Now that we understand our AKS Cluster coverage and areas of risk exposures, this next section shows you security alerts that exists in your environment. This way you can quickly prioritize where it would make sense to start to close most gaps.

Search queries for security monitoring

In this section we will talk about building custom content to search for common use cases.

1. Identifying the Users and IPs who have most number of denies 

You would want to understand who is trying to get situational awareness of your AKS environment. This can be an existing user or a script that’s trying to query your cluster. 

//API Authorization Deny by User, Source IP 
AKSAudit 
| where TimeGenerated > ago (1h) 
| extend authorizationDecision = parse_json(Annotations) 
| extend user = parse_json(User) 
| extend sourceIps = parse_json(SourceIps) 
| project TimeGenerated, PodName, Verb, sourceIps[0],user.username, authorizationDecision[\"authorization.k8s.io/decision\"], RequestUri 
| order by TimeGenerated asc 

2. Users that are assigned to Cluster Roles 

A ClusterRole can be used to grant the same permissions as a Role. Because ClusterRoles are cluster-scoped, you can also use them to grant access to: 

\n
• cluster-scoped resources (like nodes)
\n
• non-resource endpoints (like /healthz)
\n
• namespaced resources (like Pods), across all namespaces 
\n

You should not assign users to cluster roles. The following query shows you the users are aligned to a Cluster Role 

AKSAudit 
| where TimeGenerated > ago (1h) 
| where RequestObject.kind == \"ClusterRoleBinding\" 
| where ResponseObject.subjects[0].name != \"aks-support\" 
| project TimeGenerated, PodName, Verb, SourceIP=SourceIps[0],User=ResponseObject.subjects[0].name,ClusterRoleBinding=ResponseObject.metadata.name,ClusterRole=RequestObject.roleRef.name 
| order by TimeGenerated asc 

3. Users that have Admin Access 

Users should not be part of system:masters and system:accounts. Any user who is a member of this group bypasses all RBAC rights checks and will always have unrestricted superuser access, which cannot be revoked by removing RoleBindings or ClusterRoleBindings.

//Users part of system:masters or Users that are part of system:accounts 
AKSAudit 
| where TimeGenerated > ago (1h) 
| extend authorizationDecision = parse_json(Annotations) 
| extend user = parse_json(User) 
| extend sourceIps = parse_json(SourceIps) 
| where user.groups[0] in (\"system:masters\",\"system:accounts\") or user.groups[1] in (\"system:masters\",\"system:accounts\") 
| where user.username !in (\"aksService\",\"system:apiserver\",\"aksProblemDetector\") 
| project TimeGenerated, PodName, Verb, SourceIP=sourceIps[0],Username=user.username, AuthorizationDecision=authorizationDecision[\"authorization.k8s.io/decision\"], AuthorizationDecisionReason=authorizationDecision[\"authorization.k8s.io/reason\"], RequestUri 
| order by TimeGenerated asc

4. Resources that can run unauthenticated and anonymous API calls 

You would want to know who is part of system:unauthenticated group and remove them where possible, as this gives access to anyone who can contact the API server at a network level. 

/Bindings of system:unauthenticated and system:anonymous group 
AKSAudit 
| where TimeGenerated > ago (1h) 
| where PodName !startswith \"kube-apiserver\" 
| extend authorizationDecision = parse_json(Annotations) 
| extend user = parse_json(User) 
| extend sourceIps = parse_json(SourceIps) 
| extend ObjectRef = parse_json(ObjectRef) 
| where user.groups[0] in (\"system:unauthenticated\",\"system:anonymous\") or user.groups[1] in (\"system:unauthenticated\",\"system:anonymous\") 
| project TimeGenerated, PodName, Verb, Resource=ObjectRef.resource, SourceIP=sourceIps[0],Username=user.username, AuthorizationDecision=authorizationDecision[\"authorization.k8s.io/decision\"], AuthorizationDecisionReason=authorizationDecision[\"authorization.k8s.io/reason\"], RequestUri 
| order by TimeGenerated asc 

5. Users that are trying to get secrets  

There are not many common use cases where a user is getting Kubernetes secrets.

//Users that have executed 'kubectl get secrets' 
AKSAudit 
| where TimeGenerated > ago (1h) 
| where Verb == \"get\" 
| extend authorizationDecision = parse_json(Annotations) 
| extend user = parse_json(User) 
| extend sourceIps = parse_json(SourceIps) 
| extend ObjectRef = parse_json(ObjectRef) 
| where ObjectRef.resource == \"secrets\" 
| where user.username !startswith \"system:serviceaccount\" 
| project TimeGenerated, PodName, Verb, SourceIP=sourceIps[0],Username=user.username, AuthorizationDecision=authorizationDecision[\"authorization.k8s.io/decision\"], AuthorizationDecisionReason=authorizationDecision[\"authorization.k8s.io/reason\"], RequestUri 
| order by TimeGenerated asc 

6. Users that are trying to bind to Cluster Admin roles 

Like we discussed above Cluster Admin roles should be used sparingly. You would want to know who is trying to bind to Cluster Roles

//Users that have executed Cluster Role Binding on cluster admin 
AKSAudit 
| where TimeGenerated > ago (1h)
| where Verb == \"create\" 
| extend authorizationDecision = parse_json(Annotations) 
| extend user = parse_json(User) 
| extend sourceIps = parse_json(SourceIps) 
| extend ObjectRef = parse_json(ObjectRef) 
| where user.username != \"aksService\" 
| where ObjectRef.resource startswith \"clusterrole\" 
| project TimeGenerated, PodName, Verb, Resource=ObjectRef.resource, SourceIP=sourceIps[0],Username=user.username, AuthorizationDecision=authorizationDecision[\"authorization.k8s.io/decision\"], AuthorizationDecisionReason=authorizationDecision[\"authorization.k8s.io/reason\"], RequestUri 
| order by TimeGenerated asc

7. Pods that are in default namespace  

In Kubernetes, namespaces provides a mechanism for isolating groups of resources within a single cluster. Namespaces are a way to divide cluster resources between multiple users. Kubernetes includes the default namespace so that you can start using your new cluster without first creating a namespace. Unless a namespace is specified when creating a resource Kubernetes assumes the default namespace. As a result users will deploy their resources in Default Namespace and can make potentially malicious changes to running applications in the default namespace. 

ContainerLogV2 
| where TimeGenerated > ago (1h) 
| where LogSource == \"stdout\" 
| where PodNamespace == \"default\" 
| extend ContainerHostName1 = tostring(LogMessage.hostname) 
| join ContainerInventory on $left.ContainerHostName1 == $right.ContainerHostname 
| summarize dcount(Image) by ContainerHostname, Repository, Image 
| project ContainerHostname, Repository, Image 

Conclusion

In this document we showed you: 

\n
• \n

  How to set up Microsoft Sentinel to monitor security risks in Azure Kubernetes Services (AKS) clusters. It also discusses the container security risks and how Microsoft Defender for Cloud addresses them. 

  \n
\n

\n
• \n

  Provide you a map of 32 container risks and how Microsoft Defender for Cloud alerts and Azure Policies provide a great coverage. It covers the areas of pod security, network security, container image security, kubelet activity, API server security, RBAC monitoring, secrets and ConfigMap access, audit logging, compliance monitoring, container runtime security, and incident response and forensics. 

  \n
\n

\n
• \n

  Showed you how to configure your environment to monitor AKS. The data connectors to ingest AKS data, setting up the diagnostic settings for the AKS cluster and enabling Container Insights to get the pod level data. Showed you how to enable the AKS Connector from Content Hub, which provides a workbook, hunting queries, and a data connector. 

  \n
\n

\n
• \n

  We show how to use the out-of-the-box workbook that comes with the AKS Connector. The workbook helps to understand the AKS cluster coverage, the security state, the security alerts, and the security recommendations. It also provides filters and drill-downs for further analysis. 

  \n
\n

\n
• \n

  Provide some examples of custom search queries that can be used to mine the log tables for more pressing risks. The queries can help to identify unauthorized or suspicious pods, privilege escalation attempts, changes to pod security policies, unexpected network traffic patterns, unauthorized access to secrets, and more.

  \n
\n

A guide to using Microsoft Sentinel for monitoring the security of your containerized applications and orchestration platforms.

Part 3 of 3 part series about security monitoring of your Kubernetes Clusters and CI/CD pipelines by Abhi Singh and Umesh Nagdev, Security GBB

Link to Part 1

Link to Part 2

Umesh_Nagdev the references to Azure Sentinel and Azure Security Center use the old product names. They should be Microsoft Sentinel and Defender for Cloud.