공부하고 기록하는, 경제학과 출신 개발자의 노트

학습일지/Service Mesh

istio 개념 정리 (3) - mTLS Security

inspirit941 2022. 10. 29. 12:50
반응형

Istio Security

k8s의 여러 노드에 app을 배포할 경우 사용할 수 있는 유용한 기능.

스크린샷 2022-10-01 오후 3 08 28

  • 일반적으로 https는 client <-> server 통신 과정에서 주고받는 데이터를 암호화해서, man-in-the-middle attack 상황에서도 보안을 확보하는 것.
  • k8s 클러스터 내에서 pod 간 통신이 이루어질 때에도 https 방식의 통신을 권장함.
    • 보통 Brower -> Load balancer, Load balancer -> Istio ingress gateway 정도는 외부 접근 가능 영역이므로 https와 같은 암호화된 통신방식이 좋다는 건 안다.
    • istio 없는 상황에서, 클러스터 내부에서 이루어지는 pod 간 통신에도 https를 적용하는 건 매우 귀찮은 작업.
    • 보통은 k8s 클러스터 내부로 접근해야 pod과 통신할 수 있으므로, pod간 통신이 암호화되지 않아서 생기는 이슈에 집중하기보다는 '클러스터 내부에 누군가가 침입하지 않도록 한다'는 접근방식이 일견 맞는 듯 보일 수 있음.

 

스크린샷 2022-10-01 오후 3 18 11

Fallacies fo distributed Computing 의 마지막 문장을 보면, fallacies (논리적 오류) 중 하나로 언급되는 게 'The network is homogeneous'이다.

  • 위 사진에서는 cluster를 단일 환경으로 묘사했지만, k8s의 클러스터는 보통 Multi-node 구성.
  • k8s deployment에서 만들어진 pod는 보통 여러 대의 노드에 배포되어 있음. (nodeAffinity 옵션이 k8s에 있지만, 특수한 경우에 보통 적용됨)
  • pod간 통신 과정에서 실제로는 어떤 노드와 노드 사이에서 통신이 일어나는지는 파악이 쉽지 않음. AWS에서 만약 Availability Zone이 여러 개인 경우, 노드가 위치해 있는 region이 다를 수 있음.
    • region이 다르다? -> 트래픽이 다른 데이터센터를 통해 이동한다 -> man-in-the-middle attack이 발생할 수 있다.
    • 민감정보를 k8s pod끼리 통신하고 있는 상황이라면 보안취약점이 발생할 수 있음
    • 설령 같은 Region이라 해도, 동일한 데이터센터라는 보장은 없음 (cloud provider마다 다르긴 하지만, region 하나에 single datacenter일 거라고 장담할 수는 없다)

How istio can upgrade traffic to TLS

스크린샷 2022-10-01 오후 3 28 42

 

스크린샷 2022-10-01 오후 3 32 31

  • 보통 pod이 다른 pod를 호출할 때에는 http://service_name:port 형태를 사용한다.
  • istio가 붙은 경우, pod는 다른 pod에 요청을 보내기 전에 istio proxy를 통과해야 한다.
    • single pod에 있는 multi-container는 동일한 노드에 배포돼 있고, networking space를 공유한다. 즉 localhost에서 실행되는 것과 같음. 따라서 user-container에서 proxy로 요청을 보낼 때에는 localhost 방식으로 호출한다.
    • localhost로 호출할 때의 프로토콜은 뭐든 상관없음. http / TCP / gRPC 다 가능.
  • istio에는 pod 간 통신에서 configuration을 담당하는 Control plane 영역이 존재한다. istio proxy -> proxy 간 통신이 이루어질 때 https로 이루어질 수 있게 해줌.
    • 예전 버전에서는 citadel이라는 별도의 pod가 있었고, 현재는 istiod에서 기능을 수행하고 있음.
    • 즉 istio proxy는 상대방의 identity를 istiod (citadel) 에서 발행한 Certificate를 활용해서 검증하는 것.
      • 요청을 보내는 쪽 / 요청을 받는 쪽 둘 다 상대방의 identity를 체크할 수 있다는 점에서 Mutual이라는 용어 추가됨.

 

istio의 mTLS 동작방식은 크게 두 가지.

스크린샷 2022-10-01 오후 3 39 27

  1. policy 생성 -> non-TLS 트래픽 전체를 Block.
  2. proxy간 통신은 자동으로 mTLS 사용하도록 변경

Enable mTLS

스크린샷 2022-10-01 오후 6 20 46

  • 화면의 자물쇠 : TLS가 적용되었다는 뜻
  • 표시된 http : container -> istio (application의 통신 프로토콜) 프로토콜이 http라는 뜻

istio에서 자동으로 proxy간 통신은 mTLS 설정을 해준다고 함. 예전에는 Enable을 위한 몇 가지 설정이 있었는데, 지금은 자동으로 설정됨

Strict TLS / Permissive TLS

https://istio.io/latest/docs/concepts/security/#peer-authentication

 

proxy to proxy는 istio에서 자동으로 TLS 설정을 해준다고 할 때

  • 그럼 istio가 붙지 않은 pod에서 istio 설정된 Pod 사이에 트래픽이 발생할 땐 어떻게 되나?

 

스크린샷 2022-10-01 오후 6 25 51

Permissive mTLS : istio의 default 세팅.

  • sending side에서 Istio proxy를 활용한 mTLS가 불가능할 경우, https로 TLS 설정하지 않고 그대로 트래픽을 받아들인다.
  • Insecure call 유지.

 

스크린샷 2022-10-01 오후 8 13 19

Strict mTLS

  • request를 istio proxy를 활용한 mTLS가 불가능할 경우, 요청을 block.
  • 반대로 istio proxy에서 non-istio pod로 요청을 보낼 경우에도 block.
반응형