Configure authorization roles

This page is for infrastructure operators.

This page describes authorization roles, role bindings, and resource access rights for Anthos private mode.

Authorization roles

Anthos private mode has four preset authorization roles:

Role name Kubernetes ClusterRole name (on admin cluster) Permissions
Infrastructure operator anthos-infrastructure-operator Full read/write access to all resources.
Infrastructure operator (read-only) anthos-infrastructure-operator-read-only Read-only access to most things in Management Center, ClusterRole/Role, ClusterRole/Role bindings and limited read access to secrets.

Users have write access to Grafana to edit dashboards.

Platform admin anthos-platform-admin
  • Read/write access to user clusters, Anthos feature management, Anthos Identity Service and Anthos Config Management.
  • Read and delete access to machines.
  • Read-only access to Bootstrap Service.
Platform admin (read-only) anthos-platform-admin-read-only Read-only access to everything that a platform admin can view.

Users have write access to Grafana to edit dashboards.

Anyone with access to ADMIN_KUBECONFIG is authenticated as a member in the Kubernetes system:master group which allows any action to the Kubernetes API server. For example, they can list all secrets by running:

kubectl get secrets --all-namespaces --kubeconfig=${ADMIN_KUBECONFIG}

Where ${ADMIN_KUBECONFIG} is the path of the kubeconfig file for the admin cluster.

Access using ADMIN_KUBECONFIG is authenticated as the generic username admin, which makes it difficult to track the person who runs the command. Consequently, it's important to keep ADMIN_KUBECONFIG in a secure place, and only use it when necessary (for example when setting up initial platform administrator role bindings, or recovering from OIDC failures).

Management Center and metrics access

Anthos private mode automatically syncs any users bound to these four roles into the allowlist of Anthos Management Center and metrics (Grafana) access.

Roles with read-only access rights are denied if trying to perform a write action in Management Center.

Role bindings

When setting up OIDC in Management Center Console, you can set an initial user bound to the platform admin role. With a logged in kubeconfig for the initial platform admin user, there are two approaches to bind another user to the platform admin role:

(Recommended) Set up GroupMembership in the OIDC provider and create role bindings based on Group

This approach binds one of your groups to a preset role to grant all members in the group with the same access rights as the preset role.

Before you begin

Check the following things before starting:

  • Determine the OIDC provider that the group is from.
  • The Groups Claim field in the OIDC Profile tab must be the same as the name of the claim which contains group membership information on your OIDC provider side. Anthos private mode gives this field a default value of groups, but if your OIDC provider has a different value, make sure you've set it in the OIDC Profile tab
  • Take a note of the Group Prefix in the OIDC Profile tab. You must include the group prefix before all your group names. For example, if you have gid- as the group prefix and a group "admin-group" in your OIDC provider, you must use gid-admin-group. Note that the - separator is the part of the group prefix, and the system does not add any separator for you.

Manage bindings using Management Center Console

You can use the Access tab in Management Center Console to manage your role bindings based on groups. Apply identity profile during cluster creation

You cannot add or update a binding to a role with more privilege than your current logged in account. For example, if you are logged in as a platform admin, you cannot bind a group to an infrastructure operator role.

Manage bindings using kubectl

Alternatively, run the following command to create a role binding based on Group. The value passed to group= must be the same as your group name in the OIDC provider prefixed with your group prefix:

kubectl create clusterrolebinding anthos-platform-admin-group-binding \
--kubeconfig=ADMIN_OIDC_KUBECONFIG --clusterrole=anthos-platform-admin \
--group=gid-anthos-platform-admin-group

Any user that you added to anthos-platform-admin-group in the OIDC provider now has all of the platform admin permissions.

Similarly, you can use the following command to bind a group to the platform admin (read-only) role:

kubectl create clusterrolebinding anthos-platform-admin-read-only-group-binding \
  --kubeconfig=ADMIN_OIDC_KUBECONFIG --clusterrole=anthos-platform-admin-read-only \
  --group=gid-anthos-platform-admin-read-only-group

