Remote Access Using SSH Cryptographic Keys
For new AWS accounts, default VPCs with subnets in every AWS region are created automatically. AWS does this to make it easy for new users to get started quickly; however it’s a nuisance to manage for your next account and every one after that. Most enterprise customers have dozens, if not hundreds of accounts, and default VPCs add complexity as they are automatically created in every region, have overlapping CIDR ranges, and assume public routing. Having default VPCs lying around creates risk that developers will deploy into the wrong region or will accidentally create public resources.
This post looks at how Turbot Guardrails can help enforce the removal of unneeded default VPCs.
Traditional Workflow
Most Turbot Guardrails customers have defined cloud networking requirements:
Specific approved regions that align to the corporate network (e.g. only us-east-1, eu-west-1 and ap-southeast-1).
Majority of workloads are internal facing, public workloads are the exception.
CIDR ranges are predefined per region, and allocated purposely per VPC to avoid overlapping CIDR ranges across the network.
Because default VPCs exist, we must decide how to handle them:
Delete all default VPCs and create custom VPCs in approved regions automatically?
Delete all default VPCs and create custom VPCs as needed?
A few services (like LightSail) require the default VPC, is an exception process needed for those services in some regions?
Keep the default VPCs, but remove Internet gateways and public routing to limit risk?
Leave in place, but clean up resources when discovered.
Our best practice recommendation is that customers delete all default VPCs and then recreate a template VPC in approved regions. Once you have made the decision that deleting default VPCs makes sense for your situation, taking action quickly will avoid more pain later trying to delete when resources are running those VPCs.
Get it done with Turbot Guardrails
Approved guardrails exist for every standard cloud resource in Turbot Guardrails. By changing the setting of “AWS > VPC > Default VPC > Approved” to “Not Approved” we tell Turbot Guardrails automation that no default VPCs are allowed to exist. Once Turbot Guardrails automation identifies a resource (e.g. a default VPC) as not approved, it has the ability to remediate it with complimentary corrective controls (or alert you with detective controls).
Create a new policy to force the default VPC key to “Not Approved”:
Create a new policy to take corrective action for resources that are in a “not approved” state:
After setting this policy, Turbot Guardrails automation will identify all instances that allow project wide SSH keys and then handle remediation (update the instance metadata to disallow project SSH keys).
After setting these policies, Turbot Guardrails automation will identify all default VPCs that are not approved, and then handle remediation (default VPC deletion). This setting is safe, even in enforcement mode, because AWS does not allow you to delete VPCs with resources deployed in them (even if that resource is just a security group). This means that even if you have some default VPCs in use, you can safely set Turbot Guardrails to clean default VPCs with the confidence that Turbot Guardrails will only raise an alert and be unable to take enforcement action until the offending resources are cleaned up.
Make it happen!
See for yourself how easy it is to remove default VPCs with just a few clicks. A ready-to-run Terraform template is available to enable this configuration from the Turbot Development Kit (TDK). If you need any assistance, let us know in our Slack community #guardrails channel. If you are new to Turbot, connect with us to learn more!