Simple RBAC system for Dev/Ops

[tangentsoft]

Description

I wrote the title carefully: there's development and there's operations, two separate activities that get mashed together into one term these days. The thing is, when it comes to a container image registry, they're very different tasks. Developers create, push, and maintain the images, while operations pulls them, only. Operations has no business pruning old images, and they absolutely must not push new ones.

All trivially true. The problem is when you go looking into the Distribution docs to find out how to implement this in the user system and find that there aren't any RBAC type controls to enforce it.

If you then go searching the web, you find all kinds of nasty hacks involving nginx and similar proxies stood up in front of Distribution to filter based on URLs, but…ick.

I'm not asking for an enterprise-grade IDM system here. All I want is to define two users: one for the developers, with full control, and one for use at install/update time that can do nothing more than pull from these images.

If the feature were hard-coded to do that and that alone, I'd be happy, but while implementing it, I think you might as well extend the concept to its natural limit, modeling the new RBAC system on the main docker image verbs: push, pull, rm, search, tag, untag, etc. For my purposes, all I'll end up using it for is the two-user configuration, but others might want to be able to do things like deny "list" and "search" to prevent bots from crawling the available set of images; if you don't know what it's called, you can't pull it.

In case anyone is thinking about objecting that all the big cloud container registries have RBACs that cover this type of need, yes, I'm aware of that. My answer to that observation is simple: if I was interested in pushing my private images into a cloud repo, would I be here typing this? No, I would not. 🤓