Skip to content

Strict conditions in the code for adding a Service ClusterIP as a NetworkPeer #194

@vchintal

Description

@vchintal

The following is a question and should be treated as such

Policy enforcement in the code

  1. For the destination Service ClusterIP to be whitelisted by a NetworkPolicy the requirements is that the set of labels in the .spec.selector in the Service definition ALL match with the set of labels in the .spec.egress[].to[].podSelector.matchLabels (of the NetworkPolicy) (code)
  2. If the NetworkPolicy lists ports on which traffic is allowed, then in addition to the above requirement, the service Port must match with Container Port of the destination Pods. (code).
  3. The above item no. 2, also goes back to the last requirement for the NetworkPolicies. As an example, an UI pod can reach the Backend Pod on the containerPort: 8080 if the NetworkPolicy allows/opens up the traffic on port 8080. But this packet transit won’t happen via the Backend Service if the port defined in the Service spec accepts traffic at port 80.

Can an alternate approach be used here?

Is the approach presented below possible? I can easily sense that the below logic, using pods, that can come in and go during scaling, may not be an ideal approach. But nevertheless, I am curious and request validation.

  1. Find all the pods that the NetworkPolicy could potentially target using the selectors - Let’s call the list X
  2. Find all the pods that the Service targets - Let’s call this list Y
  3. Whitelist the Service ClusterIP if X ⊆ Y
Image Image

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions