Using OpenID Connect with Cozystack on Cozystack

Enable OIDC Server

Mon, 01 Jan 0001 00:00:00 +0000

Prerequisites

OIDC Configuration Your API server must be configured to use OIDC. If you are using Talos Linux, your machine configuration should include the following parameters:

cluster:
 apiServer:
 extraArgs:
 oidc-issuer-url: "https://keycloak.example.org/realms/cozy"
 oidc-client-id: "kubernetes"
 oidc-username-claim: "preferred_username"
 oidc-groups-claim: "groups"

For Talm Add to your values.yaml in talm repo:

oidcIssuerUrl: "https://keycloak.<YOUR_ROOT_DOMAIN>/realms/cozy"

Domain Reachability Ensure that the domain keycloak.example.org is accessible from the cluster and resolves to your root ingress controller.

Creating users and add roles for them

Mon, 01 Jan 0001 00:00:00 +0000

Creating users and add roles for them

Overview

When a tenant is created in Cozy (starting with version 1.6.0), roles, RoleBindings and keycloak groups will automatically be created in the Kubernetes cluster.

To create a user, refer to the following documentation: Keycloak Admin Console Documentation

Assigning a Role to a User for a Tenant

Access Keycloak: To retrieve login credentials, check the secret by running the following command:
```
kubectl get secret keycloak-credentials -n cozy-keycloak -o yaml
```
Keycloak Address: The Keycloak address will match the publishing.host value specified in your Platform Package. For example, if your Package includes:

Private CA and Let's Encrypt Staging

Mon, 01 Jan 0001 00:00:00 +0000

This guide explains how to serve Keycloak with a certificate that is not publicly trusted and how to establish trust in every OIDC client. It covers private certificate authorities (CAs), Let’s Encrypt staging, wildcard certificates, Talos, the Kubernetes API server, browsers, and kubelogin.

Choose a certificate source

Source	Recommended use	Publicly trusted	Notes
Let’s Encrypt production	Production	Yes	Subject to production rate limits. Prefer a DNS-01 wildcard when many endpoints share a domain.
Let’s Encrypt staging	Ephemeral and development clusters	No	Uses separate accounts and much higher limits than production. Trust staging roots only in isolated development clients.
Private CA	Air-gapped and corporate environments	No	Distribute the CA certificate to every trust boundary. Keep the CA stable and rotate leaf certificates beneath it.
Direct self-signed leaf	Temporary diagnostics only	No	Every leaf replacement changes the trust anchor. Use a self-signed issuer to bootstrap a CA instead.

Let’s Encrypt explicitly warns against adding its staging roots to a trust store used for ordinary browsing because the staging hierarchy is not audited to production standards. A dedicated browser profile, disposable VM, or isolated development workstation avoids extending that trust to unrelated browsing. See the Let’s Encrypt staging environment for the current staging root certificates and limits.