[nexus3] Allow user credentials specified by kubernetes secret

[springroll12]

Description

From what I can see, except for the admin user, users generated by this helm chart are given a randomly generated password. In most cases it makes sense to pre-generate these passwords and feed them into the chart via a kubernetes secret.

Would it be a simple task to allow this?

[stevehipwell]

@springroll12 I assume you're referring to the users created from config.users? If so this is an explicit choice based on keeping the configuration as simple as possible and not wanting to promote the use of users over roles and an external auth system. The only reason I added support for users in the first place was to be able to support adding the anonymous user, which obviously doesn't require credentials.

[springroll12]

Yes I was referring to config.users.

I would love to use an external auth system for Nexus but the OSS version does not support it natively. There is a lot of extra effort in figuring out how to handle authorization for different types of repositories that seems non-trivial to implement. If you know of a simple way to do this other than proxy authentication then I would love to hear it.

I don't think it would be difficult to add an optional field for the name of the secret or env variable to use for specific users?

[stevehipwell]

@springroll12 you can use LDAP and configure it through my Helm chart.

[springroll12]

@stevehipwell Unfortunately LDAP is not available to us. I think this is not uncommon, especially for small deployments of nexus. Would it be possible to update the chart to pull username/passwords or even full x-user.json files from a secret?

It might be possible to achieve this by mounting x-user.json files to the ${base_dir}/conf/ directory per https://github.com/stevehipwell/helm-charts/blob/main/charts/nexus3/files/configure.sh#L61 ?

[EugenMayer]

@springroll12 if you terraform you can use https://registry.terraform.io/providers/datadrivers/nexus/latest/docs to configure your entire nexus.

I was very surprised to see which customization level @stevehipwell included in this charts .. with all the config parts. Impressive but also a huge maintenance effort for a helm chart. Kudos!

[stevehipwell]

@springroll12 I'm not sure I've got the time to add this capability right now or if I want to even support it. My long term plan was to refactor the config out into job run as a hook but I'm not sure on the direction of OSS Nexus so haven't wanted to spend any time until that clears up. Longer term this would fit a Kubernetes operator but that should be something driven by Sonatype.

FYI I no longer directly consume this chart myself although I'm aware of people in my company who do so.

[EugenMayer]

I'm not sure on the direction of OSS Nexus so haven't wanted to spend any time until that clears up

Nice to see that i'am not the only one with that gut feeling. Well things changed since they have been bought 2019 .. all the issues with OSS Index, rate limits, min tier from 35 (was 10) .. kind of seems someone is pressing the company. US style investment i guess, similar story for rundeck.

Not sure how nexus OSS turns out too, but there are hardly any alternatives yet. Github packages is for really small scale only, sure there is artifactory .. which is even more expensive in the scale nexus OSS plays.

[springroll12]

@stevehipwell No problem. As @EugenMayer mentioned we greatly appreciate you maintaining the chart as it stands.

We are looking at creating an "extraInitContainer" to solve this for ourselves, and if it makes sense we will make a PR or comment here for posterity.

[stevehipwell]

@springroll12 if you're engineering something and would like to contribute a PR I'd consider something for this similar to how you can pass repo credentials via a secret.

[springroll12]

For what its worth, we did not end up using an initContainer or modifying the helm chart to suit our needs. In the end we wrote a modified configure.sh which mapped the users we needed to static secrets loaded in via environment variables. Then we used helm post-render hooks to replace the postInit command of the nexus deployment with a command to run our custom configure.sh.

Not really an elegant or scalable solution, so we don't think it's worthy of contributing. However it may help future folks looking to do something similar.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stevehipwell]

@springroll12 do you still require this functionality? I've refactored the chart and this should be possible in the same way the repo secrets are handled.

[mreiche]

@springroll12 do you still require this functionality? I've refactored the chart and this should be possible in the same way the repo secrets are handled.

I need it for fully automated rollout without LDAP. How is your approach implemented?

[stevehipwell]

@mreiche it's on the README under config.ldap using the standard secret/key pattern.

config:
  ldap:
    authPassword:
      secret: my-secret
      key: password

[mreiche]

@stevehipwell I mean passing user credentials (passwords) via. values.yml to configure.sh instead of configuring LDAP. In our Air-Gap environment, we just need a list of static users. Your answer suggests that you have already implemented this.

If not, I could do it.

[stevehipwell]

@mreiche sorry I missed the WITHOUT part of your comment. This hasn't been implemented yet, but I'm happy to add it.