Authentication

charm
,
1

This guide describes how authentication works in Charmed Kubeflow (CKF).

All CKF applications and services, including the Kubeflow central dashboard, are centrally exposed through a single ingress, which can also be configured for TLS. Since these applications can modify resources in the underlying Kubernetes (K8s) cluster, they require users to be logged in and authenticated to enable proper authorization checks.

Authentication is handled by configuring the central ingress to enforce request authentication via the OIDC flow. If a request is unauthenticated, the user is redirected to log in. This ensures that access to all CKF applications and resources is restricted to authenticated users.

Components

Authentication in CKF leverages three components:

  • An Identity Provider (IdP), which stores and manages digital identities. It is implemented by the dex-auth charm. Also referred to as OpenID Connect (OIDC) provider.
  • An OIDC client, which requests tokens for authentication. It is implemented by the oidc-gatekeepercharm. Also referred to as AuthService.
  • An ingress, which manages external access to your Kubernetes cluster’s services. It is implemented by the istio-ingressgateway and istio-pilot charms, both needed to configure the istio-gateway charm.

These three components participate in the OIDC flow:

Some important aspects to highlight:

  1. The Istio Gateway is configured by an EnvoyFilter, which enforces authentication by forwarding every request made to the Gateway to an AuthService (oidc-gatekeeper).

  1. The EnvoyFilter template is rendered and applied by istio-pilot when integrated with oidc-gatekeeper via the ingress-auth interface where the latter provides the following data:
  • service - oidc-gatekeeper: service name to forward all ingress traffic to.
  • port: port of the service - oidc-gatekeeper.
  • allowed-request-headers: a list of allowed headers to configure the EnvoyFilter authorisation_request value, which is always set to:
"allowed-request-headers": [
    "cookie",
    "X-Auth-Token",
],
  • allowed-response-headers: a list of allowed headers to configure the EnvoyFilter authorisation_response value, which is always set to:
"allowed-response-headers": ["kubeflow-userid"]
  1. userID headers are added by the AuthService to the original request and are used later in the authorisation process.
  2. Dex has a built-in connector that allows the creation of static users. In CKF, this is used for easy access to the dashboard and in development and testing scenarios.

Programmatic access with the ingress and AuthService can be configured. See this guide for more details.

CKF ingress

The following diagram showcases the CKF ingress flow:

  1. A user request from outside the cluster is sent, targeting component-a.
  2. The request is first intercepted by a LoadBalancer, only if set up, or the Service that is right at the edge of the Istio Service Mesh.
  3. The request is forwarded to the Istio Ingress Gateway, this is the istio-ingressgateway Service.
  4. The request reaches the istio-ingressgateway Pod at the listening port, which is configured by the Gateway resource. See Gateway for more details.
  5. The route from the istio-ingressgateway Pod to the desired component is configured by a VirtualService. See VirtualService for more details.

This flow does not consider authentication and authorisation.

Some important aspects to highlight:

  1. A Gateway gets created automatically by the istio-pilot charm. The Gateway Custom Resource (CR) configures the traffic received by the istio-ingressgateway-xxxx Pod with:
    • servers.hosts: exposed by the Gateway and re-routed to their respective hosts based on the request.
    • TLS: when enabled either via the integration of a TLS certificate provider charm or passing cert and key values via a Juju secret. See this guide for more details.

The Gateway template is rendered and applied by the istio-pilot charm.

  1. VirtualServices are created to define a set of traffic routes to apply when a host is addressed. In the picture above, whenever a request handled by the kubeflow-gateway contains component-a in the request, it gets routed to the component-a Service based on the VirtualService routing rules.

A charm that requires a VirtualService, for instance, jupyter-ui or kfp-ui, integrates with istio-pilot via the ingress interface.

The ingress interface is not the same as this ingress interface.

The requirer charm shares the following data:

  • prefix: prefix-based URI to match.
  • rewrite: used to rewrite the prefix portion of the URI.
  • service: the Service used as the destination of the request.
  • port: the port of the Service used as the destination.

The VirtualService template is rendered and applied by the istio-pilot charm in the namespace where Istio is deployed. The VirtualService always uses the kubeflow-gateway as the spec.gateways value. This is not configurable.

  1. Kubeflow utilises path-based routing for reaching inside each components APIs, so most components expect the requests to have the format /<rewrite>/<some>/<route>, meaning that the request should be forwarded to the component without being prefixed with anything different than what’s defined in the VirtualService. For example:
curl -v [kubeflow.io/pipeline](http://kubeflow.io/pipelines) -H <some header>
# or from browser [kubeflow.io/pipeline](http://kubeflow.io/pipelines)

# Should be routed as
GET /pipeline/ -H <some header>
  1. The istio-ingressgateway Deployment and Service are created by the istio-gateway charm.
1 Like
2

change the available connectors github url

4

The connector configuration is described as a YAML, but the example below is JSON. Please align both of them to be in the same format. Additionally, if the expected format is JSON, please adjust the charm config description - there is explicitly written that YAML is supported.

5

YAML is a superset of JSON, so the example is technically still YAML (but agreed, it is in the form most anyone would call JSON rather than YAML). I won’t change the example above as it is technically valid, but to clarify the situation both YAML and JSON will work in this config. Note though that the config is asking for the list of connectors to put inside the Dex connectors config (example here), not the entire connectors: [ ... ] key value pair. So the pure YAML equivalent to the example above would be:

- id: ldap
  name: OpenLDAP
  type: ldap
  config:
    bindDN: cn=admin,dc=example,dc=org
    bindPW: admin
    groupSearch:
      baseDN: cn=admin,dc=example,dc=org
      filter: ''
      groupAttr: DN
      nameAttr: cn
      userAttr: DN
    host: ldap-service.auth.svc.cluster.local:389
    insecureNoSSL: true
    userSearch:
      baseDN: cn=admin,dc=example,dc=org
      emailAttr: DN
      filter: ''
      idAttr: DN
      nameAttr: cn
      username: cn
    usernamePrompt: Email Address
6

How to do programmatic authentication with Dex?

I have already tried based on the following URL: [https://www.kubeflow.org/docs/components/pipelines/v1/sdk/connect-api/#example-for-dex]

But still stuck in

CSRF check failed. This may happen if you opened the login form in more than 1 tabs. Please try to login again.

Could you please help me in solving this problem?

7

Hey, I’ve asked this in our channel: https://chat.charmhub.io/charmhub/pl/tjq8h9crsbgzzj3ppi8yj51euw.