Helm: admit read-only harness MCP clients#19
Conversation
Allow the sie-gw-cfg Synty endpoint to accept callers only when both the sie-harness namespace and MCP-client pod label match. Helm rendering confirms the new peer remains constrained by 2 selectors.
📝 WalkthroughWalkthroughThe Helm network policy now requires MCP client pods to have the required label and belong to the ChangesMCP ingress restriction
Suggested reviewers: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 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 `@deploy/helm/synty/values-sie-gw-cfg.yaml`:
- Around line 49-54: Replace the original same-namespace labeled-pod peer in
deploy/helm/synty/values-sie-gw-cfg.yaml lines 49-54 with the sie-harness
namespaceSelector so ingress is limited exclusively to labeled harness pods.
Update README.md lines 270-272 to document the harness-only admission behavior.
🪄 Autofix (Beta)
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: bdec2be3-c66a-4469-9af6-b589fd0520c9
📒 Files selected for processing (2)
README.mddeploy/helm/synty/values-sie-gw-cfg.yaml
| - namespaceSelector: | ||
| matchLabels: | ||
| kubernetes.io/metadata.name: sie-harness | ||
| podSelector: | ||
| matchLabels: | ||
| synty.superlinked.com/mcp-client: "true" |
There was a problem hiding this comment.
🔒 Security & Privacy | 🟠 Major | ⚡ Quick win
The policy remains broader than a harness-only ingress restriction.
The existing same-namespace labeled-pod peer is still ORed with the new sie-harness peer. Remove the original peer if the service must accept traffic exclusively from labeled sie-harness pods, then update the README accordingly.
deploy/helm/synty/values-sie-gw-cfg.yaml#L49-L54: replace the existing same-namespace peer instead of adding a second peer.README.md#L270-L272: document harness-only admission after the policy is narrowed.
📍 Affects 2 files
deploy/helm/synty/values-sie-gw-cfg.yaml#L49-L54(this comment)README.md#L270-L272
🤖 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 `@deploy/helm/synty/values-sie-gw-cfg.yaml` around lines 49 - 54, Replace the
original same-namespace labeled-pod peer in
deploy/helm/synty/values-sie-gw-cfg.yaml lines 49-54 with the sie-harness
namespaceSelector so ingress is limited exclusively to labeled harness pods.
Update README.md lines 270-272 to document the harness-only admission behavior.
What
Allow the sie-harness namespace to reach the private Synty MCP service only when pods also carry the existing synty.superlinked.com/mcp-client: true label.
Why
Kubernetes pod selectors without a namespace selector only match the policy namespace. The local harness deployment runs separately, so its labeled probe was still denied.
Verification
Summary by CodeRabbit
Documentation
Configuration