michaeljmarshall commented on pull request #10815: URL: https://github.com/apache/pulsar/pull/10815#issuecomment-855055334
> do you have some suggestion about how to help users work on the pods now that we are rootless ? I think the largest difference is that you cannot download dependencies via `apt`. I've found Bitnami blogs pretty helpful with the non-root container work. They have a blog here that mentions the main challenges that users face when using them: https://engineering.bitnami.com/articles/running-non-root-containers-on-openshift.html and https://docs.bitnami.com/tutorials/work-with-non-root-containers/. (Note that the blogs have some outdated references to limitations of kubernetes.) Depending on how we move forward here, I can add docs for troubleshooting with the non-root docker images. (As the above links describe, one note is that you can still run the container as the root user. If you're starting the docker container yourself, you can specify `--user root`. If the container is already running, you can specify the user when using `docker exec`. In Kubernetes, you can do this by specifying the pod's `securityContext`.) This PR does raise one question for me: what are our container security goals for Pulsar? I agree that development is easier with these tools (and possibly others) in the docker image. However, I'd posit the main use case for these docker images is not development, but is rather running in a production environment where there shouldn't be frequent debugging. These tools technically introduce potential attack vectors and increase the size of these docker images. One option is to create "debug" docker images that include more tools. Given that we already include several pulsar clients in the basic `pulsar` docker image, it's probably reasonable to include these three packages as the PR proposes. If we change direction and have smaller docker images or if we need to add many more packages, we could discuss have "debug" images and limiting the packages shipped in the basic `pulsar` and `pulsar-all` images. Full disclosure, my perspective is influenced by Google's "distroless" work: https://github.com/GoogleContainerTools/distroless. Their perspective is strong (and if you go to their README, you'll see that they make use of "debug" images): > Why should I use distroless images? Restricting what's in your runtime container to precisely what's necessary for your app is a best practice employed by Google and other tech giants that have used containers in production for many years. It improves the signal to noise of scanners (e.g. CVE) and reduces the burden of establishing provenance to just what you need. I'm not sure that Pulsar should (or can) become "distroless", but I do find the principles compelling. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
