Strategies for Securing Cloud-Native Workloads

Addressing Challenges in Cloud-Native Security

Containers, and to a lesser extent, serverless functions, have revolutionized how applications are built, deployed, and executed. Unlike virtual machines (VMs) with fixed OS parameters and configurations, containers allow developers to package OS components, significantly influencing the runtime environment. This shift means that much of the security posture is established during development. Additionally, the frequent use of open-source components can introduce vulnerabilities.

Containers and functions are deployed through high-velocity, automated CI/CD pipelines, often resulting in the daily release of numerous updated images with minor code changes. The microservices architecture, which packages services into containers and functions, transforms application networking. Instead of VMs, the networked entities are now functions, containers, and pods, creating a more dynamic and lower-level network environment.

These containers and serverless functions operate in highly orchestrated, non-predetermined environments. They can run across different clouds and on-premises, scale dynamically, and have brief lifespans with fluctuating networking requirements. These environments often use minimal “thin OS” Linux distributions, reducing the attack surface. Traditional security tools, however, lack the visibility and application context necessary to discern legitimate activities from anomalies.

One advantage of this setup is the elimination of runtime code patching. In a containerized environment, all changes flow from development to production, ensuring fixes are applied early in the development cycle rather than at runtime. This immutability enhances security by simplifying change control and anomaly detection.

To effectively address these security challenges, a comprehensive lifecycle approach is essential, starting early in development and continuing through deployment to runtime:

1. Integrate Security Early: Embed security into your build process, automate testing, and manage risks in container images and functions. Address known vulnerabilities, malware, excessive permissions, and poor configurations.
2. Control Image Integrity: Ensure that the images you run remain unchanged unless intentionally replaced.
3. Enforce Application Behavior: Use a whitelisting approach to enforce least privilege, enabling the detection of suspicious activities.
4. Segment Networks: Implement segmentation and firewalling between different services.
5. Manage Secrets: Properly manage secrets and their access by containers.

Grasping the Shared Responsibility Model

AWS provides a well-documented shared responsibility model for security and compliance. This model clearly delineates the security responsibilities between AWS and its customers. Often referred to as Security “of” the Cloud versus Security “in” the Cloud, it specifies where AWS’s responsibilities end and the customer’s begin.

Services categorized under Infrastructure-as-a-Service (IaaS) on AWS, such as Amazon EC2, primarily fall under the customer’s responsibility. Most cloud-native compute services on AWS also fit into this category.

In certain areas, the responsibilities are shared and need clear delineation. AWS provides the following examples:

• Patch Management: AWS is responsible for patching and fixing flaws within the infrastructure, while customers are responsible for patching their guest OS and applications.
• Configuration Management: AWS maintains the configuration of its infrastructure devices, whereas customers are responsible for configuring their own guest operating systems, databases, and applications.

AWS is clearly responsible for areas like physical and infrastructure security. Conversely, customers are responsible for everything they bring onto AWS infrastructure, including customer data, code, applications, and operating systems.

Shared Responsibility Model for Cloud-Native Workloads on AWS

Here is an overview of the division of responsibilities for key AWS services involved in running containers and serverless functions:

Scanning Images on Amazon ECR

As container images are built and stored in registries such as Amazon ECR, they can introduce risks to the entire application environment due to several factors:

• Known Vulnerabilities: Open-source components in various programming languages and OS packages can contain severe vulnerabilities, potentially allowing an attacker to compromise the entire host or cluster.
• Malware: This includes threats such as viruses and cryptocurrency miners.
• Hard-Coded Secrets: Developers often embed private keys or other sensitive information in images for testing convenience but may forget to remove them before deployment.
• Poor Image Configuration: Examples include allowing images to run with root access or as privileged containers.

To mitigate these risks, it is essential to scan and analyze container registries regularly to ensure that images meet your organization’s security and compliance criteria. It is recommended to scan Amazon ECR daily since new vulnerabilities can be discovered, rendering previously safe images unsafe. Automating this scanning process and analyzing the results will help maintain compliance and security standards.

Securing Workloads on Amazon ECS and Amazon EKS

Amazon ECS and Amazon EKS both offer orchestrated environments for running containers on virtual machine (VM) nodes. Amazon ECS provides a highly scalable orchestration platform, whereas Amazon EKS is fully based on upstream Kubernetes and is managed by AWS.

Best practices for securing ECS and EKS clusters include:

