Conversation
Signed-off-by: Jim Fitzpatrick <jfitzpat@redhat.com>
📝 WalkthroughWalkthroughRFC 0022 proposes always-on, runtime-managed Kubernetes NetworkPolicies for Kuadrant. It defines ingress deny and component-specific allow policies, dynamic namespace reconciliation, RBAC, cache filtering, cleanup, port mappings, alternatives, and future extensions. ChangesNetwork Policy RFC
Estimated code review effort: 2 (Simple) | ~10 minutes Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 6
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@rfcs/0022-network-policy.md`:
- Line 6: Replace the placeholder pull request reference in the RFC PR link with
the actual Kuadrant/architecture PR number, preserving the existing link format.
- Around line 154-159: Update the gRPC extensions ingress rule for port 50051 to
restrict callers to the intended trusted pods by replacing the empty podSelector
with the appropriate identifying labels; if all pods in the operator namespace
are intentionally trusted, explicitly define and enforce that namespace as the
trusted boundary.
- Around line 483-485: Update the RFC’s Standard NetworkPolicy claims to remove
universal CNI support and state the supported CNI/OpenShift version matrix
consistently at both referenced sections. Add either an ingress-enforcement
integration test or an explicit deployment gate that rejects or flags clusters
whose CNI does not enforce NetworkPolicy.
- Around line 412-416: Update the Controller-Runtime Cache Filtering guidance to
require validating the expected owner reference, not just the
kuadrant.io/managed label. Ensure NetworkPolicy create/update logic rejects
conflicting owners, and cleanup only deletes objects whose owner reference
matches the operator, preventing same-name or same-label policies belonging to
another controller from being modified or removed.
- Around line 117-133: Qualify the deny-by-default guarantee for
kuadrant-deny-managed in the RFC: state that ingress remains deny-by-default
only when no other NetworkPolicy selects these pods with allowing rules, and
document the RBAC/trust assumptions for NetworkPolicy authors. Alternatively,
replace this policy with a non-overridable enforcement mechanism and describe
that baseline.
- Around line 92-100: The RFC’s allow-policy selectors must be constrained to
managed pods and created before managed labels are applied during upgrades.
Update every component allow selector to include kuadrant.io/managed: "true",
and order allow-policy creation ahead of applying that label while preserving
the deny-policy sequencing.
🪄 Autofix
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro Plus
Run ID: 62702395-df76-4830-9fb8-2fa35d2d5ee8
📒 Files selected for processing (1)
rfcs/0022-network-policy.md
| - Feature Name: `network-policy` | ||
| - Status: Draft | ||
| - Start Date: 2026-08-10 | ||
| - RFC PR: [Kuadrant/architecture#0000](https://github.com/Kuadrant/architecture/pull/0000) |
There was a problem hiding this comment.
📐 Maintainability & Code Quality | 🟡 Minor | ⚡ Quick win
Replace the placeholder RFC link.
Kuadrant/architecture#0000 is not a usable PR reference. Replace it with the real PR number before merge.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@rfcs/0022-network-policy.md` at line 6, Replace the placeholder pull request
reference in the RFC PR link with the actual Kuadrant/architecture PR number,
preserving the existing link format.
| On upgrade from a version without network policies to a version with them, the labeling must be in place before the deny policies take effect. | ||
| The upgrade path must ensure: | ||
|
|
||
| 1. **Labels are applied before deny policies are created.** The reconciler must label all existing component pods (or ensure the sub-operators roll out updated pod templates with the label) before creating deny NetworkPolicies. | ||
| If a deny policy is created before a pod is labeled, that pod will not be selected by the deny policy and will remain open — but more critically, it will also not be selected by any allow policy, so if the pod is later labeled it will immediately fall under deny-all with no allow rules if the allow policy uses a different selector. | ||
| 2. **Sub-operator pod template updates trigger rolling restarts.** Adding a label to a Deployment's pod template causes a rollout. | ||
| The operator should account for the temporary disruption during this rollout on upgrade. | ||
| 3. **Ordering within the reconciler.** The network policy workflow should run after the sub-operator reconciliation workflows that ensure labels are present, so that by the time deny policies are created, all pods are guaranteed to be labeled and matched by both deny and allow policies. | ||
|
|
There was a problem hiding this comment.
🔒 Security & Privacy | 🟠 Major | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -eu
file="rfcs/0022-network-policy.md"
printf '%s\n' '--- referenced sections ---'
sed -n '70,115p;135,160p;175,200p;198,220p;220,242p;242,264p;292,315p;335,360p' "$file"
printf '%s\n' '--- all podSelector blocks and policy names ---'
rg -n -A8 -B3 'podSelector:|kind: NetworkPolicy|name:|matchLabels:' "$file"Repository: Kuadrant/architecture
Length of output: 13341
🌐 Web query:
Kubernetes NetworkPolicy podSelector selects pods in the policy namespace ingress isolation additive allow rules official documentation
💡 Result:
In Kubernetes, the NetworkPolicy API handles ingress isolation and rule evaluation with specific behaviors regarding pod selectors and rule combination [1][2][3]. Scope of podSelector The spec.podSelector field in a NetworkPolicy determines which pods the policy applies to [2][4]. It is restricted to the namespace in which the NetworkPolicy is defined [1][5]. Similarly, when a podSelector is used within an ingress rule's from section without a namespaceSelector, it selects pods only within the policy's own namespace [1][2]. Ingress Isolation When a pod is selected by at least one NetworkPolicy with policyTypes including Ingress, it becomes isolated for ingress traffic [3]. Once isolated, the pod rejects all incoming traffic by default, unless that traffic is explicitly permitted by an ingress rule [2][3]. If no NetworkPolicies select a pod, that pod is non-isolated and accepts all ingress traffic [1][3]. Additive Allow Rules Ingress rules are additive [2][4]. If multiple NetworkPolicies select the same pod, the ingress rules from all those policies are combined [2][4]. Traffic is allowed if it matches at least one ingress rule across all active NetworkPolicies for that pod [2][3]. Combined Namespace and Pod Selectors When both namespaceSelector and podSelector are defined within a single ingress from entry, they act as an intersection (AND condition) [6]. This selects pods that match the podSelector label within the namespaces that match the namespaceSelector label [2][6][5]. If only one is provided, it selects all pods in the matched namespaces (if namespaceSelector is used) or pods in the policy's own namespace (if podSelector is used) [2].
Citations:
- 1: https://kubernetes.io/docs/concepts/services-networking/network-policies/
- 2: https://kubernetes.io/docs/reference/kubernetes-api/networking/network-policy-v1/
- 3: https://www.redhat.com/en/blog/guide-to-kubernetes-ingress-network-policies
- 4: https://github.com/kubernetes/kubernetes/blob/63b36867/pkg/apis/networking/types.go
- 5: https://docs.tigera.io/calico/latest/network-policy/get-started/kubernetes-policy/kubernetes-network-policy
- 6: https://github.com/ahmetb/kubernetes-network-policy-recipes/blob/master/07-allow-traffic-from-some-pods-in-another-namespace.md
Constrain every allow policy to managed pods.
Each allow policy selects pods by app only, while the deny policy selects kuadrant.io/managed: "true". A pod without the managed label but with a matching app label can therefore be isolated and receive these ingress rules. Add kuadrant.io/managed: "true" to every component allow selector. Create the allow policies before applying the managed label during upgrade.
🧰 Tools
🪛 LanguageTool
[grammar] ~92-~92: The verb ‘deny’ does not usually follow articles like ‘the’. Check that ‘deny’ is spelled correctly; using ‘deny’ as a noun may be non-standard.
Context: ...m, the labeling must be in place before the deny policies take effect. The upgrade path ...
(A_INFINITIVE)
[typographical] ~96-~96: It seems that a comma is missing.
Context: ...ny allow policy, so if the pod is later labeled it will immediately fall under deny-all...
(IF_COMMA)
[uncategorized] ~98-~98: The preposition ‘of’ seems more likely in this position.
Context: ...emporary disruption during this rollout on upgrade. 3. **Ordering within the recon...
(AI_HYDRA_LEO_REPLACE_ON_OF)
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@rfcs/0022-network-policy.md` around lines 92 - 100, The RFC’s allow-policy
selectors must be constrained to managed pods and created before managed labels
are applied during upgrades. Update every component allow selector to include
kuadrant.io/managed: "true", and order allow-policy creation ahead of applying
that label while preserving the deny-policy sequencing.
| **`kuadrant-deny-managed`** — Deny all ingress to Kuadrant-managed pods in the operator namespace. | ||
|
|
||
| ```yaml | ||
| apiVersion: networking.k8s.io/v1 | ||
| kind: NetworkPolicy | ||
| metadata: | ||
| name: kuadrant-deny-managed | ||
| namespace: <operator-namespace> | ||
| labels: | ||
| kuadrant.io/managed: "true" | ||
| spec: | ||
| podSelector: | ||
| matchLabels: | ||
| kuadrant.io/managed: "true" | ||
| policyTypes: | ||
| - Ingress | ||
| ``` |
There was a problem hiding this comment.
🔒 Security & Privacy | 🟠 Major | 🏗️ Heavy lift
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
printf '%s\n' '--- RFC context ---'
sed -n '90,155p' rfcs/0022-network-policy.md
printf '%s\n' '--- NetworkPolicy references in RFC ---'
rg -n -C 3 'NetworkPolicy|deny|allow|managed|operator namespace|RBAC|enforcement' rfcs/0022-network-policy.md
printf '%s\n' '--- Relevant repository policy and RBAC files ---'
git ls-files | rg -i '(^|/)(network.?polic|rbac|role|clusterrole|rolebinding|clusterrolebinding|gateway|watch)' | head -200Repository: Kuadrant/architecture
Length of output: 25447
🏁 Script executed:
#!/bin/bash
set -euo pipefail
printf '%s\n' '--- RBAC and lifecycle sections ---'
sed -n '390,457p' rfcs/0022-network-policy.md
printf '%s\n' '--- All policy-authority and guarantee statements ---'
rg -n -i -C 2 'ClusterRole|RoleBinding|NetworkPolicy authors|author|trust|deny-by-default|always-on|universally supported|unrelated|external|user-configurable|cleanup|ownership' rfcs/0022-network-policy.mdRepository: Kuadrant/architecture
Length of output: 15893
Qualify the deny-by-default guarantee.
NetworkPolicy ingress rules are additive. Any other policy that selects these pods can allow traffic despite kuadrant-deny-managed. State the RBAC and trust assumptions for all NetworkPolicy authors, or use an enforcement layer with a non-overridable baseline.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@rfcs/0022-network-policy.md` around lines 117 - 133, Qualify the
deny-by-default guarantee for kuadrant-deny-managed in the RFC: state that
ingress remains deny-by-default only when no other NetworkPolicy selects these
pods with allowing rules, and document the RBAC/trust assumptions for
NetworkPolicy authors. Alternatively, replace this policy with a non-overridable
enforcement mechanism and describe that baseline.
| ## Controller-Runtime Cache Filtering | ||
|
|
||
| All managed NetworkPolicies carry the label `kuadrant.io/managed: "true"`. | ||
| The controller-runtime cache for `networking.k8s.io/v1/NetworkPolicy` is configured with a label selector matching this label. | ||
| This ensures the operator only watches and caches NetworkPolicies it owns, avoiding unnecessary load from other NetworkPolicies in the cluster. |
There was a problem hiding this comment.
🗄️ Data Integrity & Integration | 🟠 Major | 🏗️ Heavy lift
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -eu
printf '%s\n' '--- target section ---'
sed -n '380,455p' rfcs/0022-network-policy.md
printf '%s\n' '--- ownership and label references ---'
rg -n -C 3 'managed:|owner|ownership|cleanup|NetworkPolicy|cache|label selector' rfcs/0022-network-policy.md
printf '%s\n' '--- repository references to the managed label and policy cleanup ---'
rg -n -C 2 'kuadrant\.io/managed|NetworkPolicy.*(delete|cleanup)|cleanup.*NetworkPolicy|LabelSelector|ownerReferences' . --glob '!rfcs/0022-network-policy.md' || trueRepository: Kuadrant/architecture
Length of output: 21015
🏁 Script executed:
#!/bin/bash
set -eu
printf '%s\n' '--- RFC 0019 ownership model ---'
fd -i '0019' . --type f -x sh -c 'wc -l "$1"; rg -n -C 4 "owner|ownership|ownerReferences|adopt|conflict|cleanup" "$1"' sh {} \;
printf '%s\n' '--- all ownership-related text in RFC 0022 ---'
rg -n -C 5 'Owned by|owner reference|ownerReferences|owner UID|adopt|conflict|Remove any NetworkPolicy|desired set' rfcs/0022-network-policy.md
printf '%s\n' '--- policy names and metadata in the RFC ---'
sed -n '111,370p' rfcs/0022-network-policy.md | rg -n -C 5 'metadata:|name:|namespace:|labels:|managed:'Repository: Kuadrant/architecture
Length of output: 21031
🌐 Web query:
Kubernetes official documentation labels are not ownership ownerReferences garbage collection controller adoption conflicting owner reference
💡 Result:
In Kubernetes, labels and ownerReferences serve distinct purposes, and confusion between them often arises from how controllers manage resources [1][2]. Labels are key-value pairs used for organizational grouping and selecting subsets of objects (e.g., matching a Service to Pods via a selector) [3][2]. They are loose, user-defined, and do not convey system-level ownership or lifecycle dependencies [3][2]. OwnerReferences, conversely, are the mechanism by which Kubernetes implements garbage collection [4]. They explicitly define a parent-child relationship between objects [4][5]. When an owner object is deleted, the garbage collector uses these references to automatically clean up dependent objects (cascading deletion) [4][5]. Regarding your specific areas of concern: Controller Adoption and Ownership Controllers (such as ReplicaSets) use label selectors to discover existing orphaned resources that match their criteria [6][1]. Once a controller identifies a candidate resource (e.g., a Pod), it "adopts" it by adding an ownerReference to that object, pointing to the controller itself [6][7]. This official link then enables the garbage collector to manage the resource's lifecycle [4][6]. Conflicting Owner References and Garbage Collection An object can technically have multiple ownerReferences, but only one can be marked as the "controller" [7]. If a controller attempts to set itself as the controller of an object that is already managed by another controller, a conflict occurs [7]. Libraries like controller-runtime provide utilities (e.g., SetControllerReference) to manage these references safely, returning errors if an object is already controlled by a different entity [7]. If ownerReferences contain invalid or conflicting data, such as cross-namespace references (which are disallowed) or missing UID references, the garbage collector may report errors [4][8]. Since Kubernetes 1.20+, the system has improved handling for invalid references—often emitting an OwnerRefInvalidNamespace event—to prevent non-deterministic behavior during garbage collection [4][8]. In summary, labels provide the initial discovery mechanism for controllers, while ownerReferences formalize the lifecycle dependency and enable automated garbage collection [6][1][2]. Conflicts typically arise when multiple controllers attempt to manage the same object or when manual manipulation of ownerReferences creates invalid, dangling, or circular dependencies [6][8][7].
Citations:
- 1: Clarification over the use of metadata.ownerReferences Vs pod labels for link between Replica controller and Pods kubernetes/website#22022
- 2: https://github.com/kubernetes/community/blob/main/contributors/devel/sig-architecture/api-conventions.md
- 3: https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/
- 4: https://kubernetes.io/docs/concepts/architecture/garbage-collection/
- 5: https://kubernetes.io/docs/concepts/overview/working-with-objects/owners-dependents/
- 6: https://github.com/kubernetes/design-proposals-archive/blob/main/api-machinery/garbage-collection.md
- 7: https://github.com/kubernetes-sigs/controller-runtime/blob/main/pkg/controller/controllerutil/controllerutil.go
- 8: Fix GC uid races and handling of conflicting ownerReferences kubernetes/kubernetes#92743
Restrict cache, updates, and cleanup to owned NetworkPolicy objects.
kuadrant.io/managed: "true" is only a label selector. It does not establish ownership, so the cache can include another controller’s policy and the label-only cleanup at lines 435–437 can delete it. Create or update logic can also modify a conflicting policy with the same name. Validate the expected owner reference, reject conflicting owners, and apply the ownership check during cleanup.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@rfcs/0022-network-policy.md` around lines 412 - 416, Update the
Controller-Runtime Cache Filtering guidance to require validating the expected
owner reference, not just the kuadrant.io/managed label. Ensure NetworkPolicy
create/update logic rejects conflicting owners, and cleanup only deletes objects
whose owner reference matches the operator, preventing same-name or same-label
policies belonging to another controller from being modified or removed.
| - **Runtime management** gives a single code path for both operator and operand policies, avoids OLM compatibility issues, and can react to dynamic state (Gateway namespaces, Kuadrant CR placement). | ||
| - **Standard NetworkPolicy** is GA, universally supported by all CNI plugins, and does not require elevated cluster-scoped RBAC beyond what the operator already has. | ||
| - **Ingress-only deny** provides meaningful security improvement while avoiding the complexity explosion of egress restrictions. |
There was a problem hiding this comment.
🔒 Security & Privacy | 🟠 Major | 🏗️ Heavy lift
🧩 Analysis chain
🏁 Script executed:
sed -n '450,555p' rfcs/0022-network-policy.mdRepository: Kuadrant/architecture
Length of output: 8051
🌐 Web query:
Kubernetes NetworkPolicy enforcement requires a network plugin that supports NetworkPolicy official documentation
💡 Result:
To enforce NetworkPolicies in a Kubernetes cluster, you must use a networking solution (specifically a Container Network Interface or CNI plugin) that supports NetworkPolicy enforcement [1][2]. Creating a NetworkPolicy resource via the Kubernetes API has no effect unless the cluster's network plugin is capable of implementing it [1]. Because NetworkPolicy enforcement is handled by the network plugin rather than the Kubernetes core itself, isolation rules are applied based on the plugin's implementation [1]. Key points regarding this requirement include: - Implementation: Network policies are implemented by the chosen networking solution [1]. If no network plugin is configured to enforce them, network policies will not be applied [3]. - Plugin Selection: Common network providers that support NetworkPolicy include Antrea, Calico, Cilium, Kube-router, Romana, and Weave Net [2]. Many cloud-managed Kubernetes services (such as GKE, Amazon EKS, and Azure Kubernetes Service) also provide their own managed plugins or supported integrations to handle these policies [3][4][5]. - Pod Lifecycle: Once a NetworkPolicy is handled by the network plugin, the plugin ensures that filtering is effective throughout a Pod's lifecycle, starting from the moment any container in the Pod is initialized [1]. - API Behavior: While the Kubernetes API will accept and store NetworkPolicy objects, there is no inherent indicator in the API itself to confirm when a specific plugin has finished processing or applying a policy to the cluster [1]. If you are planning to use NetworkPolicies, ensure that your cluster's networking configuration is explicitly set up to support them, as this is often an opt-in or plugin-specific feature [2][3][4].
Citations:
- 1: https://kubernetes.io/docs/concepts/services-networking/network-policies/
- 2: https://kubernetes.io/docs/tasks/administer-cluster/declare-network-policy/
- 3: https://docs.cloud.google.com/kubernetes-engine/docs/how-to/network-policy
- 4: https://docs.aws.amazon.com/eks/latest/userguide/cni-network-policy.html
- 5: https://learn.microsoft.com/en-us/azure/aks/use-network-policies
🏁 Script executed:
#!/bin/bash
set -eu
printf '%s\n' '--- repository references ---'
rg -n -i --glob '!vendor/**' --glob '!node_modules/**' \
'CNI|OpenShift|networkpolic|NetworkPolicy|integration test|status condition' . \
| head -n 240
printf '%s\n' '--- candidate documentation and test files ---'
git ls-files | rg -i '(^|/)(readme|support|compat|test|e2e|integration|deploy|config|docs?)([^/]*|/.*)$|openshift|network.?polic'Repository: Kuadrant/architecture
Length of output: 21611
🏁 Script executed:
#!/bin/bash
set -eu
python3 - <<'PY'
from pathlib import Path
import re
path = Path("rfcs/0022-network-policy.md")
text = path.read_text()
lines = text.splitlines()
claims = {
"universal CNI claim": re.compile(r"universally supported by all CNI plugins"),
"GA claim": re.compile(r"Standard NetworkPolicy.*GA"),
"always-on claim": re.compile(r"Always-on ensures every deployment"),
"test/status references": re.compile(r"test|status|condition|enforce", re.I),
}
for name, pattern in claims.items():
matches = [(i + 1, line) for i, line in enumerate(lines) if pattern.search(line)]
print(f"--- {name} ---")
for number, line in matches:
print(f"{number}: {line}")
PYRepository: Kuadrant/architecture
Length of output: 1136
Remove the universal CNI support claim.
The networking.k8s.io/v1 API is GA, but enforcement depends on the CNI plugin. An unsupported plugin accepts the resource without enforcing it. Replace the claims at lines 484 and 535–537 with the supported CNI and OpenShift version matrix. Add an ingress-enforcement integration test or an explicit gate for clusters without enforcement. (kubernetes.io)
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@rfcs/0022-network-policy.md` around lines 483 - 485, Update the RFC’s
Standard NetworkPolicy claims to remove universal CNI support and state the
supported CNI/OpenShift version matrix consistently at both referenced sections.
Add either an ingress-enforcement integration test or an explicit deployment
gate that rejects or flags clusters whose CNI does not enforce NetworkPolicy.
maleck13
left a comment
maleck13
left a comment
There was a problem hiding this comment.
Generally this looks good.
Main concern was around whose responsibility it is to create the network policy. Normally it would be the job of the operator responsible for the operand. That said as the kuadrant operator has the view of the gateways and also has a view of the ports (due to the DAG) it has all the info needed and so doing this in one place rather than individually doing it in each operator makes sense especially as the deployment model supported is via the Kuadrant operator rather than individual operators.
The other concern is around the generic label kuadrant.io/managed: true, This may require additional work, if we have a view of the podTemplate via the deployments, we could dynamically figure out what label to use based on those available favouring the managed: true label? Not against the approach just thinking if there are existing labels we could use.
Finally for MCP Gateway, its objects are not in the DAG so we will need to create and manage those in the controller . I have linked a related issue
| port: 8080 | ||
| policyTypes: | ||
| - Ingress | ||
| ``` |
There was a problem hiding this comment.
These 3 are the same bar the label selector any reason not to just add app: dns-operator for example and name the policy kuadrant-controlplane-metrics? That said if we want individual ones, I don't have a strong reason not to
There was a problem hiding this comment.
I did think about this, but the ports can be configured per deployment. Also having the configurations separate allows us to make use of the ownerReference. If the deployment for the dns-operator is remove k8s also removes the network policy related to it.
|
|
||
| NetworkPolicies use Kubernetes owner references for lifecycle management: | ||
|
|
||
| - **Operator namespace policies**: Owned by the kuadrant-operator Deployment. |
There was a problem hiding this comment.
poss worth looking at @mikenairn RFC that introduces a KuadrantControlPlane CR
There was a problem hiding this comment.
I had a look over https://github.com/Kuadrant/architecture/blob/main/rfcs/0019-olmv1-operator-consolidation.md and I did see anything in it with would conflict with what we are planning. Is there any sections that you are concerned over.
| This labeling work must be completed across all sub-operators before network policies are effective. | ||
| - **No egress restrictions** means a compromised pod can still make outbound connections to arbitrary destinations. | ||
| This is an accepted trade-off for the significant reduction in implementation complexity. | ||
| - **Pod selector labels** (`app: kuadrant-operator`, `app: authorino`, etc.) must match the actual labels on component deployments. |
There was a problem hiding this comment.
If the kuadrant operator has the deployment and service in the DAG, it could ensure that the policy it is creating uses an existing label rather than relying on a new one?
There was a problem hiding this comment.
yes we can do something like that. It would have being not to need to.
2 participants
Summary
Introduces RFC 0022, which proposes runtime-managed Kubernetes NetworkPolicy resources for ingress-only network isolation across all Kuadrant components.
The kuadrant-operator will dynamically create and manage standard
networking.k8s.io/v1NetworkPolicy objects to establish a deny-by-default ingress posture with explicit allow rules for known traffic patterns (metrics scraping, gRPC, wasm-shim serving, OIDC discovery, and console plugin access). This is an always-on feature requiring no user configuration.Motivation
Today all Kuadrant pods accept ingress traffic from any source in the cluster with no defense-in-depth at the network layer. This RFC closes that gap by defining a label-scoped deny model that avoids disrupting non-Kuadrant workloads sharing the same namespaces.
Design Highlights
kuadrant.io/managed: "true", leaving other workloads in shared namespaces unaffectednetworking.k8s.io/v1API, supported by all CNI plugins, avoiding the alpha AdminNetworkPolicy and its OVN-Kubernetes requirementSummary by CodeRabbit