Google Cloud Platform permissions management is a critical part of managing your Google Cloud Platform account. By understanding how permissions work and setting up rules to manage who has access to what, you can keep your data safe and secure. In this article, we’ll take a look at the basics of permission management in Google Cloud Platform. We’ll start with an overview of the different types of permissions and then explore how to set up rules to manage who has access to what. Overview of Permissions in Google Cloud Platform There are three types of permissions in Google Cloud Platform: user, group, and resource. User permissions are used for individual users or groups. Group permission is used for groups of users that have been assigned the same rights as a single user. Resource permission is used for resources such as servers or data sets that have been assigned specific rights to be accessed by only certain users or groups. User Permissions in Google Cloud Platform User permissions are used for individual users or groups. A user can be a single user, an organization, or a combination thereof. A user’s role in a group is determined by their affiliation with the group (i.e., whether they are a member). When creating or joining a new group, you must specify the name and affiliation of the group’s members before you can create any memberships for them (you cannot join an existing group without specifying its members). To join a new group, type its name into the Join Group dialog box and click on Join . After joining the group, all members of that group have access to all its resources (including any resources owned by other groups within Google Cloud Platform). If you want to restrict access to some members of your team while allowing others full access, you can use resource permission instead of user permission when creating new servers or data sets. For more information on using resource permission instead of user permission see: How To Use Resource Permission Instead Of User Permission When Creating New Servers
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.
