자동 mTLS
자동 mTLS (Automatic mTLS)
기본적으로 Linkerd는 메시(mesh)에 포함된 파드 간 모든 TCP 트래픽에 대해 상호 인증 Transport Layer Security(mTLS)를 자동으로 적용해요. 다시 말해, Linkerd가 여러분의 애플리케이션 통신에 인증과 암호화를 별다른 작업 없이 추가해 준다는 뜻이에요. (그리고 Linkerd 컨트롤 플레인도 데이터 플레인 위에서 실행되기 때문에, Linkerd 컨트롤 플레인 컴포넌트 간 통신도 자동으로 mTLS로 보호돼요.)
자세한 내용은 아래의 주의사항(Caveats)을 확인해 주세요.
본문
mTLS란 무엇인가요?
mTLS, 즉 상호 TLS(Mutual TLS)는 "일반 TLS"에 클라이언트도 인증된다는 조건이 하나 더 추가된 것이에요. TLS는 신뢰성을 보장하지만, 기본적으로는 한 방향으로만 일어나요. 즉 클라이언트가 서버를 인증하지만 서버는 클라이언트를 인증하지 않지요. mTLS는 이 신뢰성을 대칭적으로 만들어 줘요.
mTLS는 아주 방대한 주제예요. mTLS가 무엇이고 Kubernetes 클러스터에서 어떻게 동작하는지에 대한 폭넓은 개요를 보고 싶다면, A Kubernetes engineer's guide to mTLS 문서를 읽어 보시길 권해요.
Linkerd가 자동으로 mTLS를 적용하는 트래픽은 무엇인가요?
Linkerd는 메시에 포함된 파드 간 모든 TCP 통신에 mTLS를 투명하게 적용해요. 하지만 시스템에 여전히 mTLS가 적용되지 않은 트래픽이 있을 수 있어요. 예를 들면:
- 메시에 포함되지 않은 파드와의 트래픽 (예: Kubernetes 헬스체크)
- skip 포트로 표시된 포트의 트래픰 (이 경우 프록시를 완전히 우회해요)
어떤 트래픽이 mTLS로 보호되는지는 다양한 방법으로 확인할 수 있어요. Buoyant Cloud와 같은 외부 시스템을 쓰면 클러스터의 TLS 트래픽 패턴에 대한 리포트를 자동으로 생성할 수도 있어요.
운영상 고려 사항
Linkerd의 mTLS는 프로덕션에서 쓰려면, 특히 오래 지속되는 클러스터나 교차 클러스터 트래픽이 예상되는 클러스터라면 몇 가지 준비가 필요해요.
기본 linkerd install CLI 명령으로 생성되는 신뢰 앵커(trust anchor)는 365일 후에 만료돼요. 그 이후에는 수동으로 교체(rotate)해야 해요. 이것은 만만치 않은 작업이에요. 또는 신뢰 앵커를 직접 제공하고 만료 날짜를 직접 제어할 수도 있어요. 예를 들어 1년이 아니라 10년으로 설정하는 식이지요.
Linkerd의 멀티 클러스터 통신을 사용하는 Kubernetes 클러스터는 신뢰 앵커를 공유해야 해요. 따라서 기본 linkerd install 설정으로는 이 상황이 동작하지 않으며, 명시적인 신뢰 앵커를 직접 제공해야 해요.
마찬가지로 기본 클러스터 발급자(issuer) 인증서와 키도 1년 후에 만료돼요. 만료되기 전에 반드시 교체해야 해요. 또는 cert-manager로 자동 교체를 설정할 수도 있어요.
Buoyant Cloud 같은 외부 시스템을 쓰면 클러스터 자격 증명을 모니터링하고 만료가 가까워지면 알림을 보내도록 할 수 있어요.
Linkerd의 mTLS 구현은 어떻게 동작하나요?
Linkerd 컨트롤 플레인에는 identity라는 인증 기관(CA)이 있어요. 이 CA는 각 Linkerd 데이터 플레인 프록시에 TLS 인증서를 발급해요. 각 인증서는 해당 파드가 가진 Kubernetes ServiceAccount ID에 바인딩돼요. 이 TLS 인증서는 24시간 후에 만료되고 자동으로 교체돼요. 프록시들은 이 인증서로 다른 프록시와의 TCP 트래픽을 암호화하고 인증해요.
컨트롤 플레인 쪽에서 Linkerd는 클러스터에 일련의 자격 증명(신뢰 앵커, 발급자 인증서와 개인 키)을 유지해요. 이 자격 증명은 설치 시점에 Linkerd가 생성할 수도 있고, Vault나 cert-manager 같은 외부 소스가 제공할 수도 있어요. 발급자 인증서와 개인 키는 Kubernetes Secret에 저장되는데, 이 Secret은 linkerd 네임스페이스에 있으며 Linkerd 컨트롤 플레인의 identity 컴포넌트가 사용하는 서비스 어카운트만 읽을 수 있어요.
데이터 플레인 쪽에서 각 프록시는 환경 변수로 신뢰 앵커를 전달받아요. 시작 시 프록시는 개인 키를 생성하는데, 이 키는 메모리에만 남고 파드를 절대 떠나지 않는 tmpfs emptyDir에 저장돼요. 프록시는 컨트롤 플레인의 identity 컴포넌트에 연결하고, 신뢰 앵커로 identity와의 연결을 검증한 다음 인증서 서명 요청(CSR)을 발행해요. CSR에는 파드의 Kubernetes ServiceAccount를 ID로 하는 초기 인증서와 실제 서비스 어카운트 토큰이 들어 있어서, identity가 CSR이 유효한지 검증할 수 있어요. 검증이 끝나면 서명된 신뢰 번들(trust bundle)이 프록시로 반환되고, 프록시는 이를 클라이언트 및 서버 인증서로 모두 사용할 수 있어요. 이 인증서는 24시간 범위로 발급되며 같은 메커니즘으로 동적으로 갱신돼요.
마지막으로, 프록시가 파드 내부의 애플리케이션 컨테이너로부터 나가는 연결을 받으면, Linkerd 컨트롤 플레인으로 해당 목적지를 조회해요. 그 목적지가 Kubernetes 클러스터 안에 있다면 컨트롤 플레인은 프록시에게 목적지의 엔드포인트 주소와 함께 ID 이름을 포함한 메타데이터를 제공해요. 프록시가 목적지에 연결할 때 TLS 핸드셰이크를 시작하고, 목적지 프록시의 인증서가 신뢰 앵커로 서명됐으며 예상된 ID를 포함하는지 검증해요.
TLS 프로토콜 파라미터
Linkerd는 현재 모든 메시 통신(즉 연결 양쪽에 Linkerd 프록시가 있는 경우)에 대해 다음 TLS 구성을 사용해요:
- TLS 버전 1.3
- 하이브리드 ML-KEM-768 + X25519 키 교환
- AES_128_GCM 암호화 스위트
- 파드 ID는 바인딩된 ServiceAccount 토큰에서 파생됨
주의사항 (Caveats)
Linkerd는 모든 메시 통신(즉 연결 양쪽에 Linkerd 프록시가 있는 경우)에 mTLS를 요구하지만, 기본적으로는 메시에 포함되지 않은 소스로부터의 평문(plaintext) 트래픽도 수락해요. 이것은 인가 정책(authorization policies)으로 비활성화할 수 있어요.