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.
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 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
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:
kubeflow/manifests/common/oidc-authservice/overlays/deploy/params.envthat holds all environment variables for configuring AuthService.
Set the allowed groups, separated by a comma:GROUPS_ALLOWLIST=<my_group_1>,<my_group_2>
(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_CLAIMand the default value is
groups, which works for most cases.
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
For changes to take effect restart the pods manually:root@rok-tools:~/ops/deployments# kubectl delete pods -n istio-system -l app=authservice