No results for ""
EXPAND ALL
  • Home
  • API docs

Creating private projects with custom roles

Read time: 2 minutes
Last edited: Nov 27, 2024

Overview

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 built-in No access role. It is also equivalent to an empty policy. By default, new custom role policies cannot take any actions on any resources.

The following code sample restricts view and edit access to all projects:

[
{
"effect": "deny",
"actions": ["*"],
"resources": ["*"]
}
]
Older custom roles may have read-only access to all resources by default

By default, new custom roles cannot take any actions on any resources. However, custom roles created prior to October 2024 had the option to use the built-in Reader role as their starting point, rather than starting with no access.


To check whether this applies to any of your existing custom roles, edit the custom role and look for the warning statement "This role currently has base permissions set to Reader. Members can view all LaunchDarkly content." Uncheck the box to update the role so that it starts with no access and only allows actions based on the statements in its policy.

The warning statement on an older custom role, indicating it includes Reader access.
The warning statement on an older custom role, indicating it includes Reader access.

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:

[
{
"effect": "allow",
"actions": ["*"],
"resources": [
"proj/project-1",
"proj/project-2",
"proj/project-3",
"proj/project-4"
]
}
]