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

AWS Security Primer

cloudonaut.io

Post reply on HN
Print view View original

31–40 of 43 posts

Re: AWS Security Primer

#31

Post by nogbit »

Yellow_Boat wrote: post #28
jeffbarr wrote: post #20

Earlier quoted context omitted.

Any aspect in particular? I'm always happy to pass feedback along to the teams.

The UI is confusing, hard to read and unapproachable for non-technical people. You guys should really hire some UI guru and get him to re-design and re-word the whole system and create an easy to start, plain english language tutorials.

Wow, I think the opposite, have you tried using Azure (yes their current iteration of their UI)? It's a nightmare, the Amazon UI is fast and efficient, please don't add UI bloat.

Re: AWS Security Primer

#32

Post by jeffbarr »

Yellow_Boat wrote: post #28
jeffbarr wrote: post #20

Earlier quoted context omitted.

Any aspect in particular? I'm always happy to pass feedback along to the teams.

The UI is confusing, hard to read and unapproachable for non-technical people. You guys should really hire some UI guru and get him to re-design and re-word the whole system and create an easy to start, plain english language tutorials.

Ok, good start, but pretend that I am dense and give me a specific example along the lines of "The W console makes it hard to do X because it says Y. Why not say Z instead?" Vector values for W, X, Y, and Z are acceptable.

Re: AWS Security Primer

#33

Post by electricEmu »

nogbit wrote: post #30
falcolas wrote: post #25

Earlier quoted context omitted.

> How is s3:* even bad? It lets you do anything, including create, remove, read, update both objects and buckets. You can also change permissions on the buckets using the bucket policies. > Why on earth would i expect the same security process Because they do kind of use the same security process - IAM permissions. And not just DBs and S3 - all of AWS uses IAM in some way or another. But it's all just different enoug…

This is expected. Each AWS service should be able to grow independently of each other (new features, integrations etc etc). It would be too difficult to standardize across services, instead, implement standards at a service level and maybe some more generic ones (non aws specific) outside of that.

Services should be able to grow independently. A consistent API doesn't have to prevent that. Look at Azure and GCE who don't same the same IAM rats nest.

Re: AWS Security Primer

#34

Post by siimtalvik »

jeffbarr wrote: post #32
Yellow_Boat wrote: post #28

Earlier quoted context omitted.

The UI is confusing, hard to read and unapproachable for non-technical people. You guys should really hire some UI guru and get him to re-design and re-word the whole system and create an easy to start, plain english language tutorials.

Ok, good start, but pretend that I am dense and give me a specific example along the lines of "The W console makes it hard to do X because it says Y. Why not say Z instead?" Vector values for W, X, Y, and Z are acceptable.

Terminating an instance instead of deleting it. A pure terminology issue that a lot of newcomers have issues with.

+ instances not really being deleted when 'terminated', so there's unnecessary clutter on your dashboard.

Ticket open since 2008: https://forums.aws.amazon.com/thread.jspa?threadID=26111&sta...

They also still count against your usage limit, so workflow gets interrupted and you have to wait till they are actually deleted, but you can't really be sure when that happens.

So have a coffee, check back, nope not gone. Get another one, nope not gone.

Re: AWS Security Primer

#35

Post by plange »

a13xb wrote: post #9
briansteffens wrote: post #5

I wonder at what point the complexity of interacting security systems hits dimishing returns? Not trying to be negative, I'm a fan of how much power AWS gives you. But seeing how many systems have interacting security implications laid out in a graph like that makes me curious how far you can take it before it becomes difficult to reason about. Maybe the systems are sufficiently isolated and well defined that it's no…

> Not trying to be negative, I'm a fan of how much power AWS gives you. I am. I find AWS API incredibly baroque and has a lot of historic baggage. I suspect a lot of this complexity is a result of an accumulation of features made by multiple people in multiple teams over the years and inertia of customers relying on it, so there is (understandably) no will to change it.

Classic mistake. Except it's not really a mistake, but a conscious decision by whoever was in charge at the time (with the main focus probably being growing the company and not hurting current customers).

How do we fix that though? Standards seem like the only solution but they either don't move fast enough or the early birds (in this case amazon, but another prime example is microsoft) become so entrenched they set the standard themselves.

My own answer up until now has been to work in linux and open standards jobs (now kubernetes) but this requires increasing amounts of effort.

Re: AWS Security Primer

#36

Post by lenova »

