Secure internal communication

Secure internal communication (내부 통신 보호)

Trino 클러스터 내부의 노드 간 통신을 보호하고 선택적으로 TLS로 암호화하는 방법을 설명해요. 공유 시크릿과 내부 TLS 구성을 다뤄요.

출처: 문서

본문

Trino 클러스터는 노드 간 내부 인증을 사용해 보안 통신을 하도록 구성할 수 있고, 선택적으로 TLS로 추가 보안을 강화할 수 있어요.

공유 시크릿 구성 (Configure shared secret)

다음 시나리오에서는 클러스터 노드 간의 모든 통신을 인증하기 위해 공유 시크릿(shared secret)을 구성해야 해요:

  • 클라이언트와 코디네이터 사이에 어떤 인증을 사용하는 경우
  • 클러스터의 모든 노드 사이에 내부 TLS 암호화를 사용하는 경우

클러스터의 모든 노드의 config.properties에 공유 시크릿을 같은 값으로 설정하세요:

internal-communication.shared-secret=

크고 무작위한 키가 권장되며, 다음 Linux 명령으로 생성할 수 있어요:

openssl rand 512 | base64 -w 0

구성 확인 (Verify configuration)

공유 시크릿 구성을 확인하려면:

  1. 공유 시크릿을 구성한 두 개 이상의 노드로 Trino 클러스터를 시작하세요.
  2. Web UI에 연결하세요.
  3. ACTIVE WORKERS 수가 공유 시크릿을 구성한 노드 수와 같은지 확인하세요.
  4. 한 워커의 공유 시크릿 값을 바꾸고 워커를 재시작하세요.
  5. Web UI에 로그인해 ACTIVE WORKERS 수가 하나 적은지 확인하세요. 잘못된 시크릿을 가진 워커는 인증되지 않으므로 코디네이터에 등록되지 않아요.
  6. Trino 클러스터를 멈추고, 워커의 값 변경을 되돌린 다음 클러스터를 재시작하세요.
  7. ACTIVE WORKERS 수가 공유 시크릿을 구성한 노드 수와 같은지 확인하세요.

내부 TLS 구성 (Configure internal TLS)

선택적으로 클러스터가 TLS로 노드 간 통신을 암호화하도록 구성해 보안 계층을 추가할 수 있어요.

코디네이터와 모든 워커가 서로 간의 모든 통신을 TLS로 암호화하도록 구성할 수 있어요. 클러스터의 모든 노드가 구성되어야 해요. 구성되지 않았거나 잘못 구성된 노드는 클러스터의 다른 노드와 통신할 수 없어요.

일반적인 배포에서는 클라이언트 도구의 클러스터에 대한 완전한 암호화 접근을 위해 코디네이터에서 직접 TLS를 활성화해야 해요.

모든 클러스터 노드에서 동일한 다음 구성으로 내부 통신용 TLS를 활성화하세요.

  1. 앞선 섹션에서 설명한 대로 내부 통신용 공유 시크릿을 구성하세요.
  2. etc/config.properties에서 자동 인증서 생성과 트러스트 설정을 활성화하세요:
internal-communication.https.required=true
  1. discovery 서비스의 URI를 HTTPS를 사용하도록 바꾸고 etc/config.properties에서 코디네이터의 IP 주소를 가리키게 하세요:
discovery.uri=https://<coordinator-ip>:<port>

URI에 호스트 이름이나 완전한 도메인 이름을 사용하는 것은 지원되지 않는다는 점에 주의하세요. 내부 TLS용 자동 인증서 생성은 IP 주소만 지원해요.

  1. 모든 워커에서 HTTPS 엔드포인트를 활성화하세요.
http-server.https.enabled=true
http-server.https.port=<port>
  1. 모든 노드를 재시작하세요.

인증서가 자동으로 생성·사용되어 클러스터 내부의 모든 통신이 TLS로 보호돼요.

SSL/TLS 활성화 시 성능 (Performance with SSL/TLS enabled)

암호화를 활성화하면 성능에 영향이 있어요. 성능 저하는 환경, 쿼리, 동시성에 따라 달라질 수 있어요.

SELECT count(*) FROM table처럼 Trino 노드 사이에 너무 많은 데이터를 전송하지 않는 쿼리는 성능 영향이 무시할 수 있을 정도에요.

하지만 분산 조인·집계·윈도우 함수처럼 재파티셔닝이 필요해 노드 간 상당한 양의 데이터를 전송해야 하는 CPU 집약적 쿼리는 성능 영향이 상당할 수 있어요. 저하 폭은 네트워크 트래픽과 CPU 사용률에 따라 10%에서 100% 이상까지 다양할 수 있어요.

Note

기본적으로 SSL/TLS가 활성화된 내부 통신은 확장성 향상을 위해 HTTP/2를 사용해요. internal-communication.http2.enabled=false로 이 기능을 끌 수 있어요.

고급 성능 튜닝 (Advanced performance tuning)

어떤 경우에는 난수(random number)의 소스를 바꾸면 성능이 크게 향상될 수 있어요.

기본적으로 TLS 암호화는 엔트로피 소스로 /dev/urandom 시스템 디바이스를 사용해요. 이 디바이스는 처리량이 제한적이라 네트워크 대역폭이 높은 환경(예: InfiniBand)에서는 병목이 될 수 있어요. 그런 상황에서는 코디네이터와 모든 워커의 config.properties에서 http-server.https.secure-random-algorithm 속성을 설정해 난수 생성기 알고리즘을 SHA1PRNG로 바꿔 보는 것을 권장해요:

http-server.https.secure-random-algorithm=SHA1PRNG

이 알고리즘은 블로킹 /dev/random 디바이스에서 초기 시드를 가져온다는 점에 주의하세요. SHAPRNG 알고리즘을 시드할 엔트로피가 충분하지 않은 환경에서는 jvm.config에 java.security.egd 속성을 추가해 소스를 /dev/urandom으로 바꿀 수 있어요:

-Djava.security.egd=file:/dev/urandom

더 알아보기 (Learn more)

내부 통신 보호에 앞서 TLS 인증서 구성은 TLS 문서를 함께 살펴보세요.