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

Open Guide to Amazon Web Services

github.com

Post reply on HN
Print view View original

61–70 of 133 posts

Re: Open Guide to Amazon Web Services

#61

Post by voganmother42 »

gtsteve wrote: post #59
voganmother42 wrote: post #47

Earlier quoted context omitted.

Thank you for the reply - that makes sense to me, least privilege seems to be the primary defense in that case. Having explicit creds you rotate yourself I could see having benefits as far as control, but also requires more work / potential for implementation mistakes.

Well, the AWS credentials auto-rotate. It does however provide a familiar place for an attacker to go to get the instance credentials, but that doesn't really help. At some point, those credentials must exist in plain-text for you to use them. If they're in a config file, they can be read out, if they're in RAM they can be pulled out with a debugger. At least if your box is temporarily owned due to a zero-day that yo…

we use iam roles and credstash(dynamodb and kms) for retrieving database credentials. My comment was mostly in terms of the fact we cannot control the rotation for roles, say in the event of a breach like where someone committed keys to github and I can explicitly expire/rotate(assuming those keys were not themselves temporary and have not already expired :))

Re: Open Guide to Amazon Web Services

#65

Post by gtsteve »

voganmother42 wrote: post #61
gtsteve wrote: post #59

Earlier quoted context omitted.

Well, the AWS credentials auto-rotate. It does however provide a familiar place for an attacker to go to get the instance credentials, but that doesn't really help. At some point, those credentials must exist in plain-text for you to use them. If they're in a config file, they can be read out, if they're in RAM they can be pulled out with a debugger. At least if your box is temporarily owned due to a zero-day that yo…

we use iam roles and credstash(dynamodb and kms) for retrieving database credentials. My comment was mostly in terms of the fact we cannot control the rotation for roles, say in the event of a breach like where someone committed keys to github and I can explicitly expire/rotate(assuming those keys were not themselves temporary and have not already expired :))

I believe you can actually [0]. In a production setting it's a lot harder to accidentally leak the credentials - my concern would be if someone compromised the instance or if it was tricked into opening the instance store up to the net, such as a badly configured nginx instance (how you'd do that accidentally though I have no idea)

[0] http://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use...

Re: Open Guide to Amazon Web Services

#66

Post by nzoschke »

zalzal wrote: post #20
nzoschke wrote: post #17

This is great. I've been working on AWS for close to 10 years now and an open guide is something I both need and want to contribute to. Many of us have simple goals on AWS. The official AWS docs are thorough, but are too technical. There are blog posts about anything, they can be hard to find or get out of date. I hope this open guide helps us all get our jobs done faster and easier!

Very glad to hear. Its this sentiment exactly that led us to get this started. We all have 100s of valuable tricks and gotchas we learn over the years, but 99% of the time fail to write down and share them helpfully. Do join us on Slack/GitHub and help us get your tips included, too.

Done and done. I was pleasantly surprised to see my ECS tips already linked. I hope I can remix this knowledge for the guide!

https://convox.com/blog/ecs-challenges/

Re: Open Guide to Amazon Web Services

#68

Post by nzoschke »

vmarsy wrote: post #34

Thanks, I like that Service Matrix[1] ! I've a few questions for AWS experts : The only container orchestration that is open source seems to be Kubernetes. Is it easy to run on AWS? What's the equivalent of Azure "Service Fabric" in the AWS world? (and in the Google Cloud?) [1] https://github.com/open-guides/og-aws#service-matrix

You probably are aware, but AWS has a container orchestration service built into the platform with ECS. The container agent is open source (https://github.com/aws/amazon-ecs-agent).

We're building an open-source platform at Convox that leverages ECS very successfully. https://github.com/convox/rack

In my experience, ECS is easy to run, as it's a first class part of the platform. Boot up the right "cattle" AMIs with the right ASG configuration and you're good to go.

K8, Docker Swarm, Mesos and Nomad have plenty of documented success but you to stand up and operate the orchestration layer yourself. This is booting up "pet" AMIs and making sure they are monitored, etc. Then you boot up your "cattle" AMIs to run your apps.

The Convox philosophy is that you get application portability by packaging your app correctly with Docker. The orchestration layer should be invisible, something that you shouldn't build or operate yourself.

Re: Open Guide to Amazon Web Services

#69

Post by voganmother42 »

gtsteve wrote: post #65
voganmother42 wrote: post #61

Earlier quoted context omitted.

we use iam roles and credstash(dynamodb and kms) for retrieving database credentials. My comment was mostly in terms of the fact we cannot control the rotation for roles, say in the event of a breach like where someone committed keys to github and I can explicitly expire/rotate(assuming those keys were not themselves temporary and have not already expired :))

I believe you can actually [0]. In a production setting it's a lot harder to accidentally leak the credentials - my concern would be if someone compromised the instance or if it was tricked into opening the instance store up to the net, such as a badly configured nginx instance (how you'd do that accidentally though I have no idea) [0] http://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use...

Good point! slightly less granular than per key but still very helpful, thanks!
Post reply on HN