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

Show HN: AWS credentials management CLI tool

github.com

Post reply on HN
Print view View original

11–20 of 21 posts

Re: Show HN: AWS credentials management CLI tool

#11

Post by sofixa »

markuman123 wrote: post #3

I always wonder why people are investing so much energy and time to invent New tools instead oft using existing tools that already solve the same issues. Just use ansible for that.

Ansible is a pig that does many things, very few of them right or well. Going by your logic, why use a dedicated IaC tool like Terraform or Pulumi if you can just force Ansible to kind of do it ?

New tools covering a specific niche, even if that niche is already covered by a bigger, more established tool, are frequent. Not everyone needs or wants the kitchen sink approach. If you're using only CloudFormation to manage AWS, why would you force misery upon yourself to use Ansible just for AWS auth?

* I slightly exaggerate, but i genuinely consider Ansible to be the worst CM tool of the "modern" ones (so excluding CFEngine) at any sort of scale/enterprise. It has so many things wrong it's baffling for me people are removing existing Puppet, Chef, Salt envs to replace them with Ansible. It's awesome for homelabs or similar though.

Re: Show HN: AWS credentials management CLI tool

#13

Post by jayceedenton »

NikolaeVarius wrote: post #2

Why use this over aws-vault

I feel for the person that built this. They had a great idea, saw a really nice way to implement it, and worked hard on building the project and some good docs and demo. But unfortunately this thing already exists, in almost exactly the same form. It's called aws-vault and it's been around for many years.

Sorry, it's hard to find a new problem these days with all these engineers around. Your learned some things along the way though, I'm sure, so all is not lost.

Re: Show HN: AWS credentials management CLI tool

#14

Post by larusso »

solatic wrote: post #7
larusso wrote: post #5

In my company everything goes through Active Directory and we use saml2aws [1] to generate credentials with two factor involved. It works quite well for us. We even use this for our artists to create local builds of our games since we keep all important secrets and such in aws secrets mananger. We scope access to said secrets with custom roles and tags. [1] https://github.com/Versent/saml2aws

