handling private user data

[Clint Byrum]

Excerpts from Sidnei da Silva's message of 2012-09-15 10:33:04 -0700:
> On Sat, Sep 15, 2012 at 2:12 PM, Juan Negron <negronjl at xtremeghost.com> wrote:
> > Hi Ricardo:
> >
> > The way you describe in your question ( having a config option that points
> > to a repository, file server, etc. ) seems reasonable to me.
> >
> > Another way would be to have a directory  in the charm itself where you can
> > put said files so the charm can use them.  This would require the
> > devops/user to download the charm before deploying it.  The latter option
> > could be considered a bit more paranoid as it would require you to download
> > the charm, adding the necessary files to a predetermined directory and
> > deploy ( from your local computer ).
> 
> Which of them is safer, from a security standpoint? IE are the configs
> or charms protected in such a way that other charms can't fetch them?
> 

Since the AWS creds to access the S3 control bucket are in ZK, until the
ZK ACL work lands, they are both really unsafe. After ACLs, S3 should
be more safe in that the ACL's on ZK will prevent getting the AWS creds,
and then the S3 ACLs will also prevent arbitrary access to the charms in
the control bucket. Still I wouldn't consider charms private data between
services, as I don't know that its been considered as an attack vector.

Juju's security model still even with ACLs shows too much trust between
service units. We'll have to take a look at containment as juju starts
to want to service more security-sensitive workloads.