Microsoft Defender for Containers is a cloud-based solution designed to safeguard your containerized environments. It protects your clusters whether they’re running in Azure Kubernetes Service (AKS), Amazon Elastic Kubernetes Service (EKS) in a connected Amazon Web Services (AWS) account, Google Kubernetes Engine (GKE) in a connected Google Cloud Platform (GCP) project, or other Kubernetes distributions (using Azure Arc-enabled Kubernetes). Defender for Containers brings with it the three core aspects of container security, which are as follows:

  • Environment hardening: As stated previously, Defender for Containers safeguards your Kubernetes clusters regardless of whether they are operating on Azure Kubernetes Service, on-premises or infrastructure as a service (IaaS) Kubernetes, or Amazon EKS. Container Sentry offers ongoing assessments of clusters, delivering enhanced visibility into misconfigurations and supported with actionable guidelines to mitigate identified threats.
  • Vulnerability assessment: It also supplies vulnerability assessment for images stored in Azure Container Registry and Elastic Container Registry (ECR).
  • Runtime nodes and clusters protection: Alerts are generated by the threat protection system for both clusters and nodes, signaling potential threats and suspicious activities.

Let us now understand the Defender for Containers architecture diagram.

Defender for Containers architecture diagram

Defender for Containers is developed differently for each Kubernetes environment. The links in this section give you the detailed and updated architecture diagram for each Kubernetes environment.

Azure Kubernetes Service (AKS)

