[ENHANCEMENT] Service != backend pods?

[npinaeva]

Is your enhancement request related to a problem? Please describe.
Services can't be used in (B)ANP allow rules. Current idea of (B)ANP being applied after the service IP is resolved makes CIDR-based matching strange for service CIDR.

Describe the solution you'd like
A separate way to select services, that will potentially work (not necessarily recommended though) with CIDR selectors.

Describe alternatives you've considered
An alternative is to leave current behaviour where service can only be matched after backend resolution.

Additional context
Currently, to allow a service, we specify service pod selector. This has the following consequences:

• if service selector ever changes, network policy also needs to be updated
• confusing semantics: if I want to allow a pod, every service that is resolved to the same pod will be allowed. If a service has multiple endpoints, and not all of them are allowed it will look like failing service connection attempts
• if a service is provided by another namespace (non-admin use case), user may not even know the selector, just service namespace+name/ip/FQDN
• service port and backend ports oftentimes differ. Customers struggle to understand why they need to use pod ports and not service port that they actually curl from their namespace.
• difficulties with defining CIDR-based policies (svc ip will never be matched)
• consider a service that has lot of endpoints, network policy doesn’t guarantee all of the endpoint will be allowed at the same time (as it thinks in pod terms, not service terms). This may end up with some svc endpoints being allowed and other denied.

What can we do? Add services!

• Add service type (it can be selected by labels of namespace+name) to network policy and CHANGE BEHAVIOUR:
• match service by IP BEFORE it is resolved to the backend pod IP
• direct pod connection will only be allowed if network policy explicitly selects this pod
• service connection won’t work by endpoint pod selector, only by explicit service selector
• bonus: egress CIDR matching may be done immediately when the traffic leave the pod, and svc IP will work same as any other ip

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale