Continuum and "Private" Projects
Discussion
Continuum offers role-based access control to prevent unauthorized users from viewing the projects through the Web UI, but in some cases this is not secure enough. Especially in corporate environments, there may be "private" projects for which the binaries and filesystem working copy must be protected.
By default, all projects in Continuum will share the same local repository, so other users could access a private project's binaries by declaring a dependency on them.
The private project may need access to third-party binaries that cannot be shared due to contract restrictions with a vendor.
The user running Continuum has access to all the working copies, so a developer on any other project could add a "shell script" type project and gain access to them.
The project's generated binaries and dependencies cannot go into a remote repository to which everyone has access.
Assumptions
- The source code for the private project is secured in a Subversion (or other scm) repository
Requirements
- Continuum's working copies must not be accessible by unauthorized users
- The project's generated binary artifacts must not be accessible by unauthorized users
- Some of the project's binary dependencies must not be accessible by unauthorized users
Strategy
- Establish a separate Continuum instance for the private project. Ensure that user and group filesystem permissions prevent access by other users.
- Establish private releases and snapshots artifact repositories
- Configure the Continuum user with credentials to publish to the private releases and snapshots repositories
- Configure distributionManagement in the private project to publish its artifacts to the private releases and snapshots repositories
- Developers needing to do local builds will configure credentials for the private releases and snapshots repositories in their settings.xml