plugin: disable queue validation, add default priority when queue cannot be found about flux-accounting HOT 8 CLOSED

Yeah, maybe so. I mean, we could just be short sighted and say that one "permit" is always sufficient and there is no deny but then someone will inevitably want something more sophisticated and this will look...short sighted. Maybe we should table this for now and I should not have hijacked @cmoussa1's issue.

from flux-accounting.

Oh, yeah, that makes sense! The idea is reminiscent of PAM with a stack of modules that are required, requisite or sufficient. I wonder if there is something that can be learned or borrowed from there...

from flux-accounting.

Brainstorming a bit on access control: maybe the [policy] and [queues] config described in RFC 33 should allow a default allow/deny policy to be set globally and on a per queue basis.

If policy were default allow, then a job is accepted unless a jobtap plugin emits an explicit deny.
If policy were default deny, then a job is rejected unless a jobtap plugin emits an explicit allow.

Maybe we would add a job.authorize jobtap callback that could return allow, deny, or pass, and then when mf_priority encounters a job for a queue it doesn't recognize, it could return pass and let the default access policy take effect (or let another plugin do something).

This takes the burden off of flux-accounting somewhat and makes at least some of the behavior visible in the TOML config, so an admin adding a queue knows what access will be in the time between pushing it out and updating flux-accounting db.

from flux-accounting.

Can this be done with the existing job.validate callback? (I'm struggling to see why a separate job.authorize callback would be required here, but then again I haven't thought about this like you two have so apologies if that is a dumb question)

from flux-accounting.

I didn't think about that too deeply before posting. This probably would work with job.validate.

There would just need to be some function that the job.validate callback could call to indicate allow or deny for the job. After the call stack completes, the tally of allow/deny results could be combined with the default allow/deny configuration to decide if the job should be rejected on the basis of authorization.

So for example, if you had a group-auth plugin that allowed everyone in the "flux" group to submit to all queues, and you had flux-accounting loaded, you could configure a default deny, then either an explicit allow call from group-auth or an allow call from mf_priority would allow the job to run, otherwise it would be denied with a generic auth failure message.

I guess the main reason I thought this was useful has less to do with enabling multiple plugins for authorization, and more to do with letting mf_priority say "I don't know" when it doesn't recognize a queue or user and let an admin configured default be used instead. Then when jobs to a newly added queue are rejected, the admin might have a more intuitive idea of what may be wrong?

Just brainstorming though, as noted above.

from flux-accounting.

Another idea (also didn't think about it too deeply):

If there isn't a real use case for deep stacks of authorization plugins, maybe we can use something similar to dependencies to handle the case where a plugin wants to authorize the use of one or more queues.

The job manager can call a job.queue.<name> or similarly named callback for a job that has requested queue <name>, at which time a plugin registered for that topic can take any queue related action, including rejecting the job due to queue access. It could be assumed that if the job is not rejected, then the job is allowed access to the queue.

If there are no plugins which have registered for the job.queue.<name> callback, then the default behavior for queue <name> could be taken, which could be a config rule to deny, or to grant access by default.

This would support multiple plugins which can reject jobs by configuration, but unfortunately wouldn't easily support a case where only one of possibly many plugins could permit the job to use a queue. The benefit for mf_priority is that it only has to register for callbacks for the queues it knows about, and can be unaware of other configured queues. We also don't have to add allow/deny reference counting, etc, so it could be easier to implement.

I haven't thought beyond that, so not sure if this is truly a workable approach or not.

from flux-accounting.

A cluster that just uses the anonymous queue could still set a default allow/deny in [policy] and use mf_priority (or another plugin) to gate access tor specific users. So it might be a misstep to tie authorization so closely to the concept of "queue"...

Random aside: I kind of forgot about this but RFC 33 also defines an "access policy" to limit access to specific groups or users (in global [policy] or per-queue). Just as a thought experiment we might want to consider how that could be implemented along side mf_priority as a jobtap plugin (IOW maybe there is a use case for a small stack of autorizors).

from flux-accounting.

So it might be a misstep to tie authorization so closely to the concept of "queue"...

Sorry, I had considered that even when no queues are configured there is still the concept of the anonymous queue. This seemed like a clever design since a job always has a queue, even if queues are not configured all jobs use the anonymous queue. Thus making it so that we don't need separate code for when queues are configured vs when they are not.

IOW maybe there is a use case for a small stack of autorizors

Maybe we will need a separate config file then to configure the stack of authorization plugins, which are required and which are sufficient, etc. Otherwise, if you just make a job.authorize callback, how do you decide what to do if one plugin says "permit" and one says "deny"?

from flux-accounting.