Authentication

Configure App Level Authentication for Seldon Enterprise Platform

App-Level Authentication

Important

Before starting the installation procedure, please download installation resources as explained here and make sure that all pre-requisites are satisfied.

This page also assumes that main Seldon Enterprise Platform components are installed.

Seldon Enterprise Platform can be set up to use app-level authentication with an OIDC provider, for example using the auth code flow. This would be particularly useful when gateway-level authentication is not set up for the Kubernetes cluster.

This feature can be activated by configuring the values file of the Seldon Enterprise Platform Helm chart. This is done by setting the boolean variable enableAppAuth to true and further providing the OIDC configuration options as env variables to connect to OIDC providers like Keycloak or Dex.

# boolean to enable app-level auth (defaults to "false")
enableAppAuth: true

Add config / env variables

Before we run an Enterprise Platform install using the Helm chart, we need to make sure to add the OIDC configuration to the env section:

env:
  OIDC_PROVIDER: ...     # oidc providerURL, e.g. 'https://${oidc_redirect_url}/auth/realms/deploy-realm'
  CLIENT_ID: ...         # oidc client ID, e.g. 'deploy-server'
  CLIENT_SECRET: ...     # oidc client secret, e.g. 'deploy-secret'
  REDIRECT_URL: ...      # `${oidc_redirect_url}/seldon-deploy/auth/callback`
  OIDC_SCOPES: ...       # oidc scopes (defaults to "profile email groups")
  USERID_CLAIM_KEY: ...  # claim to be used as userid (defaults to "preferred_username")
  USERNAME_CLAIM_KEY: ...  # claim to be used as username (defaults to "name")
  EMAIL_CLAIM_KEY: ...  # claim to be used as email (defaults to "email")
  GROUPS_CLAIM_KEY: ...  # claim to be used as groups (defaults to "groups")
  SA_ID_CLAIM_KEY: ...  # claim to be used as userid for service accounts (defaults to "preferred_username")

Hint

Do not forget to run helm upgrade seldon-deploy ... as described in the Seldon Enterprise Platform configuration section.

Expected Claims

As Seldon Enterprise Platform integrates with OIDC providers, it expects to receive an ID token for authentication. This differs from an OAuth 2.0 access token by making certain claims non-optional and defining additional, standard claims for identity information.

Seldon Enterprise Platform expects the following claims in an ID token:

  • name – the name of the user determined by environment variable USERNAME_CLAIM_KEY

  • email – the user’s email determined by environment variable EMAIL_CLAIM_KEY

  • groups – a list of groups to which the user belongs determined by environment variable GROUPS_CLAIM_KEY

  • A unique user identity token. This is determined by environment variable USERID_CLAIM_KEY. This can be used for both human users and service accounts. If it is not possible to share claim keys for both, it is possible to use the environment variable SA_ID_CLAIM_KEY for service accounts. Note: the USERID_CLAIM_KEY is always used if present. SA_ID_CLAIM_KEY is used only if USERID_CLAIM_KEY does not exist in the token

Whilst these claims are technically not mandatory, it is highly recommended to provide all of them as they are used for authorization and audit purposes. See helm chart for default values.

  • The identity and groups claims are required for authorizing access.

  • The name and email claims are used with GitOps to track which user performed an action, for example, and for other informational purposes.

Groups/LDAP Configuration

Some customers choose to get groups from LDAP. See the LDAP section on that.

Identity Brokering

Sometimes there’s an existing identity server that doesn’t support OIDC and instead supports SAML.

Seldon does not support SAML directly but Keycloak can be used to broker to a SAML server.

Keycloak Reference Installation

Note

The reference installation is only intended for illustrative purposes.

Consult with your operations and/or security teams on the best practices for installing and integrating with an OIDC provider within your organisation.

Keycloak is a popular OIDC provider.

A lot of information on how to install and configure Keycloak can be found in the official guides. The Helm chart for Keycloak, which is used in the reference installation below, can be found on its GitHub page.

A reference installation of Keycloak is included under the following Ansible roles from the installation resources:

seldon-deploy-install/ansible/roles/deps-installation/keycloak
seldon-deploy-install/ansible/roles/deps-configuration/keycloak

In the reference installation, default clients and users are created, but this should only be seen as a guide. Customisation of users, passwords and tokens is highly recommended.

Following the reference installation, these should be the configuration values:

env:
  CLIENT_ID: "deploy-server"
  CLIENT_SECRET: "deploy-secret"
  OIDC_PROVIDER: "http://${INGRESS_URI}/auth/realms/deploy-realm"
  REDIRECT_URL: "http://${INGRESS_URI}/seldon-deploy/auth/callback"

With Istio, INGRESS_URI may be obtained with:

INGRESS_URI=$(kubectl get svc -n istio-system istio-ingressgateway -o jsonpath='{.status.loadBalancer.ingress[0].ip}')
INGRESS_URI+=$(kubectl get svc -n istio-system istio-ingressgateway -o jsonpath='{.status.loadBalancer.ingress[0].hostname}')

or with NGINX Ingress:

INGRESS_URI=$(kubectl get svc -n ingress-nginx ingress-nginx-controller -o jsonpath='{.status.loadBalancer.ingress[0].ip}')
INGRESS_URI+=$(kubectl get svc -n ingress-nginx ingress-nginx-controller -o jsonpath='{.status.loadBalancer.ingress[0].hostname}')

Debugging

There’s some details on debugging the token content in the LDAP section.

Often the issue is the auth configuration rather than Seldon specifically. In those cases it can be useful to connect a different application that dumps more details.

We provide an example app for debugging purposes. It can be run on the cluster alongside Seldon Enterprise Platform.

Or you can edit your Seldon Enterprise Platform installation and replace the Docker image with that one. To do this, first find the deployment for Seldon Enterprise Platform and find what image it is using:

kubectl get deployment -n seldon-system seldon-deploy -o jsonpath="{..image}"

Then make a note of that and save the note. Next edit the deployment with kubectl edit deployment -n seldon-system seldon-deploy. Change the image to seldonio/oauth-test-tool:0.1.

Now when you login to Seldon Enterprise Platform it will actually login to the test tool. Its pod logs will give more detail about the login process. After debugging and resolution then the image can be edited back to what it was before, which was saved in a note.