Grant and revoke access

Every subject - a user or a group - follows a two-step process to gain access to the admin cluster, and system and user clusters:

• Admin cluster access: Grant a subject with permissions in the admin cluster using ClusterRoleBinding or RoleBinding to a predefined ClusterRole.

• User cluster access: Create a ProjectRole and ProjectRoleBinding to propagate a Kubernetes Role and RoleBindings to Kubernetes Namespaces in system and user clusters (corresponding to the Project that the ProjectRole and ProjectRoleBinding are in).

Note: You can bind one subject to multiple roles in admin clusters and user clusters. Permissions are purely additive, and there are no deny rules.

Note: You can grant a subject with only user cluster access through ProjectRoles and ProjectRoleBindings that another person has created. The subject has no access in the org admin cluster.

Personas (IO, PA, AO) are not roles but are collections of user roles mapped to specific permissions and assigned to individual users.

Both the Organization IAM Admin and the Project IAM Admin can create more project roles and project role bindings to grant additional project-specific permissions. However, Organization IAM Admins can create project roles and project role bindings for any project. On the other hand, Project IAM Admins can only create project roles and project role bindings for projects they have permission to access.

Set up role bindings

You can set up role bindings that give team members access to resources at the organization or project level.

To get the permissions that you need to set up role bindings, ask your Organization IAM Admin to grant you the Organization IAM Admin role.

To assign a role to an authorized member, follow these steps:

Console

1. Sign in to the GDC console.
2. Click Select project to select an organization or project.
   
   • To set up role bindings for an organization, select an organization.
   • To set up role bindings for a project, select a project.
3. In the navigation menu, click Identity and Access > Access.
4. Click Add member.
5. In the Identity provider list, select an identity provider.
6. Choose whether you want to add individual users or groups.
7. In the Username or group alias field, enter the username, email address, or alias.
8. In the Role list, select the role that you want to assign to the user or group, such as Organization Viewer at the organization level or Project Creator at the project level.
9. Click Add.

The member appears in the Authorized member list.

CLI

1. Export the user credential that you use:

   export YOUR_IAM_ADMIN_KUBECONFIG=YOUR_IAM_ADMIN_KUBECONFIG
   

2. Export the email account of the user that you want to assign the role, such as [e-mail]:

   export USER_EMAIL=USER_EMAIL
   

   Note: The user email needs to include the identity provider prefix.

3. Export the name of the role the user needs, such as project-creator. Refer to Role descriptions to find the according role.

   export ROLE_NAME=ROLE_NAME
   

4. Assign a user to a ClusterRole or a Role:

   • Assign a user to a ClusterRole:

     kubectl create --kubeconfig ${YOUR_IAM_ADMIN_KUBECONFIG} \
     clusterrolebinding ${USER_EMAIL}-${ROLE_NAME}-binding \
     --clusterrole=${ROLE_NAME} --user=${USER_EMAIL}
     

     For cases when a ClusterRole requires a RoleBinding instead of a ClusterRoleBinding, refer to the Role descriptions to find out what binding type the role needs and create a RoleBinding in the namespace gpc-system instead:

     kubectl create --kubeconfig ${YOUR_IAM_ADMIN_KUBECONFIG} \
     rolebinding ${USER_EMAIL}-${ROLE_NAME}-binding \
     --clusterrole=${ROLE_NAME} --user=${USER_EMAIL} --namespace=gpc-system
     

   • Assign a user to a Role:

     1. Export the namespace where the binding must be created:

        export BINDING_NAMESPACE=BINDING_NAMESPACE
        

     2. Run the following commands to create a RoleBinding:

        kubectl create --kubeconfig ${YOUR_IAM_ADMIN_KUBECONFIG} \
        rolebinding ${USER_EMAIL}-${ROLE_NAME}-binding \
        --role=${ROLE_NAME} --user=${USER_EMAIL} --namespace=${BINDING_NAMESPACE}
        

Remove role bindings

When access is no longer required, remove a member and their associated roles, permissions, and access.

To remove members, work through the following steps:

Console

1. Sign in to the GDC console.
2. In the navigation menu, click Identity and Access > Access.
3. In the Authorized members list, select a member.
4. Click Remove member.
5. When prompted, click Remove member to confirm.

CLI

Delete the ClusterRoleBinding to revoke the permission granted to the PA account:

kubectl --kubeconfig ${YOUR_IO_SECURITY_ADMIN_KUBECONFIG} \
delete clusterrolebinding ${PA_EMAIL}-pa

Revoke user access

If a member leaves your organization or team, you can revoke their access to Google Distributed Cloud (GDC) air-gapped appliance. Revoking a user's access logs them out of GDC air-gapped appliance and denies their roles and permissions. You can also list the user's activity and sessions from their start and end time.

To revoke a user's access, do the following:

1. Revoke the user's access:

   gdcloud admin auth revoke --accounts USER_EMAIL
   

   Replace USER_EMAIL with the email of the user to revoke access.

   After running the command, you see output similar to the following. This example revokes access from the user [e-mail]:

   Success: NUMBER of sessions revoked for user [e-mail]
   

   In this example, the variable NUMBER refers to the number of active sessions the user had.

2. Confirm you've revoked the user's access by running the gdcloud admin auth revoke command again. If successful, you see the following:

   No sessions found for account: [e-mail]
   

List all revoked users

To view all revoked users and their activity and sessions, do the following:

• List all revoked users from their start and end time:

  gdcloud admin auth list --format="csv(ACCOUNT, IDENTITY_PROVIDER, CREATION_TIME, EXPIRATION_TIME)"
  

  If successful, you see output similar to the following:

  account,identity_provider,creation_time,expiration_time
  [e-mail],example-idp,2023-02-15 22:10:52,2023-02-15 23:10:52