Docker-compose yml scripts currently expose "wurstmeister" as a root user

[caldempsey]

The Zookeeper image docker compose yml can be found here.
The base image that script inherits can be found here.

It can be shown that the docker compose script is exposing (needlessly) a root access user (which is not used within the rest of the build). This consitutes a security vulnerability unless properly understood by users as a consequence of directly using that base image.

There should be documentation advising at least that a root user is explicitly defined on the image, as it shouldn't be the user responsibility to trawl through the base images.

Not only that, but SSH port 22 is also exposed, meaning for any system using an image generated from docker-compose.yml, its vulnerable to shell access. Either this problem should be addressed, or the consequences of the image should be documented.

[sscaling]

I think you have perhaps missed the focus of this repo - this is to provide packaging for the Kafka binary. Zookeeper is a component required to coordinate / persist state in a Kafka cluster.

The only artifact managed by this repo is the one published to Dockerhub here: https://hub.docker.com/r/wurstmeister/kafka

By all means if you see a security issue in any of the support images open them in the respective repositories.

Historically there wasn't an official Zookeeper image, so the one you linked to was published purely to support this. This was also before the time of the exec capabilities of the docker client so one of the ways to provide access to the process namespace was by enabling ssh.

Nothing in the current image exposes SSH.

As Kafka is a non-trivial piece of infrastructure, it is assumed that the operator would understand the risks and security configuration required to operate it securely in a production environment. On that note, the zookeeper image is unsuitable for a production environment - it is not able to run in replicated mode therefore unable to reach quorum and offer durability and consistency. Also, a simple review of the git history would see that this is not a well maintained image: https://github.com/wurstmeister/zookeeper-docker/commits/master

Thanks for taking the time to raise this issue, but it seems a bit misleading and just falls into the same category as mounting the docker socket through to the container as per the example docker-compose files included in this repo.

If by any chance you have a CVSS or a proof of concept exploit agains the kafka-docker image we'd be happy to review it.

Thanks.

[caldempsey]

@sscaling Sorry but I feel you haven't investigated the issue. Have you actually read the source image for Wurstmeister base used in the Wustmeister zookeeper image you are defending?

FROM ubuntu:trusty
MAINTAINER Wurstmeister 
RUN apt-get update; apt-get install -y unzip openjdk-7-jre-headless wget supervisor docker.io openssh-server
ENV JAVA_HOME /usr/lib/jvm/java-7-openjdk-amd64/
RUN echo 'root:wurstmeister' | chpasswd
RUN mkdir /var/run/sshd
RUN sed -i 's/PermitRootLogin without-password/PermitRootLogin yes/' /etc/ssh/sshd_config

EXPOSE 22

[caldempsey]

I'll come back with a proof that you can dial straight into the containers via SSH. My position is Docker is a non-trivial piece of technology and the base images should be developed to minimise vulnerability. I suppose I may be overly concerned with people running the docker-compose scripts in production, but still it's pretty nasty to expose a root user directly over SSH to the Zookeeper base image through two through Docker image layers. To claim Nothing in the current image exposes SSH. is strictly false.

[sscaling]

That is the zookeeper image. Not the Kafka image. The Zookeeper image shouldn't be used in production because it does not support multi node.

My position is Docker is a non-trivial piece of technology

If i've understood correctly, you have images and orchestration (docker-compose) confused.

To claim Nothing in the current image exposes SSH. is strictly false.

Please can you indicate on which line is responsible for exposing SSH: https://github.com/wurstmeister/kafka-docker/blob/master/Dockerfile

Then we can gladly investigate.

[caldempsey]

@sscaling But instructions on the repository are for orchestration? Why would it be a prerequisite to install Docker compose if that were not the case? Your claim that "The only artefact managed by this repo is the one published to Docker hub here: https://hub.docker.com/r/wurstmeister/kafka" is strictly misleading.

The default docker-compose.yml should be seen as a starting point. By default each broker will get a new port number and broker id on restart. Depending on your use case this might not be desirable. If you need to use specific ports and broker ids, modify the docker-compose configuration accordingly, e.g. docker-compose-single-broker.yml:

docker-compose -f docker-compose-single-broker.yml up

We can show that the orchestrated container exposes a root user and SSH, and we know plenty of users are using the compose as if it were supported by the repo...

#319
#478
#447
#167

So even if you believe the repository is only for maintaining the Dockerfile image at https://github.com/wurstmeister/kafka-docker/blob/master/Dockerfile which I agree is fine, that does not mean that is reflected in the repository, and the situation is made even worse by contributors who support users trying to use the compose YAML They are put at-risk if say they decide to use that docker-compose yml as a resource for Kubernates in a production system provisioning an sshd_config with a googleable root login.

That doesn't have to be a big organisation where there are degrees of liability involved in-case there was a breach in a production system, but even personal projects that people deploy for their own learning and development are affected (and I would argue just as important).

It strikes me strange if the only artefact managed by this repository is that Dockerfile, then why would contributors support users of the compose scripts? There really should be a warning for users that the Zookeeper image is insecure and is not intended for use in production. After all the repository has a high throughput of users who are using the compose.yml resource. Could you or I at least make a pull request to advise users that the Zookeeper image is poorly maintained, do you not think that would be appropriate all-things-considered? It otherwise seems irresponsible to keep giving people advice on how to use the Docker compose yml without "officially supporting it".

[sscaling]

https://kafka.apache.org/documentation/#zk

If you have a small deployment, then using 3 servers is acceptable, but keep in mind that you'll only be able to tolerate 1 server down in this case.

https://zookeeper.apache.org/doc/r3.1.2/zookeeperStarted.html#sc_RunningReplicatedZooKeeper

Running ZooKeeper in standalone mode is convenient for evaluation, some development, and testing. But in production, you should run ZooKeeper in replicated mode.

https://github.com/wurstmeister/zookeeper-docker/blob/master/start-zk.sh
https://github.com/wurstmeister/zookeeper-docker/blob/master/Dockerfile

☝️No image-provided way to configure replicated mode.

---

To run Kafka, operators are required to understand Kafka, Zookeeper, Networking and Storage.
To run Kafka inside a container, they are also required to understand the above plus Containers and Container networking.

The default docker-compose.yml should be seen as a starting point. By default each broker will get a new port number and broker id on restart. Depending on your use case this might not be desirable. If you need to use specific ports and broker ids, modify the docker-compose configuration accordingly, e.g. docker-compose-single-broker.yml:

docker-compose -f docker-compose-single-broker.yml up

This re-iterates that the example docker-compose files are a starting point and examples.

---

Re "official support" - this is an Apache-licensed open-source project that comes with no warranty or liability. We make a best-effort attempt at support and help the community.

---

Re "making a pull request" - PRs are always welcome - however adding a warning seems pointless. All related projects are available on github - so it seems if you really have an issue with the zookeeper image, you should open a PR to fix the Zookeeper image.

Thanks.