Google Certified Associate Cloud Engineer 2020

Sign Up Free or Log In to participate!

Roles and policies compared to AWS

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)?

  • When 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


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


  • members:


role: roles/compute.serviceAgent

  • members:



role: roles/editor

  • members:


role: roles/owner

  • members:


role: roles/storage.objectCreator

  • members:


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

Sign In
Welcome Back!

Psst…this one if you’ve been moved to ACG!

Get Started
Who’s going to be learning?