Serverless and Containers

The ability to seamlessly incorporate serverless technology, container technology, and microservice designs in AWS enables customers to build multiple levels of isolation for workloads. AWS services use multiple layers of security to achieve isolated operations. Many of the security features of services like AWS Lambda and AWS Fargate, while operating behind the scenes, are based on the functionality provided by capabilities of AWS services and features already discussed in this paper. For example, the set of security services and capabilities included with the EC2 Nitro architecture, VPC networking, and IAM, (e.g., ACLs, Security Groups, and IAM Policies) apply here as well.

AWS approaches logical isolation with its serverless service, AWS Lambda, and its managed container service, AWS Fargate, in a multilayered fashion. These layers start with bare metal instances, the same ones that any customer can provision, using the same underlying Nitro architecture and its security benefits that were previously discussed. Then, at a subsequent layer, there is the purpose-built lightweight virtual machine monitor called Firecracker which was created by AWS to securely manage containers and serverless functions. Firecracker functions as an isolated environment that provides secure runtime execution for serverless functions and containers. Lambda operates in EC2 as micro virtual machines (micro-VMs) and offers similar protections for logical isolation as other EC2 instances. Each function executes in a sandbox that is contained in the micro-VM. The sandbox offers secure Linux kernel isolation using cgroups, namespaces, seccomp, and other features. Additionally, techniques such as process jailing and static linking are used to securely isolate runtime. Firecracker presents multiple security features such as a simple guest model — in other words, a virtualized device model that presents a minimal surface area allowing just enough features for operation. These concentric levels of protection allow for rapid, fraction-of-a-second invocations while securely isolating the micro-VM to a customer account. The source code for Firecracker has been provided as open source to the community at large to support full transparency with its operational configuration and capabilities.

Customers can build their own logical isolation and separation practices tailored to their organization using capabilities such as serverless resources. For example, customers can build event driven architectures which have multiple automation focused use cases from incident response to fleet management. Lambda in combination with other AWS services, such as Amazon CloudWatch Events or Amazon EventBridge, AWS Step Functions, Amazon GuardDuty, and others to create new security capabilities. With these services, operations can be designed to auto-remediate security issues without the need for human intervention. For example, a finding in Amazon GuardDuty can be sent to CloudWatch Events which can then trigger a Lambda function to initiate a remediation activity, such as updating security groups, web application firewall, or changing IAM policies. AWS Step Functions and additional Lambda functions can be added to the workflow for more complex logic such as calling AWS Systems Manager to execute commands on an EC2 instance to capture or modify configurations. This concept can be used to build similar isolation practices that keep direct human access away from important workloads — something that would be highly difficult in a traditional on-premises environment. For more information, see the AWS Security Incident Response Guide.

AWS container orchestration service, Amazon Elastic Container Service (Amazon ECS), provides its own security separation and isolation properties whether you are using it to manage container services such as AWS Fargate or in a self-managed environment on EC2. Amazon ECS Task Definitions allows customers to define security functionality and isolation parameters using the security features of their own VPC. One or more containers can operate within prescribed constraints using an Amazon ECS Task Definition. A customer can define granular container communication rules because each task definition can receive its own elastic network interface in a customer VPC. This gives containers the same VPC network security features as seen in EC2 instances. Customers can apply IAM policies to each task furthering access and operational bounds for each container or sets of containers. Security and isolation mechanisms related to upstream functions such as a container registry are addressed with Amazon Elastic Container Registry (Amazon ECR). When a container is built or pulled, it is critical that protections are around those source images both as they are being housed and transmitted. Amazon ECR automatically encrypts container images at rest and in transit. Using IAM policies, access to images in Amazon ECR can be constrained to only the principals that have a need for that access. When used together, the suite of AWS container services creates an end-to-end isolated and secure environment for fleets of containers or microservices.  

AWS services offer customers with a growing list of capabilities to make security in the cloud robust and easy to implement while maintaining a high security bar. Ever expanding security services and features minimize cumbersome processes, improve confidentiality, and expand accessibility to democratize security and the benefits of modern techniques and innovation. Applying foundational security practices, such as encryption, with proper customer implementation can effectively address the security risks associated with the demand for physical separation.