This is a blocker for one of my clients and for all internal projects.
On our internal projects, Docker is banned from everything inside the edge firewall due to ongoing major security issues. Docker itself is ok, but images pulled from hub.docker.com are completely unverifiable, often out-of-date and missing security patches and based on inappropriate Linux distributions.
Let’s take for example mender-api-gateway-docker with the Dockerfile defined at https://github.com/mendersoftware/mender-api-gateway-docker/blob/master/Dockerfile. As you’re pulling a very specific version of the openresty image (18.104.22.168-0-alpine) you’re getting something that was built over a year ago. That’s no security patches on the front-end nginx for a full year - that really worries me and is why hub.docker.io images of all forms are banned from inside our firewall.
My ideal deployment case is all microservices within Mender Server running on Ubuntu Server LTS containers within either Docker (if built from Dockerfiles locally, regularly and with no use of any upstream images from hub.docker.com) or LXD with automatic updates enabled on a nightly basis so that security updates are applied within 24 hours of release.
Due to the tight integration with docker here, and specifically with the way DNS works within Docker, we’re really not left with any other options than using Docker and docker-compose as provided in the integration repository. The hostnames seem to be hardcoded in the various microservices implemented in golang and nodejs so this isn’t something I’m in a position to pull apart. So we’ll be restricted to deploying Mender on third-party cloud services outside of our normal infrastructure at greatly increased administrative burden.
Handling certificates within the mender-api-gateway openresty instance also breaks our policies - we have a system in place using letsencrypt with automated certificate renewals and isolated nginx proxies handling SSL termination. At the very least we need the option to deploy mender-api-gateway in a HTTP-only mode with SSL termination handled in a separate proxy.