Network policy and (later) linkerd policy generator.

Basic idea:

1. The kubernetes clusters hosts applications
2. Applications communicate to other applications

Allowed communication betwen applications is configured as follows:

communication: 
- from: app1
  to: app2
  ports:
    - 80
    - linkerd-admin

Ports are optional. When omitted all ports are intended

There are pre-defined applications such as api-server. Beyond that thera are two types of applications:

• cidr: a cidr with possible except clauses following netpol syntax
• app: regular app based on matchLabels, together with namespace name.

Application names must be unique.

There are also standard capablities for an application such as:

• linkerd: addes egress to linkerd-jaeger, egress to linkerd, ingress from linkerd-viz

networks: 
  - name: internet
    cidr: 0.0.0.0/0
    except:
      - 10.0.0.0/8
      - 172.16.0.0/12
      - 192.168.0.0/16 

capablities can also be defined at the namespace level, which means they apply to each pod in the namespace

namespaces:      
- namespace: wamblee-org 
  capabilities:
    - linkerd 
  applications: 
    - name: nexus-server
      # ports when specified at the application level are used when 
      # not explicitly mentioned when a link is made
      ports:
        - 8081
        - 8082
      matchLabels: 
        app: nexus-server
      
- namespace: exposure
  applications: 
    - name: httpd-wamblee-org
      matchLabels: 
        app: wamblee-org

communications: 
- from: # can we support both string and list of strings? 
    - httpd-wamblee-org
  to:
    - nexus-server 
    - wamblee-static
    - wamblee-safe 
    
# or limiting ports further
- from: 
    - httpd-wamblee-org
  to:
    - nexus-server
  ports:
    - 8081
    - 8082
    
 

Linkerd extension: 
* for each application an optional service account is defined, when not 
  defined, 'default' is assumed. 
* together with the communication links this determines the authorization 
  policies. 
  
Technical realization could be in the form of go templates where the input 
the template is:
1. map of app name to definition with for each app also a list of 
   capabilities. 
2. a single app config with for each app
   * all ingresses
   * all egresses
   
Similar and easier technical solution via interface with a network policy 
implementation and a linkerd implementation. 

Then we can have: 
1. networkpolicy templates
2. server, meshtls, networkauthentication, authorization policy
   * when linkerd capability for both pods, the tool can generated a 
     meshtlsauthentication, when the target pods does not have linkerd 
     capability, it can be ignored.