Security
Security with the Retool Platform can cover aspects of the underlying infrastructure (compute, network, storage, monitoring), user management and permissions, resource secrets, encryption and others as covered in the following best practices.
Best practices
Authentication
Resource: https://docs.retool.com/org-users/concepts/user-authentication
Authentication validates users through email, Google, or for self-hosted SSO providers. This helps prevent unauthorized users from gaining access to the Retool platform. When connected to SSO solutions, automated provisioning of users can also be enabled via SCIM. For further details on SSO and SCIM, please examine the following sections.
Leverage SSO to manage users (Self-hosted)
Resource: https://docs.retool.com/sso
Retool leverages OpenID with Authorization Code Flow or SAML for SSO integration. For OIDC, Retool, at minimum, expects either an ID token or access token to be a JSON Web Token (JWT) that will contain the email of the user being authenticated.
Enable 2FA for users
Resource: https://docs.retool.com/org-users/guides/two-factor-authentication
Multi-factor authentication (2FA) requires that a user not only provide a username and password, but also provide a uniquely generated token provided by a 2FA application. This token can only be generated on a device that the authenticating user has access to. This additional layer of security helps reduce the likelihood of unauthorized access.
Disable users
Resource: https://docs.retool.com/org-users/guides/disable-users
Retool administrators can easily disable users that no longer need access to the platform. If required, the user can be re-enabled at a later time.
Authorization
Once a user has authenticated, what privileges are available to that user falls under authorization. Within Retool, authorization is assigned via permissions and permission groups. The following sections detail those privileges.
Leverage permissions and permission groups
Resource: https://docs.retool.com/org-users/guides/user-permissions
Resource: https://docs.retool.com/org-users/concepts/permission-groups
Permissions for individual users or groups of users are controlled via permission groups. These permissions provide access to folders, apps, resources, and workflows. Access rules identify three different types including:
- Use - View and interact with apps in a folder.
- Edit - Create and update apps in a folder.
- Own - Rename, move, export, and delete apps in a folder.
Additional access to the query library and settings are also available.
Route users to specific apps
Resource: https://docs.retool.com/org-users/guides/workspaces
Workspaces within Retool allows an administrator to identify a specific permission group and an associated Retool application that is set as that group's default. Retool users that are in this permissions group and that do not have Edit permissions will automatically be routed to this application when they sign in.
Use current_user to control access within applications
Resource: https://docs.retool.com/org-users/guides/user-permissions
Resource: https://docs.retool.com/reference/apps/global/objects/current_user
When developing applications, the current_user that is in the app can be identified using JavaScript. With this knowledge the application can hide or disable components and restrict access to data.
Encryption
Encryption is the process of protecting information by converting it to cipher text from plain text.
Confidentiality and security controls
Resource: https://docs.retool.com/legal/security#confidentiality-and-security-controls
Retool uses AES encryption while data is at rest within the Retool platform. When in-transit Retool leverages the latest recommended cipher suite and protocols to encrypt.
Auditing
Auditing is the process of recording all actions performed by parties within the Retool Platform. The following section provides an overview.
Monitor user audit logs
Resource: https://docs.retool.com/org-users/guides/audit-logs
Within Retool, Audit Logs are available and queryable providing administrators with quick access to user access and actions performed. You can also send audit log events from Retool to DataDog. See our guide for more details.
id:"4927715028"
userId:634532
organizationId:8
ipAddress:"X.X.X.X"
geoLocation:null
responseTimeMs:113
actionType:"QUERY_RUN"
pageName:"inventory api"
queryName:"query1"
resourceName:"da58a6ed-72d1-4598-9710-3153b10af402"
▶
metadata:{} 8 keys
error:null
▶
query:{} 66 keys
status:200
isError:false
▶
request:{} 4 keys
▶
parameters:{} 4 keys
statusText:"OK"
pageVersion:"latest"
createdAt:"2023-06-26T15:12:32.652Z"
updatedAt:"2023-06-26T15:12:32.652Z"
▶
user:{} 21 keys
hasGoogleId:false
id:634532
sid:"user_f783f0a04c0e4eb8b9396a5e755285d9"
userName:null
email:"some@email.com"
firstName:"Babe"
lastName:"Ruth"
profilePhotoUrl:null
lastLoggedIn:"2023-05-27T19:12:43.329Z"
lastActive:"2023-06-26T15:12:30.956Z"
enabled:true
twoFactorAuthEnabled:null
salesCTADismissed:false
tutorialCTADismissed:false
passwordExpiresAt:null
userType:"default"
metadata:{} 0 keys
externalIdentifier:null
createdAt:"2023-05-27T19:12:42.776Z"
updatedAt:"2023-06-26T15:12:30.958Z"
organizationId:8
Administration
Synchronize users with SCIM (Self-hosted)
Resource: https://docs.retool.com/sso/guides/scim-user-provisioning
System for Cross-domain Identity Management (SCIM) provides a way to integrate user provisioning automation from the SSO provider to Retool. Examples include creating, updating, and deactivating of user accounts through actions that occur within the SSO. These events are automatically propagated to Retool via SCIM.
Protect queries
Resource: https://docs.retool.com/queries/concepts/queries#prevent-query-variable-spoofing
Resource: https://docs.retool.com/queries/concepts/queries#hide-parameters-from-audit-logs
Queries within Retool access sensitive data and can expose that data in the audit logs. To protect queries from variable spoofing, enable Prevent query variable spoofing. This prevents the use of current_user values from using values that don’t match the expected values.
In addition, an advanced feature is to use Disable logging for. This allows the administrator to call out specific parameters to disallow them from being placed in the audit logs and thus decreases the risk of accidental exposure.
Deploy multiple Retool Instances (Self-hosted)
When using Retool Self-hosted, customers can install as many Retool instances as their licenses allow. For some customers, creating environments such as Development, Testing, Staging, and Production follows their best practices for security. In this model, the customer can strictly control access to each instance and only allow those instances to see data that matches the environment. For example, test data in the development environment versus actual customer data in staging and production. By managing these environments independently, the data can have appropriate protections and preventative measures regarding data access.
Configuration variables
Resource: https://docs.retool.com/data-sources/guides/config-vars
Retool provides support for configuration variables that can be employed in different environments to store URLs, usernames, passwords, and other configuration parameters. Encryption can be enabled to keep these values secret.
Secrets management
Resource: https://docs.retool.com/self-hosted/guides/secrets/aws
Resource: https://docs.retool.com/self-hosted/guides/secrets/environment-variables
Resource: https://docs.retool.com/self-hosted/guides/secrets/file-system
Resource: https://docs.retool.com/self-hosted/guides/secrets/hashicorp-vault
Support for managing secrets is supported in Cloud and Self-hosted Retool. Secret management using AWS Secrets Manager and Hashicorp Vault allows secrets to be securely managed externally. Secret management focuses on securely storing users, passwords, and parameters. It also provides support for rotation of credentials. Retool accesses these credentials when making API and Connection requests that require these values in the request for authentication and authorization purposes.
Infrastructure
Resource: https://aws.amazon.com/compliance/shared-responsibility-model/
Resource: https://learn.microsoft.com/en-us/azure/security/fundamentals/shared-responsibility
Resource: https://cloud.google.com/architecture/framework/security/shared-responsibility-shared-fate
The underlying compute, storage, networking and monitoring solutions depend on the public cloud provider. Each provider has recommendations on security practices that can be employed in providing least privileged access in combination with the shared responsibility that the public cloud provider employs. Shared responsibility means that the provider is responsible for the security of the regions, availability zones, power, hardware and managed services that they provide. Customers are responsible for the applications (e.g., Retool Platform) they deploy into those regions/AZ(s) and policies they apply for providing access to managed services.