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.
IAM role configuration for AWS Secrets Manager
If you access AWS Secrets Manager using role-based authentication, you need to ensure that the IAM role that the Secure Agent uses to access secrets has the appropriate policies and permissions. You must also attach the role to your EC2 instance.
To configure the IAM role, first define a policy with the appropriate permissions, assign the policy to the role, and then update the role trust policy.
Create an IAM policy and assign appropriate permissions
The policy must be able to list and read secrets from Secrets Manager. The following image shows the minimum policies required:
Assign the policy to the IAM role
Assign the policy you created to the role that the Secure Agent uses to access secrets, as shown in the following image:
Update the IAM role trust policy
After you assign the policy, update the IAM role trust policy to define which AWS resources can access the role. To do this, either allow any EC2 VM instance to access the role or allow the EC2 instance’s role to assume the role that has permission to read secrets.
If the IAM role is the same role as the EC2 instance’s role, you can have the role assume itself.
To allow any EC2 VM instance to access the role, configure the following trust policy:
For more information about assigning polices to IAM roles and attaching IAM roles to EC2 instances, see the AWS documentation.
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:
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).
STS Endpoint
STS endpoint URL if you are using a regional or manually configured endpoint.
For example, if your service endpoint is US West (N. California), enter the following value:
https://secretsmanager.us-west-1.amazonaws.com
If not specified, the global endpoint https://sts.amazonaws.com is used.
STS Endpoint Region
Region in which your service endpoint is located, for example, us-west-1.
Enter a value for this property if your STS endpoint region differs from your Secrets Manager region. If not specified, the STS endpoint region is assumed to be the same as the Secrets Manager region.
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.
Authority Host
URL of the authority host endpoint. If not specified, the global endpoint https://login.microsoftonline.com is used.
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:
Custom path in which the AppRole authentication method was enabed. If not specified, the value is assumed to be the default path, approle.
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, Azure Key Vault, or HashiCorp 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 secrets manager for a sub-organization
You can configure a secrets manager for a sub-organization. To do this, log into the sub-organization and enable the secrets manager.
When you enable a secrets manager for a sub-organization, ensure that the SecretManagerApp service is running on a Secure Agent that is native to the sub-organization. If the SecretManagerApp service runs on a Secure Agent that is shared from the parent organization, it can only connect to the secrets manager that is configured for the parent organization. It can't connect to the secrets manager that is configured for the sub-organization.
For more information about the SecretManagerApp Secure Agent service, see Secure Agent Services.
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 path, including the secret name, in the corresponding field. If the secret is a JSON object, you'll also need to include the secret key.
The following table shows the value to enter based on the format of the secret:
For example, you configure a relational connection and you store the database password in HashiCorp Vault. The path to the secret is secret/data/MyCredentials, and the secret key is MyPassword. To retrieve the password from HashiCorp Vault, select Use Secret Vault, enable the checkbox next to the Password field, and enter secret/data/MyCredentials:MyPassword in the Password field.
The following image shows the connection details:
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.
