
AWS bastions and assume-role - grahar64
https://engineering.coinbase.com/you-need-more-than-one-aws-account-aws-bastions-and-assume-role-23946c6dfde3
======
gregwebs
Also 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}'
    

[1] [https://github.com/99designs/aws-vault](https://github.com/99designs/aws-
vault)

~~~
willejs
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.

~~~
cjcampbell
I'm about to evaluate it for my needs. Do you run into any issues with the
temporary tokens expiring, e.g., with developers working locally on a web app
over a period of a couple hours?

~~~
willejs
Not really. Its quite straight forward and really just makes it easier to
store your creds (on any platform) securely, and enables you to switch roles
via profiles in your ~/.aws/config.

One thing I would point out is that by default it will timeout the session in
4h and the role in 15m. This means that every 15m you will need to exit your
bash shell that aws-vault exec created, or replace the env vars you generated.
Set the two env vars for session and role ttl to your desired values in your
bash profile to avoid setting them on the cli on every invocation.

You just want to look at this file, as the env vars are not documented.
[https://github.com/99designs/aws-
vault/blob/4acbb48b48b90555...](https://github.com/99designs/aws-
vault/blob/4acbb48b48b905553024331408f890f7c18dd517/cli/exec.go#L43)

~~~
cjcampbell
Appreciate the link. Until now, I've used aws-vault with the `exec` command to
run CLI tools with a quick return, so the role TTL isn't much of an issue.

I'd like to employ the tool to support local development on a containerized
web application. The assume role TTL may prove to be the real issue, so I need
to weight the tradeoff of allowing a longer life on the STS keys. I suppose I
could set up a profile without a role and override the AWS_PROFILE environment
variable within docker-compose. And I know that aws-vault also supports the
virtual meta-data service.

Either way, the benefit of something like aws-vault extends beyond security.
We've discovered numerous inconsistencies with the profile-based credential
handlers in the Java API ([https://github.com/aws/aws-sdk-
java/issues/803](https://github.com/aws/aws-sdk-java/issues/803)) which beg
for a simpler solution in terms of supporting developers.

------
skrebbel
I 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.

~~~
lazyant
AWS is not for newbies, they released a paired-down version:
[https://amazonlightsail.com/](https://amazonlightsail.com/)

~~~
NDizzle
AWS is totally for newbies, so long as you aren't afraid of performing
sysadmin work.

You don't need to have some zany serverless infrastructure. The overhead in
setting it up isn't worth the trouble.

~~~
cagataygurturk
Sure you can use AWS as newbie but I wonder how much money you burn because of
not clicking one checkbox.

~~~
NDizzle
Checkboxes can be tricky! Why, I unmounted several local volumes when adding a
Windows server to a failover cluster just last month...

------
dantiberian
In Google Cloud, something like this is mostly unnecessary. The project model
scopes resources to a particular project within an organisation, rather than
all resources being global to the account. This gives a really good first cut
at isolating different environments and projects.

~~~
bpicolo
This goes beyond just prod/staging. It allows you to easily manage fine-
grained roles down to e.g. particular microservices and also control how users
can access those resources as minimally as is necessary.

So you can recreate the project-model here, and also refine it beyond that.

------
takeda
I like AWS multiple accounts support it helps securing specific environments,
but I don't like that going this route increases the cost.

Here are some things I don't like:

1\. if you want to use AWS support, you need to purchase it per account,
otherwise support will refuse any help that involves anything specific to the
account (they will only respond with generic documents)

2\. with separate account you need to recreate the same components (and
therefore pay more) for example if you want internet access on your VPC over
IPv4, you need to set up a NAT instance per account, you can't for example use
VPC peering and use NAT instance on another account

3\. you are being charged for any data going between accounts even if same AZ
is used. Yes, I understand that one can't easily tell which AZ is which across
accounts since they are randomized per account but still...

~~~
mentat
If you use the same billing account I'm pretty sure 1 is not true. I only know
at higher support levels though it is not a problem for sure.

~~~
takeda
Well, I don't have access to the root account to see if these accounts are
under the same billing account (but best of my knowledge it is), and the
support we purchased is Business.

When I had question related to one of account I was told that I will need to
open a support ticket on that account, but I couldn't open because they had
basic support.

We contacted our TAM and he just shrugged. If this is true that would be
great.

Edit: I checked and looks like our account are consolidated until single
master one, although we did not purchase support for the master account since
nothing is running on it. If there is a way to not have to purchase separate
support I would like to know since it could save some money.

------
fxaguessy
Great article and nice tool. Switching role and profile with multiple
organizations is indeed cumbersome with AWS.

We are also developing an open source CLI for AWS named awless (cf.
[https://github.com/wallix/awless](https://github.com/wallix/awless)). We
currently support easy MFA, profile switch and role assuming in CLI with the
'-p' flag and are working on extending these features to support multiple
organizations. We had multiple issues filed on GitHub which are closely
related to this.

------
xref
2018 Hottest AWS Job Postings:

    
    
      - Identity-Access-Management Manager
      - Pricing Oracle
      - Sysadmin we fired when Moving To The Cloud(tm)

------
sdfjkl
Poor choice of name, as the term "bastion" is already commonly used in AWS to
describe a bastion host for a VPC.

~~~
CaveTech
That's exactly the reason for this naming choice.

------
sandd
Now that I'm comfortable with the IAM side of things, I will always use
multiple accounts. I'm also beginning to think it's valuable to not even limit
yourself to a single account per environment. Tools like Terraform become
essential, though.

I've written about using multiple accounts in combination with CodePipeline to
manage Lambda deployments here: [https://medium.com/statics-and-
dynamics/automated-lambda-dep...](https://medium.com/statics-and-
dynamics/automated-lambda-deployments-with-terraform-
codepipeline-a4d2a2019eae)

------
RoutinePlayer
Like 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](https://github.com/lencap/awslogin) .
Simplicity is the main driver. I welcome constructive input.

~~~
jimwalsh
This is nice, but having the ability to get prompted for all the authorized
roles for a user in an account is nice, as is done by the aws-login node app.

------
lox
We took this approach at 99designs with aws-vault and bastion accounts:
[https://99designs.com.au/tech-blog/blog/2015/10/26/aws-
vault...](https://99designs.com.au/tech-blog/blog/2015/10/26/aws-vault/)

------
mavus
Very 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.

~~~
legohead
Would you mind describing your needs? I read the article and I still don't
fully understand the need for multiple accounts -- seems the article is more
about the tool. I would understand the need when it comes to API rate
limiting, but I have never ran across this on a million+ session/day website.

------
fogetti
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.

~~~
otterley
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...](http://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html)).

~~~
grahar64
I think naming things is difficult, and the best name for a thing is the most
meaningful to you and your company.

------
dmikalova
This is what we do. Each product has it's own prod and qa account.

------
grabcocque
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.

~~~
bpicolo
Isn't STS exactly what the article is describing? This is just an sts usage
pattern

------
1ba9115454
As 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 implementation details.

If a zero day is found in any of their stack, they're a google search away
from being found for that.

~~~
weego
Good security doesn't require obscurity.

~~~
cat199
what then is an 'information disclosure vulnerability'?

~~~
Artemis2
It’s not what you think. It’s more about disclosing business-related data or
metadata (e.g. customer names, last time a customer logged in) than technical
information (e.g. internal service names, minor debug information).

