Google Cloud Platform is secured with their Identity and Access Management system, which controls the permissions for each user in your project. If you’re switching from AWS, GCP does things a little differently.
How Do Permissions Work?
If you’re used to AWS’s namesake IAM system, you may recognize some of the keywords here, but they mean different things. With Google’s IAM, you manage access control “by defining who (identity) has what access (role) for which resource.”
First, the identity. These can be individual user Google accounts or G Suite accounts which have access to the project, or a service account that can be used to give 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 the same.
Multiple permissions are grouped into “Roles,” which are granted to specific users. Unlike AWS, roles don’t give granular access to any particular resource. Instead, Roles are general things that can be applied to multiple resources, like “Instance Admin,” “Viewer,” or “Editor.” If attached to the user, it will give project-wide permissions for all resources in the account. If attached to an individual resource, it will give permissions for that resource.
Roles and Identities are linked together in an IAM Policy, which enforces which roles are granted to 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, like Compute Engine instances, and give them specific roles that allow them access to the given resource.
Because of this, granular permissions are handled at the resource level in that resources settings. For Compute Engine, you give a list of members a specific role, like Instance Admin, that allows them to administrate the instance.
Using The IAM Console
All of IAM’s various settings are handled in the IAM section of GCP. Under “IAM,” you’ll find controls for viewing the members for the project, as well as adding new members.
When adding or editing users, you can give them project-wide permissions, like Viewer, Editor, or Owner, or specific permissions to apply to a whole resource type—just not specific resources like individual Compute Engine instances or Cloud Storage buckets.
As for permissions, there are plenty of them predefined, and due to the way you assign them manually to specific resources, you won’t have to create them nearly as often as you would for AWS policies. However, if you want to edit them, you can do so from the “Roles” tab in the IAM console.
From here, click “Add Permissions” to edit the role.
There’s a lot of 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.
