You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@superset.apache.org by "carn1x (via GitHub)" <gi...@apache.org> on 2026/01/19 14:01:40 UTC
[D] Any way to force RLS inheritance from the Guest Token provisioning account, or other techniques to restrict/validate the RLS? [superset]
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 notifications@superset.apache.org.
To unsubscribe, please send an email to: notifications-unsubscribe@superset.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@superset.apache.org
For additional commands, e-mail: notifications-help@superset.apache.org
Re: [D] Any way to force RLS inheritance from the Guest Token provisioning account, or other techniques to restrict/validate the RLS? [superset]
Posted by "dosubot[bot] (via GitHub)" <gi...@apache.org>.
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 notifications@superset.apache.org.
To unsubscribe, please send an email to: notifications-unsubscribe@superset.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@superset.apache.org
For additional commands, e-mail: notifications-help@superset.apache.org
Re: [D] Any way to force RLS inheritance from the Guest Token provisioning account, or other techniques to restrict/validate the RLS? [superset]
Posted by "dosubot[bot] (via GitHub)" <gi...@apache.org>.
GitHub user dosubot[bot] edited a comment on 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?utm_source=github&utm_medium=bot-comment&utm_campaign=github-comment-footer-20260415&utm_content=reply-with-mention&utm_term=apache%2Fsuperset).*
---
Docs are dead. Just use [Dosu](https://dosu.dev?utm_source=github&utm_medium=bot-comment&utm_campaign=github-comment-footer-20260415&utm_content=static-docs-tagline&utm_term=apache%2Fsuperset).
[](https://app.dosu.dev/response-feedback?utm_source=github&utm_medium=bot-comment&utm_campaign=github-comment-footer-20260415&utm_content=static-docs-feedback&utm_term=apache%2Fsuperset&message_id=60c67f5c-361f-4a80-b8a6-94577e0ab46f) [](https://github.dosu.com/apache/superset?utm_source=github&utm_medium=bot-comment&utm_campaign=github-comment-footer-20260415&utm_content=static-docs-ask-repo&utm_term=apache%2Fsuperset) [](https://app.dosu.dev/signup?referrer=openSource&source=github-footer&utm_source=github&utm_medium=bot-comment&utm_campaign=github-comment-footer-20260415&utm_content=static-docs-share-team&utm_term=apache%2Fsuperset)
GitHub link: https://github.com/apache/superset/discussions/37251#discussioncomment-15539164
----
This is an automatically sent email for notifications@superset.apache.org.
To unsubscribe, please send an email to: notifications-unsubscribe@superset.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@superset.apache.org
For additional commands, e-mail: notifications-help@superset.apache.org