Google Cloud Platform is secured with their Identity and Access Management system, which controls the permissions of each user in your project. If you switch from AWS, GCP does things a little differently.
How do permissions work?
If you are used to AWS named IAM systems, you may recognize some of the keywords here, but they mean different things. With Google IAM, you manage access control “by defining who (identity) has what an asset (role) for what a resource.”
First the identity. These can be Google Accounts for individual users or G Suite accounts that have access to the project, or a service account that can be used to provide application access, or an entire Google group. These different types of users will all have different ways of accessing GCP resources, but permissions are handled in the same way.
Several permissions are grouped in “Roles”; that are granted to specific users. Unlike AWS, roles do not provide detailed access to any particular resource. Instead, roles are general things that can be applied to multiple resources, such as “Instance Administrator”, “Viewer” or “Editor.” If linked to the user, it will grant project privileges for all resources in the account. If it is linked to an individual resource, it authorizes that resource.
Roles and identities are linked together in an IAM policy that governs which roles are assigned which identities. IAM policies are attached directly to instances not defined in the IAM console.
What you end up with is a system where you can simply add people to individual resources, such as Compute Engine instances, and give them specific roles that give them access to the specified resource.
Because of this, detailed permissions at the resource level are handled in those resource settings. For Compute Engine, you provide a list of members with a specific role, such as Instance Admin, which allows them to administer the instance.
Using the IAM console
All different IAM settings are handled in the IAM section of GCP. Under “IAM” you will find controls to show the members of the project, as well as add new members.
When you add or edit users, you can give them project-wide permissions, such as Viewer, Editor, or Owner, or specific permissions to apply to an entire resource type – just not specific resources such as individual Compute Engine instances or Cloud Storage buckets.
When it comes to permissions, there are many predefined ones, and because of how you manually assign them to specific resources, you do not need to create them nearly as often as for AWS policies. But if you want to edit them, you can do so from the “Roles” tab of the IAM console.
From here, click “Add Permissions” to edit the role.
There are many permissions here, so it definitely helps to filter them by service type and search for them manually. You can also filter by role to select permissions from predefined roles.