[Istio] 쉿! 우리만의 비밀이야 - mTLS (확인편)

 

 

쿠버네티스 위에는 다양한 서비스들이 존재합니다. 이 서비스들이 하나하나 생겨나다 보면 어느 새 몇 백개, 몇 천개의 서비스들이 존재하게 됩니다.

 

이런 서비스들을 쉽게 관리하기 위해서 이스티오를 사용합니다. 이스티오는 서비스 메쉬 서비스 라는 타이틀에 걸맞게 다양한 기능들을 제공해주는데 이번 글에서는 그 중 핵심 기능 중 하나인 mTLS (Mutual TLS) 에 대해 알아보고자 합니다.

 

먼저 mTLS 가 무엇인지 알아보기 전에 왜 필요하진 부터 알아보죠.

 

이스티오 인그레스 게이트웨이를 통해 우리는 쿠버네티스 내부에 접근이 가능합니다.

이스티오 인그레스 게이트웨이

 

클라이언트가 데이터를 전송할 때 암호화를 한 후 전송하게 되는데 (HTTPS), 문제는 인그레스 게이트웨이 까지만 데이터가 암호화가 되고 쿠버네티스 내부에서는 HTTPS 가 아닌 HTTP 로 통신되기 때문에 평문으로 데이터가 이동하게 됩니다.

 

그런데 어차피 쿠버네티스 내부는 프라이빗한 영역인데, 굳이 내부에서의 통신까지 HTTPS 로 할 필요가 있을까? 라는 의문점이 있습니다.

 

 

이 질문에서 대해서는 이스티오는 이렇게 설명합니다.

 

"만약 워커 노드들이 서로 다른 리전에 존재하게 되면 당연히 통신은 데이터 센터 건물 밖으로 나가게 되고, 정말 나쁜 해커가 의도적으로 탈취하게 되면 데이터가 유출될 수 있다"

외부로 나간다?

 

틀린 말은 아닌데 그렇다고 또 막 100% 맞는 말도 아닌 거 같습니다. 건물 밖으로 나간다해도 AWS 의 물리적인 네트워크 선을 통해 나갈텐데.. 이것을 AWS 가 바보도 아니고, 쉽게 탈취해가지 못하게 이미 설계 해놓았을 것 같습니다. 근데 뭐 이건 제 추측이고, 암튼 확실해서 나쁠 건 없죠?

 

그럼 이제 왜 쿠버네티스 내부에서도 HTTPS 통신이 필요한지 알아보았습니다. 그런데 또 하나 문제가 생깁니다. 마이크로 서비스가 1000 개라면 1000 개 모두 TLS 인증서를 만들고, 관리해야합니다. 정말 귀찮고, 관리하기가 만만치 않을 겁니다.

 

그래서 이러한 부분을 이스티오의 mTLS 가 해결해 줍니다.

 

이스티오 공식 문서에선 mTLS 과정을 이렇게 설명해줍니다.

1. Istio는 클라이언트의 아웃바운드 트래픽을 클라이언트의 로컬 사이드카 Envoy로 다시 라우팅합니다.
2. 클라이언트 측 Envoy는 서버 측 Envoy와 상호 TLS 핸드셰이크를 시작합니다. 핸드셰이크 중에 클라이언트 측 Envoy는 서버 인증서에 제공된 서비스 계정이 대상 서비스를 실행할 권한이 있는지 확인하기 위해 보안 이름 지정 검사도 수행합니다.
3. 클라이언트 측 Envoy와 서버 측 Envoy는 상호 TLS 연결을 설정하고 Istio는 클라이언트 측 Envoy에서 서버 측 Envoy로 트래픽을 전달합니다.
4. 서버 측 Envoy가 요청을 승인합니다. 권한이 있는 경우 로컬 TCP 연결을 통해 트래픽을 백엔드 서비스로 전달합니다.

mTLS 과정 도식화

 

즉, Istio Proxy 가 이를 알아서 데이터를 보내줄 때 암호화를 해주고, 받을 때 다시 복호화를 해준다는 겁니다. 우리는 굳이 TLS 인증서에 신경쓸 필요가 없다는 것이죠.

 

참고로 TLS 버전은 아래와 같이 구성된다고 합니다.

