Thinking about future use cases, should we transform worker UUIDs into structures?

Fair. You might be able to add some stats about them. Like their tags? Idk

The provisioner daemons endpoint (#16028) supports filtering by IDs, so you could request them from there. I don't think we should prematurely add data/structure until we know what/if it's needed.

The only case I could imagine needing to check the permissions on the provisioner is if you are taking into account user-scoped provisioners{"scope": "user", "owner": "abc123..."}.

The questions I'd raise here are:

1. Do we want organization members to be able to view provisioners/jobs owned by other users?
2. Do we want organization members to be able to view provisioners/jobs in other organizations?

For provisionerjobs, the answer for 1) should probably be no, as there may be inputs to provisioners that they're not meant to see.
For provisionerdaemons, I don't think there's as much of a potential for information leakage.

Do we want organization members to be able to view provisioners/jobs owned by other users?

Provisioners are owned by an organization. All org members can read all provisioners today:

We have organizations to isolate provisioners if needed. No more granularity is currently supported.

Seeing other jobs should not be allowed. Checking permission of a list of jobs is a slow process.

Do we want organization members to be able to view provisioners/jobs in other organizations?

no we do not.

I just realized the premise for thisRBACObject is a bit broken. Essentially we would need access to template ID or workspace ID to check user-level permissions, but we only have templateversion ID and workspacebuild ID.

I don't think we want to introduce new RBAC resources for either of these so what would be a good way to solve it? Have a customdatabase.ProvisionerJobWithRBAC or something where we have/join in the required IDs?

@mafredri it is a limitation that we currently have.

template_version inherits the permissions from thetemplate. We do not have a resource for the version. The same is true for theworkspace_build. So you have to fetch the related resource to check the permissions.

To check atemplate_importprovisioner_job, you need to fetch the template version, then the template, then check the perms.

This is done because if you add a new resource, there is no method today to add related permissions. Meaning, you cannot say "If you can read template A, then you can read version B and job C". So without the related permissions, we have to duplicate the perms consistently. Which can lead to bugs, so we just do the data relation fetched 🤷‍♂️

It is a limitation we have today, and I do not see it changing anytime soon.

or something where we have/join in the required IDs

We'd have to go this way. Maybe some newVIEW. Right now we just pay the round trip costs of multiple fetches 😢. I'd support a newVIEW that joins in the right resource IDs if we need it for listing purposes.

Thanks for the detailed info@Emyrk. For now I decided to limit jobs to owners and template admins as it simplifies the RBAC. I've opened#16160 to track future work improving this. Feel free to post on the issue if I've missed something.

// cc@johnstcn

I do not love leaving this open, but I get it.

As long as we don't break any existing APIs that might fetch a provisioner job today, I can be ok with it.

@Emyrk fair. Most of the existing APIs don't apply any RBAC at all AFAICT, the just call directly out to DB in dbauthz.

The exception isGetProvisionerJobByID fetches workspace/template based on job type, but this one wasn't updated to take into account the newrbac.ResourceProvisionerJobs which would break existing functionality.

Most of the existing APIs don't apply any RBAC at all AFAICT, the just call directly out to DB in dbauthz.

Yup, ideally all RBAC checks live in the dbauthz.

Disgusting idea: usedbtestutil.NewDBWithSQLDB and just insert the raw rows you want 😅

Fair. You might be able to add some stats about them. Like their tags? Idk

Nice 👍

nit, non-blocking:organizationProvisionerJobs perhaps?

👍 This is fine for the moment.