search

opendevstack / ods-core

The core of OpenDevStack - infrastructure setup based on Atlassian tools, Jenkins, Nexus, SonarQube and shared images
Apache License 2.0
47 stars 34 forks source link

Create project specific Nexus user #321

Open michaelsauter opened 5 years ago

michaelsauter commented 5 years ago

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

tjaeschke commented 4 years ago

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 commented 4 years ago

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

tjaeschke commented 4 years ago

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

segator commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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

Questions we have to answer:

tjaeschke commented 4 years ago

@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 commented 4 years ago

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 commented 4 years ago

Regarding repos:

tjaeschke commented 4 years ago

@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 commented 4 years ago

AFAIK no such structure exists - at least not enforced.

tjaeschke commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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

see https://github.com/opendevstack/ods-core/pull/313

tjaeschke commented 4 years ago

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 commented 4 years ago

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.