analysis with specific ingress controllers

[shireenf-ibm]

issue #235

[shireenf-ibm]

hi @adisos,
some questions:

at this first commit in this PR, I've added a test directory with an example that should be resolved for issue #235

• I would like if you take a look on the example

with our current analysis , ingress connection to the default/apple-app[Pod] is blocked by the policy.
when conducting the namespace of the specific ingress in the policy as an ingress resource:

1. should the new output include the "old" row of :
   {ingress-controller} => default/apple-app[Pod] : TCP 5678
   or a new row with the specified namespace in the policy?
   (e.g ingress-nginx => default/apple-app[Pod] : TCP 5678 )

2. how should the analyzer behave if the policy enables the ingress from ingress-nginx but there is no Ingress/Route object provided?

[adisos]

hi @adisos, some questions:

at this first commit in this PR, I've added a test directory with an example that should be resolved for issue #235

* I would like if you take a look on the example

with our current analysis , ingress connection to the default/apple-app[Pod] is blocked by the policy. when conducting the namespace of the specific ingress in the policy as an ingress resource:

1. should the new output include the "old" row of :
   `{ingress-controller} => default/apple-app[Pod] : TCP 5678`
   or a new row with the specified namespace in the policy?
   (e.g `ingress-nginx => default/apple-app[Pod] : TCP 5678` )

2. how should the analyzer behave if the policy enables the ingress from `ingress-nginx` but there is no `Ingress/Route` object provided?

(1) A connectivity line should specify a specific ingress-controller if possible
(2) In such case just as in usual analysis of netpols -- show the possible connections based on the policy. (maybe this is related to the issue about exposure analysis).

[shireenf-ibm]

hi @adisos ,
in this commit a first solution for considering the specific ingress controllers:

• for each peer that is selected by Route/Ingress object:
  • if the general ingress-controller connection to the peer is empty (i.e. blocked by policies' rules - no intersection)
    -> then I check for specific ingress controllers connections to the peer.
    -> if all ingress controllers connections are blocked by the policy, then the original "blocking" warning is printed
• code update in connlist.go file
• since our interfaces checks allowed connections only between peers; in-order to check connections from the specific ingress controllers (e.g. ingress-nginx), I add fake pods with namespace and name of the specific ingress-controller namespace (which i have).
  this means, this solution assumes that the policy-rule selecting an ingress controller must have a namespaceSelector with the label of the specified namespace.
  but not sure how to behave if it has also a podselector rule?

[shireenf-ibm]

in the last commit added support for some labels of the openshift and nginx ingress-controllers namespaces.
Also added a new doc docs/ingress_analysis.md with a description of the new supported labels and the analysis output

[adisos]

added a few comments

[adisos]

what if such pods already exist in the input resources list?

[shireenf-ibm]

if such pod already exists but no Route/Ingress found - nothing need to be done (handled in the past).

if we have Ingress/Route , till now assumed there is no ingress-controller deployment, in the resources.
but if such resources exist :
how should it behave?
option 1 : act as the existing ingress pod/s are the only ones considered for ingress analysis? (don't add fake ingress pods from other namespaces)
but then if (for-example) we have an nginx-ingress deployment in the resources.
and a policy-rule with namespaceSelector selecting one of the openshift controller namespaces - this rule will be ignored for ingress-analysis (as any rule which select a not existing namespace/pod)

option2 : add fake ingress pods for the other ingress-controllers ?
if this option is the desired :
- if all ingress-controllers are supported should still have the general output line with {ingress-controller} as source ? (without the existing pod line)

[shireenf-ibm]

another q: should we assume only one ingress-controller deployment may exist in the resources?

[adisos]

I think it makes sense to assume only the input ingress controller if there is such, and then avoid adding the fake ingress pods.