Hacker News new | past | comments | ask | show | jobs | submit login

> 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 enough to make it damned hard to create any kind of standard.

Some permissions can be fine tuned, some can not. Some can rely on conditionals, some can not. Some can be overridden at the object level, some can not. Some use roles, some users, some policies.

Understanding the differences - what works when - is what makes it all so hard to understand. And when it changes, all that knowledge is useless (or worse, dangerously incomplete) again.




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.


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

So if you don't want that, don't write it? I don't see how AWS forces anyone to make that infrastructure decision in any specific case. And its not default. You have to go out of your way to do that.

> 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 enough to make it damned hard to create any kind of standard.

So? The standard is running your own services and using any of the standard networking options. They are handling provisioning and networking so naturally they need an abstraction for security of network clients they are connecting for you.

> Some permissions can be fine tuned, some can not. Some can rely on conditionals, some can not. Some can be overridden at the object level, some can not. Some use roles, some users, some policies.

So? permissions, conditionals, asset policies aren't new or complicated and well within what you'd deal with in any tech stack in existence. Same goes for roles, policies, and users... Do those abstractions really seem that complicated? And in which stack do they not exist?

> Understanding the differences - what works when - is what makes it all so hard to understand. And when it changes, all that knowledge is useless (or worse, dangerously incomplete) again.

Thats fine, but arguably not better than any other service provider. You could also say those things about any software service out there - especially if its intended for consumption by engineers. Documenting APIs isn't a solved problem for anyone.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: