Effective project handling

[markylaing]

Implements the following:

1. Always sets the effective project when querying entities that have associated features.* project config. This includes:
   i. Adding network, network zone, image, and profile specific access handlers.
   ii. For each entity type above, setting details in the request context to avoid repeated calculation (same pattern as for storage buckets and volumes).
2. Always uses the request project in calls to (Authorizer).CheckPermission and in calls to the auth.PermissionChecker returned by (Authorizer).GetPermissionChecker.
3. In the TLS driver, we remove effective project handling (we always expect calls to use the request project, this is what we check in their allowed project list).
4. In the OpenFGA driver, overwrite the request project with the effective project in calls to the embedded OpenFGA server. But do not "punch through" to the default project like with the TLS driver, as these permissions can be managed by an administrator.
5. Increased test coverage for project features with TLS authorization.
6. Adds tests for handling of project features with fine-grained authorization.

Closes #13863

[github-actions]

Heads up @mionaalex - the "Documentation" label was applied to this issue.

[markylaing]

I've created this issue to refactor the image database methods. For now there is an extra database call in image and image alias handlers to resolve the effective project and set it in the request context before the access check.

Edit: Whoops I forgot to add the link - #13896

[tomponline]

I've created this issue to refactor the image database methods. For now there is an extra database call in image and image alias handlers to resolve the effective project and set it in the request context before the access check.

Missing link?

[markylaing]

I've created this issue to refactor the image database methods. For now there is an extra database call in image and image alias handlers to resolve the effective project and set it in the request context before the access check.

Missing link?

Whoops, I've added it to the original comment.

[tomponline]

So in general 2 questions:

1. Can we avoid passing *Daemon to addFooDetailsToRequestContext?
2. Why are the not found errors from project.FooRecord() being masked, and if there is a reason, we should have a comment explaining it, as its non-obvious.

[tomponline]

@markylaing please can you look at whether func eventsSocket(s *state.State, r *http.Request, w http.ResponseWriter) error { is doing the right thing (WRT to projects/all projects ) whilst you're working in this area? Thanks

[markylaing]

@markylaing please can you look at whether func eventsSocket(s *state.State, r *http.Request, w http.ResponseWriter) error { is doing the right thing (WRT to projects/all projects ) whilst you're working in this area? Thanks

The events socket is doing the right thing WRT project/all-projects. If all-projects is passed, we get a permission checker with can_view_events on projects and use that for each event that is to be sent to the client. If a project name is given, we check that the identity has can_view_events on that project and deny the request if they don't, then only send events that are in that project.

This breaks down for effective projects of course. If an event occurs in the default project because the feature is not enabled in another project, we can't resolve the original request project because there may be more than one project with that feature disabled.

[tomponline]

This breaks down for effective projects of course. If an event occurs in the default project because the feature is not enabled in another project, we can't resolve the original request project because there may be more than one project with that feature disabled.

Mmm yeah that is what I was getting at. So this would mean that specifying a specific project which has certain features disabled would mean missing events for entities related to those features ? But it wouldn't mean seeing events that one shouldnt?

[tomponline]

I think we should decouple this PR from the 404 not found discussion so as not to prevent this from being merged. Can you rework this PR to not do any error masking and then we can revisit the discussion as a separate issue?

[tomponline]

var effectiveProjectName string would be clearer here no? Showing that its empty until its loaded from the DB below, rather than defaulting to the request project? (infact you seem to have switched to that pattern further down in this file).