Role based access control

Roles

Basic (Primitive)

• Also referred to as coarse-grained roles, the three basic roles are: owner, editor, viewer and are concentric i.e owner permissions include editor permissions and editor permissions include viewer permissions
• These roles existed prior to the introduction of Cloud IAM in GCP and contain thousands of privileges across GCP services
• Their use is highly discouraged. Predefined or custom roles should be used instead

Predefined

• Also referred to as fine-grained roles
• A collection of permissions on a given GCP service e.g. Compute Engine
• Services offer their own predefined set of roles that can be applied to them
• Example predefined roles include roles/compute.admin, roles/compute.networkAdmin, roles/compute.storageAdmin

Custom

• A user-defined set of permissions tied to a role
• Existing predefined roles can be used as a starting point to create a custom role. In the example below, the “Cloud Tasks Viewer” Role is used as a starting point

Group & Policy Membership

The following member types are supported:

• Google Accounts (end users)
• Service Account (apps and VMs)
• Google Group
• Google Workspace (G-Suite) domain
• Google Cloud Identity domain

• Policies and groups both have members
• Policies can be applied to groups instead of individual accounts
• Groups also have an email addresses associated them

Google Workspace (G-Suite) and Cloud Identity domains contain a set of google accounts. When such a domain is added to a policy all the accounts contained therein are included in the membership.

Note: Users and Groups cannot be created in GCP Console – they must be separately created in Workspace or Cloud Identity

Google Cloud Directory Sync (GCDS)

Organisations with an existing identity provider (IDP) such as Active Directory or LDAP can utlise GCDS to import users and groups into Google Cloud Identity. In the example below, Active Directory Federated Services and Cloud Identity are used to control application access. With this approach, synchronisation is one way – no user data at the source AD/LDAP directory is modified by GCDS. See Federating GCP with Activty Directory for further details.

Single Sign On

Full integration with an organisations IDP is achieved through SSO configuration with one of the following supported authentication methods:

• Cloud Directory Sync
• Third party connectors:
  • PingIdentity
  • Otka
  • Centrify

All methods use SAML2

Service Accounts

• Service accounts are used by an application or a VM for server-to-server communication
• They do not have passwords cannot login via browsers or cookies – use RSA key pairs

Applications use service accounts to make either

• authorized API calls, authorized as either the service account itself
• Google Workspace or Cloud Identity users through domain-wide delegation

Applications running on an instance obtain credentials from a service account enabled on it to authenticate to APIs without having to store credentials locally on the machine

Account Types

Built-in (Compute Engine and App Engine)

All projects come with built-in default service accounts

• Compute Engine: <project_number>-compute@developer.gserviceaccount.com
• App Engine: <project_id>@appspot.gserviceaccount.com

Google API (Run Google processes)

A Google Cloud Platform API service account is provided to all projects with the address format:

• <project_number>@cloudservices.gserviceaccount.com
• Used to access internal Google services
• Granted Editor role on the project

Custom (User defined)

• User defined accounts assigned to virtual machines with custom roles in IAM
• Quota of 100 service accounts per project by default but can be increased
  • Default service accounts do not count towards this limit
• Format: <service-account-name>@<project_id>.iam.gserviceaccount.com

Access Scopes

• Access Scopes are the legacy approach to specifying permissions on an instance
• The level of access provided to a default service account on a VM instance is configured after the machine is created

• Note: a VM must be shutdown before its service account access scope can be adjusted
• Recommended best practice is to allow cloud-platform (Allow full access to all Cloud APIs) access when configuring the account and refine access through IAM policies
  • IAM restricts access to APIs based on IAM roles assigned to a service account
  • Access Scopes further control access to the gcloud tool and client libraries on the instance
• Default service accounts support primitive and predefined IAM roles
• Custom service accounts support predefined roles only
• Permissions can be delegated e.g.
  • A service account is assigned with certain roles on a given VM Instance
  • The roles/serviceAccountUser role is subsequently assigned to user(s). Caution: This role provides full access to any resource a service account has access to so you can inadverdently give a user more privilges to a resource than intended
  • The service account permissions are thus delegated to the user of that account