Chore/k8s network policy demo #2857
No reviewers
Labels
No labels
1week
2weeks
Failed compliance check
IP cameras
NATS
Possible security concern
Review effort 1/5
Review effort 2/5
Review effort 3/5
Review effort 4/5
Review effort 5/5
UI
aardvark
accessibility
amd64
api
arm64
auth
back-end
bgp
blog
bug
build
checkers
ci-cd
cleanup
cnpg
codex
core
dependencies
device-management
documentation
duplicate
dusk
ebpf
enhancement
eta 1d
eta 1hr
eta 3d
eta 3hr
feature
fieldsurvey
github_actions
go
good first issue
help wanted
invalid
javascript
k8s
log-collector
mapper
mtr
needs-triage
netflow
network-sweep
observability
oracle
otel
plug-in
proton
python
question
reddit
redhat
research
rperf
rperf-checker
rust
sdk
security
serviceradar-agent
serviceradar-agent-gateway
serviceradar-web
serviceradar-web-ng
siem
snmp
sysmon
topology
ubiquiti
wasm
wontfix
zen-engine
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
carverauto/serviceradar!2857
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "refs/pull/2857/head"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Imported from GitHub pull request.
Original GitHub pull request: #2710
Original author: @mfreeman451
Original URL: https://github.com/carverauto/serviceradar/pull/2710
Original created: 2026-02-05T06:51:50Z
Original updated: 2026-02-05T06:54:28Z
Original head: carverauto/serviceradar:chore/k8s-network-policy-demo
Original base: staging
Original merged: 2026-02-05T06:53:59Z by @mfreeman451
User description
IMPORTANT: Please sign the Developer Certificate of Origin
Thank you for your contribution to ServiceRadar. Please note, when contributing, the developer must include
a DCO sign-off statement indicating the DCO acceptance in one commit message. Here
is an example DCO Signed-off-by line in a commit message:
Describe your changes
Issue ticket number and link
Code checklist before requesting a review
PR Type
Enhancement
Description
Add optional Kubernetes NetworkPolicy for egress controls with configurable allow lists
Add optional Calico NetworkPolicy for deny logging and enforcement
Enable network policies in demo values with sensible defaults
Document new networkPolicy Helm chart values and configuration options
Diagram Walkthrough
File Walkthrough
6 files
Document networkPolicy Helm configuration optionsDocument network policy change proposalDocument network policy design decisionsDefine kubernetes-network-policy requirementsTrack network policy implementation tasksArchive kubernetes-network-policy specification2 files
Add Kubernetes NetworkPolicy egress templateAdd Calico NetworkPolicy deny logging template2 files
Add networkPolicy configuration valuesEnable network policies in demo environmentImported GitHub PR comment.
Original author: @qodo-code-review[bot]
Original URL: https://github.com/carverauto/serviceradar/pull/2710#issuecomment-3851401082
Original created: 2026-02-05T06:52:30Z
PR Compliance Guide 🔍
Below is a summary of compliance checks for this PR:
No security concerns identified
No security vulnerabilities detected by AI analysis. Human verification advised for critical code.🎫 No ticket provided
Codebase context is not defined
Follow the guide to enable codebase context checks.
Generic: Comprehensive Audit Trails
Objective: To create a detailed and reliable record of critical system actions for security analysis
and compliance.
Status: Passed
Generic: Meaningful Naming and Self-Documenting Code
Objective: Ensure all identifiers clearly express their purpose and intent, making code
self-documenting
Status: Passed
Generic: Robust Error Handling and Edge Case Management
Objective: Ensure comprehensive error handling that provides meaningful context and graceful
degradation
Status: Passed
Generic: Secure Error Handling
Objective: To prevent the leakage of sensitive system information through error messages while
providing sufficient detail for internal debugging.
Status: Passed
Generic: Secure Logging Practices
Objective: To ensure logs are useful for debugging and auditing without exposing sensitive
information like PII, PHI, or cardholder data.
Status:
Deny logging exposure: The Calico policy enables
Logon denied egress which may emit potentially sensitivenetwork metadata (destinations/ports) depending on cluster logging configuration and
should be reviewed for data exposure and retention.
Referred Code
Generic: Security-First Input Validation and Data Handling
Objective: Ensure all data inputs are validated, sanitized, and handled securely to prevent
vulnerabilities
Status:
Unvalidated CIDR input: User-provided Helm values (e.g.,
networkPolicy.egress.allowedCIDRsand optionalnetworkPolicy.podSelector) are rendered without validation, so malformed or overly broadinputs could weaken egress restrictions or cause deploy-time failures.
Referred Code
Compliance status legend
🟢 - Fully Compliant🟡 - Partial Compliant
🔴 - Not Compliant
⚪ - Requires Further Human Verification
🏷️ - Compliance label
Imported GitHub PR comment.
Original author: @qodo-code-review[bot]
Original URL: https://github.com/carverauto/serviceradar/pull/2710#issuecomment-3851407005
Original created: 2026-02-05T06:54:28Z
PR Code Suggestions ✨
Explore these optional code suggestions:
Only render rules with real CIDRs
In the
egressrule condition, replace$allowKubeAPIwith$hasKubeAPICIDRstoprevent rendering an empty block if no API server CIDRs are found.
helm/serviceradar/templates/network-policy.yaml [45]
Suggestion importance[1-10]: 8
__
Why: This change correctly identifies and fixes a potential template rendering error where an empty
egressblock could be generated, leading to an invalid Kubernetes manifest.Consolidate duplicated Helm template logic
Refactor the duplicated logic for generating egress allow-lists from the new
Kubernetes and Calico network policy templates into a shared Helm helper
template. This will improve maintainability and reduce the risk of future
inconsistencies.
Examples:
helm/serviceradar/templates/calico-network-policy.yaml [11-26]
helm/serviceradar/templates/network-policy.yaml [10-25]
Solution Walkthrough:
Before:
After:
Suggestion importance[1-10]: 7
__
Why: The suggestion correctly identifies significant code duplication in the Helm templating logic for Kube API server discovery between the new
calico-network-policy.yamlandnetwork-policy.yamlfiles, which improves long-term maintainability and reduces the risk of configuration drift.Guard Calico policy on networkPolicy.enabled
Ensure the Calico policy is only rendered when both
networkPolicy.enabledandnetworkPolicy.calicoLogDenied.enabledare true to avoid creating an orphanedpolicy.
helm/serviceradar/templates/calico-network-policy.yaml [1-3]
Suggestion importance[1-10]: 7
__
Why: The suggestion correctly prevents the Calico policy from being rendered when the main network policy feature is disabled, improving the chart's logical consistency.
Use a more robust selector
To allow egress to the same namespace, replace the
namespaceSelectorwith anempty
podSelector: {}, which selects all pods in the current namespace.helm/serviceradar/templates/network-policy.yaml [70-75]
Suggestion importance[1-10]: 2
__
Why: The suggestion's premise that the
kubernetes.io/metadata.namelabel is not guaranteed on namespaces is incorrect, making the proposed change a stylistic preference rather than a required robustness fix.