Memberships

What are memberships?

Memberships are used to manage access to organizations and projects in Phobos. Each membership is associated with a role that has designated permissions. The role defines what a principal (user, team, or service account) can do within the organization or project.

Have a question?

Check the FAQ to see if there's already an answer.

Types of memberships

Phobos contains the following three types of membership:

• User Membership: a direct association between a user and an organization or project. It is created when a user is added to an organization or project. It represents a human user.

• Team Membership: an association between a team and an organization or project. It is created when a team is added to an organization or project. It represents a collection of human users.

• Service Account Membership: an association between a service account and an organization or project. It is created when a service account is added to an organization or project. It represents a machine user.

Roles and permissions

Roles define what a principal can do within an organization or project. Phobos contains four default roles each with designated permissions. The roles are assigned to a membership to manage access and actions that a principal can perform.

Phobos contains the following default roles:

• Owner: has administrative control over projects, users, memberships, agents, environments, and approval rules. This role is suited for those responsible for governing access, defining policies, and overseeing the entire platform.
• Release Manager: can oversee releases, manage pipelines, and ensure that deployments are executed smoothly. While Release Managers can create and modify pipeline templates, manage service accounts, and control release lifecycles, they do not have administrative privileges over users or projects. Release Managers can create and update environment protection rules. Additionally, they include all the permissions of the Developer role.
• Developer: can execute pipelines, manage pipeline templates, and interact with most resources necessary for development and deployment. However, they do not have administrative control over environments, projects, or users. Developers cannot create and update environment protection rules.
• Viewer: a read-only role, which provides access to view resources within an organization or project without making changes.

Organization- and Project-level Memberships

Memberships are either at the organization or project level. Additionally organization-level memberships are inherited. For example, a user membership with a role of Release Manager at the organization level would also have the same Release Manager capabilities in all of the organization's projects.

Viewing memberships

To view memberships, select Members from the organization or project sidebar. The Members page lists all members along with their membership Type and Role.

The example above shows a list of members of an organization.

The example above shows a list of members of a project. Note, the project memberships table contains a Source column. Organization means the membership was inherited from the parent organization and updates will need to be made at the organization level. Direct Member means the membership was created within the project and therefore, the member only has access to the target project.

Creating a membership

1. Navigate to the target organization or project in which the membership will be created.

2. Select Members from the sidebar. Then select Add Member.

3. Select a member type: User, Team, or Service Account.

4. Select one of the users, teams, or service accounts that are available to the targeted organization or project from the dropdown.

5. Select a role for the member.

6. Click Add Member.

   

Updating a membership

1. Navigate to the target organization or project.

2. Select Members from the sidebar.

3. Click on the pencil icon of the member you want to update.

4. Select a role from the Role dropdown.

5. Click Save.

   

Removing a membership

1. Navigate to the target organization or project.

2. Select Members from the sidebar.

3. Click on the X of the member you want to remove.

4. In the Remove Member dialog, click Remove to remove the member. Click Cancel to close the dialog without making any changes.

   

   warning

   Removing a membership will prevent the user, team, or service account from accessing the organization or project.

Frequently Asked Questions (FAQ)

Who can create a membership?

Owner or higher roles (e.g., System Administrators or custom roles with additional permissions) can create a membership.

What role should I give to a principal?

We recommend following least privilege practices, therefore a principal should only have access to the minimum amount of information and actions needed to carry out their roles. Here is some additional guidance:

Owner roles should be assigned to principals who need complete control over an organization or project, including creating memberships, agents, environments, and approval rules. While an organization or project can have many Owners, we recommend assigning this role sparingly.

Release Managers and Developers are for principals who will need to run and execute pipelines and create releases. See the FAQ below for more details on who should be assigned as either a Release Manager or Developer.

Viewer roles should be given to principals who only need read-only access to an organization or project. Viewers are for principals who do not need to make changes to any resources and/or may just need to monitor or review activity.

What's the difference between a Release Manager and a Developer?

The main difference is that a Release Manager can create, update, and delete environment protection rules and a Developer cannot create nor update the rules. Assigning a member as a Release Manager designates that member as being responsible for controlling which principals (users, teams, or service accounts) or other members with designated roles can deploy to certain environments.

Both Release Managers and Developers have many of the same permissions, for example, they can both create and modify pipeline templates, manage service accounts, control release lifecycles, and interact with most resources needed for deployment. Additionally, neither of them have full administrative control over projects and users, for example, they cannot create nor update projects, agents, nor environments.

If a member will need to manage and limit pipeline deployments by creating and updating environment protection rules, they should be assigned as a Release Manager. If a principal will need to the ability to modify resources for deployment, but will not need to limit deployments for other members, they should be given the role of Developer. Check out Environment Protection Rules for more information.

Why am I seeing a "subject is not authorized to perform the requested operation" error?

Generally, this error occurs when the subject (a.k.a., principal) is able to view the resource but not modify it. Please reach out to the organization or project owner to get the necessary role assigned to the principal.

Why am I seeing a "Resource not found" error?

This error occurs when the principal is not a member of the organization or project. Please make sure that the principal is a member of the organization or project and has the necessary role assigned to it. (For security reasons, Phobos returns "Resource not found" instead of a more specific error to prevent information disclosure about the existence of resources to unauthorized users.)

Can a user from one organization access resources in another organization?

No, a user can only access resources within the organization it is a member of.

I don't want to give my user access to all projects in my organization. What should I do?

You can assign a role to the user at the project level. Navigate to the project's page and click on the "Members" tab. Then click on the Add Member button and assign a role to the user.

What's the benefit of a team membership over a user membership?

A team membership allows you to manage access to an organization or project for a group of users. This is useful when you want to give the same level of access to multiple users.

Is it possible to have custom roles?

Yes, although, only System Administrators can create custom roles. Please reach out to your System Administrator if you need a custom role.