Hacker News new | ask | show | jobs
by mishappen 2292 days ago
Be careful with SSM in general. The documentation suggests adding the AmazonEC2RoleforSSM policy to the role of the EC2 instances you want to access via Session Manager. This role grants read/write to all S3 buckets in your account (amongst other things). See this article for better steps and unavoidable risky things: https://cloudonaut.io/aws-ssm-is-a-trojan-horse-fix-it-now/
4 comments

There are so many AWS managed policies that provide access far beyond what one might suspect given the policy name and description. Implementing least privilege with IAM can be really difficult in any moderately complex environment.
And close to impossible in highly complex environments. We're looking to adopt using AWS accounts to achieve a few objectives but one being reducing the blast radius of potential breaches and outages.
Good call to watch out for this stuff. The examples in the repo we set up use the AmazonSSMManagedInstanceCore managed policy, which does not grant any S3 permissions, just various ssm, ssmmessages, and ec2messages permissions.
> The documentation suggests adding the AmazonEC2RoleforSSM policy to the role of the EC2 instances

Which documentation do you mean? The article mentions the policy AmazonSSMManagedInstanceCore, which is the same as what's mentioned in the SSM setup guide:

https://docs.aws.amazon.com/systems-manager/latest/userguide...

Thanks for clarifying, I didn’t recheck since we rolled out SSM in mid-2019 and then scrambled when we realised we’d granted account wide S3 permissions. The article I linked to also has a recommended minimal IAM policy for Run Command and SSM. I’ll update my comment to mention this.
It looks like the docs were update in June 2019 (https://github.com/awsdocs/aws-systems-manager-user-guide/co...)
AmazonSSMManagedInstanceCore is still too much access, it has unscoped ssm:GetParameter! I hope you weren't trying to protect any secrets in ParameterStore!
Doesn’t that still fail if you don’t also have the corresponding decrypt KMS permission?
This has not been true for a while. The IAM policy also indicates it is deprecated in the description.

Though I always suggest to read what managed profiles are doing. Many of them are very permissive