Cool! We do the same but we call it root account instead of bastion account, since bastion is an overloaded term in the AWS universe.
AWS bastions and assume-role
31–40 of 68 posts
Re: AWS bastions and assume-role
#32Earlier 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 you save the attacker a day by explicitly telling them what software stack you use. They still have to exploit that stack.
It doesn't really change anything, just possibly saves the attacker some time if they can exploit the remaining layers.
Re: AWS bastions and assume-role
#33Earlier quoted context omitted.
People say that security trough obscurity is not a good idea.
Keeping the details of your security setup secret or obscure is not security through obscurity. Security trough obscurity is using the secrecy of your security setup as a pillar of that security. It's perfectly sane to keep the details secret even if those details themselves don't form part of your security.
I'd argue that the reasons for wanting to keep implementation details secret would be more political than for security. eg wanting to exaggerate your DR capabilities to would-be customers. Or using tech that works but has a bad image (like Perl). Or perhaps you're just releasing a commercial solution that leverages a lot of open source components and thus could easily be replicated by anyone else. I'm not saying these are good reasons, but they make more sense than the "security" argument because if your infrastructure isn't secure to begin with then it's pretty trivial to find out what is running even without the tech being published / open sourced; and if it is secure then it doesn't really matter if the details were published in the first place.
Re: AWS bastions and assume-role
#34Earlier quoted context omitted.
People say that security trough obscurity is not a good idea.
and yet, there are 'information disclosure' vulnerabilities..
There are different degrees of sensitivity though. Infrastructure, eg what Coinbase published, are pretty vague in the real terms. A hacker would still need to approach their target in the same way even with knowing this information. But exploits like Heartbleed could leak information about what users are in /etc/passwd, which is a lot more sensitive since that would significantly reduce the entropy needed for a brute force attack against the host.
Re: AWS bastions and assume-role
#35I know of no service that is more complex and off putting to newbies than AWS. I mean, wait, I need multiple accounts? Getting my team access to the one account we have took me 3 hours already!
No wait, I need a design pattern for how to manage accounts of a SaaS service?
I'm probably not the target audience here but I strongly get the impression that these patterns would not be necessary if AWS would get their shit together in terms of AWS Console UX design.
Re: AWS bastions and assume-role
#36Poor choice of name, as the term "bastion" is already commonly used in AWS to describe a bastion host for a VPC.
That's exactly the reason for this naming choice.
Re: AWS bastions and assume-role
#37I know of no service that is more complex and off putting to newbies than AWS. I mean, wait, I need multiple accounts? Getting my team access to the one account we have took me 3 hours already! No wait, I need a design pattern for how to manage accounts of a SaaS service? I'm probably not the target audience here but I strongly get the impression that these patterns would not be necessary if AWS would get their shit…
AWS is not really SaaS or PaaS although they do offer some of those (eg. Elastic Transcoder, Elastic Beanstalk), they aren't best of breed. Rather, AWS is IaaS, and hence it has to remain extremely broad, flexible and scalable. The first thing to understand is AWS is defined by its APIs, the console is a sprinkle of convenience, but understand that it is intentionally a second-class citizen.
As far as multiple accounts are concerned, this is a tradeoff you make for isolation and security. Knowing that fat fingering a staging change can not possibly impact production because the credential used in that case is literally for a different account is very comforting when you're running devops in an environment managed by multiple people.
While a lot of the stuff Amazon gives you may seem complicated, or overkill, if it's something you need it tends to be quite a bit simpler than the off-the-shelf alternative (see: VPC versus private networking).
Re: AWS bastions and assume-role
#38Cool! We do the same but we call it root account instead of bastion account, since bastion is an overloaded term in the AWS universe.
We call ours the "hub" account, since we picture the relationships between our accounts as a hub-and-spoke model.
"Root account" is also a bit misleading, because the root user is the initial non-IAM login associated with the account (http://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user...).
Re: AWS bastions and assume-role
#39I know of no service that is more complex and off putting to newbies than AWS. I mean, wait, I need multiple accounts? Getting my team access to the one account we have took me 3 hours already! No wait, I need a design pattern for how to manage accounts of a SaaS service? I'm probably not the target audience here but I strongly get the impression that these patterns would not be necessary if AWS would get their shit…
AWS is not for newbies, they released a paired-down version: https://amazonlightsail.com/
Re: AWS bastions and assume-role
#40As 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…
If you're a single zero day away from a crippling attack, you're not practising defence in depth, are you?
I was literally going to say the exact same thing. +1