Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

AWS bastions and assume-role

engineering.coinbase.com

Post reply on HN
Print view View original

41–50 of 68 posts

Re: AWS bastions and assume-role

#41

Post by NDizzle »

lazyant wrote: post #39
skrebbel wrote: post #35

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 not for newbies, they released a paired-down version: https://amazonlightsail.com/

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.

Re: AWS bastions and assume-role

#42

Post by Artemis2 »

cat199 wrote: post #24
weego wrote: post #8

Earlier quoted context omitted.

Good security doesn't require obscurity.

what then is an 'information disclosure vulnerability'?

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

Re: AWS bastions and assume-role

#43

Post by ncallaway »

1ba9115454 wrote: post #15
mxstbr wrote: post #11

Earlier quoted context omitted.

This is, maybe counterintuitively, not true. If anything, Coinbase is more secure than before by publishing this. 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 b…

There's no proof there that they are now at less 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.

Sure, but that can easily be turned back around on you:

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.

Re: AWS bastions and assume-role

#44

Post by takeda »

skrebbel wrote: post #35

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…

As it was pointed out AWS is IaaS.

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.

Re: AWS bastions and assume-role

#45

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

Re: AWS bastions and assume-role

#46

Post by yarrel »

1ba9115454 wrote: post #13
weego wrote: post #8

Earlier quoted context omitted.

Good security doesn't require obscurity.

Good security means defence in depth. You secure everything including your backend implementation details.

Good security means not kidding ourselves that backend implementation details are providing us with any defense.

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.

Re: AWS bastions and assume-role

#47

Post by peterwwillis »

1ba9115454 wrote: post #2

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

Leave your house's front door unlocked and keep a camera outside trained on the door. For the first week, tell nobody that it is unlocked. For the second week, tell everyone you meet that it is unlocked, and provide a map. On the third week your camera records someone going into the house.

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.

Re: AWS bastions and assume-role

#48

Post by cagataygurturk »

NDizzle wrote: post #41
lazyant wrote: post #39

Earlier quoted context omitted.

AWS is not for newbies, they released a paired-down version: https://amazonlightsail.com/

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.

Re: AWS bastions and assume-role

#49

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

Post reply on HN