[bitnami/openldap] 2.6.4 and later do not start in Kubernetes (using the same deployment as 2.6.3)

[johanneskastl]

Name and Version

bitnami/openldap 2.6.4 and 2.6.5

What architecture are you using?

amd64

What steps will reproduce the bug?

I created a helm chart for openldap that uses the bitnami openldap image. https://github.com/johanneskastl/openldap-bitnami-helm-chart/

I am running 2.6.3 and everything works.

I upgrade the image tag to 2.6.4 and get an error (see below) and the pod does never start.

I upgrade to the 2.6.5 image tag and get the same error.

I use the 2.6.3 tag and everything is working again.

What is the expected behavior?

The pod starts successfully.

What do you see instead?

This is the log from the Kubernetes pod:

 12:30:48.80 INFO  ==> ** Starting LDAP setup **
/opt/bitnami/scripts/openldap/setup.sh: line 82: /opt/bitnami/openldap/sbin/slappasswd: Operation not permitted
/opt/bitnami/scripts/openldap/setup.sh: line 83: /opt/bitnami/openldap/sbin/slappasswd: Operation not permitted
 12:30:48.81 INFO  ==> Validating settings in LDAP_* env vars
 12:30:48.82 INFO  ==> Initializing OpenLDAP...
 12:30:48.82 DEBUG ==> Ensuring expected directories/files exist...
 12:30:48.83 INFO  ==> Using persisted data
 12:30:48.84 INFO  ==> ** LDAP setup finished! **

/opt/bitnami/scripts/openldap/run.sh: line 82: /opt/bitnami/openldap/sbin/slappasswd: Operation not permitted
/opt/bitnami/scripts/openldap/run.sh: line 83: /opt/bitnami/openldap/sbin/slappasswd: Operation not permitted
 12:30:48.85 INFO  ==> ** Starting slapd **
/opt/bitnami/scripts/openldap/run.sh: line 34: /opt/bitnami/openldap/sbin/slapd: Operation not permitted

Additional information

No response

[johanneskastl]

I already tried to explicitly set the LDAP and LDAPS port variables to unprivileged ports. I also tried adding the CAP_NET_BIND capability (as the chart drops all capabilities).

The error is still the same.

[luoyan35714]

I get the same issue on OpenShift.

[andresbono]

Hi, what if you don't drop all the capabilities? Just for testing purposes. Is the error still there?

[johanneskastl]

Hi, what if you don't drop all the capabilities? Just for testing purposes. Is the error still there?

The deployment that is being created by my helm chart already does that:

      containers:
[...]
        securityContext:
          capabilities:
            drop:                             
            - ALL

[andresbono]

My proposal (only for testing purposes) was to remove that block that limits the capabilities. Another thing that you can try is to explicitly add the following capability: NET_BIND_SERVICE. You mentioned it in a previous comment, but just to doublecheck there was not a typo when you first tried (NET_BIND_SERVICE vs CAP_NET_BIND). This would be the values.yaml:

securityContext:
  capabilities:
    drop:
    - ALL
    add:
    - NET_BIND_SERVICE

[johanneskastl]

Aaaah, looks like that did the trick. Thanks for your help!

@luoyan35714 Can you please confirm this also solves the issue for you?

[andresbono]

Great, thanks for confirming! I'm going to mark this issues as closed, but feel free to add new comments if you find problems related to this issue.

[luoyan35714]

@johanneskastl it works for me, thanks a lot!

[jandusek4]

I came across this when trying with latest openldap 2.6.7 and the issue is still there. Why is the new security capability NET_BIND_SERVICE needed from 2.6.3 onwards?

[toffentoffen]

This might be relates to a change in Openshift's SecurityContextConstraints: https://access.redhat.com/solutions/6975936

OpenShift 4.11 introduced the "restricted-v2" SCC in place of the "restricted" SCC known from previous versions. This change was made to adjust security to the current Pod security standards.

The new "restricted-v2" SCC drops "ALL" capabilities from a container (compared to the "restricted" SCC that dropped only a subset), and as a result of this, workloads created in OpenShift 4.11 might fail for a lack of permissions to perform certain operations.

[Deepakganigerupgrad]

i am getting below error message in pod, when i am passing

securityContext:
runAsNonRoot: true

in my deployment.yaml file. I am passing this value because the pod should use the user assigned by ocp not the default user which is 1001. could you please help me here

error:

05:40:47.90 INFO ==> ** Starting LDAP setup **
/opt/bitnami/scripts/openldap/setup.sh: line 102: /opt/bitnami/openldap/sbin/slappasswd: Operation not permitted
/opt/bitnami/scripts/openldap/setup.sh: line 103: /opt/bitnami/openldap/sbin/slappasswd: Operation not permitted
/opt/bitnami/scripts/openldap/setup.sh: line 104: /opt/bitnami/openldap/sbin/slappasswd: Operation not permitted
05:40:47.92 INFO ==> Validating settings in LDAP_* env vars
05:40:47.93 INFO ==> Initializing OpenLDAP...
05:40:48.00 INFO ==> Creating LDAP online configuration
05:40:48.00 INFO ==> Creating slapd.ldif

[Deepakganigerupgrad]

any update?

[jandusek4]

I successfully use this security context on OCP 4.12 and 4.14

          securityContext:
            seccompProfile:
              type: RuntimeDefault
            privileged: false
            allowPrivilegeEscalation: false
            runAsNonRoot: true
            capabilities:
              drop:
                - ALL
              add:
                - NET_BIND_SERVICE

[Deepakganigerupgrad]

@Jan could you please share any documents/notes to build own openldap image?

On Thu, 21 Mar 2024 at 1:43 AM, Jan Dušek @.***> wrote:

I successfully use this security context on OCP 4.12 and 4.14

      securityContext:
        seccompProfile:
          type: RuntimeDefault
        privileged: false
        allowPrivilegeEscalation: false
        runAsNonRoot: true
        capabilities:
          drop:
            - ALL
          add:
            - NET_BIND_SERVICE

— Reply to this email directly, view it on GitHub https://github.com/bitnami/containers/issues/40841#issuecomment-2010539635, or unsubscribe https://github.com/notifications/unsubscribe-auth/BAGDJ2DAYG5RMUFJWNPXXZ3YZHUUZAVCNFSM6AAAAAA2HNRL2CVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMJQGUZTSNRTGU . You are receiving this because you commented.Message ID: @.***>

[jandusek4]

I have not built a custom image, I used the bitnami published one. O only provided the piece i input in the Kubernetes Deployment for it to be able to run in a rootless fashion again - nothing new, it was already provide in previous comments in this thread and adding NET_BIND_SERVICE also worked for me.

[jan]

I'll let @jandusek4 handle this one. Great job so far everyone.

[vlaborie]

The /opt/bitnami/scripts/openldap/postunpack.sh script do a setcap CAP_NET_BIND_SERVICE=+eip on slapd binary which force to have add the NET_BIND_SERVICE capabilities even when listening on ports > 1024.

slappasswd do also an Operation not permitted error because is just a symlink to slapd.

The setcap has probably been added for permitting to run the container as non root user (linked to #63711).

I think the setcap need to be dropped from this script, people who want to run slapd on standard ports need to add NET_BIND_SERVICE capability with Docker params or Kubernetes securityContext.

[vlaborie]

As a workaround, i just rebuild a custom openldap image with a Dockerfile like this:

FROM bitnami/openldap:2.6.8
USER 0
RUN setcap -r /opt/bitnami/openldap/sbin/slapd
USER 1001

And i can run Openldap in Kubernetes without any capabilities (on ports 1389 and 1636).