How can I restrict pg_net queue access when net objects are owned by supabase_admin?

[mimiru9101-lgtm]

Hi, I’m trying to establish a supported permissions setup before enabling scheduled HTTP calls through pg_net.

The request would contain a reusable authentication token retrieved from Vault. I want to prevent application database roles from reading that token from the request queue.

Local environment

• Supabase CLI database image: public.ecr.aws/supabase/postgres:17.6.1.166
• PostgreSQL: 17.6
• pg_net: 0.20.4
• Extension schema: extensions
• Runtime schema: net

The database is healthy. This is a permissions question, not a connectivity problem.

Observed permissions

The extension and net objects are owned by supabase_admin, which is also the recorded ACL grantor.

In this local instance:

• PUBLIC has schema USAGE and queue/response/sequence privileges.
• Application roles also have direct schema USAGE and HTTP GET/POST EXECUTE grants.
• anon, authenticated, and service_role have effective SELECT access to the queue and response tables.

The postgres role has usage permissions but no relevant ownership, grant options, superuser privileges, or membership in supabase_admin.

What I tried

REVOKE ALL ON SCHEMA net FROM PUBLIC, anon, authenticated, service_role;

PostgreSQL returned:

WARNING: no privileges could be revoked for "net"

Effective access remained unchanged. I stopped there; table, sequence, and function revocations were not attempted.

Intended boundary

Our intended configuration denies these application roles access to net objects while preserving access required by the authorized dispatcher and extension worker.

I understand that being outside the exposed Data API schemas is different from denying access at the database-role level.

Transport is still inactive, and no invocation token has been added to the queue.

Questions

1. Is there a supported procedure for managing these owner-granted ACLs on this local CLI image? Which administrator or delegated role should perform it?
2. Is an equivalent procedure available on hosted Supabase? I have not verified hosted ACLs and do not assume they match the local instance.
3. Would these restrictions interfere with pg_net operation, and could extension upgrades restore the grants?
4. If this ACL configuration is unsupported, what approach is recommended for protecting reusable secrets in scheduled HTTP request headers?

Documentation pointers or experience with this version would be appreciated. Thanks!

[Jorge-Polanco-Roque]

Yeah, there are actually two different things going on here, and neither one is going to work the way you tried it.

First, why the revoke did nothing. That WARNING: no privileges could be revoked isn't really about anon/authenticated/service_role, it's about the role you're running it as. In Postgres a privilege can only be revoked by whoever granted it (or by someone holding it WITH GRANT OPTION). Everything in net was granted by supabase_admin, and your postgres role isn't a superuser, isn't a member of supabase_admin, and wasn't the grantor, so there's literally nothing for it to revoke and Postgres just shrugs with that warning.

Second, even if you were the right role, REVOKE ... ON SCHEMA net only covers the schema-level stuff (USAGE and CREATE). The SELECT that lets those roles read the queue lives on the tables themselves, not on the schema. So you'd need something closer to:

REVOKE ALL ON ALL TABLES IN SCHEMA net FROM PUBLIC, anon, authenticated, service_role;
REVOKE ALL ON ALL SEQUENCES IN SCHEMA net FROM PUBLIC, anon, authenticated, service_role;

run as supabase_admin (the owner), not postgres.

One more thing worth knowing (your Q3): extension install/upgrade re-runs the extension's own grant statements, so any manual revoke on net objects gets quietly restored the next time pg_net is upgraded. That by itself makes hand-revoking a fairly leaky boundary.

So honestly, for what you're actually after (Q2 and Q4), I'd stop fighting the ACLs. On hosted you're postgres, not supabase_admin, so you can't durably revoke owner-granted privileges regardless. The pattern that actually holds up is to never store the token in the queue in readable form in the first place. Keep it in Vault and resolve it at dispatch time inside a SECURITY DEFINER function that builds the header, instead of writing the token into a row anything with SELECT on the queue can read. That sidesteps the whole grant fight and it survives upgrades.

I can't point you at an official statement on whether revoking platform grants is supported on hosted (worth pinning that down through the private support request you opened), but the Postgres mechanics above are standard.

[mimiru9101-lgtm]

