Istio in Action 9장 - 마이크로서비스 통신 보호하기

 

안녕하세요?
Istio in Action 책을 공부하면서 내용을 조금씩 정리해보려고 합니다.

9장은 마이크로서비스 통신 보호하기 입니다.

실습 환경 준비

• MacOS, OrbStack으로 Container 구동
• Kind, k8s 1.33.1
• istioctl 1.27.0

curl -L https://istio.io/downloadIstio | sh -

istioctl install --set profile=demo -y
        |\
        | \
        |  \
        |   \
      /||    \
     / ||     \
    /  ||      \
   /   ||       \
  /    ||        \
 /     ||         \
/______||__________\
____________________
  \__       _____/
     \_____/

WARNING: Istio is being upgraded from 1.13.0 to 1.27.0.
         Running this command will overwrite it; use revisions to upgrade alongside the existing version.
         Before upgrading, you may wish to use 'istioctl x precheck' to check for upgrade warnings.
✔ Istio core installed ⛵️
✔ Istiod installed 🧠
✔ Egress gateways installed 🛫
✔ Ingress gateways installed 🛬
✔ Installation complete

9.1 애플리케이션 네트워크 보안의 필요성

 

• 사용자 데이터를 지키기 위해서 필요한 것
  • 리소스 접근을 허가하기 전에 사용자 인증 및 인가
  • 데이터를 요청한 클라이언트로 가면서 여러 네트워크 장치를 거쳐가는 동안 데이터 도청을 방지하는 전송 중 데이터 암호화
• 인증 authentication
  • 클라이언트나 서버가 자신의 정체를 입증하는 절차
  • 패스워드, 인증서 등
• 인가 authorization
  • 이미 인증된 사용자가 리소스 생성이나 조회, 갱신, 삭제 작업을 수행하는 것을 허용하거나 거부하는 것

 

9.1.1 서비스간 인증

 

• 확인할 수 있는 ID 문서를 제시한 후에 다른 서비스를 신뢰해야 한다.
• 이 문서는 그 문서를 발급한 신뢰할 수 있는 제3자에게 확인한다.

 

9.1.2 최종 사용자 인증

 

• 대부분은 사용자를 인증 서버로 리다이렉션하는 것
• 사용자가 인증 서버에서 로그인을 성공하면 사용자 정보를 담고 있는 자격 증명을 받음(HTTP 쿠키나 JWT 등으로 저장)
• 사용자는 이 자격 증명을 서비스에 제시함

 

9.1.3 인가

 

• 인가는 호출자가 인증된 후 진행
• 호출자가 누구인지 서버가 식별하면 서버는 이 ID가 어떤 작업을 수행할 수 있도록 허용돼 있는지 확인하고 그에 따라 승인하거나 거부

 

9.1.4 모놀리스와 마이크로서비스의 보안 비교

 

• 둘 모두 최종 사용자 및 서비스 간 인증과 인가를 구현해야 함
• 마이크로서비스에는 네트워크를 오가는 커넥션과 요청이 훨씬 더 많아서 보호대상이 많음
  • 전통적인 IP 주소 등은 사용 불가
• 이스티오는 SPIFFE 사양을 사용함
• SPIFFE : 워크로드에 ID를 제공하기 위한 오픈소스 표준

 

9.1.5 이스티오가 SPIFFE를 구현하는 방법

 

• SPIFFE ID는 RFC 3986 호환 URI로, spiffe://trust-domain/path 형식
  • trust-domain : 개인 또는 조직 같은 ID 발급자를 나타냄
  • path : trust-domain 내에서 워크로드를 유일하게 식별
• SPIFFE 명세 구현자를 통해 워크로드를 식별하는 자세한 방법을 결정할 수 있다. (path가 아니라)
• 이스티오에서는 이 path를 특정 워크로드가 사용하는 서비스 어카운트로 채운다.
• SPIFFE ID는 X.509 인증서로 인코딩되며, 이스티오의 컨트롤 플레인이 워크로드마다 만들어낸다.
• 그리고 이 인증서는 전송 이터를 암호화해서 서비스간 통신의 전송을 보호한다.

 

9.1.6 이스티오 보안 요약

 

• PeerAuthentication
  • 이 리소스는 서비스 간의 트래픽을 인증하도록 프록시를 설정한다.
  • 인증에 성공하면, 프록시는 상대 peer의 인증서에 인코딩된 정보를 추출해 요청 인가에 사용할 수 있도록 한다.
