Istio 인가 정책, 혹시 아직도 ‘활성화’하고 계신가요? (ft. 우리만 몰랐던 진실) 😲

안녕하세요! MSA(Microservice Architecture) 환경에서 서비스를 개발하고 운영하는 분들이라면 한 번쯤 '보안'이라는 거대한 산 앞에서 막막함을 느껴보셨을 겁니다. 특히 서비스 간 통신이 복잡하게 얽히면서 "이 요청이 과연 안전한가? 🤨", "허가된 서비스만 서로 통신하게 할 순 없을까?" 하는 고민, 다들 해보셨죠?

 

이때 많은 분들이 서비스 메쉬(Service Mesh)의 대표 주자, Istio를 떠올립니다. Istio는 강력한 트래픽 제어, 관찰 가능성 그리고 '보안' 기능을 제공하니까요. 그중에서도 특정 서비스 간의 통신을 허용하거나 차단하는 인가(Authorization) 기능은 정말 매력적입니다.

 

그런데 여기서 많은 분들이 하는 결정적인 실수가 있습니다. 바로…

"Istio 인가 기능을 어떻게 '활성화'하죠?" 라는 질문입니다.

결론부터 말씀드리면, 그럴 필요가 없습니다! 🤯

---

💡 진실: Istio 인가는 '켜는' 기능이 아닙니다

많은 분들이 Istio를 설치할 때 IstioOperator 리소스를 수정하거나 설치 옵션으로 values.pilot.authorization.enabled=true 같은 설정을 찾아 헤매곤 합니다. 마치 새로운 기능을 추가 설치하듯 말이죠.

하지만 Istio의 인가 기능은 별도로 활성화할 필요 없이, Istio를 설치하는 순간 이미 우리 곁에 와 있습니다. 곁에 있지만 우리가 불러주지 않아서 조용히 있었을 뿐이죠.

비유하자면, 우리 집에 이미 '문 잠금장치'는 설치되어 있는 상태입니다. 우리는 그저 어떤 사람에게 '열쇠'를 줘서 문을 열게 할지, 아니면 열쇠를 주지 않아 못 들어오게 할지를 결정하기만 하면 되는 것입니다.

• Istio 인가 기능: 이미 설치된 문 잠금장치 🚪
• AuthorizationPolicy 리소스: 누구에게 열쇠를 줄지 정하는 규칙(정책) 🔑

즉, 인가 기능 자체는 Istio의 핵심 컴포넌트인 Envoy 프록시에 내장되어 항상 대기 중입니다. 우리가 AuthorizationPolicy라는 정책 리소스를 만들어 클러스터에 적용하는 순간, 이 잠금장치가 정책에 따라 작동을 시작하는 것이죠.

---

🧐 그렇다면 실제로 어떻게 작동할까요? (전체 프로세스 톺아보기)

개별 정책을 아는 것도 중요하지만, 전체적인 흐름을 이해하면 훨씬 쉽습니다.

1. Istio 설치 및 Sidecar 주입 🚀
   • Kubernetes 클러스터에 Istio를 설치합니다.
   • 우리가 보호하고 싶은 서비스(Pod)에 Istio의 Envoy 프록시(Sidecar)를 주입합니다. 이제 모든 트래픽은 이 프록시를 거치게 됩니다.
2. 정책 미적용 상태 (기본값: 모두 허용) ✅
   • 아무런 AuthorizationPolicy를 만들지 않으면, Istio는 메쉬 내부의 모든 트래픽을 허용(ALLOW)합니다. 보안 기능이 있지만, 규칙이 없으니 모든 통신을 통과시키는 것이죠.
3. AuthorizationPolicy 생성 및 적용 📝
   • 우리가 "A 서비스는 B 서비스의 GET 요청만 허용한다"와 같은 규칙을 YAML 파일로 작성합니다. 이것이 바로 AuthorizationPolicy입니다.
   • kubectl apply 명령어로 이 정책을 클러스터에 적용합니다.
4. Istiod의 역할 (정책 전파) 📡
   • 컨트롤 플레인인 Istiod가 이 AuthorizationPolicy 생성을 감지합니다.
   • Istiod는 이 정책을 해석해서 해당 정책의 영향을 받는 Envoy 프록시들에게 새로운 규칙을 전파합니다.
5. Envoy 프록시의 역할 (정책 강제) 👮
   • 정책을 전달받은 Envoy 프록시는 그때부터 들어오고 나가는 모든 트래픽을 검사합니다.
   • 정책에 명시된 규칙과 일치하는 트래픽은 허용(ALLOW)하고, 일치하지 않는 트래픽은 거부(DENY)합니다.

이 흐름을 이해하면, 우리가 할 일은 단지 '원하는 규칙을 잘 만들어서 적용'하는 것뿐이라는 걸 알 수 있습니다.

