TLS and HTTPS

TLS and HTTPS (TLS와 HTTPS)

Trino 서버가 TLS를 사용해 클라이언트가 HTTPS 연결 프로토콜을 사용하도록 요구하게 구성하는 방법을 설명해요. Trino가 지원하는 모든 인증 기술은 TLS를 기반 계층으로 요구해요.

출처: 문서

본문

Trino는 기본적으로 보안 없이 실행돼요. 이 덕분에 Trino CLI, Web UI 또는 다른 클라이언트를 사용할 때 HTTP 프로토콜을 지정하는 URL로 서버에 연결할 수 있어요.

이 토픽은 Trino 서버가 TLS를 사용해 클라이언트가 HTTPS 연결 프로토콜을 사용하도록 요구하게 구성하는 방법을 설명해요. Trino가 지원하는 모든 인증 기술은 기반 계층으로서 TLS 구성을 요구해요.

Important

이 페이지는 Trino 클러스터 외부에서 클라이언트가 코디네이터에 보안 연결하도록 Trino 서버를 준비하는 방법만 다뤄요. 낯선 용어는 Glossary를 참고하세요.

지원 표준 (Supported standards)

TLS를 사용하도록 구성되면 Trino 서버는 TLS 1.2와 TLS 1.3 인증서로 클라이언트 연결에 응답해요. 서버는 TLS 1.1, TLS 1.0, 그리고 모든 SSL 형식 인증서를 거부해요.

Trino 서버는 지원되는 암호화(cipher) 집합을 지정하지 않고, 사용 중인 JVM 버전이 설정한 기본값에 맡겨요. Java 25 문서에 지원되는 암호화 스위트가 나열돼 있어요.

코디네이터에 구성된 것과 같은 공급업체의 같은 JVM에서 다음 두 줄 코드를 실행해 그 JVM의 기본 암호화 목록을 확인해 보세요:

echo "java.util.Arrays.asList(((javax.net.ssl.SSLServerSocketFactory) \
javax.net.ssl.SSLServerSocketFactory.getDefault()).getSupportedCipherSuites()).forEach(System.out::println)" | jshell -

기본 Trino 서버는 전방 비밀성(FS, forward secrecy)을 지원하지 않는 오래된 암호화 스위트를 제외하는 정규식 집합을 지정해요.

http-server.https.included-cipher 속성을 사용해 선호 사용 순서로 쉼표 구분 암호화 목록을 지정하세요. 선호 선택 중 하나가 비-FS 암호화라면 http-server.https.excluded-cipher 속성을 빈 목록으로 설정해 기본 제외를 재정의해야 해요. 예:

http-server.https.included-cipher=TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA256
http-server.https.excluded-cipher=

다른 암호화 스위트를 지정하는 것은 복잡한 문제라 조직의 보안 관리자와 함께 고려해야 해요. 다른 스위트를 사용하려면 다른 SunJCE 구현 패키지를 다운로드해 설치해야 할 수 있어요. 일부 지역에서는 암호화 스위트에 대한 수출 제한이 있을 수 있어요. Java 문서의 Customizing the Encryption Algorithm Providers로 시작하는 논의를 참고하세요.

Note

코디네이터의 직접 TLS 구현을 관리한다면 HTTPS 활성화 후 Trino 코디네이터의 CPU 사용률을 모니터링하세요. Java는 큰 암호화 목록에서 선택하도록 두면 더 CPU 집약적인 암호화 스위트를 선호해요. HTTPS 활성화 후 CPU 사용률이 받아들일 수 없을 정도로 높다면 이 섹션에서 설명한 대로 Java가 특정 암호화 스위트를 사용하도록 구성할 수 있어요.

하지만 모범 사례는 다음에서 논의하는 대로 외부 로드 밸런서를 사용하는 것이에요.

접근 방법 (Approaches)

Trino를 TLS 지원으로 구성하려면 두 가지 대체 경로를 고려해 보세요:

사이트나 클라우드 환경의 로드 밸런서 또는 프록시를 사용해 TLS/HTTPS를 종료. 이 접근 방식이 가장 간단하고 강력히 선호되는 해결책이에요.
Trino 서버를 직접 보호. 유효한 인증서를 얻어 Trino 코디네이터의 구성에 추가해야 해요.

로드 밸런서로 TLS/HTTPS 종료 (Use a load balancer to terminate TLS/HTTPS)

