Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

AWS Session Manager: less infrastructure, more features

github.com

Post reply on HN
Print view View original

41–49 of 49 posts

Re: AWS Session Manager: less infrastructure, more features

#41

Post by x3n0ph3n3 »

jcrites wrote: post #32
mishappen wrote: post #28

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/

> 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...

AmazonSSMManagedInstanceCore is still too much access, it has unscoped ssm:GetParameter! I hope you weren't trying to protect any secrets in ParameterStore!

Re: AWS Session Manager: less infrastructure, more features

#42

Post by acdha »

x3n0ph3n3 wrote: post #41
jcrites wrote: post #32

Earlier quoted context omitted.

> 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...

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?

Re: AWS Session Manager: less infrastructure, more features

#43

Post by jhinds »

bogomipz wrote: post #40

The author states: >"No more bastion hosts required! Session Manager uses AWS APIs to communicate with your instances, so you can remove the administrative burden of maintaining bastion hosts." Does this presume the EC2 instances have a public IP or is there a way this would also work with EC2 instances on private subnets?

We've been using the Session Manager with instances in private subnets without issue, works like a charm.

Re: AWS Session Manager: less infrastructure, more features

#44

Post by LilBytes »

WatchDog wrote: post #38
mishappen wrote: post #28

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/

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.

Re: AWS Session Manager: less infrastructure, more features

#45

Post by mishappen »

mishappen wrote: post #39
jcrites wrote: post #32

Earlier quoted context omitted.

> 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...)

Re: AWS Session Manager: less infrastructure, more features

#46

Post by bogomipz »

jhinds wrote: post #43
bogomipz wrote: post #40

The author states: >"No more bastion hosts required! Session Manager uses AWS APIs to communicate with your instances, so you can remove the administrative burden of maintaining bastion hosts." Does this presume the EC2 instances have a public IP or is there a way this would also work with EC2 instances on private subnets?

We've been using the Session Manager with instances in private subnets without issue, works like a charm.

Is there anything special that needs to be configured to get this to work on private subnets?

Currently I have an EKS cluster accessible only on private subnets. It would be wonderful to to be able to access this without OpenVPN in the mix.

Re: AWS Session Manager: less infrastructure, more features

#47

Post by exidy »

bogomipz wrote: post #46
jhinds wrote: post #43

Earlier quoted context omitted.

We've been using the Session Manager with instances in private subnets without issue, works like a charm.

Is there anything special that needs to be configured to get this to work on private subnets? Currently I have an EKS cluster accessible only on private subnets. It would be wonderful to to be able to access this without OpenVPN in the mix.

The instances establish an outbound connection to the API SSM API, so as long as they can hit that, Session Manager will work.

Connectivity from a private subnet to the AWS API could be (a) NAT gateway (b) HTTP proxy (c) PrivateLink VPC endpoint.

Post reply on HN