continuum-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Deng Ching <>
Subject Securing working copies in build agent (CONTINUUM-2632)
Date Tue, 31 May 2011 08:57:18 GMT
Currently, there is no security implemented for accessing (read-only) the
working copies in the build agent via webdav. For CONTINUUM-2632, I'm
planning to use a similar mechanism as with Maven when downloading/getting
artifacts from a secured repository:

1. Configure access credentials in continuum-buildagent.xml (or a new
configuration file, maybe continuum-buildagent-security.xml?). We can have
the access configuration either by user (Option A) or by project group
(Option B).

    ** Option A: Access to the working copy will be controlled per user,
making it more granular. The <projectGroupIds> element can contain a
comma-separated list of all the IDs of the project groups that the user
should be able to access. Drawback with this option is that the
configuration in the config file will be longer (compared to option B) if
there are a lot of users.

> <userAccess>
>   <username>dev1</username>
>   <password>encrypted.password</password>
>   <projectGroupIds>,</projectGroupIds>
> </userAccess>

   ** Option B: Access to the working copy will be per project group. All
devs/users of a project group will use the same access key to view the
project group's working copy. Drawback with this option is that the secret
key is shared across multiple users (e.g. devs and users for the project

>   <projectGroupAccessId></projectGroupAccessId>
>   <secretKey>encryptedsecretkey</secretKey>
> </projectGroupAccess>

2.  Use Maven's encryption API (that is used for encrypting/decrypting
server credentials in settings.xml) to encrypt and decrypt the secret keys,
and the use of a master password.

On a related note, for CONTINUUM-2044 (Build agent should only accept
requests from its master), it was suggested in the discussion threads linked
below to use a shared key between the master and the build agent. We can
extend the implementation proposed above by having a separate configuration
for the continuum master's access key, where the build agent can match the
access key provided by the master when it invokes a call to the build agent
(sample configuration below). In case we go in the direction of allowing a
build agent to have multiple masters in future, the following configuration
would be able to accomodate it as well.

>   <continuumMasterAccessKey>
>     <id>master_url_id</id> // may not necessarily be the url of the
> continuum master, we can use a different identifier
>     <secretKey>encryptedsecretkey</secretKey>
>   </continuumMasterAccessKey>
> </continuumMasterAccessKeys>

Any thoughts or suggestions? :)


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message