diff --git a/content/kubermatic/main/architecture/concept/kkp-concepts/kkp-security/securing-system-services/_index.en.md b/content/kubermatic/main/architecture/concept/kkp-concepts/kkp-security/securing-system-services/_index.en.md index 6720d137c..d7443e905 100644 --- a/content/kubermatic/main/architecture/concept/kkp-concepts/kkp-security/securing-system-services/_index.en.md +++ b/content/kubermatic/main/architecture/concept/kkp-concepts/kkp-security/securing-system-services/_index.en.md @@ -17,7 +17,7 @@ proxy's authentication entirely. ## Configuration Dex can then be configured to use external authentication sources like GitHub's or Google's OAuth endpoint, LDAP or -OpenID Connect. For this to work you have to configure both Dex (the `oauth` Helm chart) and OAuth2-Proxy +OpenID Connect. For this to work you have to configure both Dex (the `dex` Helm chart) and OAuth2-Proxy (called "IAP", Identity-Aware Proxy) in your Helm `values.yaml`. ### Dex @@ -33,36 +33,41 @@ A sample configuration for Prometheus and Alertmanager could look like this: ```yaml dex: ingress: - host: kkp.example.com - - clients: - # keep the KKP client for the login to the KKP dashboard - - id: kubermatic - # ... - - # new client used for authenticating Prometheus - - id: prometheus # a unique identifier - name: Prometheus - secret: - RedirectURIs: - - 'https://prometheus.kkp.example.com/oauth/callback' - - # new client used for authenticating Alertmanager - - id: alertmanager # a unique identifier - name: Alertmanager - secret: - RedirectURIs: - - 'https://alertmanager.kkp.example.com/oauth/callback' + hosts: + - host: kkp.example.com + paths: + - path: /dex + pathType: ImplementationSpecific + + config: + staticClients: + # keep the KKP client for the login to the KKP dashboard + - id: kubermatic + # ... + + # new client used for authenticating Prometheus + - id: prometheus # a unique identifier + name: Prometheus + secret: + RedirectURIs: + - 'https://prometheus.kkp.example.com/oauth/callback' + + # new client used for authenticating Alertmanager + - id: alertmanager # a unique identifier + name: Alertmanager + secret: + RedirectURIs: + - 'https://alertmanager.kkp.example.com/oauth/callback' ``` -Each service should have its own credentials (i.e. a different `secret` for every client). Re-deploying the `oauth` chart +Each service should have its own credentials (i.e. a different `secret` for every client). Re-deploying the `dex` chart with Helm will now prepare Dex to act as an authentication provider, but there is no OAuth2-Proxy yet to make use of this: **Helm 3** ```bash -helm --namespace oauth upgrade --install --wait --values /path/to/your/helm-values.yaml oauth charts/oauth/ +helm --namespace dex upgrade --install --wait --values /path/to/your/helm-values.yaml dex charts/dex/ ``` ### OAuth2-Proxy (IAP) diff --git a/content/kubermatic/main/installation/install-kkp-ce/_index.en.md b/content/kubermatic/main/installation/install-kkp-ce/_index.en.md index 1782f8761..3c0c76dc4 100644 --- a/content/kubermatic/main/installation/install-kkp-ce/_index.en.md +++ b/content/kubermatic/main/installation/install-kkp-ce/_index.en.md @@ -126,14 +126,18 @@ Both files will include secret data, so make sure to securely store them (e.g. i The release archive hosted on GitHub contains examples for both of the configuration files (`values.example.yaml` and `kubermatic.example.yaml`). It's a good idea to take them as a starting point and add more options as necessary. +{{% notice note %}} +Fresh installations default to the upstream Dex chart (`dex`) with `useNewDexChart: true` (set in `values.example.yaml`), replacing the legacy `oauth` chart. +{{% /notice %}} + The key items to consider while preparing your configuration files are described in the table below. | Description | YAML Paths and File | | ------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------- | -| The base domain under which KKP shall be accessible (e.g. `kkp.example.com`). | `.spec.ingress.domain` (`kubermatic.yaml`), `.dex.ingress.host` (`values.yaml`); also adjust `.dex.clients[*].RedirectURIs` (`values.yaml`) according to your domain. | +| The base domain under which KKP shall be accessible (e.g. `kkp.example.com`). | `.spec.ingress.domain` (`kubermatic.yaml`), `.dex.ingress.hosts[0].host` and `dex.ingress.tls[0].hosts[0]` (`values.yaml`); also adjust `.dex.config.staticClients[*].RedirectURIs` (`values.yaml`) according to your domain. | | The certificate issuer for KKP (KKP requires it since the dashboard and Dex are accessible only via HTTPS); by default cert-manager is used, but you have to reference an issuer that you need to create later on. | `.spec.ingress.certificateIssuer.name` (`kubermatic.yaml`) | -| For proper authentication, shared secrets must be configured between Dex and KKP. Likewise, Dex uses yet another random secret to encrypt cookies stored in the users' browsers. | `.dex.clients[*].secret` (`values.yaml`), `.spec.auth.issuerClientSecret` (`kubermatic.yaml`); this needs to be equal to `.dex.clients[name=="kubermaticIssuer"].secret` (`values.yaml`), `.spec.auth.issuerCookieKey` and `.spec.auth.serviceAccountKey` (both `kubermatic.yaml`) | -| To authenticate via an external identity provider, you need to set up connectors in Dex. Check out [the Dex documentation](https://dexidp.io/docs/connectors/) for a list of available providers. This is not required, but highly recommended for multi-user installations. | `.dex.connectors` (`values.yaml`; not included in example file) | +| For proper authentication, shared secrets must be configured between Dex and KKP. Likewise, Dex uses yet another random secret to encrypt cookies stored in the users' browsers. | `.dex.config.staticClients[*].secret` (`values.yaml`), `.spec.auth.issuerClientSecret` (`kubermatic.yaml`); this needs to be equal to `.dex.config.staticClients[name=="kubermaticIssuer"].secret` (`values.yaml`), `.spec.auth.issuerCookieKey` and `.spec.auth.serviceAccountKey` (both `kubermatic.yaml`) | +| To authenticate via an external identity provider, you need to set up connectors in Dex. Check out [the Dex documentation](https://dexidp.io/docs/connectors/) for a list of available providers. This is not required, but highly recommended for multi-user installations. | `.dex.config.connectors` (`values.yaml`; commented in example file) | | The expose strategy which controls how control plane components of a User Cluster are exposed to worker nodes and users. See [the expose strategy documentation]({{< ref "../../tutorials-howtos/networking/expose-strategies/" >}}) for available options. Defaults to `NodePort` strategy, if not set. | `.spec.exposeStrategy` (`kubermatic.yaml`; not included in example file) | | Telemetry used to track the KKP and k8s cluster usage, uuid field is required and will print an error message when that entry is missing. | `.telemetry.uuid` (`values.yaml`) | diff --git a/content/kubermatic/main/tutorials-howtos/oidc-provider-configuration/share-clusters-via-delegated-oidc-authentication/_index.en.md b/content/kubermatic/main/tutorials-howtos/oidc-provider-configuration/share-clusters-via-delegated-oidc-authentication/_index.en.md index 652a5df49..f4d044c5f 100644 --- a/content/kubermatic/main/tutorials-howtos/oidc-provider-configuration/share-clusters-via-delegated-oidc-authentication/_index.en.md +++ b/content/kubermatic/main/tutorials-howtos/oidc-provider-configuration/share-clusters-via-delegated-oidc-authentication/_index.en.md @@ -100,17 +100,18 @@ spec: issuerRedirectURL: https://example.com/api/v1/kubeconfig ``` -These values must match the configuration used for the `oauth` Helm chart (Dex). Define +These values must match the configuration used for the `dex` Helm chart (Dex). Define the new `issuerClientID` in Dex by editing your `values.yaml` used for setting Dex up: ```yaml dex: - clients: - - id: kubermaticIssuer - name: Kubermatic OIDC Issuer - secret: "" # put the value of issuerClientSecret here - RedirectURIs: - - https://example.com/api/v1/kubeconfig # issuerRedirectURL + config: + staticClients: + - id: kubermaticIssuer + name: Kubermatic OIDC Issuer + secret: "" # put the value of issuerClientSecret here + RedirectURIs: + - https://example.com/api/v1/kubeconfig # issuerRedirectURL ``` ## Root CA Certificates Chain @@ -125,12 +126,12 @@ OIDC provider. ## Update KKP -After all values are set up, it's time to update the KKP master cluster. Update the `oauth` chart first: +After all values are set up, it's time to update the KKP master cluster. Update the `dex` chart first: **Helm 3** ```bash -helm --namespace oauth upgrade --install --wait --values values.yaml oauth charts/oauth/ +helm --namespace dex upgrade --install --wait --values values.yaml dex charts/dex/ ``` Now that the issuer is available, update the `KubermaticConfiguration`: diff --git a/content/kubermatic/v2.27/installation/install-kkp-ce/_index.en.md b/content/kubermatic/v2.27/installation/install-kkp-ce/_index.en.md index 1782f8761..6be470c45 100644 --- a/content/kubermatic/v2.27/installation/install-kkp-ce/_index.en.md +++ b/content/kubermatic/v2.27/installation/install-kkp-ce/_index.en.md @@ -481,4 +481,4 @@ This will allow you to use the KKP Dashboard and API as an admin. Other users ca ## Next Steps * [Add a Seed cluster]({{< ref "./add-seed-cluster" >}}) to start creating User Clusters. -* Install the [Master / Seed Monitoring, Logging & Alerting Stack]({{< ref "../../tutorials-howtos/monitoring-logging-alerting/master-seed/installation" >}}) to collect cluster-wide metrics in a central place. +* Install the [Master / Seed Monitoring, Logging & Alerting Stack]({{< ref "../../tutorials-howtos/monitoring-logging-alerting/master-seed/installation" >}}) to collect cluster-wide metrics in a central place. \ No newline at end of file