Closed johanneskastl closed 1 year ago
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.
I get the same issue on OpenShift.
Hi, what if you don't drop all the capabilities? Just for testing purposes. Is the error still there?
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
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
Aaaah, looks like that did the trick. Thanks for your help!
@luoyan35714 Can you please confirm this also solves the issue for you?
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.
@johanneskastl it works for me, thanks a lot!
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?
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.
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
any update?
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
@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: @.***>
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.
I'll let @jandusek4 handle this one. Great job so far everyone.
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.
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).
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:
Additional information
No response