Authentication and Authorization

This section explains how authentication and authorization work in Arrikto EKF.

EKF supports authentication using Istio Gateway and AuthService. Istio Gateway intercepts requests to authenticated endpoints and sends them to the AuthService. The AuthService is then responsible for verifying that the request was made by a user with valid credentials, and if so, it allows the request to pass. Alternatively, the AuthService will prompt the user to log in to an Identity Provider using OIDC.

An Identity Provider (IdP) is a service that stores and manages digital identities. These services allow users to connect to the resources they need. They provide a way to manage access, adding, or removing privileges in a secure way.

The next guides present various scenarios of how AuthService authenticates clients. For each scenario, we make a distinction based on the kind of the client that performs the initial request. There are two type of actors:

  • User: indicates that the actor is either a real person or a programmatic client.
  • Client: indicates that the actor is a programmatic client.

AuthService works as an authentication proxy and can authenticate the clients with the authentication methods in the following order:

  1. Kubernetes authenticator: authenticates the client with their Kubernetes Service Accounts. This authenticator communicates with Kubernetes API server to validate the client request and retrieves the respective information.
  2. Access token authenticator: AuthService can validate access tokens issued by an external Identity Provider with one of the following two authentication methods:
    1. Opaque access token authenticator: authenticates the client based on the opaque access token that the external Identity Provider granted for the client. This authenticator communicates with the integrated external Identity Provider to validate each client request and retrieves the respective information.
    2. JWT access token authenticator: authenticates locally the client based on the JWT access token that the external Identity Provider granted for the client. If the signature of the JWT access token exists in the JSON Web Key Set (JWKs) list, this authenticator validates the client request without communicating with the external Identity Provider.
  3. Session authenticator: authenticates the client based on their cookie. If the session for this client exists, this authenticator validates the client request locally.
  4. ID token authenticator: authenticates locally the client based on the ID token that the external Identity Provider granted for the client. If the signature of the ID token exists in the JSON Web Key Set (JWKs) list, this authenticator validates the client request without communicating with the external Identity Provider.

By default, AuthService will examine all the aforementioned authentication methods -except for the opaque access token authenticator- while attempting to authenticate the client of the received request. Admins can specify which of the available authentication methods will use. For the access token authentication admins can only enable either the opaque access token authenticator or the JWT access token authenticator.

Note

Admins can also enable the AuthService caching mechanism. This mechanism can significantly reduce the authentication overhead for both the Kubernetes authenticator and the opaque access token authenticator. You can find out more on how to enable the AuthService caching mechanism in the Enable AuthService Caching Mechanism guide.

We present how a user can login with OIDC via their browser and get the necessary credentials. Once the user acquires the credentials, then Kubeflow Reception creates an account and the Profile Controller creates a Kubernetes resource of type Profile for them. Then we analyze how AuthService can authenticate both the user and their programmatic clients with their cookie, their Kubernetes Service Accounts, or their access token granted by an external Identity Provider.

If the user authentication was successful then EKF needs to authorize the user to perform the request. EKF performs authorization by leveraging from Kubernetes Role-Based Access Control (RBAC). RBAC is a method of regulating access to computer or network resources based on the roles of individual users within your organization. RBAC authorization uses the rbac.authorization.k8s.io API group to drive authorization decisions, allowing you to dynamically configure policies through the Kubernetes API.

Once EKF receives the request of an authenticated client it performs a SubjectAccessReview call to the Kubernetes API server. This method examines whether or not the authenticated client has sufficient permissions to perform this request. Thanks to RBAC, Kubernetes API server can inspect the permissions of this client.