Exposure analysis

[adisos]

Consider enhancement of the connectivity analysis:
A "what-if" analysis, to report if an analyzed workload is exposed (ingress of egress) to workloads which are not included in the input manifests.

[adisos]

More details:

Possible situations, which may not be reflected on the current connectivity report (since such connections may only be possible with peer workloads that do not exists on the input dir of the analyzed workload manifests):

• Pod is exposed to entire cluster (both ingress and egress) – not protected by netpols
• Pod is exposed to cluster only on ingress / egress (protected only on one direction by netpols)
• exposure to entire namespace (one or more, also potentials)
• Pod is exposed to potential specific namespaces / specific pods (which may exist or not on the cluster, but do not exist on the analyzed workload manifests)

How to provide/add this information in a connectivity report / graph?
(Currently, the concept of a “connection” between workloads in the report is defined only for workloads that exist on the input dir, and for which both source is allowed by netpols to egress to destination, and destination is allowed by netpols to ingress from source).

[zivnevo]

The analysis provided by ACS only includes the first two bullets + indicating pods that are externally exposed.

[shireenf-ibm]

work plan:

• initial computing of exposure analysis - (basic exposure cases - entire class + rules with namespaceSelector)

  • • define new interface ExposedPeer and change the connlist API more info(wip - defining an interface for exposure-analysis results #295)
  • • code implementations in connlist: compute (separate) exposure-analysis results in getConnectionsBetweenPeers into the new returned value (connlist implementing exposure analysis #296)
  • • revert changes to connlist API funcs, add new func to get the []ExposedPeer
      Also, do not change types for existing APIs (Revert api changes #298)
  • • add connlist exposure_analysis_test.go , unit-tests for functionality of connlist\exposure_analysis.go (Exposure analysis unit tests #299)
  • • save on the fly - if a peer is exposed to entire cluster and the largest connection-set the allows such connectivity, and remove fake pod for "any namespace" more info and here (Entire cluster exposure opt #304)
  • • optimize policy pre-processing : store data on policy's general conns (to whole world/ entire cluster)more info(pre proccessing policy for general conns #306)
  • • adding new api func for policy-engine for running exposure-analysis individually(info)(Policy engine with new api func for exposure analysis  #307 )
  • • implement RepresentativePeer interface/struct (adding representativePeer struct #309)
  • • optimize fake-pods generations (Optimize representative peers generation  #314)
      • first add fake pods for all non-empty rules while policies upsert
      • refine pods that has a match in the resources
  • • basic tests for exposure analysis results (exposure analysis test #316)
  • • [ ]optimize exposure connections refinement in connlist pkg more info (was added on functionality that does not exist anymore)
  • • consider not returning an internal interface in the exposed result more info

• adding flag --exposure to turn on this feature only when needed

• adding exposure analysis results in textual output (textual output with exposure analysis #331)

• adding exposure analysis results in graphical output(dot output with exposure results #333 )

• expanding the exposure analysis to rules with PodSelector (exposure analysis with pod selectors #343)

  • • handling cases of empty nsSelector (any-namespace) with non-empty podSelector : don't refine its representative peer if there is a matching pod in a specific namespace(don't remove representative peers in any-namespace #352)

• handling cases of labels containment with same conns (more info)

• support running exposure analysis with focus-workload which is in-cluster (+adding tests)(exposure analysis with focus-workload #349)

• add docs explaining the new feature (Add exposure analysis documentation #391)

• adding more complicated tests

• support all output formats of connnlist with exposure analysis (supporting csv, md and json formats #360)

• support selectors with matchExpression (all operators)(handling selectors with matchexpressions (fixed) #377)

  • • in representative_selectors.go, func SelectorsFullMatch decide whether to accept an empty rule as a full-match with non-empty representative-peer's selectors or not (currently is considered as full-match)

• add support for considering policies that capture representative peers (consider for each generated representative peer to keep a reference to the policies that capture it)(more info)

• output enhancement: currently MatchExpressions of a LabelSelector are written using v1.LabelSelectorRequirement.String ; which returns an extra , at the end of the requirement.
  consider if to remove that , from the end of the resulted string

[shireenf-ibm]

Summary of the implementation flow: (highlights)

• exposure-analysis results are produced by running list command with --exposure flag
  (./bin/k8snetpolicy list --dirpath <testing-dir> --exposure)

• the string output when running with exposure-analysis will include both

  • connlist results, i.e. connections between peers from the manifests / connections between real peers and ip-blocks.
  • exposure analysis results, i.e. connections between real peers from the manifests and potential pods. (connections to any namespace in the cluster will be represented by entire-cluster, connections to external resources will be represented by ip-blocks).

• getting a structured exposure-results from connlist-analyzer is also possible by calling connlistAnalyzer's ExposedPeers() which returns a list of objects of ExposedPeer interface type.

  • each ExposedPeer object captures potential ingress and egress connections data for an exposed Peer; i.e. an ExposedPeer is a real peer (from the manifests) which is:
    • potentially exposed to peers that are not in the manifests, those peers are described by their potential NamespaceLabels and PodLabels. OR
    • exposed widely , i.e the peer is exposed to all namespaces in the cluster (entire-cluster)/ exposed to the whole world (entire-cluster and any external resource (ip-blocks))

- flow of computing the exposure results:
1. building a policy-engine for exposure goals:

• first-step: inserting the policies from input-resource to the policy-engine:
  for each policy: looping policy's rules and update as following:
  • if the policy allows all (empty rules list) then the PolicyExposureWithoutSelectors field of the affected policy-direction is updated to indicate that the policy exposes its selected pods to all external and cluster resources with all connections
  • if the policy contains any rule which exposes its selected pods to any-namespace in the cluster, the ClusterWideExposure sub-field of the PolicyExposureWithoutSelectors field of the affected policy-direction is updated with the rule's port.
    • a rule that exposes the selected pods to any-namespace in the cluster is a rule that:
      • contains an empty namespaceSelector and nil podSelector
      • contains empty podSelector and empty namespaceSelector
  • otherwise, the rule contains:
    a nil namespaceSelector and non-empty podSelector / only non-empty namespaceSelector / both non-empty namespaceSelector and podSelector;
    for a such rule, a representative peer with those namespaceSelector and podSelector are generated.
  • note:
    • if the namespaceSelector is nil, the representative peer is generated in the policy's namespace and its namespaceSelector will conatin the matchLabels of the namespace name.
    • otherwise the representative-peer will be generated without a namespace as itself include all info about its potential namespace.

• generating representative-peers occurs only for different policy rules (representative-peers are unique).

• second-step: while inserting the pods/workloads from the input-resources, we remove all redundant representative-peers.
  i.e. a representative-peer that has a matching pod with same pod matchLabels and pod's namespace matchLabels is removed
  exceptional cases:
  * representative peers matching any-namespace or any-pod in a namespace will not be removed.
  * representative peers inferred from rules containing matchExpressions will not be removed either

2. computing allowed connections:

• after building the policy-engine with all input-resources and all generated representative-peers, next step is computing allowed connections between all pairs of peers (including pairs of a real peer and a representative-peer) to build the regular connlist and an exposure-map.

  • connections between real-peers or real-peers and ip-blocks are stored in the connlist
  • connections between real workloads and representative-peers are stored in an exposure-map
  • moreover, a peer which is exposed widely by the policies that selected it will be inserted to the map with the wide-connection info
  • also, a peer which is not selected by any policy (not protected) is inserted to the map since such peer is exposed to whole world (in and out the cluster) with all conns on ingress and egress

• the exposure map is a map from real-peer to its exposure-info which will be converted finally to the []ExposedPeer

• more notes:

  • it was also determined that when computing allowed connections, a rule matches a representative peer if :
    • the rule is empty (matches all)
    • the rule points to same reference of the selectors of the representative peer
    • the rule and the selectors of the representative peer have same requirements (1 way containment is not a match)

[shireenf-ibm]

moved the not yet handled tasks to #392