The problem with managing AWS security groups
So you’ve got some security groups that you want to make changes to but unsure of where to start?
A good first place to start is to understand its associated resources.
Although most commonly used with EC2 compute instances, it is worth remembering many AWS services rely on security groups. Including:
- Lambda
- Elastic load balancing
- Databases (Amazon RDS, Amazon Redshift)
- Elastic Beanstalk
- Container and Kubernetes services (ECS and EKS)
Therefore it is best to run the following command in the AWS CLI as it will find all network interfaces associated with a security group based on the security group ID:
If the output is empty similar to this, then there are no resources associated with the security group:
If the output contains results, then use this command to find more information about the resources associated with the security group:
A solution with Overmind
Start by querying your security group ID.
Next double click the security group to expand the link depth and discover related resources and use the generated meta-data to understand without prior context.
From the graph above we can see that making any modifications to this security group will impact various other linked security groups and resources. This means we need to be careful to ensure that any changes will not have any unintended impact.
Security group dependencies
Dependencies are when a security group has been referenced by another in the inbound/ outbound rules.
One way to find this is out is by attempting to delete the security group, even if you don’t intend to remove it so you can get AWS to expose this information. However if you are not planning to remove this security group it would not be recommended to attempt to delete it just to find out this information.
Instead you could use this command to generate the Adjacency list (direct dependencies):
And then repeat this command for all possible users of the security group.
Using Overmind
You are able to easily spot any dependent security groups by seeing if they have any links between them and another security group.
Unused security groups
A best practice is to remove any unused security groups as they can create confusion and invite misconfiguration. There’s not really a ‘best way’ to do this and it can be common to run into errors when trying to remove these groups. This AWS support page goes into detail on how to troubleshoot them.
In the console
- Navigate to security groups and select all the security groups and click on actions
- Click on delete security groups.
- A popup will appear displaying that you cannot delete security groups that are attached to instances, other security groups, or network interfaces, and it will list down all the security groups that you can delete.
- Now you know all the unused security groups, so click on cancel and delete them separately.
Similarly to finding dependencies it is not always best advised to attempt to delete it just to find out this information.
With Overmind
After modifying security groups
It is best practice to monitor security group usage to both see if they are configured correctly and if there are any unused ones.
If you just have a few security groups, you can just use the AWS CLI or AWS API. It is recommended over AWS console as it can be quite tedious going through all the different resources and known to be error-prone.
AWS also offers another option in the form of AWS Firewall Manager which can be leveraged to help improve monitoring and visibility. However it comes with a subscription cost that will be added to your ever-increasing AWS bill in the form of monthly fees per region and requires AWS Organisations.
With Overmind
Overmind then queries the AWS API in real-time:
And you can do all this without any additional subscription cost.
Overmind is now available to try for free. Get started by signing up and creating an account here.