You can configure your organization to retrieve sensitive connection credentials from an external secrets manager instead of storing the credentials in the Informatica Intelligent Cloud Services repository. A secrets manager is also called a secret vault or a key vault.
Using a secrets manager offers the following benefits:
•You retain complete control of your sensitive connection credentials like passwords, OAuth tokens, and API shared secrets.
•You can manage secrets across multiple environments instead of on a per-application basis.
•You can rotate secrets on your schedule without affecting your connections, mappings, or tasks in Informatica Intelligent Cloud Services.
When you enable your organization to use a secrets manager, your Secure Agents can dynamically access sensitive connection credentials from the secrets manager. You can configure one secrets manager for each organization or sub-organization.
You can use one of the following secrets managers:
•AWS Secrets Manager
•Azure Key Vault
•HashiCorp Vault (HCP cloud-hosted)
If you use AWS Secrets Manager, the Secure Agent can access it using either role-based authentication or an access key.
Configure a secrets manager for your organization or sub-organization on the on the Security tab of the Settings page, as shown in the following image:
To configure your organization to use a secrets manager, you must have the Admin role or the SMS Manage Connection and SMS View Connection feature privileges as well as sufficient privileges to access the Administrator service. The organization must also be configured to store connection credentials on the cloud. You can't use a secrets manager if your organization stores connection credentials on a local Secure Agent.
After you configure a secrets manager for your organization, you can configure your connections to use the secrets manager. You can also choose which secrets to store and retrieve.
Note: If you configure a secrets manager, all connections must be created and edited in Administrator. You can't create and edit connections when you configure mappings and tasks in Data Integration.
Secret names and formats
AWS Secrets Manager and Azure Key Vault enforce restrictions on secret names. HashiCorp vault requires that secrets use a different format based on the version of the secrets engine.
The following secrets managers have restrictions on secret names or formats:
AWS Secrets Manager
In AWS Secrets Manager, secret names can contain only alphanumeric characters and the following special characters:
/ _ + = . @ - "
Azure Key Vault
In Azure Key Vault, secret names can only contain alphanumeric characters and dashes.
HashiCorp Vault
In HashiCorp Vault, secrets must be in either of the following formats based on the secrets engine version:
Note: Because a colon is used to separate the secret path from the key, Informatica Intelligent Cloud Services can't process keys that have a colon in the path.
For more information about restrictions on secret names and formats, see the documentation for your secrets manager.
AWS Secrets Manager connection properties
If you select AWS Secrets Manager as your secrets manager, configure connection properties such as the authentication type and region. The connection properties vary based on whether you use role-based authentication or an access key.
Note: To use role-based authentication, the Secure Agent must be installed in an EC2 instance.
Role-based authentication
Configure the following properties when you access Secrets Manager using role-based authentication:
Property
Description
Type
Secrets manager type. Choose AWS Secrets Manager.
Authentication Type
Authentication type that the Secure Agent should use to access Secrets Manager. For role-based authentication, choose Role Based Access.
IAM Role
Amazon Resource Name (ARN) of the IAM role that the Secure Agent should use to access secrets. Typically, the format is:
arn:aws:iam::<account>:role/<role-name-with-path>
The IAM role that you specify must be assigned an access policy with the GetSecretValue and ListSecrets permissions.
For more information about setting up IAM roles on EC2, see the AWS documentation.
External ID
External ID required to assume the IAM role.
Region
Region code for the region where your Secrets Manager secrets are hosted, for example, us-east-2.
Don't enter a full region name like US East (Ohio).
Access key authentication
Configure the following properties when you access Secrets Manager using an access key:
Property
Description
Type
Secrets manager type. Choose AWS Secrets Manager.
Authentication Type
Authentication type that the Secure Agent should use to access Secrets Manager. For access key authentication, choose Access Key.
Access Key ID
AWS access key ID that the Secure Agent should use to access secrets, for example, AKIAIOSFODNN7EXAMPLE.
The access key ID must be associated with an IAM role that is assigned an access policy with the GetSecretValue and ListSecrets permissions.
You need to enter both the access key ID and the secret access key.
Secret Access Key
AWS secret access key that the Secure Agent should use to access secrets, for example wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY.
You need to enter both the access key ID and the secret access key.
Region
Region code for the region where your Secrets Manager secrets are hosted, for example, us-east-2.
Don't enter a full region name like US East (Ohio).
For more information about AWS Secrets Manager properties, see the AWS documentation.
Azure Key Vault connection properties
If you select Azure Key Vault as your secrets manager, configure connection properties such as the client ID, client secret, and tenant ID.
Configure the following properties:
Property
Description
Type
Secrets manager type. Choose Azure Key Vault.
Client ID
Application (client) ID that the Secure Agent should use to connect to your key vault.
The client ID is the unique application (client) ID assigned to your app by Azure AD when it was registered.
Tip: You can find your application (client) ID in your Azure subscription in Azure Active Directory > Enterprise applications > Application (client) ID.
The application (client) that you specify must have the Get and List permissions for secrets.
Client Secret
Secret string that the Secure Agent uses to prove its identity when requesting access to the key vault.
Tenant ID
Azure Active Directory (tenant) ID that should be used for authenticating requests to the key vault.
Vault URI
URI of the key vault that stores the connection credentials.
For more information about Azure Key Vault properties, see the Azure documentation.
HashiCorp Vault connection properties
If you select HashiCorp Vault as your secrets manager, configure connection properties such as the role ID, secret ID, and Vault URI.
Configure the following properties:
Property
Description
Type
Secrets manager type. Choose HashiCorp Vault.
Role ID
ID of the AppRole that the Secure Agent should use to authenticate with Vault.
The AppRole must have the read and list permissions for secrets.
Secret ID
Secret ID of the AppRole that the Secure Agent should use to authenticate with Vault.
Vault URI
URI of the key vault that stores the connection credentials, for example:
For more information about HashiCorp Vault properties, see the HashiCorp documentation.
Enabling and disabling a secrets manager
Enable and disable the use of a secrets manager on the Security tab of the Settings page.
1On the Settings page, open the Security tab.
2Click the edit (pencil) icon.
3Select Enable Secret Vault, as shown in the following image:
4 Select the secrets manager that you use, either AWS Secrets Manager or Azure Key Vault.
5 Enter the connection details such as the vault URI, authentication type, and region.
6 Test the connection.
When you test the connection, you need to select a runtime environment. The runtime environment you select must contain a local Secure Agent that runs the SecretManagerApp service. The Hosted Agent, serverless agents, and cloud-hosted agents can’t connect to an external secrets manager.
When the connection is successful, you can configure connections to use the secrets manager.
To disable the use of a secrets manager, clear the Enable Secret Vault option. However, you'll first need to disable the Use Secret Vault option in all connections.
Configuring a connection to use the secrets manager
You can configure any connection that has sensitive credentials to retrieve these credentials from the secrets manager.
Note: If you use a secrets manager, you need to create or edit connections in Administrator. You can't create and edit connections when you configure mappings and tasks in Data Integration.
1Open the Connections page.
2Perform either of the following actions:
- To create a connection, click New Connection and enter the connection details.
- To edit a connection, click the connection name, and then click Edit.
3In the Connection Properties area, select Use Secret Vault.
4Enable the checkbox next to each property that you store in the secrets manager, and then enter the secret name in the corresponding field.
Enter the secret name in the following format:
- AWS Secrets Manager: <secret name>:<secret key>
- Azure Key Vault: <secret name>
For example, you configure a relational connection and you store the database password in AWS Secrets Manager. The secret name is MySQLServerCredentials, and the secret key is MyPassword. Select Use Secret Vault, enable the checkbox next to the Password field, and enter MySQLServerCredentials:MyPassword in the Password field, as shown in the following image:
5Select the runtime environment to be used with the connection.
The runtime environment you select for the connection must contain a local Secure Agent that runs the SecretManagerApp service. The Hosted Agent, serverless agents, and cloud-hosted agents can’t connect to an external secrets manager.
6Configure the connection-specific properties.
7To test the connection, click Test Connection.
8Click Save.
For more information about configuring connections, see Connections.
