pipelines: Follow up on connecting to KFP in multi-user mode.

[zijianjoy]

To address the comments in #2905:

• Process about process of AuthN and AuthZ
• Cross-namespace section title
• ServiceAccountToken explanation.
• Overall doc structure.

cc @bartgras @shuesc1

[google-oss-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: zijianjoy

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• content/en/docs/components/pipelines/OWNERS [zijianjoy]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[shuesc1]

"When using Kubeflow Pipelines SDK in the same cluster, [it] authenticates as default-editor.."

Could we be more explicit about the situation and what "it" refers to? For example:

"When multiple users employ the Kubeflow Pipelines SDK in the same cluster, the [service/SDK] authenticates the [namespace/role/user?] as default editor..."

[zijianjoy]

Reworded to following:

When calling Kubeflow Pipelines API in the same cluster, Kubeflow Pipelines SDK authenticates itself as default-editor in your namespace using ServiceAccountToken projection.

Hope it is a bit clearer.

[bartgras]

@zijianjoy Please correct me if I'm wrong but is it the token from default-editor that KFP SDK uses to authenticate against KFP API?
As far as I understand, the Pod itself uses default-editor but separate, projected token is being used by KFP SDK.

Quote from the comment:

How does the client find a ServiceAccountToken to use?

Kubernetes has built-in ways to project tokens with specific audience for the ServiceAccount of a pod.
Each container of a pod mounts the token similarly to how it would mount some volume.
The kubelet generates a token and stores it in a file. Then, to retrieve the token, it's just a matter of reading this file.

The KFP client should have a seamless way to

retrieve the path where the token is mounted,
read it, and
use it in request headers.

... and (to my knowledge) the token SDK retrieves is the one from /var/run/secrets/kubeflow/pipelines/token

Also, have a look at this jupyter Pod (namespace has been already configured with PodDefault):

apiVersion: v1
kind: Pod
[ ... ]
spec:
  containers:
  - env:
    - name: KF_PIPELINES_SA_TOKEN_PATH
      value: /var/run/secrets/kubeflow/pipelines/token
    image: public.ecr.aws/j1r0q0g6/notebooks/notebook-servers/jupyter-scipy:v1.4-rc.0
    imagePullPolicy: IfNotPresent
    name: test-jupyter-server
    volumeMounts:
    [ ... ]
    - mountPath: /var/run/secrets/kubernetes.io/serviceaccount
      name: kube-api-access-46h49
      readOnly: true
    - mountPath: /var/run/secrets/kubeflow/pipelines
      name: volume-kf-pipeline-token
      readOnly: true
    workingDir: /home/jovyan
  [ ... ]
  volumes:
  [ ... ]
  - name: kube-api-access-46h49
    projected:
      defaultMode: 420
      sources:
      - serviceAccountToken:
          expirationSeconds: 3607
          path: token
      - configMap:
          items:
          - key: ca.crt
            path: ca.crt
          name: kube-root-ca.crt
      - downwardAPI:
          items:
          - fieldRef:
              apiVersion: v1
              fieldPath: metadata.namespace
            path: namespace
  - name: volume-kf-pipeline-token
    projected:
      defaultMode: 420
      sources:
      - serviceAccountToken:
          audience: pipelines.kubeflow.org
          expirationSeconds: 7200
          path: token

[Bobgy]

@bartgras the documentation in https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/#service-account-token-volume-projection wasn't very clear on this.

To answer your question, the projected token is a derived token from the service account token (e.g. default-editor here), the projected token has an audience of pipelines.kubeflow.org, so that only the pipelines service will accept the projected token and authenticate you as default-editor.
It is not the same as service account token, but it represents the service account identity too.

this is a follow up on #2905 (comment)

[Bobgy]

nit: instead of default-editor, it's more accurate to say "your Pod's service account" (or any other words with the same meaning), because the example is using default-editor, but people can configure auth with any other service accounts too.

[Bobgy]

Thanks for the update!
/lgtm

[Bobgy]

Ohh, I didn't intend to merge the PR right away. Feel free to leave more comments.

[bartgras]

Thanks for clarifying @Bobgy

That made me realize that Pod manifest in section "Access Kubeflow Pipelines from within any Pod" is
missing in spec: serviceAccountName: default-editor
(and has to be run from namespace that already has default-editor declared)