This section explains the authentication and user-management integration of Kubeflow and Arrikto EKF with external Identity Providers.
OIDC is a standardized OAuth2 flow that allows a Client (Kubeflow or Arrikto EKF) to get a user’s identity from a trusted Provider (GitLab - Google).
The Istio Gateway is an OIDC Client. Kubeflow applications do not contain any authentication code. Authentication is performed once at the Istio Gateway, when requests enter the Kubeflow cluster.
However, the Istio Gateway cannot act as an OIDC Client on its own. This is why we enhanced the Istio Gateway capabilities by creating an AuthService which enables the Istio Gateway to act as an OIDC client. After the Istio Gateway authenticates the user, it places their identity in HTTP headers and forwards the request to Kubeflow applications.
Arrikto’s journal on authentication with Istio and Dex.
Single Sign-On (SSO)¶
Single sign-on (SSO) enables users to authenticate with multiple applications by logging in only once.
As an example, GitLab offers the following experience as an Identity Provider:
- The user logs in to GitLab for the first time, typing their credentials.
- The user navigates to Kubeflow, which is an OIDC Client to GitLab.
- Kubeflow initiates an OIDC flow to authenticate the user, redirecting them to GitLab to sign in.
- GitLab recognises the user is signed in, because it has stored a session cookie in the user’s browser.
- The user is not asked to type their credentials. They may be asked to authorize the application to access their identity (configurable).
- After granting access to Kubeflow, the user is logged in and redirected to Kubeflow.
Single Logout (SLO)¶
Single logout (SLO) enables users to logout from all applications at once, without having to sign out from each one separately.
OIDC defines the following specifications related to logout:
- OpenID Connect Session Management.
- OpenID Connect Front-Channel Logout.
- OpenID Connect Back-Channel Logout.
Because Kubeflow is a confidential client that doesn’t live in the user’s browser, the Back-Channel logout is what applies here. The gist of the spec is
- When a user logs out from the Provider (GitLab), the Provider sends requests to a logout endpoint at every Client (Kubeflow).
- When a user logs out from a Client, the Client redirects them to a special page at the Provider where the Provider prompts them to log out. Then, the Provider initiates a procedure that logs them out of all Clients.
However, GitLab doesn’t seem to either
- Implement the OpenID Connect Back-Channel Logout specification.
- Provide an administrative endpoint to log out users from all Clients.
To work around those issues, here are the suggested solutions:
To log a user out of GitLab when they log out of Kubeflow, we an HTTP POST request to the GitLab
/users/sign_outendpoint. This is effectively using CSRF so it is not ideal, however a recent GitLab issue removed CSRF protection of the logout endpoint for exactly this use.
To log a user out of Kubeflow (or other applications) when they logout of GitLab, force the AuthService to effectively use GitLab for session management and check the access/refresh token’s validity for every request.
Currently, when a user logs out of GitLab, GitLab doesn’t revoke all the tokens issued to applications. This means that logging out of GitLab does not log the user out of Kubeflow.
Authentication is done via OIDC tokens. To log out globally, navigate to your Profile
Applications, and in the
Authorized Applicationssection revoke every application’s access token.