Skip to content

NetworkPolicy: restrict :8443 ingress to the controller SA #265

@bdchatham

Description

@bdchatham

Problem

Surfaced by security cross-review on the TLS-removal refactor. With kube-rbac-proxy running in --insecure-listen-address (HTTP) and SAR-based authz as the trust boundary, the controller→sidecar bearer token traverses the cluster network in clear text. Authz still works, but the threat model now leans entirely on "no packet-capture-capable workload in the cluster" and "no untrusted workload can reach :8443 on a SeiNode pod."

A per-SeiNode NetworkPolicy restricting ingress on :8443 to the controller's pod labels closes the second leg of that assumption.

Proposed scope

  • Generate a NetworkPolicy per SeiNode (or a shared one keyed on the SeiNode-owned pod labels) selecting pods with sei.io/node label
  • policyTypes: [Ingress], single rule allowing from.podSelector matching the controller manager pod (or from.namespaceSelector for the controller namespace)
  • Owner-ref'd to the SeiNode so it GCs cleanly

Why deferred from refactor/seinode-drop-sidecar-tls

The refactor establishes the new trust model; NetworkPolicy hardens it. Decoupling lets the refactor land cleanly with the threat model documented, while the hardening lands in a focused PR with its own test coverage.

References

  • refactor/seinode-drop-sidecar-tls (commits 2076a80..c51075b)
  • internal/noderesource/noderesource.go buildRBACProxyContainer--insecure-listen-address
  • internal/sidecartransport/sidecartransport.go — bearer-token injection

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions