Problem with securing self-hosted Supabase

Hello everybody,

I would like to use Supabase for a project, but can’t use the hosted service because of GDPR issues (missing order data processing, AWS as a sub contractor, …). Therefore I tried the self-hosted version.

My setup is highly inspired by the Traefik-based solution from @firstdorsal (Thanks, Paul!)

Bug report

1. /rest is reachable without kong (✔️ solved by this commit)

This is of course a security problem, because the authorization can easily be bypassed. I suppose this is a specific problem of the Traefik solution as it is right now. The official docker solution is providing everything (rest, auth, realtime) only behind kong. Is that right? So the Traefik-version should probably do the same? Right now I have to explicitly access the REST API via /kong/rest/v1, instead of /rest.

2. Row Level Security doesn’t work

I’ve used RLS on hosted Supabase without any problems. Only the allowed data was returned. However after exporting the schema and data from the hosted version and importing it into the self-hosted postgres. The RLS wasn’t working anymore, despite that pgAdmin showed that RLS is active on that table.

To Reproduce

1. Create Supabase project with at least one table with RLS
2. Create a docker based self-hosted Supabase (I did it with Traefik, but that’s probably not important)
3. Regenerate the anon-key and service key like in these instructions
4. Export the schema and data similar “Migrate between projects”, however, here I’ve migrated only public (schema and data) like recommended in the issue #1416. I’ve search and replaced supabase_admin with postgres, because the self-hosted version doesn’t have a supabase_admin.
5. Verify that RLS is active and and the Policies have also been imported (via pgAdmin)
6. Send a request:

docker-compose is showing those two lines on the request: curl --location --request GET 'https://supabase.my-server.com/kong/rest/v1/mytable?select=*' \ --header 'apikey: the-anon-key-generated-in-step-3'

supabase-rest | 172.22.0.4 - - [16/May/2021:14:12:21 +0000] “GET /mytable?select=* HTTP/1.1” 200 - “” “curl/7.76.1” supabase-kong | 172.22.0.2 - - [16/May/2021:14:12:21 +0000] “GET /rest/v1/mytable?select=* HTTP/1.1” 200 727 “-” “curl/7.76.1” Note that rest is printing before kong (why?).

1. See that too much data is returned. An equivalent request to the hosted Supabase is returning the correct data.

Probably kong is assigning the wrong role (not anon)? Or the problem occurs because supabase_admin is not the owner anymore?

bypassrls is only activated for the service_role (like here). I haven’t modified auth-schema.sql nor the 00-initial-schema.sql.

Expected behavior

Row level Security Policies are applied to the returned data by the REST API.

System information

• Server: Ubuntu 20.04
• Docker: 20.10.2

Postgres Roles:

[firstdorsal]

thank you! i’m glad it helped. this is correct. i was not ware that kong handles the access control as i havent got to using supabase myself to be honest ^^ the last commit should fix this right? https://github.com/supabase/supabase/pull/1562/commits/2200e0406b2b29875d892a074d35e65a99ea0b07

best, paul

[ymilhahn]

Fixed by #1692.