ACM.73 Thinking through serverless network architecture
This is a continuation of my series of posts on Automating Cybersecurity Metrics.
I covered network access for developers for our batch job development and deployment in the last post.
Network Design: Developer Network
In this post I am going to cover some considerations for serverless application networking.
Earlier in this series I provided scripts to deploy a VPC and related networking in an automated fashion. Those posts start here:
We left the networking rules for our Lambda functions blank to be implemented at a later point. Here are some of the things we’ll need to consider.
Private Batch Job VPC
My plan is to deploy batch jobs to a separate production account where they will execute with restricted permissions in a completely automated manner. When designing the network, we could have put our batch jobs and related lambda functions in the same VPC as our developer subnet for development purposes, but then our network would not mirror the way I want to deploy my batch jobs in production. I wouldn’t be able to use the same templates to deploy my networks to dev, QA, staging, and production.
I know that in production the batch job resources will be in a separate account which obviously means they will be in a separate VPC, so I’m going to create a separate VPC for those resources and make it private. We actually already did that in prior posts, but we need to complete a few more things before our Lambda function will be restricted from the Internet, yet able to access the resources they need.
Private Link for resources in our private batch job network (no NAT)
Since the batch job VPC is private, the resources in that network will not be able to reach the Internet or other AWS services that require Internet connections. I could set up a NAT to allow the resources in that private network to reach AWS services, but we’re going to take a look at Private Link instead and see if we can get that to work. I covered Private Link briefly in the last post.
One of the things I’ll need to do is allow a Lambda function to reach SSM Parameter store as I showed you earlier from a private network. I imagine we’ll also be access AWS S3 buckets and other resources for which we want to keep traffic on the AWS network.
AWS-managed prefix lists
We may need an AWS-managed prefix list at some point to access AWS services in our network rules. These prefixes can be used to get the IP ranges for AWS services.
Work with AWS-managed prefix lists
AWS also provides the IP addresses for AWS services here:
As you can see it is not always that fine-grained. In order to use it you would need to constantly be evaluating the list and updating your rules based on CIDRs whenever the list changes. A prefix will maintain that relationship for you.
Inbound Internet Traffic for Lambda Functions in our Batch Network
What if you want to assign a static IP address to a Lambda function? I explained what EIPs (elastic IPs) were in the last post. They allow you to reserve and assign a static IP address that doesn’t change which you can then use in firewall rules. Put your Lambda function that requires a static IP address behind an Elastic Load Balancer (ELB) and assign an EIP to the load balancer.
We can also use the ELB in a public network and have it send traffic to a Lambda function in a private network. That may come in handy later. I haven’t decided yet.
We could also front a Lambda function with an API gateway if we wanted to expose APIs for external use. I don’t forsee a need for that in the immediate future for what I am building in this series.
Outbound Internet Traffic for Lambda and Batch from a Private Network (such as to GitHub)
I already showed you some risks related allowing outbound traffic for Lambda functions in this post:
If we do end up needing to allow our Lambda functions to call an external API (e.g. something on GitHub) then we could use a NAT to allow that external access.
We can associate an EIP with the NAT gateway to allow it to access GitHub.
Of course, if we have a lot of resources using that NAT gateway that would be a risk. We’ll likely want to have a NAT gateway just for the purpose of accessing GitHub so we don’t inadvertently allow someone else to change our code. This is one of the security controls that can help us prevent attacks such as those that affected Solar Winds:
SolarWinds Hack: Retrospective
Separate networks for resources that indirectly require Internet access
I’m going to break up my subnets in my private Batch VPC into at least the following subnets:
NAT subnet (public): The NAT, if we were hosting it, would be in a separate subnet. That may be handled by AWS.NAT-Access Subnet (private): Even though some resources will be in a private network they may require access to the NAT for outbound Internet Access.ELB subnet (public): We will deploy ELBs in their own subnet as they have Internet Access (unless we front them with an additional security appliance).ELB-Access Subnet (Private): Other resources may require access inbound via an ELB. We will put them in their own Subnet.Private Data Subnet: Certain other resources will never need access to or from the Internet even indirectly. This is where the most sensitive data will be accessed and will remain completely segregated from even indirect access.Remote Access Subnet: We’ve got our developers using virtual machines in a separate network so they will get their own remote access subnet. To simplify our network we’ll use separate security groups for RDP and SSH but a single subnet for both protocols.
It could be that when we get further along into our design we decide we need additional or less subnets but that’s currently what I’m thinking we need. If you look at what I’ve designed it is similar to a three tier network: Web tier — App tier — Data tier.
VPC Peering
Since I’m planning to deploy my production batch jobs in a separate account ultimately, we’ll put the batch jobs in their own VPC. If we need to allow the developers to connect to the batch jobs or Lambda function in that separate account and VPC we’d need to set up VPC peering for that. We’ll see if we need to do that or not in future posts.
If we think through this a bit, developers might need to access Lambda functions or Batch jobs in a development environment. The QA team might need to access them in a QA environment. An Ops team might access them in a production environment. We’ll see if we need all that but we would want to create our deployment scripts to support that model, if required.
Separate security groups for all resources for a zero-trust network
We may end up creating broader security group rules in some cases, but we’ll always create a separate security group for each resource unless they require exactly the same network access.
Batch Network: ELB Subnets
We might need a public and private ELB subnet as explained above. In this case, we would associate a public route table with the ELB subnet and a private route table for the subnet that has resources accessed through the ELB. We could use any port for communication between the ELB and the resources it interfaces with in the private network so I am leaving that TBD or now.
Batch Network: NAT Subnets
The NAT subnets look similar but the direction of traffic is reversed. We don’t need a NAT for updates at this point since we will pull resources into our developer account and then deploy from there. All our resources will be deployed via code so we don’t need to have resources go get updates on the Internet. We don’t yet have a resources that needs to reach out over the Internet but we may in the future. We’ll deploy this if and when we need it.
Batch Network: Private Data Subnet
Now here’s the interesting thing. I mentioned we want to create a private VPC for our Lambda functions and Batch jobs. However, as I look ahead at the configuration of AWS Batch I only see this option to add a public IP address or not when using a non-Fargate deployment.
If you’re using Fargate you can assign subnets but I don’t see a place to assign security groups:
It is interesting that you can assign a public IP when using Fargate even if there is no Internet Gateway. In that case would Batch jobs be able to access the Internet??
We’re going to need to explore what kind of network connectivity and logs we get when we start using AWS Batch, but for now we’re going to just create the network infrastructure defined so far and keep moving forward. Sometimes AWS adds new capabilities to lock services down to private networks later after the service is initially released. I haven’t explored Batch in enough detail (yet) to fully understand our options for networking.
For now we will a completely private network, and we will create a security group per Lambda function as we started doing. We’ll update our Lambda configurations to run in a VPC. We will add a VPC Endpoint configuration that allows our Lambda functions to access whatever services they need to access.
That seems like it will work. We’ll have to complete our POC and do some additional testing. I suspect we will need to add some additional network constructs along the way. Follow for updates.
Teri Radichel
If you liked this story please clap and follow:
Medium: Teri Radichel or Email List: Teri Radichel
Twitter: @teriradichel or @2ndSightLab
Requests services via LinkedIn: Teri Radichel or IANS Research
© 2nd Sight Lab 2022
All the posts in this series:
Automating Cybersecurity Metrics (ACM)
____________________________________________
Author:
Cybersecurity for Executives in the Age of Cloud on Amazon
Need Cloud Security Training? 2nd Sight Lab Cloud Security Training
Is your cloud secure? Hire 2nd Sight Lab for a penetration test or security assessment.
Have a Cybersecurity or Cloud Security Question? Ask Teri Radichel by scheduling a call with IANS Research.
Cybersecurity & Cloud Security Resources by Teri Radichel: Cybersecurity and Cloud security classes, articles, white papers, presentations, and podcasts
Network Design: Serverless Applications was originally published in Cloud Security on Medium, where people are continuing the conversation by highlighting and responding to this story.
