Update NPEP-133 with Admin-tier restriction, DNS security guidance, and v1alpha2 API#366
Update NPEP-133 with Admin-tier restriction, DNS security guidance, and v1alpha2 API#366tssurya wants to merge 1 commit into
Conversation
✅ Deploy Preview for kubernetes-sigs-network-policy-api ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: tssurya The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
k8s-ci-robot
added
approved
| if BANP allows traffic to `example.io`, but the namespace admin installs a | ||
| Kubernetes Network Policy, the namespace admin has no way to replicate the | ||
| `example.io` selector using just Kubernetes Network Policies. | ||
| * DomainNames is restricted to the Admin tier of ClusterNetworkPolicy only. |
There was a problem hiding this comment.
The notes from Atlanta say that we didn't really discuss this, which matches my memory. I think we had agreed though, when talking about Pass and priority, that in the new one-object-with-tiers world, there would be a default assumption that Admin and Baseline would have identical functionality.
The fact that some uses of DomainNames in Baseline would cause problems seems more like a "don't do that then" situation than something we actually need to restrict.
There was a problem hiding this comment.
We discussed this again in the network-policy-api sub area meeting on April 7th 2026 and decided let's start with restricting it to only Admin Tier and then later upon use case and request , we can make it available for Baseline Tier
There was a problem hiding this comment.
oh wait or maybe I am confusing this with Pass..
Did we decide to keep DomainNames with Baseline as well, but just restrict it to not be used with Pass?
There was a problem hiding this comment.
Yeah, the "Maybe we start with restricting things and then open things up?" comment there was about whether we should allow Pass rules with DomainNames. I think we all agreed that we should allow DomainNames in Baseline CNPs.
| // +kubebuilder:validation:XValidation:rule="self.tier == 'Baseline' ? !self.egress.exists(rule, rule.to.exists(peer, has(peer.domainNames))) : true",message="domainNames cannot be used in Baseline tier as NetworkPolicy cannot override FQDN rules" | ||
| type ClusterNetworkPolicySpec struct { ... } | ||
|
|
||
| // +kubebuilder:validation:XValidation:rule="self.to.exists(peer, has(peer.domainNames)) ? self.action == 'Accept' : true",message="domainNames may only be used with Accept action" |
There was a problem hiding this comment.
Maybe flip the rule the other way around like the tier check above, to put the simple check first and only do the exists check if it fails?
Also, is "only with Accept" correct, or should it be "not with Deny"? That is, should we allow "Pass" with DomainNames? I'm not sure we really thought about that, and given how we kept getting confused and thinking of admins using "Allow" when we really meant "Pass", maybe we need to revisit this.
There was a problem hiding this comment.
Meeting notes from 7th April 2026:
[surya] https://github.com/kubernetes-sigs/network-policy-api/pull/366 - update to FQDN NPEP
If any API changes are we ok to backport this to ANP - noone opposed in meeting
[dan] Do we need to also have FQDN in the PASS case? And not just ACCEPT?
Meeting notes:
supporting PASS is OK?
Does Calico allow PASS for domainNames match? - NO.
Right now Cilium is also only doing domainNames and ACCEPT
Maybe we start with restricting things and then open things up?
so for now we keep it only with accept and then open it up later for pass?
| tier of ClusterNetworkPolicy. | ||
|
|
||
| These restrictions are enforced via CEL validation on | ||
| `ClusterNetworkPolicySpec` (Baseline tier) and |
There was a problem hiding this comment.
don't do a CEL for this
allow FQDN also in baseline tier
There was a problem hiding this comment.
k8s-ci-robot
added
the
needs-rebase
…nd CEL The PR updates the details around domainNames as discussed in KubeCon Atlanta: https://docs.google.com/document/d/1AtWQy2fNa4qXRag9cCp5_HsefD7bxKe3ea2RPn8jnSs/edit?tab=t.k47ujuef4zxk#bookmark=id.hl0pbdvwfotd - Restrict domainNames to Admin tier only with CEL validation (Baseline tier breaks the NetworkPolicy override model) - Add CEL validation for Accept-only action restriction - Update API examples to v1alpha2 ClusterNetworkPolicy format - Add Expected Behavior points for DNS reachability and resolv.conf - Add Recommended Behavior section covering DNS security concerns, grace period, and DNSSEC best practice - Add Connection Lifecycle section for policy add/remove semantics
tssurya
force-pushed
the
fqdn-field-description-update
branch
from
b8a2a6c to
2af60be
Compare
k8s-ci-robot
removed
the
needs-rebase
3 participants
The PR updates the details around domainNames
as discussed in KubeCon Atlanta:
https://docs.google.com/document/d/1AtWQy2fNa4qXRag9cCp5_HsefD7bxKe3ea2RPn8jnSs/edit?tab=t.k47ujuef4zxk#bookmark=id.hl0pbdvwfotd
NOTE to reviewers:
*can mean one or more labels and that's what is present in current OKEP as well