To prevent privilege escalation, a platform admin cannot bind a group to an infrastructure operator or an infrastructure operator (read-only) role. To initialize the first group of infrastructure operators, you need ADMIN_KUBECONFIG:

kubectl create clusterrolebinding anthos-platform-operator-group-binding \
  --kubeconfig=${ADMIN_KUBECONFIG} --clusterrole=anthos-infrastructure-operator --group=gid-anthos-platform-operator-group

After that, you can use a KUBECONFIG with a logged in infrastructure operator account to bind other groups to any roles:

# Bind a group to infrastructure operator (read-only):
kubectl create clusterrolebinding anthos-platform-operator-read-only-binding \
  --clusterrole=anthos-infrastructure-operator-read-only --group=gid-anthos-platform-operator-read-only-group --kubeconfig=${ADMIN_OIDC_KUBECONFIG}

Create role bindings based on User

You can also create role bindings based on the User role. The commands to create role bindings are similar to using Group. Replace --group with --user.

You must also append your user prefix of your OIDC profile to every username. For example, if your OIDC provider is set to have a user prefix uid- and you want to bind joedoe@example.com to a role, use uid-joedoe@example.com.

You can also use the Access tab in Management Center Console to manage role bindings to users.

Here is a sample command to create a role binding for charlie@example.com and grant it platform admin permissions:

kubectl create clusterrolebinding charlie-platform-admin-binding \
  --clusterrole=anthos-platform-admin --user=uid-charlie@example.com --kubeconfig=ADMIN_OIDC_KUBECONFIG

To delete one role binding to remove a user's access rights, you can update existing bindings instead of deleting them (e.g. revoke Platform Admin right of charlie@example.com ):

kubectl patch clusterrolebinding charlie-platform-admin-binding \
  -p '{"subjects":[]}' --kubeconfig=${ADMIN_OIDC_KUBECONFIG}

You can also ask your infrastructure operator to delete the ClusterRoleBinding.

Notes

  • See more information about authorization in Using RBAC Authorization
  • No preset authorization roles are set in the user clusters. Kubernetes API server access in each user cluster access is open to anyone who has the kubeconfig.
  • Platform admins are not allowed to delete a role binding, to prevent platform admins from deleting bindings for higher privileged users. To revoke a user's access, you can update the role binding that binds the user to an empty subject list. The deletion action in the Identity and Access page of Management Center Console also updates the role bindings to an empty subject list instead of deleting the bindings for the same reason.
  • The name of the ClusterRoleBinding resource must be unique. Only the latest binding applied or created takes effect when there are multiple cluster role bindings with the same name.

Kubernetes resource access rights for each preset role

This section provides details of all the Kubernetes resource access rights for each preset role.

Infrastructure operator

The infrastructure operator role corresponds to the Kubernetes anthos-infrastructure-operator role, which can perform any verbs on any resources.

Infrastructure operator (read-only)

The infrastructure operator (read-only) role corresponds to the Kubernetes anthos-infrastructure-operator-read-only role, which can read all resources in the ApiGroups listed here with limited read access to Secret. The read access to Secret is only limited to admin cluster access token, user cluster kubeconfig, and secrets with a logmon label in the kube-system for logging and monitoring.

