-
Epic
-
Resolution: Done
-
Normal
-
None
-
None
User Problem
As a developer/DevOps using ACS build time tools ( netpol connectivity) I want to understand exactly which pieces of YAML code in my network policy are responsible for -
- allowing a certain connection
- not allowing a connection that I expect to be open
so that I can find mistakes and fix them faster during my network policy development effort.
A couple of common mistakes for why a connection is not allowed:
- I have a tight connection (e.g. selected for a specific source/target deployment) where the egress is allowed but ingress is denied (or vice versa)
- both sides allow a connection but (due to a typo) they open different ports/protocols
See also NP-Guard integration roadmap
Definition of Done:
- logic implemented and merged into roxctl by IBM team
- Tests prepared and successfully passed by IBM team
- Documentation is updated by IBM team, working with doc team
- PR approved by ACS team
Explainability vs exposure analysis:
Explainability can provide more details of the analysis, beyond the final connection result. For example, instead of just providing the info that a permitted connection from a to b is tcp 80 , it adds details which policies allow which connection on ingress from a to be, which policies allow which connections on egress, etc..
Explainability is more for the debugging use case, where you want to gain insights of your policy rules, which affect on each side of the connection, and where the computation of the final permitted connection comes from.
(Exposure analysis description is at https://issues.redhat.com/browse/ROX-24429 )
See this slide deck for a walkthrough of the implemented feature
- is cloned by
-
ROX-25007 better DNS support for build time netpol generation (np-guard)
-
- Release Pending
-