Managing Batch on GKE users

Before you begin

You must have already installed Batch on GKE.

  1. Get the admin tools:

    git clone
  2. Go to the admin tools directory:

    cd admintools

Granting permissions

To use Batch on GKE, users must be able to authenticate to the Kubernetes cluster with container.clusters.get. This permission allows users to run: gcloud container clusters get-credentials <var>cluster-name</var>

This permission needs to be granted to every user in each GCP project. Once you grant permissions, it works for every cluster in that project.

There are two options to grant this permission:

  1. Create a custom role and policy binding.

    To create a custom role with the container.clusters.get permission, run the following command:

    gcloud iam roles create BatchUser --project [PROJECT_ID] \
     --title GKEClusterReader --permissions container.clusters.get --stage BETA 2>&1

    Then grant the role to a user:

    gcloud projects add-iam-policy-binding [PROJECT_NAME] \
     --member=user:[USER_EMAIL] \
  2. Grant the predefined containers.clusterViewer role to the user.

    gcloud projects add-iam-policy-binding [PROJECT_NAME] --member=user:[USER_EMAIL] --role=roles/container.clusterViewer

Adding BatchUsers

To allow users to submit batch jobs, you must grant them certain Kubernetes RBAC (role-based access control). To add a new user, go to the users directory:

cd users

Adding a user without an auto PVC

Batch provides a script to add all the necessary RBACs in one step:

./ -s [SHORT_NAME] -u [USER'S_NAME] \
  -n [NAMESPACE] --project [PROJECT_ID] --security-policy [UID],[GROUP_ID]

This command generates the following RBACs for the user:

  • A BatchUserContext (named [SHORT_NAME]-[NAMESPACE]) with the UIDid and group ID configured as MustRunAs.
  • A k8s ClusterRole and ClusterRoleBinding (named [SHORT_NAME]-cr) to grant the user the read permission of BatchCostModel and BatchPriority.
  • A k8s Role and RoleBinding (named [SHORT_NAME]-[NAMESPACE] to grant create and read permission to BatchJobs in the namespace.

With all these permissions, a user can submit BatchJobs in the specified Namespace.

Adding a user with a private PVC

If you set up FileStore and a NFS auto provisioner in your cluster, you can run the following command to add a user and create a private PVC:

  --project [PROJECT_ID] --auto-pvc --security-policy "2000,3000"

Where 2000 is the UID and 3000 is the GID.

In addition to the RBACs, --auto-pvc flag will cause an NFS-based PVC to be created. The NFS auto provisioner creates a folder under the NFS server. Additional resources are created inside the namespace for user include:

A PersistentVolumeClaim named [SHORT_NAME]-[NAMESPACE]. A PersistentVolume which is bound to the PVC above. Grant the user the RBACs to use that PVC.

Adding a user with shared PVC

To add a user and grant access to specific PVCs, run the following command:

  --project [PROJECT_ID] --pvcs [PVC_NAME],[PVC_NAME] --security-policy "2000,3000"

Deleting a user

To remove a user's ability to submit and view BatchJobs, run the following command:


The [SHORT_NAME] is the same as the short name used when the user is added.

Customizing user settings

BatchUserContext (BUC) is a Batch API resource that configures a job's security context. BatchUserContext associates a user with a PodSecurityPolicySpec. It defines the security context for the batch jobs submitted by that user.

Some important things that can be configured by BatchUserContext are:

  • Unix Identity (UID) that the job will run as
  • Whether the job can run in privilege mode as root.
  • The type of volumes that can be used by this user.

When a job is submitted Batch performs the following two operations based on BUC:

  • Validates that the BatchJob spec does not violate the policy. For example, if the policy prevents a BatchJob from running in privileged mode, but the BatchJob has the "privileged" field set to true, the job submission will fail.

  • Copies values from the BUC to empty fields in the job spec. For example, if the UID in the BUC is set to MustRunAs: 3000 and the job doesn't have a RunAs value set, Batch will accept the BatchJob and set the RunAs field to be 3000.

Refer to PodSecurityPolicySpec for descriptions of all the fields.

For example, the default BatchUserContext is:

kind: BatchUserContext
  labels: "1.0"
  name: alice-default
  namespace: default
  userName: "*"
    privileged: false
    allowPrivilegeEscalation: false
      - ALL
      - 'configMap'
      - 'emptyDir'
      - 'secret'
      - 'downwardAPI'
      - 'persistentVolumeClaim'
    hostNetwork: false
    hostIPC: false
    hostPID: false
      rule: 'MustRunAs'
        - min: 12345
          max: 12345
      rule: 'RunAsAny'
      rule: 'MustRunAs'
        - min: 12345
          max: 12345
      rule: 'MustRunAs'
        - min: 12345
          max: 12345
      rule: 'MustRunAs'
        - min: 12345
          max: 12345

Creating a BatchUserContext

To create a BatchUserContext run the following command:

kubectl create -f [NAME]-default-buc.yaml

Updating a BatchUserContext

To change a BatchUserContext run the following command once you have saved your changes to the file:

kubectl apply -f [NAME]-default-buc.yaml

Deleting a BatchUserContext

To delete a BatchUserContext run the following command:

kubectl delete -f [NAME]-default-buc.yaml

What's next