Getting Started

Overview

_images/DKube_Hierarchy_Diagram.png

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

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.

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


_images/Operator_Renew_License_Popup.png

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.

_images/Operator_OAuth.png

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

_images/Operator_Github_Popup.png

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://

_images/OAuth_Fields.png
Access Token Details

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

_images/GitHub_Access_Token.jpg

Important

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

LDAP Authorization

_images/Operator_LDAP_Popup.png

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.