Handling of project features.* in authorization
#13863
Comments
tomponline
added a commit
that referenced
this issue
Aug 27, 2024
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
Should this issue remain open as only 1 PR has closed it? |
I had thought the PRs would be much larger but I've ticked all the bullets off here with the one PR. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
When any
features.*are disabled on a project, entities of that type are created in the default project instead.Authorization checks are made with specific entity URLs. If the authorizer is not aware that the entity may not be in the project specified by the project query parameter in the URL, the authorization check may fail with a "not found" error.
I've investigated the work that is needed for this and outlined it below:
request.CtxEffectiveProjectNamein the request context and handle appropriately.features.profiles, the effective project is only set in the request context when listing profiles. Iffeatures.profilesis disabled for a project, getting/updating/deleting a single profile in that project works because the access check is using the request project. This will not work with the OpenFGA authorization driver, so we'll need to always set the effective project in the request context.features.networksandfeatures.networks.zoneswe have the same situation as withfeatures.profilesabove.features.imageswe have a similar situation as withfeatures.profiles, however we need to be careful to two key areas. Firstly, the process of getting the effective project is not standardised like it is for other entity types (with a function in thelxd/projectpackage). Secondly, the database methods for getting/listing images are quite convoluted, and reperform this check on each call. I think we'll need to refactor a bit to simplify these methods by determining the effective project beforehand and passing it in.I will treat each item here separately and create a PR for each.
The text was updated successfully, but these errors were encountered: