Project Role Bindings
![](../../__attachments/143696348/enterprise%20-%20badge@500w.png?inst-v=fbc98f0a-f9ae-4d4c-828f-dc0defe966ca)
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:
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:
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:
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:
kubectl -n ${projectns} get federatedrolebindings.types.kubefed.io projectpolicy-gtct4-rdkwq -o yaml
Output:
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:
kubectl -n ${projectns} get rolebinding projectpolicy-gtct4-rdkwq -o yaml
Output:
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, VirtualGroup
is a list of subjects that can be assigned to several different kinds of roles, including:
ClusterRole
for cluster-scoped objectsWorkspaceRole
for workspace-scoped objectsProjectRole
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 VirtualGroup
since 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
.