[Istio 가이드 ep.38] 6부 트러블슈팅 #3 | mTLS 인증 실패 문제 해결

🔹 개요

이번 글에서는 Istio에서 발생하는 mTLS(Mutual TLS) 인증 실패 문제를 해결하는 방법을 살펴보겠습니다.
Istio는 서비스 간 트래픽을 보호하기 위해 mTLS를 활용하여 보안 통신을 수행하지만,
잘못된 설정으로 인해 서비스 간 인증 실패, 연결 거부, 503 오류 등이 발생할 수 있습니다.

이 글에서는 mTLS 인증 실패의 주요 원인, 디버깅 방법 및 해결책을 설명하겠습니다.

---

🔹 1. mTLS 인증 실패의 주요 원인

 

오류 유형	설명
503 오류 (Service Unavailable)	인증 실패로 인해 Envoy Proxy가 요청을 거부하는 경우
TLS handshake 실패	클라이언트와 서버 간 TLS 핸드셰이크가 이루어지지 않는 경우
Peer 인증 실패	인증서가 올바르게 설정되지 않은 경우
자동 mTLS 설정 불일치	클라이언트와 서버 간 보안 정책이 다를 경우 발생

💡 Istio의 인증 정책이 올바르게 설정되었는지 확인하는 것이 중요합니다.

---

🔹 2. mTLS 인증 실패 디버깅 방법

✅ 2.1 현재 mTLS 설정 확인 (PeerAuthentication 조회)

Istio에서 적용된 mTLS 정책을 확인하려면 다음 명령어를 실행합니다.

kubectl get peerauthentication -n istio-system

 

출력 예제:

NAME          MODE      AGE
default       STRICT    20m

💡 STRICT 모드일 경우, 모든 서비스 간 트래픽이 mTLS를 통해 보호되어야 합니다.

---

✅ 2.2 Envoy Proxy 로그 확인 (mTLS 인증 문제 분석)

mTLS 인증 실패가 발생하면 Envoy Proxy 로그를 확인하여 원인을 파악할 수 있습니다.

kubectl logs <pod-name> -c istio-proxy -n default | grep "TLS"

 

출력 예제:

[2024-03-18T12:30:00.123Z] TLS error: 336134278: SSL routines:SSL3_READ_BYTES:tlsv1 alert unknown ca

💡 "unknown ca" 오류는 클라이언트와 서버 간의 CA 인증서가 일치하지 않음을 의미합니다.

---

✅ 2.3 대상 서비스의 인증 정책 확인 (DestinationRule 조회)

DestinationRule에서 mTLS가 올바르게 설정되었는지 확인해야 합니다.

kubectl get destinationrule my-service -n default -o yaml

 

출력 예제:

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: my-service
  namespace: default
spec:
  host: my-service.default.svc.cluster.local
  trafficPolicy:
    tls:
      mode: ISTIO_MUTUAL  # mTLS를 사용하여 통신

💡 mode: ISTIO_MUTUAL 설정이 빠져 있으면 mTLS가 적용되지 않을 수 있습니다.

---

✅ 2.4 서비스 간 통신 상태 확인

mTLS 인증 실패 시 서비스 간 통신이 차단될 수 있으므로, 네트워크 연결 상태를 점검해야 합니다.

kubectl exec -it  -n default -- curl -v https://my-service.default.svc.cluster.local:443

출력 예제:

* SSL certificate problem: unable to get local issuer certificate

💡 "SSL certificate problem" 오류가 발생하면, 인증서 설정을 점검해야 합니다.

---

🔹 3. mTLS 인증 실패 트러블슈팅 실전 예제

✅ 3.1 503 오류 (Service Unavailable) 해결

🛠️ 해결 방법:

• DestinationRule 및 PeerAuthentication 설정이 올바른지 확인

올바른 DestinationRule 설정

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: my-service-dr
  namespace: default
spec:
  host: my-service.default.svc.cluster.local
  trafficPolicy:
    tls:
      mode: ISTIO_MUTUAL  # mTLS 활성화

올바른 PeerAuthentication 설정

apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: default
  namespace: istio-system
spec:
  mtls:
    mode: STRICT  # mTLS를 강제 적용

💡 PeerAuthentication이 STRICT 모드일 경우, 모든 서비스가 mTLS를 사용해야 합니다.

---

✅ 3.2 TLS Handshake 실패 해결

🛠️ 해결 방법:

• 클라이언트와 서버의 인증서가 일치하는지 확인

클라이언트 측 DestinationRule 설정

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: client-dr
  namespace: default
spec:
  host: my-service.default.svc.cluster.local
  trafficPolicy:
    tls:
      mode: ISTIO_MUTUAL  # 클라이언트도 mTLS 사용

💡 클라이언트와 서버가 모두 ISTIO_MUTUAL을 설정해야 정상적인 mTLS 통신이 가능합니다.

---

✅ 3.3 자동 mTLS 설정 충돌 해결

🛠️ 해결 방법:

• Istio의 autoMTLS 설정을 확인하고, 불필요한 수동 설정을 제거

kubectl get meshconfig -n istio-system -o yaml | grep autoMTLS

 

출력 예제:

autoMTLS: enabled

수동 설정을 제거하고 자동 mTLS 적용

apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: default
  namespace: istio-system
spec:
  mtls:
    mode: PERMISSIVE  # 자동 mTLS 활성화

💡 PERMISSIVE 모드는 mTLS와 일반 HTTP 트래픽을 모두 허용하는 설정입니다.

---

📌 결론

• Istio의 mTLS 인증 실패는 PeerAuthentication, DestinationRule 및 인증서 설정을 점검해야 합니다.
• 503 오류가 발생하면 DestinationRule 및 PeerAuthentication 설정을 확인해야 합니다.
• TLS Handshake 실패가 발생하면 클라이언트와 서버의 인증서가 올바르게 설정되었는지 확인해야 합니다.
• Istio의 autoMTLS 설정을 확인하여 불필요한 충돌을 방지할 수 있습니다.