This solution involves creating the following resources: This led me down a long rabbit hole, and I've emerged with an alternative solution that makes me feel a lot better. Especially not ones that grant AdministratorAccess. This is where I had issues: I don't particularly appreciate having long-lived credentials on my local filesystem. My first step was creating a new IAM user for myself and granting it the AdministratorAccess policy.Īt this point, Amazon recommends creating API credentials and configuring a named profile for automatically authenticating the CLI with an IAM account. The root account has unmitigated access to create, modify, and destroy all AWS resources. The first bit of advice I came across is pretty straightforward: lockdown the AWS root account and only use IAM accounts for interacting with the AWS console/API.
I'm always looking for the crossroads of ease of use and a small blast radius. One of the first things I look at optimizing is the security of how I am authenticating against AWS. Access is then granted based on instance tags through SSO policy using attribute based access control so that certain groups in our IDP will be allowed to ssm/ssh to any node with the correct access tag on it.I've recently been skilling up on AWS and have been setting up my local environment for building various labs.
Requires an agent on the ec2 instances (official Amazon AMIs include it by default) and IAM permission in the instance profiles (though there is a new way to set this up with default host configuration though so it automatically has the permissions on every ec2 instance ). Have used a combination of AWS SSO + Systems Manager Session Manager + EC2 Instance Connect so there are no long lived ssh keys (temp created ones by instance connect), and don't need to open any inbound ports for ssh (do ssh over the ssm tunnel, which is outbound from instance to ssm vpc endpoint, so vpc doesn't even need internet access directly).
0 kommentar(er)
