By: Jeremy Pedersen
It's time to start getting deeper into a subject I have mostly avoided: cloud networking.
Don't get me wrong: I love networking, it's a fascinating subject! It's just so...big.
To make things simpler, I'll be breaking this subject down in a multipart series. Why? Because networking is complicated and there are way too many networking tools to fit into one blog post!
There are generally three classes of networking tools on Alibaba Cloud:
Today we will be focusing on the first area: public Internet connections. Specifically, I want to talk about routing and security. How can you decide which systems are Internet accessible and which ones are not? More importantly, how do you enforce it?
Before we can talk about connecting things to the Internet, we have to talk about VPCs, or Virtual Private Clouds.
The VPC serves as the network foundation on which other Alibaba Cloud services depend. Except for some services that are always designed to be accessible via the Internet (like Object Storage Service, most Alibaba Cloud services will need to connect to a VPC group to function. This includes things like virtual machines (ECS instances), databases (RDS instances), and load balancers (ALB and CLB instances).
Today, I want to focus on how things within the VPC connect to the Internet, and how you can control that access.
This makes controlling Internet access something you can do at the VPC level:
Simple! This makes it easy to create fully private VPCs, fully public VPCs, and VPCs where some subnets route to the Internet and some do not.
Sadly, this is not how it works on Alibaba Cloud.
We can see this just by taking a glance at the routing tables for an AWS VPC and an Alibaba Cloud VPC.
The AWS VPC:
The Alibaba Cloud VPC:
Notice that the AWS VPC has an explicit route to the Internet gateway (plus another local route for traffic between subnets), whereas the Alibaba Cloud VPC only has routes for its three subnets (called VSwitches) and one route for Alibaba Cloud internal services.
Bottom line: Alibaba Cloud VPCs don't have an internet "route", because by default all Alibaba Cloud VPCs allow connections to the Internet!
This is a pretty major difference that can trip up experienced AWS users.
This means that on Alibaba Cloud, controlling Internet access is about controlling the ability to create public IP addresses, not the ability to control VPC routing tables.
We'll dive deeper into how this works in the next few sections.
We'll focus on ECS instance Internet access for now, saving other services for a future blog post.
Essentially, there are four ways an ECS instance can reach the Internet.
Let's look at each of these in turn, and see what we can do to restrict access in each case.
The ECS API breaks the ECS instance creation process into two API calls:
Creating a RAM Policy that Denies
AllocatePublicIPAddress will prevent a user from binding a public IP to new ECS instances.
Note: This is not enough to guarantee that an ECS instance can't reach the internet. We've still got to worry about NAT Gateways, Elastic IPs, and Load Balancers! Read on.
Simply making sure a user can't call
AllocatePublicIPAddress isn't enough to guarantee that an ECS instance isn't granted a public IP address, because Elastic IPs are bound to ECS instances through a separate set of API calls.
Making sure a user cannot create and bind EIPs would require also restricting access to the EIP service. At a minimum, your RAM policy would need to restrict access to make the following API calls:
It would probably be wise to restrict the ability to unbind and delete EIPs as well, for those users who do not need that level of access.
This takes care of direct access to the Internet. But what about indirect access via a NAT Gateway or Load Balancer?
Restricting ECS permissions won't prevent an ECS instance from being added to a load balancer's backend server pool, but we can restrict the ability of a RAM user or RAM role to:
How this is done will depend on whether we're talking about Application Load Balancer (ALB) or Classic Load Balancer (CLB). The load balancer API reference tells us which API calls we'd need to restrict.
Writing a custom RAM policy for this is left as an exercise for the reader!
Setting up a NAT Gateway gives you a lot of control over which ECS instances can reach the Internet (and which instances are reachable from the Internet as well).
NAT Gateways allow you to create two types of rules:
SNAT rules can be configured to allow outbound traffic for:
This means you can use NAT Gateway to create a VPC that contains "public" and "private" VSwitches (a VSwitch is a network subnet), just by controlling the SNAT rule configuration.
So long as you are careful to restrict RAM users (so that they cannot create EIPs, bind ECS public IPs, or alter NAT rules) then you can exercise complete control over which parts of your VPC have Internet access, using this approach.
DNAT rules also give you a convenient way to expose a particular private IP address to traffic from the Internet. For instance, if you need to gain access to an ECS instance from the Internet for administrative tasks, you could create a DNAT rule that forwards traffic on port 22 (SSH) to a particular private IP inside your VPC.
The NAT Gateway documentation is a good source of configuration examples.
What if you want to put rules in place that can further restrict public Internet access, even when instances have been granted a public IP address? There are two ways:
Setting strict outbound security rules is one potential way to limit Internet access for ECS instances, even if they do have a public IP address:
CreateInstancepermissions, you need to make sure they aren't able to create a new Security Group at ECS instance creation time (which would circumvent your Security Group rules)
This method gives you stateless, VSwitch-level control over exactly which IP address ranges are accessible to an ECS instance, no matter how its network interfaces are configured.
Better, since these settings apply at the VSwitch level, users who do not have permission to access VPC settings cannot circumvent them, even if they have permission to create ECS instances.
That last point is a critical one: since Network ACL doesn't work for all instance classes, a user can create an ECS instance from a class that doesn't support Network ACL, which will result in any Network ACL rules you have created failing to take effect for that instance.
Restricting Internet access in an effective way requires a combination of active measures to:
But you can go further than this and adopt passive and corrective measures. For instance, creating a set of Cloud Config rules that can check for open Security Groups or instances which have been granted public IP addresses.
Tip: Using a three-pronged strategy (limit egress points, restrict traffic flow, and check for configuration changes) is the best way to guarantee only the traffic you want to allow is reaching the Internet.
That's it for this week, see you next time!
Great! Reach out to me at
firstname.lastname@example.org and I'll do my best to answer in a future Friday Q&A blog.
You can also follow the Alibaba Cloud Academy LinkedIn Page. We'll re-post these blogs there each Friday.
Alibaba Cloud Community - May 13, 2022
JDP - October 8, 2021
JDP - March 17, 2022
JDP - May 14, 2021
JDP - February 10, 2022
JDP - April 1, 2021
Respond to sudden traffic spikes and minimize response time with Server Load BalancerLearn More
A public Internet gateway for flexible usage of network resources and access to VPC.Learn More
An independent public IP resource that decouples ECS and public IP resources, allowing you to flexibly manage public IP resources.Learn More
A cloud solution for smart technology providers to quickly build stable, cost-efficient, and reliable ubiquitous platformsLearn More
More Posts by JDP