Hi all,
I’m quite confused regarding the Roles/Policies/Member in GCP.
To take an example
In AWS-world, if I want to grant an EC2 Machine a permission to write data into S3, I
Create a policy which allows to write into S3
Attach this policy to a role
Attach this role to the EC2 instance
Now, in GCP, here what I understand you need to do
Create a policy which allows to write into Storage
Attach this policy to a member (first question – why a member? I don’t want to have a Google Identity for each of my role). Or do I have to attach it to a serviceAccount (seems to be overkill to me)?
ORWhen launching an Instance, manually tick the "access to Storage" in the option. Does that mean I modify the GCE service account scope just for this instance?
In other words, what would I need to do in GCP which is equivalent to what I’d do in AWS (create a policy to reach S3, attach it to a role and attach this role to EC2)?
Many thanks for any help!
1 Answers
Firstly policies are a lot different in GCP than AWS. So the mapping would be
AWS GCP
user user be that through cloud identity, g-suite or gmail
group google groups
role service account – since in AWS you usually gives roles to services, like instance role, lambda execution role
policies role ( yuk – so policies say what you can do and so do roles in GCP)
Some differences:
Policies in AWS also contain the resource that you are allowed to act on.
In GCP the roles gives the permission in a generic sense as it’s not attached to a resource. It just says what apis yhou can use.
In GCP policies are used to bind permissions (GCP roles ) to an actual resource and at the same time bind who can use that permission, be that a user, group, or service account.
So for you answer
create a custom gcp role to allow actions on storage – but have not defined which bucket or who
create a specific compute engine service account.
create a VM with that compute engine service account.
On the folder. project or the storage resource add a policy binding to giving that the custom role, permission to the member a service account. of the VM in this case.
Although members ( user, group, service account ) can have roles. the roles just say they can use the api, it does not say on what resources.
The console when you create a service account, add some roles in the console does the binding for you at the project level. These are my projects bindings, so that is the magic of a console.
redacted@cloudshell:~ (compute-labs-redacted)$ gcloud projects get-iam-policy compute-labs-redacted
redacted@cloudshell:~ (compute-labs-redacted)$ gcloud projects get-iam-policy compute-labs-redacted
bindings:
members:
serviceAccount:service-redacted@compute-system.iam.gserviceaccount.com
role: roles/compute.serviceAgent
members:
serviceAccount:redacted-compute@developer.gserviceaccount.com
serviceAccount:redacted@cloudservices.gserviceaccount.com
role: roles/editor
members:
user:redacted@gmail.com
role: roles/owner
members:
serviceAccount:my-compute@compute-labs-redacted.iam.gserviceaccount.com
role: roles/storage.objectCreator
members:
serviceAccount:my-compute@compute-labs-redacted.iam.gserviceaccount.com
role: roles/storage.objectViewer
etag: BwWjGibB7Cs=
Don’ think of service accounts as actual accounts. It’s a bad name think of them as service roles.
Also when you use your own service account on a VM the scoping options are not available. So the scoping is only if using the default compute service account