서비스 메시 mTLS는 켜는 순간보다 운영 모델이 더 어렵다

마이크로서비스 사이에 mTLS를 적용하면 통신 양쪽이 서로의 인증서를 검증하고 트래픽을 암호화할 수 있다. 그러나 “메시에 넣었으니 모든 통신이 안전하다”는 가정은 위험하다. 일부 워크로드에 프록시가 빠져 있거나, 정책이 PERMISSIVE 상태로 남아 있거나, 서비스 계정이 잘못 공유되면 암호화와 신원 경계가 기대대로 작동하지 않는다.

운영 모델의 핵심은 인증서 자체보다 어떤 워크로드가 어떤 서비스 ID를 갖고, 누구와 통신할 수 있으며, 인증서와 정책이 실패할 때 어떤 신호가 보이는지를 정의하는 것이다. 메시 제품과 버전에 따라 기본 동작과 API가 달라질 수 있으므로 배포 전 현재 공식 문서와 릴리스 노트를 다시 확인해야 한다.

먼저 그릴 신뢰 경계

요소	결정할 질문	흔한 실수
서비스 ID	ID가 서비스 계정, 네임스페이스, 워크로드 중 무엇에 묶이는가	여러 앱이 같은 서비스 계정을 공유
신뢰 도메인	클러스터·환경·조직 간 신뢰를 어디까지 연결할 것인가	개발·운영 환경이 같은 루트를 무분별하게 신뢰
CA 계층	루트와 중간 CA를 누가 운영하고 회전하는가	루트 키가 온라인 클러스터에 장기 보관
정책 범위	메시·네임스페이스·워크로드 정책의 우선순위는 무엇인가	상위 정책을 하위 예외가 조용히 완화
비메시 트래픽	배치·레거시·헬스체크를 어떻게 처리할 것인가	영구 PERMISSIVE로 남겨 평문 허용
관측성	인증 실패와 인가 거부를 어떻게 구분할 것인가	503 오류만 보고 애플리케이션 장애로 오판

서비스 ID는 이름표가 아니라 권한의 주체다. 같은 서비스 계정을 여러 워크로드가 공유하면 한 워크로드 침해가 다른 서비스의 신원으로 확장될 수 있다.

암호화와 인가는 별도 통제다

mTLS는 상대가 신뢰된 인증서를 제시했음을 확인하고 통신을 암호화한다. 하지만 인증된 서비스가 모든 API를 호출해도 된다는 뜻은 아니다. 결제 서비스가 사용자 프로필의 읽기 API를 호출할 수 있어도 관리자 변경 API까지 호출할 이유는 없을 수 있다.

따라서 다음 순서로 설계한다.

1. 워크로드마다 고유하거나 최소 범위의 서비스 ID를 부여한다.
2. mTLS로 신원과 암호화된 채널을 확보한다.
3. 인가 정책에서 호출 주체, 대상, 포트, 메서드, 경로를 제한한다.
4. 거부 로그에 소스·대상 ID와 적용 정책을 남긴다.
5. 정책 변경을 코드 리뷰와 배포 이력에 연결한다.

안전한 전환 절차

1단계: 트래픽 지도를 만든다

실제 서비스 호출, 배치 작업, 외부 게이트웨이, 헬스체크, 모니터링 에이전트, 데이터베이스 연결을 수집한다. 문서상 호출 관계가 아니라 최근 트래픽과 배포 구성을 함께 본다.

2단계: 관찰 가능한 허용 모드로 시작한다

기존 평문과 mTLS가 섞여 있다면 제한된 범위에서 호환 모드로 시작하되, 평문 요청 비율과 발신 워크로드를 대시보드에 표시한다. 예외마다 소유자와 제거 기한을 둔다.

3단계: 네임스페이스 또는 서비스 단위로 STRICT 전환한다

한 번에 전체 메시를 잠그기보다 의존성이 단순하고 영향이 작은 서비스부터 강화한다. 예시는 제품 버전에 맞게 검증해야 한다.

apiVersion: security.istio.io/v1
kind: PeerAuthentication
metadata:
  name: default
  namespace: payments
spec:
  mtls:
    mode: STRICT

적용 직후 성공률만 보지 말고 비메시 클라이언트, 헬스체크, 배치, 포트별 예외가 어떻게 변했는지 확인한다.

4단계: 인가를 기본 거부로 전환한다

