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
  
capablities can also be defined at the namespace level, which means they 
apply to each pod in the namespace. 



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 


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
  porst:
    - 8081
    - 8082
    
    
Handling of capabilities: 
1. capabilities at namespace level is defined a template that gets the namespace name.  

   Ingress template
      
      from: 
        - linkerd-viz
      to:
        - {{ application }}
        
   egress template
       
      from: 
        - {{ application }} 
      to: 
        - linkerd-jaeger
        - linkerd 
   
   The templates are evaluated for an application and then parsed, and added
   to the allowed communications. 


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.