This guide describes what the AuthService is and how to configure it.


What is the problem?

The traditional way of authenticating users is to include authentication code inside the application. However, in the microservice world, this approach becomes repetitive and prone to error, as similar logic has to be implemented over and over.

There is a need to consolidate authentication in one place. What if we could perform all common authentication logic in a proxy in front of the application and just let the application know the final result? For example, the proxy could use a standardized flow to authenticate users and propagate the authentication’s result to the application in HTTP headers. This allows for the authentication logic to be implemented once and reused across applications.

Cloud-Native Proxies

Modern proxies (e.g., Envoy) allow the user to extend their functionality. One common extension they allow is to call into an external service to ask if a request is allowed or denied. This is especially useful since it allows extending existing proxies of a Service Mesh (e.g., Istio) with the functionality described above. Envoy calls this extension interface the envoy.ext_authz filter. So instead of writing our own proxy, we can implement this interface and extend existing proxies, lowering the barrier-to-entry and improving efficiency.

The AuthService

The AuthService is an implementation of Envoy’s ext_authz interface. For every request that reaches Envoy, it will make a request to the AuthService to ask if that request is allowed.

Configure the AuthService

The AuthService is configured through environment variables, defined in a ConfigMap called oidc-authservice-parameters. Find an exhaustive list of configuration options along with their default values and explanations in the AuthService README.

In this section, we will go through some of the most common configuration settings that a user may need.

Control Access Based on Groups

The AuthService can allow or block access based on the user’s groups. If the corresponding setting is provided, it acts as an allow list, i.e., if a user belongs to a group included in the list, then, it grants them access. Conversely, if a user is not in any of the configured groups, it will not authenticate them. By default all groups are allowed. To allow access for specific groups:

  1. Edit kubeflow/manifests/common/oidc-authservice/overlays/deploy/params.env that holds all environment variables for configuring AuthService.

  2. Set the allowed groups, separated by a comma:



    If you want to allow access via Kubernetes ServiceAccountToken (see also Access Services with External Clients and Access Kubeflow Pipelines from External Client) you need to include the system:serviceaccounts group to the list above.

  3. (optional) Configure the claim in which to find the groups list, inside the IDToken (JWT) returned by the OIDC Provider (e.g., GitLab, Dex, etc.). The setting is GROUPS_CLAIM and the default value is groups, which works for most cases.

  4. Commit and apply changes:

    root@rok-tools:~/ops/deployments# git commit -am "authservice: Configure allowed groups" root@rok-tools:~/ops/deployments# rok-deploy --apply install/kubeflow
  5. For changes to take effect restart the pods manually:

    root@rok-tools:~/ops/deployments# kubectl delete pods -n istio-system -l app=authservice