OIDC Provider Setup
Choosing Your OIDC Provider
Using the Internal OIDC Identity Provider
If you do not have access to your own OpenID Connect (OIDC) provider, you can use the internal OIDC identity provider. It is enabled by default in the Helm chart.
We do not recommend using the internal OIDC identity provider in production environments managing sensitive or confidential data. The API provided for interacting with the internal OIDC identity provider exposes the entire user list stored in the provider. This means that users can see all the users that are part of their organization, as well as users that are not part of their organization. If you have multiple organizations or want to reduce the risk of data leaking, we recommend you use an external OIDC Identity Provider.
You can provide the certificate to the internal OIDC identity provider through either of the following methods:
Certificate in Referenced Secret object
dex: ingress: authHost: 'auth.company.com' tls: authSecretName: gooddata-cn-auth-tls
Certificate Generated by cert-manager
The internal OIDC identity provider supports cert-manager annotations to dynamically provision certificates. Example:
dex: ingress: authHost: 'auth.company.com' annotations: cert-manager.io/cluster-issuer: letsencrypt-production
Using your own OIDC provider
You do not need to deploy the internal OIDC identity provider if you have your own OIDC provider (Okta, Auth0 and others).
The OIDC provider setup for each Organization is covered in the Administration Guide.