Creating private projects with custom roles
This topic explains how to use custom roles to create private projects or restrict access to projects. It gives examples of how to restrict access to one project, effectively creating a private project for members you choose, how to restrict access to all projects, and how to grant access only to one or some projects.
This topic uses the viewProject action to restrict and grant access to projects. To learn more about this action, read Using actions.
Account members can't modify what they can't view
Viewing access is required to modify a resource, so if a member cannot view a resource, they also cannot modify it in any way. You can use the policies below to control who can access and modify the feature flags or other child resources in a project.
Restricting access to all projects
This example policy forbids access to all projects. It is equivalent to the LaunchDarkly Member project role, and to the No access base role. It is also equivalent to an empty policy. By default, new roles cannot take any actions on any resources.
The following code sample restricts view and edit access to all projects:
Granting access to specific projects
You can restrict teams or members to their own project-based workspace by allowing them access to only one project.
The example below allows access to the specific projects listed in the resources parameter:
Read access is project-scoped
Denying edit actions on an environment or its child resources restricts what members can modify. However, it does not prevent them from viewing resources in that environment. Instead, view access is controlled by the viewProject action on the proj/* resource. This action applies to all resources in all of the project’s environments, including flags, configs, segments, and other resources.