Create project specific Nexus user

[michaelsauter]

Instead of one Nexus user, we need one per project (aka initiative).

[tjaeschke]

Just some thoughts.

I think we still need one general Nexus user to use the proxy repos. This would be the developer user, but we should restructure the rights, so only the proxy repos have read access.

For upload, we have two options in general, repository targets and a repo per team. Both seem to fit, but fewer repositories are easier to maintain, while from a security perspective and different lifecycles the option for one repo per team/project seems more vaild.

[tjaeschke]

We will go for the repository target option. This seems to be the most mnimal invasive change according to the logic implemented.

[tjaeschke]

https://help.sonatype.com/repomanager3/configuration/repository-management#RepositoryManagement-ContentSelectors

[segator]

I think devleoper used should not be used,
by default everyone that can login to nexus can read all artifacts, if project needs private access then block everyone read access and only project group team can read the artifacts.

[tjaeschke]

I think devleoper used should not be used,
by default everyone that can login to nexus can read all artifacts, if project needs private access then block everyone read access and only project group team can read the artifacts.

Right, but the general user (guest, developer, read-user...) to access the proxy repos targets automated builds, for example on config change or something similar of base images, that are not controlled by an authenticated user. Maybe I'm missing a point.

[tjaeschke]

We need to create content selectors, privileges and roles and specific nexus users. To do this, we need a user, that is only able to run a script located on nexus. I would assume, we create a enhanced nexus user for the prov-cd namespace, who is able to run a specific script in nexus (e.g. createProjectSpecificNexusAccess). The command for script execution would run in the Jenkins Pipeline, which creates a specific cd project. The script located in nexus will take the project id and return a project specific username and base64 encoded pw, which will be passed to the tailor update script, which creates the project specific Jenkins. So we would restrict access to the scripting API from Nexus, restrict the possibilites of the used script.

[tjaeschke]

After discussing with @michaelsauter there are some things that have to be clarified, before we are able to get this running.
The current implementation would only capture Maven repositories. There we have a defined structure, but there has to be a logic, that also covers other repo types, like python and npm.
There we have to evaluate, if there are simililarities, which can be used by content selectors.
I will document the findings in this issue.

[tjaeschke]

Another point of evaluation is to take changes in the general repo structure in account.

Questions we have to answer:

• What happens, if there are repositories added?
• What has to be done, to enable the specific user to access new repos?
• Is there a way to implement this logic in a way, that we can add additional repos on the fly?
• Are we able to provide a specific user with all rights, the current developer user has?
• How can we handle hosted repositories, shared by different teams? Do we need a logic to specify this.

[tjaeschke]

@michaelsauter There are also questions about the current repository usage. Would you please calrify the usage and provide informations about it, so I'm able to adopt it?

[tjaeschke]

Are we able to provide a specific user with all rights, the current developer user has?

I would purpose, we add the OpenDevStack-Developer role to the specific user and modify the OpenDevStack-Developer role, so the role is only able to read the proxy repositories. Adding, Editing and Viewing of projectspecific data, would be handled by the project specific role.
The specific user would get two roles, the project specific and the OpenDevStack-Developer role.

[michaelsauter]

Regarding repos:

• There is one called leva-documentation, and @metmajer @ungerts might know more about the needs there
• For NPM and Python, there is this setup of one group exposing one (or more) proxies and one hosted repo. E.g. group npmjs includes proxy repo npm-registry and hosted repo npm-private

[tjaeschke]

@michaelsauter Do you know which structure the hosted repos have?

As far as I can see npm has a flat path structure. Do you have naming conventions for the npm packages reflecting the project they belong to?

The same question I have with Python and PEP503 names.

[michaelsauter]

AFAIK no such structure exists - at least not enforced.

[tjaeschke]

AFAIK no such structure exists - at least not enforced.

This is a problem, if you want to isolate assets from different projects from each other, if you don't have a separate repo for each possible hosted repo type for each project. IMHO a massive overhead.

[tjaeschke]

So after evaluation I don't see another possiblitity than a naming convention. The path is the only part all repos have in common. Maybe we can also rewrite an expression matching different repository types and naming conventions.

I have implemented setting a specififc nexus user.
This assumes, that the createProjectSpecificAccess script exists in Nexus and that the nexus user used in prov cd has rights to execute scripts.

The privilege to run scripts can be granted via the Nexus 3 administration.

I will document the way on monday, since the logic will not be part of 2.0.

[tjaeschke]

I propose to move this issue to ods-core, since the logic is handled there.

see #313

[tjaeschke]

Added basic documentation for Nexus 3. Changed the scripts, so the nexus host is no longer hardcoded, but retrieved from the env files. Also the user name can be set in the script.

[tjaeschke]

I think it is important to mention, that at the moment the developer user role hasn't been modified for backward compatibility reasons. The specific nexus user has all rights the developer role has, plus the addition with the content selector.
We will have to define the "default" repositories, but IMO this is something, we will have to define together.