Handling multiple HTTP rules

[seungsoo-lee]

For now, the HTTP rule (method/path) is handled by the exact matching. So, for example, if the product page is defined by the product ID, there could be many paths as follows.

apiVersion: v1
kind: KnoxNetworkPolicy
metadata:
  name: autopol-egress-thbttgjfepzbadb
  namespace: hipster
  rule: matchLabels+toHTTPs+toPorts
  status: latest
  type: egress
spec:
  selector:
    matchLabels:
      app: loadgenerator
  egress:
  - matchLabels:
      app: frontend
      k8s:io.kubernetes.pod.namespace: hipster
    toPorts:
    - port: "8080"
      protocol: tcp
    toHTTPs:
    - method: GET
      path: /product/6E92ZMYYFZ
    - method: GET
      path: /product/9SIQT8TOJO
    - method: GET
      path: /cart
    - method: GET
      path: /product/0PUK6V6EV0
    - method: GET
      path: /product/OLJCESPC7Z
    - method: GET
      path: /product/1YMWWN1N4O
    - method: GET
      path: /product/2ZYFJ3GM2N
    - method: GET
      path: /product/66VCHSJNUP
  action: allow
generatedTime: 1608101559

So we need to handle those multiple paths of the HTTP rule by aggregating. The challenges here are how to merge? and why?

[nyrahul]

The question is if the user adds a policy with the generic rule path: /product/*, will the module stop generating new policies? Currently, I do not think this will happen. The auto-discovery module uses exact matching rules on the policy rules and thus even if the general rule is added it will keep on discovering new HTTP paths.

1. Should we allow the user to edit the auto-discovered policies even for internal rules and keep them in the DB?
2. How to handle generic rule matching?

[seungsoo-lee]

Fixed #93