Hacker News Reader

Comment by snadal | Hacker News Reader

Why so many of this frameworks insist in using an account with administrator privileges?

From the docs: "search for a Policy named 'AdministratorAccess', click next and confirm".

It would be much more convenient to request only the needed privileges while teaching the user what is the tool doing in the background.

View on HN

So here's the thing - they all need enough IAM privileges that, effectively, a malicious script could get -any other access it wanted-.

That is, to be able to function these things need stuff like CreateRole, CreatePolicy, and the equivalent assignment actions (as your functions need a role and policy to execute under).

The AWS policy descriptors are not sufficiently robust to allow the creation of roles/policies that, themselves, only have certain policies/rules attached to them. That is, you either have the ability to create a policy of anything, or you do not have the ability to create a policy, period. Same with role creation.

Because of this, having the necessary permissions the framework needs to do what it says on the tin necessarily means it also can give itself -any other permission-. You can't give it the ability to create and assign policies, but prevent it from accessing, say, EC2 instances, because the role the framework operates under can create a policy for all EC2 actions, for all resources, and assign it to its own role.

So while, sure, it would be nice to enumerate just the permissions it actually needs, and what's going on behind the scenes, just so the user knows exactly what is going on, that set of permissions is still effectively administrator access. There's no security benefit.

AWS policy descriptors are certainly robust enough to handle something like this. These frameworks are built for hackathon type projects where you are just using a personal AWS account and you don't care about fiddling with permissions. Try getting access to an Administrator user/role at a big company.

To back up my first point, the framework owner could easily instruct users to set up a temporary user/role that creates the initial function roles/policies as one-time setup. Then a user/role with only the service-level permissions (Lambda etc.) could manage all the actual resources.

The devs who build these frameworks want them to be super simple to use, otherwise they won't retain users!

AWS policy descriptors actually aren't, that I've seen anyway (I'd invite you to provide a counter example though; I'd -love- to see it, because it's something I'd definitely use). In IAM, you have an action, and a resource. I can create a user that has access to CreateRole and CreatePolicy, but I can't limit what kind of policy that user can create. There's no way to say "This person can only create a policy that involves the dynamodb:, lambda: actions, and no others", for instance. They either have access to create any policy, or they can't create any.

And to your first point, it's not just being super simple though; fundamentally you have to have that admin access to be able to deploy initially.

After that, sure, provided you make no changes to the policies, the framework could theoretically diff the policies with just the iam:Get* actions applied, ensure they're the same, and deploy without touching it. But you get into weird situations where you decide "oh, this function now needs access to Dynamo, so let me modify the policy for the role the lambda is executing under", and now you have to have admin credentials again. Any new resources in AWS you want access to require you to have the iam:PutRolePolicy action, which, given you already created it and attached it, is again equivalent to admin rights, and the ability to do anything.

Sure, I agree with you and with most of the replies here.

dawson will soon switch to using an AWS CloudFormation Service Role, which allows us to require users to grant fine-grained permissions. We will then provide a copy-pasteable Policy for users to set, and update the documentation accordingly.

Currently, since CloudFormations runs with the CLI user's AWS Credentials, such user needs to be granted the permission to do every action, including, for example, managing DynamoDB Tables, S3 Buckets etc...

Also, imagine you're adding an S3 Bucket as a custom resource to your app. dawson will create such S3 Bucket using CloudFormation; CloudFormation needs to be run by a user with S3::CreateBucket permission. This applies for each resource managed by dawson/CloudFormation.

Again, thanks for your valuable inputs and feedbacks!

~ The maintainers,

Just a clarification:

NONE of your App's code will run using such "AdministratorAccess" policies. Each function will run in its own iam:Role with limited permissions defined by the developer.

The AdministratorAccess is currently required only for the CLI but, as said in my previous comment, we'll eventually move to using a Service Role and providing a more restrictive policy.

Delving into the intricacies of IAM policies can take up a LOT of room on a tutorial or blog post. Whenever I post an AWS tutorial, I usually say to pick the policy that gives '*' access to that particular service, but with a strong disclaimer that this is not for production usage, and to narrow down the permissions accordingly.

EDIT: Not global admin privileges, just full read/write to whatever AWS service I am basing the tutorial on.

There are a lot of good IAM policy setting tutorials out there that I usually point them to.

Why not just give a copy-pastable policy?

Where the policies are simple, I try and do that, but sometimes there can be complex ARNs etc. that will take too many words to try and explain, or might distract from the pace of the tutorial itself.

It is actually quicker to point to one of the built in or pre-made AWS policies, which are usually fairly generic.

Links to such tutorials would be greatly appreciated!

Did you mean IAM tutorials? A Google search on "AWS IAM Tutorials" should show you a lot of them, but some that I have pointed to myself are:

http://tom.meinlschmidt.org/2014/06/12/aws-s3-iam-user-polic...

http://mikeferrier.com/2011/10/27/granting-access-to-a-singl...

If you mean some of my AWS tutorials, a couple are:

https://hackernoon.com/building-a-face-recognition-web-app-i...

https://hackernoon.com/building-an-iot-dashboard-using-the-o...

Definitely not more convenient, however if they're going to give a getting started guide that provides quick instructions, they should also pair it with a more detailed explanation of the permissions required.

Speaking from experience, the developers themselves probably don't know off hand. Its one of those things where they probably selected AdministratorAccess permissions with the plan to later take inventory of the actual permissions used, but never ended up doing the second step. If they want people to think their framework is polished, that second step is necessary.

Yes, I think you can do much better with IAM. Experienced AWS users will not follow such a suggestion, as I suppose that doc is meant to provide a quickstart for beginners.

It's not more convenient to select the correct privileges. It is certainly a good idea, but for something where you want to get started quickly, just giving full access is much easier. However, I think whereever this is done in a tutorial, there should be a big disclaimer with a link on how to set permissions correctly.

That is the point. It is a terrible idea to provide full administrative privileges to something you are testing. I.e, it does not need to remove EC2 instances so it is a bad idea granting it against you AWS account.

If the tutorial provides a policy ready to copy & paste with all the required privileges, you will be able to customise it better or just using it as it is.

Reply on news.ycombinator.com