ApiGroups Resource Verbs
"" configmaps get, list, watch
"" endpoints get, list, watch
"" persistentvolumeclaims get, list, watch
"" persistentvolumeclaims/status get, list, watch
"" pods get, list, watch
"" replicationcontrollers get, list, watch
"" replicationcontrollers/scale get, list, watch
"" serviceaccounts get, list, watch
"" services get, list, watch
"" services/status get, list, watch
"" bindings get, list, watch
"" events get, list, watch
"" limitranges get, list, watch
"" namespaces/status get, list, watch
"" pods/log get, list, watch
"" pods/status get, list, watch
"" replicationcontrollers/status get, list, watch
"" resourcequotas get, list, watch
"" resourcequotas/status get, list, watch
"" namespaces get, list, watch
apps * get, list, watch
autoscaling * get, list, watch
batch * get, list, watch
cert-manager.io * get, list, watch
extensions * get, list, watch
metrics.k8s.io * get, list, watch
networking.k8s.io * get, list, watch
policy * get, list, watch
rbac.authorization.k8s.io * get, list, watch
addons.gke.io * get, list, watch
authentication.gke.io * get, list, watch
baremetal.cluster.gke.io * get, list, watch
cluster.x-k8s.io * get, list, watch
managementcenter.anthos.cloud.google.com * get, list, watch

Platform admin

The platform admin role has the following access rights:

Resource Verbs
namespaces get, list, watch, create, update
pods get, list, watch
services get, list, watch
events get, list, watch
configmaps get, list, watch
deployments get, list, watch
daemonsets get, list, watch
replicasets get, list, watch
statefulsets get, list, watch
jobs get, list, watch
cronjobs get, list, watch
memberships.managementcenter.anthos.cloud.google.com get, list, watch, create, update, delete
onpremuserclusters.managementcenter.anthos.cloud.google.com get, list, watch, create, update, delete
clusters.baremetal.cluster.gke.io get, list, watch, create
nodepools.baremetal.cluster.gke.io get, list, watch, create
clusters.cluster.x-k8s.io get, list, watch
machines.baremetal.cluster.gke.io get, list, watch
inventorymachines.baremetal.cluster.gke.io get, list, watch
addresspools.managementcenter.anthos.cloud.google.com get, list, watch
bootstrapservicebindings.managementcenter.anthos.cloud.google.com get, list, watch, create, update, delete
bootstrapservices.managementcenter.anthos.cloud.google.com get, list, watch
bootstrapservicebindingitems.managementcenter.anthos.cloud.google.com get, list, watch
adminoperators.managementcenter.anthos.cloud.google.com get, list, watch
clientconfigs.authentication.gke.io get, list, watch, create, update, delete
configmanagementbindings.managementcenter.anthos.cloud.google.com get, list, watch, create, update, delete
configmanagementfeaturespecs.managementcenter.anthos.cloud.google.com get, list, watch, create, update, delete
configmanagementbindingitems.managementcenter.anthos.cloud.google.com get, list, watch, create, update, delete
servicemeshbindings.managementcenter.anthos.cloud.google.com get, list, watch, create, update, delete
servicemeshfeaturespecs.managementcenter.anthos.cloud.google.com get, list, watch, create, update, delete
servicemeshbindingitems.managementcenter.anthos.cloud.google.com get, list, watch, create, update, delete
identityservicebindings.managementcenter.anthos.cloud.google.com get, list, watch, create, update, delete
identityservicefeaturespecs.managementcenter.anthos.cloud.google.com get, list, watch, create, update, delete
identityservicebindingitems.managementcenter.anthos.cloud.google.com get, list, watch, create, update, delete
updatablecomponents.managementcenter.anthos.cloud.google.com get, list, watch
domainconfigs.managementcenter.anthos.cloud.google.com get, list, watch, create, update, delete
logmons.addons.gke.io get, list, watch, create, update, delete
clusterrolebindings.rbac.authorization.k8s.io get, list, watch, create, update

Platform admins have read access to secrets to allow them to obtain a kubeconfig which is authenticated as a cluster-admin role to a user cluster.

Platform admins can read and write secrets and configmaps with a logmon label in the kube-system in order to configure Logmon.

Platform admin (read-only)

The platform admin (read-only) role has the same access rights as a platform admin except:

  • All write-related verbs (create, update, and delete) are not granted.
  • For access to a user cluster, a platform admin (read-only) can only read a kubeconfig that is authenticated as a view role in the user cluster.