관측된 호출 관계를 그대로 허용 목록으로 복사하면 오래된 호출까지 영구화할 수 있다. 서비스 소유자가 필요한 업무 흐름을 승인하고, 읽기·쓰기·관리 경로를 나눠 최소 권한 정책을 만든다.

인증서 회전에서 놓치기 쉬운 것

인증서가 자동 회전된다는 설명만으로 운영 준비가 끝나지 않는다.

• 워크로드 인증서 만료 시간과 실제 회전 시점을 측정한다.
• CA 또는 제어 평면 장애가 발생했을 때 기존 인증서로 버틸 수 있는 시간을 확인한다.
• 노드 시계 오차가 not yet valid 또는 만료 오류로 나타나는지 감시한다.
• 루트·중간 CA 교체 시 구·신뢰 번들을 겹쳐 배포하는 절차를 시험한다.
• 멀티클러스터에서 신뢰 도메인 별칭과 서비스 ID 충돌을 검토한다.
• 인증서 비밀값이 로그, 디버그 덤프, 지원 번들에 포함되지 않도록 한다.

장애 신호를 원인별로 나눈다

신호	가능한 원인	우선 확인
TLS handshake 오류 급증	만료, 신뢰 번들 불일치, 시간 오차	인증서 유효기간, 발급자, 노드 시간
특정 네임스페이스만 503	프록시 누락, 정책 범위 충돌	사이드카/ambient 등록, 정책 선택자
RBAC: access denied 증가	인가 정책 변경, 서비스 ID 변경	최근 정책 배포와 호출 주체 ID
평문 트래픽 비율 유지	비메시 워크로드, 영구 예외	소스 워크로드와 예외 만료일
인증서 발급 지연	CA·제어 평면 장애, API 제한	발급 큐, 제어 평면 상태, 인증서 TTL
재시도·지연 증가	TLS 협상 실패 또는 프록시 자원 부족	프록시 CPU·메모리, 연결 재사용

애플리케이션 오류율과 메시 오류율을 같은 그래프에서 비교하면 코드 장애와 신원·정책 장애를 빠르게 구분할 수 있다.

롤백은 평문 전환이 아니라 범위 축소다

장애가 났다고 메시 전체를 PERMISSIVE로 되돌리면 평문 경로가 재개되고 원인 분석도 어려워진다. 우선 문제 네임스페이스나 워크로드의 정책만 되돌리고, 호출 경로를 제한하며, 임시 예외에 만료 시간을 둔다. 인증서·인가 정책 변경은 별도 배포로 나눠 어느 변경이 실패했는지 추적할 수 있어야 한다.

복구 훈련에는 CA 장애, 잘못된 루트 번들, 서비스 계정 변경, 메시 밖 배치 작업을 포함한다. 이 항목은 재해복구 탁상훈련의 인프라 시나리오로 넣기 좋다.

운영 체크리스트

• 워크로드와 서비스 ID의 매핑이 소유자와 함께 관리된다.
• 개발·운영 환경의 신뢰 도메인과 CA 경계를 분리한다.
• 평문 허용 예외에 소유자·이유·만료일이 있다.
• mTLS 성공 여부와 인가 거부를 별도 지표로 수집한다.
• 인증서 만료·회전·발급 실패 알림을 시험한다.
• STRICT 전환 전 비메시 클라이언트와 헬스체크를 식별한다.
• 인가 정책은 호출 주체와 경로를 최소 범위로 제한한다.
• 정책 롤백이 메시 전체 보안 해제로 이어지지 않는다.
• CA와 정책 변경 권한은 일상 운영 권한과 분리한다.

함께 읽을 글

CA 키와 메시 설정을 코드로 관리한다면 Terraform state 파일 보안을 함께 점검해야 한다. 비정상 프록시 증설이나 재시도 폭증은 클라우드 비용 이상 징후에도 나타날 수 있다.

참고 기준

• Istio Security Concepts
• Istio Mutual TLS Migration
• Istio TLS Configuration
• Kubernetes Security Checklist

결론

mTLS의 성공 기준은 설정 화면에 “enabled”가 표시되는 것이 아니다. 모든 워크로드 신원을 설명할 수 있고, 평문 예외를 찾을 수 있으며, 인증서 회전과 정책 실패를 장애 신호로 구분하고 안전하게 되돌릴 수 있는가가 운영 성숙도를 결정한다.