SDEWAN is a solution to enable SDWAN functionalities include multiple WAN link support, WAN traffic management, NAT, firewall, IPSec and Traffic shaping etc. with focus to address the challenges when applying on edge computing environment like resource limitation, edge overlays, traffic sanitization, automation and cost sensitive etc.
SD-EWAN main functionalities include
- IPsec tunnels across K8s clusters - Supporting multiple types of K8s clusters "K8s clusters having static public IP address", "K8s clusters having dynamic public IP address with static FQDN" and "K8s clusters with no public IP".
- Stateful inspection firewall (for inbound and outbound connections)
- Source NAT and Destination NAT for supporting K8s clusters whose POD and ClusterIP subnets are overlapping.
- Multiple WAN link support
SD-EWAN is based on set of Linux packages
- mwan3 (for Multiple WAN link support)
- IPTables (for firewall, SNAT, DNAT)
- Strongswan (for IPsec)
- TC (Traffic Control)
SD-EWAN functionalities are realized via three components: Central Controller, CNF (Containerized Network Function) and CRD controller that deployed through K8s. SD-EWAN CNF leverages Linux kernel functionality for packet processing of above functions. Actual CNF is set of user space processes consisting of fw3, mwan3, strongswan and others.
SD-EWAN is considered as platform feature by ICN.
SDEWAN platform features include cnf, cr definition and controller.
CNF is implemented based on OpenWRT, it enhances OpenWRT Luci web interface with SDEWAN controllers to provide Restful API for network functions' configuration and control.
CRD controller is implemented as k8s CRD Controller, it manages CRDs (e.g. Firewall related CRDs, Mwan3 related CRDs and IpSec related CRDs etc.) and internally calls SDEWAN Restful API to do CNF configuration. And a remote client (e.g. SDEWAN Central Controller) can manage SDEWAN CNF configuration through creating/updating/deleting SDEWAN CRs.
central-controller provides central control of SDEWAN overlay networks by automatically configuring the SDEWAN CNFs through SDEWAN CRD controller located in edge location clusters and hub clusters.
To make our project work for your solution, please do the environment settings following the best practices that are widely known by the communities and industries.
First of all, please follow the best practices to configure your host operating system. e.g. keep host OS components up-to-date and minimize host OS attack surface.
Please follow the best know practices of Docker in your development lifecycle that will give you more productivity and security.
- Development Best Practices
- Image Build Best Practices
- Only Use Trusted Registry Service Like Docker Hub
- Using Docker Hub for CI CD
Please follow the industry best practices for setting your Kubernetes clusters.
Etcd is a is a strongly consistent, distributed key-value store. It's a critical Kubernetes component which stores information on state and secrets, and it should be protected differently from the rest of your cluster. Administrators should always use strong credentials from the API servers to their etcd server, such as mutual auth via TLS client certificates, and it is often recommended to isolate the etcd servers behind a firewall that only the API servers may access.
Access to etcd (the datastore of Kubernetes) should be limited to the control plane only. Depending on your configuration, you should attempt to use etcd over TLS. More information can be found in the etcd documentation.
Wherever possible, it's a good practice to encrypt all storage at rest. Since etcd holds the state of the entire cluster (including Secrets) its disk should especially be encrypted at rest. e.g. Kubernetes documentation on encrypting data at rest
Please follow the best known practices of MongoDB
Our project can be used with Istio to enable a secure running environment. Please follow the general practice of the Istio Service Mesh and Istio / Security to complete the settings for your own solution. In addition to that, in order to get a general idea or quick impression about the usage, you can also reference our introduction to a demo. Please also follow the best practices of Istio for scalability and performace.
Please follow the best practices for administration or operations.
e.g. We recommend you to follow the guidelines about the authentication lifecycle management in Digital Identity Guidelines that covers a broad range of that topic. Especially, please follow the guidelines in section "5.1.1.2 Memorized Secret Verifiers" in that document when you configure your secret verifiers.
Please follow the best practices of industry to manage the accounts. e.g. authentication lockout or throttling, minimum password requirements, password of application should be protected, authentication error should be consistent, avoid authentication timing vulnerabilities, new user should be forced to change password etc.
Please follow the best practices of industry to manange your certificate. e.g. https://kubernetes.io/docs/setup/best-practices/certificates/
For any questions about this project, feel free to ask a question in #general in the ICN slack, or open up a https://jira.opnfv.org/issues/.