By default, all Google Cloud Platform projects come with a single user: the original project creator. No other users have access to the project, and therefore, access to Compute Engine resources, until a user is added as a project team member. This page describes the different ways you can add new users to your project.
If you have applications running on a virtual machine instance, and the application needs access to Compute Engine or other Google Cloud Platform APIs, this page describes service accounts that can be used for this purpose.
Access control for users
To give users the ability to create and manage your Compute Engine resources, you can add users as team members to your project and grant them permissions using Identity and Access Management (IAM) roles. IAM provides two types of roles: predefined and primitive roles.
If you want to give a user only SSH access to one or more virtual machine instances and prevent access to all APIs, add a user's SSH keys to the project or instance.
Predefined IAM roles
Predefined roles grant a set of related permissions. Examples of predefined Compute Engine IAM roles are:
roles/compute.instanceAdmin.v1: Has all the permissions necessary to create and manage virtual machine instances.
roles/compute.networkAdmin: Has permissions to create and manage networking-related resources.
roles/compute.securityAdmin: Has permissions to manage security-related resources like firewalls and SSL certificates.
Each product has its own set of predefined roles. You can see a full list of available Compute Engine IAM roles and their permissions on the Compute Engine IAM documentation.
Primitive IAM roles
Primitive IAM roles map directly to the legacy project owner, editor, and viewer roles. Generally, you should use predefined roles whenever possible; however, in some cases, where IAM is not yet supported, you might need to use a primitive role to grant the correct permissions.
To learn more about primitive roles, read documentation for Primitive Roles.
If you are a G Suite member, your project might be part of an Organization resource. An Organization resource is the supernode in the Google Cloud Platform resource hierarchy that is closely associated with a G Suite account. Once an Organization resource is created for a G Suite domain, all Cloud Platform Projects created by members of the domain will belong to the Organization resource. An organization can implement Organization Policies which are policies that restrict allowed configurations across your entire Cloud Resource hierarchy. For example, you can use an organization policy to disable interactive access to the serial console so that even if a user attempts to enable access to the serial console, the policy prohibits it.
To set Organization Policies,
you must have been granted the
orgpolicy.policyAdmin role on the organization.
You can also set project-specific overrides in case you have exceptions to the
To learn more about Organizations, read the Organizations documentation.
To learn more about Organization Policies, read the Organization Policy documentation.
SSH access to virtual machine instances
If you just want to give a user the ability to connect to a virtual machine instance as an SSH user, but don't want to grant them the ability to manage your Compute Engine resources, add a user's public key to the project, or add a user's public key to a specific instance.
To learn more about SSH and managing SSH keys, read the SSH keys Overview.
Note that if you grant the
roles/compute.instanceAdmin.v1 role to a user, they
can automatically connect to instances using SSH, as long as the instance is
not set up to run as a service account. If the instance is set up to run as a
service account, you must also grant the user the
roles/iam.serviceAccountActor role in order for the user to connect to the
If you add a user as a project owner or editor, they also automatically have SSH access to virtual machine instances in the project.
Access control for virtual machine instances
If you run application code on instances and the application needs to authenticate to other Google Cloud Platform APIs, you can create service accounts and give these service accounts specific IAM roles to authenticate to other Cloud Platform APIs on your behalf. A service account is a special account that has no user credentials and is ideal for server-to-server interactions.
To learn more about service accounts, read the Service Accounts documentation.