Getting Started



DKubeTM is a portable, end-to-end, Kubeflow-based MLOps platform that enables data scientists to develop, tune, and deploy complex models. It is based on Kubernetes, and will run on-premises and on the most popular cloud providers. It has the same look, feel, and workflow on all of them, and migrating back and forth between providers is fast and simple.

This guide provides the information needed to run DKube after installation.

  • An access URL, and all of the necessary credentials for the application, will be provided

  • If you are the DKube Operator, a license token will be provided

  • After installation, the system is initially set up for local use. A single user is enabled.

  • An initial guide to getting started with the platform is provided at Using DKube

  • A tutorial is available to step you through your first at Data Science Tutorial

  • DKube examples are available at DKube Examples

  • Details for code developers is provided at DKube Developer’s Guide

Initiating Dashboard and Workflow Screens

  • Access the DKube site at the URL provided

    • Chrome and Firefox browsers are supported

  • If the DKube instance has not yet been signed in, sign in with the credentials provided. The login will be either local or through a backend authorization, as described below.


If you get a message that your connection is not private, it is because the certificate is self-signed. Please proceed to the url.


If you get an “Authentication Failed” or “Network Error” message after reaching the login page, refresh your browser window. This is not a valid error.

  • The first screen will ask you to provide your login credentials

  • This will bring up the DKube dashboard. For subsequent launches, the credentials will be remembered, and the login screen will not appear. DKube periodically forces a new login.

_images/Sign_In.png _images/Login_Fields.png

Providing the License Token

If the system is being used for the first time, or if the previous license has expired, a license token needs to be entered in order to use the system. If you are an Operator, you will be provided with a token to use when this happens. Paste in the token provided and select submit.


The same process is used to renew the license when it expires. The Operator can update the license at any time as described at DKube License Update

Authentication Credentials

There are several authorization mechanisms for accessing DKube.

Local Authorization

Local authorization is used to access DKube after installation. It is based on a username and password. The credentials were provided as part of the installation process, and you will receive them from the cluster manager.

Local authorization allows the user to operate in both the Operator and Data Science screens, as described at Using DKube

Most of the functions of DKube are active when locally authorized, and it is meant to allow the product to be tested, or to allow one organization to install DKube and then hand it over to another organization.

In order to allow other users to be added to the system, and before doing significant work, a backend authorization should be activated. Once the backend authorization is activated, DKube cannot go back to local authorization.


After activating the backend credentials, the work performed as part of the local authorization is lost

Backend Authorization

A backend authorization allows Users to be added to Groups and share Pools, as described in the section Using DKube

All of the functions of DKube are available in this mode. In order to move from local to backend authorization, the Operator selects the OAuth menu item on the left.

This will bring up the OAuth Providers screen.


The Activate button should be selected under the Actions column, and this will bring up the appropriate authorization popup screen.


After migrating to a backend authorization, additional users can be onboarded as explained in Add (On-Board) User

GitHub Authorization


The GitHub credentials are as follows:



Git User Name

GitHub user name for operator

Organization Name

GitHub organization name for users

Redirect URI

Authorization callback url (see below)

Client ID

GitHub Client ID from OAuth app Create OAuth App

Client Secret

GitHub Client Secret from OAuth app Create OAuth App

Access Token

GitHub access token Create GitHub Token

OAuth Details

For the OAuth App, the following field definitions are required. The access url is the url that is used to run DKube from your browser.



Homepage URL

https://<DKube access url>:32222/dex

Authorization callback URL

https://<DKube access url>:32222/dex/callback


Note that the access url needs be https://

Access Token Details

During the creation of the GitHub access token, the repo permissions should be selected.



The GitHub access token should be saved for future use. It cannot be viewed after the initial token creation is completed.

LDAP Authorization




LDAP Server Address

The url, including port, that identifies the LDAP server in the format ldap(s)://<IP>:<PORT>. For example, ldap:// or ldaps:// (secure mode).

Bind DN

The LDAP administrator Bind DN is the administrative username configured for the LDAP authentication. This is sometimes called Administrator DN. An LDAP query is authenticated using the Bind DN and Bind Password. An example of this field is cn=Administrator,cn=Users,dc=dkube,dc=local

Bind Password

The administrator Bind Password is the password configured for the LDAP authentication. An LDAP query is authenticated using the Bind DN and the Bind Password.

Bind DN Attribute

The Administrator attribute against which a Bind DN should be matched. This is sometimes called Login Attribute or User ID Attribute. For Active Directory, use sAMAccountName to uniquely identify a user. When a user logs in with the Bind DN, they will be matched against sAMAccountName until a match is found.

DKube Operator Username

After a successful migration to LDAP, the DKube operator will log in with this DKube Operator Username. This user must be present in the LDAP server.

Base DN

The LDAP server search domain. This is the point from which an LDAP server will search for users. An example of this field is cn=Users,dc=dkube,dc=local

Base DN Filter

The User Filter eliminates unwanted users from a Base DN search result. For example, the filter might be (&(objectClass=user)(cn=*Marketing*)), which searches for all the user entries that have an objectClass of User AND a cn that contains the word Marketing.


Indicates the set of entries at or below the Base DN that may be considered for a potential match in a SearchRequest.

Group Attribute

For Active Directory, use member as the value. A Group’s member attribute points to the list of DNs for user objects that are members of the group.

Group Filter

The Group Filter eliminates unwanted groups from a Base DN search result. An example filter is (&(objectClass=group)(|(ou:dn:=Chicago)(ou:dn:=Miami))). This example finds groups with an OU component of their DN which is either Chicago or Miami.