Thread: Pgadmin python executable requires extended capabilities
Hello all,
I'm trying to run pgadmin in a Kubernetes cluster with enforced Pod Security Policies. Long story short, in the cluster, none of the Linux capabilities are allowed.
The Dockerfile enables this for the python exec:
setcap CAP_NET_BIND_SERVICE=+eip /usr/bin/python3.8 && \
So the entrypoint.sh fails at startup time, as soon as it invokes the python executable:
/entrypoint.sh: line 70: /venv/bin/python3: Operation not permitted
I removed this requirement creating a new Docker image with the following definition:
FROM dpage/pgadmin4:5.5
USER root
RUN setcap -r /usr/bin/python3.8
USER pgadmin
And then it boots without problem (using the 5050 port).
Do you think it makes sense to modify the main Dockerfile to avoid this problem? Is there any other workaround that doesn't require creating a new image?
Thanks.
Hi
On Mon, Jul 19, 2021 at 8:53 PM Albert Serrallé <albert.serralle@adevinta.com> wrote:
Hello all,I'm trying to run pgadmin in a Kubernetes cluster with enforced Pod Security Policies. Long story short, in the cluster, none of the Linux capabilities are allowed.The Dockerfile enables this for the python exec:setcap CAP_NET_BIND_SERVICE=+eip /usr/bin/python3.8 && \So the entrypoint.sh fails at startup time, as soon as it invokes the python executable:/entrypoint.sh: line 70: /venv/bin/python3: Operation not permittedI removed this requirement creating a new Docker image with the following definition:FROM dpage/pgadmin4:5.5
USER root
RUN setcap -r /usr/bin/python3.8
USER pgadminAnd then it boots without problem (using the 5050 port).Do you think it makes sense to modify the main Dockerfile to avoid this problem?
If we do that, then we break the container for anyone who is using a privileged port for the server (e.g. everyone using default settings). I don't see how we could introduce such a change without causing problems for such users.
Is there any other workaround that doesn't require creating a new image?
Not that I can think of, I'm afraid.
Maybe have a separated Dockerfile for unprivileged setups? Does it make sense? Maybe with an extra validation of settings in the entrypoint.sh.
Nginx does something like that: https://github.com/nginxinc/docker-nginx-unprivileged
On Tue, 20 Jul 2021 at 10:12, Dave Page <dpage@pgadmin.org> wrote:
Hi--On Mon, Jul 19, 2021 at 8:53 PM Albert Serrallé <albert.serralle@adevinta.com> wrote:Hello all,I'm trying to run pgadmin in a Kubernetes cluster with enforced Pod Security Policies. Long story short, in the cluster, none of the Linux capabilities are allowed.The Dockerfile enables this for the python exec:setcap CAP_NET_BIND_SERVICE=+eip /usr/bin/python3.8 && \So the entrypoint.sh fails at startup time, as soon as it invokes the python executable:/entrypoint.sh: line 70: /venv/bin/python3: Operation not permittedI removed this requirement creating a new Docker image with the following definition:FROM dpage/pgadmin4:5.5
USER root
RUN setcap -r /usr/bin/python3.8
USER pgadminAnd then it boots without problem (using the 5050 port).Do you think it makes sense to modify the main Dockerfile to avoid this problem?If we do that, then we break the container for anyone who is using a privileged port for the server (e.g. everyone using default settings). I don't see how we could introduce such a change without causing problems for such users.Is there any other workaround that doesn't require creating a new image?Not that I can think of, I'm afraid.
On Tue, Jul 20, 2021 at 1:43 PM Dave Page <dpage@pgadmin.org> wrote:
HiOn Mon, Jul 19, 2021 at 8:53 PM Albert Serrallé <albert.serralle@adevinta.com> wrote:Hello all,I'm trying to run pgadmin in a Kubernetes cluster with enforced Pod Security Policies. Long story short, in the cluster, none of the Linux capabilities are allowed.The Dockerfile enables this for the python exec:setcap CAP_NET_BIND_SERVICE=+eip /usr/bin/python3.8 && \So the entrypoint.sh fails at startup time, as soon as it invokes the python executable:/entrypoint.sh: line 70: /venv/bin/python3: Operation not permittedI removed this requirement creating a new Docker image with the following definition:FROM dpage/pgadmin4:5.5
USER root
RUN setcap -r /usr/bin/python3.8
USER pgadminAnd then it boots without problem (using the 5050 port).Do you think it makes sense to modify the main Dockerfile to avoid this problem?If we do that, then we break the container for anyone who is using a privileged port for the server (e.g. everyone using default settings). I don't see how we could introduce such a change without causing problems for such users.
Two separate containers can help.
-- Ashesh
--Is there any other workaround that doesn't require creating a new image?Not that I can think of, I'm afraid.
On Tue, Jul 20, 2021 at 9:30 AM Ashesh Vashi <ashesh.vashi@enterprisedb.com> wrote:
On Tue, Jul 20, 2021 at 1:43 PM Dave Page <dpage@pgadmin.org> wrote:HiOn Mon, Jul 19, 2021 at 8:53 PM Albert Serrallé <albert.serralle@adevinta.com> wrote:Hello all,I'm trying to run pgadmin in a Kubernetes cluster with enforced Pod Security Policies. Long story short, in the cluster, none of the Linux capabilities are allowed.The Dockerfile enables this for the python exec:setcap CAP_NET_BIND_SERVICE=+eip /usr/bin/python3.8 && \So the entrypoint.sh fails at startup time, as soon as it invokes the python executable:/entrypoint.sh: line 70: /venv/bin/python3: Operation not permittedI removed this requirement creating a new Docker image with the following definition:FROM dpage/pgadmin4:5.5
USER root
RUN setcap -r /usr/bin/python3.8
USER pgadminAnd then it boots without problem (using the 5050 port).Do you think it makes sense to modify the main Dockerfile to avoid this problem?If we do that, then we break the container for anyone who is using a privileged port for the server (e.g. everyone using default settings). I don't see how we could introduce such a change without causing problems for such users.Two separate containers can help.
Sure, but that requires more testing and more builds to maintain. If this were a common request, I would be inclined to re-prioritise the resources to handle the additional work, however resources are thin (as always), and it doesn't make sense in response to a single request (with apologies to Albert of course).
I understand, as we can easily build our own modified image without the extra capability, we're not blocked by this.
Thanks for considering it, anyway!