CONTROLLED DATA
Leidos Proprietary - US Citizens ONLY
The information contained herein is proprietary to Leidos, Inc. It may not be used, reproduced, disclosed, or exported without the written approval of Leidos.

  • Created by Unknown User (johnsonli), last modified by Unknown User (blazerd) on Mar 30, 2020

For the complete list of tools, you can visit SecureDevOps (SDO) Tools and Technologies. This article describes the responsibilities for each tool.


Roles


SecDevOps Role Descriptions

SDO has its own set of roles for managing the environment and supporting the tenants. 

Project Role Descriptions

There are four roles are Project Administrator, Project User, Project Service Account and Default Read Only User.

  • For the Project Administrator role, we create an AD/Crowd group for each SDO project (sdo.project<project key>.admins and sdo.project-<project key>.users) and all users with permission to administrate a project are added to the admins group. All other project users are added to the sdo.project-<project key>.users. The mapping to each tool is not the same but in general the SDO administrator is responsible for provisioning all other users and services as well as maintaining any associated infrastructure. The Project Administrator maintains content and customization, including tool specific permissions, for a given project. Depending on the tool or service this may involve delegating or defining further roles to support project organization/administration (e.g. CMMI requirements/roles).
  • Project User has read and write access to the applications and tools. 
  • Project Service Accounts are required for projects that utilize the Continuous Integration/Continuous Deployment (CI/CD) toolchain.  The service account is a project specific, no-login account, that acts on behalf of the user who initiates the build process.  It allows the backend tools to seamlessly execute at the server level.
  • The Default Read Only User is a user that has only been afforded the minimum privileges.  This role is not specific to any particular project but does vary depending on the tool or service. For example, all users with access to SecDevOps should be able to read and checkout "public" Bitbucket repositories as well as initiate pull requests(and create branches to facilitate). Each section below will maps existing roles/permissions for each tool as well as architectural impacts/considerations (primarily whether tool is multi tenanted or project specific).

Jira Roles

Every project in Jira will have one or more users added to the Administrator role. The Administrator role allows designated users to manage Project-specific settings, including assigning users to pre-defined roles (roles and their permissions are defined by jira-administrators).  All other users will be assigned to the Developers or Read-Only role.

Confluence Roles


Confluence permissions are managed at the group level. 

  • sdo.project-<project key>.admins are granted permission to manage the project's space, including adding, deleting, and exporting content. This role also allows granting specific permissions to individual users if needed, however, most permissions will still be granted at the group levels.
  • sdo.project<project-key>.users are granted read/write permission and the ability to delete their own content.
  • Anonymous users have read-only access.  For most projects in a multi-tenant environment, this role is not used due to contract and need to know constraints.

Bitbucket Roles

Bitbucket roles are managed at the group level. Within the project, there are three levels you can be granted to a user or group:  1) Admin, 2) Write, or 3) Read.


  • sdo.project-<project key>.admins are granted permission to manage the project, its users, and its repositories. This role also allows granting specific permissions to individual users as needed, however most permissions will still be at the group level.
  • sdo.project<project-key>.users are granted read/write permission.

Bamboo

Bitbucket roles are managed at the group level. Within the project, there are two levels that can be granted to user or group:  1) Create, 2) Plan or 3) Admin.

  • sdo.project-<project key>.admins are granted permission to manage the project, its users, its build plans, and repository access. This role also allows granting specific permissions to individual users as needed, however most permissions will still be at the group level.
  • sdo.project<project-key>.users are granted create plan permission.

SonarQube

SonarQube roles are managed at the group level. Within the project, there are two roles:  1) Administer and 2) User.

  • sdo.project-<project key>.admins are granted permission to manage the project settings, and its users. This role also allows granting specific permissions to individual users as needed, however most permissions will still be at the group level.
  • sdo,project-<project-key>.users are granted User permissions.

CxSAST

CxSAST roles are managed at the group level. Within the Company (think project), there are three roles: 1) Company Managers (think project), 2) Scanner, or 3) Reviewer.

  • sdo.project-<project-key>.admins are granted Company Manager role which provides them the ability to create and manage projects, manage teams, team membership, and permissions.
  • sdo.project-<project-key>.users are granted Scanner or Reviewer permissions.



The information contained herein is proprietary to Leidos, Inc. It may not be used, reproduced, disclosed, or exported without the written approval of Leidos.
CONTROLLED DATA