Unless I'm missing something, isn't this whole process made a lot simpler just by using STS? It also works incredibly well with Vault's STS backend.
Isn't STS exactly what the article is describing? This is just an sts usage pattern
AWS bastions and assume-role
21–30 of 68 posts
Re: AWS bastions and assume-role
#22Earlier quoted context omitted.
This is actually a best practice and I believe Amazon also advises this. So it's not really something secret. For me as a customer it is good to know they follow these practices and communicate their understanding of it outwards. For private projects I have been experimenten with how far I can go in open sourcing everything (including server configuration) and where you hit limits. Example project: https://gitlab.com…
The first step of an attack is reconnaissance. How is making that step very easy for an attacker best practice?
How does releasing this information change that in any way to benefit the attacker?
Re: AWS bastions and assume-role
#23Very well written article with some good advice. We found very early on the need for multiple AWS accounts and managing varying levels of access to all of them has been challenging.
I also recommend looking into using SAML with your own login provider, if you have one, to assume individual roles in AWS accounts.
Re: AWS bastions and assume-role
#24As coinbase is a Bitcoin wallet and they transact a lot of money it suprises me that they reveal details of their implementation publicly. Edit - Getting downvoted a lot. Seems that some people think that the expression 'You shouldn't rely on security through obscurity' means that it's OK to publish your backend infrastructure. Best practice is defence in depth. That means you secure everything including your impleme…
Good security doesn't require obscurity.
what then is an 'information disclosure vulnerability'?
Re: AWS bastions and assume-role
#25As coinbase is a Bitcoin wallet and they transact a lot of money it suprises me that they reveal details of their implementation publicly. Edit - Getting downvoted a lot. Seems that some people think that the expression 'You shouldn't rely on security through obscurity' means that it's OK to publish your backend infrastructure. Best practice is defence in depth. That means you secure everything including your impleme…
People say that security trough obscurity is not a good idea.
and yet, there are 'information disclosure' vulnerabilities..
Re: AWS bastions and assume-role
#26Also take a look at aws-vault [1]. This not only assumes roles but also helps you store your original credentials in an encrypted form rather than a plain text ~/.aws/credentials file. You do have to configure all assumed roles in ~/.aws/config
They have an exec command but you can also export your credentials to env variables with somethings like
aws-vault exec "$AWS_PROFILE" -- env | egrep '^AWS' | awk '{print "export " $1}'
Re: AWS bastions and assume-role
#27Like everyone else, I also wrote a CLI login util in GoLang for multiple AWS account with this "bastion/main" account setup: https://github.com/lencap/awslogin . Simplicity is the main driver. I welcome constructive input.
Re: AWS bastions and assume-role
#28Earlier quoted context omitted.
This is actually a best practice and I believe Amazon also advises this. So it's not really something secret. For me as a customer it is good to know they follow these practices and communicate their understanding of it outwards. For private projects I have been experimenten with how far I can go in open sourcing everything (including server configuration) and where you hit limits. Example project: https://gitlab.com…
The first step of an attack is reconnaissance. How is making that step very easy for an attacker best practice?
So in a scenario where you can breach their AWS accounts, it would be a noticeable difficulty for you to discover that they use this pattern to work? I'm not very familiar with AWS, but that seems odd.
Re: AWS bastions and assume-role
#29Also take a look at aws-vault [1]. This not only assumes roles but also helps you store your original credentials in an encrypted form rather than a plain text ~/.aws/credentials file. You do have to configure all assumed roles in ~/.aws/config They have an exec command but you can also export your credentials to env variables with somethings like aws-vault exec "$AWS_PROFILE" -- env | egrep '^AWS' | awk '{print "exp…
This is the best tool I've found so far to manage profiles securely and switching roles between the ~35 accounts im working with right now.
Re: AWS bastions and assume-role
#30Poor choice of name, as the term "bastion" is already commonly used in AWS to describe a bastion host for a VPC.