quantum
is a software defined network device written in go with global networking, security, and auto-configuration at its heart. It leverages the latest distributed data stores and state of the art encryption to offer fully secured end to end global networking over a single cohesive network. quantum
is fully opensource, and is licensed under the MPL-2.0, for details see the license.
For detailed information on the operation and configuration of
quantum
take a look at the wiki.
quantum
is designed to be essentially plug and play, however the default configuration will run quantum
in an insecure mode and assumes each node running quantum is also running its own instance of the data store. In reality for quantum
to guarantee safe operation it must be run with either the encryption
plugin enabled or using the DTLS backend. As well as having TLS fully setup and configured with the datastore.
Supported Datastores | Supported OS's | Supported Providers |
---|---|---|
etcd | linux | AWS, GCE, Azure |
Packet, Digital Ocean, Rackspace | ||
Private datacenters, Private co-locations, and many more |
quantum
can be configured in any combination of three ways, cli arguments, environment variables, and configuration file entries. All configuration options are optional and have sane defaults, however runnig without parameters will force quantum to run in insecure mode. All three variants can be used in conjunction to allow for overriding variables depending on environment, the hierarchy is as follows:
- Cli parameters override all other methods
- Environment variables override configuration file entries but can be overridden by cli parameters
- Configuration file entries will override defaults but can be overridden by either cli parameters or environment variables
Run quantum -h|--help
for a current list of configuration options or see the wiki on configuration for further information.
The security that quantum
can guarantee is based on a few pieces of configuration. Review the following sections for a high level overview of the configuration needed to make quantum
secure, and for a detailed overview of the different options see the wiki on security..
Etcd security configuration is very well documented and implemented. It is highly recommended to fully read and understand the security setup for etcd before considering quantum for production use. The security provided by quantum
is intrinsicly linked to the security used by etcd, as the information stored in etcd is highly sensitive and should be kept out of sight of prying eyes.
To ensure the secure operation of quantum
the following must be true:
- Require TLS communication to etcd in all cases.
- Each server running
quantum
has its own unique TLS client certificate/key pair. - Etcd client certificate authentication should be enabled.
- For added security each server should also have a unique username/password to access etcd.
For a minimalistic openssl configuration that can be used to generate test certificates see the included
dist/bin/generate-tls-test-certs.sh
bash script
The DTLS
backend network is the most secure way to use quantum
, this backend configures and uses DTLS v1.2 based on OpenSSL v1.1.0f. While this backend is the most secure, it also requires the most configuration to properly use. Specifically a fully configured and secured CA is needed, and each server should be given its own signed client certificate/key pair that is set to use the unique public host IP as the common name for verification purposes. The other caveat of using the DTLS
backend network, is that all servers in the quantum
network will use DTLS
for communication, whether or not encryption is needed.
Again for a minimalistic openssl configuration that can be used to generate test certificates see the included
dist/bin/generate-tls-test-certs.sh
bash script
The Encryption Plugin
allows for secure communication using randomly generated ECDH key pairs for each server using curve25519. While this plugin is easier to utilize than the DTLS
backend network it is not as secure. Due to the fact that there is no authentication of the communicating peers. However the messages that are received are authenticated using GCM guaranteeing that there is no tampering with messages between servers in transit. The Encryption Plugin
utilizes a combination of the randomly generated ECDH key pairs, a unique random salt, pbkdf2, and AES-256-GCM. Unlike the DTLS
backend network, only servers with this plugin enabled will communicate with encryption, which allows for granular configuraion of which servers require the security provided.
Currently quantum
development is entirely in go and utilizes a few BASH scripts to facilitate builds and setup. Development has been mostly done on ubuntu server 14.04+, however any recent linux distribution with the following dependencies should be sufficient to develop quantum
.
- bash
- GNU make
- tun kernel module must be enabled
- please see your distributions information on how to enable it.
- docker
- docker-compose
- openssl
- go 1.9.x
- a recent c/c++ compiler
To get started developing quantum
, run the following shell commands to get your environment configured and running.
Note that testing quantum requires
sudo
access to create and configure TUN/TAP devices, see the includeddist/bin/coverage.sh
script anddevice/device_test.go
tests for details.
$ cd $GOPATH/src/github.com/supernomad/quantum
# Setup the dev environment
$ make setup_dev
# Run a full development build including linting and unit tests
$ make
$ make check
# Start up the docker test bench
$ docker-compose up -d
# Wait a few seconds for initialization to complete
# Check on the status of the different quantum containers
$ docker-compose logs quantum0 quantum1 quantum2
# Run ping to ensure connectivity over quantum
$ docker exec -it quantum1 ping 10.99.0.1
$ docker exec -it quantum2 ping 10.99.0.1
After running the above you will have a single etcd container and three quantum containers running. The three quantum containers are configured to run a quantum network 10.99.0.0/16
, with quantum0
having a statically defined private ip 10.99.0.1
and quantum1
/quantum2
having DHCP defined private ip addresses.
To run basic unit testing and builds execute:
$ cd $GOPATH/src/github.com/supernomad/quantum
$ make check
To do basic bandwidth based testing each of the quantum
containers all have iperf3 installed. For example to test how much throughput quantum0
can handle from both quantum1
/quantum2
:
# Assuming the three development quantum containers are started
# Start three shells
# In first shell start iperf3 server
$ cd $GOPATH/src/github.com/supernomad/quantum
$ docker exec -it quantum0 iperf3 -s -f M
# In second shell start iperf3 client in quantum1
$ cd $GOPATH/src/github.com/supernomad/quantum
$ docker exec -it quantum1 iperf3 -c 10.99.0.1 -P 2 -t 50
# In third shell start iperf3 client in quantum2
$ cd $GOPATH/src/github.com/supernomad/quantum
$ docker exec -it quantum2 iperf3 -c 10.99.0.1 -P 2 -t 50
Contributions are definitely welcome, if you are looking for something to contribute check out the current road map and grab an open issue in the next release.
Work flow:
- Fork
quantum
from develop - Make your changes
- Open a PR against
quantum
on to develop - Get your PR merged
- Rinse and Repeat
There are a few rules:
- All jenkins builds must successfully complete before a PR will be considered.
make all check
must be run successfully before the PR is open.- Documentation is added for new user facing functionality.
Copyright (c) 2016-2018 Christian Saide