Sharing a DB user password among units of the app

[Stuart Bishop]

On 27 March 2014 03:49, Andreas Hasenack <andreas at canonical.com> wrote:
> On Tue, Mar 25, 2014 at 12:07 PM, Stuart Bishop
> <stuart.bishop at canonical.com> wrote:
>>> 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
>
> Interesting. So I tried with a dummy charm that joins the postgresql
> db relation. I deployed it as pgsql-test and pgsql-test-second, so,
> two services.

The 'postgresql-psql' charm in the store might be useful for this sort
of experiment too.


> I have two users that can login, one per service: db_27_pgsql_test and
> db_28_pgsql_test_second. These are different users, with different
> credentials. Yet, once they login, they both have the same roles:
> landscape and landscape_maintenance, correct? So whatever the
> landscape role has in terms of permissions, db_27_pgsl_test will have
> too.
>
> In effect it looks like I don't need to share the credentials among
> the services?

Correct. I think you are just fine with one relation per database and
using the generated credentials, and using the granted roles to
control database permissions.

To actually create the tables and grant permissions to the roles, you
can use a db-admin relation (or perhaps 'juju-run' from a subordinate
charm on the PostgreSQL service). Try to avoid the undocumented
'schema_user' and 'schema_password' set of credentials on the db
relation that has permissions - there is a security hole there that
needs to be closed up, probably by dropping the feature entirely (Bug
#1167249).

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