Access Control Around Package Promotion


#1

We’re getting to the point where we’re going to want to be using the Supervisor’s ability to watch a channel and use an update strategy to deploy a new version of a package (in this case a new release of an application).

We’re prototyping this, and things look good, but it does open the question of mitigating against the risk of bad (or just clumsy) actors putting things into a channel which don’t belong there.

Access to the ability to promote or place a package in a channel becomes the way to specify whether something is released - that’s a lot of power and responsibilty.

Any thoughts or experiences on how to control and audit access and use of this extreme power?


#2

:+1: me too!

I think anyone should be able to submit a package. It’s ok to have 50 builds and only one promoted to stable. “bad (or just clumsy) actors putting things into a channel which [are experimental]” I think should be encouraged (well, within reason of course… I took some liberties…), with some sane way to cut through the cruft. And easily deprecate/sunlight/remove old/broken packages… (cough core/docutils/0.12/20170514150826 cough)

That’s a long way to say, that I agree, I think Builder, either on-prem or hosted could benefit from some RBAC!