Policy engine with new api func for exposure analysis

[shireenf-ibm]

issue #236

sub task :

• adding new api func for policy-engine for running exposure-analysis individually(info)

PR's tasks :

• adding new api func to the policy-engine; so all pre-process (and storing general conns for pods) will be computed only for exposure-analysis. (3917237)

• in case of exposure-analysis; updating some computation that can benefit from the stored data of the policy (a8474e2) and (e5a5270)

• tested locally with desired results

[adisos]

do we have a planned item to avoid re-iterating the netpols here at SetExposureAnalysisResources, and add the representative peers while adding policies? if so add a todo here as well

[shireenf-ibm]

yes we do :

• • optimize fake-pods generations
    - first add fake pods for all non-empty rules while policies upsert
    - refine pods that has a match in the resources

added TODO

[adisos]

I don't think this initialization has much value for being more efficient here... as the current implementation iterates the rules anyway... I don't see how it helps?

I thought we could avoid iterating the rules, in cases where we know the policy allows all connections for all targets (either cluster-internal or also external).

[shireenf-ibm]

• I see; yes the initialization may just save the computation of rule connections np.ruleConnections(rulePorts, dst) for the general rules (as it was already stored while pre-proccessing);
  so should revert the commits of

in case of exposure-analysis; updating some computation that can benefit from the stored data of the policy (a8474e2) and (e5a5270)
?

• i think the only policies that we can avoid iterating their rules are the policies with "general" rules only;
  a specified rule might always has "extra" value to a specific connection between two peers; unless we check if the specific rules conns are contained in general conns while pre-process; is this desired?

[adisos]

what do you mean by policies with "general" rules only?

a specified rule might always has "extra" value to a specific connection between two peers

how if we avoid iterating only for "all connections" allowed for all targets ?

[adisos]

the initialization may just save the computation of rule connections

This does not save much, so I would remove that to simplify the code

[shireenf-ibm]

what do you mean by policies with "general" rules only?

I mean policies that the only rules that they contain are either "empty from/to " - which means all targets
or its only from/to rules are with : namespaceSelector: {}; i.e. the policies that their conns are stored for sure

a specified rule might always has "extra" value to a specific connection between two peers

how if we avoid iterating only for "all connections" allowed for all targets ?

we can avoid iterating policies above (in this comment) and not only for all connections;
we might have a policy for all destinations with specific ports .. and this connection already stored

[shireenf-ibm]

I think we have 2 cases:
1- policies that include only "general" rules, for example:

egress:
  - to:
    - namespaceSelector: {}
    ports:
        - port: 8000
 ingress:
    - ports:
           - port: 8090
// which is egress to entire cluster on TCP 8000
// and ingress from whole world on TCP 8090

for this policy; both "general" connections are stored on pre-process
I can save also a new variable for the policy that indicates that there are only general (no other) rules in the policy;
and then avoid iterating it when computing connections between two peers
but is this a common use-case? should apply this?

2. when the policy has mix of general and more specified rules (with non-empty namespaceSelector/ podSelector)
   in this case we need to check rules' connections containment in order to avoid iterating later (complex approach)

[adisos]

I don't see why we need to differentiate between these cases.. if we have mixed rules, we can avoid iterating the rules if we identified in the pre-prcoessing that there was a rule enabling all connections to the entire cluster..

[shireenf-ibm]

uh, yes when the "general" connection is "All Connections" ; there is no need to iterate; (committed changes)

I was speaking on the case where the general stored connections are not "All Connections" .. trying to think how to benefit in such cases from stored data (however this will complicate the code, if desired may consider in another issue)

[adisos]

right, maybe just add a comment in the code

[shireenf-ibm]

done