Root access

[aleclarson]

Is it necessary for sumologic/collector:latest to be run as the root user?

If so, how vulnerable does that make my other containers?

[maimaisie]

Hi @aleclarson , we do support running collector as a user other than root. It is documented here https://help.sumologic.com/Send-Data/Installed-Collectors/05Reference-Information-for-Collector-Installation/05Set-the-Run-As-User-for-a-Collector

However, you'll need to follow Docker's documentation to create a user group and a user in your own Dockerfile to build the collector image.
https://docs.docker.com/engine/userguide/eng-image/dockerfile_best-practices/#user

The Dockerfile we are using for sumologic/collector:latest is https://github.com/SumoLogic/sumologic-collector-docker/blob/master/Dockerfile

The engineering team will track a work item to provide an option that allows running as non-root user in the collector image to save you from these extra steps in the future.

[aleclarson]

Are there disadvantages to running as non-root? Why is root the default?

[maimaisie]

The collector process needs to listen to TCP/UDP ports (if you are running Syslog source), read/write from the collector directory for configurations, caches, etc. Defaulting to root makes the setup process a bit easier. Also, in Docker, any process is run with root by default. But of course, we need to provide options to change the default. You can do that pretty easily on the non-dockerized Sumo collector (when you install collector as a service, not a container), however needs some extra steps for dockerized collector.

[coderanger]

I'm going to echo this, running as UID 0 is very dangerous in most cases. I would strongly recommend using a USER nobody line in the Dockerfile.

[adilfulara]

+1

My employer does not allow containers to run as root on our kubernetes env.

Adil.

[farisjarrah]

Any update to this issue? We are trying to run this in a Kubernetes cluster and really care about the security context in which all of our containers run. It would be very useful to not have to roll our own specialty image to manage this.

You folks allow some configuration of the docker based deployment to be injected via environment variables. Would that be an option to add that to this docker image?

[adilfulara]

Any update to this issue? We are trying to run this in a Kubernetes cluster and really care about the security context in which all of our containers run. It would be very useful to not have to roll our own specialty image to manage this.

You folks allow some configuration of the docker based deployment to be injected via environment variables. Would that be an option to add that to this docker image?

Your best bet is to create a custom docker image based on the official docker image. That will enable you to impose your orgs policies. We ended up dong the same rather than wait.