Sharing a DB user password among units of the app

[Stuart Bishop]

On 25 March 2014 19:47, Andreas Hasenack <andreas at canonical.com> wrote:
> On Tue, Mar 25, 2014 at 7:51 AM, Stuart Bishop <stuart at stuartbishop.net> wrote:
>
>> The simple fix is to add a usernames or extra_usernames parameter on
>> the relation, similar to database, allowing the client to specify a
>> list of extra usernames that should be allowed to connect from the
>> client to this relation's database.
>
> This works, and has the benefit of using randomly generated passwords.
> But I need these to be shared among different services, like mysql's
> shared-db relation.

Right. You would need to specify the password too, and ensure they all match.


>> There are security issues with this approach. A malicious client can
>> specify a database and user with permissions, gaining access to
>> another service's data. If service_a and service_b are related to the
>> same PostgreSQL service, then if service_a is compromised then all of
>> service_b's data is also accessible.
>
> This is the same as with mysql's shared-db relation, right? The same
> risk exists there, as all services have access to each other's
> credentials.

I haven't looked at the implementation, and don't know enough about
mysql's database level security to know if it matters. If a service
can gain access to any database as any user it requests via the
relation, then if it is compromised it can gain access to any database
as any user. I'd rather not add that problem to the PostgreSQL charm
if we can avoid it, or if someone more familiar with juju's internals
can tell me it isn't possible or irrelevant.


>> For your particular use case of patching the database, we could use
>> the db-admin relation. This already connects as a superuser to any
>> database, and we could open that up to connecting to any database as
>> any user without lowering security further.
>
> The patch would be like: "GRANT DELETE ON TABLE person TO landscape".
> That "landscape" is hardcoded, so that user has to exist and be the
> user the services use. So your first paragraph above solves this
> already, right? We give a list of users to postgresql via the
> relation, and "landscape" is in that list.

I see. If this is the issue, then the 'roles' feature already does
what you need: 'relation-set roles=landscape' in your
db-relation-joined hook, and the generated user will be granted the
landscape role and inherit all its permissions (users and groups are
now just roles in postgresql, 'user' and 'group' are just syntactic
sugar and help make documentation more readable). This is the
recommended way of handing database permissions, rather than granting
them individually to all the login roles.


-- 
Stuart Bishop <stuart.bishop at canonical.com>