A user represents an authenticated account that can access a hybrid organization and the entities within that organization, such as the environments, API proxies, and keystores.
To add a new user to your Apigee organization, you grant access to the user’s account, first in the GCP project and then in the hybrid UI. (This document uses the terms “user” and “user account” interchangeably.)
When you add a new user, you typically:
- In the GCP Console, assign the new user to one or more roles in your GCP
project. This gives the user broad access to all environments in the hybrid organization.
For more information, see Manage access in the GCP.
- In the hybrid UI, refine that new user’s access by specifying one or more
roles per environment in your hybrid organization.
For more information, see Manage users in the hybrid UI.
About role inheritance
The capabilities that you grant to the user account depend on the type of role that you assign to them. For example, you might assign a developer to the role of API Creator so that they can create API proxies, KVM, and shared flows. For someone that will deploy proxies, you might assign them to the role of Deployer, which grants them the ability to deploy and undeploy API proxy revisions. For details about all Apigee roles, see Apigee roles.
Additionally, the resources that a user can access based on their role depends on where you assigned the role:
- GCP project: If you assign a role in the GCP Console (on the GCP project), then the user can access all hybrid resources—all environments and resources within those environments—in that role. This is because the GCP project is the parent of the hybrid UI in the resource hierarchy; the permissions set on the parent (the GCP project) are inherited by all children (hybrid environments). You can refine this access by specifying user roles on a per environment basis in the hybrid UI.
- Environment access: If you assign a role in the hybrid UI, the user only acts as that role for the selected environment. This assignation supersedes settings at the GCP project level. However, these role assignments are for the selected environments only—role assignments for all other environments continue to inherit the GCP project's settings.
The following image shows how inheritance works with this access model:
When you add a specific role to a user at one of these levels, the user has access to all resources below that level in that role by default. Because a hybrid environment is considered a resource underneath the GCP project, permissions set on the GCP project apply to all environments unless you specify more fine-grained permissions on the environment in the hybrid UI.
For example, if you define a user as an API Creator on the GCP project only and don’t specify per-environment roles in the hybrid UI, then that user will have access—as an API Creator— to all environments in your hybrid organization.
Apigee recommends that you do the following for each new user account that you add. (When adding “super users” or administrators, this is not necessary.):
- In the GCP Console, add the new user account and select a role that has a minimal set of permissions. For example, set the role of a new user to API Creator.
- In the hybrid UI's Environment Access view, add the user and set the appropriate roles for each environment in the organization as described in Manage users. This lets you apply more fine-grained permissions after you grant the user access to the project in the GCP Console.
To reiterate: To specify that a user should have permissions only to certain environments, grant an appropriate role on the environment in the hybrid UI after adding them to the project in the GCP Console.
About GCP access control
Access control in Google Cloud Platform is controlled using Cloud Identity and Access Management (Cloud IAM). Cloud IAM lets you set permissions specifying who has what kind of access to which resources in your project.
Users are a type of member, a broad term that refers to an identity that can be granted access to resources. Other types of GCP members include service accounts, Google groups, and G Suite domains. For more information, see this overview of Cloud Identity and Access Management.