Aspects of Serverless Security: Networking

Networking in serverless solutions, and by networking I mean VPCs, Subnets, Security Groups etc, and all the configuration that goes with them, is an important aspect of security to consider. Unlike other AWS compute services, such as EC2, it is possible to provision most serverless services, such as Lambda and API Gateway outside of a user-managed VPC, in fact this is the default configuration for Lambda functions, and API Gateway. For APIs this means that they will be accessible to the public Internet, and for Lambda functions means they have unfettered access to the Internet. This obviously has serious security considerations and implications in most cases.

In this blog I discuss networking configuration for serverless, how and why user-managed networking can improve security for serverless applications, and also an example of how to set up serverless components within a VPC, and some of the considerations that go along with it.

Networking for serverless

As I previously mentioned, networking for serverless applications uses the same services and features as for any other kind of application in AWS; VPCs, Subnets, NACLs, Security Groups etc, so the good news is that any knowledge you already have of these is completely transferable.

This post is mostly concerned with two of the main services used in serverless applications running on AWS, Lambda, and API Gateway.

Lambda

Lambda functions can now easily be provisioned in a customer-managed VPC. This is very simple and just requires specifying which VPC and Subnets the function should be provisioned into (as with any resource on AWS at least two subnets, in different availability zones should be chosen to maintain the availability of the function in the result of an availability zone failure).

The only other resource required is a Security Group for the Lambda function. This acts as a firewall and restricts both inbound and outbound traffic to and from the function by either IP address range, or Security Group.

API Gateway

It is also very easy to provision a private API Gateway API. This simply involves selecting the ‘Private’ endpoint type when creating the API. It is then provisioned into a VPC that has no inbound access from the public Internet. It is not possible to place the API directly into a customer-managed VPC so instead access from your VPC/s to the API must take place through an Interface VPC endpoint. This endpoint can also be used as a Security Control, Interface VPC Endpoints allow the attachment of a policy to allow and deny traffic based on where it is coming from. A typical use case could see traffic to the endpoint, and therefore the API, restricted to a single VPC.

Security Benefits

Networking Security Controls

The benefits of hosting your serverless applications inside a VPC are obvious, you gain the benefits of all of the excellent controls that AWS provides to manage network traffic.

Protection from the Public Internet

The biggest benefit of this is that you are able to prevent your applications from being publicly accessible. Having applications directly accessible to the public Internet is, of course, a major risk, and provides many attack vectors for a person wishing to compromise an application or its data in some way.

Controlled Public Access

Whilst some applications are only needed to be accessed internally within an organisation, and so can be completely cut off from the internet, others do need to be public-facing. Networking can be extremely useful here as well. It can help to make sure that access to application components is done in a controlled way, i.e. through a network configured access point, such as a public-facing load balancer.

Egress Control

A slightly less obvious benefit is the ability to use networking controls to limit egress traffic. A lot of thought is often given to ingress access to applications but compromises can also result from too little control over outbound access from application components. Networking controls, such as Security Groups and NACLs, also allow a high degree of control over this type of traffic.

Traffic Analysis

Introducing networking controls also allows for traffic analysis of network traffic that is flowing in and out of the VPC. This is typically done by enabling VPC flow logs and streaming them into a threat detection or security information and event management (SIEM) system. This can help to identify unusual access and access patterns, and possible security breaches.

Access to other VPC resources

For Lambda functions to access resources, such as EC2 instances, and RDS Databases, that must reside in a VPC, there are two main options available. The first is to make those resources publicly accessible, which is usually highly undesirable. And the second is to provision the Lambda function into the same VPC, or one that has access to the VPC the resources reside in. From a security standpoint the second option here is obviously the far superior choice.

Least Privilege

Finally, network controls in AWS allow you to define access patterns and better follow the security principle of least privilege using things like Security Group and NACL rules, and Routes in Route Tables to provide the access that is needed but no more than that.

Other Considerations

Complexity

Obviously, introducing networking also introduces the need to configure and manage that networking, something that is managed by AWS to a large degree if your resources are a customer-defined network. This comes with added complexity. You likely need to configure NACL rules, Security Group rules, Route Tables, CIDR Ranges and other networking components in order for the application components to be able to communicate with one another. This is not a small undertaking and so should be considered carefully.

Scaling

