feature: Add definition of kubeconfig that supports OIDC

[natereid72]

Is your feature request related to a problem?

I'd like to be able to define a ConfigMap that has OIDC issuer and ClientID to be added to the generated admin.conf kubeconfig. This would enable better experience when deploying vclusters that are intended to use OIDC rather than cert based auth.

Which solution do you suggest?

Add a ConfigMap option to helm chart that will be read for OIDC info to be added to kubeconfig.

Which alternative solutions exist?

afaik, manually editing the cert based kubeconfig file.

Additional context

The resulting kubeconfig would look something like this:

apiVersion: v1
clusters:
- cluster:
    certificate-authority-data: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUMvakNDQWVhZ0F3SUJBZ0lCQURBTkJna3Foa2lHOXcwQkFRc0ZBREFWTVJNd0VRWURWUVFERXdwcmRXSmwKY201bGRHVnpNQjRYRFRJek1EUXlNREUyTURJME1Wb1hEVE16TURReE56RTJNREkwTVZvd0ZURVRNQkVHQTFVRQpBeE1LYTNWaVpYSnVaWFJsY3pDQ0FTSXdEUVlKS29aSWh2Y05BUUVCQlFBRGdnRVBBRENDQVFvQ2dnRUJBTGNCClJXcXp2NVpyRzMzeFZlbmR4b3NKeUtGc3k5SC94THBaYUpJM0lOZjQrMkY3bTZ2TWVTQm1BdmFuRFc1Wndzci8KQXZzaXhnWS9lSVFoV1NYTDcxdW9jcHllUldWQzdNc25CcjNuMVozRytpdnFhWXlhKzVGd0NrMmYxU1JNdWdlRwo4NDVUb1VmL1dqZy9MdGJCZ2lhck0rLzJCSFVYL0NoL2N3Qy9RdTltRTdnalk5a2RKM2YyUnBlT1ovdzF6dDZ3CkhVbUU2a01oQ00xSXBEZTMrNDNMc295TlA4WlcvM09sNVIxRlFFNG96V3BZckxJeGlycTd1MHZDME5aSFVkQzUKRXBkWUNDZVNVbStWM0MxdWRMV1R2eFl2RVZNNlRpL21jbHhvQ1l6cjd5WHU2dzZuUlZWMlJXMGxQejZCZng5RApHK2V5RFpaWGhHcjhZK1dmUWtNQ0F3RUFBYU5aTUZjd0RnWURWUjBQQVFIL0JBUURBZ0trTUE4R0ExVWRFd0VCCi93UUZNQU1CQWY4d0hRWURWUjBPQkJZRUZBU05mTlpBOENUK1k4YXV1MXRSeUlBMVZSc2dNQlVHQTFVZEVRUU8KTUF5Q0NtdDFZbVZ5Ym1WMFpYTXdEUVlKS29aSWh2Y05BUUVMQlFBRGdnRUJBSjZQb1psN3BLN3hUK0VnSTM5aQpjNURrVjViaFFpSGpKdG5hT3lmcm5pV3pNVHBVQ1I1S3lzU0t3MmdOMUk4dFZKMStUYWNYdktOeUIyL2hjQXlPClNuNjZ2NTdoSGlQd0dsTzZqbkRpcE5lM1BndTVkUnFxT2V3Zldzd25TeTFoZWpWc2NsZ1BBQmhyWldQSmlYYW8KUDRKa0cwSEpRNXdJVmlMcW5Xd2JkY2dtaGd5aHZobFJKUk9CMU5rZkNzUTNWZnJXYU9nMncvck45aGJXOHhmcApJNnp5em5vWkpjcVZ2RFVMWG5SSTBQd1hMK2tNMnVmalhSM3BJM3BPeTJzdlltZVBUOGlaK0JqYjJ1ZkNnUnJGCmhSbk5wbHFPRGJXa01tTlBEOWZVYlIxd1hNZXJQaHIrVEQveHVmZ2VhZUxRdlhuQ2s2S1NMZmNIb0dlWVVCR1oKWVZVPQotLS0tLUVORCBDRVJUSUZJQ0FURS0tLS0tCg==
    server: https://192.168.253.2:443
  name: cluster-a
contexts:
- context:
    cluster: cluster-a
    user: cluster-a
  name: cluster-a@cluster-a
current-context: cluster-a@cluster-a
kind: Config
preferences: {}
users:
- name: cluster-a
  user:
    exec:
      apiVersion: client.authentication.k8s.io/v1beta1
      command: kubectl
      args:
      - oidc-login
      - get-token
      - --oidc-issuer-url=https://dev-69716366.okta.com/oauth2/aus94zuko1QlEE5Qm5b6
      - --oidc-client-id=0oa94zu5m3tQpadSR5b6
      - --oidc-extra-scope="email offline_access profile openid"

With the oidc-issuer-url, oidc-client-id, and oidc-extra-scope values being read in from a CM defined in the host cluster. All of these values are non-sensitive.

[neogopher]

Hi @natereid72 :wave: , Thanks for creating the issue. We will look into this and let you know soon.

[matskiv]

Thank you for raising this feature request. Because of the available alternatives (manual edit of kubeconfig, or Loft SSO) this won't be a priority for us right now. But we will leave this issue open to gauge the interest in this feature.

We are open to community contributions, but we may have higher expectations (automated tests, docs, maintenance commitment, etc.) for the features that we deem a lower priority.

[natereid72]

Thanks @matskiv, and understood. I think this would be something that could be handled out-of-tree with a simple controller. If I find some cycles, I will take a swipe and post back.