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.

[MarekMichali]

We would like to provide the user with only the OIDC array list schema in the cockpit, but we still need to accept the OIDC object type for backward compatibility.

• check with btp cli if it is possible to send an object if it is not defined in the schema --> btp cli validates the input with the schema before sending to KEB

Check if the schema supports loading the default OIDC as the first element of the array so that the default is defined explicitly. Below scenarios should be supported:

1. Create a new SKR without a user-defined OIDC. Only the default OIDC should be defined as the first element of the array
2. Create a new SKR with a default OIDC and a user-defined OIDC.
3. Create a new SKR without a default OIDC, only with a user-defined OIDC

The update schema should also only list additionalOIDC array list.
The GET function should return only the array list, even if only an object was originally provided