dfw is conceptually based on the Docker Firewall Framework,
goal is to make firewall administration with Docker simpler, but also more extensive by trying
to replace the Docker built-in firewall handling by direct interaction with iptables.
This is accomplished by a flexible configuration which defines how the firewall should be built up. While DFW is running, Docker container events will be monitored and the rules rebuilt when necessary.
See DFWFW's README for more insight. Most of what you will read there will be applicable to DFW.
The general configuration happens across six categories:
This category defines global, default values to be used by DFW and the other categories.
This controls the communication between containers and across Docker networks.
This controls if and how containers may access the wider world, i.e. what they can communicate across the
OUTPUTchain on the host.
To restrict or allow access to the host, this section is used.
This controls how the wider world, i.e. whatever comes in through the
INPUTchain on the host, can communicate with a container or a Docker network.
This category allows you to define specific rules for destination network address translation, even or especially across Docker networks.
One category which DFWFW covers that is not (yet) implemented in DFW is
container_internals, that is configuring iptables rules within containers.
See the [examples][examples] (TODO), and the configuration types for a detailed description of every configuration section.
At least Docker 1.13.0 is required.
DFW has been successfully tested under the following Docker versions:
While you can use Cargo to install
dfw as a binary, using the Docker image is the preferred
way to go, especially if you don't want to install Rust and Cargo on your host:
$ docker pull pitkley/dfw:0.2 $ docker run -d \ --name=dfw \ -v /var/run/docker.sock:/var/run/docker.sock:ro \ -v /path/to/your/config:/config \ --net host --cap-add=NET_ADMIN \ pitkley/dfw --config-path /config
This will download a lightweight image, coming in at under 6 MB, and subsequently run it using your configuration.
I have reimplemented DFWFW in Rust for two reasons:
DFWFW had lost compatibility with the Docker API starting with release 17.04.0-ce, although this has been fixed in the meantime.
The main reason for this reimplementation was that I found a real-life project to tackle with Rust. This project allowed me to delve into quite a few different aspects and facets of Rust and especially its eco-system, amongst others:
clap, for parsing of command line arguments
chan, for easy messaging and coordination between threads
error-chain, for simplified application wide error handling
- Serde, for deserialization of the TOML configuration
slog, for structured logging
Disregarding the obvious hair-pulling moments regarding ownership, borrowing and lifetimes, my experience with Rust and its brillant eco-system has been an absolute pleasure.
DFW is licensed under either of
- Apache License, Version 2.0, (LICENSE-APACHE or http://www.apache.org/licenses/LICENSE-2.0)
- MIT license (LICENSE-MIT or http://opensource.org/licenses/MIT)
at your option.
Unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in DFW by you, as defined in the Apache-2.0 license, shall be dual licensed as above, without any additional terms or conditions.
This module holds the types related to configuration processing and rule creation.
The types in this module make up the structure of the configuration-file(s).