[Plone-testing-team] S3 bucket account management for collective repositories

Asko Soukka asko.soukka at iki.fi
Sat Mar 1 12:07:14 UTC 2014


Hi,

I'd like to work next week to make it reality that collective
repositories could push their build artifacts into Plone Foundations's
S3 buckets. (An alternative would be to use GitHub Pages, but for me it
still feels scary to make automated pushes from Travis. [Rok is doing
this for p.a.widgets.])
 
The only issues is, how to automate S3 bucket management.

I see two alternatives:


a)

- each collective repository will get its own AWS identity
- each collective repository will get its own S3 bucket
- the identity will be given push permissions to the bucket *)

but

The master identity for creating those collective identities must have
permissions to both create new identities and set their policies. For me
this seems that the master identity would then have permission to give
new identities any permissions it wishes.


b)

- each collective repository will get its own S3 bucket
- all collective repositories would use the same AWS identity for
pushing to their own bucket *)

then

The master identity for creating those collective buckets would require
only a few permissions for S3 (Create new bucket, Set bucket policy and
some other). This could be automated quite safely. No
automated/collective identity would ever get permissions to delete
anything, but it would be possible for collective identities to push to
others' buckets.


To summarize:

a) would be otherwise perfect, but could not be fully automated, because
most probably we don't want to automate user with permissions to set
permissions.

b) could be fully automated, but would give all participating collective
Travis-builds permissions to push to any collective S3 bucket.


Any opinions?

Cheers,
Asko

*) Credentials for collective-repositories would be added and encrypted
into their .travis.yml and only Travis-CI would have knows the private
keys to decrypt those credentials.



More information about the Plone-testing-team mailing list