Fabric supports integration with Secrets Management services, as they provide several benefits. While secrets are not stored in Fabric itself, only their reference IDs are.
Configuration Settings
1.1 AWS Secrets Manager
1.2 HashiCorp Vault
1.3 Azure Key Vault
1.4 CyberArk CCP
1.5 Google Cloud Secret Manager
1.6 One Identity Safeguard
Multi Secrets Management Services and Instances Support
2.1 Multi Secrets Management Service Systems
2.2 Multi Secrets Management Service Instances
In order to integrate any one of the Secrets Management service providers currently supported by Fabric, you should configure the config.ini file with the properties of the selected Secrets Management service, along with the access and permission details.
Ready to be selected, each supported Secrets Management service has its own dedicated section in the config.ini file, containing all required access and permission details.
In addition to populating these details, you must also activate that selected Secrets Management service by setting the 'ENABLED' property to 'true' in the relevant service section in the config.ini file.
The following are the required config.ini file properties for each Secrets Management service provider:
Section name: [encryption_aws_sm]
Properties:
Authentication can be done by setting these properties:
Authentication can also be performed by the service account associated with the server. This is an alternative to using an Access ID and an Access Key.
Section name: [encryption_hashicorp_sm]
Properties:
https://<vault_URL>/v1/<engine_name>
, where default engine name is "secret" (accordingly format will looks like https://<vault_URL>/v1/secret
https://<vault_URL>/v1/<engine_name>/data
Optional Properties:
Authentication is done by either tokens that can be used directly or using one of HashiCorp's other auth methods, in which case the token is dynamically generated.
Fabric supports 2 authentication methods:
Directly - where the AUTH_TOKEN property should be set.
When using this method, Fabric accesses the Vault URL with the token as auth credentials to get the secret.
AppRole - which is based on the role that Fabric is associated to in the Vault.
When using the AppRole method, Fabric first accesses the AppRole URL to obtain a token dynamically and then uses that token as authentication credentials to retrieve the secret. For this method, you should specify the following properties:
Section name: [encryption_azure_sm]
Properties:
Optional Properties:
Authentication -
Fabric supports one of the following authentication methods for Azure Key Vault, and you should accordingly set their properties:
Section name: [encryption_cyberark_sm]
Properties:
Optional Properties:
Authentication is done by using either an API key or a username and password, and accordingly, the following parameters have to be set:
Section name: [encryption_gcp_sm]
Properties:
Optional Properties:
Authentication is performed with a credentials file:
Section name: [encryption_safeguard_sm]
Properties:
Optional Properties:
TIMEOUT - default is 10000 ms.
Authentication is performed through certifications and keys that must be applied.
You can use several Secrets Management services on the same Fabric by setting and activating them in the config.ini file.
There may be various systems that provide Secrets Management services for your organization, where data resource credentials are set across different providers. In such a case, Fabric is required to access each one of them to obtain the secrets.
To use it:
Note that in the Interface Editor you can specify, per secret, which Secrets Management service to use. If you do not specify it, Fabric will attempt to find the secrets in each activated service (according to their appearance in the config.ini file).
Different Secrets Management service instances may be used in your organization. For example, in TDM production, DB source secrets are managed by a production's Secrets Management service instance, while the DB target secrets are managed by another Secrets Management service instance, although both instances are of the same provider.
To use it:
[encryption_{my_name}_sm]
. For example, name the section for production's Secrets Management service instance as [encryption_prod_sm]
and the section for the QA's instance as [encryption_qa_sm]
.TYPE
property to that section, including the name of the service provider. You can identify the type by searching for the default section namelisted above. For example, the section name for AWS Secrets Manager is [encryption_aws_sm]
, and accordingly, its type is aws
.Note: This type-specifying step is not required for sections that preserve their default names stated in the above configuration settings.
You can add as many sections as needed and also several instances across several providers. Later, in the Interface Editor, refer to and specify each secret, advising which Secrets Management service instance to use.
Fabric supports integration with Secrets Management services, as they provide several benefits. While secrets are not stored in Fabric itself, only their reference IDs are.
Configuration Settings
1.1 AWS Secrets Manager
1.2 HashiCorp Vault
1.3 Azure Key Vault
1.4 CyberArk CCP
1.5 Google Cloud Secret Manager
1.6 One Identity Safeguard
Multi Secrets Management Services and Instances Support
2.1 Multi Secrets Management Service Systems
2.2 Multi Secrets Management Service Instances
In order to integrate any one of the Secrets Management service providers currently supported by Fabric, you should configure the config.ini file with the properties of the selected Secrets Management service, along with the access and permission details.
Ready to be selected, each supported Secrets Management service has its own dedicated section in the config.ini file, containing all required access and permission details.
In addition to populating these details, you must also activate that selected Secrets Management service by setting the 'ENABLED' property to 'true' in the relevant service section in the config.ini file.
The following are the required config.ini file properties for each Secrets Management service provider:
Section name: [encryption_aws_sm]
Properties:
Authentication can be done by setting these properties:
Authentication can also be performed by the service account associated with the server. This is an alternative to using an Access ID and an Access Key.
Section name: [encryption_hashicorp_sm]
Properties:
https://<vault_URL>/v1/<engine_name>
, where default engine name is "secret" (accordingly format will looks like https://<vault_URL>/v1/secret
https://<vault_URL>/v1/<engine_name>/data
Optional Properties:
Authentication is done by either tokens that can be used directly or using one of HashiCorp's other auth methods, in which case the token is dynamically generated.
Fabric supports 2 authentication methods:
Directly - where the AUTH_TOKEN property should be set.
When using this method, Fabric accesses the Vault URL with the token as auth credentials to get the secret.
AppRole - which is based on the role that Fabric is associated to in the Vault.
When using the AppRole method, Fabric first accesses the AppRole URL to obtain a token dynamically and then uses that token as authentication credentials to retrieve the secret. For this method, you should specify the following properties:
Section name: [encryption_azure_sm]
Properties:
Optional Properties:
Authentication -
Fabric supports one of the following authentication methods for Azure Key Vault, and you should accordingly set their properties:
Section name: [encryption_cyberark_sm]
Properties:
Optional Properties:
Authentication is done by using either an API key or a username and password, and accordingly, the following parameters have to be set:
Section name: [encryption_gcp_sm]
Properties:
Optional Properties:
Authentication is performed with a credentials file:
Section name: [encryption_safeguard_sm]
Properties:
Optional Properties:
TIMEOUT - default is 10000 ms.
Authentication is performed through certifications and keys that must be applied.
You can use several Secrets Management services on the same Fabric by setting and activating them in the config.ini file.
There may be various systems that provide Secrets Management services for your organization, where data resource credentials are set across different providers. In such a case, Fabric is required to access each one of them to obtain the secrets.
To use it:
Note that in the Interface Editor you can specify, per secret, which Secrets Management service to use. If you do not specify it, Fabric will attempt to find the secrets in each activated service (according to their appearance in the config.ini file).
Different Secrets Management service instances may be used in your organization. For example, in TDM production, DB source secrets are managed by a production's Secrets Management service instance, while the DB target secrets are managed by another Secrets Management service instance, although both instances are of the same provider.
To use it:
[encryption_{my_name}_sm]
. For example, name the section for production's Secrets Management service instance as [encryption_prod_sm]
and the section for the QA's instance as [encryption_qa_sm]
.TYPE
property to that section, including the name of the service provider. You can identify the type by searching for the default section namelisted above. For example, the section name for AWS Secrets Manager is [encryption_aws_sm]
, and accordingly, its type is aws
.Note: This type-specifying step is not required for sections that preserve their default names stated in the above configuration settings.
You can add as many sections as needed and also several instances across several providers. Later, in the Interface Editor, refer to and specify each secret, advising which Secrets Management service instance to use.