Secure DevOps Best Practices for Multi-Tenant

Many tenants have asked how Secure DevOps (SDO) Engineering was able to provide flexible project administration capabilities and project segregation in the multi-tenant environment.  This article is intended to provide instruction for Jira administrators (i.e., written at a level for Jira administrators).

The key aspect of how SDO successfully operates its multi-tenant environment starts with our User Management approach. Our philosophy is to maximize the use of groups for authentication and utilizing roles for project administration. This model allows the project leads the ability to manage roles at the project level. User authentication is based on the Leidos Corporate Active Directory (AD) groups.  In our model, every project gets two groups, one for administrators (project-key.admins) and one for users (project-key.users).  This hierarchy supports the reuse of project groups for any application.  Most of our Atlassian applications authenticate through Crowd which is configured with the SDO AD filter. Other applications (Jira Service Desk, Mattermost, CxSAST) are configured to use the Corporate AD with SDO filters.

Below is a list highlighting the SDO techniques applied for multi-tenancy.

• Naming Convention
  • All customization and user-defined items such as filters, boards, screens, workflows, schemes, must have the project's prefix in the name.  For issue types and custom fields, we add the project prefix to the description of the item.  Following this naming convention is critical to preventing collisions and merging.
• User Management

• AD with or without Crowd (we go directly to the AD for CxSAST, Jira Service Desk, and Mattermost)
• Project groups

• Admin group
• User group

• Project roles

• Roles are defined at the application level.
• Project level (Users and Roles) allow changes to individuals (downgrade from user to Read-only or upgrade to admin w/o needing to change AD)

• Shared Configuration and reuse

• Jira

• We evaluated a variety of use cases and came up with

• Default Roles
• Default (rich set) of issue types
• Default Status (for workflows)
• Default Workflows (grouped issue types where appropriate)
• Default Permission scheme

• Then we created a project as a template that is configured to use all the defaults
• When we create any new project in SDO, we click on the “Use Shared Configuration” option

• Confluence

• We created a project space that serves as a template
• We use a lot of labels, content report tables, and Page Properties (this is good for rolling up data) in the project space
• Created a project blueprint from the template

• Automation for onboarding (nearing end of construction)

• REST APIs, python, ansible, …
• Use shared configuration for Jira and Blueprints for Confluence

• Customization

• Customization is limited to Jira custom issue types, custom fields, screens, and custom workflows. For performance concerns, we assess any customization requests to determine if
  • the custom issue type, field, or workflow is truly unique or does it already exist in the application
    • we will negotiate to reuse an existing field to avoid any duplication
  • the changes are beneficial to the enterprise or is unique to the project
    • If beneficial to all tenants, it will be added to the default SDO schemes provided
    • If unique, the project will have their own schemes that contain the customization
• Customization doesn't bleed because we make use of the project schemes.

• Add-ons

• Must be compatible with the host application. – for SDO this means any add-on must match Data Center compatibility for Jira, Confluence, Crowd and/or Bitbucket
• Must be beneficial to the enterprise

• no project specific add-ons (they are managed at the application level)
• add-on user license must match host user license count (e.g., Jira 2000 users, all add-ons must meet 2000 user requirement)