search

onnela-lab / beiwe-backend

Beiwe is a smartphone-based digital phenotyping research platform. This is the Beiwe backend code
https://www.beiwe.org/
BSD 3-Clause "New" or "Revised" License
64 stars 46 forks source link

Suggested IAM Policy for Beiwe IAM User (instead of AdministratorAccess) #160

Open aware-ravi-bhankharia opened 4 years ago

aware-ravi-bhankharia commented 4 years ago

Hello,

As part of the deployment setup, we create an IAM user and attach an AdministratorAccess policy (https://github.com/onnela-lab/beiwe-backend/wiki/Deployment-Instructions---Scalable-Deployment#set-up-an-iam-user-with-sufficient-permissions)

However, in the interest of the principle of least privilege, it would be better to scope this down to an IAM policy with just the necessary permissions (or having 2 policies - one for deployment and one for normal usage).

However, I fear doing this on my running Beiwe server could potentially be very harmful, so I wanted to ask you first - do you have any examples of a scoped-down policy that could be used in place of Administrator Access?

biblicabeebli commented 4 years ago

Hello, and thanks for this one.

This is important, but it is also a hard one because I'm the only one with coverage on the project as a whole to guess the of permissions required. I want this, it is now a todo on this project, but I simply lack the time for it. Not an excuse, just a fact.

The problem is the time commitment plus the need for a vanilla environment that does not have any assets already created. The full stack deployment of a cluster will skip steps because certain aspects of the deploy script only need to happen once. I can come up with a list of permissions for known and anticipated items, and I'm happy to take a whack at that if you or someone else has the resources to attempt some spin-ups on a totally clean account / VPC.

It would be a process of reading the python stack traces of the deploy scripts, identifying the part of the deployment script that failed, and working out missing permissions and rerunning. FORTUNATELY, we used pretty verbose and accurate names for all those variables and functions so it should be pretty straight forward .... he said, unknowingly

After that the servers have pretty straight-forward needs, mostly s3.

And then we need to work out a way to add / remove permissions for new items in the future. Presumably as a part of the launch script.

Marking as a todo, looking for help on this.

biblicabeebli commented 4 years ago

Ah, and now I realized I missed part of your question.

Updating the permissions required for runtime servers is now MUCH easier because we have deprecated and are replacing the pipeline. That component had an ever-growing and arcane set of requirements. While I will need to do a review, it should be possible to work out the EB server permissions and the data processing server permissions and reduce that scope.

aware-ravi-bhankharia commented 4 years ago

Yes, that would be great! I'm assuming it's primarily S3 and RDS permissions?

biblicabeebli commented 4 years ago

Those are the biggies, yeah. Servers don't need creds to deploy anything anymore.

Todo: 1) What AWS permission-related objects (sets of credentials) do we require the launch script be handed. 2) what are all our "credential domains"? frontend/EB servers, data processing server, rds server, launch script user. any others? 3) Update launch script to generate appropriate permissions, roles, etc. that we can attach to our active server-like assets. 4) Write some idempotent code that will detect credentials that do not match a particular setup and [.... uhg, silently?] updates them in the background. [That is going to be a human-level problem. My initial guess is roll with a big stick and treat any issues that come up as emergency bug fixes. But.... uhg.]

5) I'm recalling something about aws key management for (doubly) encrypted s3? which there is a todo about it not working? .... Any chance you could .... "triage" that for me? I don't recall anything about that code, I think it was a community member.