PostgreSQL gssencmode 기준 정리

본문 중간의 쿠팡 추천 상품 구매시 쿠팡 파트너스에서 일정액의 수수료를 제공받습니다.

PostgreSQL gssencmode 기준 정리

gssencmode는 libpq 계열 PostgreSQL 클라이언트가 TCP 연결에서 GSSAPI 암호화를 시도할지 정하는 연결 옵션이다. 2026년 7월 29일 확인한 PostgreSQL 18 공식 문서 기준으로 disable, prefer, require 세 값을 지원하며, 기본값은 GSSAPI 지원 빌드에서 prefer다.

실무에서 핵심은 세 가지다. Kerberos 같은 GSSAPI 인프라가 실제로 있는지, SSL보다 GSS 암호화를 우선할지, 그리고 서버 쪽에서 GSS 암호화를 강제해야 하는지다. 이 기준을 분리해서 보면 sslmode와 같이 써도 의미가 더 분명해진다.

gssencmode는 무엇을 제어할까?

PostgreSQL 공식 문서는 gssencmode가 secure GSS TCP/IP connection의 협상 여부와 우선순위를 정한다고 설명한다. 즉 인증 자체만이 아니라, 클라이언트와 서버 사이의 전송 구간을 GSSAPI로 암호화할지 선택하는 값이다.

이 옵션은 Unix domain socket 통신에서는 무시된다. 따라서 로컬 소켓으로만 접속하는 애플리케이션이라면 gssencmode를 조정해도 체감 동작이 바뀌지 않을 수 있다.

세 가지 값은 어떻게 다를까?

값	의미	실무 판단
disable	GSSAPI 암호화 연결을 시도하지 않고 비 GSS 연결만 시도한다.	SSL을 명시적으로 쓰고 싶거나 GSS 인프라가 없는 환경에 맞다.
prefer	자격 증명 캐시에 GSSAPI 자격 증명이 있으면 먼저 GSS 암호화를 시도하고, 실패하거나 자격 증명이 없으면 비 GSS 연결을 시도한다.	기본값이지만, 암호화를 반드시 강제하는 값은 아니다.
require	GSSAPI 암호화 연결만 시도한다.	Kerberos 기반 내부망처럼 GSS를 반드시 써야 할 때 적합하다.

공식 문서에는 PostgreSQL이 GSSAPI 지원 없이 빌드된 경우 require는 오류를 일으키고, prefer는 받아들여지지만 실제 GSS 암호화 시도는 하지 않는다고 적혀 있다. 따라서 운영 문서에 prefer만 적어 두면, 실제 배포 바이너리의 빌드 옵션 차이까지 숨길 수는 없다.

sslmode와는 어떤 관계일까?

PostgreSQL 18 libpq 연결 문서는 GSSAPI 암호화가 가능하면 sslmode 값과 관계없이 SSL보다 GSS 암호화를 우선 사용한다고 설명한다. 따라서 공개 CA 기반 TLS를 의도한 환경인데 Kerberos 인프라도 정상 동작한다면, 생각보다 먼저 GSS 쪽으로 연결될 수 있다.

반대로 SSL 사용을 강제하고 싶다면 PostgreSQL 공식 문서는 gssencmode=disable을 함께 두라고 안내한다. 즉 sslmode=verify-full만으로는 "반드시 SSL을 사용한다"는 뜻이 완전히 닫히지 않는다.

 

 

prefer를 기본값으로 그대로 써도 될까?

prefer는 편의성 중심 기본값에 가깝다. 자격 증명 캐시에 GSS 자격 증명이 있으면 암호화를 시도하지만, 실패하거나 자격 증명이 없을 때 비 GSS 연결로 내려갈 수 있기 때문이다. 내부 보안 정책에서 전송 구간 암호화를 반드시 요구한다면 이 값만으로 충분하다고 보기 어렵다.

공식 GSSAPI 암호화 문서는 기본적으로 이 협상 결정이 클라이언트에 달려 있고, 이 때문에 공격자가 다운그레이드할 수 있다고 설명한다. 따라서 "가능하면 GSS를 쓰기"와 "반드시 GSS를 쓰기"는 다른 요구사항으로 봐야 한다.

언제 require를 검토해야 할까?

Kerberos 또는 다른 GSSAPI 기반 인증 체계를 이미 운영하고 있고, 내부 규정상 데이터베이스 전송 구간도 그 체계로 보호해야 한다면 require가 더 직접적이다. 이 경우 클라이언트가 GSS 암호화 없이 접속하지 못하므로 정책 위반 연결을 조기에 막을 수 있다.

다만 이 선택은 전제 조건이 분명하다. 클라이언트와 서버 모두 GSSAPI 구현체가 설치되어 있어야 하고, PostgreSQL 빌드에도 관련 지원이 들어 있어야 한다. 일부 클라이언트만 이 조건을 만족하지 못하면 운영 혼선이 생길 수 있다.

환경 변수로도 설정할 수 있을까?

가능하다. PostgreSQL 공식 문서는 PGGSSENCMODE 환경 변수가 gssencmode 연결 파라미터와 같은 역할을 한다고 설명한다. 다만 libpq 연결 파라미터 처리 순서를 보면, 연결 문자열이나 명시적 파라미터가 먼저 적용되고 남은 미설정 항목에 환경 변수와 기본값이 채워진다.

여러 애플리케이션이 같은 계정을 공유하는 환경이라면 전역 환경 변수보다 각 애플리케이션의 연결 문자열에 명시하는 편이 설정 경계를 나누기 쉽다. 반대로 공통 정책을 한 번에 맞춰야 하는 배치 계정이라면 환경 변수 방식이 단순할 수 있다.

어떤 경우에 무엇을 고르면 될까?

• Kerberos 인프라가 없고 TLS를 표준화할 계획이라면 gssencmode=disable과 적절한 sslmode 조합이 더 예측 가능하다.
• 내부망에 GSS 자격 증명 캐시가 자연스럽게 배포되고, 실패 시 일반 연결 허용이 괜찮다면 prefer가 무난하다.
• GSS 암호화를 보안 요구사항으로 강제해야 한다면 require를 검토한다.
• SSL 인증서 검증을 반드시 적용해야 하는 환경에서는 GSS가 SSL보다 우선될 수 있다는 점을 먼저 확인한다.
• 연결 정책을 문서화할 때는 클라이언트 빌드에 GSS 지원이 포함되는지도 함께 적는다.

FAQ

gssencmode=require면 인증도 자동으로 GSSAPI만 쓰게 될까?

그렇지 않다. PostgreSQL 공식 GSSAPI 암호화 문서는 GSS 암호화와 GSS 인증을 함께 쓰는 것이 일반적이지만, 다른 PostgreSQL 인증 방식을 추가로 선택하는 것도 가능하다고 설명한다.

sslmode=verify-full을 써도 GSS 암호화가 먼저 선택될 수 있을까?

그럴 수 있다. PostgreSQL 18 공식 문서는 GSSAPI 암호화가 가능하면 sslmode 값과 관계없이 SSL보다 우선한다고 설명한다.

로컬 소켓 접속에도 gssencmode를 맞춰야 할까?

아니다. 공식 문서 기준으로 gssencmode는 Unix domain socket 통신에서 무시된다.

참고 자료

• PostgreSQL 18 libpq connection parameters
• PostgreSQL 18 secure TCP/IP connections with GSSAPI encryption
• PostgreSQL 18 libpq environment variables