Istio AuthorizationPolicy 이해해보기

Istio에서는 Traffic에 대한 인가를 해주는 정책이있다 바로 AuthoriationPolicy 이다.
인가에 대한 설명을 잠시하자면 어떤 리소스에 접근할 수 있는지 또는 어떤 동작을 수행할 수 있는지를 검증하는 것, 즉 접근 권한을 얻는 일을 말합니다. 이번 글에서는 Istio의AuthoriationPolicy을 통한 인가 정책에 알아보겠습니다. 

 

• 구성환경
  • istio: 1.25.0

1. AuthorizationPolicy의 주요 구성 요소

AuthorizationPolicy는 다음과 같은 주요 요소로 구성됩니다:

• selector: 정책을 적용할 대상(워크로드)을 지정합니다.
• action: 허용(allow), 거부(deny), 감사(audit) 등의 동작을 정의합니다.
• rules: 조건을 기반으로 특정 요청을 필터링합니다. (예: IP, HTTP 메서드, JWT 클레임 등)

다 중요하지만 이번에는 rules를 통한 접근제어등을 살펴보고자합니다. 

rule은 source를 지정하며, opertion 조건을 지정도 할수 있습니다.  아래의 Table을 보며 간단히 이해해봅시다.

필드	설명
from	request를 날리는 출처입니다. from을 지정하게되면 해당 출발지에서만 오는 트래픽을 허용합니다.  만약 설정하지않으면 모든 source 즉 출발지가 허용됩니다.
to	to는 요청 작업을 지정하며, host, method등이 있습니다
when	when은 if문처럼 조건에대한 충족조건을 설정하는 곳입니다.

 

yaml을 보며 좀더 자세히 보도록 하겠습니다. 간단한 예시입니다.

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: httpbin
  namespace: foo
spec:
  action: DENY
  rules:
  - from:
    - source:
        namespaces: ["dev"]
    to:
    - operation:
        methods: ["POST"]

 

해당 yaml에는 action과 rules만 지정이 되어있습니다.

action은 DENY이고 거부정책입니다. namespace foo라는 곳에 있는 Service에 해당 인가정책을 적용합니다.

rules은 namespace Dev 에서 Post를 하는 경우에 거부하는 정책입니다.

 

이와같이 authoriationPolicy 인가정책은 NetworkPolicy랑 비슷한면이 있다는것을 볼수 있습니다. 물론 좀더 자세한 세밀한 컨트롤도 가능합니다. ( jwt 등 )

 

2. AuthorizationPolicy관련 실습해보기

2-0. Test를 위한 Deploy

먼저 istio에서 제공하는 httpbin deployment를 배포합니다. 

배포시 저는 istioexample로 Namespace만들고 배포했습니다.

# istio-injection을 namespace에 주입 후 배포

$ kubectl create istioexample
$ kubectl label namespace istioexample  istio-injection=enabled
$ kubectl apply -f https://raw.githubusercontent.com/istio/istio/refs/heads/master/samples/httpbin/httpbin.yaml -n istioexample
$ kubectl get pod
NAME                       READY   STATUS    RESTARTS   AGE
httpbin-7f56dc944b-8kt52   2/2     Running   0          2m4s

 

이후 서비스 통신을 위한 curl pod도 배포를 진행합니다. 해당 파드는 authorizationPolicy를 Test를 위해 default Namespace에 배포합니다.

# default 에 배포
$ kubectl apply -f https://raw.githubusercontent.com/istio/istio/refs/heads/master/samples/sleep/sleep.yaml  -n default

 

 

2-2. 정책 전체 거부 & 전체 허용

먼저 Deny을 전체적으로 배포해봅시다. 전체배포를 하려면 istio-system에 배포하게되면 전체 서비스가 거부가 됩니다.

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: deny-all
  namespace: istio-system
spec: {}

 

그후 한번 sleep파드로 httpbin에 요청을 날려봅시다.

k exec -n default deploy/sleep -c sleep -- curl -sSL httpbin.istioexample.svc:8000/get

거부가 됨..

다른 paths로 날려도 거부가 될것이다. 그렇다면 정책의 전체 허용은 어떤식으로 사용될까? 간단히 rules에 {} 만추가해주면된다.

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: deny-all
  namespace: istio-system
spec:
  rules:
  - {}

 

2-2. 특정 Paths만 허용하기

먼저 사용하기전 모든 거부정책을 삭제해줘야한다.

그리고 아래의 yaml을 배포해보자

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: allow-nothing
  namespace: istioexample
spec:
  selector:
    matchLabels:
      app: httpbin
  rules:
  - to:
    - operation:
        paths: ["/get"]

 

해당 httpbin에대해 /get Path는 허용하지만 그외에는 거부가 될것이다. 한번 요청을 해보자

 $ k exec -n default deploy/sleep -c sleep -- curl -sSL httpbin.istioexample.svc:8000/get

 

 

요청이 잘받아지는것을 볼수있다. 그렇다면 다른 Path는 허용될까??

이번엔 /status/200 을 날려보자

 $ k exec -n default deploy/sleep -c sleep -- curl -sSL httpbin.istioexample.svc:8000/status/200

 

deny가 된것을 알수 있다..이와같이 paths control이라던지 method방법이라던지 여러방법들이 굉장히 무궁무진하게 많다.

path라는건 대부분 유동적이기때문에 path에 대한 정규표현식도 허용을 한다. 그렇기에 이런부분들은 스스로 테스트를 해보는게 제일 좋은거같다.

이번엔 인가의 조건부 적용은 어떤식으로 흘러가는지도 보도록해보자

 

2-3. when 을 사용한 조건부 정책

when에대한 조건부는 key, values로 사용하여 정의한다. when조건을 사용하면 특정 headers만 허용한다던지 jwt토큰, sni , envoyfilter등 여러가지 조건등을 사용할 수 있다.

정의 조건은 https://istio.io/latest/docs/reference/config/security/conditions/ 에 보면 자세히 나와있다. 

이번에는 header를 통한 정책을 해보고자한다. 정의된 header가 없으면 deny가되고 있으면 allow가 되는 규칙을 사용해보자

 

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: allow-nothing
  namespace: istioexample
spec:
  action: ALLOW
  selector:
    matchLabels:
      app: httpbin
  rules:
  - when:
    - key: request.headers[swlee]
      values:
      - "good"

 

header에 키값으로 swlee를 넣고 good의 value를 넣어야 요청 트래픽이 httpbin에 허용될것이다.

먼저는 header가 실리지않은 request를 던져보자

$ k exec -n default deploy/sleep -c sleep -- curl -sSL httpbin.istioexample.svc:8000/get
$  k exec -n default deploy/sleep -c sleep -- curl -sSL httpbin.istioexample.svc:8000/ip

 

 

두곳다.. Deny가 되었다. 그렇다면 이번엔 Header를 넣어서 request를 하면 어떻게 될까??

$ k exec -n default deploy/sleep -c sleep -- curl -sSL -H "swlee:good" httpbin.istioexample.svc:8000/get
$ k exec -n default deploy/sleep -c sleep -- curl -sSL -H "swlee:good" httpbin.istioexample.svc:8000/ip

 

결과를 보면 성공적으로 가는것을 알수있다.

 

 

3. 정리하기

Istio의 AuthorizationPolicy를 활용하면 서비스 간 세분화된 접근 제어를 적용할 수 있습니다. 이를 통해 보안성을 강화하고, 정책을 중앙에서 관리하는 것이 가능해집니다. 내부 트래픽에 대한 보안을 강화하고자한다면 무조건 사용은 필수라고 볼 수 있겠다.