When safeguarding a cluster hosted in AKS, Defender for Cloud ensures a seamless and effortless process for collecting audit log data without the need for an agent. The deployment of the Defender profile on each node enables runtime protections and helps the collection of signals. For more comprehensive information, please consult the Microsoft documentation (https://learn.microsoft.com/en-us/azure/defender-for-cloud/defender-for-containers-architecture?tabs=defender-for-container-arch-aks#architecture-diagram-of-defender-for-cloud-and-aks-clusters).

Figure 7.1 – Architecture diagram of Defender for Cloud and AKS cluster (source: Microsoft)

Arc-enabled Kubernetes clusters

When a non-Azure container is integrated with Azure through Arc, the Arc extension collects Kubernetes audit logs from every control plane node within the cluster. Subsequently, the extension transmits the log data to the Microsoft Defender for Cloud backend in the cloud, enabling comprehensive analysis. Although the extension is associated with a Log Analytics workspace used as a data pipeline, the audit log data itself is not stored within the Log Analytics workspace.

For more details and updated information on this, refer to your chosen CSPM vendor documentation or, in this case, the Microsoft documentation (https://learn.microsoft.com/en-us/azure/defender-for-cloud/defender-for-containers-architecture?tabs=defender-for-container-arch-eks#architecture-diagram-of-defender-for-cloud-and-eks-clusters).

Figure 7.2 – Architecture diagram of Defender for Cloud and non-Azure cluster (source: Microsoft)

Security in containerized environments is of paramount importance due to the unique challenges posed by containerization. While containerization provides many benefits in terms of agility, scalability, and portability, it also introduces unique security challenges that need to be addressed.

Let us now look at common security risks and threats in containerized environments:

  • Isolation and vulnerability management: Containers rely on a shared host kernel, and if one container is compromised, it can potentially impact other containers and the underlying host. Therefore, ensuring strong isolation between containers and proactive vulnerability management is crucial to prevent lateral movement of threats and unauthorized access.
  • Container image security: Containers are built from images that contain the application and its dependencies. These images must be regularly scanned for vulnerabilities and validated to ensure they do not include any malicious or outdated components. Failure to secure container images can lead to the exploitation of known vulnerabilities and compromise the integrity of the entire containerized environment.
  • Runtime threats and monitoring: Monitoring container runtime is essential to detect and respond to security incidents in real time. It involves tracking container behavior, network traffic, and application activity to identify anomalies or malicious activities. Continuous monitoring helps in the timely detection of runtime threats, such as unauthorized access attempts, abnormal resource usage, or malicious code execution.
  • Compliance and regulatory requirements: Organizations working in regulated industries need to ensure their containerized environments comply with industry-specific security standards and regulatory frameworks. Failure to meet these requirements can lead to severe legal and financial consequences. Proper security measures, such as access controls, data encryption, and audit logs, must be implemented to maintain compliance.
  • Orchestration and configuration security: Container orchestration platforms such as Kubernetes introduce additional security considerations. Securing the orchestration layer, managing access controls, and enforcing secure configuration practices are vital to protecting the underlying infrastructure and preventing unauthorized access or manipulation of containers.
  • Complex networking: Containers are often dynamic, and their IP addresses may change frequently. Service discovery becomes challenging in a dynamic and distributed environment. Managing networking for containers can be complex, especially when dealing with multiple containers on different hosts that need to communicate with each other.
  • Resource overhead: Container orchestration tools, such as Kubernetes or Docker Swarm, introduce additional resource overhead to manage and coordinate container deployment, scaling, and load balancing. Running multiple containers on a host can lead to resource contention, such as container density requiring careful resource allocation to ensure optimal performance.
  • Monitoring: Monitoring containers poses challenges due to their ephemeral nature. Traditional monitoring tools may struggle to provide real-time insights into the state of containers. Containers require specific monitoring tools that understand container orchestration platforms and can track metrics such as container health, resource usage, and application performance.
  • Logging management and aggregation: Containerized applications generate a large volume of logs, and managing and analyzing these logs becomes challenging. Centralized log management solutions are crucial but can be complex to set up. Aggregating logs from multiple containers and services requires a comprehensive strategy to ensure that logs are accessible for debugging and auditing purposes.
  • Secure deployment pipelines: Security should be integrated into the entire container deployment pipeline. From the development stage to production deployment, each step should include security checks and measures to ensure that containers are free from vulnerabilities and adhere to security best practices. Implementing secure container registries, automated security testing, and secure image signing are critical aspects of a secure deployment pipeline.
  • Container escape and privilege escalation: Container escape vulnerabilities, though rare, have the potential to compromise the entire host system. Proper security measures, such as user namespace remapping, seccomp, and AppArmor, must be implemented to mitigate the risk of container escape and privilege escalation attacks.

Organizations are increasingly adopting cloud-native architectures to enhance scalability, agility, and cost-effectiveness as a result of the rapidly evolving digital landscape. They are leveraging containerization to enhance their application deployment processes. Containers offer portability, scalability, and agility, allowing businesses to accelerate software development and delivery. However, they introduce unique security challenges that must be addressed to maintain a strong security posture. With increased complexity comes the need for robust security measures to protect containerized environments from potential vulnerabilities and threats. Onboarding containers to a CSPM tool is a vital step in this process, enabling organizations to extend their security capabilities to containerized workloads and effectively mitigate risks.

In this chapter, we will delve into the intricacies of onboarding containers to a CSPM tool, equipping security professionals, cloud architects, and DevOps teams with the knowledge and skills needed to bolster container security within their cloud environments. Throughout this chapter, you will gain valuable insights and skills to effectively onboard containers to a CSPM tool.

Here are the main topics we’ll be looking at:

  • Containerization overview and its benefits
  • Understanding container security challenges
  • Onboarding containers to CSPM tools
  • Onboarding roadblocks and mitigation best practices
  • Most recent trends and advancements in container security in the context of CSPM

Let’s get started!

Containerization overview and its benefits

Containerization is a method of lightweight virtualization that involves the isolated packaging of an application and its dependencies into a self-contained unit called a container. Containers provide an isolated and consistent runtime environment, allowing applications to be easily deployed and executed across different computing environments, such as development machines, servers, and cloud platforms.

The process for offboarding cloud accounts from a CSPM tool is an essential step in maintaining the security and compliance of your cloud infrastructure. Here is a general process for offboarding cloud accounts:

  • Identify inactive or decommissioned cloud accounts: Determine which cloud accounts are no longer in use, have been decommissioned, or are otherwise no longer relevant to your organization’s operations. This can be based on input from IT and operations teams, account status, or business requirements.
  • Review account dependencies: Before offboarding a cloud account, assess its dependencies within the CSPM solution. Identify any connected resources, configurations, or associated data that may require migration or backup.
  • Plan the offboarding process: Create a clear plan outlining the steps involved in offboarding the cloud accounts. Include considerations such as data backup, resource migration, and access revocation.
  • Backup or transfer data: If there is any relevant data associated with the offboarding cloud accounts in the CSPM solution, ensure it is properly backed up or transferred to a suitable location for future reference or auditing purposes.
  • Terminate monitoring and alerting: Disable monitoring and alerting for the specific cloud accounts within the CSPM solution. This ensures that the CSPM platform no longer collects data or generates alerts for those accounts.
  • Revoke access and permissions: Remove the CSPM solution’s access and permissions to the offboarding cloud accounts, ensuring that the solution can no longer access or manage the resources within those accounts.
  • Update documentation and processes: Update any relevant documentation, procedures, or workflows to reflect the offboarding of the cloud accounts from the CSPM solution. Ensure that stakeholders are informed of the changes and any alternative monitoring mechanisms, if applicable.
  • Validate and verify offboarding: After completing the offboarding process, perform validation checks to ensure that the cloud accounts are successfully removed from the CSPM solution and that monitoring and management have ceased.
  • Decommission resources (if applicable): If there are any resources associated with the offboarding cloud accounts that are no longer needed, follow proper decommissioning processes to remove or delete those resources securely.

Remember that the specific steps for offboarding cloud accounts from a CSPM solution may vary depending on the solution itself and the cloud provider involved. Always consult the documentation and guidelines provided by the CSPM solution and the respective cloud provider for the most accurate and up-to-date offboarding procedures.

Summary

In this chapter, we explored the best practices and steps involved in onboarding cloud accounts to a CSPM solution. We discussed the importance of automating the onboarding process to streamline and expedite account setup. Additionally, we examined the deployment architecture for onboarding multi-cloud environments, considering the complexities and unique requirements of each cloud provider. We also delved into the challenges that can arise during the onboarding process and provided mitigations to address them. We explored the topic of offboarding cloud accounts from the CSPM solution and its significance.

The next chapter is focused on containers onboarding to CSPM tool. As containers are complex and vast in themselves, their onboarding aspects are discussed separately.

Further reading

To learn more about the topics that were covered in this chapter, take a look at the following resources:

Containerization has revolutionized the way applications are developed, deployed, and managed. Some key advantages include the following:

  • Portability: Containers possess remarkable portability, facilitating the consistent execution of applications across various operating systems, cloud platforms, and infrastructure environments. This inherent mobility effectively eliminates the pervasive issue of “works on my machine” and simplifies the deployment process.
  • Scalability: Containers facilitate the easy scaling of applications. They can be quickly replicated and distributed across multiple instances, allowing organizations to handle increased workloads efficiently. With container orchestration platforms such as Kubernetes, scaling applications becomes seamless and automated.
  • Resource efficiency: Containers are lightweight, consuming minimal resources compared to traditional virtual machines (VMs). They share the host operating system kernel, reducing the overhead associated with full OS virtualization. This efficiency enables higher density and optimal utilization of infrastructure resources.
  • Faster deployment: Containers provide rapid application deployment and release cycles. By encapsulating all dependencies within the container image, applications can be deployed consistently and quickly. This agility is particularly beneficial in modern DevOps and continuous delivery practices.
  • Isolation and security: Containers offer process-level isolation, ensuring that applications and their dependencies run independently of one another. This isolation provides enhanced security by mitigating the impact of potential vulnerabilities or exploits in one container or many. Container security measures, such as sandboxing and restricted access, further strengthen the overall security posture.
  • DevOps collaboration: Containerization fosters collaboration between development and operations teams. By providing a standardized environment, developers can package their applications with all required dependencies, ensuring consistent behavior throughout the development life cycle. Operations teams can then deploy these containers seamlessly across various environments.
  • Microservices architecture: Containers align well with microservices-based architectures. They enable the decomposition of complex applications into smaller, independently deployable, and scalable services. This modular approach enhances agility and fault isolation, and facilitates easier maintenance and updates.

Now that you understand what containers are and the benefits they bring, let us now understand the importance of security in a containerized environment.

Container escape is an exploitative technique in which an unauthorized individual gains entry to the underlying host operating system from inside a container. This illicit access enables them to breach the container’s isolated environment and potentially manipulate or access resources on the host system. If container escape is successfully executed, it can jeopardize the security of other containers residing on the same host and potentially compromise the entire infrastructure.

Despite these challenges, containerization remains a popular and valuable technology. Many of these issues can be addressed with careful planning, proper tooling, and ongoing management practices. To address these security challenges, organizations use various tools and practices, including container security scanners, CSPM solutions, runtime protection tools, network security policies, access controls, and security best practices tailored to containers.

How does CSPM address these unique security challenges?

CSPM addresses the unique security challenges introduced by containers through its holistic approach. It provides complete visibility into containerized environments, constantly monitors for misconfigurations, compliance violations, and vulnerabilities, and automatically enforces security policies. This proactive stance ensures that dynamic, short-lived containers are always configured securely. Additionally, CSPM integrates seamlessly with DevOps, promoting security throughout the development and deployment process, thus mitigating issues early. It offers real-time alerts and automates incident response, enabling quick reactions to security threats within containers. This combination of continuous monitoring, proactive configuration management, and integration into the development life cycle allows CSPM to effectively tackle the challenges of container security.

Now that we understand the unique security challenges of a containerized environment and how CSPM addresses these concerns, let us explore the onboarding aspects of containers to a CSPM tool.

Onboarding containers to CSPM tools

Onboarding containers to a CSPM tool refers to the process of integrating containers into the CSPM tool for enhanced security monitoring and management. The onboarding process involves configuring the CSPM tool to scan, assess, and protect containers against security risks and compliance violations.

Note

To make the concept easily understandable, the Microsoft Defender for Containers feature of the Microsoft Defender for Cloud tool is taken as a reference wherever it is imperative to explain with an example. There are many other tools available on the market that offer container security posture management features as well. The example chosen here is purely based on publicly accessible information.

At the time of writing this chapter, Defender for Containers support for Amazon EKS clusters is a preview feature. To receive the full protection offered by Microsoft Defender for Containers, the following components are needed:

  • Kubernetes audit logs
  • Azure Arc-enabled Kubernetes
  • The Defender extension
  • The Azure Policy extension

To understand the full concepts and updated information, read the Microsoft documentation (https://learn.microsoft.com/en-us/azure/defender-for-cloud/defender-for-containers-architecture?tabs=defender-for-container-arch-eks#architecture-diagram-of-defender-for-cloud-and-eks-clusters).

Figure 7.3 – Architecture diagram of Defender for Cloud and Amazon EKS cluster (source: Microsoft)

Google Cloud GKE cluster

At the time of writing this chapter, Defender for Containers support for GKE in a connected GCP project cluster is a preview feature. To receive the full protection offered by Microsoft Defender for Containers, the following components are needed:

  • Kubernetes audit logs
  • Azure Arc-enabled Kubernetes
  • The Defender extension
  • The Azure Policy extension

To understand the full concepts and updated information, read the Microsoft documentation (https://learn.microsoft.com/en-us/azure/defender-for-cloud/defender-for-containers-architecture?tabs=defender-for-container-arch-eks#architecture-diagram-of-defender-for-cloud-and-eks-clusters).

Figure 7.4 – Architecture diagram of Defender for Cloud and GKE cluster (source: Microsoft)

Once containers are onboarded, Defender for Containers receives and analyzes the following information to protect Kubernetes containers:

  • Audit logs and security events from the API server
  • Cluster configuration information from the control plane
  • Workload configuration from Azure Policy
  • Security signals and events from the node level

Now that you understand the architecture diagram of Kubernetes clusters along with Microsoft Defender for Containers, let us now understand how the onboarding of Kubernetes clusters works.

Enabling Microsoft Defender for Containers for Kubernetes clusters

Microsoft Defender for Containers is a feature bundled with cloud-native solutions through Microsoft Defender for Cloud for securing your Kubernetes clusters.

Let us now understand how it works in the case of Azure Kubernetes clusters.

Offboarding cloud accounts from a CSPM solution is an essential process to ensure the secure removal of cloud resources and associated monitoring from the CSPM platform. Every tool offers different ways to achieve this. Let us look at some scenarios that show why it is important to offboard the cloud accounts.

Importance of offboarding cloud accounts from CSPM

Offboarding cloud accounts from a CSPM tool is an important process that should not be overlooked for several reasons. Here are some key reasons why offboarding is important:

  • Security and compliance: When an organization no longer requires the monitoring and management of specific cloud accounts, it is crucial to remove them from the CSPM solution to avoid potential security risks and maintain compliance with relevant regulations.
  • Resource optimization: Offboarding cloud accounts helps optimize the resources utilized by the CSPM solution, reducing unnecessary costs and overhead.
  • Access control: By removing the cloud accounts from the CSPM platform, you ensure that only authorized personnel can access and manage those accounts, improving overall security.
  • Cost optimization: Many CSPM tools are subscription-based or incur costs based on the number of cloud accounts or resources they monitor. Failing to offboard unused or decommissioned accounts can result in unnecessary subscription fees or resource consumption, leading to increased costs.
  • Auditing and accountability: Organizations may be subject to audits or compliance checks, where they are required to demonstrate that inactive or decommissioned cloud accounts are properly managed and offboarded from the CSPM tool. Non-compliance can result in penalties or regulatory issues.

To ensure the ongoing effectiveness of your CSPM tool and maintain a strong security and compliance posture, it’s crucial to prioritize the offboarding of cloud accounts when they are no longer in use or relevant to your organization’s operations.

Roadblock #4 – Policy complexity

Defining and configuring complex security policies can be time-consuming and prone to misconfigurations.

Best practices are as follows:

  • Start with foundational security policies and gradually add complexity as needed
  • Leverage industry-standard templates for common policies
  • Use automation to simplify policy creation and enforcement

Roadblock #5 – Alert fatigue

Overwhelming numbers of alerts can lead to alert fatigue, where important alerts may be overlooked.

Best practices are as follows:

  • Customize alert thresholds and priorities based on the severity and business impact
  • Implement intelligent alerting that correlates multiple events to reduce noise
  • Use automated remediation to address common, low-level issues without generating alerts

Roadblock #6 – Integration complexity

Integrating the CSPM tool with existing security and operations tools can be complex.

Best practices are as follows:

  • Use pre-built integrations where available
  • Develop clear integration strategies and roadmaps
  • Engage with the CSPM tool vendor or consult with experts to facilitate integration

Roadblock #7 – Monitoring and alerting configuration

Configuring the monitoring and alerting features of the CSPM tool correctly can be daunting.

Best practices are as follows:

  • Consult with CSPM tool documentation and vendor support for guidance
  • Start with a small set of critical alerts and expand gradually
  • Conduct regular testing and validation to ensure alerts are functioning as expected

Roadblock #8 – Data privacy and security

Handling sensitive data collected by the CSPM tool can pose privacy and security concerns.

Best practices are as follows:

  • Implement data protection measures, including encryption and access controls
  • Comply with data privacy regulations (e.g., GDPR) and data retention policies
  • Conduct regular security assessments of the CSPM tool itself

Roadblock #9 – Compliance variability

Different cloud platforms may have variations in compliance standards and terminology.

Best practices are as follows:

  • Ensure that the CSPM tool can handle these variations and offer consistent reporting
  • Collaborate with compliance experts to align your policies and practices

Roadblock #10 – Scalability

The CSPM tool should be able to scale with your growing cloud infrastructure.

Best practices are as follows:

  • Choose a CSPM tool that can handle increased volumes of cloud accounts and resources
  • Regularly assess the performance and capacity of the tool to plan for scaling

Addressing these roadblocks and implementing the recommended best practices will help ensure a smooth onboarding process and effective use of a CSPM tool in securing your cloud accounts and resources.

Every CSPM vendor is on a journey to bring new features every day. It is part of the vendor assessment process to make sure that the vendor you are choosing has the capabilities to support all other cloud environments your organization is using. For example, as of today while writing this chapter, Microsoft Defender for Cloud supports Azure DevOps and GitHub environment (in preview) but no other cloud environments, such as Oracle Cloud Infrastructure (OCI) or Alibaba Cloud. However, you can still onboard your SQL servers, Windows servers, or any other workloads by installing Microsoft Defender for Endpoint agents to the workloads. Defender for Cloud can monitor the security posture of non-Azure computers, but first, you need to connect them to Azure.

The following are some links that you can refer to when onboarding non-Azure workloads to Microsoft Defender for Cloud:

Please refer to the Further reading section of this chapter to learn more about cloud account onboarding.

Let us now look at challenges and roadblocks that may arise during onboarding.

Onboarding roadblocks and mitigation best practices

During the onboarding process of cloud accounts to a CSPM tool, organizations may encounter several roadblocks. Let us understand these roadblocks one by one, along with mitigation best practices.

Roadblock #1 – Lack of necessary permissions

Obtaining the required permissions and credentials to connect cloud accounts can be challenging, especially in larger organizations.

Best practices are as follows:

  • Work closely with your cloud service providers to grant the necessary access
  • Clearly define and communicate the required permissions to relevant stakeholders
  • Use role-based access control (RBAC) to manage access more effectively

Roadblock #2 – Complex cloud environments

Multi-cloud or hybrid environments can be complex, with different configurations and security practices across platforms.

Best practices are as follows:

  • Develop a standardized approach for security policies and practices
  • Ensure your CSPM tool can support multiple cloud platforms
  • Create a comprehensive inventory of all cloud assets

Roadblock #3 – Resistance to change

Resistance from IT or development teams when introducing a CSPM tool can be a roadblock.

Best practices are as follows:

  • Communicate the benefits of the CSPM tool, such as improved security and compliance
  • Collaborate with teams to address their concerns and involve them in the onboarding process
  • Provide training to ensure that teams can use the tool effectively

copyright © 2024 skygravity.org