Getting Started

Overview

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.

  • If more than one user is required, backend authorization must be enabled, as described in section Authentication Credentials

• 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.

Note

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

Note

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.

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.

Important

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.

Note

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:

Field	Value
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.

Field	Value
Homepage URL	https://<DKube access url>:32222/dex
Authorization callback URL	https://<DKube access url>:32222/dex/callback

Important

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.

Important

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

LDAP Authorization

Field	Value
LDAP Server Address	The url, including port, that identifies the LDAP server in the format ldap(s)://<IP>:<PORT>. For example, ldap://192.168.1.20:369 or ldaps://192.168.1.20:639 (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.
Scope	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.