We recently began experimenting with building with retool and I quickly ran into a security issue that I can't seem to get past.
Right now it seems access controls for retool plans only restrict based on application/component.
As things stand, I'm unable to task our developers with creating tooling in a develop environment without exposing sensitive keys/secrets that would be needed by our production internal tools.
If possible, it would be extremely useful to restrict access to environments as well. Doing so would allow us to build our applications in a "least-knowledge-needed" paradigm, which ultimately will be required for us to continue to build with retool.
Retool allows access per environment and also at the query level. Have you read through the docs? What exactly are you trying to accomplish? This has been brought up several times in the forum. Also, if you can’t find info based on what you are trying to achieve, reach out to support. Are you on cloud or self hosted?
I was told to post this feature request here by the support team as they told me that access restriction by environment was not possible.
What I'm trying to accomplish:
We have API servers that our org runs which can be accessed by providing an auth header along with the request.
I would like to create internal tooling which can access these Rest API endpoints with retool
I would like to give certain developers access to create these tools, but restrict them to only have access to the "develop / staging" environment variables in retool
Engineer here from Retool who worked on the environments feature.
Thanks for posting this and sharing your feedback! We've been seeing a lot of requests for assigning access to environments based on permission groups and it's something that is on our roadmap! We'll keep this thread updated as we make progress.
No updates yet, unfortunately. The team in charge of this product area is currently focused on revamping our Source Control feature, but we'll hopefully revisit this feature request soon!
Does this mean that with a Business subscription, users assigned a use permission for an app can switch between environments??
We're trying to find a solution for an app that connects with several Oauth resources and rather than creating an app for each client, environments seems a solution, but if clients can change them that would mean seeing other client's data resources
That is correct. We don't currently have a way to restrict users to a certain environment.
For the time being, I'd recommend separate apps, or data restrictions that limit what each authenticated user is able to query. For example, on the Retool side, you could add limitations based on the current_user (like this example and this example)
Question, if we use embed, will end users also be able to switch environments? Are we able to embed an app with a link for a specific environment (using URL or other solution) or will it always default to production?
if we use embed, will end users also be able to switch environments? Are we able to embed an app with a link for a specific environment (using URL or other solution) or will it always default to production?
I just checked on this internally. It looks like you should be able to set the environment when generating the url (using the optional environment param), but end users won't be able to switch environments - unless you build a feature to fetch a new url with the environment they want
I noticed that there is the possibility of defining a profile's access to specific environments for each resource (I don't know from which version). However, the behavior of these definitions was not as we expected.
A serious mistake occurs for our purposes with this feature: when a user who has this profile creates a query with the elt-mssql resource (see image) within an application in a staging environment, he can, after creation, execute it in the production environment, simply switch to this environment and click the "preview" or "run" button. This means that queries in development can be executed in production, which is exactly what we don't want to happen.
My hope is that you will tell me that I am using this configuration wrong, but if I use it correctly, I will be able to restrict the environments that each group on the system will have access to. Is this the case?
@Tess, the simple functionality of being able to block access to the production environment from the development screen would be very useful. However, the ideal is that we could restrict the production environment to everyone with the "Dev" profile, regardless of whether the user is on the development screen or the tool use screen.
