Secure Approvals
Matt Taylor
We would like to see a feature added to limit the user accounts that can approve an "hold for approval" block. This would allow a release manager or gatekeeper be the only one to release to a production environment. It's best practice and good procedurally to be able to secure deployments to production environments or at least gate them properly.
D
David Castillo
+1 upvote for Penn Gaming who listed this as one of the main reasons for not moving forward with CircleCI. They expressed that they would incur unnecessary cost (i.e. all upstream jobs before hold job) due to the fact that anyone can approve said hold job even with restricted context.
J
John Parker
That is correct. I am going to echo Nick Fisher's comments below, and repeat that contexts simply won't suffice.
---
I've seen restricted contexts suggested as a solution to this a few times, mostly because secure approvals have been requested repeatedly, and closed repeatedly with restricted contexts being the "answer".
Restricted contexts might suffice as a temporary workaround, or might even be a great solution to a different problem, but it's a poor user experience for this problem. It's much better to disable a button a user isn't permitted to click, rather than let them click and fail on the next step. I've never worked on a software product where that would be considered acceptable behavior - it's unintuitive and frustrating.
---
This hits the nail on the head, and reflects my exact feelings on the matter.
M
Mike Lay
Have you considered making use of restricted contexts with an approval job? There is some documentation that goes over how that works here:
N
Nick Fisher
I've seen restricted contexts suggested as a solution to this a few times, mostly because secure approvals have been requested repeatedly, and closed repeatedly with restricted contexts being the "answer".
Restricted contexts might suffice as a temporary workaround, or might even be a great solution to a different problem, but it's a poor user experience for this problem. It's much better to disable a button a user isn't permitted to click, rather than let them click and fail on the next step. I've never worked on a software product where that would be considered acceptable behavior - it's unintuitive and frustrating.
FWIW, the company I work for currently uses CircleCI for our continuous integration, and Harness for continuous delivery. We'd love to consolidate the whole pipeline into Circle, but I'm very hesitant to do that if restricted contexts is the best solution we're going to get to limiting production access.
A
Alec Wilson
This would be a workaround, but as Nick Fisher says - it would be much better if the user could be prevented from clicking the approval if they're not authorised. If we started using this I imagine a lot of cases of having to rerun workflows as users clicked approve without realising they weren't in the restricted group.
A
Andrew Tremblay
Mike Lay: This doesn't solve this issue and is poor work-around. A dev that can write to the repo could simply just comment out or delete the approval from the pipeline and bypass any approval/hold.