사이트나 클라우드 환경에 유효하고 전 세계적으로 신뢰받는 TLS 인증서로 구성·실행 중인 로드 밸런서나 프록시 서버가 이미 있을 수 있어요. 이 경우 네트워크 관리자와 협력해 Trino 서버를 로드 밸런서 뒤에 놓을 수 있어요. 로드 밸런서나 프록시 서버는 TLS 연결을 받아 기본 HTTP 구성(기본 포트 8080)으로 보통 실행되는 Trino 코디네이터로 전달해요.

로드 밸런서가 TLS 암호화 연결을 받으면 요청에 X-Forwarded-Proto: https 같은 forwarded HTTP 헤더를 추가해요.

이 헤더는 Trino 코디네이터에게 해당 연결에 대해 TLS 연결이 이미 성공적으로 협상된 것처럼 처리하라고 알려줘요. 그래서 로드 밸런서 뒤의 코디네이터에는 http-server.https.enabled=true를 구성할 필요가 없어요.

하지만 이런 forwarded 헤더 처리를 활성화하려면 서버의 config properties 파일에 다음이 포함되어야 해요:

http-server.process-forwarded=true

HTTP 서버 구성에 대한 자세한 내용은 HTTP server properties에서 확인할 수 있어요.

이것으로 로드 밸런서와 함께 HTTPS를 사용하는 데 필요한 구성을 마쳤어요. 클라이언트 도구는 로드 밸런서가 노출한 URL로 Trino에 접근할 수 있어요.

Trino 직접 보호 (Secure Trino directly)

외부 로드 밸런서를 사용하는 선호 메커니즘 대신 Trino 코디네이터 자체를 보호할 수 있어요. TLS 인증서를 얻어 설치하고 클라이언트 연결에 사용하도록 Trino를 구성해야 해요.

TLS 인증서 추가 (Add a TLS certificate)

Trino 서버에 사용할 TLS 인증서 파일을 얻으세요. 다음 유형의 인증서를 고려해 보세요:

전 세계적으로 신뢰받는 인증서 (Globally trusted certificates) - 모든 브라우저와 클라이언트가 자동으로 신뢰하는 인증서. 클라이언트를 구성할 필요가 없어 가장 쓰기 쉬운 유형이에요. 다음에서 얻을 수 있어요:
- 상업용 인증서 공급업체
- 클라우드 인프라 제공자
- Verisign·GoDaddy 같은 도메인 이름 등록 기관
- letsencrypt.org 또는 sslforfree.com 같은 무료 인증서 생성기
기업 신뢰 인증서 (Corporate trusted certificates) - 조직의 브라우저와 클라이언트가 신뢰하는 인증서. 보통 사이트의 IT 부서가 지역 인증 기관을 운영하고 클라이언트·서버가 이 CA를 신뢰하도록 미리 구성해요.
생성된 자체 서명 인증서 (Generated self-signed certificates) - Trino만을 위해 생성되고 어떤 클라이언트도 자동으로 신뢰하지 않는 인증서. 사용 전에 자체 서명 인증서의 한계를 반드시 이해하세요.

가장 편리하고 강력히 권장되는 옵션은 전 세계적으로 신뢰받는 인증서예요. 초기에 약간 더 작업이 필요할 수 있지만, 모든 클라이언트를 하나하나 구성하지 않아도 된다는 점이 가치 있어요.

키와 인증서 (Keys and certificates)

Trino는 PEM 인코딩 PKCS #1, PEM 인코딩 PKCS #8, PKCS #12, 레거시 Java KeyStore(JKS) 형식으로 인코딩된 인증서와 개인 키를 읽을 수 있어요. DER 같은 바이너리 형식으로 인코딩된 인증서와 개인 키는 변환해야 해요.

인정된 인증 기관이 검증한 인증서를 얻도록 하세요.

받은 인증서 검사 (Inspect received certificates)

인증서를 설치하기 전에 받은 키와 인증서 파일을 검사·검증해 Trino 서버에 접근하는 올바른 정보를 참조하는지 확인하세요. 인증서를 서버 구성 전에 검증하는 시간을 투자하면 불필요한 디버깅 시간을 많이 아낄 수 있어요.

PEM 인코딩 파일은 Inspect PEM files에 설명된 대로 검사하세요.
PKCS #12와 JKS keystore는 Inspect JKS files에 설명된 대로 검사하세요.

유효하지 않은 인증서 (Invalid certificates)

인증서가 검증을 통과하지 못하거나 검사 시 예상한 정보를 보여주지 않으면, 제공한 그룹이나 공급업체에 교체를 요청하세요.

인증서 파일 배치 (Place the certificate file)

인증서 파일의 위치 요구 사항은 다음 조건만 충족하면 어디든 돼요:

