Restrict ability to deploy to production - understanding 2.x permissions model

Legacy Uncategorised
1

I am attempting to upgrade from 1.6 -> 2.3.3. I’m having some issues mapping our existing permissions.

I want one of our groups to have the ability to view and edit all projects. They should be able to modify the projects, set variables for all environments, view environments, view deployment logs, create releases and deploy releases to development and staging. Basically do everything except deploy to production, manage environments and admin.

Based on what I’m seeing in the Teams screen I should create two groups with the same users. One with roles “Project lead, Project Initiator, and Environment Viewer” for all environments and another with “Project Deployer” for the development and staging environments.

Is that correct? I understand that 2.4 will allow me to manage this at the AD Group level but 2.3 requires me to do it at the user level.

We would also like to restrict the ‘admin’ group from deploying to production. This is possible in 1.6 but I don’t see a way in 2.x. I realize that it will always be possible for an administrator to get around this restriction but it was very useful to be able to show that only the ‘deployment team’ would be able to easily deploy to production and that administrators couldn’t do it accidentally.

2

Hi Trevor,

The setup you’ve described sounds right to me.

Regarding your question about restricting admin rights, we do have support for “custom roles” coming in 2.4 that I’d expect can be used to meet this need. Essentially you’d create your own pseudo-admin role with all permissions except the deployment one.

Hope this helps,
Nick

3

Thanks Nick. Due to timelines I’ll have to implement 2.3 first and then re-do things in 2.4 once AD group support and “custom roles” are implemented.

For the first part I want to be explicit so both we’re on the same page: in 2.3 Environment restrictions on a team apply to all roles for that team. If I want a user to perform Role A in all environments and Role B in just one environment I need to assign them to two teams.

Correct?

4

Hi Trevor - yes, that’s correct.

Regards,
Nick

5

2.4.1-pre is out now with this fix. Please see Configuration > Teams for role editing.

Regards,
Nick

6

For reference of future searchers we created a new Role called ‘System administrator - No deployment’ that has all permission roles assigned except DeploymentCreate.

The administrators where then assigned to a team that contains that role with no environment restrictions and a second team that allows deployment to our non-production environments.

We also removed the CreateDeployment roles from all other teams and created two new teams for Production and Non-Production deployment. AD Groups are added to both a regular team such as ‘Developer’ or ‘QA Analyst’ as well as a separate team that only grants deployment permissions to the appropriate environments and projects.

Although obviously an administrator could assign themselves to a production deployment team at any time it creates enough of an ‘air gap’ that we can demonstrate that an Octopus administrator cannot accidentally deploy to production and would have to take a positive, unambiguous step that is against policy in order to deploy a release to production.

This has (so far) been sufficient for the army of regulators and auditors charged with ensuring that only authorized personnel can deploy to production.