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 個答案
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.

AWS
Taka_M
已回答 2 年前
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
已回答 2 年前
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
已回答 2 年前
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
已回答 2 年前

您尚未登入。 登入 去張貼答案。

一個好的回答可以清楚地回答問題並提供建設性的意見回饋,同時有助於提問者的專業成長。

回答問題指南