Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Warning

This page was translated from the original Japanese version by PLaMo Translate. The Japanese version is authoritative; the English translation may contain inaccuracies.

Managing User Cluster Access Permissions

PFCP supports Role-Based Access Control (RBAC) using Kubernetes’ Role/RoleBinding mechanism. By creating a RoleBinding, you can assign permissions defined in Roles to specific users or groups.

Note

Before proceeding, please review the PFCP Roles documentation to understand the roles available in PFCP.

Standard Roles and Groups Provided by PFCP

The following three ClusterRoles1 are available:

  • org-view
    • Provides the necessary permissions to view user workloads.
  • org-edit
    • In addition to the org-view permissions, includes the necessary permissions to execute user workloads.
  • org-admin
    • In addition to the org-edit permissions, includes administrative privileges such as Role/RoleBinding management.

Tip

Each ClusterRole is based on the standard Kubernetes view/edit/admin ClusterRoles, with additional permissions removed for some resources and added permissions for custom resources used in PFCP. You can check exactly which operations are permitted on which resources using the following command:

$ kubectl get clusterrole org-view org-edit org-admin -o yaml

Additionally, the following two groups are pre-configured:

  • org-<organization-name> (e.g., org-pfn)
    • Both organization administrators and regular users belong to this group.
    • Only the org-edit Role is granted for the root Namespace. Roles are not granted for any subNamespaces.
  • org-<organization-name>/admin (e.g., org-pfn/admin)
    • This group is for organization administrators.
    • The org-admin ClusterRole is granted for both the root Namespace and all subNamespaces.

The root Namespace can be used as is with default settings because all users belonging to the organization have org-edit or higher permissions2. For newly created subNamespaces, regular users do not have any permissions. To grant permissions to regular users, you must create a RoleBinding.

Creating RoleBindings

RoleBindings can be created in one of two ways:

  1. Creating a RoleBinding for a group
  2. Creating a RoleBinding for a specific user

Below we explain how to grant org-edit ClusterRole2 to both groups and users for subNamespaces.

Creating a RoleBinding for a Group

To grant permissions to all users for a subNamespace (org-<organization-name>--foo), create the following RoleBinding:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: org-edit
  namespace: org-<organization-name>--foo
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: org-edit
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: Group
  name: oidc:org-<organization-name>

You can also grant permissions to user groups created through Managing Organization Users. To grant permissions to a user group (ops) for a subNamespace (org-<organization-name>--foo), create the following RoleBinding:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: org-edit-ops # The name can be arbitrary
  namespace: org-<organization-name>--foo
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: org-edit
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: Group
  name: oidc:org-<organization-name>/ops  # Specify the PFCP user group name

Note

If you would like to enable SAML integration with an external identity provider, please contact support for assistance.

Creating a RoleBinding for a Specific User

To grant permissions to a specific user (alice@example.com) for a subNamespace (org-<organization-name>--foo), create the following RoleBinding:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: org-edit-user-alice  # The name can be arbitrary
  namespace: org-<organization-name>--foo
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: org-edit
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: User
  name: oidc:org-<organization-name>/alice@example.com

Removing Workload Execution Permissions for Regular Users on Root Namespaces

As noted in the Standard Roles and Groups Provided by PFCP, regular users are by default granted org-edit permissions on the root Namespace. To remove org-edit permissions for regular users on the root Namespace, execute the following command:

$ kubectl -n org-<organization-name> delete rolebindings org-edit

This will prevent regular users from creating any resources or executing workloads in the root Namespace.

Note

Regular users will always retain org-view permissions on the root Namespaceand this cannot be disabled by organization administrators.

Creating Custom Roles

The org-admin ClusterRole includes permissions to create custom Roles within Namespaces, allowing organization administrators to create and assign Roles with custom permission sets to regular users.

For example, to create a custom Role that only grants view permissions for Pods, use the following configuration:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: pod-view
  namespace: org-<organization-name>--foo
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list", "watch"]

Frequently Asked Questions

Q. As an organization administrator, I want to use the org-edit role when interacting with clusters

The org-admin role granted to organization administrators includes powerful permissions for managing subNamespaces and RoleBindings. For executing training workloads, using the org-edit role helps prevent accidental modifications. This can be achieved by creating a ServiceAccount with the org-edit role and operating as that ServiceAccount.

Below are the steps to operate the org-<organization-name>--foo subNamespace using the org-edit role:

// Create a ServiceAccount in the `org-<organization-name>--foo` Namespace.
$ kubectl -n org-<organization-name>--foo create sa org-edit-sa
serviceaccount/org-edit-sa created

// Grant the `org-edit` role to the created ServiceAccount.
$ kubectl -n org-<organization-name>--foo create rolebinding org-edit-sa --clusterrole=org-edit --serviceaccount=org-<organization-name>--foo:org-edit-sa
rolebinding.rbac.authorization.k8s.io/org-edit-sa created

// Use the --as system:serviceaccount:<Namespace>:<ServiceAccount> flag to impersonate the target ServiceAccount.
// Verify that you are impersonating the correct ServiceAccount.
$ kubectl --as system:serviceaccount:org-<organization-name>--foo:org-edit-sa auth whoami
ATTRIBUTE   VALUE
Username    system:serviceaccount:org-<organization-name>--foo:org-edit-sa
Groups      [system:serviceaccounts system:serviceaccounts:org-<organization-name>--foo system:authenticated]

// While the `org-admin` role would allow creating ResourceQuotas, impersonation prevents this operation.
$ kubectl auth can-i create resourcequotas -n org-<organization-name>--foo
yes
$ kubectl --as system:serviceaccount:org-<organization-name>--foo:org-edit-sa auth can-i create resourcequotas -n org-<organization-name>--foo
no

If you prefer not to repeatedly add the --as flag, you can configure the following in the user field of your kubeconfig file to set it as the default:

 - name: pfcp-<organization-name>-<cluster-name>
   user:
+    as: system:serviceaccount:<Namespace>:<ServiceAccount>
     auth-provider:
       config

  1. A ClusterRole is a role that can be used from any Namespace. ↩

  2. If you do not need to grant the org-edit ClusterRole for root Namespaces to regular users, you can opt out. For instructions, see Removing Workload Execution Permissions for Regular Users on Root Namespaces. ↩ ↩2