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. In Envoy, this extension interface is called 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.

AuthService Configuration

The AuthService is configured through environment variables, defined in a ConfigMap called oidc-authservice-parameters. An exhaustive list of configuration options along with their default values and explanations can be found 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, access is granted. Conversely, if a user is not in any of the configured groups, the user will not be authenticated. By default all groups are allowed. To allow access for specific groups:

  1. Edit kubeflow/manifests/istio/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 Set up an external client and Access Kubeflow Pipelines) 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:

    $ git commit -am "authservice: Configure allowed groups"
    $ rok-deploy --apply install/kubeflow
  5. For changes to take effect we have to restart the pods manually:

    $ kubectl delete pods -n istio-system -l app=authservice