We do the same, through Google Workspace. saml2aws has a propensity to randomly break (probably Google's fault, as saml2aws scrapes the login pages) but it's "good enough". Quoting original link: > The regular approach taken by many software companies is either: > Using expensive SSO solutions (3rd party single sign-on SaaS platforms) and writing custom CLI toolkits for integrating with said platforms for programmati…

We have the rule to limit down shared and manual maintained users in all our services. More so we not only want to limit down the attack vector but also are able to know where a potential breach came from. A shared IAM role coming from an ansible vault or git crypt repo does not cut it. Also the credentials valid to the end of time. There is also on and off boarding issues. A person which has access today should have his access easily being revoked if necessary. With shared tokens that is super hard to maintain.

Re: Show HN: AWS credentials management CLI tool

#15

Post by solatic »

paranoidrobot wrote: post #9

I'm not sure I see the benefit of this over using the built-in functionality of AWS SSO[1] which is built into AWS and integrates with Control Tower. If you want to use it's internal iDP - you can. If you want to authenticate against GSuite or another SAML provider, you can do that, too. [1] https://aws.amazon.com/single-sign-on/

AWS SSO has one huge gotcha that makes it nigh impossible to use well (from a security perspective). Instead of using bog-standard IAM roles, AWS SSO reinvents the wheel and asks you to create a "Permission Set". What's the difference between a Permission Set and an IAM role? Whereas with an IAM role, you can attach multiple IAM policies to a single role, with a Permission Set you can only use a single inline policy or AWS managed policies. A single inline policy is nearly impossible to maintain, you reach maximum policy size extremely quickly, and AWS managed policies are a security nightmare with wildcards everywhere.

And behind the scenes, AWS SSO sets up the exact same SAML infrastructure that is available to you already in IAM, just with roles with unpredictable names (so that it's difficult to programmatically attach policies) with "DONOTDELETE" as part of the name but no actual SCP in place to prevent the role from being deleted. Because it's the same exact SAML infrastructure, but with additional redirects to allow you to login through the AWS SSO start page instead, it's slower compared to setting up SAML access per AWS account directly.

AWS SSO is a horrible product that actually encourages poor security practice (i.e. AWS managed policies, because a single inline policy is not large enough) and really the only reason why anybody bothers using it is because SAML login from the AWS CLI tooling is not well-supported by AWS.

Re: Show HN: AWS credentials management CLI tool

#16

Post by conradludgate »

As others have mentioned, there is saml2aws. I make use of this, with aws profiles and with saml2aws configured as a 'credentials provider' in aws. If I have already entered my username, password and MFA code once in a session, all my other profiles become active. I can use `aws --profile eks-dev` for instance to connect to that configured account/role.

This extends well to my kubeconfig which make use of these specified profiles to login. So I just run saml2aws, and my kubectl contexts also automatically get configured

Re: Show HN: AWS credentials management CLI tool

#17

Post by dhess »

solatic wrote: post #15
paranoidrobot wrote: post #9

I'm not sure I see the benefit of this over using the built-in functionality of AWS SSO[1] which is built into AWS and integrates with Control Tower. If you want to use it's internal iDP - you can. If you want to authenticate against GSuite or another SAML provider, you can do that, too. [1] https://aws.amazon.com/single-sign-on/

AWS SSO has one huge gotcha that makes it nigh impossible to use well (from a security perspective). Instead of using bog-standard IAM roles, AWS SSO reinvents the wheel and asks you to create a "Permission Set". What's the difference between a Permission Set and an IAM role? Whereas with an IAM role, you can attach multiple IAM policies to a single role, with a Permission Set you can only use a single inline policy…

Prior to AWS SSO and Control Tower, we followed best practices and used an "identity hub" account in our organization, tied to our IdP via SAML. Users authenticated via SAML into their identity hub role, and that role could then `sts:AssumeRole` to any other roles they needed to do their work.

We've since adopted AWS SSO and Control Tower, and to address the problems with it that you mention, we configure the SSO permission set so that the only thing the user can do is assume their identity hub role. Because you can chain `AssumeRole`, it's an extra indirection, but everything works just like it did before.

So while I agree that AWS SSO is not the right place to configure fine-grained permissions, I think that overall I prefer the benefits of Control Tower and the relatively easy SAML integration provided by AWS SSO over the previous bespoke SAML configuration we used. It's a bit inconvenient to set up the extra hoop to jump through to go from SSO permission set to identity hub IAM Role, but that's a one-time cost and is trivial to maintain.

Re: Show HN: AWS credentials management CLI tool

#19

Post by senorsmile »

sofixa wrote: post #11
markuman123 wrote: post #3

I always wonder why people are investing so much energy and time to invent New tools instead oft using existing tools that already solve the same issues. Just use ansible for that.

Ansible is a pig that does many things, very few of them right or well. Going by your logic, why use a dedicated IaC tool like Terraform or Pulumi if you can just force Ansible to kind of do it ? New tools covering a specific niche, even if that niche is already covered by a bigger, more established tool, are frequent. Not everyone needs or wants the kitchen sink approach. If you're using only CloudFormation to manag…

Ansible is so much more than CM. I agree that TF does infra provisioning better. Even so, I don't see how Ansible solves the same problem. Ansible is not interactive.

Re: Show HN: AWS credentials management CLI tool

#20

Post by sofixa »

senorsmile wrote: post #19
sofixa wrote: post #11

Earlier quoted context omitted.

Ansible is a pig that does many things, very few of them right or well. Going by your logic, why use a dedicated IaC tool like Terraform or Pulumi if you can just force Ansible to kind of do it ? New tools covering a specific niche, even if that niche is already covered by a bigger, more established tool, are frequent. Not everyone needs or wants the kitchen sink approach. If you're using only CloudFormation to manag…

Ansible is so much more than CM. I agree that TF does infra provisioning better. Even so, I don't see how Ansible solves the same problem. Ansible is not interactive.

> Ansible is so much more than CM

And it barely even does that well.

Post reply on HN