AWS bastions and assume-role
engineering.coinbase.com
engineering.coinbase.com
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}'
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...
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) which beg for a simpler solution in terms of supporting developers.
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.
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).
You don't need to have some zany serverless infrastructure. The overhead in setting it up isn't worth the trouble.
Abstraction is no replacement for knowledge.
I think the reason it might seem hard is because you probably don't have operational experience. You need to have that knowledge if you have your own data center.
Sure, this all could be abstracted, and it kind of is if you use things like Beanstalk, but AWS provides great flexibility which can make difference how your application performs in the end and how easy it is to maintain it.
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?
So you can recreate the project-model here, and also refine it beyond that.
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...
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.
We are also developing an open source CLI for AWS named awless (cf. 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.
- Identity-Access-Management Manager
- Pricing Oracle
- Sysadmin we fired when Moving To The Cloud(tm)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...
I also recommend looking into using SAML with your own login provider, if you have one, to assume individual roles in AWS accounts.
"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...).
It also works incredibly well with Vault's STS backend.
http://docs.aws.amazon.com/STS/latest/APIReference/API_Assum...
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.
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.
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/failmap/server
Diving into a project with a open source mindset really makes me think more about security topics from a different angle and find better solutions. Like reducing the secrets that must be known (and thus can leak), like user/database passwords. Instead of security by obscurity there is nothing to obscure.
How is making that step very easy for an attacker best practice?
Security through obscurity and all that.
It doesn't really change anything, just possibly saves the attacker some time if they can exploit the remaining layers.
They're not, and if we base our security strategy on the assumption that they are then we have at least one weakness in that strategy.
For a great and well-reasoned argument see the Gov.UK guidelines, which state that all of their new code has to be open source. (yes, that's the UK government, not some startup) They even specifically mention security-enforcing code![0]
> Code that contributes to your service’s security does not need to be kept closed. Many security-enforcing functions, such as cryptographic algorithms, are provably better when openly examined and understood while the keys are kept private.
They also have another guide and a blog post specifically about security considerations with open source code.[1][2]
> Doesn’t it give attackers an advantage?
> Although there’s a common concern that coding in the open could give an advantage to an attacker, we believe that only a negligible advantage exists. [...] In fact there is no evidence to suggest that being open source makes software more susceptible to exploitation.
I would highly recommend reading through those if you really think Coinbase is now under a higher risk of attack due to this article. They aren't.
[0]: https://www.gov.uk/service-manual/technology/making-source-c... [1]: https://www.gov.uk/government/publications/open-source-guida... [2]: https://mojdigital.blog.gov.uk/2017/02/21/why-we-code-in-the...
I've looked at the code and I can see already some potential supply channel attacks as they are not hash protecting their incoming libraries.
If you're open sourcing stuff that other people use, it makes sense, because people fix security issues from using software, fixing bugs and witnessing failures, and needing the fixes for themselves. Not from going 'wow, that's 500 repositories, most of which I don't care about at all'. You're not going to go fix the issues you just saw, are you?
In this case, Coinbase open-sourced some useful code (with an install-this-one-liner), and details of a systematic security method that other people can also use themselves, critique and improve on. The difficulty of breaking their setup hasn't changed, simply by knowing that the keys/MFA combo you really want is a different one. You'd still need to steal it. Perfect example of helping security by transparency.
There's no proof there that they are now at more risk.
> I've looked at the code and I can see already some potential supply channel attacks as they are not hash protecting their incoming libraries.
And if you, or anyone else who sees that sends them a notification about a potential vulnerability and they investigate it they're probably better off than they were before.
Did telling people your house was unlocked make your house less secure?
Your house was exactly the same in the first week as the second week. Telling people it was insecure did not make it insecure - it was already insecure. You left it unlocked.
So it follows that if knowing some piece of information does not reduce the security of your system, then it is not sensitive information, and can be released publicly. On the other hand, if you don't know whether a piece of information reduces your security, you should probably find out. And finally, even if you never release information, that does not mean your house is locked up. But it may lead to a false sense of security.
It's a common tactic for burglars to look for when homeowners are going on holidays. The homeowner being on holiday makes the house less secure, but the information that that particular house is less secure is of benefit to the burglar.
Security isn't a binary state.