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

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 (see below 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
Client ID	GitHub Client ID from OAuth app (see Create OAuth App)
Client Secret	GitHub Client Secret from OAuth app (see Create OAuth App)
Access Token	GitHub access token (see 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://<Access url>:32222/dex
Authorization callback URL	https://<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.