Support additional OIDC configuration with shoot-oidc-service extension

[pbochynski]

Description Enable the option to trust the additional identity provider compliant with OpenID. The provider can be registered in the Kyma cluster and kubernetes API server will authenticate tokens that match the provider issuer. The complete solution should allow to establish the trust during the provisioning so the cluster can be accessed from fully automated processes (without user presence). To accomplish that the following changes are required:

• enable shoot-oidc-service extension for shoot clusters
• add possibility to pass the OpenIDConnect resource in the shoot cluster as Kyma instance parameter (KEB)
• grant permissions to accounts authenticated by new provider by some role and role binding (or use the existing feature of extending administrator list)

Acceptance Criteria

• [ ] Ensure Isolation between user facing and operator-facing OIDC configs. User should not be able to override Opereator facing OIDC
  • [ ] Configure Operator facing OIDC
  • [ ] https://github.com/kyma-project/kyma-environment-broker/issues/423

Reasons Many users request a possibility to deploy software to freshly creaated Kyma clusters in automated way. Changing the default IDP for the cluster is the only solution available for now, but then IDP has to support both human users and service accounts what is usually challenging. With additional OIDC provider it can be used only for system to system authorization and will be much easier to set up.

Links

• https://github.com/kyma-project/kyma/issues/18198
• https://github.com/gardener/oidc-webhook-authenticator/blob/master/README.md
• https://blogs.sap.com/2022/09/23/using-github-actions-openid-connect-in-kubernetes/
• https://github.com/gardener/gardener-extension-shoot-oidc-service/blob/master/docs/usage/openidconnects.md

[maximilianbraun]

Would love to test it at earliest convinience.

[kyma-bot]

This issue or PR has been automatically marked as stale due to the lack of recent activity. Thank you for your contributions.

This bot triages issues and PRs according to the following rules:

• After 60d of inactivity, lifecycle/stale is applied
• After 7d of inactivity since lifecycle/stale was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Close this issue or PR with /close

If you think that I work incorrectly, kindly raise an issue with the problem.

/lifecycle stale

[kwiatekus]

The goal would be to allow kyma users to deploy apps (and run tests ) on the provisioned kyma runtimes in the CI jobs .

Execution can be divided into several stages:

• [x] https://github.com/kyma-project/kyma/issues/18519
• [ ] https://github.com/kyma-project/control-plane/issues/3316 - Q2 2024 (see comment)
• [ ] https://github.com/kyma-project/kyma-environment-broker/issues/423

[kwiatekus]

OIDC configuration will be included in the gardener provisioning in q2 https://github.com/kyma-project/control-plane/issues/3316#issuecomment-1963822606

[github-actions[bot]]

This issue has been automatically marked as stale due to the lack of recent activity. It will soon be closed if no further activity occurs. Thank you for your contributions.

[kwiatekus]

Kyma Infrastructure Manager (KIM) should apply Operator-Facing OIDC separately from User-facing OIDC(s)

In order to allow this we need to adjust the interfaces: 1) User -> Kyma Environment Broker (KEB)

• User should be able to define multiple OIDCs

• User should be able to define requiedClaims (key-value pairs)

  2) KEB -> KIM

  • If user provides OIDC(s) KEB populates them as additionalOidcConfigs
  • If user provides no OIDC config KIM defaults the additionalOidcConfigs[0] with the default User-facing OIDC config
  • KIM defaults oidcConfig with Operator-facing OIDC

3) KIM -> Gardener

• KIM enables shoot-oidc-service extension in shoot CR
• KIM defines Operator-facing OIDC explicitely in shoot CR

4) KIM -> Kyma

• KIM reconciles authentication.gardener.cloud/v1alpha1/OpenIDConnect objects in kyma based on additionalOidcConfigs
• KIM reconciles the clusterrolebindings based on administrators it got from KEB
• KIM ensures clusterrole binding for operators

to avoid unwanted impersonations, we should:

• ensure prefixes in Operator-facing OIDC (for username and groups)
• document recommendation about prefixes in user facing documentation

[Disper]

Regarding migration from existing shoots to Runtime CRs.

• oidcConfig <- Populate withoidcConfig
• additionalOidcConfigs <- Populate as the first entry withoidcConfig

[burkardendres]

Would be great to have this available soon, as a dependency we want to use requires that and also to bring our kya into production it would be kind of a prerequisite.