- Home
- Configuration
- Authentication
- Supply authentication credentials
Supply authentication credentials#
A number of sensitive authentication settings are stored in a Kubernetes Secret rather than in the cluster configuration:
- LDAP bind password
- OIDC client ID
- OIDC client secret
You can supply these values either in your configuration (Option A) or by referencing a Secret that you create (Option B).
Which authentication supply method to use
| Scenario | Authentication supply method | Detail |
|---|---|---|
| Child clusters | Option B | Create a Secret and reference it with credentialsSecretName. For child clusters, the option of setting credential fields inline is deprecated and will be removed in a future API version. |
| Management clusters | Option A or Option B | Both value supply options are supported. |
| Newly installed cluster | Option A | Provide the credentials inline in the configuration, as there is no cluster yet in which a referenced Secret could exist. |
| Existing cluster | Option B | When you enable or change authentication on a management cluster that is already running, you can instead pre-create the Secret and reference it with credentialsSecretName. To use this option, you must create the Secret in advance. |
Warning
Certificate authority (CA) material is not a credential. Trust
certificates for LDAP, SAML, and OIDC are public configuration and are set
directly in the configuration (ldap.caData, saml.caData, oidc.rootCAs).
Never place CA certificates in the credentials Secret.
Option A: Provide credentials in the configuration#
Set the credential fields directly in your configuration:
authentication.ldap.bindPWauthentication.oidc.clientIDauthentication.oidc.clientSecret
When the configuration is applied, these values are moved into a Secret and are removed from the stored configuration. You do not create or manage the Secret yourself.
Option B: Reference a Secret you create#
Create the Secret and point MKE 4 to it with
authentication.credentialsSecretName. Configure MKE 4 so that it references the
Secret rather than storing credentials in the configuration file — for example,
when an external secrets manager produces the Secret.
spec:
authentication:
credentialsSecretName: my-auth-credentials
# Do NOT also set ldap.bindPW, oidc.clientID, or oidc.clientSecret here.
Warning
-
credentialsSecretNamecannot be combined with any inline credential field (ldap.bindPW,oidc.clientID,oidc.clientSecret). Any attempt to set both will be rejected. -
The Secret must exist before you reference it, and it must match the credentials Secret specification.
Credentials Secret specification#
The Secret you reference with credentialsSecretName must have the following
shape:
-
Type:
mke.mirantis.com/auth-credentials -
Namespace — management cluster:
mkenamespace. -
Namespace — child cluster: Same namespace as the child cluster configuration object, on the management cluster.
-
Keys: include Only the ones that are required by your enabled connectors, detailed blow:
Key Value Used by ldapBindPasswordLDAP bind password (plain text) LDAP oidcClientIdOIDC client ID OIDC oidcClientSecretOIDC client secret OIDC Do not add any other keys. In particular, do not add CA certificates.
Examples#
Create the Secret in the mke namespace for a management cluster:
kubectl create secret generic my-auth-credentials \
--namespace mke \
--type mke.mirantis.com/auth-credentials \
--from-literal=ldapBindPassword='<ldap-bind-password>' \
--from-literal=oidcClientId='<oidc-client-id>' \
--from-literal=oidcClientSecret='<oidc-client-secret>'
Create the Secret for a child cluster in the cluster configuration namespace:
kubectl create secret generic my-auth-credentials \
--namespace <child-cluster-configuration-namespace> \
--type mke.mirantis.com/auth-credentials \
--from-literal=ldapBindPassword='<ldap-bind-password>' \
--from-literal=oidcClientId='<oidc-client-id>' \
--from-literal=oidcClientSecret='<oidc-client-secret>'
Reference the Secret#
spec:
authentication:
credentialsSecretName: my-auth-credentials