Project Role Bindings

Project Role Bindings grant access to a specified Project Role for a specified group of people

Configure Project Role Bindings - UI Method

Before you can create a Project Role Binding, ensure you have created a Group. A Kommander Group can contain one or several Identity Provider users or groups.

You can assign a role to this Kommander Group:

From the Projects page, select your project.
Select the Role Bindings tab, then select Add Roles next to the group you want.
Select the Role, or Roles, you want from the drop-down menu, and then select Save.

Configure Project Role Bindings - CLI Method

A Project role binding can also be created using kubectl:

CODE

cat << EOF | kubectl create -f -
apiVersion: workspaces.kommander.mesosphere.io/v1alpha1
kind: VirtualGroupProjectRoleBinding
metadata:
  generateName: projectpolicy-
  namespace: ${projectns}
spec:
  projectRoleRef:
    name: ${projectrole}
  virtualGroupRef:
    name: ${virtualgroup}
EOF

Configure Project Role Bindings to Bind to WorkspaceRoles - CLI Method

You can also create a Project role binding to bind to a WorkspaceRole in certain instances. To list the WorkspaceRoles that you can bind to a Project, run the following command:

CODE

kubectl get workspaceroles -n ${workspacens} -o=jsonpath="{.items[?(@.metadata.annotations.workspace\.kommander\.d2iq\.io\/project-default-workspace-role-for==\"${projectns}\")].metadata.name}"

You can bind to any of the above WorkspaceRoles by setting spec.workspaceRoleRef in the project role binding:

CODE

cat << EOF | kubectl create -f -
apiVersion: workspaces.kommander.mesosphere.io/v1alpha1
kind: VirtualGroupProjectRoleBinding
metadata:
  generateName: projectpolicy-
  namespace: ${projectns}
spec:
  workspaceRoleRef:
    name: ${workspacerole}
  virtualGroupRef:
    name: ${virtualgroup}
EOF

Note that you must specify either workspaceRoleRef or projectRoleRef to be validated by the admission webhook. Specifying both values is not valid and will cause an error.

Ensure the projectns, workspacens, projectrole (or workspacerole) and the virtualgroup variables are set before executing the command.

When a Project Role Binding is created, Kommander creates a Kubernetes FederatedRoleBinding on the Kubernetes cluster where Kommander is running. You can view this by first finding the name of the project role binding that you created: kubectl -n ${projectns} get federatedrolebindings.types.kubefed.io

Then, view the details like in this example:

CODE

kubectl -n ${projectns} get federatedrolebindings.types.kubefed.io projectpolicy-gtct4-rdkwq -o yaml

Output:

CODE

apiVersion: types.kubefed.io/v1beta1
kind: FederatedRoleBinding
metadata:
  creationTimestamp: "2020-06-04T16:19:27Z"
  finalizers:
  - kubefed.io/sync-controller
  generation: 1
  name: projectpolicy-gtct4-rdkwq
  namespace: project1-5ljs9-lhvjl
  ownerReferences:
  - apiVersion: workspaces.kommander.mesosphere.io/v1alpha1
    blockOwnerDeletion: true
    controller: true
    kind: VirtualGroupProjectRoleBinding
    name: projectpolicy-gtct4
    uid: 19614de2-4593-433e-82fa-96dc9470e07a
  resourceVersion: "196270"
  selfLink: /apis/types.kubefed.io/v1beta1/namespaces/project1-5ljs9-lhvjl/federatedrolebindings/projectpolicy-gtct4-rdkwq
  uid: beaffc29-edec-4258-9813-3a17ba27a2a6
spec:
  placement:
    clusterSelector: {}
  template:
    roleRef:
      apiGroup: rbac.authorization.k8s.io
      kind: Role
      name: admin-dbfpj-l6s9g
    subjects:
    - apiGroup: rbac.authorization.k8s.io
      kind: User
      name: user1@d2iq.lab
status:
  clusters:
  - name: konvoy-5nr5h
  conditions:
  - lastTransitionTime: "2020-06-04T16:19:27Z"
    lastUpdateTime: "2020-06-04T16:19:27Z"
    status: "True"
    type: Propagation
  observedGeneration: 1

Then, if you run the following command on a Kubernetes cluster associated with the Project, you’ll see a Kubernetes RoleBinding Object, in the corresponding namespace:

CODE

kubectl -n ${projectns} get rolebinding projectpolicy-gtct4-rdkwq -o yaml

Output:

CODE

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  creationTimestamp: "2020-06-04T16:19:27Z"
  labels:
    kubefed.io/managed: "true"
  name: projectpolicy-gtct4-rdkwq
  namespace: project1-5ljs9-lhvjl
  resourceVersion: "125392"
  selfLink: /apis/rbac.authorization.k8s.io/v1/namespaces/project1-5ljs9-lhvjl/rolebindings/projectpolicy-gtct4-rdkwq
  uid: 2938398d-437b-4f3a-9cb9-c92e50139196
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: admin-dbfpj-l6s9g
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: User
  name: user1@d2iq.lab

Role Binding with VirtualGroup

In DKP, VirtualGroupis a list of subjects that can be assigned to several different kinds of roles, including:

ClusterRole for cluster-scoped objects
WorkspaceRole for workspace-scoped objects
ProjectRole for project-scoped objects

In order to define which VirtualGroup(s) is assigned to one of these roles, administrators can create corresponding role bindings such as VirtualGroupClusterRoleBinding, VirtualGroupWorkspaceRoleBinding, and VirtualGroupProjectRoleBinding.

For more information about configuring VirtualGroup, please refer to the DKP API Documentation.

Note that for WorkspaceRole and ProjectRole, the referenced VirtualGroup and corresponding role and role binding objects need to be in the same namespace. If they are not in the same namespace, the role will not bind to the VirtualGroupsince it is assumed that the rules set in the role apply to objects that live in that namespace. Whereas for ClusterRole which is cluster-scoped, the VirtualGroupClusterRoleBinding is also cluster-scoped, even though it references a namespace-scoped VirtualGroup.