mTLS 트래픽 검증하기
mTLS 트래픽 검증하기 (Validating your mTLS traffic)
Linkerd가 자동으로 활성화하는 상호 TLS(mTLS)가 실제로 동작하는지 linkerd viz edges, linkerd viz tap, tshark로 검증하는 방법을 알려드려요.
본문
기본적으로 Linkerd는 Linkerd 프록시 사이에 안전하고 사적인 TLS 연결을 수립·인증함으로써 meshed pod 사이의 TCP 트래픽에 상호 TLS(mTLS)를 자동으로 활성화합니다. 서비스를 Linkerd에 추가하기만 하면 나머지는 Linkerd가 처리해요.
Linkerd의 자동 mTLS는 애플리케이션에 완전히 투명한 방식으로 이루어집니다. 물론 mTLS가 실제로 적용되고 있는지 검증할 수 있으면 유용할 때가 있죠!
linkerd viz edges로 mTLS 검증하기
mTLS가 동작하는지 검증하려면 linkerd viz edges 명령으로 Linkerd가 관리하는 서비스 간 TCP 연결 요약을 볼 수 있어요. 예를 들어:
`linkerd viz -n linkerd edges deployment
`
출력은 이렇게 생깁니다:
`SRC DST SRC_NS DST_NS SECURED
prometheus linkerd-controller linkerd-viz linkerd √
prometheus linkerd-destination linkerd-viz linkerd √
prometheus linkerd-identity linkerd-viz linkerd √
prometheus linkerd-proxy-injector linkerd-viz linkerd √
prometheus linkerd-sp-validator linkerd-viz linkerd √
`
이 예시에서 모든 것이 성공적으로 mTLS 처리되었고 CLIENT와 SERVER 열은 service-account-name.namespace 형식의 사용 아이덴티티를 나타냅니다. (이 아이덴티티가 무엇을 의미하는지 자세한 내용은 Linkerd의 자동 mTLS 문서를 참고하세요.) 연결을 mTLS로 자동 업그레이드하는 데 문제가 있었다면 MSG 필드에 그 이유가 들어 있을 거예요.
linkerd viz tap으로 mTLS 검증하기
집계 결과에 의존하는 대신, 실시간으로 요청과 응답을 관찰해 어떤 것이 mTLS 처리되는지 이해할 수도 있어요. linkerd viz tap 명령으로 실시간 요청 데이터를 샘플링할 수 있습니다.
`linkerd viz -n linkerd tap deploy
`
Note
기본적으로 컨트롤 플레인 리소스는 tap 할 수 없습니다. Viz 확장을 설치한 뒤(linkerd viz install) 컨트롤 플레인 컴포넌트를 재시작하기만 하면 tap을 활성화할 수 있는데, kubectl -n linkerd rollout restart deploy로 다운타임 없이 할 수 있어요. Viz 확장 자체에서 tap을 활성화하려면 kubectl -n linkerd-viz rollout restart deploy를 실행하세요.
컨트롤 플레인을 특별히 보면 두 가지 주요 유형의 출력이 있을 거예요.
`req id=0:0 proxy=in src=10.42.0.1:60318 dst=10.42.0.23:9995 tls=no_tls_from_remote :method=GET :authority=10.42.0.23:9995 :path=/ready
rsp id=0:0 proxy=in src=10.42.0.1:60318 dst=10.42.0.23:9995 tls=no_tls_from_remote :status=200 latency=267µs
end id=0:0 proxy=in src=10.42.0.1:60318 dst=10.42.0.23:9995 tls=no_tls_from_remote duration=20µs response-length=3B
`
이것은 Kubernetes readiness 프로브의 호출입니다. 프로브는 메시에 없는 kubelet에서 시작되므로 아이덴티티가 없고, tls=no_tls_from_remote 메시지가 나타내듯 이 요청들은 mTLS 처리되지 않아요.
컨트롤 플레인에 대한 다른 요청은 TLS 처리됩니다:
`ireq id=2:1 proxy=in src=10.42.0.31:55428 dst=10.42.0.22:9995 tls=true :method=GET :authority=10.42.0.22:9995 :path=/metrics
rsp id=2:1 proxy=in src=10.42.0.31:55428 dst=10.42.0.22:9995 tls=true :status=200 latency=1597µs
end id=2:1 proxy=in src=10.42.0.31:55428 dst=10.42.0.22:9995 tls=true duration=228µs response-length=2272B
`
이 연결은 메시 안에 있는 Prometheus에서 온 것이므로, tls=true 출력이 나타내듯 요청이 자동으로 mTLS 처리됩니다.
tshark로 mTLS 검증하기
mTLS를 검증하는 마지막 방법은 클러스터 내부의 원시 네트워크 트래픽을 보는 것입니다.
Linkerd에는 서비스 메시 자체를 검증·디버그하기 더 쉽게 해주는 명령 집합이 포함된 디버그 사이드카가 있습니다. 예를 들어 emojivoto 데모 애플리케이션으로 다음을 실행해 디버그 사이드카를 추가할 수 있어요:
`curl --proto '=https' --tlsv1.2 -sSfL https://run.linkerd.io/emojivoto.yml \
| linkerd inject --enable-debug-sidecar - \
| kubectl apply -f -
`
그다음 voting 서비스의 pod 디버그 컨테이너에 원격 셸을 직접 수립할 수 있습니다:
`kubectl -n emojivoto exec -it \
$(kubectl -n emojivoto get po -o name | grep voting) \
-c linkerd-debug -- /bin/bash
`
디버그 사이드카 안에 들어가면 내장 tshark 명령으로 네트워크 인터페이스의 원시 패킷을 검사할 수 있어요. 예를 들어:
`tshark -i any -d tcp.port==8080,ssl | grep -v 127.0.0.1
`
이것은 tshark에게 포트 8080이 TLS 처리될 수 있고, localhost(그 트래픽은 항상 암호화되지 않으므로)는 무시하라고 알려줍니다. 출력은 주요 애플리케이션 트래픽이 자동으로 mTLS 처리됨을 보여줄 거예요.
` 133 11.391540872 10.4.0.17 → 10.4.0.23 TCP 68 46766 → 4191 [ACK] Seq=557 Ack=3942 Win=1329 Len=0 TSval=3389590636 TSecr=1915605020
134 12.128190076 10.4.0.25 → 10.4.0.23 TLSv1.2 154 Application Data
140 12.129497053 10.4.0.23 → 10.4.0.25 TLSv1.2 149 Application Data
141 12.129534848 10.4.0.25 → 10.4.0.23 TCP 68 48138 → 8080 [ACK] Seq=1089 Ack=985 Win=236 Len=0 TSval=2234109459 TSecr=617799816
143 13.140288400 10.4.0.25 → 10.4.0.23 TLSv1.2 150 Application Data
148 13.141219945 10.4.0.23 → 10.4.0.25 TLSv1.2 136 Application Data
`
요약 (Summary)
이 가이드에서는 Linkerd가 연결을 mTLS로 자동 업그레이드했는지 검증하는 여러 방법을 소개했습니다. Linkerd가 이 업그레이드를 못 하는 데는 여러 이유가 있을 수 있다는 점을 알아두세요(Linkerd 자동 mTLS 문서의 "Caveats and future work" 섹션 참고). 보안 목적으로 Linkerd에 의존한다면 이런 종류의 검증은 유익할 수 있어요.
더 알아보기 (Learn more)
- Linkerd 자동 mTLS 문서
- linkerd viz tap 명령 문서
- emojivoto 데모 애플리케이션