같은 접속 계정으로 실행과 스키마 변경을 처리하지 않습니다

9월 초에는 서비스별 PostgreSQL 역할과 데이터베이스 소유권을 정리했습니다. 애플리케이션이 업무 데이터를 읽고 쓰는 권한과 migration이 테이블을 생성하거나 변경하는 권한은 사용 목적이 다릅니다.

CloudNativePG의 역할 관리와 Secret 기반 접속 구성을 확인하고, 실행 계정에는 업무에 필요한 권한만 연결하는 방식으로 경계를 나눴습니다. 아래 SQL은 권한 구조를 설명하는 가상의 schema와 역할입니다. 비밀번호를 생성하거나 실제 운영 계정을 변경하는 스크립트는 아닙니다.

SQL
CREATE ROLE example_runtime NOLOGIN;
GRANT USAGE ON SCHEMA example_app TO example_runtime;
GRANT SELECT, INSERT, UPDATE, DELETE
  ON ALL TABLES IN SCHEMA example_app TO example_runtime;
GRANT USAGE, SELECT
  ON ALL SEQUENCES IN SCHEMA example_app TO example_runtime;

NOLOGIN 역할은 권한을 묶는 그룹으로 사용할 수 있습니다. 실제 애플리케이션의 로그인 역할에 이 역할을 부여하면 비밀번호 관리와 데이터 접근 권한을 분리할 수 있습니다. 서비스별로 별도 접속 계정을 사용하고 관리자 계정을 공용 실행 계정으로 사용하지 않습니다.

새 테이블에도 권한이 이어지도록 설정합니다

기존 테이블에 대한 GRANT만 하면 다음 migration에서 만든 테이블의 권한이 빠질 수 있습니다. 테이블을 실제로 생성하는 owner 역할을 지정해 default privileges를 설정합니다.

SQL
ALTER DEFAULT PRIVILEGES FOR ROLE example_owner
  IN SCHEMA example_app
  GRANT SELECT, INSERT, UPDATE, DELETE ON TABLES TO example_runtime;
ALTER DEFAULT PRIVILEGES FOR ROLE example_owner
  IN SCHEMA example_app
  GRANT USAGE, SELECT ON SEQUENCES TO example_runtime;

이 설정은 example_owner가 앞으로 생성하는 객체에 적용합니다. 다른 역할이 테이블을 만들면 동일하게 적용되지 않으므로 migration 접속 역할과 SET ROLE 정책을 대조합니다. 이미 존재하는 객체에는 앞의 GRANT가 따로 필요합니다.

허용된 작업과 거절된 작업을 함께 확인합니다

검증에서는 실행 계정의 업무 조회와 저장, migration 역할의 스키마 변경, 다른 서비스 데이터에 대한 접근 경계를 확인합니다. has_table_privilege로 특정 테이블의 SELECT 권한을 조회하고 pg_roles에서 superuser와 createdb 같은 관리자 권한을 점검할 수 있습니다.

역할 분리는 DB 이름을 서비스별로 나누는 것만으로 끝나지 않습니다. 실제 연결 Secret, 객체 owner, 기존 GRANT와 미래 객체 권한이 같은 경계를 가리키는지 확인했습니다.