feat: cross ns policy attachment #8676
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -51,7 +51,18 @@ type TargetSelector struct { | |
| // Kind is the resource kind that this selector targets. | ||
| Kind gwapiv1.Kind `json:"kind"` | ||
|
|
||
| // Namespaces determines which namespaces are considered for target selection. | ||
| // | ||
| // If unspecified, only targets in the same namespace as this policy are considered. | ||
| // | ||
| // When specified, the effective set of namespaces is always constrained to the | ||
| // namespaces watched by Envoy Gateway. | ||
| // | ||
| // +optional | ||
| Namespaces *TargetSelectorNamespaces `json:"namespaces,omitempty"` | ||
|
|
||
| // MatchLabels are the set of label selectors for identifying the targeted resource. | ||
| // | ||
| // +optional | ||
| MatchLabels map[string]string `json:"matchLabels,omitempty"` | ||
|
|
||
|
|
@@ -62,6 +73,35 @@ type TargetSelector struct { | |
| MatchExpressions []metav1.LabelSelectorRequirement `json:"matchExpressions,omitempty"` | ||
| } | ||
|
|
||
| type TargetNamespaceFrom string | ||
|
|
||
| const ( | ||
| // TargetNamespaceFromSame limits target selection to the policy's namespace. | ||
| TargetNamespaceFromSame TargetNamespaceFrom = "Same" | ||
| // TargetNamespaceFromAll allows target selection from all watched namespaces. | ||
| TargetNamespaceFromAll TargetNamespaceFrom = "All" | ||
| // TargetNamespaceFromSelector allows target selection from watched namespaces matching the selector. | ||
| TargetNamespaceFromSelector TargetNamespaceFrom = "Selector" | ||
| ) | ||
|
|
||
| // TargetSelectorNamespaces determines which namespaces are considered for target selection. | ||
| // +kubebuilder:validation:XValidation:rule="self.from != 'Selector' || has(self.selector)", message="selector must be specified when from is Selector" | ||
| type TargetSelectorNamespaces struct { | ||
| // From indicates how namespaces are selected for this target selector. | ||
| // | ||
| // All means all namespaces watched by Envoy Gateway. | ||
| // Selector means namespaces watched by Envoy Gateway that match Selector. | ||
| // | ||
| // +kubebuilder:validation:Enum=Same;All;Selector | ||
| // +kubebuilder:default:=Same | ||
| From TargetNamespaceFrom `json:"from"` | ||
|
|
||
| // Selector selects namespaces when From is set to Selector. | ||
| // | ||
| // +optional | ||
| Selector *metav1.LabelSelector `json:"selector,omitempty"` | ||
|
Member
Author
There was a problem hiding this comment. I’m a bit hesitant to add Or EG probably shouldn't require There is already precedent for this distinction in the Gateway API:
Member
There was a problem hiding this comment. My concern with allowing this without ReferenceGrant is that app teams could affect cluster-wide resources without the infra team’s knowledge or consent. In Gateway API model, the affected resource (e.g. Gateway managed by the infra team) has the authority to control who can attach to it. In other words, consent comes from the target side. By contrast, policy resources can be created by app teams, and a policy in one team’s namespace could target resources owned by other teams, without giving those teams any way to opt in or opt out. That said, from the infra team’s perspective, this feature is very useful because a single policy can apply across resources in all namespaces. So I think it's important to be clear about who should have that authority.
Member
Author
There was a problem hiding this comment. Hi @kkk777-7 That's a good point! I agree the key question is who should have the authority to enable cross-namespace attachment. One option is to require ReferenceGrant, but this might not be the right semantic fit, since Gateway API generally uses We've got a few options here:
type CrossNamespacePolicyAttachment struct {
Enabled bool `json:"enabled,omitempty"`
AllowedPolicyNamespaces []string `json:"allowedPolicyNamespaces,omitempty"`
}
Option 1 provides more granular control, while option 2 is simpler and would allow a smoother transition to a more Gateway API-native target-side consent model, such as an If we go with option 1, we should also start with a simpler namespace allowlist first rather than a fully flexible Selector, since the latter makes the authorization and UX harder to reason about. type TargetSelectorNamespaces struct {
// +kubebuilder:validation:Enum=Same;All;Names
From TargetNamespaceFrom `json:"from"`
MatchNames []string `json:"matchNames,omitempty"`
}In the meantime, we could pursue a more target-side consent model in the upstream Gateway API. cc @envoyproxy/gateway-maintainers could you please weigh in on the options?
Member
There was a problem hiding this comment. thanks @zhaohuabing :)
Contributor
There was a problem hiding this comment. +1 for option1, since there isnt a direct parent child relationship for policy and target, similar to gateway-route or gateway-listenerSet I do think we need to think of a way to opt out of explicit ReferenceGrants, to reduce the number of resources needed to author intent, that can be a future follow up
Member
Author
There was a problem hiding this comment. Raised kubernetes-sigs/gateway-api#4799 in Gateway API to explore an “allow-from-target” approach, similar to |
||
| } | ||
|
|
||
| func (p PolicyTargetReferences) GetTargetRefs() []gwapiv1.LocalPolicyTargetReferenceWithSectionName { | ||
| if p.TargetRef != nil { | ||
| return []gwapiv1.LocalPolicyTargetReferenceWithSectionName{*p.TargetRef} | ||
|
|
||
Uh oh!
There was an error while loading. Please reload this page.