Conversation
seb-kro
force-pushed
the
I759286/flavor_permission_rules
branch
from
November 5, 2025 01:30
1108c89 to
76b89e5
Compare
seb-kro
force-pushed
the
I759286/flavor_permission_rules
branch
5 times, most recently
from
July 10, 2026 13:44
fb0d424 to
0ecf556
Compare
seb-kro
force-pushed
the
I759286/flavor_permission_rules
branch
from
July 24, 2026 13:37
0ecf556 to
5401635
Compare
seb-kro
force-pushed
the
I759286/flavor_permission_rules
branch
from
August 28, 2026 08:43
5401635 to
13d2e32
Compare
seb-kro
force-pushed
the
I759286/flavor_permission_rules
branch
from
September 7, 2026 09:42
13d2e32 to
9f30865
Compare
seb-kro
force-pushed
the
I759286/flavor_permission_rules
branch
2 times, most recently
from
September 14, 2026 14:51
d73a561 to
77fe2e2
Compare
Flavor access is currently controlled via private/public flavors and the flavor access list aka `FlavorProjects`. To restrict access to a flavor, it must be private and access must be granted individually to each project. To support external customers, we want to restrict access to public flavors for arbitrary domains while keeping these flavors publicly accessible on other domains without additional configuration needs. Additionally, we want to enable project owners to configure project-specific public flavor access. This adds the data model, database migration and `oslo.object` for flavor permission rules: a new mechanism for controlling flavor access. These rules do only apply to public flavors. Private flavors continue to be controlled exclusively via the flavor access list. Each flavor permission rule has a `domain_id`, an optional `project_id`, an optional `flavor_id` and an `effect` (`allow` or `deny`). The two scopes of flavor permission rules are derived from the project hierarchy: - `domain` scope rules have no `project_id`. They apply to all projects within their domain - `project` scope rules have a `project_id` of a non-domain project. They apply only to that project itself and are not inherited by sub-projects A flavor can be accessed by a project if it is allowed at both the domain scope and the project scope. Flavor-specific rules have a `flavor_id` and based on their effect either allow or deny the use of that flavor for their scope. Rules without a `flavor_id` define the default behavior for their scope. I.e., whether flavors without a flavor-specific rule are allowed or denied. If no default behavior rule exists, then all such flavors are allowed. There is at most one flavor permission rule for each combination of `domain_id`, `project_id` and `flavor_id`. Consequently, a flavor is only denied at a scope if the corresponding domain or project: - has a `deny` rule matching the `flavor_id` - OR has a `deny` rule without a `flavor_id` AND no `allow` rule matching the `flavor_id` Change-Id: I5e1332d111c07ee714f2965c558f393c8568ffaf
We enforce flavor permission rules for all flavor object get functions by extending the filtering of the query function `_flavor_get_query_from_db`. The filtering is based on the context's `project_domain_id` and `project_id`. For each scope, public flavors are filtered by their effective permission which is derived from both the flavor-specific and the default behavior flavor permission rules. So a flavor is denied for a domain or project if: - there is a `deny` rule matching the `flavor_id` - OR there is a `deny` rule without a `flavor_id` AND there is no `allow` rule matching the `flavor_id` Filter options are passed to the relevant get-function via `domain_permission` and `project_permission` parameters: - ALLOW returns non-public flavors and public flavors allowed by flavor permission rules (enforce permission rules) - DENY returns (public) flavors denied by flavor permission rules - None returns all flavors (no permission filtering) Just like the existing flavor privacy mechanisms (private flavors/flavor access list), flavor permission rules do not take effect for admin contexts and do not restrict the flavor object create, save and destroy methods in any way. We also implement new `get_permission(s)` functions to return the effective domain and project permission for flavors and flavor lists. The `Flavor` and `FlavorList` hashes in `test_objects` are updated to reflect the new fingerprints that result from adding new parameters to the remotable class methods. Since the parameter has a default, the method signature changes are backward-compatible and we do not bump the object versions. Change-Id: Ic17dcc21a07a383e26822a5fbf7cf5cfc5383ec6
Adds API endpoints for managing flavor permission rules:
- GET `/flavor-permission-rules`
- POST `/flavor-permission-rules`
- GET `/flavor-permission-rules/{id}`
- PUT `/flavor-permission-rules/{id}`
- DELETE `/flavor-permission-rules/{id}`
The index action checks three policies to determine which rules are
visible to the caller
- `index:all`: all rules
- `index:domain`: rules belonging to the context's `project_domain_id`
- `index:project`: rules belonging to the context's `project_id`
Show, create, update and delete each enforce a per-scope policy
(e.g. `create:domain`, `create:project`). This lets operators separately
restrict access to:
- domain-scope rules based on the context's `project_domain_id`
- project-scope rules based on the context's `project_domain_id` and
`project_id`
Change-Id: I8397afed673e7ffbae8bef0870cacb1bd07601d1
Add optional parameters `domain_permission` and `project_permission` to the flavor `index` and `detail` endpoints. These allow filtering flavors by the effective flavor permission (`allow`, `deny`) for the context project domain and context project. The effective flavor permission for each scope is derived from both the flavor-specific and default behavior flavor permission rules. Equivalent to flavor extra specs, the usage of these parameters is restricted by the existing flavor permission rule `index` policies. Correspondingly, we add HTTP Code 403 (forbidden) as an expected error. The flavor `detail` and `show` endpoints now also return the effective flavor permissions for the current context project domain and context project for users with the relevant flavor permission rule access. Change-Id: I5ad7e2a932755218f31c97509a8814dac329fa0a
seb-kro
force-pushed
the
I759286/flavor_permission_rules
branch
from
September 15, 2026 09:42
77fe2e2 to
ced5be4
Compare
seb-kro
marked this pull request as ready for review
September 15, 2026 10:22
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Flavor Permission Rules
To support external customers, we want to restrict access to public flavors for arbitrary domains while keeping these flavors publicly accessible on other domains without additional configuration needs. Additionally, we want to enable project owners to configure project-specific public flavor access.
This adds flavor permission rules as a new mechanism for controlling flavor access. These rules do only apply to public flavors. Private flavors continue to be controlled exclusively via the flavor access list.
Each flavor permission rule has a
domain_id, an optionalproject_id, an optionalflavor_idand aneffect(allowordeny).The two scopes of flavor permission rules are derived from the project hierarchy:
domainscope rules have noproject_id. They apply to all projects within their domainprojectscope rules have aproject_idof a non-domain project. They apply only to that project itself and are not inherited by sub-projectsA flavor can be accessed by a project if it is allowed at both the domain scope and the project scope.
Flavor-specific rules have a
flavor_idand based on their effect either allow or deny the use of that flavor for their scope. Rules without aflavor_iddefine the default behavior for their scope. I.e., whether flavors without a flavor-specific rule are allowed or denied. If no default behavior rule exists, then all such flavors are allowed.There is at most one flavor permission rule for each combination of
domain_id,project_idandflavor_id. Consequently, a flavor is only denied at a scope if the corresponding domain or project:denyrule matching theflavor_iddenyrule without aflavor_idAND noallowrule matching theflavor_idFurther Info