---

🛠️ 실제 예제로 이해하기: reviews 서비스 보호하기

말로만 하면 감이 안 오죠? 실제 코드를 통해 reviews 서비스로 들어오는 요청을 제어하는 정책을 만들어 보겠습니다.

시나리오: product-api 서비스만 reviews:v1 서비스의 /reviews/{id} 경로로 GET 요청을 보낼 수 있도록 허용한다. 그 외의 모든 요청은 차단한다.

1. AuthorizationPolicy 정의 (allow-product-to-reviews.yaml)

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: allow-product-to-reviews
  namespace: default
spec:
  # 이 정책을 적용할 워크로드를 선택합니다.
  # app: reviews, version: v1 레이블을 가진 Pod에 적용됩니다.
  selector:
    matchLabels:
      app: reviews
      version: v1
  # 이 정책의 기본 액션은 'ALLOW' 입니다.
  # 아래 'rules'에 맞는 요청을 허용하겠다는 의미입니다.
  action: ALLOW
  # 허용할 요청에 대한 상세 규칙을 정의합니다.
  rules:
  - from:
    # 어떤 '출발지'로부터 오는 요청을 허용할 것인가?
    - source:
        # 요청을 보내는 워크로드의 서비스 계정(Service Account)을 명시합니다.
        # 이것이 가장 안전하고 권장되는 방법입니다.
        principals: ["cluster.local/ns/default/sa/product-api"]
    to:
    # 어떤 '목적지'로 가는 요청을 허용할 것인가?
    - operation:
        # 허용할 HTTP 메서드를 지정합니다.
        methods: ["GET"]
        # 허용할 경로를 지정합니다.
        paths: ["/reviews/*"]

2. 정책 적용하기

터미널에서 아래 명령어를 실행하여 정책을 클러스터에 적용합니다.

kubectl apply -f allow-product-to-reviews.yaml

3. 결과 확인

이제 어떻게 될까요?

• 허용되는 요청 👍
  • product-api 서비스 계정으로 실행 중인 Pod가 reviews:v1 Pod의 /reviews/123으로 보내는 GET 요청
• 거부되는 요청 👎
  • product-api가 reviews:v1으로 보내는 POST 요청 (메서드가 달라서 거부)
  • unknown-service가 reviews:v1으로 보내는 GET 요청 (서비스 계정이 달라서 거부)
  • product-api가 reviews:v2으로 보내는 GET 요청 (정책의 selector에 version: v1이 지정되어 있어 v2에는 정책이 적용되지 않음. 만약 다른 DENY 정책이 없다면 이 요청은 기본적으로 허용됨)

⚠️ 중요: action: ALLOW 정책을 하나라도 적용하면, 해당 selector에 맞는 워크로드는 기본적으로 '암시적 DENY' 상태가 됩니다. 즉, ALLOW 규칙에 명시되지 않은 모든 요청은 자동으로 거부됩니다. 이것이 Istio의 강력한 Zero Trust 보안 모델의 시작입니다.

---

😫 흔한 오해들, 왜 틀렸을까요?

• "IstioOperator나 Helm 값으로 인가 기능을 활성화해야 한다."
  • 왜 아닌가요? 위에서 설명했듯이, 인가 기능은 Envoy 프록시의 핵심 기능으로 분리할 수 없는 부분입니다. 별도의 설치나 활성화 과정이 필요 없는 내장 기능(built-in)이기 때문입니다. 컨트롤 플레인(Istiod)은 단지 우리가 만든 정책을 프록시에 전달해주는 역할만 합니다.
• "Istio를 설치했으니 내 서비스는 이제 안전하다."
  • 왜 아닌가요? Istio를 설치만 한 상태는 '보안을 적용할 수 있는 능력'을 갖춘 것이지, '보안이 적용된 상태'가 아닙니다. AuthorizationPolicy를 적용하기 전까지는 모든 트래픽이 허용되므로, 반드시 명시적인 정책을 통해 원하는 보안 수준을 직접 설정해야 합니다.

✨ 결론: 생각을 바꾸면 Istio 보안이 쉬워집니다

Istio 인가 정책은 '활성화'하는 것이 아니라, '정책을 적용하여 실행'하는 것입니다.

이 간단한 사실 하나만 기억해도 Istio 보안에 접근하는 방식이 훨씬 명확해집니다. 더 이상 존재하지 않는 설정 값을 찾아 헤맬 필요 없이, 지금 바로 여러분의 서비스에 필요한 접근 규칙(AuthorizationPolicy)을 정의하고 적용해보세요. 작지만 강력한 YAML 파일 하나가 여러분의 MSA 환경을 훨씬 더 안전하게 만들어 줄 것입니다.

---