자동 vs 수동: Istio mTLS 인증서 관리, 당신의 선택은? 🧐

마이크로서비스 아키텍처(MSA) 환경에서 서비스 간 통신 보안은 아무리 강조해도 지나치지 않습니다. 서비스 메시의 대표주자 Istio는 mTLS(상호 TLS)를 통해 이 문제를 아주 우아하게 해결하죠. 마치 서비스마다 보이지 않는 경호원을 붙여주는 것과 같습니다. 💂‍♂️💂‍♀️

그런데 Istio에서 mTLS를 설정하다 보면 ISTIO_MUTUAL과 MUTUAL이라는 두 가지 모드를 만나게 됩니다. 이름이 비슷해서 그냥 같은 건가 싶기도 하고, 미묘한 차이가 있는 것 같기도 하죠.

오늘은 이 두 가지 모드의 결정적인 차이점과 언제 어떤 모드를 사용해야 하는지 명확하게 파헤쳐 보겠습니다!

TL;DR: 핵심 요약 📝

• ISTIO_MUTUAL: Istio가 자동으로 인증서를 발급하고 관리해주는 방식 (편리함 ✨)
• MUTUAL: 사용자가 직접 인증서를 준비해서 제공해야 하는 방식 (유연성/통제력 🔑)

  

---

🤔 ISTIO_MUTUAL: Istio에게 모든 걸 맡기세요!

ISTIO_MUTUAL은 Istio를 사용하는 가장 표준적이고 권장되는 mTLS 방식입니다.

이 모드를 사용하면 Istio의 컨트롤 플레인에 내장된 CA(Certificate Authority), 즉 istiod가 모든 것을 알아서 처리해 줍니다.

1. 자동 인증서 발급: 새로운 워크로드(Pod)가 생성되면 istiod가 해당 워크로드의 서비스 아이덴티티에 맞는 인증서를 자동으로 발급합니다.
2. 안전한 배포: 발급된 인증서와 개인 키를 사이드카 프록시(Envoy)에 안전하게 전달합니다.
3. 자동 갱신 (Rotation): 인증서 만료 기간이 다가오면 기존 인증서를 자동으로 새로운 인증서로 교체하여 서비스 중단 없이 보안을 유지합니다. ⚙️

장점:

• 압도적인 편리함: 인증서 생성, 관리, 갱신에 대한 고민을 할 필요가 전혀 없습니다. 그냥 "mTLS 켜줘!"라고 말하기만 하면 됩니다.
• 강력한 보안: Istio가 검증된 방식으로 전체 프로세스를 자동화하므로 사람의 실수로 인한 보안 사고 가능성이 줄어듭니다.

대부분의 경우, 여러분은 ISTIO_MUTUAL을 사용하게 될 것이며, 이것만으로도 충분히 강력한 보안을 구축할 수 있습니다.

YAML 설정 예시

PeerAuthentication 리소스를 사용하여 특정 네임스페이스(default)의 모든 워크로드에 ISTIO_MUTUAL 모드를 적용하는 예시입니다.

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

네, 이게 전부입니다! 정말 간단하죠? 😉

---

🧐 MUTUAL: 내가 직접 관리할래요!

MUTUAL 모드는 사용자가 직접 인증서 관리를 책임져야 할 때 사용합니다.

어떤 경우에 필요할까요?

• 회사에 이미 자체적으로 구축하여 사용하는 외부 CA(사설 CA)가 있을 경우
• 보안 규정상 특정 CA에서 발급한 인증서만 사용해야 하는 컴플라이언스 요구사항이 있을 경우
• 인증서의 수명 주기나 사양을 완벽하게 통제하고 싶을 경우

이 모드를 사용하려면 사용자는 다음의 것들을 직접 준비해서 워크로드에 제공해야 합니다.

• 서버 인증서 (tls.crt)
• 서버 개인 키 (tls.key)
• CA 체인 인증서 (ca.crt)

이 파일들을 Kubernetes Secret으로 만들어 워크로드에 마운트하고, Istio에게 이 Secret을 사용하라고 알려줘야 합니다.

단점:

• 높은 관리 비용: 인증서 생성, Secret 관리, 주기적인 갱신까지 모두 수동으로 처리해야 합니다. 🥵
• 복잡성 증가: 설정 과정이 복잡하고, 인증서 관리를 잘못하면 서비스 장애나 보안 취약점으로 이어질 수 있습니다.

YAML 설정 예시

MUTUAL 모드는 클라이언트가 특정 목적지(서버)로 통신할 때 사용할 인증서를 지정하는 DestinationRule에서 주로 사용됩니다.

1. 먼저, 준비한 인증서 파일로 Secret을 생성합니다.

# httpbin-credential 이라는 이름의 Secret 생성
kubectl create -n default secret tls httpbin-credential \
--key=client.key.pem \
--cert=client.cert.pem \
--cacert=ca.cert.pem

2. DestinationRule에서 MUTUAL 모드와 Secret을 지정합니다.

httpbin.default.svc.cluster.local 서비스로 요청을 보낼 때, 방금 생성한 httpbin-credential Secret의 인증서를 사용하도록 설정하는 예시입니다.

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: "egress-mtls-httpbin"
  namespace: "default"
spec:
  host: httpbin.default.svc.cluster.local
  trafficPolicy:
    tls:
      mode: MUTUAL
      credentialName: httpbin-credential # 1번에서 생성한 Secret 이름
      sni: httpbin.default.svc.cluster.local

ISTIO_MUTUAL에 비해 확실히 손이 많이 가는 것을 볼 수 있습니다.

전체 맥락에서 보기: 언제 무엇을 선택해야 할까?

두 모드의 차이점을 이해했다면, 이제 전체적인 관점에서 언제 어떤 것을 선택해야 할지 결정할 수 있습니다.

특징	ISTIO_MUTUAL	MUTUAL
인증서 관리 주체	Istio (istiod) 🤖	사용자 🙋‍♂️
설정 복잡도	낮음 (간단)	높음 (복잡)
관리 편의성	매우 높음	낮음
사용 사례	일반적인 서비스 메시 환경, 빠른 보안 적용	기존 PKI 인프라 연동, 엄격한 보안 규정 준수
추천 대상	대부분의 사용자	특정 요구사항이 있는 고급 사용자

결국 선택의 기준은 "누가 인증서를 통제해야 하는가?" 입니다.

Istio의 자동화된 생태계에 모든 것을 맡기고 싶다면 ISTIO_MUTUAL을, 기존의 보안 정책과 인프라에 Istio를 통합해야 한다면 MUTUAL을 선택하면 됩니다.

결론 🚀

ISTIO_MUTUAL과 MUTUAL은 단순히 이름만 비슷한 것이 아니라, 인증서 관리의 책임 주체가 누구에게 있는지를 결정하는 매우 중요한 설정입니다.

• ISTIO_MUTUAL: Istio가 제공하는 강력한 자동화의 이점을 누리세요.
• MUTUAL: 외부 CA 연동 등 특별한 요구사항이 있을 때 사용하세요.

자신의 환경과 요구사항을 정확히 파악하고 올바른 mTLS 모드를 선택하여, 더 안전하고 신뢰할 수 있는 마이크로서비스 환경을 구축하시길 바랍니다!

---