add the possibility to configure keycloak with an OIDC identity provider (!7592) · Merge requests · Sylva-projects / sylva-core

What does this MR do and why?

This MR allows to configure keycloak with an OIDC identity provider. It allows to use Sylva while managing users and group with an upstream identity management system. This MR considers keycloak as upstream IDP.

The use-case is the following:

[ Upsteam Keycloak ] -------- [ Sylva Keycloak ] ---- [ Sylva OIDC Clients ]

For details, please refer to the documentation sylva-projects.gitlab.io!326 (merged)

The MR configures the necessary identity provider mappers binding a given upstream group to the Sylva technical group infra-admins, i.e. the default mappers only grant infra admin privileges.

When an indentity provider is configured, the unit keycloak-user-management is disabled. Actually, when a user authenticates with an account from the upstream keycloak, this account is added as a member of the group infra-admins (part of the sylva realm in sylva's keycloak). The problem is that, when the unit keycloak-user-management is reconciled, the membership of the group infra-admins is recreated and the usptream account is removed from this group, i.e. the upstream account looses its privileges. Anyway, the membership management methods (managing group membership via keycloak-user-management or through the mappers of the identity providers) should not be supported at the same time, so that there is only one source of truth (identities should be managed in a single place, i.e. either at Sylva or at the upstream domain side, for the sake of consistency and auditability).

closes #3951 (closed)

CI configuration

Below you can choose test deployment variants to run in this MR's CI.

Click to open to CI configuration

Legend:

Icon	Meaning	Available values
☁️	Infra Provider	`capd`, `capo`, `capm3`
🚀	Bootstrap Provider	`kubeadm` (alias `kadm`), `rke2`, `okd`, `ck8s`
🐧	Node OS	`ubuntu`, `suse`, `na`, `leapmicro`
🛠️	Deployment Options	Deployment option list and description
🎬	Pipeline Scenarios	Available scenario list and description
🟢	Enabled units	Any available units name, by default apply to management and workload cluster. Can be prefixed by `mgmt:` or `wkld:` to be applied only to a specific cluster type
🔴	Disabled units	Any available units name, by default apply to management and workload cluster. Can be prefixed by `mgmt:` or `wkld:` to be applied only to a specific cluster type
🏗️	Target platform	Can be used to select specific deployment environment Available platform list and description
⚡	Pipeline control	`autorun`, `manual` or `blocking`. Can be used to override global config and start a deployment pipeline the required way

Global config for deployment pipelines

autorun pipelines
allow failure on pipelines
record sylvactl events

Notes:

Enabling autorun will make deployment pipelines to be run automatically without human interaction
Disabling allow failure will make deployment pipelines mandatory for pipeline success.
if both autorun and allow failure are disabled, deployment pipelines will need manual triggering but will be blocking the pipeline

Be aware: after configuration change, pipeline is not triggered automatically. Please run it manually (by clicking the run pipeline button in Pipelines tab) or push new code.

Edited May 04, 2026 by Pierrick Seite

add the possibility to configure keycloak with an OIDC identity provider

What does this MR do and why?

CI configuration

Global config for deployment pipelines

Merge request reports