By using AWS re:Post, you agree to the Terms of Use

Allow Listing in AWS Security Groups

6 minute read
Foundational
3

Learn three easy methods to allow access to your resources via Security Groups.

One of the questions from the episode mentioned above was how to allow list specific IPs or general access to a security group on EC2 so that only certain people could access an environment. This is a pretty common task for most users in AWS as you'll need to grant access to your EC2 instances, and other AWS resources to allow access for users or other services. There are a few different ways to accomplish this and this article aims to guide you to be able to implement this in your AWS account. We're going to highlight three different methods for allowing traffic to a Security Group, each one is broken down below.

Method One: Allowing IP address ranges directly Allow Listing by IP

In the above image we can see that we have few different IP addresses individually added to the security group. Whatever we enter for IP addresses and ranges of IPs is going to be allowed to access this resource. It's important to accurately scope access to your site so it may be helpful to quickly covers some CIDR notations to assure you are aware of what each noted IP ranges above mean.

We can see a notation of x.72.30.245/32 in the first line. Anything with a /32 noted after it, is going to be one single IP address allowed to the security group. We can expand access by changing that notations tot he appropriate range of IPs for our users. This could be a remote site where we have users that need access to our environment over a VPN. Those users might sit on a VPN network of 10.10.0.0 that we need to allow into our environment, rather than list every IP address with a /32 we can instead open it to the entirety of a network as needed by changing the /32 to a /24 to then allow all 256 IPs of that network access to the resources over listing one by one. This approach works well for security groups where access will be limited to just a few IP ranges, and management can be controlled on who uses that security group. If you're dealing with resource access inside AWS, you may want a different approach and that leads us to method two.

Method Two, Allow Security Groups access:* Security group to security group allow

In the above image you can see we have access to 0.0.0.0/0 in the allowed as well as the IPv6 annotation for the same range. If you're not familiar this is the range to allow everything into the security group as 0.0.0.0/0 means allow any an all IPv4 addresses. If we're trying to scope down access and allow only certain AWS resources to the environment we'll need to remove that, and replace with the appropriate IP ranges, or if we know that the resources will all be attached to one particular Security Group we can add a notation that says allow traffic from a specific Security Group ID to access the AWS Resources. Much like adding an IP address range we simply chose the protocol we want to allow and then in the Source option we instead can start typing sg- and get a populated list of Security Groups I can then allow access. This is helpful when the Security Group is in a VPC and may have multiple IP address ranges attached it and you just generally want to allow that group of resources to access your environment. You can also reference a Security Group in itself to allow access for all resources in the Security Group to access itself. This is also helpful if you have resources in a VPC such as 172.16.0.0/16 and not all resources in that IP range should access this environment, you can use the sg- group ID to more specifically scope within a subnet.

Method Three, Create a prefix list, and grant it access: Security Prefix list allow For our third method, we're going to talk about the prefix lists option. This is a great option if you have a large number of remote sites in this case to allow access to your AWS resources. You can create a re-usable set of IPs with descriptions in a prefix list and then assign that as the allowed resource in a Security Group as shown in the above image. This will allow you to define a prefix list group such as Remote Sites, where you can enter in all of your remote office locations, that will need access to your AWS environment. In this prefix list you can add the CIDR notations such as 172.10.0.0/24. 192.168.0.024 and 10.10.0.0/24 into the list as well as more. And then from within the security group, you can just reference the prefix list by typing pl- and see the list of available Prefix Lists to chose from. This avoids you having to create multiple lines into the security group allow lists and also centralizes management of the remote sites IPs. This way when you add a new site, you don't have to remember to add it to every Security Group, but instead you can just update the Prefix List and it will update the access on every Security Group references the pl- identifier.

This was a short and quick explanation of the ways you can provide access to your resources in AWS. If there are additional questions about how to grant access, please feel free to post them here on re:Post and one of the AWS Experts here will be happy to help out. Checkout the video linked at the top of the article to get more details on setting up a prefix list and see what other questions we answered during the episode.

Please make sure to check out the AWS Supports You program page located here: https://awssupportsyou.splashthat.com/ Sign up to get notified of upcoming episodes!

4 Comments

Is method two applicable for VPC's connected via TGW?

replied 18 days ago

That's an excellent point @E Gabrielli. Being able to reference like that is another very helpful way of allowing access.

profile picture
EXPERT
replied a month ago

@PK might be helpful to take a look here: https://docs.aws.amazon.com/vpc/latest/tgw/tgw-vpc-attachments.html You wouldn't be able to reference them across the attachments

profile picture
EXPERT
replied 17 days ago

Just a little add-on: you can reference a Security Group in another account (provided there is a properly set cross account communication via VPC peering for example, of course) prefixing the account ID followed by a slash to the SG id itself: 12348154634/sd-4a5db84b76.

Maybe it's a 4th way or just a variant on the 2nd one :)

profile picture
replied a month ago