GitHub user dosubot[bot] added a comment to the discussion: Any way to force RLS inheritance from the Guest Token provisioning account, or other techniques to restrict/validate the RLS?
<!-- Greeting --> Hi @carn1x! I'm [Dosu](https://go.dosu.dev/dosubot) and I’m helping the superset team. <!-- Answer --> Superset does not natively support RLS inheritance from the Guest Token provisioning account—RLS rules for Guest Tokens are defined by the provisioning service and included in the token payload, not automatically derived from the provisioning account's own RLS or permissions [ref](https://github.com/apache/superset/blob/master/superset/security/manager.py). To mitigate the risk of misconfiguration or overly permissive RLS (like `1=1`), you can use the server-side `GUEST_TOKEN_VALIDATOR_HOOK` config. This hook lets you enforce custom validation logic on the RLS rules in guest tokens before they're issued. For example, you can require that every RLS clause includes a `tenant_id` condition, or matches a whitelist of allowed tenants [ref](https://github.com/apache/superset/pull/30132). If the hook returns `False` or raises an exception, the token request is rejected [ref](https://github.com/apache/superset/blob/master/tests/integration_tests/security/api_tests.py). There’s no built-in mechanism to enforce a default RLS value or require the tenant column to be a pre-shared secret or hash, but you can implement this logic in your validator hook or in your provisioning service. For extra defense, you could use unguessable tenant identifiers and require them in RLS clauses, as you suggested. Ultimately, the security of guest token-based RLS depends on the correctness and hardening of your token provisioning service and the strictness of your validator hook. Without these, there is a real risk of cross-tenant data leakage if a client or provisioning service is compromised or misconfigured [ref](https://github.com/apache/superset-embedded-sdk/README.md). Best practice: always use the validator hook to enforce strict RLS validation, and treat the provisioning service as a critical security boundary. <!-- Dosu Comment Footer --> *To reply, just mention [@dosu](https://go.dosu.dev/dosubot).* --- <sup>How did I do? [Good](https://app.dosu.dev/response-feedback/60c67f5c-361f-4a80-b8a6-94577e0ab46f?feedback_type=great_response) | [Irrelevant](https://app.dosu.dev/response-feedback/60c67f5c-361f-4a80-b8a6-94577e0ab46f?feedback_type=irrelevant_answer) | [Incorrect](https://app.dosu.dev/response-feedback/60c67f5c-361f-4a80-b8a6-94577e0ab46f?feedback_type=incorrect_sources) | [Verbose](https://app.dosu.dev/response-feedback/60c67f5c-361f-4a80-b8a6-94577e0ab46f?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/60c67f5c-361f-4a80-b8a6-94577e0ab46f?feedback_type=hallucination) | [Report 🐛](https://app.dosu.dev/response-feedback/60c67f5c-361f-4a80-b8a6-94577e0ab46f?feedback_type=bug_report) | [Other](https://app.dosu.dev/response-feedback/60c67f5c-361f-4a80-b8a6-94577e0ab46f?feedback_type=other)</sup> [](https://app.dosu.dev/a28d3c7e-a9d3-459e-9fb6-3a6f9ff4f357/ask?utm_source=github) [](https://cursor.com/link/prompt?text=Superset%20does%20not%20natively%20support%20RLS%20inheritance%20from%20the%20Guest%20Token%20provisioning%20account%E2%80%94RLS%20rules%20for%20Guest%20Tokens%20are%20defined%20by%20the%20provisioning%20service%20and%20included%20in%20the%20token%20payload%2C%20not%20automatically%20derived%20from%20the%20provisioning%20account%27s%20own%20RLS%20or%20permissions%C2%A0%5Bref%5D%28https%3A//github.com/apache/superset/blob/master/superset/security/manager.py%29.%0A%0ATo%20mitigate%20the%20risk%20of%20misconfiguration%20or%20overly%20permissive%20RLS%20%28like%20%601%3D1%60%29%2C%20you%20can%20use%20the%20server-side%20%60GUEST_TOKEN_VALIDATOR_HOOK%60%20config.%20This%20hook%20lets%20you%20enforce%20custom%20validation%20logic%20on%20the%20RLS%20rules%20 in%20guest%20tokens%20before%20they%27re%20issued.%20For%20example%2C%20you%20can%20require%20that%20every%20RLS%20clause%20includes%20a%20%60tenant_id%60%20condition%2C%20or%20matches%20a%20whitelist%20of%20allowed%20tenants%C2%A0%5Bref%5D%28https%3A//github.com/apache/superset/pull/30132%29.%20If%20the%20hook%20returns%20%60False%60%20or%20raises%20an%20exception%2C%20the%20token%20request%20is%20rejected%C2%A0%5Bref%5D%28https%3A//github.com/apache/superset/blob/master/tests/integration_tests/security/api_tests.py%29.%0A%0AThere%E2%80%99s%20no%20built-in%20mechanism%20to%20enforce%20a%20default%20RLS%20value%20or%20require%20the%20tenant%20column%20to%20be%20a%20pre-shared%20secret%20or%20hash%2C%20but%20you%20can%20implement%20this%20logic%20in%20your%20validator%20hook%20or%20in%20your%20provisioning%20service.%20For%20extra%20defense%2C%20you%20could%20use%20unguessable%20tenant%20identifiers%20and%20require%20them%20in%20RLS%20clauses%2C%20as%20you%20suggested.%0A%0AUltimatel y%2C%20the%20security%20of%20guest%20token-based%20RLS%20depends%20on%20the%20correctness%20and%20hardening%20of%20your%20token%20provisioning%20service%20and%20the%20strictness%20of%20your%20validator%20hook.%20Without%20these%2C%20there%20is%20a%20real%20risk%20of%20cross-tenant%20data%20leakage%20if%20a%20client%20or%20provisioning%20service%20is%20compromised%20or%20misconfigured%C2%A0%5Bref%5D%28https%3A//github.com/apache/superset-embedded-sdk/README.md%29.%0A%0ABest%20practice%3A%20always%20use%20the%20validator%20hook%20to%20enforce%20strict%20RLS%20validation%2C%20and%20treat%20the%20provisioning%20service%20as%20a%20critical%20security%20boundary.) [](https://go.dosu.dev/discord-bot) [](https://twitter.com/intent/tweet?text=%40dosu_ai%20helped%20me%20solve%20this%20issue!&url=https%3A//github.com/apache/superset/dis cussions/37251) GitHub link: https://github.com/apache/superset/discussions/37251#discussioncomment-15539164 ---- 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]
