Versions Compared

Old Version 20

changes.mady.by.user Keong Lim

Saved on

compared with

New Version Current

changes.mady.by.user Keong Lim

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

...

Example from Cloud Native Deployment:

  • ubuntu@a-cd-one:~$ kubectl get pods --all-namespaces
    (shows 210 pods in onap namespace)


TypeVMsPods
TypeVMs
Containers
Full Cluster (14 + 1) - recommended15
28
248 total



Example from Open Wireless Laboratory (OWL) at Wireless Information Network Laboratory (WINLAB):

  • There are currently three Ubuntu 18.04 servers: node1-1, node2-1 and node2-2, which are managed by OpenStack.
    Node1-1 is the controller node, and node2-1 and node202 are compute nodes.
    We have installed ONAP using the OOM Rancher/Kubernetes instructions into five VMs.OpenStack.
    Node1-1 is the controller node, and node2-1 and node202 are compute nodes.
    We have installed ONAP using the OOM Rancher/Kubernetes instructions into five VMs.

Development

  • There is a transition from http ports to https ports, so that communications are protected by TLS encryption.
  • However the transition is piecemeal and spread over multiple ONAP releases, so individual projects still have vulnerabilities to due intra-ONAP dependencies, e.g.
    Jira
    serverONAP JIRA
    serverId425b2b0a-557c-3c0c-b515-579789cceedb
    keyOJSI-97
    out of a total of
    Jira
    serverONAP JIRA
    jqlQuerytext ~ "plain text http" ORDER BY updated DESC
    counttrue
    serverId425b2b0a-557c-3c0c-b515-579789cceedb
    .
  • A node-to-node VPN (working at the level of the VM or physical servers that host the Kubernetes pods/docker containers of ONAP) would provide blanket coverage of all communications with encryption.
  • A node-to-node VPN is both
    • an immediate stopgap solution in the short-term to cover the exposed plain text HTTP ports
    • an extra layer of security in the long-term to thwart unforeseen gaps in the use of HTTPS ports

Discussion

  • There has already been discussion and recommendation for using Istio https://istio.io/
    • Istio Envoy is deployed within each pod using sidecar-injection, then stays in the configuration when the pods are restarted
    • Istio Envoy probably appears within each pod as a network bridge, such as Kubernetes cluster networking bridge cbr0, thereby controlling all network traffic within the pod
    • Istio Envoy provides full mesh routing but can also provides control of routing with traffic management and policies
    • Istio Envoy also provides telemetry in addition to the security of mutual TLS authentication
    • Istio Citadel is run in the environment as the certificate authority / PKI supporting the mutual TLS authentication
    • Istio appears to have only a single overall security domain (i.e. the environment that includes Mixer, Pilot, Citadel and Galley), though it does contain many options to distinguish different services, users, roles and authorities

...

  • Appearance:
    • Tinc VPN appears as IP level network device
    • ZeroTier appears as Ethernet level network port
    • WireGuard appears as IP level network device
  • Connectivity provided:
    • Tinc VPN automatically gives full mesh routing
    • ZeroTier automatically gives full mesh routing
    • WireGuard gives point-to-point connection like SSH (mesh routing is a todo)
  • Node/Host Configuration:
    • Tinc VPN host is configured with public/private key pair, in a config file
    • ZeroTier node is configured with public/private key pair, then generates a VL1 ZeroTier Address
    • WireGuard host is configured with public/private key pair and ACL, in a config file
  • Network Configuration:
    • Tinc VPN network is configured by hosts exchanging (out-of-band) exported config files for a specified "network name"
      • rest of network is exchanged in-band
    • ZeroTier network is configured with knowledge of "roots" and with VL2 ZeroTier Network ID (VL1 ZeroTier Address of the controller and network number)
      • rest of network is exchanged in-band
    • WireGuard network is configured by hosts sharing public keys (out-of-band), connect via IP Address corresponding to keys
      • IP roaming is exchanged in-band
  • Number of network connections:
    • Tinc VPN hosts can connect to many "network names" concurrently
    • ZeroTier nodes can connect to multiple VL2 ZeroTier Network IDs concurrently
    • WireGuard hosts can connect to many other hosts concurrently
  • Deployment:
    • Tinc VPN is deployed on the VM hosting the pods/containers/processes
      • could be in the container base image
      • no explicit interoperability with kubernetes to manipulate pod/container network namespaces
    • ZeroTier is deployed on the VM hosting the pods/containers/processes
      • could be in the container base image
      • no explicit interoperability with kubernetes to manipulate pod/container network namespaces
    • WireGuard is deployed on the VM hosting the pods/containers/processes
      • could be in the container base image
      • no explicit interoperability with kubernetes to manipulate pod/container network namespaces
  • Single-Points-of-Failure:
    • Tinc VPN runs daemon processes on each host (one per network name), topology is peer-to-peer
    • ZeroTier runs a global "planet" root server called "Earth" apparently as testing network and casual communications
      • Unclear about how users can deploy their own "planet" root servers
      • Users can deploy their own "moon" root servers
    • WireGuard runs daemon processes on each host, topology is peer-to-peer
  • Scaling:
    • Tinc VPN can add new hosts to existing network names without altering configurations of existing hosts
      • invitations dynamically create a configuration on the server
    • ZeroTier can add new nodes to existing network IDs without altering configurations of existing nodes (Network ID is obscure but public information)
      • Unclear whether adding new root servers requires a restart
    • WireGuard can add new hosts but requires both ends of the connection to be updated and present in the ACL of host config file
  • Access Control:
    • Tinc VPN has control by the exchange of exported host config files
      • an invitation refers to the configuration on the server
    • ZeroTier nodes need to be authorised after attempting to connect the network ID, but it can be turned off to allow "public" networks
    • WireGuard has control by the exchange of host public keys and ACL in host config file
  • Based on example from Cloud Native Deployment:
    • Tinc VPN would be deployed on 15 VMs, compared to 28 210 pods
    • ZeroTier would be deployed on 15 VMs, compared to 28 210 pods
    • WireGuard would be deployed on 15 VMs, compared to 28 210 pods
  • Based on example from Open Wireless Laboratory:
    • Tinc VPN would be deployed on 3 servers or 5 VMs, compared to 28 210 pods
    • ZeroTier would be deployed on 3 servers or 5 VMs, compared to 28 210 pods
    • WireGuard would be deployed on 3 servers or 5 VMs, compared to 28 210 pods
  • tbc


Comparison to Istio

...