IBM / network-config-analyzer

A semantic analyzer for resources that configure network connectivity (e.g., Kubernetes NetworkPolicy).
Apache License 2.0
17 stars 11 forks source link

Lazy evaluation of policies' allowed connections #496

Closed zivnevo closed 3 weeks ago

zivnevo commented 1 year ago

In the new optimized evaluation of allowed connections, a lot of work is done in preprocessing, that is, when building network configs. This may increase runtime for certain queries, which do not rely on allowed connections (e.g., allCaptured, disjointness). Moreover, if a network-config is defined but not used, we pay the price for preprocessing its policies.

Suggestions:

tanyaveksler commented 1 year ago

Regarding bullet#2 and bullet#3 above (https://github.com/IBM/network-config-analyzer/issues/496#:~:text=In%20the%20NetworkPolicy,are%20actually%20required): their implementation must be consistent with https://github.com/IBM/network-config-analyzer/issues/485: Initially, during the parsing of network policies, the full domain of peers is set to its default (assuming maximum 10000 number of pods). Later, during queries run, the full domain of peers is updated to all peers in the current config (whose number is necessarily smaller than 10000). Therefore, if we want to make lazy policy parsing (including calculation of optimized_allow_ingress_props, optimized_deny_ingress_props, etc) and lazy evaluation of policy allowed connections, we should make these lazy calculations while peers domains are set to their default (up to 10000 pods), and then the result of these calculations may be stored and reused by all queries. In order to use these stored connections by some query, we should first reduce them according to that query context (i.e., setting peers domains in DimensionsManager to union of all peers from the configs of the query and running _reduce_active_dimensions for the connections that we need for that query).

zivnevo commented 3 weeks ago

Moved to NP-Guard repo. See here