Approach to prevent out-of-band (clickops) updates to CloudFormation created resources

1

At one of my client organisation we have deployed almost all the AWS resources via CloudFormation/DevOps. On some occasions, users made updates to some of the resources directly via AWS console resulting in drift and other challenges. Thus, I am looking to see if there is any option to prevent users from making “updates” to all CloudFormation created resources.

I can think of an option of deploying an SCP like below but not clear about all all actions need to be included in the SCP to prevent updates to many of the AWS resources which are deployed currently. Moreover this may result in a very long list of actions which may hit SCP policy limits as well. In this example I have only included ec2:RebootInstances for testing purpose but in reality I want to prevent all update/delete actions across all the resources.

{
	"Version": "2012-10-17",
	"Statement": [
		{
			"Sid": "VisualEditor0",
			"Effect": "Allow",
			"Action": "ec2:Describe*",
			"Resource": "*"
		},
		{
			"Sid": "VisualEditor1",
			"Effect": "Deny",
			"Action": "ec2:RebootInstances",
			"Resource": "*",
			"Condition": {
				"StringNotEquals": {
					"aws:PrincipalArn": [
						"arn:aws:iam::xxxxxxxx:user/devopsuser",
						""
					]
				},
				"StringEquals": {
					"ec2:ResourceTag/DeploymentType": [
						"CloudFormation",
						"Terraform"
					]
				}
			}
		}
	]
}

Is there any option available for this requirement?

4 Answers
1

To save yourself from specifying every action, you can use a wildcard for API actions (write actions) like Create*. Obviously, to prevent users from making out-of-band changes, restricting write actions would suffice. For those resources/actions that support tags, you can implement Attribute Based Action Control (ABAC). Using ABAC, you can reduce the number of policies (not only SCPs but IAM policies as well). Multiple users/roles can use the same policies but have different access based on tags (attributes).

Also, you can consider using AWS Config to detect changes and apply remediation. This is more of a reactive solution but can help detect unpredicted changes.

Taka_M
answered 3 months ago
1

Thinking out loud here: most AWS resources created by AWS CloudFormation that support tagging (which is nearly all of them) often get AWS-generated cloud formation tags, i.e. aws:cloudformation:stack-id and so on. Might be worth looking into creating a policy that denies any action if these tags are present on the resources? Might not work for all resources, not all API calls support resource-level tagging conditions but that's a good "covers everything it can".

profile picture
answered 3 months ago
0

Answers from Taka_M and JohnPreston are great. I'm also looking into those methods. In addition, if you are considering even more locked-down resources, you could also provision resources via Service Catalog or an external Pipeline such as GitHub/GitLab/Bitbucket/etc.. This way you could give access to those tools instead of direct access to the resources in the console, and keep console access mostly read-only. As an example, we're looking to give EC2 console access (SSH/RDP) via Session Manager, and also restart the instance in the console, but otherwise read-only. Hope this helps.

Rob_El
answered 3 months ago
0

Thank you all for all the great suggestions. I think I will start with an option of building a SCP based on CFN tags with limited console access in lower environment and try it out. For SCP, as per Taka_M's suggestion probably identifying suitable wildcards (Create* etc) makes more sense.

mj123
answered 3 months ago

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.

Guidelines for Answering Questions