If a provider does not know who a consumer is, then the provider cannot authorize the consumer's access to any shared data. The provider could allow the consumer to create new data, but access to any shared or pre-existing data needs to be restricted.
Some charms and services do not handle authorization. If a client unit has been given authentication credentials to Cassandra, then they can access all the data in Cassandra. There is no authorization, just authentication.
Other charms do handle authorization. If a client unit is given authentication credentials to PostgreSQL, then they can only access the tables they create or have been granted access to by other PostgreSQL users. MySQL is similar, as are likely MongoDB and other databases.
A problem occurs when doing redeployments, either redeploying a client application or redeploying a service (such as PostgreSQL, redeploying using existing data from persistent Juju storage). When the client is reconnected to PostgreSQL, PostgreSQL needs to provide them the same authentication credentials as before so the client can access its data. This was quite simple - PostgreSQL and MySQL just used the client application name as the username, and if the client was redeployed with the same name it would be given access to the same database user and would have access to the same data. These charms rely on extracting the remote application name from the $REMOTE_UNIT environment variable in the hook context.
With cross model relations, it was decided that the relation between client and server should be anonymized. $REMOTE_UNIT is now a UUID, and the server does not know the remote client application's name by design. The server now lacks the only trusted information it had, and has no way of providing the correct credentials to a client. Now, when clients are related they must be handed fresh credentials with no access to any existing data.
The relation data set by the client is also untrusted, so the client cannot instruct the server who it is and what privileges it should be granted. The relation data cannot be trusted, because it can be altered by a compromised client and this would allow a compromised client to escalate is privileges.
If anonymization needs to remain, then providers in this situation need some way to de-anonymize the relation. One way would be an action, allowing the operator of the provider charm to map anonymized relations to credentials (so for PostgreSQL, an action that lets you specify which database user a relation should be using). This is more explicit and provides advantages to the $REMOTE_USER heuristic, but does increase operator burden. It also begs the question if anonymization should be done in the first place, given there are charms that cannot be operated securely without de-anonymization.
The postgres charm could generate a unique identifier that cannot really be
guessed (UUID, 256 bytes of random data). And then trust that only a client
that knew that data would be able to present it back to postgres.
(it's essentially just password auth, instead of username auth)
Wouldn't that work?
John
=:->
On Feb 23, 2018 18:01, "Stuart Bishop" <email address hidden> wrote:
> Public bug reported:
>
> If a provider does not know who a consumer is, then the provider cannot
> authorize the consumer's access to any shared data. The provider could
> allow the consumer to create new data, but access to any shared or pre-
> existing data needs to be restricted.
>
> Some charms and services do not handle authorization. If a client unit
> has been given authentication credentials to Cassandra, then they can
> access all the data in Cassandra. There is no authorization, just
> authentication.
>
> Other charms do handle authorization. If a client unit is given
> authentication credentials to PostgreSQL, then they can only access the
> tables they create or have been granted access to by other PostgreSQL
> users. MySQL is similar, as are likely MongoDB and other databases.
>
> A problem occurs when doing redeployments, either redeploying a client
> application or redeploying a service (such as PostgreSQL, redeploying
> using existing data from persistent Juju storage). When the client is
> reconnected to PostgreSQL, PostgreSQL needs to provide them the same
> authentication credentials as before so the client can access its data.
> This was quite simple - PostgreSQL and MySQL just used the client
> application name as the username, and if the client was redeployed with
> the same name it would be given access to the same database user and
> would have access to the same data. These charms rely on extracting the
> remote application name from the $REMOTE_UNIT environment variable in
> the hook context.
>
> With cross model relations, it was decided that the relation between
> client and server should be anonymized. $REMOTE_UNIT is now a UUID, and
> the server does not know the remote client application's name by design.
> The server now lacks the only trusted information it had, and has no way
> of providing the correct credentials to a client. Now, when clients are
> related they must be handed fresh credentials with no access to any
> existing data.
>
> The relation data set by the client is also untrusted, so the client
> cannot instruct the server who it is and what privileges it should be
> granted. The relation data cannot be trusted, because it can be altered
> by a compromised client and this would allow a compromised client to
> escalate is privileges.
>
> If anonymization needs to remain, then providers in this situation need
> some way to de-anonymize the relation. One way would be an action,
> allowing the operator of the provider charm to map anonymized relations
> to credentials (so for PostgreSQL, an action that lets you specify which
> database user a relation should be using). This is more explicit and
> provides advantages to the $REMOTE_USER heuristic, but does increase
> operator burden. It also begs the question if anony...