• RequestAuthentication
  • 이 리소스는 프록시가 최종 사용자의 자격 증명을 발급 서버에 확인해 인증하도록 설정한다.
  • 인증에 성공하면, 역시 자격 증명에 인코딩된 정보를 추출해 요청 인가에 사용할 수 있도록 한다.
• AuthorizationPolicy
  • 이 리소스는 앞선 두 리소스에 따라 추출한 정보를 토대로 프록시가 요청을 인가하거나 거부하도록 구성한다.

 

9.2 자동 상호 TLS

• 사이드카 프록시가 주입된 서비스 사이의 트래픽은 암호화되고 서로 인증

• 메시를 더 안전하게 하기 위해서는
  • 서로 인증한 트래픽만 허용하도록 설정
  • 서비스를 인증하면 최소 권한 원칙을 준수

9.2.1 환경 설정하기

환경 설정하기

k label namespace istioinaction istio-injection=enabled
k apply -f services/catalog/kubernetes/catalog.yaml
k apply -f services/webapp/kubernetes/webapp.yaml 
k apply -f services/webapp/istio/webapp-catalog-gw-vs.yaml
k apply -f ch9/sleep.yaml -n default 

설정이 잘 되었는지 확인

k -n default exec deploy/sle
ep -c sleep -- curl -s webapp.istioinaction/api/catalog -o /dev/null -w "%{http_code}"
200

9.2.2 이스티오의 PeerAuthentication 리소스 이해하기

 

• PeerAuthentication
  • 워크로드가 상호 TLS를 엄격하게 요구하거나
  • 평문 트래픽을 허용하고 받아들이게 설정할 수 있음
  • 메시, 네임스페이스 범위, 워크로드 별로 설정 가능

메시 범위 정책으로 모든 미인증 트래픽 거부하기

 

• STRICT 상호 인증 모드를 강제해서 평문 트래픽 금지 가능

이스티오를 설치한 네임스페이스에 적용
메시 범위 리소스의 이름을 default로 짓는건 컨벤션

apiVersion: "security.istio.io/v1beta1"
kind: "PeerAuthentication"
metadata:
  name: "default" # 메시 정책 범위는 default라고 지어야 함. 
  namespace: "istio-system" # 이스티오를 설치한 네임스페이스 
spec:
  mtls:
    mode: STRICT # 상호 TLS 모드

적용 후에는 이렇게 된다.

k -n default exec deploy/sleep -c sleep -- curl -s webapp.istioinaction/api/catalog -o /dev/null -w "%{http_code}"
000command terminated with exit code 56

평문 요청이 거부된 것이다.

 

상호 인증하지 않은 트래픽 허용하기

apiVersion: "security.istio.io/v1beta1"
kind: "PeerAuthentication"
metadata:
  name: "default" # 네임스페이스 범위 리소스가 하나만 존재하도록 default 컨벤션
  namespace: "istio-system" # 정책을 적용할 네임스페이스 
spec:
  mtls:
    mode: PERMISSIVE # PERMISSIVE는 HTTP 트래픽을 허용한다. 

• 네임스페이스 범위 정책을 사용하면 메시 범위 정책을 덮어쓸 수 있다.
• 위와 같이하면 istioinaction 네임스페이스의 워크로드가 sleep 서비스와 같이 메시의 일부가 아닌 레거시 워크로드로부터 평문 트래픽을 받아들이도록 허용한다.

 

워크로드별 PeerAuthentication 정책 적용하기

 

• webapp만 목표로 하기 위해서 워크로드 셀렉터를 지정할 수 있음

  apiVersion: "security.istio.io/v1beta1"
  kind: "PeerAuthentication"
  metadata:
  name: "webapp"
  namespace: "istio-system"
  spec:
  selector:
    matchLabels:
      app: "webapp" # 이 레이블과 일치하는 워크로드는 PERMISSIVE 상호 TLS 모드사용
  mtls:
    model: PERMISSIVE

• k apply -f ch9/workload-permissive-peer-authn.yaml
• 위와 같이 설정시 상호 인증 정책이 webapp 워크로드에만 적용
• catalog 워크로드에는 적용 X

