[389-users] Re: Running 389ds server in Kubernetes: Questions on certificate names and bootstrapping

Hi William,

thanks for the reply.

On 22.03.22 at 23:22 William Brown wrote:
>> On 22 Mar 2022, at 19:22, Johannes Kastl <kastl@b1-systems.de> wrote:

>> 1. Does the docker container have any kind of bootstrapping mechanism included, i.e. I put some LDIF files somewhere and those get imported automatically? Or is the idea to just setup a working server, that the user can then put things into. And that state is being preserved in /data/? I guess it is the latter.
>
> At the moment we can't import an ldif like this. There are lots of issues with state management in this kind of setup, that LDAP is not well suited to cope with.

No problem, then I know that I do not need to build anything like that into the
helm chart.

>> 2. The choice of certificate/key naming is unfortunate, as Kubernetes secrets automatically contain a tls.key and tls.crt file. I can easily inject such a secret, but as 389ds is expecting server.key and server.crt, I guess those files would just be ignored. Right?
>> Could this maybe be enhanced (not changed, to keep backwards compatibility)? That would make life in Kubernetes land easier.
>
> It's annoying that kubernetes is so inflexible in how it emits the certs like this. Can you explain more about how it puts them into the volume or similar? That way we can work out what the right answer is.

Here is an example from another pod, where the Kubernetes secret is mounted into
the pod into /certificate:

> ~ $ ls -lh /certificate/
> total 0
> lrwxrwxrwx 1 root root 14 Mar 23 03:32 tls.crt -> ..data/tls.crt
> lrwxrwxrwx 1 root root 14 Mar 23 03:32 tls.key -> ..data/tls.key
> ~ $

As you can see, there are two "files", that are being generated from the two
key-values-pairs inside the secret. Those are actually linked into that directory.

But the default names are tls.crt and tls.key.

I will try to do subpath mounting, i.e. I will specify where each of the keys is
"mounted" to, aka which file name it gets. But AFAIK this has some drawbacks,
but currently it seems like the only option.

Alternative approach:
I would need to have a look if I can somehow use a different "CMD" in
Kubernetes, I am thinking of a small script that just copies tls.key and tls.crt
from $LOCATION to /data/... somehwere, where 389ds expects them. And then runs
"/usr/lib/dirsrv/dscontainer -r"

>> 3. The Dockerhub page say "Instances now support running dirsrv as non-root...". However I could not get it to run without root permissions. That might have been due to the "wrong" user I picked. So, before spending more time on debugging this, is this still supported? Which user/group should I pick to do that?
>
> Any! What version of the container are you running? You'll need the upstream version which has the correct nsswitch components in place.

I tried running without root permissions, but immediately got CrashLoopBackOff
errors in Kubernetes. But if you say it should work then I will dig deeper into
that and try to get it working.
I am using the latest image from dockerhub, tag 2.0.

Kind Regards,
Johannes

--
Johannes Kastl
Linux Consultant & Trainer
Tel.: +49 (0) 151 2372 5802
Mail: kastl@b1-systems.de

B1 Systems GmbH
Osterfeldstraße 7 / 85088 Vohburg
http://www.b1-systems.de
GF: Ralph Dehner
Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537