Manage access to standard clusters

Standard

This document explains how to manage permissions for standard clusters in Google Distributed Cloud (GDC) air-gapped using the gdcloud CLI. Standard clusters are project-scoped, configurable Kubernetes environments with minimal default services that offer greater flexibility and control for custom workloads.

For more information about standard clusters and other cluster types, see Kubernetes cluster configurations.

This document is for audiences within the application operator group, such as developer operations or data scientists, who need to manage and secure resources within GDC projects. For more information, see Audiences for GDC air-gapped documentation.

Before you begin

Before managing access to standard clusters, you must have the necessary permissions and prepare your environment.

Request IAM roles

Contact your Organization IAM Admin to request the following roles based on the tasks you need to perform:

Project IAM Admin (project-iam-admin): create, update, and delete role bindings for standard clusters within a project.
Standard Cluster Admin (standard-cluster-admin): create, update, and delete role bindings within a specific standard cluster.

Prepare your environment

Download and install the gdcloud CLI, if you haven't already done so.
Install the kubectl CLI, as described in Install components.

Grant permissions for standard cluster access

A user with the Project IAM Admin (project-iam-admin) role can grant other users the necessary roles for managing access within standard clusters:

Sign in with your configured identity provider using the gdcloud CLI.
Grant the user the Standard Cluster Admin (standard-cluster-admin) role for the project. This command binds the user to the role, allowing them to manage access within the standard cluster.

See Predefined role descriptions and Role definitions for projects for more information about the roles.
```
gdcloud projects add-iam-policy-binding PROJECT \
  --role=ROLE \
  --member=user:USER_ACCOUNT
```
Replace the following variables:
- PROJECT: the name of the project where the standard cluster exists.
- ROLE: the name of the role you want to grant (such as standard-cluster-admin).
- USER_ACCOUNT: the user account for which you want to grant the role, including the identity provider prefix associated with your organization (such as idpprefix-user@example.com). The specific prefix used depends on your organization's IdP configuration. See Connect to an identity provider for more information.
The following example grants the Standard Cluster Admin role to user@example.com, assuming the identity provider prefix is fop- for project foo:
```
gdcloud projects add-iam-policy-binding foo \
  --role=standard-cluster-admin \
  --member=user:fop-user@example.com
```

Manage access within the standard cluster

A user with the Standard Cluster Admin (standard-cluster-admin) role can grant access within a standard cluster:

Sign in with your configured identity provider using the gdcloud CLI.
Generate a kubeconfig file for a standard cluster using the --standard flag. This flag is required to target a standard cluster.
```
export KUBECONFIG=KUBECONFIG_FILE
gdcloud clusters get-credentials STANDARD_CLUSTER_NAME --standard --project=PROJECT
```
Replace the following variables:
- KUBECONFIG_FILE: the path to the kubeconfig file such as standard-cluster-kubeconfig.yaml.
- STANDARD_CLUSTER_NAME: the name of the standard cluster.
- PROJECT: the name of the project where the standard cluster exists.
Define permissions within the standard cluster using kubectl.

Users with standard-cluster-admin permissions can create custom Role and ClusterRole objects. To grant these permissions, they can create the corresponding Rolebinding and ClusterRoleBinding objects to bind the roles to specific subjects, such as users or service accounts.

Note: Users can only grant permissions they already possess. They can't use this access to escalate their own permissions.

The following example uses kubectl to create a sample custom Role named test-role in the test namespace:
```
kubectl apply -f - <<EOF
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: test-role
  namespace: test
rules:
- apiGroups:
  - ""
  resources:
  - configmaps
  verbs:
  - get
EOF
```
The following example creates the RoleBinding for the Role named test-role in the test namespace. It grants permissions to the user alice@example.com with the identity provider prefix fop-, as well as to a ServiceAccount named my-service-account in the default namespace:
```
kubectl apply -f - <<EOF
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: test-role-binding
  namespace: test
subjects:
- kind: User
  name: fop-alice@example.com
  apiGroup: rbac.authorization.k8s.io
- kind: ServiceAccount
  name: my-service-account
  namespace: default
roleRef:
  kind: Role
  name: test-role
  apiGroup: rbac.authorization.k8s.io
EOF
```