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 role-based, instance profile, or access key authentication.
Configure your organization or sub-organization to use a secrets manager 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 your organization to use a secrets manager, you can configure your connections to retrieve credentials from the secrets manager.
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.
Step 1. 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:
Step 2. 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:
Step 3. 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.
Instance profile configuration for AWS Secrets Manager
If you access AWS Secrets Manager using instance profile authentication, you need to create an IAM policy that can read secrets, create a role that has this policy, and then attach an instance profile to the AWS resource that hosts the Secure Agent.
1Log in to the AWS Management Console.
2Navigate to the IAM console.
3Under Access management, select Policies.
4Click Create policy.
5Create an IAM policy with the All list actions and All read actions access levels as shown in the following image:
6Under Access management, select Roles.
7Click Create role.
8On the Select trusted entity page, select AWS service as the trusted entity type and EC2 as the use case, and then click Next.
9On the Add permissions page, select the policy you created, and then click Next.
10Enter a role name, verify the permissions policy, and create the role, as shown in the following image:
11Navigate to the EC2 dashboard and select the EC2 instance that hosts the Secure Agent.
12Click Advanced.
13Under IAM instance profile, select the IAM role you created, and launch the EC2 instance.
Cross-account access configuration for AWS Secrets Manager
If the AWS account that hosts your secrets differs from the account that hosts the Secure Agent, you'll need to set up both accounts for cross-account access.
When you configure a connection to use a secrets manager, you choose the runtime environment for the connnection. If the runtime environment contains a Secure Agent that is hosted within an AWS account and this account differs from the account that hosts the secrets, you need to configure cross-account access. Configure cross-account access so that the Secure Agent can access the secrets.
Note: To configure cross-account access, the resource that hosts the secrets needs to be in the same region as the region you choose when you enable your organization to use a secrets manager. For more information about enabling your organization to use a secrets manager, see Enabling and disabling a secrets manager.
Step 1. Set up the account that hosts the secrets.
To set up the account that hosts the secrets, you need to create a customer-managed KMS key, encrypt the secret using the key, and attach a resource policy to the secret. You can't use the AWS managed key for cross-account access.
Perform the following steps:
1Create the KMS key by performing the following steps:
aLog in to the AWS Management Console, and search for "Key Management Service" or "KMS."
bNavigate to Customer Managed Keys.
cCreate a new customer-managed key that has the following properties:
Property
Value
Key type
Symmetric
Key usage
Encrypt and Decrypt
Key administrators
Select the IAM users or roles that will manage the key.
Key users
Select the IAM users or roles that will use the key to encrypt and decrypt secrets.
dConfigure the following key policy to allow access to the IAM role in the account that hosts the Secure Agent:
Step 2. Set up the account that hosts the Secure Agent.
To set up the account that hosts the Secure Agent, attach an identity policy to the role that the agent uses, and then verify that the account that hosts the agent can fetch the KMS key from the account that hosts the secrets.
Attach the following identity policy to the the role that the agent uses to access secrets:
To verify that the account that hosts the agent can retrieve the KMS key, run the following command from the EC2 instance in the account that hosts the agent:
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 the authentication type.
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.
Instance profile authentication
Configure the following properties when you access Secrets Manager using instance profile 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 instance profile authentication, choose Instance Profile.
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.
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. All Secure Agents within the runtime environment must be installed on a local machine or VM, and the SecretManagerApp service must be running on each agent. The Hosted Agent and serverless 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: In some organizations that are configured to retrieve sensitive connection credentials from an external secrets manager, users must create connections in Administrator. Users in these organizations can't create or edit connections 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 option 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:
* If you use AWS Secrets Manager, and the account that hosts the Secure Agent differs from the account that hosts the secrets, you must enter the full ARN 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 option 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.
All Secure Agents within the runtime environment must be installed on a local machine or VM and must be able to access the secrets manager. Additionally, the SecretManagerApp service must be running on each agent.
6Configure the connection-specific properties.
7To test the connection, click Test Connection.
8Click Save.
For more information about configuring connections, see Connections.
