Most prominently pointed out by Michael Wittig more than a year ago (aws-ssm-is-a-trojan-horse-fix-it-now) it’s easy to mistakenly make a policy that gives command execution through SSM, and the AWS managed policies for SSM are extremely loose and give over-reaching permissions.
Although it’s extremely unlikely to be an exam topic (because AWS still has not pulled back the permissions assigned to roles like "AmazonEC2RoleforSSM"), everyone who plans to be an advocate for security in the cloud should be aware of the pitfalls here.
Policies with unrestricted access to SSM (or one of a handful of ambiguously named permissions) are effectively giving root on all EC2 instances/local machines with an SSM agent.
AWS managed policies for SSM, clearly aimed at EC2 instances with the agent like "AmazonEC2RoleforSSM", may give overreaching permissions like GetObject and PutObject access to every bucket in S3 (among other permissions).
1 Answers
AWS have listened, apparently: https://aws.amazon.com/blogs/mt/applying-managed-instance-policy-best-practices/