[FEAT] - Backend for Cluster Registry

[IvoGoman]

Priority

(Low) Something is a little off

Description

Greenhouse has an holistic view on all Clusters and the Organisations OIDC Configuration. This information can be used to generate KubeConfigs for users as shown below.

The goal for the Cluster Registry backend is to make the Kubeconfigs available so that they can be consumed by cloudctl.

Example generated kubeconfig.yaml:

apiVersion: v1
clusters:
- cluster:
    certificate-authority-data:  <CA>
    server: <K8S API server>
  name: <cluster name>
contexts:
- context:
    cluster: <cluster name>
    user: oidc@<cluster name>
  name: <cluster name>
current-context: <cluster name>
kind: Config
preferences: {}
users:
- name: oidc@<cluster name>
  user:
    auth-provider:
      config:
        client-id: <client id>
        client-secret:  <client secret>
        idp-issuer-url: <idp issuer url>
      name: oidc

The OIDC settings can be consumed from the organization CRD (default). Optionally, an org-wide alternative clientID, clientSecret should be configurable in case of different IDS applications.

Acceptance Criteria:

• open-sourcing of Kubeconfig Generator within CloudOperators Organisation
• integration with Greenhouse as a Core Plugin e.g. Service Proxy, which is available for all Organisations.
• Introduction of new CRD to store generated KubeConfigs

References

kubeconfig-generator plugin

Reference Issues

No response

[onuryilmaz]

464 defines CRD to store kubeconfig data as part of Kubernetes API

Next step is creating and additional controller (for watching Cluster resources) by re-using kubeconfig-generator logic

[onuryilmaz]

controller PR is open: https://github.com/cloudoperators/greenhouse/pull/526