Hi, in order to make sure we can secure our docker containers as much as possible we need to drop all docker communication in the DOCKER-USER chain in iptables upon boot. This needs to happen upon starting the device before containers are started.
We found one solution where we create a udevrule in config.json which simply executes iptables to insert a rule with iptables to drop all docker traffic. Afterwards we have a container which configures the proper rules to only allow necessary traffic between the containers.
My question is, is there any better or more recommended approach to this problem?
Edit: The udev-rule seems to be provisioned to the device from config.json and by then it is too late for it to execute (first boot ever) but booting the device after the udev-rule has been applied to the device it works flawlessly.
Is this for open-balena or the balenaCloud device? As for balenaCloud, for proper functioning of the device its necessary to have supervisor or cloudlink related req. enabled to help it successfully connect to balenaCloud. See: Development Anti-patterns - Balena Documentation
This is for balenaCloud. At the moment we only fiddle with docker specific communication and the supervisor/vpn/balena firewall remains untouched so that is not a concern as of now.
The goal is to be able to reliably execute iptables at boot acting as a network kill switch (for the containers, not balena specific services!). Ideally this should also work at the first boot of the device.
You could try setting the IPTable rules from within a container by setting network mode as host and ensuring the sufficient privileges, but there isn’t an easy way to interact with the devices automatically before that step, except perhaps by building your own image: Customer Board Support - Balena Documentation
Here is some more info on network requirements regarding Cloudlink and balena communication for reference:
I am curious though what the goal is here? The device is already every secure, as it Docker for isolating environments. Perhaps there are other ways to improve the security if you have some more information on your use case?
We already do set IP Table rules from a container. This is to make sure only specific containers are allowed to communicate with each other and also to only allow certain services to be accessible from specific network interfaces.
The goal really is to disable container network connectivity on boot because there is no guarantee that our container which manages the IP Table rules will actually be done before the other services have started.
Why? Because we want to assure we always have control over the communication flow to ensure the best security we can and remove as many possible attack surfaces as possible.
Would adding each container on to its own bridge network suffice for the container isolation? By default, when containers are on the same bridge network they can see each other (ping container-name), but if they are on their own bridge networks they should be isolated:
container1:
...
networks:
- front
container2:
...
networks:
- back