GCP IAM Role Setup

Recommended Reading : https://cloud.google.com/iam/docs/overview


The Fluid-Slurm-GCP cluster is accessed by two different types of users

System Administrators

System Administrators (SysAdmins) typically are responsible for managing software packages, compute partition arrangements, slurm accounting, and network file storage. To fill this role, SysAdmins need to have ssh access to the cluster and root privileges. SysAdmins will sometimes work with or may also act as Google Cloud Administrators, helping manage Google Cloud projects and Identity and Access Management policies.


System Users

System users are typically researchers, scientists, or engineers that need to use the Fluid-Slurm-GCP cluster to carry out their work. They typically do not have root privileges on the cluster, but will leverage compute resources to execute scientific workloads.



Providing Access through Custom IAM Roles (Recommended)

Fluid Numerics has developed custom IAM roles that you can create in Google Cloud to provide the necessary access for SysAdmins and System Users. The table below provides the permissions you will need to align with the slurmAdmin and slurmUser custom roles.


These permissions give SysAdmins the ability to see compute instances from the Compute Engine UI and SSH to the instances within the cluster with root privileges. System users are given permissions that allow them to SSH into the cluster without root privileges.


To create the custom roles, you can follow the documentation from Google Cloud on creating custom roles.

Custom IAM Roles and Permissions

System Administrator

Custom Role Name: slurmAdmin

Permissions:

compute.instances.get

compute.instances.osAdminLogin

compute.instances.osLogin

compute.projects.get

iam.serviceAccounts.actAs

iam.serviceAccounts.get

iam.serviceAccounts.list

resourcemanager.projects.get

resourcemanager.projects.list

serviceusage.services.get

serviceusage.quotas.get

serviceusage.services.list

System User

Custom Role Name: slurmUser

Permissions:

compute.instances.get

compute.instances.osLogin

compute.projects.get

iam.serviceAccounts.actAs

iam.serviceAccounts.get

iam.serviceAccounts.list

resourcemanager.projects.get

resourcemanager.projects.list

Once the custom roles are defined, you can assign the slurmAdmin and slurmUser roles to the appropriate users by following the Google Cloud Documentation for Granting Access.

Providing Access through Predefined IAM Roles

As an alternative to using custom roles, you can provide access to SysAdmins and System Users using predefined roles. The table below provides the roles you will want to align with SysAdmins and System Users in your organization.

These roles give SysAdmins the ability to see compute instances from the Compute Engine UI and SSH to the instances within the cluster with root privileges. System users are given permissions that allow them to SSH into the cluster without root privileges. Additionally, these roles allow users to view and access compute engine instances from the Compute Engine UI, in addition to 3rd party SSH tools.

System Administrator

Predefined Roles:

Service Account User

Compute OS Admin Login

System User

Predefined Roles:

Service Account User

Compute OS Login

To assign roles to users in your organization, use the above table and the Google Cloud Documentation for Granting Access.


Managing Permissions through GSuite Groups (Optional, Recommended)

G Suite and Cloud Identity provide groups that can be used to easily assign permissions to one or more users by specifying a group email address in IAM policies. There are a number of ways to create groups. We recommend using https://admin.google.com to create and manage groups.


Within the Admin panel, you can create groups for SysAdmins and System Users. For example, you could create

  1. slurm-admins@my-organization.com
  2. slurm-users@my-organization.com


From the Admin panel, you can add users in your organization to the appropriate group. Then, when assigning IAM policies in Google Cloud (with either custom or predefined roles), you can use the group email address rather than the individual users. This makes IAM policies across GCP much simpler than assigning roles to individual users.