Introduction
It is possible in AWS to check if your environment is compliant to your minimum standards. It is also possible to automatically change the environment to make it compliant again. Maybe not in a way that was designed by the developer – but compliant anyhow. Let me give an example what I mean by this.
Security Groups restricting inbound traffic to SSH port 22
We all know the best practices, don’t we? One should never ever put port 22 open to the world. But hey, we’re human – everyone forgets the standards on one moment or another. Fortunately, AWS Config can see that this happened and it is also possible to change the security group automatically. This can be done by deleting all inbound and outbound rules to and from the security group. I already said that this is a rather drastic approach which is probably not what your developer expects. But the result is that our environment is compliant again.
AWS Config doesn’t change the inbound and outbound rules of the security group itself. It asks Systems Manager (SSM) to do that for AWS Config. And this is what became confusing for me.
Let me show this in the AWS Config screen. When you never used AWS Config before, go to the AWS Config service and click on “Get started”:
All the default settings are fine, click “Next”:
In the rules screen, search for “ssh”, select “restricted-ssh” and click next:
In the confirmation screen, click “Confirm”. Click the welcome screen away, and go to “rules” in the left menu. Select restricted-ssh and in the menu under “Actions” click on “Manage remediation”:
Select automated remediation, search for “security group” in the “Remediation action details” and select “AWS-CloseSecurityGroup”:
So far so good. Scroll a little bit down, and under Parameters, click in the checkbox behind “SecurityGroupId”. Under Resource ID parameter, select “SecurityGroupId”. It should look like:
This means, that when a security group is found where SSH is allowed for the whole internet, then this security group will be changed so all inbound and outbound rules are removed. There is just one parameter to fill in: “AutomationAssumeRole”.
IAM role
And this is where it became a little bit messy. We are using remediation in AWS Config, we ask SSM Automation to execute AWS-CloseSecurityGroup:
So the IAM Role that I expected was a role where I would grant AWS Config the permissions to invoke a task within Systems Manager. I couldn’t configure this in IAM: when I tried to create a role in IAM on behalf of AWS Config, there was just one option: I had to accept the AWS managed role AWSConfigServiceRolePolicy:
And this role doesn’t have permissions to start anything in SSM:
In the end, I connected a role to SSM Manager (instead of AWS Config) and allowed that role to change the Security Group (instead of trying to allow it to start an automation task in SSM). When I configured the Amazon Resource Name (ARN) of this role in the AWS Config remediation screen, the remediation started to work…
Conclusion
When you work with remediation in AWS Config, you should create an IAM role for SSM, not for AWS Config. When you do, you can automate remediation in your environment. Developers might not be too happy that their initial solution doesn’t work, but you will end up with an environment which is compliant to all the rules that you define in your environment.
(photo: www.pexels.com)
