IAM Permissions are missing from the documentation

[Tim Van Steenburgh]

Opened by lazypower on 2018-12-14 21:57:43+00:00 at https://github.com/juju-solutions/charm-gcp-integrator/issues/4

------------------------------------------------------------

After deploying the gcp-integrator charm, it was blocked by the level of credentials of the service-account we assigned to the unit.
unit-gcp-integrator-1: 15:54:34 INFO unit.gcp-integrator/1.juju-log Labelling instance juju-3033d9-0 in us-central1-a with: {'k8s-io-cluster-name': 'kubernetes-mx52r49peyjgy8qmeyb8wsozd2keucwf', 'k8s-io-role-master': 'master'}
unit-gcp-integrator-1: 15:54:36 INFO unit.gcp-integrator/1.juju-log Enabling instance inspection for kubernetes-master
unit-gcp-integrator-1: 15:54:38 ERROR unit.gcp-integrator/1.juju-log Traceback (most recent call last):
  File "/var/lib/juju/agents/unit-gcp-integrator-1/charm/reactive/gcp.py", line 72, in handle_requests
    request.application_name)
  File "lib/charms/layer/gcp.py", line 134, in enable_instance_inspection
    _add_roles(service_account, ['roles/compute.viewer'])
  File "lib/charms/layer/gcp.py", line 308, in _add_roles
    '--role', role)
  File "lib/charms/layer/gcp.py", line 253, in _gcloud
    raise GCPError(stderr)
charms.layer.gcp.GCPError: ERROR: (gcloud.projects.add-iam-policy-binding) User [<email address hidden>] does not have permission to access project [my-project:setIamPolicy] (or it may not exist): The caller does not have permission

unit-gcp-integrator-1: 15:54:38 INFO unit.gcp-integrator/1.juju-log status-set: blocked: error while granting requests; check credentials and debug-log

I think it would be helpful to clearly document the IAM policy that's expected to be provided to the GCP Integrator to streamline bootstrapping a fresh deployment.
Despite seeing the link to "Enable API Access" - that link wasn't helpful. I was brought to a dashboard that didn't seem to have the juice we were looking for. Here's what I see when I visit, which doesn't seem to have anything to do with IAM credentials in this context other than the "credentials" button on the left which brings me to the IAM detail editor for service accounts.

====================== COMMENTS ============================

Comment created by kwmonroe on 2018-12-14 22:35:47+00:00

Thanks for the report @lazypower. The link from the readme [0] will take you to a dashboard of whatever gce account you're currently logged-in as. That's conceivably less-than-helpful :/ Sorry about that!

We had something similar come up for AWS (that is, enumerate the perms required) which yielded this:

https://github.com/juju-solutions/charm-aws-integrator#permissions-requirements

We'll fix this with something similar for gcp.

[0] - https://console.developers.google.com/apis/api/iam.googleapis.com/overview

------------------------------------------------------------

Comment created by johnsca on 2018-12-15 00:10:00+00:00

I think that @kwmonroe has a good point that you might be logged into a different account in your browser than the master for the SA, but from the browser page and the error, it does look like the API is already enabled anyway.

The error message does give the permission that failed (`my-project:setIamPolicy`) but that would clearly get tedious to enumerate-by-failure. We definitely need to list them in the README, but at the end of the day it essentially boils down to being able to create SAs and manipulate their IAM roles, which basically amounts to admin in the project so it would probably be easier to just grant that.

Since GCP, unlike AWS, requires passing credentials for the SA anyway, it would probably be better to at least offer a fallback mode where, instead of managing dedicated SAs for the related applications, it just passed through the creds it was given. While this would make the cred have to be one-size-fits-all, it would require granting less trust to the integrator, which might be preferable. This is essentially how the OpenStack and vSphere integrators work, since those platforms don't support managed SAs with fine-grained roles anyway.

[Charles Butler (lazypower)]

I wound up editing the permission we gave it by binding a custom role that granted the specific IAM permission it was seeking and that seems to have resolved the inconsistencies for now.

I'd advocate we get at least those bare minimum role assumptions spelled out so we can create a "one shot" role that it needs to self bootstrap. otherwise it works as advertised.