Tuesday, March 22, 2022

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

> On 22 Mar 2022, at 19:22, Johannes Kastl <kastl@b1-systems.de> wrote:
>
> Hi all,
>
> finally I had some time to try and get the 389ds server running in Kubernetes.
>
> As I am also still learning Kubernetes (and will be for the next few years, always something new to learn), I tried to get this into a helm chart. And: It works!
>
>> https://github.com/johanneskastl/389server-helm-chart/tree/main/charts/389server
>
> This means, I can create a Kubernetes secret containing the DS_DM_PASSWORD and SUFFIX_NAME variables, and the pod running inside Kubernetes gets those values injected from the secret.
> I could connect to the server using the "cn=Directory Manager", i.e. I get an "No such object" response but no longer a "ldap_bind: Invalid credentials (49)" warning.
>
> There are three questions that I could not answer myself:
>
> 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.

>
> 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.

>
> 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.

>
> Thanks in advance, and have a nice day everyone!

Thanks!

>
> 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
> _______________________________________________
> 389-users mailing list -- 389-users@lists.fedoraproject.org
> To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org
> Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org
> Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure

--
Sincerely,

William Brown

Senior Software Engineer,
Identity and Access Management
SUSE Labs, Australia

_______________________________________________
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure

No comments:

Post a Comment