파일을 Trino 코디네이터 서버 프로세스가 읽을 수 있어야 함.
위치가 악의적 행위자의 복사나 변조로부터 안전해야 함.

파일을 Trino 코디네이터의 etc 디렉토리에 놓을 수 있어요. 그러면 구성 파일에서 상대 경로 참조를 사용할 수 있어요. 다만 이 위치는 인증서 파일을 추적하고 Trino 버전을 업그레이드할 때 새 etc 디렉토리로 옮겨야 할 수 있어요.

코디네이터 구성 (Configure the coordinator)

코디네이터에서 config properties 파일에 다음 줄을 추가해 서버의 TLS/HTTPS 지원을 활성화하세요.

Note

PEM 인코딩 인증서를 직접 사용할 때도 속성 이름에는 레거시 keystore·truststore 용어가 사용돼요.

http-server.https.enabled=true
http-server.https.port=8443
http-server.https.keystore.path=etc/clustercoord.pem

세 번째 줄의 가능한 대안:

http-server.https.keystore.path=etc/clustercoord.jks
http-server.https.keystore.path=/usr/local/certs/clustercoord.p12

상대 경로는 Trino 서버의 루트 디렉토리를 기준으로 해요. tar.gz 설치에서는 루트 디렉토리가 etc보다 한 단계 위예요.

JKS keystore는 항상 비밀번호가 필요한 반면, 비밀번호가 있는 PEM 파일은 Trino가 지원하지 않아요. JKS의 경우 구성에 다음 줄을 추가하세요:

http-server.https.keystore.key=<keystore-password>

keystore 안의 키가 keystore의 비밀번호와 별개로 자체 비밀번호를 가질 수 있어요. 이 경우 다음 속성으로 키의 비밀번호를 지정하세요:

http-server.https.keymanager.password=<key-password>

Trino 코디네이터에 HTTPS가 활성화된 상태로 인증기가 활성화되면 Web UI를 포함한 모든 클라이언트에 대해 HTTP 접근이 자동으로 비활성화돼요. 권장되지는 않지만 다음을 설정해 다시 활성화할 수 있어요:

http-server.authentication.allow-insecure-over-http=true

구성 확인 (Verify configuration)

TLS/HTTPS 구성을 확인하려면 Web UI에 로그인하고 Trino CLI로 쿼리를 보내 보세요.

브라우저에서 https://trino.example.com:8443 같은 HTTPS URL로 Web UI에 연결하세요. Username 텍스트 박스에 아무 사용자 이름이나 입력하고 UI에 로그인하세요. 인증이 구성되지 않은 동안에는 Password 상자는 비활성화돼 있어요.

https://trino.example.com:8443 같은 HTTPS URL로 Trino CLI로 연결하세요:

./trino --server https://trino.example.com:8443

연결을 테스트하는 쿼리를 보내 보세요:

trino> SELECT 'rocks' AS trino;

trino
-------
rocks
(1 row)

Query 20220919_113804_00017_54qfi, FINISHED, 1 node
Splits: 1 total, 1 done (100.00%)
0.12 [0 rows, 0B] [0 rows/s, 0B/s]

자체 서명 인증서의 한계 (Limitations of self-signed certificates)

openssl, keytool 또는 Linux에서 certtool 명령으로 자체 서명 인증서를 생성할 수 있어요. 자체 서명 인증서는 내부 전용 클러스터 개발 중에 유용할 수 있어요. 프로덕션 Trino 서버에는 자체 서명 인증서를 사용하지 않는 것을 강력히 권장해요.

자체 서명 인증서는 누구도 신뢰하지 않아요. 신뢰 서명을 받을 필요가 없어서 관리자가 편의상 만드는 경우가 보통이에요.

클러스터 개발 중 자체 서명 인증서를 사용하려면 다음이 필요해요:

인증서를 검증하는 지역 truststore를 모든 클라이언트에 배포
모든 클라이언트가 이 인증서를 사용하도록 구성

하지만 이런 클라이언트 구성이 있어도 현대 브라우저는 이 인증서를 거부하므로 자체 서명 서버는 다루기 어려워요.

자체 서명과 무서명(unsigned) 인증서 사이에는 차이가 있어요. 두 유형 모두 같은 도구로 만들지만, 무서명 인증서는 인증서 서명 요청(CSR)과 함께 CA에 전달되도록 의도된 것이에요. CA는 CA가 서명한 인증서를 반환하고 이제 전 세계적으로 신뢰받게 돼요.

더 알아보기 (Learn more)

인증서 파일을 준비한 뒤에는 Certificate authentication이나 비밀번호 기반 인증으로 이어서 구성해 보세요.