• ECDHE-ECDSA-AES256-GCM-SHA384
• ECDHE-RSA-AES256-GCM-SHA384
• ECDHE-ECDSA-AES128-GCM-SHA256
• ECDHE-RSA-AES128-GCM-SHA256
• AES256-GCM-SHA384
• AES128-GCM-SHA256

 

그럼 실제로 어떻게 동작하는 지 알아보죠!

 

렛츠두더코드~!

 

 

mTLS 를 위한 특별한 방법은 없습니다. 그저 네임스페이스에 아래와 같이 이스티오를 사용한다고 명시만 하면 바로 적용됩니다.

kubectl label namespace default istio-injection=enabled

 

아래 그림은 Kiali 를 통해서 nginx 들을 도식화한 것입니다. 보면 nginx-01 -> nginx-02 에는 자물쇠가 채워져있지만, nginx-01 -> nginx-03 은 자물쇠가 채워지지 않았습니다. 이 자물쇠 아이콘이 바로 mTLS 의 적용 여부입니다.

 

그래서 default 네임스페이스에 있는 서비스들은 자물쇠가 채워져 있고, not-istio 네임스페이스는 이스티오를 사용하지 않으니 자물쇠가 채워지지 않았습니다.

 

그럼 이번에는 이스티오 mTLS 의 3가지 모드를 알아보죠.

• PERMISSIVE : 워크로드가 상호 TLS 및 일반 텍스트 트래픽을 모두 허용합니다. 이 모드는 사이드카가 없는 워크로드가 상호 TLS를 사용할 수 없는 마이그레이션 중에 가장 유용합니다. 사이드카 삽입으로 워크로드가 마이그레이션되면 모드를 STRICT로 전환해야 합니다.
• STRICT : 워크로드는 상호 TLS 트래픽만 허용합니다.
• DISABLE : 상호 TLS가 비활성화됩니다. 보안 관점에서 자체 보안 솔루션을 제공하지 않는 한 이 모드를 사용해서는 안 됩니다.

 

기본 값은 PERMISSIVE 이기 때문에 굳이 mTLS 를 사용하지 않는다고 해도 mTLS 를 사용하는 마이크로 서비스와 통신이 가능하게 됩니다.

 

실제 그렇게 동작하는 지 확인해보죠.

 

아래와 같이 default 네임스페이스에서 PERMISSIVE 를 사용하도록 하면,

apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: "default-strict"
  namespace: "default"
spec:
  mtls:
    mode: PERMISSIVE

 

이스티오를 사용하지 않는 not-istio 네임스페이스의 nginx-03 에서 이스티오를 사용하는 nginx-01 로도 통신이 가능합니다.

 

그리고 모드를 한번 STRICT 바꿔보겠습니다.

apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: "default-strict"
  namespace: "default"
spec:
  mtls:
    mode: STRICT

 

 

이스티오를 사용하지 않는 nginx-03 에서 이스티오를 사용하는 nginx-01 에는 통신이 불가능하게 됩니다. 이렇게 함으로써 보안이 중요시 되는 영역에서는 mTLS 를 강제화 할 수 있죠.

 

오늘은 이스티오의 mTLS 기능에 대해 알아보았습니다. mTLS 를 이용하면 내부에서의 모든 통신을 쉽게 HTTPS 로 할 수 있다는 장점이 있죠.

 

그런데 실제로 curl 명령어를 보면 https 로 보내는 것이 아니라 http 로 보내는 것을 확인 할 수 있는데 이는 어차피 파드를 빠져나갈때 이스티오 프록시가 알아서 자동으로 암호화를 해줘서 그렇기 때문입니다. 

 

그럼 저는 여기서 의문이 하나듭니다. 그럼 내부끼리 통신하는 마이크로서비스는 https 로 통신되게 할 필요가 없는 건가? 코드를 작성할 때 https://xxx 가 아닌 http://xxx 로 해도 무방한 것인가?

 

이스티오 mTLS 기능을 살펴보면 그래도 되보이지만... 저도 이 부분에 대해선 확답을 모르겠습니다. 이동하는 데이터를 하이재킹할 수도 없을 노릇이구요.

 

그래서 혹시나 답을 아시는 분이 계시다면, 댓글에 남겨주시면 정말 감사하겠습니다 :)

 

mTLS 를 이용해서 데이터가 실제로 암호화가 되었는지 확인해보고 싶다면 여기 클릭!

 

 

그럼 오늘은 여기까지!