feat(clusterkubeconfigs): enable organization and cluster level overrides with labels

[onuryilmaz]

Description

This PR enables overriding client-id and client-secret values of ClusterKubeconfig resources based on the labels assigned to Organization and Cluster resources:

greenhouse.sap/clusterkubeconfig-ovveride-clientid
greenhouse.sap/clusterkubeconfig-ovveride-clientsecret

What type of PR is this? (check all applicable)

• 🍕 Feature
• 🐛 Bug Fix
• 📝 Documentation Update
• 🎨 Style
• 🧑‍💻 Code Refactor
• 🔥 Performance Improvements
• ✅ Test
• 🤖 Build
• 🔁 CI
• 📦 Chore (Release)
• ⏩ Revert

Related Tickets & Documents

Closes #1402

Added tests?

• 👍 yes
• 🙅 no, because they aren't needed
• 🙋 no, because I need help
• Separate ticket for tests # (issue/pr)

Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration

Added to documentation?

• 📜 README.md
• 🤝 Documentation pages updated
• 🙅 no documentation needed
• (if applicable) generated OpenAPI docs for CRD changes

Checklist

• My code follows the style guidelines of this project
• I have performed a self-review of my code
• I have commented my code, particularly in hard-to-understand areas
• My changes generate no new warnings
• New and existing unit tests pass locally with my changes

[IvoGoman]

client id & secret are essentially like username and password. We should not store them in resource metadata.

How about using the organisation's to store the override configuration.

e.g.

- cluster: "*" # all clusters
   clientID:
      secretRef: {}
   clientSecret:
      secretRef: {}
- cluster: "my-cluster" # only the "my-cluster"
   clientID:
      secretRef: {}
   clientSecret:
      secretRef: {}

Then the controller get's the configuration from there and the values are kept hidden. Endusers might still get to see these, but only if they have permissions to retrieve the ClusterKubeConfigs. So we can still control who can/cannot access them.

[onuryilmaz]

client id & secret are essentially like username and password. We should not store them in resource metadata.

How about using the organisation's to store the override configuration.

e.g.

- cluster: "*" # all clusters
   clientID:
      secretRef: {}
   clientSecret:
      secretRef: {}
- cluster: "my-cluster" # only the "my-cluster"
   clientID:
      secretRef: {}
   clientSecret:
      secretRef: {}

Then the controller get's the configuration from there and the values are kept hidden. Endusers might still get to see these, but only if they have permissions to retrieve the ClusterKubeConfigs. So we can still control who can/cannot access them.

Do you mean extending Organization API spec with something similar to:

type Authentication struct {
	// OIDConfig configures the OIDC provider.
	OIDCConfig *OIDCConfig `json:"oidc,omitempty"`
	// SCIMConfig configures the SCIM client.
	SCIMConfig *SCIMConfig `json:"scim,omitempty"`
	// OIDConfigOverride configures override values for clusters of this organization.
	OIDCConfigOverride *OIDCConfigOverride `json:"oidcConfigOverride,omitempty"`
}

[uwe-mayer]

After discussing with @IvoGoman , the following approach should cover it best:

Annotate the (Cluster-) Secrets with:

greenhouse.sap/oidc-override: {
    "clientIDReference" : {
      "key": <secret-key>
      "name": <secret-name>
    }
    "clientSecretReference": {
      "key": <secret-key>
      "name": <secret-name>
    }
}

This

• is consistent with how OIDC credentials are spec'ed on the Organization
• puts the overrides on the Cluster (single source of truth --> no duplicate (label) matching for overrides)
• keeps credentials centrally in a Secret

WDYT?

[onuryilmaz]

After discussing with @IvoGoman , the following approach should cover it best:

Annotate the (Cluster-) Secrets with:

greenhouse.sap/oidc-override: {
    "clientIDReference" : {
      "key": <secret-key>
      "name": <secret-name>
    }
    "clientSecretReference": {
      "key": <secret-key>
      "name": <secret-name>
    }
}

This

• is consistent with how OIDC credentials are spec'ed on the Organization
• puts the overrides on the Cluster (single source of truth --> no duplicate (label) matching for overrides)
• keeps credentials centrally in a Secret

WDYT?

This approach sounds good, I will update this PR accordingly 👍

[onuryilmaz]

@uwe-mayer @IvoGoman annotation based overrides are implemented in this PR