Authentication

Configure App Level Authentication for Seldon Deploy

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 components are installed.

Seldon Deploy 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 Deploy 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 a Deploy 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")

Hint

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

Expected Claims

As Seldon Deploy 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 Deploy expects the following claims in an ID token:

  • name – the name of the user

  • email – the user’s email

  • groups – a list of groups to which the user belongs

  • An identity determined by USERID_CLAIM_KEY, which defaults to preferred_username

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.

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

Or you can edit your Seldon Deploy installation and replace the docker image with that one. To do this, first find the deployment for Seldon Deploy 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 Deploy 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.