Live data from Hacker News

Open Guide to Amazon Web Services

github.com

41–50 of 133 posts

Re: Open Guide to Amazon Web Services

#42

I recommend you also make the content available on a one-topic-per-page format ASAP before someone else does and takes credit for it. WHY: Google still doesn't handle anchor-links very well. You have 1000 amazing articles on a single page. Each section (e.g.: "High Availability on AWS") would be a great resource for someone searching on that topic in Google. But when you put it all on one page Google infers "1/1000th…

That's a very insightful suggestion, thanks!

Re: Open Guide to Amazon Web Services

#43
post #14

Earlier quoted context omitted.

An attacker who compromises an EC2 instance can quietly grab the instance role credential and use it even after losing access to the instance itself.

"Have the application retrieve a set of temporary credentials and use them." "In the case of Amazon EC2, IAM dynamically provides temporary credentials to the EC2 instance, and these credentials are automatically rotated for you." Attacker should only have access until creds are expired no ?

That's right. Instance store credentials have an expiration time of a few hours. However, if the instance policy is very open you could create yourself a new IAM account or use STS to maintain persistence after the generated credentials expire.

This is why it's important to lock down instance profiles to do only what the application needs to do and no more. For example, you may give the permission to s3:DeleteObject, and in the event that the box is compromised the attacker would be able to delete files in your S3 bucket. However, if you don't give access to s3:DeleteObjectVersion you can evict the attacker and restore the deleted objects with relative ease.

This is why I would not recommend giving access to s3:* to an instance profile (or indeed, any production credentials).

Re: Open Guide to Amazon Web Services

#44
post #24

Wish there was more information about Elastic beanstalk - it always confuses me about how it works..

Well, you could start by submitting a PR with everything you already know about Beanstalk:

1. That would be very valuable for everyone else.

2. A section, that does not look overwhelmingly empty would attract more and higher quality contributions from others. Kind of a reverse broken windows theory (https://en.wikipedia.org/wiki/Broken_windows_theory).

Re: Open Guide to Amazon Web Services

#47
post #43

Earlier quoted context omitted.

"Have the application retrieve a set of temporary credentials and use them." "In the case of Amazon EC2, IAM dynamically provides temporary credentials to the EC2 instance, and these credentials are automatically rotated for you." Attacker should only have access until creds are expired no ?

That's right. Instance store credentials have an expiration time of a few hours. However, if the instance policy is very open you could create yourself a new IAM account or use STS to maintain persistence after the generated credentials expire. This is why it's important to lock down instance profiles to do only what the application needs to do and no more. For example, you may give the permission to s3:DeleteObject,…

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.

Re: Open Guide to Amazon Web Services

#48
post #29

I still don't get why Opsworks is not getting more love? I guess people don't like Chef? Opsworks has enabled hassle free deployments for us over the past three years or so at no additional cost. :)

Yep, not sure where this perception of "nobody's using it" comes from but I have been using it in 2 different companies in the last 3 years as well with nothing but love. In fact, if it were the case that "nobody's using it for good reasons", maybe we should ought to know the reasons?

Been using opsworks for about a year now and while it has very significantly streamlined our provisioning/deployment tasks, "nothing but love" is not quite how I'd describe it.

It does have some warts.

Re: Open Guide to Amazon Web Services

#49
post #29

I still don't get why Opsworks is not getting more love? I guess people don't like Chef? Opsworks has enabled hassle free deployments for us over the past three years or so at no additional cost. :)

Please write an update and submit a PR. I'm moving from Ansible to Chef and would love some real world advice on what Opsworks has to offer me without another dreaded POC.

It's likely the original authors aren't using Chef or just use Chef server as I do now.

Re: Open Guide to Amazon Web Services

#50

I recommend you also make the content available on a one-topic-per-page format ASAP before someone else does and takes credit for it. WHY: Google still doesn't handle anchor-links very well. You have 1000 amazing articles on a single page. Each section (e.g.: "High Availability on AWS") would be a great resource for someone searching on that topic in Google. But when you put it all on one page Google infers "1/1000th…

Why not both things?

I like the monolithic format, but if the cost is lower SEO, maybe have a paginated version "in addition to" (as opposed to "in place of")

Post reply on HN