Draft
Conversation
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 flavor permission rules as a new mechanism for controlling flavor access. 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`, an optional `flavor_id` and a `type` (`allow` or `deny`). If a project does not have any rules, then all flavors are permitted (i.e., default to the previous behavior). Rules without a `flavor_id` define the project's default behavior for flavors without a flavor-specific rule. If a project uses flavor permission rules, it is advisable to always define a corresponding default behavior rule without `flavor_id`. If a project does have rules but no default behavior rule, then flavors are denied by default. Depending on the specified `project_id`, flavor permission rules have two different scopes: - domain-project rules apply to all projects within the domain - rules of regular projects apply only to the project itself and are not inherited by sub-projects A flavor is permitted for a project if it is permitted at both the domain- and project-level. There is at most one flavor permission rule for each combination of `project_id` and `flavor_id`. Consequently, a flavor is permitted at the domain- or project-level if for that level: - No rules are defined - OR there is an `allow` rule matching the flavor - OR there is an `allow` rule without a `flavor_id` AND there is no `deny` rule matching the flavor Change-Id: I5e1332d111c07ee714f2965c558f393c8568ffaf
seb-kro
force-pushed
the
I759286/flavor_permission_rules
branch
from
1108c89 to
76b89e5
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.
There are two types of flavor permission rules:
allowanddeny.denyrules take precedence overallowrules. Rules without aflavor_iddefine the project default behavior for flavors without a flavor-specific rule. If a domain or a project does not define any rules, then all flavors are permitted by default.Depending on the specified
project_id, flavor permission rules have two different scopes:There is at most one flavor permission rule for each combination of
project_idandflavor_id. Consequently, a flavor is permitted at the domain- or project level if for that level:allowrule matching the flavorallowrule without aflavor_idAND there is nodenyrule matching the flavorChange-Id: I5e1332d111c07ee714f2965c558f393c8568ffaf