jeffbarr wrote: post #32
Yellow_Boat wrote: post #28

Earlier quoted context omitted.

The UI is confusing, hard to read and unapproachable for non-technical people. You guys should really hire some UI guru and get him to re-design and re-word the whole system and create an easy to start, plain english language tutorials.

Ok, good start, but pretend that I am dense and give me a specific example along the lines of "The W console makes it hard to do X because it says Y. Why not say Z instead?" Vector values for W, X, Y, and Z are acceptable.

Hey Jeff, long-term AWS fan and daily user of it here. One thing I see time and time again for new user confusion: the names given to AWS services.

It has always felt that AWS has been too playful with the naming of services, to the point of obfuscation. Sure, you and I know what EC2 and S3 are, and what an instance and a bucket are. But for new companies adopting AWS, I swear that a third of my time is translating AWS service names into industry terminology for them, and often here statements like:

- "Why don't they just call it a virtual machine or cloud storage?"

- "What the heck is an EBS or a Cognito?"

- etc, etc

Also, the first run of the AWS console can be overwhelming when compared to that of Digital Ocean (though I know the two aren't really comparable in terms of breadth of services offered, but look how obvious DO's call to action is).

Just immediate thoughts that pop into my head.

[1] AWS web console: http://imgur.com/GwAeBrC

[2] Digital Ocean console: http://imgur.com/a/cO3Kn

Re: AWS Security Primer

#38

Post by rendaw »

jeffbarr wrote: post #20
racl101 wrote: post #4

AWS is so f-ing confusing sometimes.

Any aspect in particular? I'm always happy to pass feedback along to the teams.

It's been a couple months so my cache has mostly flushed, but:

Properties

InternetGatewayId

The ID of the Internet gateway.

This isn't the only example of entirely useless documentation.

Documentation for VPC users and VPC-less users are munged together. VPC users don't care about VPC-less arguments and documentation, and will never (since new customers must use VPCs). They should be completely separate documentation sets.

AMIs are critical but you have to dig into examples to find an up to date list ids, they're spread across multiple examples in multiple locations of the docs with no directions to find them.

Default values for properties and configurations don't appear to be documented anywhere. There are warnings about deleting the default VPC but no mention of how to remake it. Is the default VPC magic?

Object ids must be [A-Za-z0-9]. Why? Neither JSON nor Yaml have syntactic issues requiring this.

The documentation talks about Redis (cluster mode disabled) and Redis (cluster mode enabled). Redis (cluster mode disabled) is referred to as a cluster. But cluster mode is disabled? And on some pages the documentation uses "shards", on others "node groups", sometimes both - apparently these terms refer to the same things.

Scaling Redis (cluster mode disabled) Clusters only discusses single node clusters. Multi node (cluster mode disabled) clusters are discussed in Scaling Redis Clusters with Replica Nodes. Scaling Up Single-Node Redis Clusters shows as Scaling Up Redis Clusters in the sidebar.

Adding nodes to a cluster currently applies only if you are running Memcached or Redis (cluster mode disabled). Adding nodes applies to all clusters. AWS doesn't support adding nodes to an existing cluster in a partitioned Redis set. This is elucidated in the unlinked page Scaling Redis Clusters with Replica Nodes in a completely different section.

Articles frequently contain irrelevant asides, which makes following the documentation harrowing. Like Because Redis (cluster mode disabled) does not support partitioning your data across multiple clusters, each cluster in a Redis (cluster mode disabled) replication group contains the entire cache dataset. in the middle of Scaling Redis Clusters with Replica Nodes.

Edit: Removed a quote I misread.

Re: AWS Security Primer

#39

Post by dantiberian »

This is a great advertisement for Google Cloud. Google Cloud's security model is much simpler. For the 95% case, you can have different projects for each app and environment, and assign access permissions per project. Then you can gradually add in shared resource access when you need it. To get the same kind of isolation by default with AWS, you need to have multiple AWS accounts (AFAIK), which is a giant pain.

Re: AWS Security Primer

#40

Post by nullnilvoid »

falcolas wrote: post #22

Such a shallow dive: there really needs to be a lot more ink spilled on this topic in great depth. I've worked extensively with AWS over the last 4 years, and I can barely wrap my head around the scope of managing security in AWS. We have an entire department dedicated to security in our company, and none of them are remotely close to being experts in AWS security either. I'm starting to get curious if there even is…

AWS has got so complex.
Post reply on HN