[Supabase] 내 테이블의 계정(User), 역할(Role)과 권한(Policy)에 대해 알기

Supabase로 TABLE을 생성하여 CRUD를 하려 하는데 뭘 할때마다

권한이 없다

접근이 제한되었다

스키마에 당신이 작성한 TABLE이 존재하지 않는다

등 내 기준 쌩뚱맞은 에러가 너무 많이 난다.

아무래도 내가 SQL을 아주 많이 까먹은 것 같은데....다시 복습 겸 정리해야겠다.

 

1. 내가 현재 접속한 계정(User) 알기

SELECT current_user;

이라고 접속하면

이렇게 뜨는데 그럼 여태까지 postgreSQL의 최상위 관리자 계정에서 설정을 진행했다는 뜻이므로 절대 이 계정으로 접속되어 있으면 안된다..

가 정석이지만 Supabase에선 postgres가 아닌 다른 계정으로 접속할 수 없다고 한다.

물론 일반적인 PostgreSQL에선 계정을 바꿀 순 있다. 아니 오히려 바꿔서 해야 한다..!

2. 내 DB의 역할(Role) 전체를 알기

Supabase에서 Database > Configuration > Roles을 검색하면 Supabase에서 제공하는 다양한 Role, 그리고 PostegreSQL의 최고 관리자인 postgres가 나온다. 

핵심적인것만 작성하면 다음과 같다.

1. 애플리케이션 사용자
   1. anon : Anonymous = 익명 사용자, 로그인하지 않은 상태의 클라이언트 요청에 사용된다.
2. 관리 및 접근
   1. anthenticated : 인증된 사용자. 로그인한 사용자의 클라이언트 요청에 사용된다.
   2. postgres : 최고 관리자(Superuser), 모든 권한을 가지며 일반적인 테스트나 운영에서 사용되선 안된다.
   3. supabase_admin : 데이터베이스 관리자. postgres와 유사하나 주로 Supabase 내부 관리 작업에 사용된다.
3. 인증 및 연결
   1. authenticator : 클라이언트의 JWT 토큰을 검증, 세션 권한을 anon 혹은 authenticated로 전환하는 역할. 데이터를 직접 읽거나 쓰지 않는다.
   2. pgbouncer : 연결 풀링 역할. 다수의 클라이언트 요청을 효율적으로 관리하여 DB 부하를 줄인다.

지금 내가 DB에 접속한 계정은 postgres이지만, 실제 서비스에서 클라이언트는 postgres, 즉 계정으로 접근하지 않는다.
Supabase에서는 클라이언트 요청이 들어올 때 ⭐⭐익명 사용자에게는 anon 역할, 로그인한 사용자에게는 authenticated 역할이 자동으로 적용된다. ⭐⭐
anon과 authenticated는 직접 로그인할 수 있는 DB 계정이 아니기 때문에, DB 내부에서 이 역할을 테스트하려면 SET ROLE anon 같은 방식으로 역할을 전환해 동작을 확인한다.

SET ROLE anon;
-- 또는 SET ROLE authenticated;

-- 여기서 테스트 쿼리 실행 (SELECT, INSERT 등)

RESET ROLE; -- 관리자 계정으로 돌아와야 한다.

계정(User) vs 역할(Role)

계정(User)

postgreSQL에서 User는 DB에 접속할 수 있는 주체이다.

즉, 아이디 + 비밀번호로 진짜 접속할 수 있는 사용자

Supabase는 보안과 구조상 PostgreSQL의 일반적인 계정 방식을 제한하고,
결국 직접 DB에 로그인할 때는 postgres 하나만 쓰게 만들어놨다.

 

역할(Role)

권한 묶음(permissions group)의 개념.

어떤 액션을 할 수 있는지, 어떤 테이블을 읽고 쓸 수 있는지, 어떤 정책이 허용되는지에 대한 설정을 한꺼번에 묶어서 적용할 수 있는 것이다. 

즉, 로그인 자체는 User로 하고,
그 User가 어떤 행동을 할 수 있는지는 Role이 결정한다.

 

다시한번 강조하지만, 헷갈리면 안되는 사실은

anon과 authenticated는 계정(User)이 아니라 역할(Role)

3. 내 테이블들의 정책(Policy) 확인하기

지금 내가 사용하는 스키마(public, dalmuri)의 정책을 보면

다음과 같이 되어 있는데, applied to에 public이라고 되어 있다.

 

헷갈리지 않을것 : Row Level Security(RLS)에서 public이 의미하는 대상

여기서 public은 schema에 있는 public이 아니라 anon, authenticated...등등 DB에 접근할 수 있는 '모든 역할(Roles) 그룹'들의 접근을 허용한다는 뜻이다. 

⚠️ 단, postgres(슈퍼계정, 그니까 계정)은 RLS 정책의 영향을 받지 않으며, 어떠한 정책이 설정되어 있어도 모든 테이블에 자유롭게 접근한다 👉 postgres는 “계정(user)”이자 “슈퍼유저 역할”을 동시에 가진 존재 → 일반 역할과 달리 RLS를 아예 무시하고 다 통과한다.

 

public 안에 있는 VIEW는 내가 openAPI로 열어뒀기 때문에 그렇다고 쳐도, dalmuri 스키마 안의 테이블들은 anon, authenticated 역할에서만 접근 가능해야하지 않나? 싶어서 gpt에게 물어봤다..

지피티 왈 👽 :
“dalmuri 스키마 insert/delete는 anon/authenticated만 되게 해야 하지 않나?”
👉 완벽하게 맞아. 그리고 Supabase도 원래 그렇게 동작해.

• open API는 JWT로 Supabase에서 자동으로 ROLE을 정해줘.
• 로그인 안 함 → anon 로그인 함 → authenticated postgres 등은 API로 접근 불가
• 즉, API를 통해 dalmuri에 insert/delete를 할 수 있는 역할은 원래 anon/authenticated 두 개뿐이야.
• 네가 수동으로 다른 ROLE을 만들지 않는다면 다른 ROLE이 접근할 일 자체가 없어.

적절한 권한 설정 :

GRANT INSERT, UPDATE, DELETE ON ALL TABLES IN SCHEMA dalmuri TO anon, authenticated;​

 

“public schema 안의 view는 모든 ROLE(public)에 select 가능하도록 해도 되는 건가?”
👉기술적으로는 “public 그룹에 SELECT를 허용했다”는 뜻이지만, Supabase 환경에서는 다음처럼 작동해:

✔ 실제로 DB에 접근할 수 있는 ROLE은 postgres, anon, authenticated 세 개뿐이야.
이 중에서 API로 접근 가능한 건 anon/authenticated뿐.
즉, 결국 public에 SELECT를 줘도 API를 통해 SELECT를 실행하는 건 anon/authenticated 둘뿐이야.
그래서 “public이라서 아무나 접근 가능할까?”는 걱정하지 않아도 돼.

Supabase에서 권장하는 권한 설정 :

REVOKE ALL ON ALL TABLES IN SCHEMA public FROM public;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO anon, authenticated;​

 

• 권한은 anon, authenticated만 명시적으로 허용
• postgres, supabase_admin 등 시스템 계정에게는 직접 권한을 건드리지 않는다.

 

따라서 CRUD권한은 모든 역할에 주는 것보다 특정 역할(anon, authenticated)에만 주는 쪽이 좋다!

 

public role은 다음 칸에서 바꾸면 된다(쿼리문보단 쉬움)

이제 정상. 아무 role에나 접근해도 함부로 데이터 변경을 막을 수 있다.