GitHub user carn1x created a discussion: Any way to force RLS inheritance from the Guest Token provisioning account, or other techniques to restrict/validate the RLS?
My concern currently is that the RLS rules are defined by the client, which to my mind violates some basic security principle, in that the client should prove themselves and are then offered the permissions by the server. In addition I'm slightly terrified of misconfiguration leading to cross-tenant data leakage. I was thinking it would be useful for Guest Tokens to inherit the RLS of their provisioning account. This would then mean that if the token provisioning service became compromised in any way, they would still only have access to what the provisioning credentials themselves have access to. An alternative I could think of would be that the tenant column itself is a pre-shared secret or hash of a secret, so that it would be un-guess-able, meanwhile RLS itself could enforce a default value , in order to prevent a compromised client from simply providing no RLS at all and therefore pulling all data? On one hand perhaps I'm worried I'm overthinking this and perhaps I should just concentrate on hardening the token provisioning service instead, but I can't shake the feeling that the current RLS enforcement technique is a bit of a time bomb? GitHub link: https://github.com/apache/superset/discussions/37251 ---- This is an automatically sent email for [email protected]. To unsubscribe, please send an email to: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
