Secrets management for connection credentials

WHO CAN USE THIS FEATURE?

Secrets Management is an advanced capability of Workato. Reach out to your Workato Customer Success Manager for more info.

To simplify the management of your connection credentials, you can use an external secrets manager to securely store and retrieve sensitive information like passwords and API tokens.

The Secrets Management feature in Workato lets you use secrets in place of hardcoded connection credentials. Centralizing credential management can help you adopt security best practices, like password rotation, without manually updating credentials wherever they're in use.

In this guide, we discuss these topics:

• How secrets management works
• The secrets managers that Workato supports
• Using secrets to configure connections
• Workspace vs. Project level secrets management

---

How secret management works

With a secrets manager, you can use a secret instead of directly entering information into Workato. Secrets contain sensitive info like a password.

When you set up a connection, you need to manually retrieve and enter your credentials. Any time those credentials change - for example, when you reset your password - you'll need to update the password in every application that uses it.

However, if you use an external secrets manager instead, you'll only need to update the password in the secrets manager and refresh the connection in Workato. Applications using the reference will retrieve the secret's updated value, thus minimizing manual work, interruptions, and most importantly, security risk.

Remember to refresh the connection in Workato

Refresh the connection by sending a request to the Workato API to clear the secrets management cache. This updates the connection with the latest credentials in your secrets manager. You do not need to disconnect and reconnect the connection.

At a high level, here's how using a secrets manager works with Workato for connection credential management:

1

You create a vault and secret in your external secrets manager. The secrets manager encrypts the credentials.

2

You grant Workato access to the secrets manager.

3

In Workato, you configure connections using the secrets instead of credentials.

The following image demonstrates a Jira connection configured with a secret from Amazon Web Services (AWS) Secrets Manager:

4

When Workato uses the connection, it performs the following tasks, in order:

1. Request secret: Workato requests the secret from the secrets manager.

2. Retrieve and decrypt: The secrets manager retrieves the secret and returns the decrypted secret value to Workato.

3. Authentication: Workato uses the decrypted value to authenticate to the application.

4. Access: If authentication is successful, the application grants access to Workato.

---

Supported secrets managers

Workato's Secrets Management feature currently supports the following secrets managers:

• AWS Secrets Manager
• HashiCorp Vault
• Azure Key Vault

---

Using secrets to configure connections

How secrets are used in Workato connections depends on the type of secrets manager you're using. Refer to the guide for your secrets manager for more information:

• Amazon Web Services (AWS) Secrets Manager
• HashiCorp Vault
• Azure Key Vault

---

Workspace vs. Project secrets management

Typically, we configure secrets management for the entire workspace. If your organization requires more granular access control, you can configure it at the level of the individual projects. This enables you to specify the secrets inside the project, so that the connections in the projects can assume the role specified in the project settings.

For example, if your organization is configuring an S3 connection only for the use in your DevOps project, you can create a project-specific IAM role that has access to your S3 connection credentials. This replaces the generic IAM role that can be used by multiple projects.

NOTE

In Workato, secrets management can be used EITHER at the level of the Workspace, or at the level of Projects. We do not support a blended approach. For example, if you implement project-level secrets management for the DevOps project, you must change your secrets management protocol to project-level for ALL projects in the workspace.