Limit Secrets Usage
When configuring in Semarchy xDM a Key Management Service to encrypt or decrypt secrets or Secrets Manager to retreive secrets, you make this secret management method usable to all parts of the platform by default. However, you may want to to limit how secrets are managed in the platform.
For example, if you store database passwords in Azure Key Vault or AWS Secrets Manager, you want these secrets to be used only for datasources. You do not want them to be configurable for the HTTP headers of a REST data notification.
You can limit the usage of secrets in the KMS or secrets manager configuration using the configuration properties.
Limiting Usages for KMS
In the KMS configuration, you can define whether you want to allow or disallow the current KMS by default using the
xdm.secrets.internal.allowed boolean property. This property applies to every place in the platform configuration where a secret needs to be encrypted.
In addition, the
xdm.secrets.internal.allowed.<secret_usage> properties let you override that default behavior for specific usages.
Disallowing the current KMS prevents storing and encrypting secrets in Semarchy xDM, and is typically recommended to force the users to refer to secrets stored in a secrets manager.
For example, in the following configuration, the current KMS uses a local key. It is configured only to encrypt secrets in the IDM configuration. Other secrets will use AWS Secrets Manager.
# Current KMS is localkms xdm.secrets.internal.kms.current=localkms # Local KMS using a local key xdm.secrets.internal.kms.localsecuredkey.type=LOCAL xdm.secrets.internal.kms.localsecuredkey.keystore.key=XXXXXXXXXX # Disallow usage everywhere xdm.secrets.internal.allowed=false # Allow usage for Identity Management only xdm.secrets.internal.internal.allowed.idm=true # AWS Corporate Secrets Manager xdm.secrets.external.corporatesecretsmanager.type=AWS ... ...
Limiting Usages of Secrets Managers
In a given Secrets Manager configuration, you can define whether you want to allow or disallow it by default anywhere using the
When the property is set to
true, the secret manager is usable anywhere by default. You can override specific places where it should not be usable.
When the property is set to
false, the secret manager is usable nowhere by default, and you can override specific places where it should be usable.
In the following configuration, the secrets manager can be used only for identity management configuration.
# AWS Corporate Secrets Manager xdm.secrets.external.corporatesecretsmanager.type=AWS # Disallow usage everywhere xdm.secrets.external.corporatesecretsmanager.allowed=false # Allow usage for Identity Management only xdm.secrets.external.corporatesecretsmanager.allowed.idm=true
The following configuration allows using the secret manager everywhere except for the data notifications.
# AWS Corporate Secrets Manager xdm.secrets.external.corporatesecretsmanager.type=AWS # Allow usage everywhere xdm.secrets.external.corporatesecretsmanager.allowed=true # Disallow usage for Data Notifications xdm.secrets.external.corporatesecretsmanager.allowed.datanotification=false
You can set the value to a regular expression to allow using a subset of the secrets stored in the secrets manager. For example, the following configuration allows using the secrets manager in the identity management configuration, but only to retrieve the secret aliases starting with "internal" or "corporate".
# AWS Corporate Secrets Manager xdm.secrets.external.corporatesecretsmanager.type=AWS # Disallow usage everywhere xdm.secrets.external.corporatesecretsmanager.allowed=false # Allow using internal* and corporate* secrets for Identity Management only xdm.secrets.external.corporatesecretsmanager.allowed.idm=^(internal|corporate).*
You can combine multiple rules and overrides.
Secret Usages List
The following table lists the various usages value and corresponding platform features.
Identity Management configuration. This includes all secrets in the identity management and identity providers configuration, such as the LDAP credentials, the OpenID Connect client ID or client secret, the SAML signature, and encryption keys.
Platform Datasource configuration. This includes all secrets in datasource configuration, such as passwords.
Data Notifications configuration. This usage includes secrets such as the JMS target username and password, the properties of a Kafka target, and the REST target HTTP headers.
Notification Servers configuration. This usage includes secrets stored in the notification server properties, such as the SMTP server password.
Variable Value Providers configuration. This usage includes secrets stored in the variable value provider configuration properties, such as the LDAP credentials.