k -n default exec deploy/sleep -c sleep -- curl -s webapp.istioinaction/api/catalog
[{"id":1,"color":"amber","department":"Eyewear","name":"Elinor Glasses","price":"282.00"},{"id":2,"color":"cyan","department":"Clothing","name":"Atlas Shirt","price":"127.00"},{"id":3,"color":"teal","department":"Clothing","name":"Small Metal Shoes","price":"232.00"},{"id":4,"color":"red","department":"Watches","name":"Red Dragon Watch","price":"232.00"}]

• 이렇게 성공응답을 반환함.
• 메시 범위 정책으로 엄격한 기본값을 적용해도 일부 서비스들에는 그 서비스들이 메시로 옮겨질때까지 상호인증이 아닌 트래픽도 허용하도록 워크로드별 정책을 사용할 수 있음

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

 

 

여기서 istiod는 peerAuthentication 리소스 생성을 수신하고,
이 리소스를 엔보이용 설정으로 변환하며,
LDS (Listener Discovery Service)를 사용해 서비스 프록시에 적용한다.
구성된 정책들은 들어오는 요청마다 평가된다.

 

두 가지 추가적인 상호 인증 모드

 

• UNSET : 부모의 PeerAuthentication 정책을 상속
• DISABLE : 트래픽을 터널링하지 않는다. 서비스로 직접 보낸다.

 

tcpdump로 서비스 간 트래픽 스니핑하기

• 이스티오 프록시에는 tcpdump가 설치되어 있음
• tcpdump는 보안 때문에 privileged permission이 필요한데 기본적으로는 이 권한이 꺼져 있기 때문에
• istioctl로 업데이트 가능

istioctl install -y --set profile=demo --set values.global.proxy.privileged=true
        |\
        | \
        |  \
        |   \
      /||    \
     / ||     \
    /  ||      \
   /   ||       \
  /    ||        \
 /     ||         \
/______||__________\
____________________
  \__       _____/
     \_____/

✔ Istio core installed ⛵️
✔ Istiod installed 🧠
✔ Ingress gateways installed 🛬
✔ Egress gateways installed 🛫
✔ Installation complete

• 업데이트 후에 파드를 다시 만들어야 함

  k delete po -l app=webapp -n istioinaction
  pod "webapp-7c96945758-m7kbz" deleted

다른 터미널에서 트래픽을 스니핑하고 있는 중에

k -n istioinaction exec deploy/webapp -c istio-proxy -- \
  sudo tcpdump -l --immediate-mode -vv -s 0 'tcp and tcp[tcpflags] & tcp-push != 0'

호출을 해보면

k -n default exec deploy/sleep -c sleep -- curl -s webapp.istioinaction/api/catalog

평문으로 전송되고 있는것을 볼 수 있습니다.

