Manage Distributed Cloud Edge users

This page explains how to manage users in a Distributed Cloud Edge.

When you create a Distributed Cloud Edge cluster, only the user account you used to create the cluster is granted access to that cluster. To grant more users access to the cluster, you can do one of the following:

Grant the required permissions using Kubernetes RBAC

This section describes how to grant the permissions required by a user's business needs to the user's account using Kubernetes Role-Based Access Control (RBAC). These permissions are encapsulated by several roles. After you grant the appropriate role to a user account, you can add that account to the target Distributed Cloud Edge cluster.

Distributed Cloud Edge does not support Identity and Access Management groups or third-party identity providers for use with Kubernetes RBAC on Distributed Cloud Edge clusters.

You need to use the following Kubernetes resources to grant roles to users:

  • ClusterRole: allows you to apply a set of permissions to any namespace in the cluster; also grants access to cluster-wide resources.
  • ClusterRoleBinding: binds a ClusterRole resource to a user account.
  • Role: allows you to apply a set of permissions to a specific namespace.
  • RoleBinding: binds a Role or a ClusterRole resource to a user account in a specific namespace.

Grant permissions for a cluster administrator

When you create a Distributed Cloud Edge cluster, the user account you use to do so automatically becomes the cluster administrator. To grant cluster administrator permissions to additional users, bind the target user account to the cluster-admin role by creating a ClusterRoleBinding resource and apply it to the cluster:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: BINDING_NAME
subjects:
  kind: User
  name: ACCOUNT_NAME
roleRef:
  kind: ClusterRole
  name: cluster-admin
  apiGroup: rbac.authorization.k8s.io    

Replace the following:

  • BINDING_NAME: a name that uniquely identifies this role binding.
  • ACCOUNT_NAME: the name of the target user account.

You can also use the following kubectl command:

kubectl create clusterrolebinding "BINDING_NAME" \
  --clusterrole cluster-admin --user "ACCOUNT_NAME"

Replace the following:

  • BINDING_NAME: a name that uniquely identifies this role binding.
  • ACCOUNT_NAME: the name of the target user account.

Grant permissions for an application developer

To grant an application developer the permissions necessary to deploy workloads on the target cluster, do the following:

  1. Create a Role resource that grants the permissions to create and manage Pods, Services, and deployments in the target namespace and apply it to the cluster:

    apiVersion: rbac.authorization.k8s.io/v1
     kind: Role
     metadata:
       namespace: NAMESPACE
       name: ROLE_NAME
     rules:
       apiGroups: ["apps", ""]
       resources: ["pods", "deployments", "services"]
       verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
    

    Replace the following:

    • NAMESPACE: the name of the target namespace.
    • ROLE_NAME: a name that uniquely identifies this role.
  2. Create a RoleBinding resource that binds the target user accounts to the role you created in the previous step and apply to the cluster:

    apiVersion: rbac.authorization.k8s.io/v1
    kind: RoleBinding
    metadata:
     namespace: NAMESPACE
     name: BINDING_NAME
    subjects:
     kind: User
     name: ACCOUNT_NAME
     kind: User
     name: ACCOUNT_NAME
    roleRef:
     kind: Role
     name: ROLE_NAME
     apiGroup: rbac.authorization.k8s.io  
    

    Replace the following:

    • BINDING_NAME: a name that uniquely identifies this role binding.
    • NAMESPACE: the name of the target namespace.
    • ACCOUNT_NAME: the name of the target user account.
    • ROLE_NAME: the name of the target role.

Grant permissions for a Cloud Build Service Agent

