Hi,
We would like to have our developers control the projects in Octopus; so setting them up, assign variables, process steps etc and deploy to any internal environment.
Deploying to production should be possible, but we need approval first. So as long as we can prove that somebody approved this, we should be good.
I tried adding a Manual intervention step, scoped it to production and that worked create. I can also not skip it during a deployment so all good.
But any developer can actually remove this step (even when they are not scoped to production), create a release (or wait for the build server to create one), deploy and add the step again. Our auditors wont like this feature 
So what are my options here?
thanks
1 Like
Hi Michiel,
Thanks for getting in touch! Sorry about the delay in getting back to you.
There are not many options, honestly I haven’t heard of devs going that far. Mostly in these cases auditors are given access to the events page and check that such things are not done! (Deleting part of a process will be recorded).
I brought this situation up with the team and we determined that the process permissions only have create and edit, as edit is more for the process itself than the actual steps, and deleting a step is editing the process. However I think also it wouldn’t be completely out of context to still add a process delete that controls deleting a step. Of course the smarter devs will just change the step to not be scoped to production and leave you in the same boat. So I am not sure what we can do about that if they have specific production permissions.
Thoughts?
Vanessa
I think that having this intervention step on the same level as the the other process steps, you will still have this issue (unless you add more fine grained permissions on individual process steps which would be overkill).
I agree that the audit log should help, but there is a lot of logs to go through and check for this. The auditors really indicate that the developers should have no option/ability to do this.
One option would be to move this approval process away from the process steps and to the environments itself or even to the lifecycles? And then control the access on those layers. If I can indicate that as part of the lifecycle, the project needs to be deployed to test AND it needs a recorded approval, only then I can deploy to production, that would cover my scenario. Lifecycle management is not something the developers need to do. Does this make sense?
Hi Michiel,
I am not sure if that would work as I know of quite a few customers who have more than one manual intervention step in a deployment process.
What about something in the middle like manual intervention steps can only be modified/created by administrators?
This may need to go to to UserVoice to see what the community has to say.
Vanessa
I see your point indeed. Marking intervention steps as something that can be secured additionally would be great. Happy to vote on a uservoice if this is in line with your thinking.
For now we will try the audit log as proof and see if we can get the auditors to accept this.