Advisory ID: DOPPLER-PSA-2024-003 Publication Date: 2024-08-08 Revision Date: 2024-08-08 Status: Confirmed, Fixed Document Revision: 1.0
Doppler has found and resolved an issue where a user or service account with specific custom workplace permissions could access projects with more permissions than they have configured.
In Doppler, an actor can have a custom workplace role with the Access All Projects permission. This grants the actor access to all projects in the workplace and their access on those projects will be determined by the workplace’s default project role.
In general, project roles have environment+config level permissions like “View Secrets” which only apply if the actor is granted access to these specific environments+configs. If the default project role has the Access All Configs, the actor will be granted the role permissions to all environments+configs. However, if this permission is not present in the default project role, the actor will not have access to any of the environments+configs and therefore the environment+config level permissions are effectively useless.
For example, if a user has a custom workplace role containing the Access All Projects permission, and the default project role is Collaborator, the user will have the Collaborator permission on all projects with no environment access. The user would be able to list all projects and click into them via the Doppler dashboard, but they would not be able to list environments+configs, much less view or edit the secrets within them.
Doppler internally discovered an issue with the permissions system which extended this default project role’s permissions to actors with implicit access to environments+configs. Implicit access can be granted to actors in different ways. This can manifest in a few specific scenarios:
In addition to the Access All Project + default project role, an actor may have implicit access to a specific environment via a group.
To continue the example, the user with Collaborator access to a project (via Access All Projects) could also be a member of a group which grants access to the project’s Production environment as a Viewer. The expected result would be that the user has only Viewer access to the project’s Production environment.
However, the permissions issue caused the default project role to apply to this access — granting the user Collaborator access to the Production environment.
This scenario can only apply to users because service accounts cannot yet be added to groups.
Another form of implicit environment access is via the List All Environments project permission. It’s possible to create a role with environment+config level permissions and the List All Environments project level permission.
To continue from the base example, suppose that the default project role is a custom role with all of the permissions as Collaborator, but also containing the List All Environments role. The user with the Access All Projects permission would be expected to have access to all projects and be able to list environments, but not to read or write secrets. The permissions issue here caused the default project role to apply to these listable environments — granting the user Collaborator access to all environments in all projects.
This scenario can apply to users and service accounts.
Similar to Scenario 2, an actor can have direct project access with the List All Environments permission.
To continue from the base example, suppose that the default project role is Collaborator and that the user also has been directly added to the project with a custom role containing the List All Environments permission. The user would be expected to have access to all projects and be able to list environments on this specific project, but not to read or write secrets. The permissions issue here caused the default project role to apply to these listable environments — granting the user Collaborator access to all environments in the project.