Onboarding Users onto a DKP Cluster

After you install DKP and create a cluster, use this procedure to add new users to your environment.

Prerequisites

• A Valid DKP License (Essential or Enterprise)

• A running Cluster

Onboarding a New User to a DKP Cluster

This procedure assumes you are using a LDAP Connector and that you are a Cluster Admin.
For information on how you add users using other types of connectors, refer to the following pages:

• OIDC

• SAML

• GitHub

1. Create an LDAP Connector definition and name it ldap.yaml. An example is shown below:

   CODE

   apiVersion: v1
   kind: Secret
   metadata:
     name: ldap-password
     namespace: kommander
   type: Opaque
   stringData:
     password: superSecret
   ---
   apiVersion: dex.mesosphere.io/v1alpha1
   kind: Connector
   metadata:
     name: ldap
     namespace: kommander
   spec:
     enabled: true
     type: ldap
     displayName: LDAP Test Connector
     ldap:
       host: ldapdce.testdomain
       insecureNoSSL: true
       bindDN: cn=ldapconnector,cn=testgroup,ou=testorg,dc=testdomain
       bindSecretRef:
         name: ldap-password
       userSearch:
         baseDN: dc=testdomain
         filter: "(objectClass=inetOrgPerson)"
         username: uid
         idAttr: uid
         emailAttr: uid
       groupSearch:
         baseDN: ou=testorg,dc=testdomain
         filter: "(objectClass=posixGroup)"
         userMatchers:
         - userAttr: uid
           groupAttr: memberUid
         nameAttr: cn

2. Add the connector using the following command:

   CODE

   kubectl apply -f ldap.yaml 

   1. The output should look similar to the following:

      CODE

      secret/ldap-password created
      connector.dex.mesosphere.io/ldap created

3. Add the appropriate role bindings and name the file new_user.yaml. Examples for both Single User and Group Bindings are shown below:
   

   

   The property for the subjects.name varies depending on the context for which you have established an Identity Provider.

   • If you have set up an identity provider for All Workspaces:

     • For groups: configure the subjects.name field to oidc:<IdP_user_group>. For example, oidc:engineering.

     • For users: configure the subjects.name field to <user_email>. For example, jane.doe@example.com

   • If you have set up an identity provider for a Specific Workspace:

     • For groups: configure the subjects.name field to oidc:<workspace_ID>:<IdP_user_group>. For example, oidc:tenant-z:engineering.

     • For users: configure the subjects.name field to <workspace_ID>:<user_email>. For example, tenant-z:jane.doe@example.com.
       Run kubectl get workspaces to obtain a list of all existing workspaces. The workspace_ID is listed under the NAME column.

   • For Single Users:

     CODE

     apiVersion: rbac.authorization.k8s.io/v1
     kind: ClusterRoleBinding
     metadata:
       name: cluster-admin
     roleRef:
       apiGroup: rbac.authorization.k8s.io
       kind: ClusterRole
       name: cluster-admin
     subjects:
     - apiGroup: rbac.authorization.k8s.io
       kind: User
       name: newUser

   • Group Binding

     CODE

     apiVersion: rbac.authorization.k8s.io/v1
     kind: RoleBinding
     metadata:
       name: cluster-admin
       namespace: ml 
     roleRef:
       apiGroup: rbac.authorization.k8s.io
       kind: ClusterRole
       name: cluster-admin 
     subjects:
     - apiGroup: rbac.authorization.k8s.io
       kind: Group
       name: oidc:kommanderAdmins  

4. Add the role binding(s) using the following command:

   CODE

   kubectl apply -f new_user.yaml

ClusterRoleBindings permissions are applicable on a global level.
RoleBindings permissions are applicable on a namespace level.

This procedure assumes that the user being added is an admin.

For additional information about the other roles in DKP and their permissions, refer to Granting Access to Kubernetes and Kommander Resources