Integration with AWS Secrets Manager for Data Source Authentication Using OCF Connector

Alation Cloud Service Applies to Alation Cloud Service instances of Alation

Customer Managed Applies to customer-managed instances of Alation

Applies from version 2023.1.5

Alation supports integration with AWS Secrets Manager. Using AWS Secrets Manager allows you to consolidate your credentials in a single, secure location, preventing “credential sprawl” and enabling your organization to comply with IT security policies. You can store secrets such as database passwords and usernames, Kerberos authentication information, JDBC URI keys, and more. Alation will read credentials from Secrets Manager when a Data Source Admin launches metadata extraction (MDE), query log ingestion (QLI), and profiling.

You can store secrets in AWS Secrets Manager in several ways, either as unstructured text or key-value pairs in JSON format. You can also store certificates in binary form, but this cannot be done through the AWS Secrets Manager web interface, only using the AWS command-line interface. For complete details, see Create an AWS Secrets Manager secret in AWS documentation.

You need the Server Admin role in Alation to set up the integration with AWS Secrets Manager. You must also have access to the AWS IAM management console and permissions to configure IAM roles and users.

Alation can integrate with AWS Secrets Manager in two main ways:

  • Through an Alation Agent. This configuration is available to Alation Cloud Service customers on the cloud-native architecture starting with 2024.1.4. With this configuration, your Alation Cloud Service instance makes a request to the Alation Agent, which is running on your own Virtual Private Cloud (VPC), to authenticate with your data sources. The Alation Agent then makes a request to AWS Secrets Manager to obtain credentials for your data source. Your data source credentials will never leave your VPC, and they are not stored in Alation or the Alation Agent. There is currently one way to integrate through an Alation Agent:

  • Through Alation Itself. With this configuration, your Alation instance makes a request to AWS Secrets Manager to obtain credentials for your data source. The credentials are passed back to Alation and from there to your data source. If you’re using Alation Cloud Service, your data source credentials will pass through the Alation Cloud Service network. This type of integration may be most appropriate if your Alation instance is customer-managed (on-prem) or if you’re an Alation Cloud Service customer whose data source is in the public cloud or who hasn’t migrated to the cloud-native architecture. The integration can be done in three ways:

    • Configure a Role to Assume on Behalf of Alation’s Instance Profile—You configure an IAM role to assume on behalf of the role attached to Alation’s Amazon EC2 instance or container. The role is provided to Alation through an authentication profile. No access keys or secret access keys are stored on the Alation server. The role to be assumed and the Alation instance can be under different AWS accounts.

    • Configure a Role to Assume on Behalf of a User—You configure a role to assume on behalf of an IAM user. The user’s information is provided through an authentication profile created in Alation. The user’s access key and secret access key are stored in an encrypted format on the Alation server as part of the authentication profile details.

      Note

      In both options involving an IAM role, the role to be assumed is one that can read secrets from the AWS Secrets Manager.

    • Establish a User to Access Secrets Manager—You establish an IAM user’s credentials as an access key and secret access key to access AWS Secrets Manager from Alation. The user’s access key and secret access key are stored in an encrypted format on the Alation server as part of the authentication profile details.