• Control Access: Ensure that access to services, including the orchestrator control planes, is governed by IAM roles. This helps prevent unauthorized access and potential security breaches.
• Deploy Trusted Images: Implement image assurance policies to ensure that only images meeting the risk policy are allowed to run. This minimizes the risk of running compromised or vulnerable images.
• Harden Node Operating Systems: Both Amazon EKS and Amazon ECS offer AWS-provided instances to run as nodes. However, if you choose to use your own OS on the node, make sure it is properly secured. This includes applying security patches, disabling unnecessary services, and implementing security configurations.
• Enforce Immutability: Since containers are intended to be immutable and should not be changed or patched while running, enforce this by ensuring that no new executables or configuration changes are added to a running container. This prevents unauthorized modifications and maintains a consistent and secure runtime environment.
• Behavioral Whitelisting: Containers may include unnecessary components, creating a large attack surface. Generate a behavioral profile of a container to whitelist only the resources it actually uses, making it difficult for attackers to manipulate containers. Limit access to files, volumes, network resources, system calls, executables, and privileges.
• Network Security: Segment container workloads using container-level firewalls to control network connections between containers and pods, as well as between containers and external sources/destinations. This isolates workloads and prevents lateral movement of threats within the network.
• Protect Secrets: Ensure that secrets used by containers are securely injected and accessible only within the container (not in the registry, on the node/host, or via the orchestrator control plane). Proper secret management prevents unauthorized access to sensitive information.

These measures can be implemented using AWS-provided tools. For more advanced controls, runtime agents running as side-car containers on the same node as the protected containers may be required. These side-car containers provide additional security monitoring and enforcement capabilities, ensuring that the containers adhere to the defined security policies and configurations.

Implementing these best practices will help secure workloads on Amazon ECS and Amazon EKS, providing a robust and secure environment for running containerized applications.

Securing Workloads on AWS Fargate

AWS Fargate is a serverless container environment that allows users to run containers without managing the underlying host infrastructure, which is fully abstracted and managed by AWS.

As a serverless service, Fargate’s infrastructure and security are managed by AWS. Therefore, the customer’s focus is on securing their workloads, specifically the contents of their containers.

The security processes required before deploying AWS Fargate containers are similar to those for other container environments: scanning images for vulnerabilities and other issues, ensuring only trusted images are deployed, managing secrets, and enforcing immutability.

The runtime security for AWS Fargate, however, differs because customers do not have access to the underlying host. The software used to monitor, detect, and control the actions of AWS Fargate containers must be deployed in one of two ways:

1. Embedded Security: Security measures can be integrated into the container during the image build, creating a self-protecting container. This approach requires changes to the image contents during the build phase but provides consistent protection throughout the container’s lifecycle.
2. Side-Car Container: Security measures can be run as a side-car container using AWS Fargate’s task concept, which allows multiple side-car containers to run alongside any application container. This approach does not require changes during the build phase but may lead to inconsistent protection throughout the lifecycle and can become complex to manage if multiple side-car containers are needed per application container.

Both methods have advantages and disadvantages. The embedded approach offers consistent protection across the entire lifecycle but requires integration during the build phase and modifications to the image contents. The side-car approach avoids the need for build phase changes but may result in inconsistent protection and more complex management when multiple side-cars are required per container.

Securing Workloads on AWS Lambda

Serverless functions hosted and executed on AWS Lambda introduce different security challenges compared to containers.

Functions are generally more lightweight and have fewer components, which simplifies their dependencies. However, their very short execution times, combined with external triggers or event-driven invocations, make it challenging to control how and when functions are run and to detect any real-time anomalies or suspicious activities.

The primary risk in using serverless functions lies in the code, which is the customer’s responsibility. Attackers might exploit vulnerabilities or excessive permissions within a function to gain access to other resources, such as Amazon S3 buckets.

To secure functions, it’s essential to focus on preemptive measures before the function is invoked:

• Pull and Scan: Regularly pull and scan functions for vulnerabilities, malware, and hard-coded keys.
• Limit Permissions: Ensure functions do not have overprovisioned permissions, such as administrative access or broad “wildcard” permissions.
• Monitor Usage: Track the actual permissions used by functions and compare them against their provisioned permissions. Remove any unused permissions to reduce the attack surface.
• Anomaly Detection: Monitor functions for anomalous behavior, such as excessively long execution times or more frequent executions than usual, to flag potential risks.

By focusing on these preemptive measures, you can mitigate the security risks associated with AWS Lambda functions.

Conclusion

In conclusion, securing cloud-native workloads on AWS necessitates a holistic and proactive approach. Containers and serverless functions, while revolutionary in their flexibility and scalability, present distinct security challenges that must be addressed from development through to runtime. By integrating security early, ensuring the integrity of images, enforcing strict application behaviors, segmenting networks, and managing secrets effectively, organizations can significantly bolster their security posture. Additionally, a clear understanding of the AWS Shared Responsibility Model helps delineate the roles and responsibilities between AWS and the customer, ensuring comprehensive protection of cloud-native applications. Implementing these best practices will help safeguard your workloads, allowing you to fully leverage the benefits of cloud-native technologies on AWS.

I hope you’ve enjoyed it and have learned something new. I’m always open to suggestions and discussions on LinkedIn. Hit me up with direct messages.

If you’ve enjoyed my writing and want to keep me motivated, consider leaving starts on GitHub and endorsing me for relevant skills on LinkedIn.

Till the next one, happy coding!