Feature Description

Currently, kcp allows to configure authentication (authN) via command line flags on the kcp binary or via a AuthenticationConfiguration file passed via a flag.

To make kcp more of a multi-tenant platform, it would be great to be able to configure authentication strategies on a per-workspace basis. This way, different workspaces could be configured for different OIDC providers (e.g. on a per-customer basis).

Proposed Solution

Configuration of workspace-level authentication should be typed, i.e. we should probably introduce a new WorkspaceAuthenticationConfiguration resource in the tenancy API. Workspaces and WorkspaceTypes should be able to reference it, even across workspace boundaries (which means we need a new RBAC verb for this, i.e. use, that can be configured on the WorkspaceAuthenticationConfiguration objects.

An example could look like this:

apiVersion: tenancy.kcp.io/v1alpha1
kind: WorkspaceAuthenticationConfiguration
metadata:
    name: oidc-tenant-1
spec:
    jwt:
    - issuer:
        url: https://example.com # Same as --oidc-issuer-url.
        discoveryURL: https://discovery.example.com/.well-known/openid-configuration
        certificateAuthority: <PEM encoded CA certificates>    
        audiences:
        - my-app # Same as --oidc-client-id.
        - my-other-app

Given that WorkspaceTypes would support this, we might skip inheritance from one workspace into child workspaces by default and instead allow configuring child workspaces via workspace type allowed children. This likely means that this resource needs to be replicated to the cache server.

Authentication should be additive, i.e. both the globally configured authentication and the per-workspace authentication should allow for accessing a workspace with this configured. The logical conclusion from this behaviour is that global authentication should only include the smallest possible set of users.

Special consideration should be given to RBAC across workspace boundaries. We might want to look into introducing some pseudo-groups that allow giving access to any user able to authenticate into a specific workspace instead of specific users or groups, since these might be arbitrary given the high amount of independence workspaces achieve with their own authentication configuration.

Alternative Solutions

No response

Want to contribute?

• I would like to work on this issue.

Additional Context

No response