Scaling is another issue. Lambda functions that are invoked very frequently need to be run concurrently, this involves multiple network interfaces being spun up to manage this. As each network interface consumes a private IP address in the subnet it is provisioned in, it is possible for a Lambda function, or functions, to quickly use up all IP addresses within the range assigned to a subnet. As it can be very difficult to resize a subnet after-the-fact it is important to provision a large enough CIDR range to deal with large spikes in traffic.

Examples

To show how networking can be used to configure networked serverless components I have included a couple of examples. The CloudFormation templates for both of these examples are publicly available at https://gitlab.com/serverless-starter-packs/serverless-networking if you wish to spin up the infrastructure for yourself.

Networked API Gateway and Lambda Function

The first example, shown above, illustrates a very basic architecture in which private networking is enabled for a Lambda function and an API Gateway API. This consists of a VPC that has no route out to the public Internet, and two subnets in different availability zones.

The Lambda function is provisioned into both subnets, and has an attached Security Group that is used to define inbound and outbound networking access rules to and from it.

The API Gateway API is created with an Endpoint Type of ‘Private’. When this option is selected, the API is provisioned in an AWS-Managed VPC that has no access from the public Internet. What this means is that requests must be routed to the API through an Interface VPC Endpoint.

In this example, the required VPC endpoint has been configured in both of the VPC subnets. This means that any client that resides in the VPC (EC2 instance, Lambda function etc) can make requests to the API using its private DNS name. The API will then invoke the connected Lambda function in one or other of the subnets.

In the CloudFormation template provided, for simplicity, the Lambda Security Group and VPC Endpoint allow all traffic, but it is easy to see how they could be used to restrict network traffic effectively.

Egress Lambda Function

The other example, shown below shows how, using networking security controls in AWS, a Lambda function can make requests out to the public internet, but only to the specific IP ranges it needs to, limiting the possibility of exfiltration of data.

The example consists of a VPC with one public, and two private subnets, with the private subnets each in separate availability zones. As a private subnet, by definition, has no route to the public internet a route out is required for requests from it to reach the Internet Endpoint.

This is achieved using a NAT Gateway. The NAT Gateway sits in a public subnet, in practice it is recommended to have at least two NAT Gateways spanning multiple availability zones so that the solution can tolerate the failure of a single availability zone.

The private subnets that host the Lambda functions have an associated Route Table with a Route that directs traffic bound for the public internet to the NAT Gateway. That traffic is then directed to the Internet Gateway and out to the internet using a Route Table that is associated with the public subnet.

There are a few different points in this architecture where traffic could be restricted from the Lambda function out to the Internet, they are:

1. The Lambda function Security Group — Security Groups contain egress rules which define, using IP address ranges, port ranges, and protocol types, which traffic is allowed out from the Lambda function.
2. Subnet NACL Rules — NACL Rules define, again by IP address range, port, and protocol which traffic is allowed in and out. The boundary of a NACL is at the edge of a subnet, so they can only restrict inter-subnet traffic, but this more than meets the requirements here. NACLs are also stateless, meaning separate ingress and egress rules must be defined to allow a request to be made and a response to be successfully returned from that request.
3. Route Tables and Routes — While not strictly a security control, Route Tables can be used to restrict traffic. For example, in the below architecture, if you wished for the Lambda function to only make requests to public endpoints at the IP address 1.2.3.4 you could define a Route in the Route Table used by the Private subnets for only that IP address to be sent to the NAT Gateway. In that situation, all other traffic would be dropped because there would be no place to route it to.

In the CloudFormation template I have provided in the repository linked earlier in this post, the only restriction I have put in place is a Security Group egress rule. That rule allows egress traffic to a single IP address and means that all other egress traffic is denied.

Conclusion

In conclusion, serverless certainly doesn’t mean network-less, and networking should be given serious consideration when designing and developing serverless applications. Networked Lambda functions and API Gateways are not the right choice in all cases.

Using networking features and controls available in AWS give you the ability to vastly improve the security posture of your applications and services but does come at the cost of added complexity.

Finally, like with more traditional, server-based applications a defence in depth approach to security is recommended, so Security Groups should be used in conjunction with NACLs and other controls that aren’t covered by this post, such as AWS Web Application Firewall (WAF).

I encourage you to use the templates I have provided, and try to add other security controls to further improve security in these examples!