#327 Granular access controls
Closed: Dropped 2 years ago by dgregor. Opened 5 years ago by ralph.

For a variety of different projects (modularity, CI), it would be excellent if we had access to more granular permissions in Koji. Today, we write our services to authenticate as an admin user with koji to accomplish their goals, but this is suboptimal from a security perspective.

In particular, we are interested in being able to create a permission which has rights to create new tags.

/cc @puiterwijk, @mikem


In particular, we are interested in being able to create a permission which has rights to create new tags.

When I look at the current permission checks in Koji, there are a few natural divisions. Tag operations is one of them. Is a "tag-admin" access level something along the line of what you want, or are you wanting finer grained (e.g. only certain tag operations or only certain tags).

Hm. "tag-admin" would be a good start, but really I think we want only certain tag operations on only certain tags (named with a pattern).

We have this module build service which needs to create new tags. With tag-admin, it would also be able to monkey with the "f26" tag, but it doesn't need to. If we could say "this permission is allowed to do anything it wants to tags named module-*", that would be ideal.

So that gets further than making permissions more granular. Permissions are by their nature sort of static. Rules involving a tag pattern match sound more like an access policy.

Written by @ralph:

Hm. "tag-admin" would be a good start, but really I think we want only certain tag operations on only certain tags (named with a pattern).
We have this module build service which needs to create new tags. With tag-admin, it would also be able to monkey with the "f26" tag, but it doesn't need to. If we could say "this permission is allowed to do anything it wants to tags named module-*", that would be ideal.

I have to say, I actually really like this idea. It could be useful for allowing packagers to even have "playground tags" that stuff can be done on (admin policy) by having rules about tags prefixed with their user name being freely created/destroyed?

Would we use some kind of more common permissions, like tree or inherited one?

for example:
                                admin
            /                      |                   \
       permA            permB          permC
            /\                    /\                    /\
permD   permE  ...

nested set could be a choice to implement this.

Would we use some kind of more common permissions, like tree or inherited one?

I think the this is a somewhat different question

I think the this is a somewhat different question

Yes, it is. It's just a thought in my mind after reading this issue and viewing our current implementation of permission yesterday.
My proposal is for the organization of permissions. It's no help for rules/patterns, but might be more or less helpful for permission management.
Let's discuss it in other issue later.

I don't have a solid list of requirements or use cases for this yet.. so I'm going to try and gather them here: https://public.etherpad-mozilla.org/p/koji-acls-requirements

Feel free to add your own use cases there. When they're solidified, maybe we'll close out the etherpad and paste them back here.

My gut feeling here is that this will require a multipronged approach.

First: breaking down the admin checks into sensible categories and replacing them with finer grained permissions. This is somewhat analogous to the way full root privilege was split into capabilities in the kernel.

However, this will almost certainly not be enough. It does not make sense to have a separate built-in permission for managing each detail of particular tags or packages. That leads us to....

Second: more policy hooks for key actions. I strongly suspect that folks will want to get super granular. For example: allow a user to create tag matching a certain pattern.

Beyond that, we may also want something like....

Third (maybe): extend built-in access settings for tags. Currently, we simply have the a single permission field for tags that sets a required perm for tagging. We could extend this for different operations (though not creation, of course). OTOH, perhaps tag level perms are better solved with policy.

Fourth (maybe): chained or otherwise implicit permissions. The access landscape is going to get much more complicated, so we might need to provide a better way to manage them. OTOH, perhaps this is better solved with more robust checks in the policy. Granted, policies are hard to parse, so it would be nice to have a way to see what access a user has.

FWIW, I think the use cases gathered in https://public.etherpad-mozilla.org/p/koji-acls-requirements have basically settled. @ausil, @bowlofeggs, @puiterwijk - do you three have anything further to add there?

Copying the scratch pad content here for posterity

Please put your nick, the system(s) affected if any, and a list of requirements or use cases for a possibly improved ACL system in koji.

from @ralph:

  • In the module-build-service (MBS), we have a number of different interactions with koji that currently require admin permissions. I'll try to list them:
    • For every new module build, the MBS needs to be able to create new tags (a dest tag and a -build tag). The tag needs to be able to inherit from other tags that the MBS previously created.
    • MBS needs to be able to create and modify groups for tags that it created (build and srpm-build).
    • MBS needs to be able to tag builds into tags that it created.
      • [mikeb] What can be tagged where can already be controlled by policy.
    • MBS needs to be able to modify the package list of tags that it created.
      • [mikeb] Permission to modify the package list can already be granted to non-admins, based on tag name, using policy.
    • MBS needs to be able to build directly from an SRPM (i.e., not from SCM). It does this to build a synthetic module-build-macros package as the first step of a module-build.
    • For now, the MBS needs to be able to create and remove targets. (We may not need to do this anymore, soon. But for now, yes.)
  • In the freshmaker system, here are some more use cases:
    • freshmaker needs to be able to submit containerbuild builds for "any" container. This is probably already covered by the existing permissions/policy system.

from @ausil

  • In Fedora, it would be nice to allow certain users to do scratch image builds.
  • allow users/group of users to admin thier own tags. For instance we have a bunch of *-infra tags for use in infrastructure. giving them access to manage their own tags would help reduce tickets to releng.
    • [dcallagh] +1 million, this idea of a "tag owner" who is allowed to manipulate the tag's inheritance and package lists would be incredibly useful. It's basically "self-service Koji" which a lot of us inside Red Hat have been wanting for a long time :-)

from @bowlofeggs

  • Bodhi probably has admin permissions today (I am not sure.)
  • Here are some things that I know Bodhi does in Koji:
    • moveBuild()
    • tagBuild()
    • untagBuild()
    • A bunch of read operations that are not likely privileged.

issue #792 was recently filed for the scratch image build case in the above list

Another use case that has come up...
Some systems perform automated builds, and sometimes those builds are more correctly assigned to another user. E.g. you might want the build to be owned by the git committer, or key package order, or for notifications go to the right place such users instead.
So sort of a ‘proxybuilder’ permission...

It would be nice if target manipulation was distinct from tag operations too. There's some desire for autobots to be able to create targets, but we wouldn't want that bot to be able to manipulate tags persay

This issue has good discussion, but it's a bit too broad to act on. I'd like to separate it out into particular use case / changes.

https://pagure.io/koji/issue/1453 is fixed in 1.18 and is sufficient for the MBS use case and perhaps some other use cases as well.

https://pagure.io/koji/issue/792 can be used to track permissions for scratch builds.

https://pagure.io/koji/issue/1582 can be used for proxyuser

https://pagure.io/koji/issue/1583 for target manipulation

Metadata Update from @dgregor:
- Custom field Size adjusted to None
- Issue close_status updated to: Dropped
- Issue status updated to: Closed (was: Open)

2 years ago

Login to comment on this ticket.

Metadata