Add flavor permission rules - #581
Draft
seb-kro wants to merge 3 commits into
Draft
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
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 turned private and access must be granted individually to each project. To support external customers, we want to restrict access to certain flavors for arbitrary domains while keeping these flavors publicly accessible on other domain without additional configuration needs. Additionally, we want to enable project owners to configure project-specific 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 are independent of flavor privacy and the flavor access list. So a flavor will only be available to a project if allowed by both the flavor permission rules and 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
Enforce flavor permission rules for all flavor object get-functions by extending the filtering of the default flavor query. All get-functions are extended with a `skip_project_fprs` parameter that allows to return flavors denied at project scope also for non-admin contexts. Domain scope rules still apply. 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` 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. The `Flavor` and `FlavorList` hashes in `test_objects` are updated to reflect the new fingerprints that result from adding the `skip_project_fprs` 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 a set of fine-grained policies to determine
which rules are visible to the caller
- `index:domain`: domain-scope rules filtered to the caller's own
domain (`project_domain_id`)
- `index:domain_all`: domain-scope rules across all domains
- `index:project`: project-scope rules filtered to the caller's own
project (`project_id`)
- `index:project_domain`: project-scope rules for all projects within
the caller's domain (`project_domain_id`)
- `index:project_all`: project-scope rules across all projects
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 by the callers' `project_domain_id`
- project-scope rules by the callers' `project_domain_id` and
`project_id`
Change-Id: I8397afed673e7ffbae8bef0870cacb1bd07601d1
seb-kro
force-pushed
the
I759286/flavor_permission_rules
branch
from
August 28, 2026 08:43
5401635 to
13d2e32
Compare
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 access is currently controlled via private/public flavors and the flavor access list aka
FlavorProjects. To restrict access to a flavor, it must be turned private and access must be granted individually to each project.This adds flavor permission rules for a more flexible flavor permission management. These rules are independent of flavor privacy and the flavor access list. So a flavor is only available to a project if allowed by both the flavor permission rules and the flavor access list.
Each flavor permission rule has a
project_id, a scope (domainorproject), an optionalflavor_idand atype(allowordeny).The two scopes of flavor permission rules are derived from the project hierarchy:
domainscope rules have a domainproject_idand apply to all projects within that domainprojectscope rules have aproject_idof a non-domain project, apply only to that project itself and are not inherited by sub-projectsA flavor is permitted for a project if it is permitted at both the domain scope and the project scope. Rules without a 'flavor_id' define the domain's or project's default behavior for flavors without a flavor-specific rule. If a domain or project does not have a default behavior rule, then all flavors are permitted at that scope by default.
There is at most one flavor permission rule for each combination of
project_id,scopeandflavor_id. Consequently, a flavor is only denied at a scope if for the correspondingproject_id:denyrule matching theflavor_iddenyrule without aflavor_idAND there is noallowrule matching theflavor_idIssue: https://github.wdf.sap.corp/sap-cloud-infrastructure/nova-issues/issues/189
Change-Id: I5e1332d111c07ee714f2965c558f393c8568ffaf