08:25:43.161147 IP (tos 0x0, ttl 64, id 29362, offset 0, flags [DF], proto TCP (6), length 664)
    webapp-7c96945758-vxhc2.http-alt > 10.244.0.18.55520: Flags [P.], cksum 0x1897 (incorrect -> 0xfa55), seq 1:613, ack 94, win 128, options [nop,nop,TS val 4198710486 ecr 2676205684], length 612: HTTP, length: 612
    HTTP/1.1 200 OK
    content-length: 357
    content-type: application/json; charset=utf-8
    date: Sun, 12 Oct 2025 08:25:43 GMT
    x-envoy-upstream-service-time: 165
    server: istio-envoy
    x-envoy-decorator-operation: webapp.istioinaction.svc.cluster.local:80/*

    [{"id":1,"color":"amber","department":"Eyewear","name":"Elinor Glasses","price":"282.00"},{"id":2,"color":"cyan","department":"Clothing","name":"Atlas Shirt","price":"127.00"},{"id":3,"color":"teal","department":"Clothing","name":"Small Metal Shoes","price":"232.00"},{"id":4,"color":"red","department":"Watches","name":"Red Dragon Watch","price":"232.00"}] [|http]

 

9.3 서비스 간 트래픽 인가하기

 

• AuthorizationPolicy
  • 서비스 메시에 메시 범위, 네임스페이스 범위, 워크로드별 접근 정책을 정의하는 선언적 API

 

9.3.1 이스티오에서 인가 이해하기

apiVersion: "security.istio.io/v1beta1"
kind: "AuthorizationPolicy"
metadata:
  name: "allow-catalog-requests-in-web-app"
  namespace: istioinaction
spec:
  selector:
    matchLabels:
      app: webapp
  rules:
  - to:
    - operation:
        paths: ["/api/catalog*"]
  action: ALLOW

• 인가 정책의 속성
  • selector 필드
    • 정책을 적용할 워크로드의 부분집합을 정의
  • action 필드
    • 이 정책이 허용 ALLOW, 거부 DENY, 커스텀 CUSTOM인지 지정
    • action은 규칙 중 하나가 요청과 일치하는 경우에만 적용
  • rules 필드
    • 정책을 활성화할 요청을 식별하는 규칙 목록을 정의
• 인가 정책 규칙 이해하기
  • 커넥션의 출처 source를 지정하며 일치해야 규칙을 활성화하는 작업 operation 조건을 지정할 수도 있다.
  • 인가 정책은 규칙 중 하나의 출처와 작업 조건 을 모두 만족 시키는 경우에만 집행된다.
• 단일 규칙의 필드
  • from 필드 : 요청의 출처를 다음 유형 중 하나로 지정한다.
    • principals: 출처 ID(SPIFFE ID) 목록. 요청이 주체 principal 집합에서 온 것이 아니면 부정 속성인 notPrincipals가 적용
      • 이 기능이 작동하려면 서비스가 상호인증해야 한다.
    • namespaces: 출처 네임스페이스와 비교할 네임스페이스 목록. 출처 네임스페이스는 참가자의 SVID에서 가져온다.
      • 작동 하려면 상호 TLS가 활성화되어야 한다.
    • ipBlocks: 출처 IP주소와 비교할 단일 IP주소나 CIDR qjadnl ahrfhr
  • to 필드 : 요청의 작업을 지정하며, 호스트나 요청의 메서드 등이 있다.
  • when 필드 : 규칙이 부합한 후 충족해야 하는 조건 목록을 지정

 

9.3.3. 워크로드에 정책 적용시 동작 변경

 

• 워크로드에 하나 이상의 ALLOW 인가 정책이 적용되면, 모든 트래픽에서 해당 워크로드로의 접근은 기본적으로 거부된다.
• 트래픽을 받아들이려면 ALLOW 정책이 최소 하나는 부합해야 한다.

 

9.3.4 전체 정책으로 기본적으로 모든 요청 거부하기

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: deny-all
  namespace: istio-system # 이스티오를 설치한 네임스페이스의 정책은 메시의 모든 워크로드에 적용된다. 
spec: {} # spec이 비어있는 정책은 모든 요청을 거부한다. 

• 이렇게 하면 ALLOW 정책을 명시적으로 지정하지 않은 모든 요청을 거부하는 메시 범위 정책이 적용된다.
• 기본 거부 catch-all deny-all 정책

k apply -f ch9/policy-deny-all-mesh.yaml
authorizationpolicy.security.istio.io/deny-all created

그 이후

k -n default exec deploy/sleep -c sleep -- curl -s webapp.istioinaction/api/catalog
RBAC: access denied

요청을 허용하는 정책이 없으므로 일반 거부 정책이 거부한다.
어떤 규칙도 없다는 것이 어떤 요청도 허용하지 않는 다는 의미라면
역으로 빈 규칙은 모든 요청을 허용한다는 의미이다.

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

 

9.3.5 특정 네임스페이스에서 온 요청 허용하기

apiVersion: "security.istio.io/v1beta1"
kind: "AuthorizationPolicy"
metadata:
  name: "webapp-allow-view-default-ns"
  namespace: istioinaction
spec:
  rules:
    - from: 
      - source:
          namespaces: ["default"] # default namespace에서 시작한
    - to:
      - operation:
          methods: ["GET"] # HTTP GET 요청에만 적용

 

9.3.6 미인증 레거시 워크로드에서 온 요청 허용하기

apiVersion: "security.istio.io/v1beta1"
kind: "AuthorizationPolicy"
metadata:
  name: "webapp-allow-unauthenticated-view"
  namespace: istioinaction
spec:
  selector:
    matchLabels:
      app: webapp
  rules:
    - to:
      - operation:
          methods: ["GET"]

• webapp에만 적용하기 위해 app:webapp 셀렉터를 추가

 

9.3.7 특정 서비스 어카운트에서 온 요청 허용하기

• 트래픽이 webapp에서 왔는지 인증하려면 트래픽에 주입된 서비스 어카운트를 사용할 수 있다.
• 서비스 어카운트 정보는 SVID에 인코딩되어 있으며, 상호 인증 중에 그 정보를 검증하고 필터 메타데이터에 저장한다.
• 다음 정책은 catalog 서비스가 필터 메타데이터를 사용해 서비스 어카운트가 webapp인 워크로드에서 온 트래픽만 허용하도록 설정.

apiVersion: "security.istio.io/v1beta1"
kind: "AuthorizationPolicy"
metadata:
  name: "catalog-viewer"
  namespace: istioinaction
spec:
  selector:
    matchLabels:
      app: catalog
  rules:
  - from:
    - source:
        principals: ["cluster.local/ns/istioinaction/sa/webapp"] # ID가 webapp 인 요청을 허용
    to:
    - operation:
        methods: ["GET"]

 

9.3.8 정책의 조건부 허용

• 아래처럼 사용자가 관리자일때 모든 작업을 허용할 수 있다.
• 인가 정책의 when 속성을 사용해 구현한다.
  • 토큰이 요청 주체 auth@istioinaction.io/* 가 발급한 것이어야 함
  • JWT에 값이 admin인 group 클레임이 포함되어있어야 함
    

apiVersion: "security.istio.io/v1beta1"
kind: "AuthorizationPolicy"
metadata:
  name: "allow-mesh-all-ops-admin"
  namespace: istioinaction
spec:
  selector:
    matchLabels:
      app: catalog
  rules:
  - from:
    - source:
        requestPrincipals: ["auth@istioinaction.io/*"]
    when:
    - key: request.auth.claims[group] # 이스티오 속성을 지정
      values: ["admin"] # 반드시 일치해야 하는 값의 목록을 지정

 

9.3.10 인가 정책이 평가되는 순서 이해하기

1. CUSTOM 정책이 가장 먼저 평가된다.
2. 다음으로 DENY 정책이 평가된다. 일치하는 DENY 정책이 없으면,
3. ALLOW 정책이 평가된다. 일치하는 것이 있으면 허용된다. 그렇지 않으면,
4. 일반 정책의 존재 유무에 따라 두 가지 결과가 나타난다.
   1. 일반 정책이 존재하면, 일반 정책이 요청 승인 여부를 결정한다.
   2. 일반 정책이 없으면, 요청은 다음과 같다.
      1. ALLOW 정책이 없으면 허용된다.
      2. ALLOW 정책이 있지만 아무것도 해당되지 않으면 거부된다.

 

9.4 최종 사용자 인증 및 인가

9.4.1 JSON 웹 토큰

• JWT는 클라이언트를 서버에 인증하는데 사용하는 간단한 클레임 표현
• 구성요소
  • 헤더 : 유형 및 해싱 알고리즘
  • 페이로드 : 사용자 클레임 포함
  • 서명 : JWT의 진위 여부를 파악하는 데 사용
  • 이 세 부분이 점으로 구분되어있고 Base64 URL로 인코딩되어 HTTP 요청에 사용하기 적합하다.

 

JWT는 어떻게 발행되고 검증되는가?

• JWT는 인증서버에서 발급
• 인증서버는 토큰을 서명하는 비밀 키와 검증하기 위한 공개 키를 갖고 있다.
• 공개 키는 JWKS JSON Web Key Set라고 하며
• well-known HTTP 엔드포인트에 노출된다.
• 이 서비스는 이 엔드포인트에서 공개 키를 가져와 인증 서버가 발급한 토큰을 검증할 수 있다.

인증서버 구현방법

• 애플리케이션 백엔드 프레임워크
• OpenIAM, Keycloak
• Auth0, Okta

 

9.4.2 인그레스 게이트웨이에서의 최종 사용자 인증 및 인가

 

• 이스티오 워크로드가 JWT로 최종 사용자 요청을 인증하고 인가하도록 설정할 수 있다.
• 최종 사용자 : ID 제공자에게 인증받고 ID와 클레임을 나타내는 토큰을 발급받은 사용자.
• 보통 이스티오 인그레스 게이트웨이에서 수행한다.워크스페이스 준비

k apply -f services/catalog/kubernetes/catalog.yaml
k apply -f services/webapp/kubernetes/webapp.yaml

인증 및 인가를 설정하기 전에 Gateway 리소스를 사용해 이스티오의 인그레스 게이트웨이로 트래픽 허용이 필요

k apply -f ch9/enduser/ingress-gw-for-webapp.yaml
gateway.networking.istio.io/webapp-gateway created
virtualservice.networking.istio.io/webapp-virtualservice created

 

9.4.3 RequestAuthentication으로 JWT 검증하기

 

• RequestAuthentication 리소스의 주 목적
  • JWT를 검증하고
  • 유효한 토큰의 클레임을 추출하고
  • 이 클레임을 필터 메타데이터에 저장
• 필터 메타데이터
  • 서비스 프록시에서 필터 간 요청을 처리하는 동안 사용할 수 있는 키-값
  • 필터 메타데이터는 인가 정책이 조치를 취하는 근거로 사용
  • 인가 정책이 요청을 허용하거나 거부하는데 사용
• 최종 사용자 요청에 따라 결과는 셋 중 하나가 됨
  • 유효한 토큰을 갖고 있는 요청은 클러스터로 받아들여지며 이들의 클레임은 필터 메타데이터 형태로 정책에 전달
  • 유효하지 않은 토큰을 갖고 있는 요청은 거부
  • 토큰이 없는 요청은 클러스터로 받아들여지지만 요청 ID가 없어서 어떤 클레임도 필터 메타데이터에 저장되지 않음
• JWT가 있는 요청과 없는 요청의 차이
  • 있는 요청 : Reuqest Authentication 필터로 검증되고 JWT 클레임이 커넥션 필터 메타데이터에 저장
  • 없는 요청 : 커넥션 필터 메타데이터에 클레임이 없음.
• 그러나 RequestAuthentication 리소스 그 자체는 인가를 적용하지 않는다.
• 인가를 위해서는 여전히 AuthorizaionPolicy가 필요함

 

RequestAuthentication 리소스 만들기

 

• 이렇게 만들고 나서 세 가지 유형의 요청과 예상 결과를 검증할 수 있다.

apiVersion: "security.istio.io/v1beta1"
kind: "RequestAuthentication"
metadata:
  name: "jwt-token-request-authn"
  namespace: istio-system # 이 네임스페이스에 적용
spec:
  selector:
    matchLabels:
      app: istio-ingressgateway
  jwtRules:
  - issuer: "auth@istioinaction.io" # 예상 발행자 
    jwks: | # 특정 JWKS로 검증 가능
      { "keys":[ {"e":"AQAB","kid":"CU-ADJJEbH9bXl0tpsQWYuo4EwlkxFUHbeJ4ckkakCM","kty":"RSA","n":"zl9VRDbmVvyXNdyoGJ5uhuTSRA2653KHEi3XqITfJISvedYHVNGoZZxUCoiSEumxqrPY_Du7IMKzmT4bAuPnEalbY8rafuJNXnxVmqjTrQovPIerkGW5h59iUXIz6vCznO7F61RvJsUEyw5X291-3Z3r-9RcQD9sYy7-8fTNmcXcdG_nNgYCnduZUJ3vFVhmQCwHFG1idwni8PJo9NH6aTZ3mN730S6Y1g_lJfObju7lwYWT8j2Sjrwt6EES55oGimkZHzktKjDYjRx1rN4dJ5PR5zhlQ4kORWg1PtllWy1s5TSpOUv84OPjEohEoOWH0-g238zIOYA83gozgbJfmQ"}]}

 

유효한 발행자의 토큰이 있는 요청은 받아들여진다.

 USER_TOKEN=$(< ch9/enduser/user.jwt); curl -H "Host: webapp.istioinaction.io" -H "Authorization: Bearer $USER_TOKEN" -sSl -o /dev/null -w "%{http_code}" http://192.168.97.2:31733/api/catalog
200

 

유효하지 않은 발급자의 토큰이 있는 요청은 거부된다.

 WRONG_ISSUER=$(< ch9/enduser/not-configured-issuer.jwt); curl -H "Host: webapp.istioinaction.io" -H "Authorization: Bearer $WRONG_ISSUER" -sSl -o /dev/null -w "%{http_code}" http://192.168.97.2:31733/api/catalog
401

 

토큰이 없는 요청은 클러스터로 받아들여진다.

curl -H "Host: webapp.istioinaction.io" -sSl -o /dev/null -w "%{http_code}" http://192.168.97.2:31733/api/catalog
200

 

9.5 커스텀 외부 인가 서비스와 통합하기