SnapLogic Accounts provide the information that Snaps need to access source and target endpoints when executing. For example, a MySQL Snap requires authenticated access to a MySQL database. In SnapLogic, you create an Account to store credentials and any other information necessary to connect, such as a URL, hostname, and port number. The following screenshot shows an example Workday Account:
Protection for Account Information
At runtime, Account credentials are protected as follows:
For a SnapLogic-managed Snaplex (Cloudplex), when you create an Account, the information in it is encrypted by the browser before transmission using your Org’s public key. At rest, the encrypted Account data is stored in an encrypted Amazon S3 bucket. When a Pipeline executes, the Snaplex decrypts the information using a private key.
For a self-managed Snaplex (Groundplex) the default behavior is the same as for a SnapLogic-managed Snaplex. Organizations can add one of the following for additional security:
Enhanced Encryption, where the organization creates and manages the private keys used by nodes to decrypt credentials.
Secrets Management, for organizations using a third-party secret manager, such as HashiCorp Vault.
Creating Accounts and Controlling Access
You can create Accounts from SnapLogic Manager or add a new Account when configuring a Snap. For some endpoints, SnapLogic supports different types of Accounts. For example, for SQL Server, you can choose between a regular or a dynamic Account. Dynamic Accounts offer expession-enabled fields as described in the next section.
A single Account can be used by multiple Pipelines, Snaps, and Flows. Accounts are accessible to the User who created them and to Pipelines in the Project folder in which they were created. Accounts in a shared folder can be used by anyone with access permission to that folder. Org admins with access to multiple Orgs can migrate Accounts from one Org to another. Learn more about Migrating Accounts.
Dynamic Accounts can use expressions for connection information instead of literal values. You can then define the values as Pipeline parameters, or if your Org is using Secrets Management, provide the values necessary to fetch credentials from a Secrets Manager. The following screenshot shows the dynamic fields available in an Azure SQL Active Directory Dynamic Account: