Fabric supports integration with Secrets Management services, with the intent that secrets - like passwords, used in interfaces that enable communication to external systems - will not be stored in Fabric itself. (For information on how can secrets be securely stored in Fabric - read here).
Secrets Management services are tools aimed for securely storing, managing, accessing and auditing sensitive information such as passwords, API keys, and other credentials, across the organization. Features of Secrets Management services include encryption, access controls, auditing and automatic rotation of secrets.
Secrets Management has several advantages:
Fabric supports integration with various external Secrets Management providers, in which case Fabric doesn't store the secrets but rather their reference IDs.
Supported Secrets Management providers are:
In order to use a Secrets Management provider:
Each of the supported Secrets Management providers has its own dedicated section in the config.ini file, with all required access and permissions details.
In addition to populating these details, you shall turn it on by setting the 'ENABLED' property to 'true', in the section of the chosen Secrets Management provider.
Following are the config.ini attributes required for each Secrets Management provider:
section name: [encryption_aws_sm] properties:
section name: [encryption_hashicorp_sm]
The authentication within HashiCorp Vault is done by tokens that can be used directly or by using one of their other auth methods, in which case the token is dynamically generated.
Fabric supports 2 authentication methods:
Directly, where AUTH_TOKEN shall be set.
When using this method, Fabric accesses the Vault URL with the token as the auth credentials, in order to get the secret.
AppRole, which is based on the role that Fabric is associated to at the Vault.
When using this method, Fabric first accesses the approle URL to dynamically get a token, and then uses this token as the auth credentials, in order to get the secret. For this method you shall specify the following attributes:
Additionally, this shall be set:
Fabric supports one of the following authentication methods for Azure Key Vault:
section name: [encryption_azure_sm]
section name: [encryption_cyberark_sm]
Authentication is done by sending an Authorization: Bearer
header, either API key or user:passowrd, using HTTP basic authentication method:
Other parameters:
Marking an interface connection details property, to be taken from the Secrets Management provider, you shall use this pattern in its value:
${secretmanager:<id-at-seceret-manager>} For example: ${secretmanager:mysql-password}
Notes:
- Each Secrets Management provider has its own pattern, usually by hierarchy; you should follow these patterns.
- The Secrets Management service can be used also for interface connection details inside Environments. Each one of the environments and the interfaces is independent, in a way that some environments may use Secrets Management services, while others, like local testing, may not.
- You can use the Test connection option to verify that the connection settings are OK, also when the Secrets Management service is activated.
- The following properties can be addressed to the Secrets Management provider for the DB Interfaces types: host, user, password. For all other interfaces, all connection details properties can be set to use the Secrets Management provider.
Fabric supports integration with Secrets Management services, with the intent that secrets - like passwords, used in interfaces that enable communication to external systems - will not be stored in Fabric itself. (For information on how can secrets be securely stored in Fabric - read here).
Secrets Management services are tools aimed for securely storing, managing, accessing and auditing sensitive information such as passwords, API keys, and other credentials, across the organization. Features of Secrets Management services include encryption, access controls, auditing and automatic rotation of secrets.
Secrets Management has several advantages:
Fabric supports integration with various external Secrets Management providers, in which case Fabric doesn't store the secrets but rather their reference IDs.
Supported Secrets Management providers are:
In order to use a Secrets Management provider:
Each of the supported Secrets Management providers has its own dedicated section in the config.ini file, with all required access and permissions details.
In addition to populating these details, you shall turn it on by setting the 'ENABLED' property to 'true', in the section of the chosen Secrets Management provider.
Following are the config.ini attributes required for each Secrets Management provider:
section name: [encryption_aws_sm] properties:
section name: [encryption_hashicorp_sm]
The authentication within HashiCorp Vault is done by tokens that can be used directly or by using one of their other auth methods, in which case the token is dynamically generated.
Fabric supports 2 authentication methods:
Directly, where AUTH_TOKEN shall be set.
When using this method, Fabric accesses the Vault URL with the token as the auth credentials, in order to get the secret.
AppRole, which is based on the role that Fabric is associated to at the Vault.
When using this method, Fabric first accesses the approle URL to dynamically get a token, and then uses this token as the auth credentials, in order to get the secret. For this method you shall specify the following attributes:
Additionally, this shall be set:
Fabric supports one of the following authentication methods for Azure Key Vault:
section name: [encryption_azure_sm]
section name: [encryption_cyberark_sm]
Authentication is done by sending an Authorization: Bearer
header, either API key or user:passowrd, using HTTP basic authentication method:
Other parameters:
Marking an interface connection details property, to be taken from the Secrets Management provider, you shall use this pattern in its value:
${secretmanager:<id-at-seceret-manager>} For example: ${secretmanager:mysql-password}
Notes:
- Each Secrets Management provider has its own pattern, usually by hierarchy; you should follow these patterns.
- The Secrets Management service can be used also for interface connection details inside Environments. Each one of the environments and the interfaces is independent, in a way that some environments may use Secrets Management services, while others, like local testing, may not.
- You can use the Test connection option to verify that the connection settings are OK, also when the Secrets Management service is activated.
- The following properties can be addressed to the Secrets Management provider for the DB Interfaces types: host, user, password. For all other interfaces, all connection details properties can be set to use the Secrets Management provider.