Handle shoot-oidc-service extension when provisioning kyma

[kwiatekus]

Description

Provisioner should always enable shoot-oidc-service feature flag when provisioning kyma runtime
When additional OIDC issuer is requested, provisioner should create this OIDC resource in the provisioned shoot cluster
https://community.sap.com/t5/additional-blogs-by-sap/using-github-actions-openid-connect-in-kubernetes/ba-p/13542513
and configure cluster admin role binding for the subject of the token issued by the additional issuer.

AC

• OIDC is part of the technical contract for KIM (= part of Runtime-CR)
• Following two fields are required in the final Runtime-CR, but for KEB is is not mandatory to set them initially. If one of these field is missing or empty, a default values will be set by KIM (default values are static values in the KIM configuration):
  • oidcConfig (default value is Kyma-OIDC provider - it will be only set if no configuration is provided by KEB)
  • additionalOidcConfigs (is a list, if list is empty KIM has to set one default entry to the list)

Reasons

It is required for the kyma-project/kyma#18305

Attachments
kyma-project/kyma#18519 (comment)
https://github.com/kyma-project/control-plane/tree/main/components/provisioner

Sample resource:

apiVersion: authentication.gardener.cloud/v1alpha1
kind: OpenIDConnect
metadata:
  name: actions-oidc
spec:
  issuerURL: https://token.actions.githubusercontent.com
  clientID: my-kubernetes-cluster
  usernameClaim: sub
  usernamePrefix: "actions-oidc:"
  requiredClaims:
    repository: myOrg/myRepo
    workflow: deploy-kubernetes
    ref: refs/heads/main

[tobiscr]

PR from @kyma-project/otters for provisioner: #3358

Docs from Gardener: https://github.com/gardener/gardener-extension-shoot-oidc-service/blob/master/docs/usage/openidconnects.md

[tobiscr]

We have it on our TODO list, but right now - based on the current ranked backlog it will be considered as part of our deliverables in Q2/24.

[tobiscr]

We agreed on following implementation on KIM side:

• KIM will store the default values for some fields in our RuntimeCR (e.g. oidcConfig)
• We will have a few fields in the RuntimeCR , which won't be necessarily provided by KEB but have to be filled out with default values by KIM (<< having them in the RuntimeCR included is helpful for later operational actions applied by SRE - they will sometimes have to adjust these values when major cluster-upgrades are applied)
• It's KIMs responsibility, to check for each creation/update of a RuntimeCR instance, that missing fields will be added to this CR with their default values (could be done by an webhook executed before KIM starts processing the values etc.)