Show HN: AWS credentials management CLI tool(github.com)
github.com
Show HN: AWS credentials management CLI tool
https://github.com/iamarkadyt/aws-auth
20 comments
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.
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.
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.
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.
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
[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 programmatic AWS access (early and unnecessary complexity, financial and development time costs). > Or not using any MFA at all and just using plain permanent AWS IAM user credentials (terribly insecure).
saml2aws is open-source code that anybody can use and contribute to, and can be used off-the-shelf. Google Workspace is "free" in that we were already using it and paying for it. Meanwhile the approach asked for in the parent, with a hub and spoke model, requires long-lived IAM users in the hub account that need to be managed separately from the company's SSO directory and thus violates SSO principles.
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 programmatic AWS access (early and unnecessary complexity, financial and development time costs). > Or not using any MFA at all and just using plain permanent AWS IAM user credentials (terribly insecure).
saml2aws is open-source code that anybody can use and contribute to, and can be used off-the-shelf. Google Workspace is "free" in that we were already using it and paying for it. Meanwhile the approach asked for in the parent, with a hub and spoke model, requires long-lived IAM users in the hub account that need to be managed separately from the company's SSO directory and thus violates SSO principles.
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.
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.
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.
Also a aws vault user here. https://github.com/99designs/aws-vault
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
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
Nice work, but I think it's a bit late. There are few competitors that does the same thing. I prefer Leapp (https://github.com/Noovolari/leapp) which expand a bit on aws-vault and saml2aws.
This looks cool, i will give it a try.
The code is very nicely done. I don't use AWS currently but I stared it on GitHub.
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.
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.
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.
And it barely even does that well.
It's just because ansible is NOT DESIGNED for that typе of tasks.
it's very inconvenient use ansible when I need just a command line tool to manage my dev env, quick and flexible ...
I don't want to edit YAML files and run ansible again when I can just rerun a command line tool with different input parameters ...
Yeah, and reinvent them in Node.js!
because Ansible doesn't solve the problem this tool solves.
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/