From 5b21c1c802d63b7f1cf99dc7daf0b67ffdd74298 Mon Sep 17 00:00:00 2001 From: mdziadosz Date: Wed, 29 May 2024 16:55:31 +0200 Subject: [PATCH 01/12] Authentication section update --- content/docs/reference/authentication/LDAP.md | 81 ++++++++------ content/docs/reference/authentication/OIDC.md | 62 ++++++----- .../docs/reference/authentication/README.md | 25 ----- content/docs/reference/authentication/SAML.md | 103 ++++++++++-------- .../authentication/authentication.md | 38 +++++++ 5 files changed, 181 insertions(+), 128 deletions(-) delete mode 100644 content/docs/reference/authentication/README.md create mode 100644 content/docs/reference/authentication/authentication.md diff --git a/content/docs/reference/authentication/LDAP.md b/content/docs/reference/authentication/LDAP.md index c459c277..8d3ba7c1 100644 --- a/content/docs/reference/authentication/LDAP.md +++ b/content/docs/reference/authentication/LDAP.md @@ -1,31 +1,15 @@ # LDAP -LDAP can be configured by setting up the `ldap` section in the `authentication` section of the MKE4 config. This also has its own `enabled` field which is disabled by default and much be switched to 'true' to enable LDAP. - -The remaining fields are used to configure the interactions with your LDAP server. Full details of these fields can be found in the (https://dexidp.io/docs/connectors/ldap/#configuration)[dex documentation] . - -| Field | Description | -| -------------------------------- | ------------------------------------------------------------------------- | -| host | Host and optional port of the LDAP server in the form "host:port" | -| rootCA | Path to a trusted root certificate file | -| bindDN | The DN for an application service account | -| bindPW | The password for an application service account | -| usernamePrompt | The attribute to display in the provided password prompt | -| userSearch | Settings to map a username and password entered by a user to a LDAP entry | -| userSearch.baseDN | BaseDN to start the search from | -| userSearch.filter | Optional filter to apply when searching the directory | -| userSearch.username | username attribute used for comparing user entries | -| userSearch.idAttr | String representation of the user | -| userSearch.emailAttr | Attribute to map to Email. | -| userSearch.nameAttr | Maps to display name of user | -| userSearch.preferredUsernameAttr | Maps to preferred username of users | -| groupSearch | Group search queries for groups given a user entry | -| groupSearch.baseDN | BaseDN to start the search from | -| groupSearch.filter | Optional filter to apply when searching the directory | -| groupSearch.userMatchers | A list of field pairs that are used to match a user to a group | -| groupSearch.nameAttr | Represents group name | - -An example configuration for LDAP is shown below. +LDAP (Lightweight Directory Access Protocol) can be configured in +the `authentication` section of the Mirantis Kubernetes Engine (MKE) 4 config. +LDAP is disabled by default, to enable it set `enabled` to `true`. + +The remaining fields in the `authentication.ldap` section are used to configure +the interactions with your LDAP server. For more details, refer to +[LDAP configuration](https://dexidp.io/docs/connectors/ldap/#configuration) +in the official Dex documentation. + +An example configuration for LDAP: ```yaml authentication: @@ -46,15 +30,42 @@ authentication: nameAttr: cn ``` -## Authentication Flow +The following table details the fields that you can configure in the +`authentication.ldap` section of the MKE 4 config: + +| Field | Description | +|------------------------------------|----------------------------------------------------------------------------| +| `host` | Host and optional port of the LDAP server in the `host:port` format. | +| `rootCA` | Path to a trusted root certificate file. | +| `bindDN` | The DN for an application service account. | +| `bindPW` | The password for an application service account. | +| `usernamePrompt` | The attribute to display in the provided password prompt. | +| `userSearch` | Settings to map a username and password entered by a user to a LDAP entry. | +| `userSearch.baseDN` | BaseDN to start the search from. | +| `userSearch.filter` | Optional filter to apply when searching the directory. | +| `userSearch.username` | Username attribute used for comparing user entries. | +| `userSearch.idAttr` | String representation of the user. | +| `userSearch.emailAttr` | Attribute to map to email. | +| `userSearch.nameAttr` | Maps to display name of a user. | +| `userSearch.preferredUsernameAttr` | Maps to preferred usernames of users. | +| `groupSearch` | Group search queries for groups given a user entry. | +| `groupSearch.baseDN` | BaseDN to start the search from. | +| `groupSearch.filter` | Optional filter to apply when searching the directory. | +| `groupSearch.userMatchers` | A list of field pairs that are used to match a user to a group. | +| `groupSearch.nameAttr` | A group name. | + +## Authentication flow + +!!! tip "Testing" -> Ports `5556` (dex) and `5555` (example-app) will need to be available externally to test the authentication flow. + Ports `5556` (dex) and `5555` (example-app) need to be available externally + to test the authentication flow. -Do the following in the browser to test the authentication flow: +In the browser, perform the following steps to test the authentication flow: -1. Navigate to `http://{MKE hostname}:5555/login` -2. Click the `Login` button -3. On the login page, select "Log in with LDAP" -4. Enter the username and password for the LDAP server -5. Click the `Login` button -6. You should now be logged in and see application's home page +1. Navigate to `http://{MKE hostname}:5555/login`. +2. Click **Login**. +3. On the login page, select **Log in with LDAP**. +4. Enter the username and password for the LDAP server. +5. Click **Login**. +6. Successful authentication will redirect you back to the client applications home page. diff --git a/content/docs/reference/authentication/OIDC.md b/content/docs/reference/authentication/OIDC.md index 04d7d9a9..5c6002af 100644 --- a/content/docs/reference/authentication/OIDC.md +++ b/content/docs/reference/authentication/OIDC.md @@ -1,17 +1,14 @@ # OIDC -OIDC can be configured by setting up the `oidc` section in the `authentication` section of the MKE4 config. This also has its own `enabled` field which is disabled by default and must be switched to 'true' to enable OIDC. +OpenID Connect (OIDC) can be configured in the `authentication` section of +the Mirantis Kubernetes Engine (MKE) 4 config. +OIDC is disabled by default, to enable it set `enabled` to `true`. -The remaining fields are used to configure the OIDC provider. +The remaining fields in the `authentication.oidc` section are used to configure +the OIDC provider. Refer to [Configure Okta](#configure-okta) for +instructions on how to obtain the field values. -| Field | Description | -| ------------ | ------------------------------------------------------------------------- | -| issuer | The root URL of the OIDC provider | -| clientID | The id from the IdP's application configuration | -| clientID | The secret from the IdP's application configuration | -| redirect URI | The URI that the provider will be returning successful authentications to | - -An example configuration for OIDC is shown below: +An example configuration for OIDC: ```yaml authentication: @@ -24,30 +21,45 @@ authentication: redirectURI: http://dex.example.com:32000/callback ``` -Use the next section to understand how to configure Okta. Once the configuration is set, run the standard `mkectl apply` command with your config file and wait for the cluster to be ready. +The following table details the fields that you can configure in the +`authentication.oidc` section of the MKE 4 config: + +| Field | Description | +|----------------|----------------------------------------------------------------------------| +| `issuer` | The root URL of the OIDC provider. | +| `clientID` | The ID from the IdP's application configuration. | +| `clientSecret` | The secret from the IdP's application configuration. | +| `redirect URI` | The URI that the provider will be returning successful authentications to. | -## Configuring Okta +## Configure Okta Create a new application in Okta and use the following settings: -1. Sign-in method: OIDC - OpenID Connect -2. Application Type: Web Application -3. App integration name: Any name you can remember -4. The host for your redirect URLs +1. Select **OIDC - OpenID Connect** as the sign-in method. +2. Select **Web Application** as the application type. +3. Choose an app integration name that you can easily remember. +4. The host for your redirect URLs: - Sign-in redirect URIs: `http://{MKE hostname}/login` - Sign-out redirect URIs: `http://{MKE hostname}` -5. Save +5. Click **Save**. + +Okta will generate the `clientSecret` and `clientID` on the `General` table of +the application. Add the generated values to your MKE 4 config. + +Once the configuration is set, run the `mkectl apply` command with your config +file and wait for the cluster to be ready. -Okta will generate the secret and clientID on the `General` table of the application. Use these in your MKE4 config. +## Authentication flow -## Authentication Flow +!!! tip "Testing" -> Ports `5556` (dex) and `5555` (example-app) will need to be available externally to test the authentication flow. + Ports `5556` (dex) and `5555` (example-app) need to be available + externally to test the authentication flow. -Do the following in the browser to test the authentication flow: +In the browser, perform the following steps to test the authentication flow: 1. Navigate to `http://{MKE hostname}:5555/login` -2. Click the `Login` button -3. On the login page, select "Log in with OIDC" -4. You will be redirected to the IdP's login page. Enter your credentials and click `Sign In` -5. Successful authentication will redirect you back to client applications home page +2. Click **Login**. +3. On the login page, select **Log in with OIDC**. +4. You will be redirected to the IdP's login page. Enter your credentials and click **Sign In**. +5. Successful authentication will redirect you back to the client applications home page. diff --git a/content/docs/reference/authentication/README.md b/content/docs/reference/authentication/README.md deleted file mode 100644 index 0edd302e..00000000 --- a/content/docs/reference/authentication/README.md +++ /dev/null @@ -1,25 +0,0 @@ -# Authentication - -Mirantis Kubernetes Engine 4 (MKE4) uses [dex](https://github.com/dexidp/dex) for its authentication. If you would like to use a different authentication method, you can simply disable authentication in the MKE4 config and add your own authentication method. Be aware, this will require you to configure authentication completely yourself. - -## Pre-requisites - -- IdP - If you are setting up OIDC or SAML then you will need an IdP with an application configured. This example setup uses [okta](https://www.okta.com/) -- LDAP Server - If you are setting up LDAP then you will need an LDAP server with a user configured. - -## Configuration - -Authentication can be configured in the `authentication` section of the MKE4 config. By default, authentication is enabled but each of the individual authentication methods are disabled. It can be disabled by setting the root `enabled` to `false`. This will completely remove any authentication related components from being installed on the cluster. - -```yaml -authentication: - enabled: true -``` - -## Authentication Methods - -From here, check out the individual files for the different authentication methods: - -- [OIDC](./OIDC.md) -- [SAML](./SAML.md) -- [LDAP](./LDAP.md) diff --git a/content/docs/reference/authentication/SAML.md b/content/docs/reference/authentication/SAML.md index c9aa0d04..63acaef9 100644 --- a/content/docs/reference/authentication/SAML.md +++ b/content/docs/reference/authentication/SAML.md @@ -1,28 +1,16 @@ # SAML -SAML can be configured by setting up the `saml` section in the `authentication` section of the MKE4 config. This also has its own `enabled` field which is disabled by default and must be switched to 'true' to enable SAML. - -The remaining fields are used to configure the SAML provider. Many of these fields can be found as part of the [Dex SAML documentation](https://dexidp.io/docs/connectors/saml/). - -| Field | Description | -| ------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------- | -| enabled | Enable authentication through dex | -| ssoMetadataURL | The metadata url provided by some IdPs. MKE can use this to retrieve information for all other SAML configuration automatically | -| ca | Alternative to caData and localCa. CA to use when validating the signature of the SAML response. This must be manually mounted in a local accessible by dex | -| caData | Alternative to ca and localCa. Place the cert data directly in the config file | -| localCa | Alternative to ca and caData. A path to a Ca file the local system. MKE will mount and create a secret for the cert | -| ssoURL | The URL to send users to when signing in with SAML. Provided by the IdP | -| redirectURI | Dex's callback URL. Where users will be returned to after successful authentication with the IdP | -| insecureSkipSignatureValidation | Skip the signature validation. This should only be used for testing purposes (optional) | -| usernameAttr | A username attribute in the returned assertions to map to ID token claims | -| emailAttr | An email attribute in the returned assertions to map to ID token claims | -| groupsAttr | A groups attribute in the returned assertions to map to ID token claims (optional) | -| entityIssuer | Include this as the Issuer value during AuthnRequest (optional) | -| ssoIssuer | Issuer value expected in the SAML response (optional) | -| groupsDelim | If groups are assumed to be represented as a single attribute, this delimiter is used to split the attribute's value into multiple groups (optional) | -| nameIDPolicyFormat | Requested format of the NameID | - -An example configuration for SAML is shown below: +Security Assertion Markup Language (SAML) can be configured in +the `authentication` section of the Mirantis Kubernetes Engine (MKE) 4 config. +SAML is disabled by default, to enable it set `enabled` to `true`. + +The remaining fields in the `authentication.saml` section are used to configure +the SAML provider. Refer to [Configure Okta](#configure-okta) for +instructions on how to obtain the field values. For more details, see +[Authentication through SAML 2.0](https://dexidp.io/docs/connectors/saml/) +in the official Dex documentation. + +An example configuration for SAML: ```yaml authentication: @@ -36,15 +24,34 @@ authentication: emailAttr: email ``` -Use the next section to understand how to configure Okta and find the values for the example config above. Once the configuration is set, run the standard `mkectl apply` command with your config file and wait for the cluster to be ready. +The following table details the fields that you can configure in the +`authentication.saml` section of the MKE 4 config: -## Configuring Okta +| Field | Description | +|-----------------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------| +| `enabled` | Enable authentication through dex. | +| `ssoMetadataURL` | The metadata URL provided by some IdPs. MKE can use this to retrieve information for all other SAML configuration automatically. | +| `ca` | Alternative to `caData` and `localCa`. CA to use when validating the signature of the SAML response. This must be manually mounted in a local accessible by dex. | +| `caData` | Alternative to `ca` and `localCa`. Place the cert data directly in the config file. | +| `localCa` | Alternative to `ca` and `caData`. A path to a CA file in the local system. MKE will mount and create a secret for the cert. | +| `ssoURL` | The URL to send users to when signing in with SAML. Provided by the IdP. | +| `redirectURI` | Dex callback URL. Where users will be returned to after successful authentication with the IdP. | +| `insecureSkipSignatureValidation` | Optional. Skip the signature validation. To be used for testing purposes only. | +| `usernameAttr` | A username attribute in the returned assertions to map to ID token claims. | +| `emailAttr` | An email attribute in the returned assertions to map to ID token claims. | +| `groupsAttr` | Optional. A groups attribute in the returned assertions to map to ID token claims. | +| `entityIssuer` | Optional. Include this as the Issuer value during authentication request. | +| `ssoIssuer` | Optional. Issuer value expected in the SAML response. | +| `groupsDelim` | Optional. If groups are assumed to be represented as a single attribute, this delimiter is used to split the attribute's value into multiple groups. | +| `nameIDPolicyFormat` | Requested format of the name ID. | + +## Configure Okta Create a new application in Okta and use the following settings: -1. Sign-in method: SAML 2.0 -2. App name: Any name you can remember -3. The host for your redirect URLs +1. Select **SAML 2.0** as the **Sign-in method**. +2. Choose an app integration name that you can easily remember. +3. The host for your redirect URLs: - Single sign-on URL: `http://{MKE hostname}/callback` - Audience URI (SP Entity ID): `http://{MKE hostname}/callback` - Attribute statements: @@ -52,25 +59,35 @@ Create a new application in Okta and use the following settings:
Value: user.email - Name: name
Value: user.login -4. Save -5. Finish -6. Navigate to the `Assignments` tab -
a. Click on `Assign` -> `Assign to people` -
b. Find the account you would like to use for authentication and click the blue `Assign` button on the right +4. Click **Save**. +5. Click **Finish**. +6. Navigate to the **Assignments** tab: + + a. Click **Assign** -> **Assign to people**. + + b. Find the account you would like to use for authentication and click the blue **Assign** button on the right. Okta will generate the `ssoURL` and cert under the `Sign On` tab. The `ssoURL` will be the MetadataURL with the final metadata removed from the path. -The cert can be downloaded from the SAML Signing Certificates section. Click Actions on the active cert and download the cert. -Configure the `localCa` to point to this file on your system that you will run `mkectl` from. The cert in the example above is stored in `/etc/ssl/okta.cert`. +The cert can be downloaded from the SAML **Signing Certificates** section. +Click **Actions** on the active cert and download the cert. +Configure the `localCa` to point to this file on your system that you will run `mkectl` from. +The cert in the example above is stored in `/etc/ssl/okta.cert`. + +Once the configuration is set, run the `mkectl apply` command with your +configuration file and wait for the cluster to be ready. + +## Authentication flow -## Authentication Flow +!!! tip "Testing" -> Ports `5556` (dex) and `5555` (example-app) will need to be available externally to test the authentication flow. + Ports `5556` (dex) and `5555` (example-app) need to be available externally + to test the authentication flow. -Do the following in the browser to test the authentication flow: +In the browser, perform the following steps to test the authentication flow: -1. Navigate to `http://{MKE hostname}:5555/login` -2. Click the `Login` button -3. On the login page, select "Log in with SAML" -4. You will be redirected to the IdP's login page. Enter your credentials and click `Sign In` -5. Successful authentication will redirect you back to the client applications home page +1. Navigate to `http://{MKE hostname}:5555/login`. +2. Click **Login**. +3. On the login page, select **Log in with SAML**. +4. You will be redirected to the IdP's login page. Enter your credentials and click **Sign In**. +5. Successful authentication will redirect you back to the client applications home page. diff --git a/content/docs/reference/authentication/authentication.md b/content/docs/reference/authentication/authentication.md new file mode 100644 index 00000000..7fd67dc8 --- /dev/null +++ b/content/docs/reference/authentication/authentication.md @@ -0,0 +1,38 @@ +# Authentication + +Mirantis Kubernetes Engine (MKE) 4 uses Dex for authentication. +If you choose to use a different authentication method, you can disable +the authentication in the MKE 4 configuration file and add your own method. + +!!! caution "Changing authentication method" + + Changing the authentication method will require you to configure + authentication completely by yourself. + +## Prerequisites + +- Identity Provider (IdP) - To set OIDC or SAML you need to configure an IdP with an application. +Refer to [Add a SAML Identity Provider](https://help.okta.com/en-us/content/topics/security/idp-add-saml.htm) +tutorial from the official Okta documentation. +- LDAP Server - To set LDAP you need to configure an LDAP server with a user. + +## Configuration + +Authentication can be configured in the `authentication` section of the MKE 4 config. +By default, authentication is enabled, but each of the individual authentication +methods is disabled. It can be disabled by setting the root `enabled` to `false`. +This will completely remove any authentication-related components from being +installed on the cluster. + +```yaml +authentication: + enabled: true +``` + +## Authentication methods + +To learn more, refer to the documentation on specific authentication methods: + +- [OpenID Connect (OIDC)](OIDC.md) +- [Security Assertion Markup Language (SAML)](SAML.md) +- [Lightweight Directory Access Protocol (LDAP)](LDAP.md) From d6844a225db235dfa3ac6aade9757226b69a44eb Mon Sep 17 00:00:00 2001 From: mdziadosz Date: Mon, 3 Jun 2024 14:25:45 +0200 Subject: [PATCH 02/12] Fixes after PR review --- content/docs/reference/authentication/LDAP.md | 51 ++++++++++--------- content/docs/reference/authentication/OIDC.md | 29 ++++++----- content/docs/reference/authentication/SAML.md | 37 +++++++------- 3 files changed, 63 insertions(+), 54 deletions(-) diff --git a/content/docs/reference/authentication/LDAP.md b/content/docs/reference/authentication/LDAP.md index 8d3ba7c1..e9ab1fdc 100644 --- a/content/docs/reference/authentication/LDAP.md +++ b/content/docs/reference/authentication/LDAP.md @@ -9,27 +9,6 @@ the interactions with your LDAP server. For more details, refer to [LDAP configuration](https://dexidp.io/docs/connectors/ldap/#configuration) in the official Dex documentation. -An example configuration for LDAP: - -```yaml -authentication: - enabled: true - ldap: - enabled: true - host: ldap.example.org:389 - insecureNoSSL: true - bindDN: cn=admin,dc=example,dc=org - bindPW: admin - usernamePrompt: Email Address - userSearch: - baseDN: ou=People,dc=example,dc=org - filter: "(objectClass=person)" - username: mail - idAttr: DN - emailAttr: mail - nameAttr: cn -``` - The following table details the fields that you can configure in the `authentication.ldap` section of the MKE 4 config: @@ -54,12 +33,36 @@ The following table details the fields that you can configure in the | `groupSearch.userMatchers` | A list of field pairs that are used to match a user to a group. | | `groupSearch.nameAttr` | A group name. | +An example configuration for LDAP: + +```yaml +authentication: + enabled: true + ldap: + enabled: true + host: ldap.example.org:389 + insecureNoSSL: true + bindDN: cn=admin,dc=example,dc=org + bindPW: admin + usernamePrompt: Email Address + userSearch: + baseDN: ou=People,dc=example,dc=org + filter: "(objectClass=person)" + username: mail + idAttr: DN + emailAttr: mail + nameAttr: cn +``` + ## Authentication flow -!!! tip "Testing" +--- +***Testing tip*** + +Ports `5556` (dex) and `5555` (example-app) need to be available externally +to test the authentication flow. - Ports `5556` (dex) and `5555` (example-app) need to be available externally - to test the authentication flow. +--- In the browser, perform the following steps to test the authentication flow: diff --git a/content/docs/reference/authentication/OIDC.md b/content/docs/reference/authentication/OIDC.md index 5c6002af..71626afb 100644 --- a/content/docs/reference/authentication/OIDC.md +++ b/content/docs/reference/authentication/OIDC.md @@ -8,6 +8,16 @@ The remaining fields in the `authentication.oidc` section are used to configure the OIDC provider. Refer to [Configure Okta](#configure-okta) for instructions on how to obtain the field values. +The following table details the fields that you can configure in the +`authentication.oidc` section of the MKE 4 config: + +| Field | Description | +|----------------|----------------------------------------------------------------------------| +| `issuer` | The root URL of the OIDC provider. | +| `clientID` | The ID from the IdP's application configuration. | +| `clientSecret` | The secret from the IdP's application configuration. | +| `redirect URI` | The URI that the provider will be returning successful authentications to. | + An example configuration for OIDC: ```yaml @@ -21,16 +31,6 @@ authentication: redirectURI: http://dex.example.com:32000/callback ``` -The following table details the fields that you can configure in the -`authentication.oidc` section of the MKE 4 config: - -| Field | Description | -|----------------|----------------------------------------------------------------------------| -| `issuer` | The root URL of the OIDC provider. | -| `clientID` | The ID from the IdP's application configuration. | -| `clientSecret` | The secret from the IdP's application configuration. | -| `redirect URI` | The URI that the provider will be returning successful authentications to. | - ## Configure Okta Create a new application in Okta and use the following settings: @@ -51,10 +51,13 @@ file and wait for the cluster to be ready. ## Authentication flow -!!! tip "Testing" +--- +***Testing tip*** + +Ports `5556` (dex) and `5555` (example-app) need to be available +externally to test the authentication flow. - Ports `5556` (dex) and `5555` (example-app) need to be available - externally to test the authentication flow. +--- In the browser, perform the following steps to test the authentication flow: diff --git a/content/docs/reference/authentication/SAML.md b/content/docs/reference/authentication/SAML.md index 63acaef9..cfe52f9c 100644 --- a/content/docs/reference/authentication/SAML.md +++ b/content/docs/reference/authentication/SAML.md @@ -10,20 +10,6 @@ instructions on how to obtain the field values. For more details, see [Authentication through SAML 2.0](https://dexidp.io/docs/connectors/saml/) in the official Dex documentation. -An example configuration for SAML: - -```yaml -authentication: - enabled: true - saml: - enabled: true - ssoURL: https://dev64105006.okta.com/app/dev64105006_mke4saml_1/epkdtszgindywD6mF5s7/sso/saml - redirectURI: http://{MKE host}:5556/callback - localCa: /etc/ssl/okta.cert - usernameAttr: name - emailAttr: email -``` - The following table details the fields that you can configure in the `authentication.saml` section of the MKE 4 config: @@ -45,6 +31,20 @@ The following table details the fields that you can configure in the | `groupsDelim` | Optional. If groups are assumed to be represented as a single attribute, this delimiter is used to split the attribute's value into multiple groups. | | `nameIDPolicyFormat` | Requested format of the name ID. | +An example configuration for SAML: + +```yaml +authentication: + enabled: true + saml: + enabled: true + ssoURL: https://dev64105006.okta.com/app/dev64105006_mke4saml_1/epkdtszgindywD6mF5s7/sso/saml + redirectURI: http://{MKE host}:5556/callback + localCa: /etc/ssl/okta.cert + usernameAttr: name + emailAttr: email +``` + ## Configure Okta Create a new application in Okta and use the following settings: @@ -79,10 +79,13 @@ configuration file and wait for the cluster to be ready. ## Authentication flow -!!! tip "Testing" +--- +***Testing tip*** + +Ports `5556` (dex) and `5555` (example-app) need to be available externally +to test the authentication flow. - Ports `5556` (dex) and `5555` (example-app) need to be available externally - to test the authentication flow. +--- In the browser, perform the following steps to test the authentication flow: From 63336f57257e27e23dfff9a55c7bb1ce1e2d43e8 Mon Sep 17 00:00:00 2001 From: mdziadosz Date: Mon, 3 Jun 2024 14:29:50 +0200 Subject: [PATCH 03/12] Fixes after PR review --- content/releases/README.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/releases/README.md b/content/releases/README.md index a1daeebc..7465e23b 100644 --- a/content/releases/README.md +++ b/content/releases/README.md @@ -31,7 +31,7 @@ This table summarizes MKE 4 features, their status, and links to guides | Licensing | | | | Load Balancing | | | | Logging, Monitoring and Alerting | alpha.1 | MVP | -| [Networking (CNI)](../docs/concepts/architecture/README.md#CNI) | alpha.1 | MVP | +| [Networking (CNI)](../docs/concepts/architecture/architecture.md#container-network-interface-cni) | alpha.1 | MVP | | Node Feature Discovery | | | | Offline Bundle | | | | OpsCare | | | @@ -42,4 +42,4 @@ This table summarizes MKE 4 features, their status, and links to guides | TLS | | | | 2FA | | | | Web UI | alpha 2 | | -| Windows | | | +| Windows | | | \ No newline at end of file From 06e828a68d5240158eafb6b4794d7eba9159a511 Mon Sep 17 00:00:00 2001 From: mdziadosz Date: Mon, 3 Jun 2024 14:33:18 +0200 Subject: [PATCH 04/12] Fixes after PR review --- content/releases/README.md | 60 +++++++++++++++++++------------------- 1 file changed, 30 insertions(+), 30 deletions(-) diff --git a/content/releases/README.md b/content/releases/README.md index 7465e23b..41a0f95d 100644 --- a/content/releases/README.md +++ b/content/releases/README.md @@ -13,33 +13,33 @@ ### Features This table summarizes MKE 4 features, their status, and links to guides -| Feature | Pre-Release | Status | -|------------------------------------------------------------------|-------|----------| -| Authentication | alpha.1| MVP | -| Authorization | alpha.1 | MVP | -| [Backup & Restore](../docs/reference/backuprestore/README.md) | alpha.1 | MVP | -| CIS Benchmark | | | -| CLI | | | -| Cloud Providers | | | -| CoreDNS | | | -| cAdvisor | | | -| gMSA | | | -| GPU Feature Discovery | | | -| [Ingress](../docs/reference/ingress/README.md) | alpha.1| MVP | | -| [Kubernetes](../docs/concepts/architecture/README.md#Components) | alpha.1 | MVP 1.29 | | -| Life Cycle Management | | | -| Licensing | | | -| Load Balancing | | | -| Logging, Monitoring and Alerting | alpha.1 | MVP | -| [Networking (CNI)](../docs/concepts/architecture/architecture.md#container-network-interface-cni) | alpha.1 | MVP | -| Node Feature Discovery | | | -| Offline Bundle | | | -| OpsCare | | | -| Policy Controller | | | -| Storage (CSI) | | | -| Support Dump | | | -| Telemetry | | | -| TLS | | | -| 2FA | | | -| Web UI | alpha 2 | | -| Windows | | | \ No newline at end of file +| Feature | Pre-Release | Status | +|------------------------------------------------------------------------|-------|----------| +| Authentication | alpha.1| MVP | +| Authorization | alpha.1 | MVP | +| [Backup & Restore](../docs/reference/backuprestore/README.md) | alpha.1 | MVP | +| CIS Benchmark | | | +| CLI | | | +| Cloud Providers | | | +| CoreDNS | | | +| cAdvisor | | | +| gMSA | | | +| GPU Feature Discovery | | | +| [Ingress](../docs/reference/ingress/README.md) | alpha.1| MVP | | +| [Kubernetes](../docs/concepts/architecture/architecture.md#components) | alpha.1 | MVP 1.29 | | +| Life Cycle Management | | | +| Licensing | | | +| Load Balancing | | | +| Logging, Monitoring and Alerting | alpha.1 | MVP | +| [Networking (CNI)](../docs/concepts/architecture/README.md#CNI) | alpha.1 | MVP | +| Node Feature Discovery | | | +| Offline Bundle | | | +| OpsCare | | | +| Policy Controller | | | +| Storage (CSI) | | | +| Support Dump | | | +| Telemetry | | | +| TLS | | | +| 2FA | | | +| Web UI | alpha 2 | | +| Windows | | | \ No newline at end of file From 7d2f222bfb8183416be946920a3b05b451c359ae Mon Sep 17 00:00:00 2001 From: mdziadosz Date: Mon, 3 Jun 2024 14:39:02 +0200 Subject: [PATCH 05/12] Fixes after PR review --- content/releases/README.md | 58 +++++++++++++++++++------------------- 1 file changed, 29 insertions(+), 29 deletions(-) diff --git a/content/releases/README.md b/content/releases/README.md index 41a0f95d..a1daeebc 100644 --- a/content/releases/README.md +++ b/content/releases/README.md @@ -13,33 +13,33 @@ ### Features This table summarizes MKE 4 features, their status, and links to guides -| Feature | Pre-Release | Status | -|------------------------------------------------------------------------|-------|----------| -| Authentication | alpha.1| MVP | -| Authorization | alpha.1 | MVP | -| [Backup & Restore](../docs/reference/backuprestore/README.md) | alpha.1 | MVP | -| CIS Benchmark | | | -| CLI | | | -| Cloud Providers | | | -| CoreDNS | | | -| cAdvisor | | | -| gMSA | | | -| GPU Feature Discovery | | | -| [Ingress](../docs/reference/ingress/README.md) | alpha.1| MVP | | -| [Kubernetes](../docs/concepts/architecture/architecture.md#components) | alpha.1 | MVP 1.29 | | -| Life Cycle Management | | | -| Licensing | | | -| Load Balancing | | | -| Logging, Monitoring and Alerting | alpha.1 | MVP | +| Feature | Pre-Release | Status | +|------------------------------------------------------------------|-------|----------| +| Authentication | alpha.1| MVP | +| Authorization | alpha.1 | MVP | +| [Backup & Restore](../docs/reference/backuprestore/README.md) | alpha.1 | MVP | +| CIS Benchmark | | | +| CLI | | | +| Cloud Providers | | | +| CoreDNS | | | +| cAdvisor | | | +| gMSA | | | +| GPU Feature Discovery | | | +| [Ingress](../docs/reference/ingress/README.md) | alpha.1| MVP | | +| [Kubernetes](../docs/concepts/architecture/README.md#Components) | alpha.1 | MVP 1.29 | | +| Life Cycle Management | | | +| Licensing | | | +| Load Balancing | | | +| Logging, Monitoring and Alerting | alpha.1 | MVP | | [Networking (CNI)](../docs/concepts/architecture/README.md#CNI) | alpha.1 | MVP | -| Node Feature Discovery | | | -| Offline Bundle | | | -| OpsCare | | | -| Policy Controller | | | -| Storage (CSI) | | | -| Support Dump | | | -| Telemetry | | | -| TLS | | | -| 2FA | | | -| Web UI | alpha 2 | | -| Windows | | | \ No newline at end of file +| Node Feature Discovery | | | +| Offline Bundle | | | +| OpsCare | | | +| Policy Controller | | | +| Storage (CSI) | | | +| Support Dump | | | +| Telemetry | | | +| TLS | | | +| 2FA | | | +| Web UI | alpha 2 | | +| Windows | | | From e849e80ba76feee4332c691fb0c7b235b47b5b72 Mon Sep 17 00:00:00 2001 From: mdziadosz Date: Fri, 7 Jun 2024 08:58:04 +0200 Subject: [PATCH 06/12] Fixes after review --- content/docs/reference/authentication/authentication.md | 3 +++ 1 file changed, 3 insertions(+) diff --git a/content/docs/reference/authentication/authentication.md b/content/docs/reference/authentication/authentication.md index 7fd67dc8..44f4259c 100644 --- a/content/docs/reference/authentication/authentication.md +++ b/content/docs/reference/authentication/authentication.md @@ -9,6 +9,9 @@ the authentication in the MKE 4 configuration file and add your own method. Changing the authentication method will require you to configure authentication completely by yourself. +For more information on authentication feature status in the release, go to +[MKE 4 releases](https://github.com/Mirantis/mke-docs/blob/main/content/releases/README.md). + ## Prerequisites - Identity Provider (IdP) - To set OIDC or SAML you need to configure an IdP with an application. From 66cc24bd1cd7ee5f3c16a7981c26de0ebb58b375 Mon Sep 17 00:00:00 2001 From: mdziadosz Date: Fri, 7 Jun 2024 09:01:17 +0200 Subject: [PATCH 07/12] Fixes after review --- content/docs/reference/authentication/authentication.md | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/content/docs/reference/authentication/authentication.md b/content/docs/reference/authentication/authentication.md index 44f4259c..87bd0d9e 100644 --- a/content/docs/reference/authentication/authentication.md +++ b/content/docs/reference/authentication/authentication.md @@ -4,10 +4,13 @@ Mirantis Kubernetes Engine (MKE) 4 uses Dex for authentication. If you choose to use a different authentication method, you can disable the authentication in the MKE 4 configuration file and add your own method. -!!! caution "Changing authentication method" +--- +***Caution: Changing authentication method*** - Changing the authentication method will require you to configure - authentication completely by yourself. +Changing the authentication method will require you to configure +authentication completely by yourself. + +--- For more information on authentication feature status in the release, go to [MKE 4 releases](https://github.com/Mirantis/mke-docs/blob/main/content/releases/README.md). From d99665fc4209b86a38f3302c57806a5c8bd5f494 Mon Sep 17 00:00:00 2001 From: Magdalena Dziadosz <160592158+MagdaDziadosz@users.noreply.github.com> Date: Tue, 11 Jun 2024 10:03:17 +0200 Subject: [PATCH 08/12] Apply suggestions from code review Co-authored-by: Kory <57411706+KoryKessel-Mirantis@users.noreply.github.com> --- content/docs/reference/authentication/LDAP.md | 40 +++++++-------- content/docs/reference/authentication/OIDC.md | 37 +++++++------- content/docs/reference/authentication/SAML.md | 50 +++++++++---------- .../authentication/authentication.md | 18 +++---- 4 files changed, 73 insertions(+), 72 deletions(-) diff --git a/content/docs/reference/authentication/LDAP.md b/content/docs/reference/authentication/LDAP.md index e9ab1fdc..d330c414 100644 --- a/content/docs/reference/authentication/LDAP.md +++ b/content/docs/reference/authentication/LDAP.md @@ -14,26 +14,26 @@ The following table details the fields that you can configure in the | Field | Description | |------------------------------------|----------------------------------------------------------------------------| -| `host` | Host and optional port of the LDAP server in the `host:port` format. | +| `host` | Host and optional port of the LDAP server, in the `host:port` format. | | `rootCA` | Path to a trusted root certificate file. | -| `bindDN` | The DN for an application service account. | -| `bindPW` | The password for an application service account. | -| `usernamePrompt` | The attribute to display in the provided password prompt. | -| `userSearch` | Settings to map a username and password entered by a user to a LDAP entry. | -| `userSearch.baseDN` | BaseDN to start the search from. | -| `userSearch.filter` | Optional filter to apply when searching the directory. | -| `userSearch.username` | Username attribute used for comparing user entries. | +| `bindDN` | Distinguished Name (DN) for an application service account. | +| `bindPW` | Password for an application service account. | +| `usernamePrompt` | Attribute to display in the password prompt. | +| `userSearch` | Settings to map user-entered username and password to an LDAP entry. | +| `userSearch.baseDN` | BaseDN from which to start the search. | +| `userSearch.filter` | Optional filter to apply for a user search of the directory. | +| `userSearch.username` | Username attribute to use for user entry comparison. | | `userSearch.idAttr` | String representation of the user. | | `userSearch.emailAttr` | Attribute to map to email. | -| `userSearch.nameAttr` | Maps to display name of a user. | -| `userSearch.preferredUsernameAttr` | Maps to preferred usernames of users. | +| `userSearch.nameAttr` | Attribute to map to display name of a user. | +| `userSearch.preferredUsernameAttr` | Attribute to map to preferred usernames. | | `groupSearch` | Group search queries for groups given a user entry. | -| `groupSearch.baseDN` | BaseDN to start the search from. | -| `groupSearch.filter` | Optional filter to apply when searching the directory. | -| `groupSearch.userMatchers` | A list of field pairs that are used to match a user to a group. | -| `groupSearch.nameAttr` | A group name. | +| `groupSearch.baseDN` | BaseDN from which to start the search. | +| `groupSearch.filter` | Optional filter to apply for a group search of the directory. | +| `groupSearch.userMatchers` | Field pairs list to use to match a user to a group. | +| `groupSearch.nameAttr` | Group name. | -An example configuration for LDAP: +LDAP example configuration: ```yaml authentication: @@ -54,10 +54,10 @@ authentication: nameAttr: cn ``` -## Authentication flow +**To test the Authentication flow:** --- -***Testing tip*** +***Note*** Ports `5556` (dex) and `5555` (example-app) need to be available externally to test the authentication flow. @@ -67,8 +67,8 @@ to test the authentication flow. In the browser, perform the following steps to test the authentication flow: 1. Navigate to `http://{MKE hostname}:5555/login`. -2. Click **Login**. -3. On the login page, select **Log in with LDAP**. +2. Click **Login** to display the login page. +3. Select **Log in with LDAP**. 4. Enter the username and password for the LDAP server. -5. Click **Login**. +5. Click **Login**. If authentication is successful, you will be redirected to the client applications home page. 6. Successful authentication will redirect you back to the client applications home page. diff --git a/content/docs/reference/authentication/OIDC.md b/content/docs/reference/authentication/OIDC.md index 71626afb..cf602072 100644 --- a/content/docs/reference/authentication/OIDC.md +++ b/content/docs/reference/authentication/OIDC.md @@ -13,12 +13,12 @@ The following table details the fields that you can configure in the | Field | Description | |----------------|----------------------------------------------------------------------------| -| `issuer` | The root URL of the OIDC provider. | -| `clientID` | The ID from the IdP's application configuration. | -| `clientSecret` | The secret from the IdP's application configuration. | -| `redirect URI` | The URI that the provider will be returning successful authentications to. | +| `issuer` | OIDC provider root URL. | +| `clientID` | ID from the IdP application configuration. | +| `clientSecret` | Secret from the IdP application configuration. | +| `redirect URI` | URI to which the provider will return successful authentications. | -An example configuration for OIDC: +OIDC example configuration: ```yaml authentication: @@ -31,17 +31,19 @@ authentication: redirectURI: http://dex.example.com:32000/callback ``` -## Configure Okta +**To create a new application in Okta:** Create a new application in Okta and use the following settings: -1. Select **OIDC - OpenID Connect** as the sign-in method. -2. Select **Web Application** as the application type. -3. Choose an app integration name that you can easily remember. -4. The host for your redirect URLs: +1. Select **OIDC - OpenID Connect** for **Sign-in method**. +2. Select **Web Application** for **Application Type**. +3. For **App integration name**, choose a name that you can easily remember. +4. Configure the host for your redirect URLs: - Sign-in redirect URIs: `http://{MKE hostname}/login` - Sign-out redirect URIs: `http://{MKE hostname}` -5. Click **Save**. +5. Click **Save** to generates the `clientSecret` and `clientID` in the `General` table of +the application. +6. Add the generated `clientSecret` and `clientID` values to your MKE configuration file. Okta will generate the `clientSecret` and `clientID` on the `General` table of the application. Add the generated values to your MKE 4 config. @@ -49,20 +51,19 @@ the application. Add the generated values to your MKE 4 config. Once the configuration is set, run the `mkectl apply` command with your config file and wait for the cluster to be ready. -## Authentication flow +**To test the Authentication flow:** --- -***Testing tip*** +***Note*** -Ports `5556` (dex) and `5555` (example-app) need to be available -externally to test the authentication flow. +"To test authentication flow, ports `5556` (dex) and `5555` (example-app) must be externally available. --- In the browser, perform the following steps to test the authentication flow: 1. Navigate to `http://{MKE hostname}:5555/login` -2. Click **Login**. -3. On the login page, select **Log in with OIDC**. -4. You will be redirected to the IdP's login page. Enter your credentials and click **Sign In**. +2. Click **Login** to display the login page. +3. Select **Log in with OIDC**. +4. Enter your credentials and click **Sign In**. If authentication is successful, you will be redirected to the client applications home page. 5. Successful authentication will redirect you back to the client applications home page. diff --git a/content/docs/reference/authentication/SAML.md b/content/docs/reference/authentication/SAML.md index cfe52f9c..a8d5d96f 100644 --- a/content/docs/reference/authentication/SAML.md +++ b/content/docs/reference/authentication/SAML.md @@ -16,20 +16,20 @@ The following table details the fields that you can configure in the | Field | Description | |-----------------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------| | `enabled` | Enable authentication through dex. | -| `ssoMetadataURL` | The metadata URL provided by some IdPs. MKE can use this to retrieve information for all other SAML configuration automatically. | -| `ca` | Alternative to `caData` and `localCa`. CA to use when validating the signature of the SAML response. This must be manually mounted in a local accessible by dex. | -| `caData` | Alternative to `ca` and `localCa`. Place the cert data directly in the config file. | -| `localCa` | Alternative to `ca` and `caData`. A path to a CA file in the local system. MKE will mount and create a secret for the cert. | -| `ssoURL` | The URL to send users to when signing in with SAML. Provided by the IdP. | -| `redirectURI` | Dex callback URL. Where users will be returned to after successful authentication with the IdP. | -| `insecureSkipSignatureValidation` | Optional. Skip the signature validation. To be used for testing purposes only. | -| `usernameAttr` | A username attribute in the returned assertions to map to ID token claims. | -| `emailAttr` | An email attribute in the returned assertions to map to ID token claims. | -| `groupsAttr` | Optional. A groups attribute in the returned assertions to map to ID token claims. | -| `entityIssuer` | Optional. Include this as the Issuer value during authentication request. | -| `ssoIssuer` | Optional. Issuer value expected in the SAML response. | -| `groupsDelim` | Optional. If groups are assumed to be represented as a single attribute, this delimiter is used to split the attribute's value into multiple groups. | -| `nameIDPolicyFormat` | Requested format of the name ID. | +| `ssoMetadataURL` | Metadata URL provided by some IdPs, with which MKE can retrieve information for all other SAML configurations. | +| `ca` | Certificate Authority (CA) alternative to `caData` and `localCa`, to use when validating the signature of the SAML response. Must be manually mounted in a local accessible by dex. | +| `caData` | CA alternative to `ca` and `localCa`, which you can use to place the certificate data directly into the config file. | +| `localCa` | Alternative to `ca` and `caData`. A path to a CA file in the local system, with which MKE mounts and creates a secret for the certificate. | +| `ssoURL` | URL to provide to users to sign into MKE 4 with SAML. Provided by the IdP. | +| `redirectURI` | Callback URL for dex to which users are returned to following successful IdP authentication. | +| `insecureSkipSignatureValidation` | Optional. Use to skip the signature validation. For testing purposes only. | +| `usernameAttr` | Username attribute in the returned assertions, to map to ID token claims. | +| `emailAttr` | Email attribute in the returned assertions, to map to ID token claims. | +| `groupsAttr` | Optional. Groups attribute in the returned assertions, to map to ID token claims. | +| `entityIssuer` | Optional. Include as the Issuer value during authentication requests. | +| `ssoIssuer` | Optional. Issuer value that is expected in the SAML response. | +| `groupsDelim` | Optional. If groups are assumed to be represented as a single attribute, this delimiter splits the attribute value into multiple groups. | +| `nameIDPolicyFormat` | Requested name ID format. | An example configuration for SAML: @@ -45,13 +45,13 @@ authentication: emailAttr: email ``` -## Configure Okta +**To configure and create a new application in Okta: Create a new application in Okta and use the following settings: -1. Select **SAML 2.0** as the **Sign-in method**. -2. Choose an app integration name that you can easily remember. -3. The host for your redirect URLs: +1. Select **SAML 2.0** for **Sign-in method**. +2. For **App name**, choose a name that you can easily remember. +3. Configure the host for your redirect URLs: - Single sign-on URL: `http://{MKE hostname}/callback` - Audience URI (SP Entity ID): `http://{MKE hostname}/callback` - Attribute statements: @@ -65,22 +65,22 @@ Create a new application in Okta and use the following settings: a. Click **Assign** -> **Assign to people**. - b. Find the account you would like to use for authentication and click the blue **Assign** button on the right. + b. Click the blue **Assign** button that corresponds to the account you want to use for authentication. Okta will generate the `ssoURL` and cert under the `Sign On` tab. The `ssoURL` will be the MetadataURL with the final metadata removed from the path. The cert can be downloaded from the SAML **Signing Certificates** section. Click **Actions** on the active cert and download the cert. -Configure the `localCa` to point to this file on your system that you will run `mkectl` from. +8. Configure the `localCa` to point to the downloaded certificate file. The cert in the example above is stored in `/etc/ssl/okta.cert`. Once the configuration is set, run the `mkectl apply` command with your configuration file and wait for the cluster to be ready. -## Authentication flow +**To test the Authentication flow:** --- -***Testing tip*** +***Note*** Ports `5556` (dex) and `5555` (example-app) need to be available externally to test the authentication flow. @@ -90,7 +90,7 @@ to test the authentication flow. In the browser, perform the following steps to test the authentication flow: 1. Navigate to `http://{MKE hostname}:5555/login`. -2. Click **Login**. -3. On the login page, select **Log in with SAML**. -4. You will be redirected to the IdP's login page. Enter your credentials and click **Sign In**. +2. Click **Login** to display the login page. +3. Select **Log in with SAML**. +4. Enter your credentials and click **Sign In**. If authentication is successful, you will be redirected to the client applications home page. 5. Successful authentication will redirect you back to the client applications home page. diff --git a/content/docs/reference/authentication/authentication.md b/content/docs/reference/authentication/authentication.md index 87bd0d9e..a4dd5914 100644 --- a/content/docs/reference/authentication/authentication.md +++ b/content/docs/reference/authentication/authentication.md @@ -1,24 +1,24 @@ # Authentication Mirantis Kubernetes Engine (MKE) 4 uses Dex for authentication. -If you choose to use a different authentication method, you can disable -the authentication in the MKE 4 configuration file and add your own method. +If you want to use a different authentication method, disable +the authentication in the MKE configuration file and add your preferred method. --- -***Caution: Changing authentication method*** +***CAUTION*** Changing the authentication method will require you to configure authentication completely by yourself. --- -For more information on authentication feature status in the release, go to +For more information on authentication feature status per release, go to [MKE 4 releases](https://github.com/Mirantis/mke-docs/blob/main/content/releases/README.md). ## Prerequisites - Identity Provider (IdP) - To set OIDC or SAML you need to configure an IdP with an application. -Refer to [Add a SAML Identity Provider](https://help.okta.com/en-us/content/topics/security/idp-add-saml.htm) +Refer to the official Okta documentation tutorial [Add a SAML Identity Provider](https://help.okta.com/en-us/content/topics/security/idp-add-saml.htm). tutorial from the official Okta documentation. - LDAP Server - To set LDAP you need to configure an LDAP server with a user. @@ -37,8 +37,8 @@ authentication: ## Authentication methods -To learn more, refer to the documentation on specific authentication methods: +Documentation for specific authentication methods as they apply to MKE 4 is available: -- [OpenID Connect (OIDC)](OIDC.md) -- [Security Assertion Markup Language (SAML)](SAML.md) -- [Lightweight Directory Access Protocol (LDAP)](LDAP.md) +- [OIDC (OpenID Connect)](OIDC.md) +- [SAML (Security Assertion Markup Language)](SAML.md) +- [LDAP (Lightweight Directory Access Protocol)](LDAP.md) From cff808d83606120184a52cccec6148624268e536 Mon Sep 17 00:00:00 2001 From: mdziadosz Date: Tue, 11 Jun 2024 12:23:02 +0200 Subject: [PATCH 09/12] Fixes after review --- content/docs/reference/authentication/LDAP.md | 62 +++++++------- content/docs/reference/authentication/OIDC.md | 40 ++++----- content/docs/reference/authentication/SAML.md | 84 +++++++++---------- .../authentication/authentication.md | 28 ++++--- 4 files changed, 99 insertions(+), 115 deletions(-) diff --git a/content/docs/reference/authentication/LDAP.md b/content/docs/reference/authentication/LDAP.md index d330c414..0c703548 100644 --- a/content/docs/reference/authentication/LDAP.md +++ b/content/docs/reference/authentication/LDAP.md @@ -1,37 +1,35 @@ # LDAP -LDAP (Lightweight Directory Access Protocol) can be configured in -the `authentication` section of the Mirantis Kubernetes Engine (MKE) 4 config. -LDAP is disabled by default, to enable it set `enabled` to `true`. - +You can configure LDAP (Lightweight Directory Access Protocol) for MKE 4 +through the `authentication` section of the MKE configuration file. +To enable the service, set `enabled` to `true`. The remaining fields in the `authentication.ldap` section are used to configure -the interactions with your LDAP server. For more details, refer to -[LDAP configuration](https://dexidp.io/docs/connectors/ldap/#configuration) -in the official Dex documentation. +the interactions with your LDAP server. +For more information, refer to the official DEX documentation +[LDAP configuration](https://dexidp.io/docs/connectors/ldap/#configuration). -The following table details the fields that you can configure in the -`authentication.ldap` section of the MKE 4 config: +The MKE configuration file `authentication.ldap` fields are detailed below: -| Field | Description | -|------------------------------------|----------------------------------------------------------------------------| -| `host` | Host and optional port of the LDAP server, in the `host:port` format. | -| `rootCA` | Path to a trusted root certificate file. | -| `bindDN` | Distinguished Name (DN) for an application service account. | -| `bindPW` | Password for an application service account. | -| `usernamePrompt` | Attribute to display in the password prompt. | -| `userSearch` | Settings to map user-entered username and password to an LDAP entry. | -| `userSearch.baseDN` | BaseDN from which to start the search. | -| `userSearch.filter` | Optional filter to apply for a user search of the directory. | -| `userSearch.username` | Username attribute to use for user entry comparison. | -| `userSearch.idAttr` | String representation of the user. | -| `userSearch.emailAttr` | Attribute to map to email. | -| `userSearch.nameAttr` | Attribute to map to display name of a user. | -| `userSearch.preferredUsernameAttr` | Attribute to map to preferred usernames. | -| `groupSearch` | Group search queries for groups given a user entry. | -| `groupSearch.baseDN` | BaseDN from which to start the search. | -| `groupSearch.filter` | Optional filter to apply for a group search of the directory. | -| `groupSearch.userMatchers` | Field pairs list to use to match a user to a group. | -| `groupSearch.nameAttr` | Group name. | +| Field | Description | +|------------------------------------|-----------------------------------------------------------------------| +| `host` | Host and optional port of the LDAP server, in the `host:port` format. | +| `rootCA` | Path to a trusted root certificate file. | +| `bindDN` | Distinguished Name (DN) for an application service account. | +| `bindPW` | Password for an application service account. | +| `usernamePrompt` | Attribute to display in the password prompt. | +| `userSearch` | Settings to map user-entered username and password to an LDAP entry. | +| `userSearch.baseDN` | BaseDN from which to start the search. | +| `userSearch.filter` | Optional filter to apply for a user search of the directory. | +| `userSearch.username` | Username attribute to use for user entry comparison. | +| `userSearch.idAttr` | String representation of the user. | +| `userSearch.emailAttr` | Attribute to map to email. | +| `userSearch.nameAttr` | Attribute to map to display name of a user. | +| `userSearch.preferredUsernameAttr` | Attribute to map to preferred usernames. | +| `groupSearch` | Group search queries for groups given a user entry. | +| `groupSearch.baseDN` | BaseDN from which to start the search. | +| `groupSearch.filter` | Optional filter to apply for a group search of the directory. | +| `groupSearch.userMatchers` | Field pairs list to use to match a user to a group. | +| `groupSearch.nameAttr` | Group name. | LDAP example configuration: @@ -59,16 +57,12 @@ authentication: --- ***Note*** -Ports `5556` (dex) and `5555` (example-app) need to be available externally -to test the authentication flow. +To test authentication flow, ports `5556` (dex) and `5555` (example-app) must be externally available. --- -In the browser, perform the following steps to test the authentication flow: - 1. Navigate to `http://{MKE hostname}:5555/login`. 2. Click **Login** to display the login page. 3. Select **Log in with LDAP**. 4. Enter the username and password for the LDAP server. 5. Click **Login**. If authentication is successful, you will be redirected to the client applications home page. -6. Successful authentication will redirect you back to the client applications home page. diff --git a/content/docs/reference/authentication/OIDC.md b/content/docs/reference/authentication/OIDC.md index cf602072..c448247a 100644 --- a/content/docs/reference/authentication/OIDC.md +++ b/content/docs/reference/authentication/OIDC.md @@ -1,21 +1,18 @@ # OIDC -OpenID Connect (OIDC) can be configured in the `authentication` section of -the Mirantis Kubernetes Engine (MKE) 4 config. -OIDC is disabled by default, to enable it set `enabled` to `true`. - +You can configure OIDC (OpenID Connect) for MKE 4 through the `authentication` section of the MKE configuration file. To enable the service, set 'enabled' to 'true' The remaining fields in the `authentication.oidc` section are used to configure -the OIDC provider. Refer to [Configure Okta](#configure-okta) for -instructions on how to obtain the field values. +the OIDC provider. +For information on how to obtain the field values, refer to +**Create a new application in Okta** section of this document. -The following table details the fields that you can configure in the -`authentication.oidc` section of the MKE 4 config: +The MKE configuration file `authentication.oidc` fields are detailed below: -| Field | Description | -|----------------|----------------------------------------------------------------------------| -| `issuer` | OIDC provider root URL. | -| `clientID` | ID from the IdP application configuration. | -| `clientSecret` | Secret from the IdP application configuration. | +| Field | Description | +|----------------|-------------------------------------------------------------------| +| `issuer` | OIDC provider root URL. | +| `clientID` | ID from the IdP application configuration. | +| `clientSecret` | Secret from the IdP application configuration. | | `redirect URI` | URI to which the provider will return successful authentications. | OIDC example configuration: @@ -33,8 +30,6 @@ authentication: **To create a new application in Okta:** -Create a new application in Okta and use the following settings: - 1. Select **OIDC - OpenID Connect** for **Sign-in method**. 2. Select **Web Application** for **Application Type**. 3. For **App integration name**, choose a name that you can easily remember. @@ -44,26 +39,19 @@ Create a new application in Okta and use the following settings: 5. Click **Save** to generates the `clientSecret` and `clientID` in the `General` table of the application. 6. Add the generated `clientSecret` and `clientID` values to your MKE configuration file. - -Okta will generate the `clientSecret` and `clientID` on the `General` table of -the application. Add the generated values to your MKE 4 config. - -Once the configuration is set, run the `mkectl apply` command with your config -file and wait for the cluster to be ready. +7. Run the `mkectl apply` command with your MKE configuration file. **To test the Authentication flow:** --- ***Note*** -"To test authentication flow, ports `5556` (dex) and `5555` (example-app) must be externally available. +To test authentication flow, ports `5556` (dex) and `5555` (example-app) must be externally available. --- -In the browser, perform the following steps to test the authentication flow: - 1. Navigate to `http://{MKE hostname}:5555/login` 2. Click **Login** to display the login page. 3. Select **Log in with OIDC**. -4. Enter your credentials and click **Sign In**. If authentication is successful, you will be redirected to the client applications home page. -5. Successful authentication will redirect you back to the client applications home page. +4. Enter your credentials and click **Sign In**. If authentication is successful, +you will be redirected to the client applications home page. diff --git a/content/docs/reference/authentication/SAML.md b/content/docs/reference/authentication/SAML.md index a8d5d96f..32799a43 100644 --- a/content/docs/reference/authentication/SAML.md +++ b/content/docs/reference/authentication/SAML.md @@ -1,35 +1,34 @@ # SAML -Security Assertion Markup Language (SAML) can be configured in -the `authentication` section of the Mirantis Kubernetes Engine (MKE) 4 config. -SAML is disabled by default, to enable it set `enabled` to `true`. - +You can configure SAML (Security Assertion Markup Language) for MKE 4 through +the `authentication` section of the MKE configuration file. +To enable the service, set `enabled` to `true`. The remaining fields in the `authentication.saml` section are used to configure -the SAML provider. Refer to [Configure Okta](#configure-okta) for -instructions on how to obtain the field values. For more details, see -[Authentication through SAML 2.0](https://dexidp.io/docs/connectors/saml/) -in the official Dex documentation. - -The following table details the fields that you can configure in the -`authentication.saml` section of the MKE 4 config: - -| Field | Description | -|-----------------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------| -| `enabled` | Enable authentication through dex. | -| `ssoMetadataURL` | Metadata URL provided by some IdPs, with which MKE can retrieve information for all other SAML configurations. | +the SAML provider. +Refer to **Configure and create a new application in Okta** section of this document +for instructions on how to obtain the field values. +For more information, refer to the official DEX documentation +[Authentication through SAML 2.0](https://dexidp.io/docs/connectors/saml/). + +The MKE configuration file `authentication.smal` fields are detailed below: + +| Field | Description | +|-----------------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| +| `enabled` | Enable authentication through dex. | +| `ssoMetadataURL` | Metadata URL provided by some IdPs, with which MKE can retrieve information for all other SAML configurations. | | `ca` | Certificate Authority (CA) alternative to `caData` and `localCa`, to use when validating the signature of the SAML response. Must be manually mounted in a local accessible by dex. | -| `caData` | CA alternative to `ca` and `localCa`, which you can use to place the certificate data directly into the config file. | -| `localCa` | Alternative to `ca` and `caData`. A path to a CA file in the local system, with which MKE mounts and creates a secret for the certificate. | -| `ssoURL` | URL to provide to users to sign into MKE 4 with SAML. Provided by the IdP. | -| `redirectURI` | Callback URL for dex to which users are returned to following successful IdP authentication. | -| `insecureSkipSignatureValidation` | Optional. Use to skip the signature validation. For testing purposes only. | -| `usernameAttr` | Username attribute in the returned assertions, to map to ID token claims. | -| `emailAttr` | Email attribute in the returned assertions, to map to ID token claims. | -| `groupsAttr` | Optional. Groups attribute in the returned assertions, to map to ID token claims. | -| `entityIssuer` | Optional. Include as the Issuer value during authentication requests. | -| `ssoIssuer` | Optional. Issuer value that is expected in the SAML response. | -| `groupsDelim` | Optional. If groups are assumed to be represented as a single attribute, this delimiter splits the attribute value into multiple groups. | -| `nameIDPolicyFormat` | Requested name ID format. | +| `caData` | CA alternative to `ca` and `localCa`, which you can use to place the certificate data directly into the config file. | +| `localCa` | Alternative to `ca` and `caData`. A path to a CA file in the local system, with which MKE mounts and creates a secret for the certificate. | +| `ssoURL` | URL to provide to users to sign into MKE 4 with SAML. Provided by the IdP. | +| `redirectURI` | Callback URL for dex to which users are returned to following successful IdP authentication. | +| `insecureSkipSignatureValidation` | Optional. Use to skip the signature validation. For testing purposes only. | +| `usernameAttr` | Username attribute in the returned assertions, to map to ID token claims. | +| `emailAttr` | Email attribute in the returned assertions, to map to ID token claims. | +| `groupsAttr` | Optional. Groups attribute in the returned assertions, to map to ID token claims. | +| `entityIssuer` | Optional. Include as the Issuer value during authentication requests. | +| `ssoIssuer` | Optional. Issuer value that is expected in the SAML response. | +| `groupsDelim` | Optional. If groups are assumed to be represented as a single attribute, this delimiter splits the attribute value into multiple groups. | +| `nameIDPolicyFormat` | Requested name ID format. | An example configuration for SAML: @@ -47,8 +46,6 @@ authentication: **To configure and create a new application in Okta: -Create a new application in Okta and use the following settings: - 1. Select **SAML 2.0** for **Sign-in method**. 2. For **App name**, choose a name that you can easily remember. 3. Configure the host for your redirect URLs: @@ -67,30 +64,29 @@ Create a new application in Okta and use the following settings: b. Click the blue **Assign** button that corresponds to the account you want to use for authentication. -Okta will generate the `ssoURL` and cert under the `Sign On` tab. -The `ssoURL` will be the MetadataURL with the final metadata removed from the path. -The cert can be downloaded from the SAML **Signing Certificates** section. -Click **Actions** on the active cert and download the cert. -8. Configure the `localCa` to point to the downloaded certificate file. -The cert in the example above is stored in `/etc/ssl/okta.cert`. + Okta generates the `ssoURL` and certificate under the `Sign On` tab. + The `ssoURL` is the MetadataURL with the final metadata removed from the path. + +7. Download the certificate to the system from which you will run mkectl: -Once the configuration is set, run the `mkectl apply` command with your -configuration file and wait for the cluster to be ready. + a. Navigate to the SAML **Signing Certificates** section. + + b. Click **Actions** for the active certificate and initiate the download. + +8. Configure the `localCa` to point to the downloaded certificate file. +9. Run the `mkectl apply` command with your MKE configuration file. **To test the Authentication flow:** --- ***Note*** -Ports `5556` (dex) and `5555` (example-app) need to be available externally -to test the authentication flow. +To test authentication flow, ports `5556` (dex) and `5555` (example-app) must be externally available. --- -In the browser, perform the following steps to test the authentication flow: - 1. Navigate to `http://{MKE hostname}:5555/login`. 2. Click **Login** to display the login page. 3. Select **Log in with SAML**. -4. Enter your credentials and click **Sign In**. If authentication is successful, you will be redirected to the client applications home page. -5. Successful authentication will redirect you back to the client applications home page. +4. Enter your credentials and click **Sign In**. If authentication is successful, +you will be redirected to the client applications home page. diff --git a/content/docs/reference/authentication/authentication.md b/content/docs/reference/authentication/authentication.md index a4dd5914..57066c6d 100644 --- a/content/docs/reference/authentication/authentication.md +++ b/content/docs/reference/authentication/authentication.md @@ -7,8 +7,9 @@ the authentication in the MKE configuration file and add your preferred method. --- ***CAUTION*** -Changing the authentication method will require you to configure -authentication completely by yourself. +Be aware that if you opt to use an authentication method other than Dex, +you will need to undertake all tasks and responsibilities associated with +configuring and maintaining that method. --- @@ -17,18 +18,23 @@ For more information on authentication feature status per release, go to ## Prerequisites -- Identity Provider (IdP) - To set OIDC or SAML you need to configure an IdP with an application. -Refer to the official Okta documentation tutorial [Add a SAML Identity Provider](https://help.okta.com/en-us/content/topics/security/idp-add-saml.htm). -tutorial from the official Okta documentation. -- LDAP Server - To set LDAP you need to configure an LDAP server with a user. +- **Identity Provider (IdP)** + + To set OIDC or SAML you need to configure an IdP with an application. + Refer to the official Okta documentation tutorial [Add a SAML Identity Provider](https://help.okta.com/en-us/content/topics/security/idp-add-saml.htm). + +- **LDAP Server** + + To set LDAP you need to configure an LDAP server with a user. ## Configuration -Authentication can be configured in the `authentication` section of the MKE 4 config. -By default, authentication is enabled, but each of the individual authentication -methods is disabled. It can be disabled by setting the root `enabled` to `false`. -This will completely remove any authentication-related components from being -installed on the cluster. +You can configure authentication for MKE 4 through the `authentication` section +of the MKE configuration file. `authentication` is enabled by default, however +the settings for each of the individual authentication methods are disabled. +To enable a service, set its `enabled` configuration option to `true`. +Doing so will completely remove any authentication-related components from +being installed on your cluster. ```yaml authentication: From 0bae8f37f26e21e42cbd92e315b590d9eadd6943 Mon Sep 17 00:00:00 2001 From: mdziadosz Date: Thu, 13 Jun 2024 14:07:42 +0200 Subject: [PATCH 10/12] Fixes after review --- content/docs/reference/authentication/LDAP.md | 4 +- .../OIDC-providers/OIDC-OKTA-configuration.md | 13 ++++++ .../{ => OIDC-providers}/OIDC.md | 27 ++++-------- .../SAML-providers/SAML-OKTA-configuration.md | 31 ++++++++++++++ .../{ => SAML-providers}/SAML.md | 42 ++++--------------- .../authentication/authentication.md | 15 +++---- 6 files changed, 71 insertions(+), 61 deletions(-) create mode 100644 content/docs/reference/authentication/OIDC-providers/OIDC-OKTA-configuration.md rename content/docs/reference/authentication/{ => OIDC-providers}/OIDC.md (59%) create mode 100644 content/docs/reference/authentication/SAML-providers/SAML-OKTA-configuration.md rename content/docs/reference/authentication/{ => SAML-providers}/SAML.md (78%) diff --git a/content/docs/reference/authentication/LDAP.md b/content/docs/reference/authentication/LDAP.md index 0c703548..51e0d540 100644 --- a/content/docs/reference/authentication/LDAP.md +++ b/content/docs/reference/authentication/LDAP.md @@ -8,6 +8,8 @@ the interactions with your LDAP server. For more information, refer to the official DEX documentation [LDAP configuration](https://dexidp.io/docs/connectors/ldap/#configuration). +## Configure MKE + The MKE configuration file `authentication.ldap` fields are detailed below: | Field | Description | @@ -52,7 +54,7 @@ authentication: nameAttr: cn ``` -**To test the Authentication flow:** +## Test authentication flow --- ***Note*** diff --git a/content/docs/reference/authentication/OIDC-providers/OIDC-OKTA-configuration.md b/content/docs/reference/authentication/OIDC-providers/OIDC-OKTA-configuration.md new file mode 100644 index 00000000..95802dc2 --- /dev/null +++ b/content/docs/reference/authentication/OIDC-providers/OIDC-OKTA-configuration.md @@ -0,0 +1,13 @@ +# Create OIDC application in Okta + +1. Select **OIDC - OpenID Connect** for **Sign-in method**. +2. Select **Web Application** for **Application Type**. +3. For **App integration name**, choose a name that you can easily remember. +4. Configure the host for your redirect URLs: + - Sign-in redirect URIs: `http://{MKE hostname}/login` + - Sign-out redirect URIs: `http://{MKE hostname}` +5. Click **Save** to generate the `clientSecret` and `clientID` in the `General` table of +the application. +6. Add the generated `clientSecret` and `clientID` values to your MKE configuration file. +7. Run the `mkectl apply` command with your MKE configuration file. + diff --git a/content/docs/reference/authentication/OIDC.md b/content/docs/reference/authentication/OIDC-providers/OIDC.md similarity index 59% rename from content/docs/reference/authentication/OIDC.md rename to content/docs/reference/authentication/OIDC-providers/OIDC.md index c448247a..0ae8cb83 100644 --- a/content/docs/reference/authentication/OIDC.md +++ b/content/docs/reference/authentication/OIDC-providers/OIDC.md @@ -1,10 +1,14 @@ # OIDC -You can configure OIDC (OpenID Connect) for MKE 4 through the `authentication` section of the MKE configuration file. To enable the service, set 'enabled' to 'true' +You can configure OIDC (OpenID Connect) for MKE 4 through the `authentication` +section of the MKE configuration file. To enable the service, set `enabled` to `true`. The remaining fields in the `authentication.oidc` section are used to configure the OIDC provider. -For information on how to obtain the field values, refer to -**Create a new application in Okta** section of this document. +For information on how to obtain the field values, refer to your provider of choice: + +- [Okta](OIDC-OKTA-configuration.md) + +## Configure MKE The MKE configuration file `authentication.oidc` fields are detailed below: @@ -28,20 +32,7 @@ authentication: redirectURI: http://dex.example.com:32000/callback ``` -**To create a new application in Okta:** - -1. Select **OIDC - OpenID Connect** for **Sign-in method**. -2. Select **Web Application** for **Application Type**. -3. For **App integration name**, choose a name that you can easily remember. -4. Configure the host for your redirect URLs: - - Sign-in redirect URIs: `http://{MKE hostname}/login` - - Sign-out redirect URIs: `http://{MKE hostname}` -5. Click **Save** to generates the `clientSecret` and `clientID` in the `General` table of -the application. -6. Add the generated `clientSecret` and `clientID` values to your MKE configuration file. -7. Run the `mkectl apply` command with your MKE configuration file. - -**To test the Authentication flow:** +## Test authentication flow --- ***Note*** @@ -54,4 +45,4 @@ To test authentication flow, ports `5556` (dex) and `5555` (example-app) must be 2. Click **Login** to display the login page. 3. Select **Log in with OIDC**. 4. Enter your credentials and click **Sign In**. If authentication is successful, -you will be redirected to the client applications home page. +you will be redirected to the client applications home page. \ No newline at end of file diff --git a/content/docs/reference/authentication/SAML-providers/SAML-OKTA-configuration.md b/content/docs/reference/authentication/SAML-providers/SAML-OKTA-configuration.md new file mode 100644 index 00000000..d13b9e36 --- /dev/null +++ b/content/docs/reference/authentication/SAML-providers/SAML-OKTA-configuration.md @@ -0,0 +1,31 @@ +# Create SAML application in Okta + +1. Select **SAML 2.0** for **Sign-in method**. +2. For **App name**, choose a name that you can easily remember. +3. Configure the host for your redirect URLs: + - Single sign-on URL: `http://{MKE hostname}/callback` + - Audience URI (SP Entity ID): `http://{MKE hostname}/callback` + - Attribute statements: + - Name: email +
Value: user.email + - Name: name +
Value: user.login +4. Click **Save**. +5. Click **Finish**. +6. Navigate to the **Assignments** tab: + + a. Click **Assign** -> **Assign to people**. + + b. Click the blue **Assign** button that corresponds to the account you want to use for authentication. + + Okta generates the `ssoURL` and certificate under the `Sign On` tab. + The `ssoURL` is the MetadataURL with the final metadata removed from the path. + +7. Download the certificate to the system from which you will run mkectl: + + a. Navigate to the SAML **Signing Certificates** section. + + b. Click **Actions** for the active certificate and initiate the download. + +8. Configure the `localCa` to point to the downloaded certificate file. +9. Run the `mkectl apply` command with your MKE configuration file. diff --git a/content/docs/reference/authentication/SAML.md b/content/docs/reference/authentication/SAML-providers/SAML.md similarity index 78% rename from content/docs/reference/authentication/SAML.md rename to content/docs/reference/authentication/SAML-providers/SAML.md index 32799a43..3fdc595d 100644 --- a/content/docs/reference/authentication/SAML.md +++ b/content/docs/reference/authentication/SAML-providers/SAML.md @@ -5,11 +5,15 @@ the `authentication` section of the MKE configuration file. To enable the service, set `enabled` to `true`. The remaining fields in the `authentication.saml` section are used to configure the SAML provider. -Refer to **Configure and create a new application in Okta** section of this document -for instructions on how to obtain the field values. +For information on how to obtain the field values, refer to your provider of choice: + +- [Okta](OIDC-OKTA-configuration.md) + For more information, refer to the official DEX documentation [Authentication through SAML 2.0](https://dexidp.io/docs/connectors/saml/). +## Configure MKE + The MKE configuration file `authentication.smal` fields are detailed below: | Field | Description | @@ -44,39 +48,7 @@ authentication: emailAttr: email ``` -**To configure and create a new application in Okta: - -1. Select **SAML 2.0** for **Sign-in method**. -2. For **App name**, choose a name that you can easily remember. -3. Configure the host for your redirect URLs: - - Single sign-on URL: `http://{MKE hostname}/callback` - - Audience URI (SP Entity ID): `http://{MKE hostname}/callback` - - Attribute statements: - - Name: email -
Value: user.email - - Name: name -
Value: user.login -4. Click **Save**. -5. Click **Finish**. -6. Navigate to the **Assignments** tab: - - a. Click **Assign** -> **Assign to people**. - - b. Click the blue **Assign** button that corresponds to the account you want to use for authentication. - - Okta generates the `ssoURL` and certificate under the `Sign On` tab. - The `ssoURL` is the MetadataURL with the final metadata removed from the path. - -7. Download the certificate to the system from which you will run mkectl: - - a. Navigate to the SAML **Signing Certificates** section. - - b. Click **Actions** for the active certificate and initiate the download. - -8. Configure the `localCa` to point to the downloaded certificate file. -9. Run the `mkectl apply` command with your MKE configuration file. - -**To test the Authentication flow:** +## Test authentication flow --- ***Note*** diff --git a/content/docs/reference/authentication/authentication.md b/content/docs/reference/authentication/authentication.md index 57066c6d..4ba7a9f3 100644 --- a/content/docs/reference/authentication/authentication.md +++ b/content/docs/reference/authentication/authentication.md @@ -1,7 +1,7 @@ # Authentication Mirantis Kubernetes Engine (MKE) 4 uses Dex for authentication. -If you want to use a different authentication method, disable +If you want to use a different authentication component, disable the authentication in the MKE configuration file and add your preferred method. --- @@ -21,11 +21,13 @@ For more information on authentication feature status per release, go to - **Identity Provider (IdP)** To set OIDC or SAML you need to configure an IdP with an application. - Refer to the official Okta documentation tutorial [Add a SAML Identity Provider](https://help.okta.com/en-us/content/topics/security/idp-add-saml.htm). + Refer to + [Create OIDC application in Okta](OIDC-providers/OIDC-OKTA-configuration.md), or + [Create SAML application in Okta](SAML-providers/SAML-OKTA-configuration.md). - **LDAP Server** - To set LDAP you need to configure an LDAP server with a user. + To set LDAP you need to configure an LDAP server with the users. ## Configuration @@ -33,8 +35,7 @@ You can configure authentication for MKE 4 through the `authentication` section of the MKE configuration file. `authentication` is enabled by default, however the settings for each of the individual authentication methods are disabled. To enable a service, set its `enabled` configuration option to `true`. -Doing so will completely remove any authentication-related components from -being installed on your cluster. +Doing so will install authentication method of your choice on your cluster. ```yaml authentication: @@ -45,6 +46,6 @@ authentication: Documentation for specific authentication methods as they apply to MKE 4 is available: -- [OIDC (OpenID Connect)](OIDC.md) -- [SAML (Security Assertion Markup Language)](SAML.md) +- [OIDC (OpenID Connect)](OIDC-providers/OIDC.md) +- [SAML (Security Assertion Markup Language)](SAML-providers/SAML.md) - [LDAP (Lightweight Directory Access Protocol)](LDAP.md) From 75b587ef7a5eec394a633776de173565f98ba785 Mon Sep 17 00:00:00 2001 From: mdziadosz Date: Fri, 14 Jun 2024 10:19:47 +0200 Subject: [PATCH 11/12] Link fix --- content/docs/reference/authentication/SAML-providers/SAML.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/docs/reference/authentication/SAML-providers/SAML.md b/content/docs/reference/authentication/SAML-providers/SAML.md index 3fdc595d..47bd59bd 100644 --- a/content/docs/reference/authentication/SAML-providers/SAML.md +++ b/content/docs/reference/authentication/SAML-providers/SAML.md @@ -7,7 +7,7 @@ The remaining fields in the `authentication.saml` section are used to configure the SAML provider. For information on how to obtain the field values, refer to your provider of choice: -- [Okta](OIDC-OKTA-configuration.md) +- [Okta](SAML-OKTA-configuration.md) For more information, refer to the official DEX documentation [Authentication through SAML 2.0](https://dexidp.io/docs/connectors/saml/). From b9fab013f81ceaf52caf06878e1f20328259e851 Mon Sep 17 00:00:00 2001 From: mdziadosz Date: Fri, 14 Jun 2024 10:59:34 +0200 Subject: [PATCH 12/12] Link fix --- .../docs/reference/authentication/OIDC-providers/OIDC.md | 2 +- .../docs/reference/authentication/SAML-providers/SAML.md | 2 +- content/docs/reference/authentication/authentication.md | 9 ++++----- 3 files changed, 6 insertions(+), 7 deletions(-) diff --git a/content/docs/reference/authentication/OIDC-providers/OIDC.md b/content/docs/reference/authentication/OIDC-providers/OIDC.md index 0ae8cb83..dabfe6ac 100644 --- a/content/docs/reference/authentication/OIDC-providers/OIDC.md +++ b/content/docs/reference/authentication/OIDC-providers/OIDC.md @@ -4,7 +4,7 @@ You can configure OIDC (OpenID Connect) for MKE 4 through the `authentication` section of the MKE configuration file. To enable the service, set `enabled` to `true`. The remaining fields in the `authentication.oidc` section are used to configure the OIDC provider. -For information on how to obtain the field values, refer to your provider of choice: +For information on how to obtain the field values, refer to your chosen provider: - [Okta](OIDC-OKTA-configuration.md) diff --git a/content/docs/reference/authentication/SAML-providers/SAML.md b/content/docs/reference/authentication/SAML-providers/SAML.md index 47bd59bd..706f784b 100644 --- a/content/docs/reference/authentication/SAML-providers/SAML.md +++ b/content/docs/reference/authentication/SAML-providers/SAML.md @@ -5,7 +5,7 @@ the `authentication` section of the MKE configuration file. To enable the service, set `enabled` to `true`. The remaining fields in the `authentication.saml` section are used to configure the SAML provider. -For information on how to obtain the field values, refer to your provider of choice: +For information on how to obtain the field values, refer to your chosen provider: - [Okta](SAML-OKTA-configuration.md) diff --git a/content/docs/reference/authentication/authentication.md b/content/docs/reference/authentication/authentication.md index 4ba7a9f3..5025f3aa 100644 --- a/content/docs/reference/authentication/authentication.md +++ b/content/docs/reference/authentication/authentication.md @@ -21,13 +21,12 @@ For more information on authentication feature status per release, go to - **Identity Provider (IdP)** To set OIDC or SAML you need to configure an IdP with an application. - Refer to - [Create OIDC application in Okta](OIDC-providers/OIDC-OKTA-configuration.md), or - [Create SAML application in Okta](SAML-providers/SAML-OKTA-configuration.md). + Refer to [OIDC](OIDC-providers/OIDC.md), or [SAML](SAML-providers/SAML.md) + for detailed procedures. - **LDAP Server** - To set LDAP you need to configure an LDAP server with the users. + To set LDAP you need to [configure an LDAP server](LDAP.md) with the users. ## Configuration @@ -35,7 +34,7 @@ You can configure authentication for MKE 4 through the `authentication` section of the MKE configuration file. `authentication` is enabled by default, however the settings for each of the individual authentication methods are disabled. To enable a service, set its `enabled` configuration option to `true`. -Doing so will install authentication method of your choice on your cluster. +Doing so will install the authentication method of your choice on your cluster. ```yaml authentication: