Live data from Hacker News

AWS bastions and assume-role

engineering.coinbase.com

51–60 of 68 posts

Re: AWS bastions and assume-role

#51

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…

Use the Console to spot check things. But beyond that, the majority of your work in AWS should be scripted using the various APIs. At that point, using federated access or a proper IAM strategy makes that fairly painless.

Re: AWS bastions and assume-role

#52

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 . Simplicity is the main driver. I welcome constructive input.

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.

Re: AWS bastions and assume-role

#53
post #29

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

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?

Re: AWS bastions and assume-role

#54

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…

AWS is a critical service for most companies and access needs to be carefully managed. There are just natural complexities in managing access to sensitive info and controls in any company and probably needs to be solved at that level rather than a specific cloud vendor.

Arguably Google Cloud is pretty well done, especially if you're already using their G-Suite service. What would make AWS easier for you and why did it take 3 hours to create accounts for your team?

Re: AWS bastions and assume-role

#55
post #41

Earlier quoted context omitted.

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.

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

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

Re: AWS bastions and assume-role

#56
post #23

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.

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.

Re: AWS bastions and assume-role

#57
post #29

Earlier quoted context omitted.

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.

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?

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

Re: AWS bastions and assume-role

#58
post #41

Earlier quoted context omitted.

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.

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

> but I wonder how much money you burn because of not clicking one checkbox.

Abstraction is no replacement for knowledge.

Re: AWS bastions and assume-role

#59
post #45

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 recre…

[deleted]

Re: AWS bastions and assume-role

#60
post #31

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.

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

I think naming things is difficult, and the best name for a thing is the most meaningful to you and your company.
Post reply on HN