Extend Kyma Provisioning Parameters to allow multiple OIDC definitions

[kwiatekus]

Description

Adjust set of input parameters of Kyma Service Instance Provisioning so that user can provide multiple OIDC configs (design oidc paramater so that in accepts a single config (for backwards compatibility) or an array).

Extend the OIDC schema so that user could also define requiedClaims (key-value pairs) that are essential for secure GH workflow access.

AC
Phase 1: migration - Size/M

• coordinate migration with SRE, see below
• Implement solutions for migration (see: Support additional OIDC configuration with shoot-oidc-service extension kyma#18305 (comment))

Phase 2: feature implementation - Size/L

• User can define multiple OIDC configs
• User can define required claims per OIDC config
• API proposal
  • must be backward compatible
• Additional OIDC proposal Implementation (see: Support additional OIDC configuration with shoot-oidc-service extension kyma#18305 (comment))
• Kubeconfig "context" enhancement to show all OIDCs that user sets. Default set to array[0]
  • INFO: Busola will make use of that to allow user to select on of them.
• E2E test
• Test load_current_config feature with OIDC data with object vs array. Check is existing values are available to user in the BTP form.
• Deploy: (only possible if Phase 1 fininshed)
  • dev + ERS update
  • stage + ERS update
  • prod + ERS update

Reasons

It is required to configure access to freshly created clusters via additional "workflow" OIDC
kyma-project/kyma#18305

Attachments

• diagram
• flow diagram
• https://community.sap.com/t5/additional-blogs-by-sap/using-github-actions-openid-connect-in-kubernetes/ba-p/13542513

Progress:

• we planned to start 12.022025, but some findings popup: 1) we should not have access to all SKRs, customer should grant that to use, and 2) many issuers support. We will discuss that 10.02.2025

[PK85]

Looks that Provisioner exposes APIs with pods and services CIDRs. We need to test it.

[kwiatekus]

As a first step we could enable that only for DEV landscape on a dedicated plan (preview):

• make sure KEB on DEV is creating RuntimeCR
• make sure KEB can consume extended provisiong parameters (incl. required claims and multiple oidc)

[ralikio]

Proposed based on last planning:

To preserve backward compatibility we would like to define a new parameter (e.g. "Additional OIDC") defined in the schema as a list. Old parameter will be functional and extended with requiredClaims. If user defined additional OIDC in the list and at the same time provides backward compatible one then we want to merge both.

[PK85]

blocked by KIM. Kim must be released on prod first

[PK85]

See what we need to do taking into account the migration:

• Support additional OIDC configuration with shoot-oidc-service extension kyma#18305 (comment)

[PK85]

Here Information what KEB must support, kyma-project/kyma#18305 (comment)

Design API and present to me. We need to keep backward compatibility. That means our current oidc attribute could be a single object or array.