Thanks for explaining. The grantor/role limitation matches what we found. One thing I’m still unclear about: if a SECURITY DEFINER function reads the token from Vault and passes it as a header to net.http_post(), wouldn’t pg_net still store that resolved header in net.http_request_queue? The docs show a headers column on that table, and requests start after commit: https://supabase.com/docs/guides/database/extensions/pg_net#analyzing-responses That’s the boundary we’re trying to protect. We already planned to retrieve the token from Vault inside the dispatcher, rather than hardcode it. Did you mean a different dispatch mechanism that resolves the secret after the request leaves the SQL queue? If so, could you point me to an example? Also, do you have a reference for which pg_net upgrade scripts restore the grants? We’d like to distinguish a possible upgrade risk from behavior confirmed for our version.

…

---------- Forwarded message --------- 보낸사람: Jorge Polanco ***@***.***> Date: 2026년 9월 14일 (월) 오후 11:25 Subject: Re: [supabase/supabase] How can I restrict pg_net queue access when net objects are owned by supabase_admin? (Discussion #50335) To: supabase/supabase ***@***.***> Cc: mimiru9101-lgtm ***@***.***>, Author < ***@***.***> Yeah, there are actually two different things going on here, and neither one is going to work the way you tried it. First, why the revoke did nothing. That WARNING: no privileges could be revoked isn't really about anon/authenticated/service_role, it's about the role you're running it as. In Postgres a privilege can only be revoked by whoever granted it (or by someone holding it WITH GRANT OPTION). Everything in net was granted by supabase_admin, and your postgres role isn't a superuser, isn't a member of supabase_admin, and wasn't the grantor, so there's literally nothing for it to revoke and Postgres just shrugs with that warning. Second, even if you were the right role, REVOKE ... ON SCHEMA net only covers the schema-level stuff (USAGE and CREATE). The SELECT that lets those roles read the queue lives on the tables themselves, not on the schema. So you'd need something closer to: REVOKE ALL ON ALL TABLES IN SCHEMA net FROM PUBLIC, anon, authenticated, service_role;REVOKE ALL ON ALL SEQUENCES IN SCHEMA net FROM PUBLIC, anon, authenticated, service_role; run as supabase_admin (the owner), not postgres. One more thing worth knowing (your Q3): extension install/upgrade re-runs the extension's own grant statements, so any manual revoke on net objects gets quietly restored the next time pg_net is upgraded. That by itself makes hand-revoking a fairly leaky boundary. So honestly, for what you're actually after (Q2 and Q4), I'd stop fighting the ACLs. On hosted you're postgres, not supabase_admin, so you can't durably revoke owner-granted privileges regardless. The pattern that actually holds up is to never store the token in the queue in readable form in the first place. Keep it in Vault and resolve it at dispatch time inside a SECURITY DEFINER function that builds the header, instead of writing the token into a row anything with SELECT on the queue can read. That sidesteps the whole grant fight and it survives upgrades. I can't point you at an official statement on whether revoking platform grants is supported on hosted (worth pinning that down through the private support request you opened), but the Postgres mechanics above are standard. — Reply to this email directly, view it on GitHub <#50335?email_source=notifications&email_token=CFAB64PAKDPTFAMK5INDB5D5O75UBA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOBUGM2TGNBWUZZGKYLTN5XKMYLVORUG64VFMV3GK3TUVRTG633UMVZF6Y3MNFRWW#discussioncomment-18435346>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/CFAB64PK5H2KBJDOKP5XN4L5O75UBAVCNFSNUABIKJSXA33TNF2G64TZHMZDCNBVHA3TCOJTHNCGS43DOVZXG2LPNY5TCMBYGEZDKMRWUF3AE> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/CFAB64ICPRDGC2QKVOZCPCL5O75UBA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOBUGM2TGNBWUZZGKYLTN5XKMYLVORUG64VFMV3GK3TUVJTG633UMVZF62LPOM> and Android <https://github.com/notifications/mobile/android/CFAB64OXVAHUSXMZSDFXEAL5O75UBA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOBUGM2TGNBWUZZGKYLTN5XKMYLVORUG64VFMV3GK3TUVZTG633UMVZF6YLOMRZG62LE>. Download it today! You are receiving this because you authored the thread.Message ID: ***@***.***>