🌱 proxy: optionally enable OIDC auth

[hardys]

Summary

This adds OIDC to the enabled optional auth methods

Related issue(s)

Follow-up to #2178

[hardys]

Some test notes - I tested this locally using dex standalone

Since the kube API requires SSL, I generated certs using the gencert.sh script, modified so the SAN contained localhost e.g:

[alt_names]
DNS.1 = localhost
IP.1 = 127.0.0.1

Then I ran dex with a config like:

issuer: https://127.0.0.1:5554/dex

storage:
  type: sqlite3
  config:
    file: examples/dex.db

web:
  https: 127.0.0.1:5554
  tlsCert: /home/shardy/go/src/github.com/dexidp/dex/examples/k8s/ssl/cert.pem
  tlsKey: /home/shardy/go/src/github.com/dexidp/dex/examples/k8s/ssl/key.pem

staticClients:
- id: kcp
  name: kcp
  redirectURIs:
  - https://localhost:8000
  - https://localhost:18000
  secret: kcp

connectors:
- type: mockCallback
  id: mock
  name: Example

kubelogin can then be used to test the login e.g:

kubectl oidc-login setup --oidc-issuer-url=https://127.0.0.1:5554/dex --oidc-client-id=kcp --oidc-client-secret=kcp --certificate-authority /home/shardy/go/src/github.com/dexidp/dex/examples/k8s/ssl/ca.pem --local-server-cert=/home/shardy/go/src/github.com/dexidp/dex/examples/k8s/ssl/cert.pem --local-server-key=/home/shardy/go/src/github.com/dexidp/dex/examples/k8s/ssl/key.pem

Then create a clusterrolebinding as directed in the output.

Then we can configure the proxy when running sharded-test-server e.g:

go run ./cmd/sharded-test-server --proxy-token-auth-file=$PWD/test/e2e/framework/auth-tokens.csv --proxy-service-account-key-file=.kcp/service-account.crt --proxy-oidc-issuer-url=https://127.0.0.1:5554/dex --proxy-oidc-client-id=kcp --proxy-oidc-ca-file=/home/shardy/go/src/github.com/dexidp/dex/examples/k8s/ssl/ca.pem 

Then we can access KCP using OIDC auth with a kubeconfig containing a user like:

...
users:
- name: oidc
  user:
    exec:
      apiVersion: client.authentication.k8s.io/v1beta1
      args:
      - oidc-login
      - get-token
      - --oidc-issuer-url=https://127.0.0.1:5554/dex
      - --oidc-client-id=kcp
      - --oidc-client-secret=kcp
      - --certificate-authority=/home/shardy/go/src/github.com/dexidp/dex/examples/k8s/ssl/ca.pem
      - --local-server-cert=/home/shardy/go/src/github.com/dexidp/dex/examples/k8s/ssl/cert.pem
      - --local-server-key=/home/shardy/go/src/github.com/dexidp/dex/examples/k8s/ssl/key.pem
      command: kubectl
      env: null
      interactiveMode: IfAvailable
      provideClusterInfo: false

This is enough to prove the authn is working - but note when using the mock connector there is a limitation in that we can't configure groups for users - so if we want to test that, we'll need to run an IdP and use one of the "real" connectors instead.

[hardys]

/cc @csams

[hardys]

/test test

Appears to be a flake ref kcp-dev/contrib-tmc#93

[hardys]

I did notice one weird thing:

kubectl workspace
Current workspace is "root:users:zh:bg:https---127-0-0-1-5554-dex--g0w---4--0y---4--0w-g-tb2-r".

I don't think that's caused by this PR, but will investigate if it's a real issue with the username, or something caused by my test setup

[hardys]

I did notice one weird thing:

kubectl workspace
Current workspace is "root:users:zh:bg:https---127-0-0-1-5554-dex--g0w---4--0y---4--0w-g-tb2-r".

I don't think that's caused by this PR, but will investigate if it's a real issue with the username, or something caused by my test setup

Ok so the token looks like e.g

  "iss": "https://127.0.0.1:5554/dex",
  "sub": "Cg0wLTM4NS0yODA4OS0wEgRtb2Nr",
  "aud": "kcp",

Then the User for the clusterolebinding is a combination of the iss and sub fields:

kubectl create clusterrolebinding oidc-cluster-admin --clusterrole=cluster-admin --user='https://127.0.0.1:5554/dex#Cg0wLTM4NS0yODA4OS0wEgRtb2Nr'

So the username ends up as https://127.0.0.1:5554/dex#Cg0wLTM4NS0yODA4OS0wEgRtb2Nr in the user.DefaultInfo

KCP then replaces disallowed characters with - so this output is expected and unrelated to this PR (although I wonder how this is going to work in practice with real SSO/OIDC, @csams any thoughts on that?)

[hardys]

After discussing with @csams I now understand that the issue above is because the dex dev-setup isn't setting name/preferred_username in the claim - I've not yet figured out how to resolve that for test/dev but it sounds like in practice this should work fine.

[sttts]

/lgtm
/approve

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: sttts

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:

• pkg/proxy/OWNERS [sttts]

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