To grant a Cloud Build Service Agent the permissions necessary to deploy workloads on the target cluster, do the following:

  1. Create a Role resource that grants the permissions to create and manage Pods, Services, and deployments in the target namespace and apply it to the cluster:

    apiVersion: rbac.authorization.k8s.io/v1
    kind: Role
    metadata:
     namespace: NAMESPACE
     name: ROLE_NAME
    rules:
     apiGroups: ["apps", ""]
     resources: ["pods", "deployments", "services"]
     verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
    

    Replace the following:

    • NAMESPACE: the name of the target namespace.
    • ROLE_NAME: a name that uniquely identifies this role.
  2. Create a RoleBinding resource that binds the target Cloud Build Service Agent account to the role you created in the previous step and apply to the cluster:

    apiVersion: rbac.authorization.k8s.io/v1
    kind: RoleBinding
    metadata:
     namespace: NAMESPACE
     name: BINDING_NAME
    subjects:
     kind: User
     name: PROJECT_ID@cloudbuild.gserviceaccount.com
    roleRef:
     kind: Role
     name: ROLE_NAME
     apiGroup: rbac.authorization.k8s.io  
    

    Replace the following:

    • BINDING_NAME: a name that uniquely identifies this role binding.
    • NAMESPACE: the name of the target namespace.
    • PROJECT_ID: the ID of the target Google Cloud project.
    • ROLE_NAME: the name of the target role.

If you need to grant a Cloud Build Service Agent permissions to deploy and manage workload across all namespaces on the target cluster, create a ClusterRole and a ClusterRoleBinding resource instead of the Role and RoleBinding resources.

Grant permissions for viewing cluster information

To grant the permissions necessary to view detailed information about the cluster in the Google Cloud console, do the following:

  1. Create a ClusterRole resource that allows the Connect Agent to impersonate the user that needs to view the cluster information in the Google Cloud console:

    apiVersion: rbac.authorization.k8s.io/v1
    kind: ClusterRole
    metadata:
     name: ROLE_NAME
    rules:
     apiGroups: [""]
     resources: ["users"]
     verbs: ["impersonate"]
     resourceNames: ["ACCOUNT_NAME"]
    

    Replace the following:

    • ROLE_NAME: the name of the target role.
    • ACCOUNT_NAME: the name of the target user account.
  2. Create a ClusterRoleBinding resource that binds the Connect Agent Service Agent account to the role you created in the previous step and apply to the cluster:

    apiVersion: rbac.authorization.k8s.io/v1
    kind: ClusterRoleBinding
    metadata:
     name: BINDING_NAME
    subjects:
     kind: ServiceAccount
     name: ACCOUNT_NAME
    roleRef:
     kind: ClusterRole
     name: ROLE_NAME
     apiGroup: rbac.authorization.k8s.io
    

    Replace the following:

    • BINDING_NAME: a name that uniquely identifies this role binding.
    • ACCOUNT_NAME: the name of the target service user account.
    • ROLE_NAME: the name of the target role.

You must create a separate ClusterRole and ClusterRoleBinding resource pair for each affected user.

You can also use the kubectl command-line tool to grant the permissions necessary to view cluster information as follows:

  1. Create a ClusterRole resource that allows the Connect Agent to impersonate the user that needs to view the cluster information in the Google Cloud console:

    kubectl create clusterrole "ROLE_NAME" --verb impersonate \
     --resource users --resource-name "ACCOUNT_NAME"
    

    Replace the following:

    • ROLE_NAME: the name of the target role.
    • ACCOUNT_NAME: the name of the target service user account.
  2. Create a ClusterRoleBinding resource that binds the Connect Agent Service Agent account to the role you created in the previous step and apply to the cluster:

    kubectl create clusterrolebinding "BINDING_NAME" --clusterrole \
     "ROLE_NAME" --serviceaccount "ACCOUNT_NAME"
    

    Replace the following:

    • BINDING_NAME: a name that uniquely identifies this role binding.
    • ACCOUNT_NAME: the name of the target service user account.
    • ROLE_NAME: the name of the target role.

Use connect gateway to access Distributed Cloud Edge clusters

You have the option to use connect gateway to access your Distributed Cloud Edge clusters. A connect gateway user needs one or more of the following roles depending on their business requirements:

  • Connect Gateway Admin (roles/gkehub.gatewayAdmin): grants access to the connect gateway API. This enables the use of the kubectl command-line tool for managing the cluster.
  • Gateway Gateway Editor (roles/gkehub.gatewayEditor): grants read and write access to the cluster.
  • Connect Gateway Reader (roles/gkehub.gatewayReader): grants read-only access to the cluster.
  • GKE Hub Viewer (roles/gkehub.viewer): grants the ability to retrieve kubeconfig files from the cluster.

For more information on using connect gateway, see the following: