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 secrets 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 usage 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 secrets.external.<secret_manager_alias>.allowed property.

When the property is set to true, the secrets 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 secrets 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 secrets 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.

Secrets usage list

The following table lists the various usages value and corresponding platform features.

Usage Description

Usage	Description
`idm`	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.
`platformdatasource`	Platform Datasource configuration. This includes all secrets in datasource configuration, such as passwords.
`datanotification`	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.
`notificationserver`	Notification Servers configuration. This usage includes secrets stored in the notification server properties, such as the SMTP server password.
`variableprovider`	Variable Value Providers configuration. This usage includes secrets stored in the variable value provider configuration properties, such as the LDAP credentials.

idm

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.

platformdatasource

Platform Datasource configuration. This includes all secrets in datasource configuration, such as passwords.

datanotification

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.

notificationserver

Notification Servers configuration. This usage includes secrets stored in the notification server properties, such as the SMTP server password.

variableprovider

Variable Value Providers configuration. This usage includes secrets stored in the variable value provider configuration properties, such as the LDAP credentials.