| 일 | 월 | 화 | 수 | 목 | 금 | 토 |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | ||||
| 4 | 5 | 6 | 7 | 8 | 9 | 10 |
| 11 | 12 | 13 | 14 | 15 | 16 | 17 |
| 18 | 19 | 20 | 21 | 22 | 23 | 24 |
| 25 | 26 | 27 | 28 | 29 | 30 | 31 |
Tags
- vpc cni
- CICD
- argocd
- docker
- Kind
- grafana
- Istio
- CNI
- Observability
- istio in action
- service entry
- K8S
- Ingress
- loadbalancer
- envoy
- prometheus
- aws gateway api controller
- vagrant
- peerauthentication
- leastconnection
- WSL
- Jenkins
- aws eks
- kiali
- traffic cloning
- authorizationpolicy
- requestauthentication
- Kubernetes
- service mesh
- traffic mirroring
Archives
- Today
- Total
WellSpring
Istio 5주차 - 마이크로서비스 통신 보안 본문
목차
※ 본 게재 글은 gasida님의 'Istio' 스터디 강의 및 실습예제와 'Istio in Action' 서적을 참고하여 작성하였습니다.
Chap9. 마이크로서비스 통신 보안하기
[ 이 챕터에서 다루는 내용 ] - Securing microservice communication
- 서비스 메시에서 서비스 간 인증 및 인가 처리하기 Handling service-to-service authentication and authorization in the service mesh
- 최종 사용자 인증 및 인가 처리하기 Handling end-user authentication and authorization
[ 들어가며 ]
더보기
- 4장에서는 트래픽을 메시로 허용하는 방법을 다륐는데, 트래픽을 보호하는 방법도 몇 가지 포함됐다.
- 여기서는 서비스 메시 기능을 사용해 서비스 기반 아키텍처의 보안 태세를 투명하게 개선하는 방법을 자세히 살펴본다.
- 이스티오는 기본적으로 안전하다.
- 이번 장에서는 그 의미는 무엇인지, 어떻게 동작하는지, 서비스 간 및 최종 사용자 인증은 어떻게 구현되는지를 설명하고 서비스 메시 내 서비스에 대한 접근 제어도 알아본다.
- 기능을 살펴보기에 앞서 먼저 보안 주제에 대해 간략히 설명한다.
- 이스티오에서 보안이 작동하는 방식은 부록 C에서 자세히 다룰 것이다.
▶ [실습 환경 구성] k8s(1.23.17) 배포 : NodePort(30000 HTTP, 30005 HTTPS)
더보기
#
git clone https://github.com/AcornPublishing/istio-in-action
cd istio-in-action/book-source-code-master
pwd # 각자 자신의 pwd 경로
code .
# 아래 extramounts 생략 시, myk8s-control-plane 컨테이너 sh/bash 진입 후 직접 git clone 가능
kind create cluster --name myk8s --image kindest/node:v1.23.17 --config - <<EOF
kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
nodes:
- role: control-plane
extraPortMappings:
- containerPort: 30000 # Sample Application (istio-ingrssgateway) HTTP
hostPort: 30000
- containerPort: 30001 # Prometheus
hostPort: 30001
- containerPort: 30002 # Grafana
hostPort: 30002
- containerPort: 30003 # Kiali
hostPort: 30003
- containerPort: 30004 # Tracing
hostPort: 30004
- containerPort: 30005 # Sample Application (istio-ingrssgateway) HTTPS
hostPort: 30005
- containerPort: 30006 # TCP Route
hostPort: 30006
- containerPort: 30007 # kube-ops-view
hostPort: 30007
extraMounts: # 해당 부분 생략 가능
- hostPath: /mnt/d/Learnings/04_Istio/istio-in-action/book-source-code-master # 각자 자신의 pwd 경로로 설정
containerPath: /istiobook
networking:
podSubnet: 10.10.0.0/16
serviceSubnet: 10.200.1.0/24
EOF
# 설치 확인
docker ps
# 노드에 기본 툴 설치
docker exec -it myk8s-control-plane sh -c 'apt update && apt install tree psmisc lsof wget bridge-utils net-tools dnsutils tcpdump ngrep iputils-ping git vim -y'
# (옵션) kube-ops-view
helm repo add geek-cookbook https://geek-cookbook.github.io/charts/
helm install kube-ops-view geek-cookbook/kube-ops-view --version 1.2.2 --set service.main.type=NodePort,service.main.ports.http.nodePort=30007 --set env.TZ="Asia/Seoul" --namespace kube-system
kubectl get deploy,pod,svc,ep -n kube-system -l app.kubernetes.io/instance=kube-ops-view
## kube-ops-view 접속 URL 확인
open "http://localhost:30007/#scale=1.5"
open "http://localhost:30007/#scale=1.3"
# (옵션) metrics-server
helm repo add metrics-server https://kubernetes-sigs.github.io/metrics-server/
helm install metrics-server metrics-server/metrics-server --set 'args[0]=--kubelet-insecure-tls' -n kube-system
kubectl get all -n kube-system -l app.kubernetes.io/instance=metrics-server
▶ [실습 환경 구성] istio 1.17.8 설치 - Docs , Install , prof
더보기
istio 설치 ( Version 1.17.8 )
demo 프로파일 컨트롤 플레인 배포
# myk8s-control-plane 진입 후 설치 진행
docker exec -it myk8s-control-plane bash
-----------------------------------
# (옵션) 코드 파일들 마운트 확인
tree /istiobook/ -L 1
혹은
git clone ... /istiobook
# istioctl 설치
export ISTIOV=1.17.8
echo 'export ISTIOV=1.17.8' >> /root/.bashrc
curl -s -L https://istio.io/downloadIstio | ISTIO_VERSION=$ISTIOV sh -
cp istio-$ISTIOV/bin/istioctl /usr/local/bin/istioctl
istioctl version --remote=false
# demo 프로파일 컨트롤 플레인 배포
istioctl install --set profile=demo --set values.global.proxy.privileged=true -y
# 보조 도구 설치
kubectl apply -f istio-$ISTIOV/samples/addons
# 빠져나오기
exit
-----------------------------------
# 설치 확인 : istiod, istio-ingressgateway, crd 등
kubectl get istiooperators -n istio-system -o yaml
kubectl get all,svc,ep,sa,cm,secret,pdb -n istio-system
kubectl get cm -n istio-system istio -o yaml
kubectl get crd | grep istio.io | sort
# 실습을 위한 네임스페이스 설정
kubectl create ns istioinaction
kubectl label namespace istioinaction istio-injection=enabled
kubectl get ns --show-labels
# istio-ingressgateway 서비스 : NodePort 변경 및 nodeport 지정 변경 , externalTrafficPolicy 설정 (ClientIP 수집)
kubectl patch svc -n istio-system istio-ingressgateway -p '{"spec": {"type": "NodePort", "ports": [{"port": 80, "targetPort": 8080, "nodePort": 30000}]}}'
kubectl patch svc -n istio-system istio-ingressgateway -p '{"spec": {"type": "NodePort", "ports": [{"port": 443, "targetPort": 8443, "nodePort": 30005}]}}'
kubectl patch svc -n istio-system istio-ingressgateway -p '{"spec":{"externalTrafficPolicy": "Local"}}'
kubectl describe svc -n istio-system istio-ingressgateway
# NodePort 변경 및 nodeport 30001~30003으로 변경 : prometheus(30001), grafana(30002), kiali(30003), tracing(30004)
kubectl patch svc -n istio-system prometheus -p '{"spec": {"type": "NodePort", "ports": [{"port": 9090, "targetPort": 9090, "nodePort": 30001}]}}'
kubectl patch svc -n istio-system grafana -p '{"spec": {"type": "NodePort", "ports": [{"port": 3000, "targetPort": 3000, "nodePort": 30002}]}}'
kubectl patch svc -n istio-system kiali -p '{"spec": {"type": "NodePort", "ports": [{"port": 20001, "targetPort": 20001, "nodePort": 30003}]}}'
kubectl patch svc -n istio-system tracing -p '{"spec": {"type": "NodePort", "ports": [{"port": 80, "targetPort": 16686, "nodePort": 30004}]}}'
# Prometheus 접속 : envoy, istio 메트릭 확인
open http://127.0.0.1:30001
# Grafana 접속
open http://127.0.0.1:30002
# Kiali 접속 1 : NodePort
open http://127.0.0.1:30003
# (옵션) Kiali 접속 2 : Port forward
kubectl port-forward deployment/kiali -n istio-system 20001:20001 &
open http://127.0.0.1:20001
# tracing 접속 : 예거 트레이싱 대시보드
open http://127.0.0.1:30004
9.1 애플리케이션 네트워크 보안의 필요성
https://netpple.github.io/docs/istio-in-action/Istio-ch9-securing-1-overview
▶ 들어가며 : 인증, 인가, 전송 중 데이터 암호화
더보기
- 애플리케이션 보안이란, 인가 받지 않은 사용자가 오염시키거나 훔치거나 접근해서는 안 되는 귀중한 애플리케이션 데이터를 보호하는 데 기여하는 모든 행동을 말한다.
- 사용자 데이터를 지키려면 다음 사항이 필요하다.
- 리소스 접근을 허가하기 전에 사용자 인증 및 인가
- 데이터를 요청한 클라이언트로 가면서 여러 네트워크 장치를 거쳐가는 동안 데이터 도청을 방지하는 전송 중 데이터 암호화
☞ 인증(authentication)이란 클라이언트나 서버가 자신의 정체를 입증하는 절차를 말하며, 아는 것(패스워드)이나 갖고 있는 것(장치, 인증서) 또는 자기 자신(지문 같은 고유 특성)을 이용한다. 인가(authorization)란 이미 인증된 사용자가 리소스의 생성이나 조회, 갱신, 삭제 같은 작업을 수행하는 것을 허용하거나 거부하는 절차를 말한다.
9.1.1 서비스 간 인증 Service-to-service authentication - SPIFFE 프레임워크
더보기
- 안전하려면, 서비스는 자신이 상호작용하는 서비스는 모두 인증해야 한다.
- 다시 말해, 확인할 수 있는 ID 문서를 제시한 후에만 다른 서비스를 신뢰해야 한다.
- 보통, 이 문서는 그 문서를 발급한 신뢰할 수 있는 제3자에게 획인한다.
- 이번 장에서는 이스티오가 SPIFFE Secure Prduction Identity Framework For Everyone 프레임워크를 사용해 서비스들의 ID 발급을 자동화하는 방법을 다룬다.
- *Universal identity control plane for distributed systems https://spiffe.io/*
- SPIFFE and SPIRE provide strongly attested, cryptographic identities to workloads across a wide variety of platforms
- SPIFFE is a set of open-source specifications for a framework capable of bootstrapping and issuing identity to services across heterogeneous environments and organizational boundaries. The heart of these specifications is the one that defines short lived cryptographic identity documents – called SVIDs via a simple API. Workloads can then use these identity documents when authenticating to other workloads, for example by establishing a TLS connection or by signing and verifying a JWT token.
- *https://spiffe.io/docs/latest/spiffe-about/overview/* → Implements 확인*
- 발급된 ID는 서비스들이 서로 인증하는 데 사용한다.
9.1.2 최종 사용자 인증 End-user authentication - JWT 등 자격증명
더보기
- 최종 사용자 인증은 사용자의 개인 데이터를 저장하는 애플리케이션의 핵심이다.
- 성숙한 최종 사용자 인증 프로토콜은 여러 가지가 있지만, 대부분은 사용자를 인증 서버로 리다이렉션하는 것이 핵심이다.
- 사용자가 인증 서버에서 로그인을 성공하면 사용자 정보를 담고 있는 자격 증명(HTTP 쿠키나 JWT 등으로 저장)을 받는다.
- 사용자는 인증을 위해 이 자격 증명을 서비스에 제시한다.
- 서비스는 어떤 종류든 접근을 허용하기 전에 자격 증명을 발급한 인증 서버에 자격 증명을 검증한다.
9.1.3 인가 Authorization - 작업 수행 승인/거부
더보기
- 인가는 호출자가 인증된 후 진행된다.
- 호출자가 ‘누구’인지 서버가 식별하고 나면, 서버는 이 ID가 ‘어떤’ 작업을 수행할 수 있도록 허용돼 있는지 확인하고 그에 따라 승인하거나 거부한다.
- 예를 들어 웹 애플리케이션에서 인가는 사용자가 리소스를 생성, 조회, 업데이트, 삭제할 수 있는지 여부를 확인하는 형식을 취한다.
- 이스티오는 서비스 인증과 ID 모델을 기반으로 서비스 사이에 또는 최종 사용자와 서비스 사이에 세분화된 인가 기능을 제공한다.
9.1.4 모놀리스와 마이크로서비스의 보안 비교 Comparison of security in monoliths and microservices
더보기
고정IP로 온프레미스에서 실행되는 모놀리스 애플리케이션
- 마이크로서비스와 모놀리스 모두 최종 사용자 및 서비스 간 인증과 인가를 구현해야 한다.
- 그러나 마이크로서비스에는 보호해야 하는, 네트워크를 오가는 커넥션과 요청이 훨씬 더 많다.
- 반면 모놀리스는 커넥션이 더 적고, 보통은 가상머신 혹은 물리 머신 같은 더 정적인 인프라에서 실행된다.
- 정적인 인프라에서 실행하면 (고정) IP 주소를 ID 확인 근거로 심기 좋으며, 덕분에 인증용 인증서에서 흔하게 사용한다. (네트워크 방화벽 규칙에도 사용한다)
- 그림 9.1은 IP를 신뢰의 근거로 삼기 좋은 정적 인프라를 보여준다.
- 반면에 마이크로서비스는 쉽게 수백, 수천 개의 서비스로 불어나므로 정적 환경에서는 서비스를 운영할 수 없다.
- 이런 이유로 클라우드 컴퓨팅이나 컨테이너 오케스트레이션 같은 동적 환경을 활용하는데, 여기서 서비스는 수많은 서버로 스케줄링되고 수명이 짧다.
- 따라서 IP 주소를 사용하는 것 같은 전통적인 방법들은 ID의 근거로 미덥지 못하게 된다.
- 설상가상으로 서비스가 반드시 같은 네트워크에서 실행되는 것도 아니며, 여러 클라우드 프로바이더에 걸쳐 있거나 심지어는 그림 9.2처럼 온프레미스에서도 실행 될 수 있다.
- 이런 문제를 해결해 고도로 동적이고 이질적인 환경에서 ID를 제공하고자 이스티오는 SPIFFE specification 사양을 사용한다.
- SPIFFE는 고도로 동적이고 이질적인 환경에서 워크로드에 ID를 제공하기 위한 일렬의 오픈소스 표준이다.
- SPIFFE 처리에 대한 더 자세한 내용과 함께 이 SPIFFE가 이스티오의 ID 추정을 뒷받침하는 방법을 보려면 부록 C를 참조하자.
9.1.5 이스티오가 SPIFFE를 구현하는 방법 How Istio implements SPIFFE - SVID
더보기
- SPIFFE ID는 RFC 3986 호환 URI로, spiffe://trust-domain/path 형식으로 구성된다.
- 여기서는 다음과 같다.
- trust-domain 은 개인 또는 조직 같은 ID 발급자를 나타낸다.
- path는 trust-domain 내에서 워크로드를 유일하게 식별한다.
- path가 워크로드를 식별하는 자세한 방법은 정해져 있지 않아서 SPIFFE 명세 구현자가 결정할 수 있다.
- 이스티오에서는 이 path를 특정 워크로드가 사용하는 서비스 어카운트로 채운다.
- SPIFFE ID는 SVID (Spiffe Verifiable Identity Document, SPIFFE 검증할 수 있는 ID 문서) 라고도 하는 X.509 인증서로 인코딩되며, 이는 이스티오의 컨트롤 플레인이 워크로드마다 만들어낸다.
- 그런 다음, 이 인증서는 전송 데이터를 암호화함으로써 서비스 간 통신의 전송을 보호하는데 사용된다.
- 다시 말하지만, 부록 C에서 이 모든 작업이 어떻게 작동하는지를 휠씬 자세히 다룬다.
- 이번 장에서는 이스티오의 기능으로 보안 태세를 개선하는 데 초점을 맞춘다.
9.1.6 이스티오 보안 요약 Istio security in a nutshell - PeerAuthentication , RequestAuthentication , AuthorizationPolicy
더보기
요청을 인증 및 인가하도록 서비스 프록시를 구성하는 리소스
- 이스티오 보안을 이해하기 위해 이스티오가 정의한 커스텀 리소스로 프록시를 설정하는 서비스 메시 운영자의 관점으로 바꿔보자.
- PeerAuthentication 리소스는 서비스 간의 트래픽을 인증하도록 프록시를 설정한다. The PeerAuthentication resource configures the proxy to authenticate service-to-service traffic.
- 인증에 성공하면, 프록시는 상대 peer의 인증서에 인코딩된 정보를 추출해 요청 인가에 사용할 수 있도록 한다.
- RequestAuthentication 리소스는 프록시가 최종 사용자의 자격 증명을 발급 서버에 확인해 인증하도록 설정한다. The RequestAuthentication resource configures the proxy to authenticate end-user credentials against the servers that issued them.
- 인증에 성공하면, 역시 자격 증명에 인코딩된 정보를 추출해 요청 인가에 사용할 수 있도록 한다.
- AuthorizationPolicy 리소스는 앞선 두 리소스에 따라 추출한 정보를 토대로 프록시가 요청을 인가하거나 거부하도록 구성한다. The AuthorizationPolicy resource configures the proxy to authorize or reject requests by making decisions based on the data extracted by the previous two resources.
- PeerAuthentication 리소스는 서비스 간의 트래픽을 인증하도록 프록시를 설정한다. The PeerAuthentication resource configures the proxy to authenticate service-to-service traffic.
- 그림 9.3은 PeerAuthentication 과 RequestAuthentication 리소스가 어떻게 요청을 인증하도록 프록시를 구성하는지, 자격 증명(SVID나 JWT)에 인코딩된 정보가 어느 시점에 추출돼 필터 메타데이터로 저장되는지를 보여준다.
- 필터 메타데이터는 커넥션 ID를 나타낸다. The filter metadata represents the connection identity.
- AuthorizationPolicy 리소스는 그 커넥션 ID에 기반해 요청을 허가할지 거부할지를 결정한다.
- *PeerAuthentication* : 서비스-to-서비스 인증 설정, 인가를 위한 피어 정보 추출
- *RequestAuthentication* : End-user 인증 설정, 인가를 위한 유저 정보 추출
- *AuthorizationPolicy* : PeerAuthentication, RequestAuthentication 에서 추출한 피어/유저 정보에 기초하여 권한 판단을 위한 인가 정책을 설정
[ Istio Security Architecture ]
- The Istio CA manages keys and certificates and the SANs in certificates are in SPIFFE format.
- Istiod distributes authentication and authorization security policies to all sidecars in the mesh.
- Sidecars enforce authentication and authorization as per security policies distributed by Istiod
[도전과제1] Istio 1.17 공식 문서에 ‘Security’ 와 ‘Security Best Practices’ 내용 정리
9.2 자동 상호 TLS (Auto mTLS)
☞ https://netpple.github.io/docs/istio-in-action/Istio-ch9-securing-2-auto_mTLS
▶ 들어가며 : 인증서 발급/갱신 자동화, 추가 작업(인증, 인가)
더보기
워크로드는 이스티오 인증 기관에서 발급한 SVID 인증서 를 사용해 서로 인증 한다.
- 사이트가 프록시가 주입된 서비스 사이의 트래픽은 기본적으로 암호화되고 서로 인증한다.
- 인증서를 발급하고 로테이션하는 절차를 자동화하는 것은 매우 중요한데, 역사적으로 사람이 관리할 때 오류가 발생하기 쉬웠기 때문이다.
- 이로 인해 불필요하고 비용이 많이 드는 서비스 중단이 발생했는데, 이스티오에서 구현한 것처럼 절차를 자동화했다면 피할 수 있었을 문제였다.
- 그림 9.4는 컨트롤 플레인에서 발급한 인증서를 사용해 서비스들이 서로 인증하고 트래픽을 암호화하는 방식을 나타낸다.
- 이 방식을 통해 기본적으로 안전한 상태를 유지한다.
- 사실 ‘기본적으로 안전한’이라고 하면 기본적으로는 대부분 안전하다는 의미로, 메시를 더 안전하게 만들기 위해서는 아직 우리가 수행해야 할 작업들이 남아 있다.
- 먼저, 서비스 메시가 서로 인증한 트래픽만 허용하도록 설정해야 한다.
- 왜 이것이 설치할 때 기본값이 아닌지 궁금할 수 있다. 이는 메시 채택을 용이하게 하려는 설계 결정이다.
- 여러 팀이 자체 서비스를 관리하는 거대 엔터프라이즈에서는 모든 서비스를 메시로 옮기기까지 몇 달 혹은 몇 년에 걸치 조직적인 노력이 필요할 수 있다.
- 두 번째로, 서비스를 인증하면 최소 권한 원칙을 준수할 수 있고, 각 서비스에 정책을 만들 수 있으며, 기능에 필요한 최소한의 접근만 허용할 수 있다.
- 이는 아주 중요한데, 서비스의 ID를 나타내는 인증서가 잘못된 사람에게 넘어갔을 때 피해 범위를 ID가 접근할 수 있도록 허용된 일부 서비스만으로 좁힐 수 있기 때문이다.
▶ 9.2.1 환경 설정하기 (실습~)
더보기
- mTLS 기능 실습을 위해 3가지 서비스를 준비.
- sleep 서비스를 추가 : 레거시 워크로드로, 사이드카 프록시가 없어서 상호 인증을 할 수 없음
Step1. 실습 환경 설정
# catalog와 webapp 배포
kubectl apply -f services/catalog/kubernetes/catalog.yaml -n istioinaction
kubectl apply -f services/webapp/kubernetes/webapp.yaml -n istioinaction
# webapp과 catalog의 gateway, virtualservice 설정
kubectl apply -f services/webapp/istio/webapp-catalog-gw-vs.yaml -n istioinaction
# default 네임스페이스에 sleep 앱 배포
cat ch9/sleep.yaml
...
spec:
serviceAccountName: sleep
containers:
- name: sleep
image: governmentpaas/curl-ssl
command: ["/bin/sleep", "3650d"]
imagePullPolicy: IfNotPresent
volumeMounts:
- mountPath: /etc/sleep/tls
name: secret-volume
volumes:
- name: secret-volume
secret:
secretName: sleep-secret
optional: true
kubectl apply -f ch9/sleep.yaml -n default
# 확인
kubectl get deploy,pod,sa,svc,ep
kubectl get deploy,svc -n istioinaction
kubectl get gw,vs -n istioinaction
Step2. 기본 통신 확인 : 레거시 sleep 워크로드 → webapp 워크로드로 평문 요청 실행
# 요청 실행
kubectl exec deploy/sleep -c sleep -- curl -s webapp.istioinaction/api/catalog -o /dev/null -w "%{http_code}\n"
# 반복 요청
watch 'kubectl exec deploy/sleep -c sleep -- curl -s webapp.istioinaction/api/catalog -o /dev/null -w "%{http_code}\n"'
Step3. Kiali 로 확인
: 네임스페이스(default, istioinaction 선택), Show Legend 클릭 후 아이콘 확인, unkonw → webapp 구간은 평문 통신
- 응답이 성공했다는 것은 서비스들이 올바르게 준비됐으며 webapp 서비스가 sleep 서비스의 평문 요청을 받아들였다는 사실을 보여준다.
- 기본적으로 이스티오는 평문 요청을 허용하는데, 이는 모든 워크로드를 메시로 옮길 때까지 서비스 중단을 일으키지 않고 서비스 메시를 점진적으로 채택할 수 있게 하기 위해서다.
- 그러나 PeerAuthentication 리소스로 평문 트래픽을 금지할 수 있다.
[ 실행 결과 - 한 눈에 보기 ]
1) default namespace 자원
2) istioinaction namespce 자원
3) 서비스 요청 및 kiali 모니터링 확인
9.2.2 이스티오의 PeerAuthentication 리소스 이해하기*
[ 들어가며 ]
더보기
- PeerAuthentication 리소스를 사용하면 워크로드가 mTLS를 엄격하게 요구하거나 평문 트래픽을 허용하고 받아들이게 설정할 수 있다.
- 이들 각각은 STRICT 혹은 PERMISSIVE 인증 모드를 사용한다.
- 상호 mutual 인증 모드는 다양한 범위에서 구성할 수 있다.
- Mesh-wide PeerAuthentication 정책은 서비스 메시의 모든 워크로드에 적용된다.
- Namespace-wide PeerAuthentication 정책은 네임스페이스 내 모든 워크로드에 적용된다.
- Workload-specific PeerAuthentication 정책은 정책에서 명시한 셀렉터에 부합하는 모든 워크로드에 적용된다.
▶ 메시 범위 정책으로 모든 미인증 트래픽 거부하기
( DENYING ALL NON-AUTHENTICATED TRAFFIC USING A MESH-WIDE POLICY )
더보기
요청을 인증 및 인가하도록 서비스 프록시를 구성하는 리소스
- 메시의 보안을 향상시키기 위해 STRICT 상호 인증 모드를 강제하는 메시 범위 MESH-WIDE 정책을 만들어서 평문 트래픽을 금지할 수 있다.
- 메시 범위 PeerAuthentication 정책은 두 가지 조건을 충족해야 한다.
- 반드시 이스티오를 설치한 네임스페이스에 적용해야 하고, 이름은 ‘default’여야 한다.
☞ 메시 범위 리소스의 이름을 ‘default’로 짓는 것은 필수가 아닌 일종의 컨벤션(convention)으로, 메시 범위 PeerAuthentication 리소스를 딱 하나만 만들기 위해서다.
#
cat ch9/meshwide-strict-peer-authn.yaml
apiVersion: "security.istio.io/v1beta1"
kind: "PeerAuthentication"
metadata:
name: "default" # Mesh-wide policies must be named "default"
namespace: "istio-system" # Istio installation namespace
spec:
mtls:
mode: STRICT # mutual TLS mode
# 적용
kubectl apply -f ch9/meshwide-strict-peer-authn.yaml -n istio-system
# 요청 실행
kubectl exec deploy/sleep -c sleep -- curl -s http://webapp.istioinaction/api/catalog -o /dev/null -w "%{http_code}\n"
000
command terminated with exit code 56
# 확인
kubectl get PeerAuthentication -n istio-system
kubectl logs -n istioinaction -l app=webapp -c webapp -f
kubectl logs -n istioinaction -l app=webapp -c istio-proxy -f
[2025-05-01T08:32:08.511Z] "- - -" 0 NR filter_chain_not_found - "-" 0 0 0 - "-" "-" "-" "-" "-" - - 10.10.0.17:8080 10.10.0.16:51930 - -
[2025-05-01T08:32:10.629Z] "- - -" 0 NR filter_chain_not_found - "-" 0 0 0 - "-" "-" "-" "-" "-" - - 10.10.0.17:8080 10.10.0.16:53366 - -
# NR → Non-Route. Envoy에서 라우팅까지 가지 못한 단계에서 발생한 에러라는 의미입니다.
# filter_chain_not_found → 해당 Listener에서 제공된 SNI(Server Name Indication), IP, 포트, ALPN 등의 조건에 맞는 filter_chain이 설정에 없다는 뜻입니다.
[ 코드 설명 ]
- 이는 평문 요청이 거부됐다는 것을 확인한다.
- 상호 인증 요구 사항을 STRICT로 지정하는 것은 좋은 기본값이지만, 진행 중인 프로젝트에서는 그런 급격한 변화가 실현 가능성이 없다.
- 워크로드를 옮기려면 여러 팀 간의 협업이 필요하기 때문이다.
- 더 나은 방법은 적용하는 제한을 점진적으로 늘리고, 팀들이 자신의 서비스를 서비스 메시로 옮길 수 있도록 시간을 주는 것이다.
- PERMISSIVE 상호 인증이 딱 그런 역할로, 워크로드가 암호화된 요청과 평문 요청을 모두 받아드릴 수 있게 허용한다.
[ 실행 결과 - 한 눈에 보기 ]
1) mTls 설정 ( strict )
2) 평문 요청 거부 확인
▶ 상호 인증하기 않은 트래픽 허용하기
( PERMITTING NON-MUTUALLY AUTHENTICATED TRAFFIC )
더보기
- 네임스페이스 범위 정책을 사용하면 메시 범위 정책을 덮어 쓸 수 있고, 네임스페이스의 워크로드에 더 잘 맞는 PeerAuthentication 요구 사항을 적용할 수 있다.
- 다음 PeerAuthentication 리소스는 istioinaction 네임스페이스의 워크로드가 sleep 서비스와 같이 메시의 일부가 아닌 레거시 워크로드로부터 평문 트래픽을 받아들이도록 허용한다.
cat << EOF | kubectl apply -f -
apiVersion: "security.istio.io/v1beta1"
kind: "PeerAuthentication"
metadata:
name: "default" # Uses the "default" naming convention so that only one namespace-wide resource exists
namespace: "istioinaction" # Specifies the namespace to apply the policy
spec:
mtls:
mode: PERMISSIVE # PERMISSIVE allows HTTP traffic.
EOF
# 요청 실행
kubectl exec deploy/sleep -c sleep -- curl -s http://webapp.istioinaction/api/catalog -o /dev/null -w "%{http_code}\n"
# 확인
kubectl get PeerAuthentication -A
NAMESPACE NAME MODE AGE
istio-system default STRICT 2m51s
istioinaction default PERMISSIVE 7s
kubectl logs -n istioinaction -l app=webapp -c webapp -f
kubectl logs -n istioinaction -l app=webapp -c istio-proxy -f
# 다음 실습을 위해 삭제 : PeerAuthentication 단축어 pa
kubectl delete pa default -n istioinaction
- 좀 더 보안을 신경써보자.
- 미인증 트래픽은 sleep 워크로드에서 webapp으로 향하는 것만 허용하고, catalog 워크로드에는 STRICT 상호 인증을 계속 유지하자.
- 이렇게 하면 보안이 뚫렸을 때 공격 표면을 더 좁힐 수 있다.
▶ 워크로드별 PeerAuthentication 정책 적용하기
( APPLYING WORKLOAD-SPECIFIC PEERAUTHENTICATION POLICIES )
더보기
webapp은 HTTP 트래픽을 받아들인다. catalog 서비스에는 상호 인증이 필요하다.
- webapp 만 목표로 하기 위해 워크로드 셀렉터를 지정해 상술했던 PeerAuthentication 정책을 업데이트 하자.
- 이로써 셀렉터에 부합하는 워크로드에만 적용될 것이다.
- 또한 이름을 ‘default’에서 webapp으로 바꾸자.
- 동작이 바꾸지는 않지만, 네임스페이스 전체에 적용되는 PeerAuthentication 정책만 ‘default’로 짓는 컨벤션을 따르려는 것이다.
# istiod 는 PeerAuthentication 리소스 생성을 수신하고, 이 리소스를 엔보이용 설정으로 변환하며,
# LDS(Listener Discovery Service)를 사용해 서비스 프록시에 적용
docker exec -it myk8s-control-plane istioctl proxy-status
kubectl logs -n istio-system -l app=istiod -f
...
2025-05-01T09:48:32.854911Z info ads LDS: PUSH for node:catalog-6cf4b97d-2r9bn.istioinaction resources:23 size:85.4kB
2025-05-01T09:48:32.855510Z info ads LDS: PUSH for node:webapp-7685bcb84-jcg7d.istioinaction resources:23 size:94.0kB
...
#
cat ch9/workload-permissive-peer-authn.yaml
apiVersion: "security.istio.io/v1beta1"
kind: "PeerAuthentication"
metadata:
name: "webapp"
namespace: "istioinaction"
spec:
selector:
matchLabels:
app: "webapp" # 레이블이 일치하는 워크로드만 PERMISSIVE로 동작
mtls:
mode: PERMISSIVE
kubectl apply -f ch9/workload-permissive-peer-authn.yaml
kubectl get pa -A
# 요청 실행
kubectl logs -n istioinaction -l app=webapp -c webapp -f
kubectl logs -n istioinaction -l app=webapp -c istio-proxy -f
kubectl exec deploy/sleep -c sleep -- curl -s http://webapp.istioinaction/api/catalog -o /dev/null -w "%{http_code}\n"
#
kubectl logs -n istioinaction -l app=catalog -c catalog -f
kubectl logs -n istioinaction -l app=catalog -c istio-proxy -f
kubectl exec deploy/sleep -c sleep -- curl -s http://catalog.istioinaction/api/items -o /dev/null -w "%{http_code}\n"
2025-05-01T09:32:00.197Z] "- - -" 0 NR filter_chain_not_found - "-" 0 0 0 - "-" "-" "-" "-" "-" - - 10.10.0.18:3000 10.10.0.16:33192 - -
...
- 성공 응답을 반환한다! 메시 범위 정책으로 엄격한 기본값을 적용했다.
- 그러나 일부 서비스(뒤처진 것들)에는 그 서비스들이 메시로 옮겨질 때까지 상호 인증이 아닌 트래픽도 허용되도록 워크로드별 정책을 사용한다.
☞ istiod 는 PeerAuthentication 리소스 생성을 수신하고, 이 리소스를 엔보이용 설정으로 변환하며, LDS(Listener Discovery Service)를 사용해 서비스 프록시에 적용한다. 구성된 정책들은 들어오는 요청마다 평가된다. The configured policies are evaluated for every incoming request.
[ 실행 결과 한 눈에 보기 ]
1) control-plane 의 istio proxy status 확인
2) 특정 조건 서비스에 "permissive" 지정 후, 서비스 호출 테스트
▶ 두 가지 추가적인 상호 인증 모드
( TWO ADDITIONAL MUTUAL AUTHENTICATION MODES )
더보기
- 대부분의 경우 STRICT 나 PERMISSIVE 모드를 사용할 것이다. 그러나 두 가지 모드가 더 있다.
- UNSET : 부모의 PeerAuthentication 정책을 상속한다. Inherit the PeerAuthentication policy of the parent.
- DISABLE : 트래픽을 터널링하지 않는다. 그냥 보낸다. Do not tunnel the traffic; send it directly to the service.
- PeerAuthentication 리소스를 이렇게 사용할 수 있다.
- 상호 인증 트래픽, 평문 트래픽 등 워크로드로 터널링할 트래픽 유형을 지정하거나, 요청을 프록시로 보내지 않고 애플리케이션으로 바로 포워딩할 수 있다.
- 다음 절에서는 상호 TLS를 사용할 때 트래픽이 암호화되는지 확인해보자.
▶ tcpdump로 서비스 간 트래픽 스니핑하기
( EAVESDROPPING ON SERVICE-TO-SERVICE TRAFFIC USING TCPDUMP )
더보기
- 이스티오 프록시에는 tcpdump가 설치돼 있다. 이 도구는 네트워크 인터페이스르 통과하는 네트워크 트래픽을 포착하고 분석한다.
- tcpdump 는 보안 때문에 권한 privileged permission 이 필요한데, 기본적으로 이 권한은 꺼져 있다.
- 이 권한을 켜려면 istioctl로 속성 values.global.proxy.privileged=true 로 설정해 이스티오 설치를 업데이트하자.
☞ 격상시킨 서비스 프록시의 권한은 악의적 공격의 매개체가 될 수 있다. 운영 환경 클러스터에서 이스티오를 설치할 때는 프록시의 권한을 격상시키지 말자. 서비스 하나를 빠르게 디버깅하고 싶을때는 kubectl edit로 디플로이먼트의 필드를 수작업으로 바꿀 수 있다.
Step1. Profile 및 권한 (Privileged) 설정
# demo 프로파일 컨트롤 플레인 배포 시 istio-proxy 에 privileged 설정 >> 이미 설정 되어 있음
istioctl install --set profile=demo --set values.global.proxy.privileged=true -y
Step2. 기본 설정확인
# 확인
kubectl get istiooperator -n istio-system installed-state -o yaml
...
proxy:
...
privileged: true
...
kubectl get pod -n istioinaction -l app=webapp -o json
"image": "docker.io/istio/proxyv2:1.17.8",
"imagePullPolicy": "IfNotPresent",
"name": "istio-proxy",
...
"securityContext": {
"allowPrivilegeEscalation": true,
"capabilities": {
"drop": [
"ALL"
]
},
"privileged": true,
"readOnlyRootFilesystem": true,
"runAsGroup": 1337,
"runAsNonRoot": true,
"runAsUser": 1337
},
...
#
kubectl exec -it -n istioinaction deploy/webapp -c istio-proxy -- whoami
kubectl exec -it -n istioinaction deploy/webapp -c istio-proxy -- id
kubectl exec -it -n istioinaction deploy/webapp -c istio-proxy -- sudo whoami
kubectl exec -it -n istioinaction deploy/webapp -c istio-proxy -- sudo tcpdump -h
Step3. 파드 트래픽을 스니핑 sniffing 해보자
# 패킷 모니터링 실행 해두기
kubectl exec -it -n istioinaction deploy/webapp -c istio-proxy \
-- sudo tcpdump -l --immediate-mode -vv -s 0 '(((ip[2:2] - ((ip[0]&0xf)<<2)) - ((tcp[12]&0xf0)>>2)) != 0) and not (port 53)'
# -l : 표준 출력(stdout)을 라인 버퍼 모드로 설정. 터미널에서 실시간으로 결과를 보기 좋게 함 (pipe로 넘길 때도 유용).
# --immediate-mode : 커널 버퍼에서 패킷을 모아서 내보내지 않고, 캡처 즉시 사용자 공간으로 넘김 → 딜레이 최소화.
# -vv : verbose 출력. 패킷에 대한 최대한의 상세 정보를 보여줌.
# -s 0 : snap length를 0으로 설정 → 패킷 전체 내용을 캡처. (기본값은 262144 bytes, 예전 버전에서는 68 bytes로 잘렸음)
# '(((ip[2:2] - ((ip[0]&0xf)<<2)) - ((tcp[12]&0xf0)>>2)) != 0) and not (port 53)' : DNS패킷 제외하고 TCP payload 길이가 0이 아닌 패킷만 캡처
# 즉, SYN/ACK/FIN 같은 handshake 패킷(데이터 없는 패킷) 무시, 실제 데이터 있는 패킷만 캡처
# 결론 : 지연 없이, 전체 패킷 내용을, 매우 자세히 출력하고, DNS패킷 제외하고 TCP 데이터(payload)가 1 byte 이상 있는 패킷만 캡처
# 요청 실행
kubectl exec deploy/sleep -c sleep -- curl -s webapp.istioinaction/api/catalog -o /dev/null -w "%{http_code}\n"
...
## (1) sleep -> webapp 호출 HTTP
14:07:24.926390 IP (tos 0x0, ttl 63, id 63531, offset 0, flags [DF], proto TCP (6), length 146)
10-10-0-16.sleep.default.svc.cluster.local.32828 > webapp-7685bcb84-hp2kl.http-alt: Flags [P.], cksum 0x14bc (incorrect -> 0xa83b), seq 2741788650:2741788744, ack 3116297176, win 512, options [nop,nop,TS val 490217013 ecr 2804101520], length 94: HTTP, length: 94
GET /api/catalog HTTP/1.1
Host: webapp.istioinaction
User-Agent: curl/8.5.0
Accept: */*
## (2) webapp -> catalog 호출 HTTPS
14:07:24.931647 IP (tos 0x0, ttl 64, id 18925, offset 0, flags [DF], proto TCP (6), length 1304)
webapp-7685bcb84-hp2kl.37882 > 10-10-0-19.catalog.istioinaction.svc.cluster.local.3000: Flags [P.], cksum 0x1945 (incorrect -> 0x9667), seq 2146266072:2146267324, ack 260381029, win 871, options [nop,nop,TS val 1103915113 ecr 4058175976], length 1252
## (3) catalog -> webapp 응답 HTTPS
14:07:24.944769 IP (tos 0x0, ttl 63, id 7029, offset 0, flags [DF], proto TCP (6), length 1789)
10-10-0-19.catalog.istioinaction.svc.cluster.local.3000 > webapp-7685bcb84-hp2kl.37882: Flags [P.], cksum 0x1b2a (incorrect -> 0x2b6f), seq 1:1738, ack 1252, win 729, options [nop,nop,TS val 4058610491 ecr 1103915113], length 1737
## (4) webapp -> sleep 응답 HTTP
14:07:24.946168 IP (tos 0x0, ttl 64, id 13699, offset 0, flags [DF], proto TCP (6), length 663)
webapp-7685bcb84-hp2kl.http-alt > 10-10-0-16.sleep.default.svc.cluster.local.32828: Flags [P.], cksum 0x16c1 (incorrect -> 0x37d1), seq 1:612, ack 94, win 512, options [nop,nop,TS val 2804101540 ecr 490217013], length 611: HTTP, length: 611
HTTP/1.1 200 OK
content-length: 357
content-type: application/json; charset=utf-8
date: Thu, 01 May 2025 14:07:24 GMT
x-envoy-upstream-service-time: 18
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]
...
#
kubectl get svc,ep -n istioinaction
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/catalog ClusterIP 10.200.1.46 <none> 80/TCP 7h4m
service/webapp ClusterIP 10.200.1.201 <none> 80/TCP 7h4m
NAME ENDPOINTS AGE
endpoints/catalog 10.10.0.19:3000 7h4m
endpoints/webapp 10.10.0.20:8080 7h4m
#
kubectl exec -it -n istioinaction deploy/webapp -c istio-proxy \
-- sudo tcpdump -l --immediate-mode -vv -s 0 'tcp port 3000 or tcp port 8080'
# 요청 실행
kubectl exec deploy/sleep -c sleep -- curl -s webapp.istioinaction/api/catalog -o /dev/null -w "%{http_code}\n"
...[ 실행 결과 한 눈에 보기 ]
1) 권한 확인
2) 패킷 모니터링
3) 구간 별 패킷 통신 확인
▶ 워크로드 ID가 워크로드 서비스 어카운트에 연결돼 있는지 확인하기
( VERIFYING THAT WORKLOAD IDENTITIES ARE TIED TO THE WORKLOAD SERVICE ACCOUNT )
더보기
- 상호 인증을 다룬 절을 끝내기 전에 발급된 인증서가 유효한 SVID 문서인지, SPIFFE ID가 인코딩돼 있는지, 그 ID가 워크로드 서비스 어카운트와 일치하는지 확인해보자.
- openssl 명령어를 사용해 catalog 워크로드의 X.509 인증서 내용물을 확인한다.
# (참고) 패킷 모니터링 : 아래 openssl 실행 시 동작 확인
kubectl exec -it -n istioinaction deploy/catalog -c istio-proxy \
-- sudo tcpdump -l --immediate-mode -vv -s 0 'tcp port 3000'
# catalog 의 X.509 인증서 내용 확인
kubectl -n istioinaction exec deploy/webapp -c istio-proxy -- ls -l /var/run/secrets/istio/root-cert.pem
kubectl exec -it -n istioinaction deploy/webapp -c istio-proxy -- openssl x509 -in /var/run/secrets/istio/root-cert.pem -text -noout
...
kubectl -n istioinaction exec deploy/webapp -c istio-proxy -- openssl -h
kubectl -n istioinaction exec deploy/webapp -c istio-proxy -- openssl s_client -h
# openssl s_client → TLS 서버에 연결해 handshake와 인증서 체인을 보여줌
# -showcerts → 서버가 보낸 전체 인증서 체인 출력
# -connect catalog.istioinaction.svc.cluster.local:80 → Istio 서비스 catalog로 TCP 80 연결
# -CAfile /var/run/secrets/istio/root-cert.pem → Istio의 root CA로 서버 인증서 검증
# 결론 : Envoy proxy에서 catalog 서비스로 연결하여 TLS handshake 및 인증서 체인 출력 후 사람이 읽을 수 있는 형식으로 해석
kubectl -n istioinaction exec deploy/webapp -c istio-proxy \
-- openssl s_client -showcerts \
-connect catalog.istioinaction.svc.cluster.local:80 \
-CAfile /var/run/secrets/istio/root-cert.pem | \
openssl x509 -in /dev/stdin -text -noout
...
Validity
Not Before: May 1 09:55:10 2025 GMT # 유효기간 1일 2분
Not After : May 2 09:57:10 2025 GMT
...
X509v3 extensions:
X509v3 Extended Key Usage:
TLS Web Server Authentication, TLS Web Client Authentication # 사용처 : 웹서버, 웹클라이언트
...
X509v3 Subject Alternative Name: critical
URI:spiffe://cluster.local/ns/istioinaction/sa/catalog # SPIFFE ID 확인
# catalog 파드의 서비스 어카운트 확인
kubectl describe pod -n istioinaction -l app=catalog | grep 'Service Account'
Service Account: catalog- 루트 인증서 서명 확인
- openssl verify 로 인증 기관 CA 루트 인증서에 대해 서명을 확인함으로써 X.509 SVID의 내용물이 유효한지 살펴보자.
- 루트 인증서는 istio-proxy 컨테이너에서 /var/run/secrets/istio/root-cert.pem 경로에 마운트돼 있다.
# webapp.istio-proxy 쉘 접속
kubectl -n istioinaction exec -it deploy/webapp -c istio-proxy -- /bin/bash
-----------------------------------------------
# 인증서 검증
openssl verify -CAfile /var/run/secrets/istio/root-cert.pem \
<(openssl s_client -connect \
catalog.istioinaction.svc.cluster.local:80 -showcerts 2>/dev/null)
/dev/fd/63: OK
# 검증에 성공 시 OK 메시지 출력: 이스티오 CA가 인증서에 서명했으며, 내부 데이터가 믿을 수 있다는 것임을 알려줌.
exit
-----------------------------------------------
- 이제 참가자 간 peer-to-peer 인증을 용의하게 하는 모든 구성 요소를 검증했으므로, 발급된 ID는 검증할 수 있는 것이고 트래픽은 안전하다는 것을 확신할 수 있다.
- 검증할 수 있는 ID가 접근 제어의 선행 조건이다. 다시 말해, 워크로드의 ID를 알고 있으므로 수행할 수 있는 작업을 정의할 수 있다.
- 다음 절에서는 인가 정책을 살펴본다.
☞ Ubuntu 24.04 에 jwt 설치
( https://lindevs.com/install-jwt-cli-on-ubuntu )
더보기
step1. download file
wget -qO jwt.tar.gz https://github.com/mike-engel/jwt-cli/releases/latest/download/jwt-linux.tar.gz
step2. Extract executable from archive to /usr/local/bin directory
sudo tar xf jwt.tar.gz -C /usr/local/bin jwt
step3. check the jwt-cli version
jwt --version
step4. Remove unneeded file
rm -rf jwt.tar.gz
step5. Uninstall jwt-cli ( Optional )
sudo rm -rf /usr/local/bin/jwt
step6. Test ( Optional )
# 1.create JWT File
jwt encode --secret=pwd123 '{"name":"John"}' > jwt.txt
# 2.read JWT file
jwt decode - < jwt.txt
부록 C 이스티오 보안: SPIFFE
C.1 PKI를 사용한 인증 - Authentication using PKI (public key infrastructure)
더보기
[ 들어가며 ]
- World Wide Web에서 통신 당사자는 PKI Public Key Infrastructure (공개 키 인프라) 규격을 따라 발급한 디지털 서명 인증서를 사용해 인증한다.
- PKI는 절차를 정의하는 프레임워크인데, 이 절차는 서버(웹 앱 등)에는 자신의 정체를 증명할 수 있는 디지털 인증서를 제공하고 클라이언트에는 디지털 인증서의 유효성을 검증할 수 있는 수단을 제공한다. https://www.securew2.com/blog/public-key-infrastructure-explained
- PKI에서 제공하는 인증서에는 공개 키와 개인 키가 있다. 클라이언트에게 인증서를 인증 수단으로 제시하는데, 공개 키는 이 인증서 안에 포함된다.
- 클라이언트는 공개된 네트워크에서 서버로 데이터를 전송하기 전에 공개 키를 사용해 데이터를 암호화하며, 개인 키를 가진 서버만이 데이터를 복호화할 수 있다.
- 이런 방식으로 데이터는 전송 중에 안전하게 보호된다.
☞ 공개 키 인증서의 표준 형식을 X.509 인증서라고 한다. 이 책에서는 X.509 인증서라는 용어와 디지털 인증서라는 용어를 같은 뜻으로 사용한다.
- 국제 인터넷 표준화 기구 IETF는 전송 계층 보안 TLS Transport Layer Security 프로토콜(PKI를 사용하기는 하지만 PKI만 사용해야 하는 것은 아님)을 정의하고, X.509 인증서를 공급해 트래픽 인증 및 암호화를 용의하게 했다
C.1.1 TLS 및 최종 사용자 인증을 통한 트래픽 암호화
- Traffic encryption via TLS and end-user authentication
더보기
TLS 핸드세이크 단계
- TLS 프로토콜은 TLS 핸드셰이크 절차에서 서버의 유효성을 인증하고 트래픽 대칭 키 암호화용 키를 안전하게 교환하는 데 X.509 인증서를 기본 메커니즘으로 사용한다. (그림 C.1 참조)
- 클라이언트가 자신이 지원하는 TLS 버전과 암호화 수단을 포함한 ClientHello 로 핸드셰이크를 시작한다.
- 서버는 ServerHello 와 자신의 X.509 인증서로 응답한다. 인증서에는 서버의 ID 정보와 공개 키가 포함돼 있다.
- 클라이언트는 서버의 인증서 데이터가 변조되지 않았음을 확인하고 신뢰 체인을 검증한다.
- 검증에 성공하면, 클라이언트는 서버에 비밀 키를 보낸다. 이 키는 임의로 생성한 문자열을 서버의 공개 키로 암호화한 것이다.
- 서버는 자신의 개인 키로 비밀 키를 복호화하고, 복호화된 비밀 키로 ‘finished’ 메시지를 암호화해 클라이언트로 보낸다.
- 클라이언트도 비밀 키로 암호화한 ‘finished’ 메시지를 서버에 보내면 TLS 핸드셰이크가 완료된다.
- TLS 핸드셰이크의 결실은 클라이언트가 서버를 인증했고 대칭 키를 안전하게 교환했다는 것이다.
- 이 대칭 키는 이 커넥션에서 클라이언트와 서버를 오가는 트래픽을 암호화하는데 사용한다.
- 이런 방식이 비대칭 암호화보다 성능이 더 좋기 때문이다.
- 최종 사용자에게 이런 절차는 브라우저가 투명하게 수행하는 것으로, 주소 표시줄에 녹색 자물쇠로 표시돼 수신자가 인증됐고 트래픽이 암호화돼 수신자만 복호화할 수 있다는 것을 확인해준다.
- 서버에서 최종 사용자를 인증하는 것은 구현하기 나름이다.
- 여러 가지 방법이 있지만, 그 모든 방법의 핵심은 비밀번호를 알고 있는 사용자가 세션 쿠키나 JWT(JSON Web Token)를 받는 것이다.
- 이때 JWT는 수명이 짧고 사용자의 후속 요청을 서버에 인증하기 위한 정보를 포함하는 것이 이상적이다.
- 이스티오는 JWT를 사용하는 최종 사용자 인증을 지원한다.
- 실제로 동작하는 모습은 9.4절에서 살펴봤다.
C.2 SPIFFE: 모든 이를 위한 안전한 운영 환경 ID 프레임워크 ( 실습 )
- Secure Production Identity Framework for Everyone
더보기
[ 들어가며 ]
- SPIFFE는 고도로 동적이며 이질적인 환경에서 워크로드에 ID를 제공하기 위한 오픈소스 표준 집합이다.
- ID를 발급하고 부트스트랩하기 위해 SPIFFE는 다음 사양을 정의한다.
- SPIFFE ID : 신뢰 도메인 내에서 서비스를 고유하게 구별한다.
- Workload Endpoint : 워크로드의 ID를 부트스트랩한다.
- Workload API : SPIFFE ID가 포함된 인증서를 서명하고 발급한다.
- SVID SPIFFE Verifiable Identity Document : 워크로드 API가 발급한 인증서로 표현된다.
- SPIFFE 사양은 SPIFFE ID 형식으로 워크로드에 ID를 발급하고 이를 SVID에 인코딩하는 절차를 정의할 뿐 아니라, 컨트롤 플레인 구성 요소(워크로드 API)와 데이터 플레인 구성 요소(워크로드 엔드포인트)가 워크로드의 ID를 검증하고 할당하고 형식의 유효성을 검사하기 위해 협동하는 방법도 정의한다.
- 이스티오가 이런 사양을 구현하므로 이에 대한 더 깊은 이해가 필요하다.
C.2.1 SPIFFE ID: Workload identity 워크로드 ID
더보기
- SPIFFE ID는 RFC 3986 호환 URI로, spiffe://trust-domain/path 형식을 따른다.
- trust-domain 은 개인이나 조직 같은 ID 발급자를 나타낸다.
- path는 trust-domain 내에서 워크로드를 고유하게 식별한다.
- 경로 path로 워크로드를 식별하는 방법의 세부 사항에는 제약이 없으며 SPIFFE 사양 구현자가 결정할 수 있다.
- 이 부록에서는 이스티오가 쿠버네티스 서비스 어카운트를 사용해 워크로드를 식별하는 경로를 정의하는 방법을 살펴본다.
C.2.2 Workload API 워크로드 API
더보기
- 워크로드 API는 SPIFFE 사양에서 컨트롤 플레인 구성 요소를 나타내며, 워크로드가 자신의 ID를 정의하는 SVID 형식 디지털 인증서를 가져갈 수 있도록 엔드포인트를 노출한다.
- 워크로드 API는 두 가지 주요 기능은 다음과 같다.
- 워크로드가 제출한 인증서 서명 요청 CSR에 인증 기관 CA 개인 키로 서명함으로써 워크로드에 인증서 발급
- 워크로드 엔드포인트에서 해당 기능을 사용할 수 있도록 API 노출
- 사양 specification sets 은 워크로드가 자신의 ID를 정의하는 비밀이나 기타 정보를 보유해서는 안 된다는 제한(규칙)을 둔다.
- 그렇지 않으면, 해당 비밀에 접근할 수 있는 악의적인 사용자가 시스템을 쉽게 악용할 수 있기 때문이다.
- 이 제한 때문에 워크로드에는 인증 수단이 없어 워크로드 API로 보안 통신을 시작할 수 없다.
- 이 상황을 해결하기 위해 SPIFFE는 워크로드 엔드포인트 사양을 정의한다.
- 이 사양은 데이터 플레인 구성 요소를 나타내고, 워크로드의 ID를 부트스트랩하는 데 필요한 모든 작업을 수행한다.
- 예를 들어, 워크로드 API와 보안 통신을 시작하거나 도청 또는 중간자 공격에 취약하지 않게 SVID를 가져오는 등의 활동을 수행한다.
C.2.3 Workload endpoints 워크로드 엔드포인트
더보기
워크로드에 ID 발급하기
- 워크로드 엔드포인트는 SPIFFE 사양의 데이터 플레인 구성 요소를 나타낸다. 이는 모든 워크로드와 함께 배포돼 다음 기능을 제공한다.
- 워크로드 증명 attestation
- 커널 검사 kernel introspection 또는 orchestrator interrogation (쿼리, 질문) 같은 방법을 사용해 워크로드의 ID를 확인한다.
- 워크로드 API 노출 exposure
- 워크로드 API와 보안 통신을 시작하고 유지한다. 이 보안 통신은 SVID를 가져오고 로테이션하는 데 사용한다.
- 워크로드 증명 attestation
☞ 그림 C.2는 워크로드에 ID를 발급하는 단계의 개요를 보여준다.
- 워크로드 엔드포인트는 워크로드의 무결성을 확인하고(즉, 워크로드 증명을 수행하고) SPIFFIE ID가 인코딩된 CSR을 생성한다.
- 워크로드 엔드포인트는 서명을 위해 워크로드 API에 CSR을 제출한다.
- 워크로드 API는 CSR을 서명하고 디지털 서명된 인증서로 응답한다.
- 이 인증서의 SAN의 URI 확장에는 SPIFFE ID가 있다.
- 이 인증서는 워크로드 ID를 나타내는 SVID이다.
C.2.4 SPIFFE Verifiable Identity Documents 검증할 수 있는 ID 문서
더보기
자신의 SVID를 가져오고 보안 통신을 시작하는 워크로드
- SVID (SPIFFE 검증할 수 있는 ID 문서) 는 워크로드의 정체를 나타내는 검증할 수 있는 문서다.
- 검증할 수 있다는 것이 가장 중요한 속성인데, 그렇지 않으면 수신자가 워크로드의 정체를 신뢰할 수 없기 때문이다.
- 사양은 SVID 표현 기준을 충족하는 문서로 두 가지 유형인 X.509 인증서와 JWT를 정의한다.
- 둘 다 다음과 같은 요소로 구성된다.
- SPIFFE ID, 워크로드 ID를 나타낸다.
- 유효한 서명, SPIFFE ID가 변조되지 않았음을 확인한다.
- (선택 사항) 워크로드 간에 보안 통신 채널을 구축하기 위한 공개 키
- 이스티오는 SVID를 X.509 인증서로 구현한다.
- 그 방법은 SAN Subject Alternative Name 확장에 SPIFFE ID를 URI로 인코딩하는 것이다.
- X.509 인증서를 사용하면 추가적인 이점이 있는데, 워크로드가 서로 간의 트래픽을 상호 인증하고 암호화할 수 있다는 것이다. (그림 C.3 참조)
- 이스티오가 SPIFFE 사양을 구현함으로써, 모든 워크로드가 각자의 ID를 공급받고 그 ID를 증거로 인증서를 받는다는 것이 자동으로 보장된다.
- 이런 인증서는 상호 인증과 모든 서비스 간 통신을 암호화하는 데 사용한다.
- 그러므로 이 기능을 자동 상호 TLS라고 한다. Hence this feature is called auto mTLS.
C.2.5 How Istio implements SPIFFE 이스티오가 SPIFFE를 구현하는 방법
더보기
이스티오 구성 요소를 SPIFFE 사양에 매핑하기
- 이스티오를 사용하면 다음 두 구성 요소가 협업해 워크로드에 ID를 제공한다.
- ID를 부트스트랩하는 워크로드 엔드포인트 (데이터플레인, 이스티오 프록시 pilot agent)
- 인증서를 발급하는 워크로드 API (컨트롤플레인, istiod 의 Istio CA)
- 이스티오에서 워크로드 엔드포인트 사양은 워크로드와 함께 배포되는 이스티오 프록시가 구현한다.
- 이스티오 프록시는 ID를 부트스트랩하고 이스티오 CA에서 인증서를 가져오는데, 이스티오 CA는 istiod의 구성 요소로 워크로드 API 사양을 구현한다.
- 그림 C.4는 이스티오가 SPIFFE 구성 요소를 구현하는 방법을 보여준다.
- 워크로드 엔드포인트는 ID 부트스트랩을 수행하는 이스티오 파일럿 에이전트로 구현한다.
- 워크로드 API는 인증서를 발급하는 이스티오 CA로 구현한다.
- 이스티오에서 ID를 발급하는 워크로드는 서비스 프록시다.
- 이는 이스티오가 SPIFFE를 구현하는 방법을 고수준에서 살펴본 것이다.
- 해당 내용을 이해하고 기억하기 위해 이 과정을 단계별로 살펴보자.
C.2.6 Step-by-step bootstrapping of workload identity* 워크로드 ID의 단계별 부트스트랩
더보기
쿠버네티스에서 이스티오로 SVID 발급하기
- 기본적으로 쿠버네티스에서 초기화된 모든 파드에는 /var/run/secrets/kubernetes.io/serviceaccount/ 경로에 시크릿이 마운트돼 있다.
- 이 시크릿에는 쿠버네티스 API 서버와 안전하게 통신하는 데 필요한 모든 데이터가 포함돼 있다.
- ca.crt 는 쿠버네티스 API 서버가 발급한 인증서의 유효성을 검증한다.
- 네임스페이스는 파드가 위치한 곳을 나타낸다.
- 서비스 어카운트 토큰에는 파드를 나타내는 서비스 어카운트에 대한 (토큰)클레임들이 포함된다.
- The service account token contains a set of claims for the service account representing the Pod.
- ID 부트스트랩 과정에서 가장 중요한 요소는 쿠버네티스 API가 발급한 토큰이다.
- 토큰의 페이로드는 수정할 수 없는데, 수정하면 서명 유효성 검사를 통과하지 못하기 때문이다.
- 페이로드에는 애플리케이션을 식별하는 데이터가 포함된다.
#
kubectl exec -it -n istioinaction deploy/webapp -c istio-proxy -- ls -l /var/run/secrets/kubernetes.io/serviceaccount/
kubectl exec -it -n istioinaction deploy/webapp -c istio-proxy -- cat /var/run/secrets/kubernetes.io/serviceaccount/token
TOKEN=$(kubectl exec -it -n istioinaction deploy/webapp -c istio-proxy -- cat /var/run/secrets/kubernetes.io/serviceaccount/token)
# 헤더 디코딩
echo $TOKEN | cut -d '.' -f1 | base64 --decode | sed 's/$/}/' | jq
{
"alg": "RS256",
"kid": "nKgUYnbjH9BmgEXYbu56GFoBxwDF_jF9Q6obIWvinAM"
}
# 페이로드 디코딩
echo $TOKEN | cut -d '.' -f2 | base64 --decode | sed 's/$/}/' | jq
{
"aud": [
"https://kubernetes.default.svc.cluster.local"
],
"exp": 1777689454,
"iat": 1746153454,
"iss": "https://kubernetes.default.svc.cluster.local",
"kubernetes.io": {
"namespace": "istioinaction",
"pod": {
"name": "webapp-7685bcb84-hp2kl",
"uid": "98444761-1f47-45ad-b739-da1b7b22013a"
},
"serviceaccount": {
"name": "webapp",
"uid": "5a27b23e-9ed6-46f7-bde0-a4e4684949c2"
},
"warnafter": 1746157061
},
"nbf": 1746153454,
"sub": "system:serviceaccount:istioinaction:webapp"
}
# (옵션) brew install jwt-cli # Linux 툴 추천 부탁드립니다.
jwt decode $TOKEN
Token header
------------
{
"alg": "RS256",
"kid": "nKgUYnbjH9BmgEXYbu56GFoBxwDF_jF9Q6obIWvinAM"
}
Token claims
------------
{
"aud": [ # 이 토큰의 대상(Audience) : 토큰이 어떤 API나 서비스에서 사용될 수 있는지 정의 -> k8s api가 aud 가 일치하는지 검사하여 올바른 토큰인지 판단.
"https://kubernetes.default.svc.cluster.local"
],
"exp": 1777689454, # 토큰 만료 시간 Expiration Time (Unix timestamp, 초 단위) , date -r 1777689454 => (1년) Sat May 2 11:37:34 KST 2026
"iat": 1746153454, # 토큰 발급 시간 Issued At (Unix timestamp), date -r 1746153454 => Fri May 2 11:37:34 KST 2025
"iss": "https://kubernetes.default.svc.cluster.local", # Issuer, 토큰을 발급한 주체, k8s api가 발급
"kubernetes.io": {
"namespace": "istioinaction",
"pod": {
"name": "webapp-7685bcb84-hp2kl",
"uid": "98444761-1f47-45ad-b739-da1b7b22013a" # 파드 고유 식별자
},
"serviceaccount": {
"name": "webapp",
"uid": "5a27b23e-9ed6-46f7-bde0-a4e4684949c2" # 서비스 어카운트 고유 식별자
},
"warnafter": 1746157061 # 이 시간 이후에는 새로운 토큰을 요청하라는 Kubernetes의 신호 (토큰 자동 갱신용) date -r 1746157061 (1시간) => Fri May 2 12:37:41 KST 2025
},
"nbf": 1746153454, # Not Before, 이 시간 이전에는 토큰이 유효하지 않음. 보통 iat와 동일하게 설정됩니다.
"sub": "system:serviceaccount:istioinaction:webapp" # 토큰의 주체(Subject)
}
# sa 에 토큰 유효 시간 3600초 = 1시간 + 7초
kubectl get pod -n istioinaction -l app=webapp -o yaml
...
- name: kube-api-access-nt4qb
projected:
defaultMode: 420
sources:
- serviceAccountToken:
expirationSeconds: 3607
path: token
...
- 파일럿 에이전트는 토큰을 디코딩하고 이 페이로드 데이터를 사용해 SPIFFE ID(예 spiffe://cluster.local/ns/istioinaction/sa/default)를 생성한다.
- 이 SPIFFE ID는 CSR안에서 URI 유형의 SAN 확장으로 사용한다.
- 이스티오 CA로 보낸 요청에 토큰과 CSR이 모두 전송되며, CSR에 대한 응답으로 발급된 인증서가 반환된다.
- Both the token and the CSR are sent in the request to the Istio CA to get a certificate issued for the CSR.
- CSR에 서명하기 전에 이스티오 CA는 TokenReview API를 사용해 토큰이 쿠버네티스 API가 발급한 것이 맞는지 확인한다.
- 이는 SPIFFE 사양에서 약간 벗어난 것인데, SPIFFE 사양에서는 워크로드 엔드포인트(이스티오 에이전트)가 워크로드 증명을 수행해야 하기 때문이다.
- 검증을 통과하면 CSR에 서명하고, 결과 인증서가 파일럿 에이전트에 반환된다.
#
kubectl api-resources | grep -i token
tokenreviews authentication.k8s.io/v1 false TokenReview
kubectl explain tokenreviews.authentication.k8s.io
...
DESCRIPTION:
TokenReview attempts to authenticate a token to a known user. Note:
TokenReview requests may be cached by the webhook token authenticator
plugin in the kube-apiserver.
...
# Kubernetes API 서버에 TokenReview API 를 호출하여 토큰이 여전히 유효한지 확인 : C(Create)
## 이때 사용되는 Kubernetes API 가 POST /apis/authentication.k8s.io/v1/tokenreviews
## 즉, istiod가 이 API를 호출하려면 tokenreviews.authentication.k8s.io 리소스에 create 권한이 필요. C(Create)
kubectl rolesum istiod -n istio-system
...
• [CRB] */istiod-clusterrole-istio-system ⟶ [CR] */istiod-clusterrole-istio-system
Resource Name Exclude Verbs G L W C U P D DC
...
signers.certificates.k8s.io [kubernetes.io/legacy-unknown] [-] [approve] ✖ ✖ ✖ ✖ ✖ ✖ ✖ ✖
subjectaccessreviews.authorization.k8s.io [*] [-] [-] ✖ ✖ ✖ ✔ ✖ ✖ ✖ ✖
tokenreviews.authentication.k8s.io [*] [-] [-] ✖ ✖ ✖ ✔ ✖ ✖ ✖ ✖
validatingwebhookconfigurations.admissionregistration.k8s.io [*] [-] [-] ✔ ✔ ✔ ✖ ✔ ✖ ✖ ✖
...
☞ istiod 컨테이너 내부에서 자신의 token 으로 k8s 에 tokenreviews api 호출해보는 실습 명령어 추가해두기. (https 로 호출해야되고, k8s root ca 인증서를 지정 필요)
파일럿 에이전트는 SDS Secrets Discovery Service 를 통해 인증서와 키를 엔보이 프록시로 전달하고, 이로써 ID 부트스트랩 과정이 마무리된다.
# 유닉스 도메인 소켓 listen 정보 확인
kubectl exec -it -n istioinaction deploy/webapp -c istio-proxy -- ss -xpl
Netid State Recv-Q Send-Q Local Address:Port Peer Address:Port Process
u_str LISTEN 0 4096 etc/istio/proxy/XDS 13207 * 0 users:(("pilot-agent",pid=1,fd=11))
u_str LISTEN 0 4096 ./var/run/secrets/workload-spiffe-uds/socket 13206 * 0 users:(("pilot-agent",pid=1,fd=10))
kubectl exec -it -n istioinaction deploy/webapp -c istio-proxy -- ss -xp
Netid State Recv-Q Send-Q Local Address:Port Peer Address:Port Process
u_str ESTAB 0 0 ./var/run/secrets/workload-spiffe-uds/socket 21902 * 23737 users:(("pilot-agent",pid=1,fd=16))
u_str ESTAB 0 0 etc/istio/proxy/XDS 1079087 * 1080955 users:(("pilot-agent",pid=1,fd=8))
...
# 유닉스 도메인 소켓 정보 확인
kubectl exec -it -n istioinaction deploy/webapp -c istio-proxy -- lsof -U
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
pilot-age 1 istio-proxy 8u unix 0x00000000bda7185a 0t0 1079087 etc/istio/proxy/XDS type=STREAM # 소켓 경로 및 스트림 타입
pilot-age 1 istio-proxy 10u unix 0x0000000009112f4b 0t0 13206 ./var/run/secrets/workload-spiffe-uds/socket type=STREAM # SPIFFE UDS (SPIFFE SVID 인증용)
# TYPE 파일 유형 (unix → Unix Domain Socket)
## 8u → 8번 디스크립터, u = 읽기/쓰기
## 10u → 10번 디스크립터, u = 읽기/쓰기
# 유닉스 도메인 소켓 파일 정보 확인
kubectl exec -it -n istioinaction deploy/webapp -c istio-proxy -- ls -l /var/run/secrets/workload-spiffe-uds/socket
srw-rw-rw- 1 istio-proxy istio-proxy 0 May 1 23:23 /var/run/secrets/workload-spiffe-uds/socket
# istio 인증서 확인 :
docker exec -it myk8s-control-plane istioctl proxy-config secret deploy/webapp.istioinaction
RESOURCE NAME TYPE STATUS VALID CERT SERIAL NUMBER NOT AFTER NOT BEFORE
default Cert Chain ACTIVE true 45287494908809645664587660443172732423 2025-05-03T16:13:14Z 2025-05-02T16:11:14Z
ROOTCA CA ACTIVE true 338398148201570714444101720095268162852 2035-04-29T07:46:14Z 2025-05-01T07:46:14Z
docker exec -it myk8s-control-plane istioctl proxy-config secret deploy/webapp.istioinaction -o json
...
echo "." | base64 -d | openssl x509 -in /dev/stdin -text -noout
# istio ca 관련
kubectl exec -it -n istioinaction deploy/webapp -c istio-proxy -- ls -l /var/run/secrets/istio
kubectl exec -it -n istioinaction deploy/webapp -c istio-proxy -- openssl x509 -in /var/run/secrets/istio/root-cert.pem -text -noout
kubectl exec -it -n istioinaction deploy/webapp -c istio-proxy -- ls -l /var/run/secrets/tokens
kubectl exec -it -n istioinaction deploy/webapp -c istio-proxy -- cat /var/run/secrets/tokens/istio-token
TOKEN=$(kubectl exec -it -n istioinaction deploy/webapp -c istio-proxy -- cat /var/run/secrets/tokens/istio-token)
# 헤더 디코딩
echo $TOKEN | cut -d '.' -f1 | base64 --decode | sed 's/$/}/' | jq
# 페이로드 디코딩
echo $TOKEN | cut -d '.' -f2 | base64 --decode | sed 's/$/"}/' | jq
# (옵션) brew install jwt-cli
jwt decode $TOKEN
# (참고) k8s ca 관련
kubectl exec -it -n istioinaction deploy/webapp -c istio-proxy -- ls -l /var/run/secrets
kubectl exec -it -n istioinaction deploy/webapp -c istio-proxy -- ls -l /var/run/secrets/kubernetes.io/serviceaccount
kubectl exec -it -n istioinaction deploy/webapp -c istio-proxy -- openssl x509 -in /var/run/secrets/kubernetes.io/serviceaccount/ca.crt -text -noout
kubectl exec -it -n istioinaction deploy/webapp -c istio-proxy -- cat /var/run/secrets/kubernetes.io/serviceaccount/token
TOKEN=$(kubectl exec -it -n istioinaction deploy/webapp -c istio-proxy -- cat /var/run/secrets/kubernetes.io/serviceaccount/token)
# 헤더 디코딩
echo $TOKEN | cut -d '.' -f1 | base64 --decode | sed 's/$/}/' | jq
# 페이로드 디코딩
echo $TOKEN | cut -d '.' -f2 | base64 --decode | sed 's/$/}/' | jq
# (옵션) brew install jwt-cli
jwt decode $TOKEN
# (참고)
kubectl port-forward deploy/webapp -n istioinaction 15000:15000
open http://localhost:15000
curl http://localhost:15000/certs
- 이제 프록시는 클라이언트에게 자신의 정체를 증명할 수 있으며 상호 인증 커넥션을 시작할 수 있다.
- 그림 C.5는 이 과정을 간략하게 요약한 것이다.
- 이스티오 프록시 컨테이너에 서비스 어카운트 토큰이 할당된다.
- 토큰과 CSR이 istiod로 전송된다.
- istiod는 쿠버네티스 TokenReview API로 토큰의 유효성을 검사한다.
- 성공하면, 인증서에 서명하고 응답으로 제공한다.
- 파일럿 에이전트는 엔보이 SDS를 통해 엔보이가 ID를 포함한 인증서를 사용하도록 설정한다.
- 그리고 이것이 이스티오가 워크로드ID를 프로비저닝하기 위해 SPIFFE 사양을 구현하는 전체 과정이다.
- 이 과정은 이스티오 프록시 사이드카가 주입되는 모든 워크로드에서 자동으로 수행된다.
C.3 요청 ID 이해하기 Understanding request identity
더보기
필터 메타데이터에서 검증된 데이터 수
요청을 인증 및 인가하도록 서비스 프록시를 구성하는 리소스
☞ 들어가며 : 필터 메타데이터 - Principal, Namespace, Request principal, Request authentication claims
- 요청 ID는 요청의 필터 메타데이터에 저장된 값으로 표현된다. Request identity is represented by the values stored in the filter metadata of the request.
- 이 필터 메타데이터에는 JWT나 피어 인증서에서 추출한 사실 또는 클레임이 포함돼 있으므로 신뢰할 수 있다. This filter metadata contains facts or claims that were extracted from either the JWT or the peer certificate and therefore can be trusted.
- 9장에서는 JWT의 정보를 검증하기 위해 필요한 RequestAuthentication 리소스를 살펴봤다.
- 마찬가지로 클라이언트 워크로드 정보(워크로드의 네임스페이스 등)를 인증하려면 워크로드들이 상호 인증 mutually authenticate 해야 한다.
- PeerAuthentication 리소스는 워크로드가 상호 인증만 사용하도록 강제 only mutual authentication 할 수 있다.
- JWT를 검증하거나 워크로드가 상호 인증을 마치면, 여기에 포함된 정보가 필터 메타데이터로 저장된다.
- 필터 메타데이터에 저장되는 정보 중 일부는 다음과 같다.
- Principal 주체 : PeerAuthentication 에서 정의한 워크로드 ID
- Namespace 네임스페이스 : PeerAuthentication 에서 정의한 워크로드 네임스페이스
- Request principal 요청 주체 : RequestAuthentication에서 정의한 최종 사용자 요청 주체 The end-user request principal defined by the RequestAuthentication.
- Request authentication claims 요청 인증 클레임 : 최종 사용자 토큰에서 추출한 최종 사용자 클레임 The end-user claims extracted from the end-user token.
- 수집된 메타데이터를 관찰하고자 서비스 프록시가 이를 표준 출력에 기록하도록 설정할 수 있다.
C.3.1 RequestAuthentication 리소스로 수집한 메타데이터 Metadata collected by the RequestAuthentication resource (실습)
더보기
Step1. rbac 로거 - 로깅 level 설정 ( debug )
기본적으로 엔보이 rbac 로거는 메타데이터를 로그에 출력하지 않는다. 따라서 출력하려면 로깅 수준의 debug로 설정해야 한다.
docker exec -it myk8s-control-plane istioctl proxy-config log deploy/istio-ingressgateway -n istio-system --level rbac:debug
...
Step. 서비스 설정
실습 중 자주 사용하는 실습 환경 초기화 후 워크로드로 트래픽을 라우팅하도록 인그레스 게이트웨이를 설정하기만 하면 된다.
kubectl apply -f services/catalog/kubernetes/catalog.yaml -n istioinaction
kubectl apply -f services/webapp/kubernetes/webapp.yaml -n istioinaction
kubectl apply -f services/webapp/istio/webapp-catalog-gw-vs.yaml -n istioinaction
Step3. Filter Metadata 생성
- 필터 메타데이터를 사용하는 RequestAuthentication 리소스와 AuthorizationPolicy 를 만든다
kubectl apply -f ch9/enduser/jwt-token-request-authn.yaml
kubectl apply -f ch9/enduser/allow-all-with-jwt-to-webapp.yaml # :30000 포트 추가 필요, 아래 실습 설정 참고.
kubectl get requestauthentication,authorizationpolicy -A
Step4. Admin Token 생성
- admin 토큰을 사용하는 요청을 해보자. 인그레스 게이트웨이에 로그를 남길 것이다
# 로깅
kubectl logs -n istio-system -l app=istio-ingressgateway -f
# admin 토큰을 사용하는 요청 : 필터 메타데이터 확인
ADMIN_TOKEN=$(< ch9/enduser/admin.jwt)
curl -H "Authorization: Bearer $ADMIN_TOKEN" \
-sSl -o /dev/null -w "%{http_code}\n" webapp.istioinaction.io:30000/api/catalog
...
dynamicMetadata: filter_metadata {
key: "envoy.filters.http.jwt_authn"
value {
fields {
key: "auth@istioinaction.io"
value {
struct_value {
fields {
key: "exp"
value {
number_value: 4745145071
}
}
fields {
key: "group"
value {
string_value: "admin"
}
}
fields {
key: "iat"
value {
number_value: 1591545071
}
}
fields {
key: "iss"
value {
string_value: "auth@istioinaction.io"
}
}
fields {
key: "sub"
value {
string_value: "218d3fb9-4628-4d20-943c-124281c80e7b"
}
}
}
}
}
}
}
filter_metadata {
key: "istio_authn"
value {
fields {
key: "request.auth.claims"
value {
struct_value {
fields {
key: "group"
value {
list_value {
values {
string_value: "admin"
}
}
}
}
fields {
key: "iss"
value {
list_value {
values {
string_value: "auth@istioinaction.io"
}
}
}
}
fields {
key: "sub"
value {
list_value {
values {
string_value: "218d3fb9-4628-4d20-943c-124281c80e7b"
}
}
}
}
}
}
}
fields {
key: "request.auth.principal"
value {
string_value: "auth@istioinaction.io/218d3fb9-4628-4d20-943c-124281c80e7b"
}
}
fields {
key: "request.auth.raw_claims"
value {
string_value: "{\"iat\":1591545071,\"sub\":\"218d3fb9-4628-4d20-943c-124281c80e7b\",\"group\":\"admin\",\"exp\":4745145071,\"iss\":\"auth@istioinaction.io\"}"
}
}
}
}
...- 출력은 RequestAuthentication 필터가 최종 사용자 토큰의 클레임을 검증했고, 클레임을 필터 메타데이터로 저장했다는 것을 보여준다.
- 이제 정책들은 이 필터 메타데이터를 기반으로 작동할 수 있다.
☞ 다음 실습을 위해 RequestAuthentication, AuthorizationPolicy 삭제
kubectl delete -f ch9/enduser/jwt-token-request-authn.yaml
kubectl delete -f ch9/enduser/allow-all-with-jwt-to-webapp.yaml
[ 실행 결과 한 눈에 보기 ]
C.3.2 한 요청의 대략적인 흐름* Overview of the flow of one request
더보기
필터 메타데이터에서 검증된 데이터 수집
요청을 인증 및 인가하도록 서비스 프록시를 구성하는 리소스
워크로드가 목적지인 요청은 모두 다음 필터를 거친다 (그림 C.6 참조)
- JWT authentication filter 인증 필터
- 인증 정책의 JWT 사양에 따라 JWT의 유효성을 검사하고 인증 클레임과 커스텀 클레임 같은 클레임을 추출해 필터 메타데이터로 저장하는 엔보이 필터 An Envoy filter that does JWT validation based on the JWT specification in authentication policies and extracts claims such as the authentication claims and custom claims, which are stored as filter metadata.
- PeerAuthentication filter 피어인증 필터
- 서비스 인증 요구 사항을 강제하고 인증된 속성(소스 네임스페이스나 주체 같은 피어 ID)을 추출하는 엔보이 필터 An Envoy filter that enforces service authentication requirements and extracts authenticated attributes (peer identity such as source namespace and principal).
- Authorization filter 인가 필터
- 앞선 필터들이 수집한 필터 메타데이터를 확인하고 워크로드에 적용된 정책에 따라 요청에 권한을 부여하는 인가 엔진 The authorization engine that checks the filter metadata collected by the previous filters and authorizes the request based on the policies applied to the workload.
- webapp 서비스에 도달해야 하는 요청의 시나리오를 살펴보자.
- 요청이 JWT 인증 필터를 통과한다. The request passes the JWT authentication filter
- 이 필터는 토큰에서 클레임을 추출해 필터 메타데이터에 저장한다. 이로써 요청에 ID가 주어진다.
- 인그레스 게이트웨이와 webapp 간에 피어 간 인증이 수행된다. Peer-to-peer authentication is performed between the ingress gateway and the webapp.
- 피어 간 인증 필터는 클라이언트의 ID 데이터를 추출해 필터 메타데이터에 저장한다.
- 인가 필터는 다음 순서대로 실행된다. Authorization filters are executed in order
- Custom authorization filters 커스텀 인가 필터들 : 요청을 허용하거나 거부할지 추가로 평가한다. Reject or allow further evaluation of the request.
- Deny authorization filters 거부 인가 필터들 : 요청을 허용하거나 거부할지 추가로 평가한다.
- Allow authorization filters 허용 인가 필터들 : 필터 조건에 맞으면 요청을 허용한다. Allow the request if the filter matches.
- Last (catch-all) authorization filter 마지막 (포괄적) 인가 필터 : 앞서 요청을 처리한 필터가 없는 경우에만 실행된다. Executed only if no prior filter has handled the request.
- 요청이 JWT 인증 필터를 통과한다. The request passes the JWT authentication filter
☞ 이것이 webapp 서비스로 향하는 요청이 인증되고 인가되는 방식이다. And that’s how the request is authenticated and authorized for the request to get to the webapp service.
9.3 서비스 간 트래픽 인가하기
[ 주요 참고링크 ]
☞ https://netpple.github.io/docs/istio-in-action/Istio-ch9-securing-3-authorizing
☞ [ssup2] Istio Authorization Policy - Link
[ 들어가며 : Understanding request identity ]
더보기
인가는 공격 범위를 단지 도난당한 ID가 접근할 수 있는 것으로 축소한다.
- 인가란 인증된 주체가 리소스 접근, 편집, 삭제 같은 작업을 수행하도록 허용됐는지 정의하는 절차다.
- 정책은 인증된 주체(’누가’)와 인가(’무엇’)를 결합해 형성되며, 누가 무슨 일을 할 수 있는지 정의한다.
- 이스티오에는 AuthorizationPolicy 리소스가 있는데, 이 리소스는 서비스 메시에 메시 범위, 네임스페이스 범위, 워크로드별 접근 정책을 정의하는 선언전 API이다.
- 그림 9.9는 특정 ID가 뚫렸을 때 접근 정책이 어떻게 접근 범위나 폭팔 반경을 제한하는지 보여준다.
- 인가 정책을 살펴보기 전에 이스티오에서 인가를 어떻게 구현하는지 먼저 이해하면 좋다.
- 다음 절에서 기초를 빠르게 살펴보자.
9.3.1 이스티오에서 인가 이해하기
: AuthorizationPolicy - selector, rules(from, to, when), action
더보기
부록 C.6 필터 메타데이터에서 검증된 데이터 수집
요청을 인증 및 인가하도록 서비스 프록시를 구성하는 리소스
- 각 서비스와 함께 배포되는 서비스 프록시가 인가 또는 집행 enforcement 엔진이다.
- 서비스 프록시가 요청을 거절하거나 허용할지 여부를 판단하기 위한 정책을 모두 포함하고 있기 때문이다.
- 그러므로 이스티오의 접근 제어는 대단히 효율적이다. 모든 결정이 프록시에서 직접 내려지기 때문이다.
- 프록시는 AuthorizationPolicy 리소스로 설정하는데, 이 리소스가 정책을 정의한다.
- 예시 AuthorizationPolicy 정의는 다음과 같다.
# cat ch9/allow-catalog-requests-in-web-app.yaml
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
- istiod가 새 AuthorizationPolicy 가 클러스터에 적용됐음을 확인하면, 다른 이스티오 리소스들처럼 해당 리소스로 데이터 플레인 프록시를 처리하고 업데이트 한다.
- 설정의 각 부분을 아직 이해하지 못한다고 걱정하지 말자. 다음 절에서 자세히 살펴볼 것이다.
인가 정책의 속성 PROPERTIES OF AN AUTHORIZATION POLICY
- AuthorizationPolicy 리소스 사양에서 정책을 설정하고 정의하는 필드는 세 가지다.
- selector 필드는 정책을 적용할 워크로드 부분집합을 정의한다.
- action 필드는 이 정책이 허용(ALLOW)인지, 거부(DENY)인지, 커스텀(CUSTOM)인지 지정한다.
- action은 규칙 중 하나가 요청과 일치하는 경우에만 적용된다.
- rules 필드는 정책을 활성화할 요청을 식별하는 규칙 목록을 정의한다.
- rules 속성은 좀 더 복잡해서 더 깊이 살펴봐야 한다.
인가 정책 규칙 이해하기 UNDERSTANDING AUTHORIZATION POLICY RULES
- 인가 정책 규칙은 커넥션은 출처 source 를 지정하며, 일치해야 규칙을 활성화하는 작업 operation 조건을 (원한다면) 지정할 수도 있다.
- Authorization policy rules specify the source of the connection and (optionally) the operation that, when matched, activates the rule.
- 인가 정책은 규칙 중 하나의 출처와 작업 조건을 모두 만족시키는 경우에만 집행된다.
- 이 경우에만 정책이 활성화되고, 커넥션은 action 속성에 따라 허용되거나 거부된다.
- 단일 규칙의 필드는 다음과 같다. The fields of a single rule are as follows:
- from 필드는 요청의 출처 source 를 다음 유형 중 하나로 지정한다.
- principals : 출처 ID(mTLS 예제에서 볼 수 있는 SPIFFE ID). 요청이 주체 principal 집합에서 온 것이 아니면 부정 속성인 notprincipals 가 적용된다. 이 기능이 작동하려면 서비스가 상호 인증해야 한다.
- namespaces : 출처 네임스페이스와 비교할 네임스페이스 목록. 출처 네임스페이스는 참가자의 SVID에서 가져온다. 이런 이유로, 작동하려면 mTLS가 활성화돼야 한다.
- ipBlocks : 출처 IP 주소와 비교할 단일 IP 주소나 CIDR 범위 목록.
- to 필드는 요청의 작업을 지정하며, 호스트나 요청의 메서드 등이 있다.
- when 필드는 규칙이 부합한 후 충족해야 하는 조건 목록을 지정한다.
- from 필드는 요청의 출처 source 를 다음 유형 중 하나로 지정한다.
- 공식 문서 https://istio.io/latest/docs/reference/config/security/authorization-policy/
9.3.2 작업 공간 설정하기 : 실습 환경 구성 확인 (실습~)
- 실습 환경 구성 : 9.2에서 이미 배포함
더보기
webapp은 HTTP 트래픽을 받아들인다. catalog 서비스에는 상호 인증이 필요하다.
# 9.2.1 에서 이미 배포함
kubectl -n istioinaction apply -f services/catalog/kubernetes/catalog.yaml
kubectl -n istioinaction apply -f services/webapp/kubernetes/webapp.yaml
kubectl -n istioinaction apply -f services/webapp/istio/webapp-catalog-gw-vs.yaml
kubectl -n default apply -f ch9/sleep.yaml
# gw,vs 확인
kubectl -n istioinaction get gw,vs
# PeerAuthentication 설정 : 앞에서 이미 설정함
cat ch9/meshwide-strict-peer-authn.yaml
apiVersion: "security.istio.io/v1beta1"
kind: "PeerAuthentication"
metadata:
name: "default"
namespace: "istio-system"
spec:
mtls:
mode: STRICT
kubectl -n istio-system apply -f ch9/meshwide-strict-peer-authn.yaml
kubectl get peerauthentication -n istio-system
cat ch9/workload-permissive-peer-authn.yaml
apiVersion: "security.istio.io/v1beta1"
kind: "PeerAuthentication"
metadata:
name: "webapp"
namespace: "istioinaction"
spec:
selector:
matchLabels:
app: webapp
mtls:
mode: PERMISSIVE
kubectl -n istioinaction apply -f ch9/workload-permissive-peer-authn.yaml
kubectl get peerauthentication -n istioinaction
- 실습 환경 요약
- sleep 워크로드는 default 네임스페이스에 배포했고, 평문 HTTP 요청을 만드는 데 사용한다.
- webapp 워크로드는 istioinaction 네임스페이스에 배포했고, default 네임스페이스에 있는 워크로드에서 미인증 요청을 받아들이고 있다.
- catalog 워크로드는 istioinaction 네임스페이스에 배포했고, 같은 네임스페이스의 인증된 워크로드로부터만 요청을 받아들이고 있다.
9.3.3 워크로드에 정책 적용 시 동작 확인
더보기
- 세부 사항으로 들어가기 전에 미리 알아둬야 할 것이 있다. 문제가 발생하기 쉽기 때문이다 (그리고 디버깅에 시간이 많이 낭비된다!).
- Before we go into the details, there is one "gotcha" that you should know up front, as it’s easy to get bitten by (and waste many hours of debugging!)
- 워크로드에 하나 이상의 ALLOW 인가 정책이 적용되면, 모든 트래픽에서 해당 워크로드로의 접근은 기본적으로 거부된다.
- 트래픽을 받아들이려면, ALLOW 정책이 최소 하나는 부합해야 한다.
- 예를 들어 설명해보자.
- 다음 AuthorizationPolicy 리소스는 webapp 으로의 요청 중 HTTP 경로에 /api/catalog* 가 포함된 것을 허용한다.
# cat ch9/allow-catalog-requests-in-web-app.yaml
apiVersion: "security.istio.io/v1beta1"
kind: "AuthorizationPolicy"
metadata:
name: "allow-catalog-requests-in-web-app"
namespace: istioinaction
spec:
selector:
matchLabels:
app: webapp # 워크로드용 셀렉터 Selector for workloads
rules:
- to:
- operation:
paths: ["/api/catalog*"] # 요청을 경로 /api/catalog 와 비교한다 Matches requests with the path /api/catalog
action: ALLOW # 일치하면 허용한다 If a match, ALLOW
[ 적용 후 확인 ]
# 로그
kubectl logs -n istioinaction -l app=webapp -c istio-proxy -f
# 적용 전 확인
kubectl exec deploy/sleep -- curl -sSL webapp.istioinaction/api/catalog
kubectl exec deploy/sleep -- curl -sSL webapp.istioinaction/hello/world # 404 리턴
# AuthorizationPolicy 리소스 적용
kubectl apply -f ch9/allow-catalog-requests-in-web-app.yaml
kubectl get authorizationpolicy -n istioinaction
#
docker exec -it myk8s-control-plane istioctl proxy-config listener deploy/webapp.istioinaction --port 15006
docker exec -it myk8s-control-plane istioctl proxy-config listener deploy/webapp.istioinaction --port 15006 -o json > webapp-listener.json
...
{
"name": "envoy.filters.http.rbac",
"typedConfig": {
"@type": "type.googleapis.com/envoy.extensions.filters.http.rbac.v3.RBAC",
"rules": {
"policies": {
"ns[istioinaction]-policy[allow-catalog-requests-in-web-app]-rule[0]": {
"permissions": [
{
"andRules": {
"rules": [
{
"orRules": {
"rules": [
{
"urlPath": {
"path": {
"prefix": "/api/catalog"
}
}
}
]
}
}
]
}
}
],
"principals": [
{
"andIds": {
"ids": [
{
"any": true
}
]
}
}
]
}
}
},
"shadowRulesStatPrefix": "istio_dry_run_allow_" # 실제로 차단하지 않고, 정책이 적용됐을 때 통계만 수집 , istio_dry_run_allow_로 prefix된 메트릭 생성됨
}
},
...
# 로그 : 403 리턴 체크!
docker exec -it myk8s-control-plane istioctl proxy-config log deploy/webapp -n istioinaction --level rbac:debug
kubectl logs -n istioinaction -l app=webapp -c istio-proxy -f
[2025-05-03T10:08:52.918Z] "GET /hello/world HTTP/1.1" 403 - rbac_access_denied_matched_policy[none] - "-" 0 19 0 - "-" "curl/8.5.0" "b272b991-7a79-9581-bb14-55a6ee705311" "webapp.istioinaction" "-" inbound|8080|| - 10.10.0.3:8080 10.10.0.13:50172 - -
# 적용 후 확인
kubectl exec deploy/sleep -- curl -sSL webapp.istioinaction/api/catalog
kubectl exec deploy/sleep -- curl -sSL webapp.istioinaction/hello/world # 403 리턴
RBAC: access denied
# 다음 실습을 위해 정책 삭제
kubectl delete -f ch9/allow-catalog-requests-in-web-app.yaml
[ 404 에러와 403 에러의 차이점 ]
구분404 에러 (Not Found) 403 에러 (Forbidden)
|
의미
|
리소스를 찾을 수 없음
|
접근 권한 없음
|
|
원인
|
잘못된 URL, 페이지 삭제 등
|
권한 부족, 서버 거부 등
|
|
예시
|
잘못된 주소로 웹페이지 요청
|
로그인 없이 접근 제한 페이지 접속
|
- 첫 번째 호출은 경로가 일치하기 때문에 요청을 허용한다.
- 두 번째 호출은 놀라울 수 있다. 정책이 요청을 허용하거나 거부하지 않았는데 왜 요청이 거부되는가?
- 이것은 바로 ALLOW 정책을 워크로드에 적용했을 때만 적용되는 기본 거부 deny-by-default 동작이다.
- 다시 말해 워크로드에 ALLOW 정책이 있는 경우, 트래픽이 허용되려면 정책 하나는 반드시 부합해야 한다.
- 정책 설정 과정을 단순화해 서비스마다 호출이 허용되는지, ALLOW 정책이 적용되는지를 스스로에게 되묻지 않으려면, 들어오는 트래픽에 다른 정책이 적용되지 않을 때 활성화되는 전체 catch-all 거부 정책을 추가하는 것을 권장한다.
- 그럼 허용허려는 트래픽에 대해서만 생각하고, 그 트래픽용 정책만 만들면 된다.
- 그림 9.10은 전체 거부 정책이 어떻게 ‘명시적으로 지정되지 않으면 요청을 거부한다’로 바꾸는지 보여준다. 그럼 트래픽을 허용하기만 하면 된다.
[ 실습 결과 - 한 눈에 보기 ]
9.3.4 전체 정책으로 기본적으로 모든 요청 거부하기
- Denying all requests by default with a catch-all policy
더보기
- 보안성을 증가시키고 과정을 단순화하기 위해, ALLOW 정책을 명시적으로 지정하지 않은 모든 요청을 거부하는 메시 범위 정책을 정의해보자.
- 즉, 기본 거부 catch-all-deny-all 정책을 정의한다.
# cat ch9/policy-deny-all-mesh.yaml
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
name: deny-all
namespace: istio-system # 이스티오를 설치한 네임스페이스의 정책은 메시의 모든 워크로드에 적용된다
spec: {} # spec 이 비어있는 정책은 모든 요청을 거부한다
[ 적용 후 요청 테스트 ]
# 적용 전 확인
kubectl exec deploy/sleep -- curl -sSL webapp.istioinaction/api/catalog
curl -s http://webapp.istioinaction.io:30000/api/catalog
# 정책 적용
kubectl apply -f ch9/policy-deny-all-mesh.yaml
kubectl get authorizationpolicy -A
# 적용 후 확인 1
kubectl exec deploy/sleep -- curl -sSL webapp.istioinaction/api/catalog
...
kubectl logs -n istioinaction -l app=webapp -c istio-proxy -f
[2025-05-03T14:45:31.051Z] "GET /api/catalog HTTP/1.1" 403 - rbac_access_denied_matched_policy[none] - "-" 0 19 0 - "-" "curl/8.5.0" "f1ec493b-cc39-9573-b3ad-e37095bbfaeb" "webapp.istioinaction" "-" inbound|8080|| - 10.10.0.3:8080 10.10.0.13:60780 - -
# 적용 후 확인 2
curl -s http://webapp.istioinaction.io:30000/api/catalog
...
kubectl logs -n istio-system -l app=istio-ingressgateway -f
...
(참고) Catch-all authorization policies : 빈 규칙 rules 은 모든 요청을 허용 의미
# cat ch9/policy-allow-all-mesh.yaml
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
name: allow-all
namespace: istio-system
spec:
rules:
- {}
[ 실행 결과 - 한 눈에 보기 ]
9.3.5 특정 네임스페이스에서 온 요청 허용하기
- Allowing requests originating from a single namespace
더보기
default 네임스페이스 에서 들어오는 호출만 허용!!
- 종종 특정 네임스페이스에서 시작한, 모든 서비스에 대한 트래픽을 허용하고 싶을 것이다.
- 이는 source.namespace 속성으로 할 수 있다.
- 다음 예제는 한 네임스페이스에서 온 HTTP GET 트래픽을 허용한다.
#
cat << EOF | kubectl apply -f -
apiVersion: "security.istio.io/v1beta1"
kind: "AuthorizationPolicy"
metadata:
name: "webapp-allow-view-default-ns"
namespace: istioinaction # istioinaction의 워크로드
spec:
rules:
- from: # default 네임스페이스에서 시작한
- source:
namespaces: ["default"]
to: # HTTP GET 요청에만 적용
- operation:
methods: ["GET"]
EOF
#
kubectl get AuthorizationPolicy -A
NAMESPACE NAME AGE
istio-system deny-all 11h
istioinaction webapp-allow-view-default-ns 11h
docker exec -it myk8s-control-plane istioctl proxy-config listener deploy/webapp.istioinaction --port 15006 -o json
...
{
"name": "envoy.filters.http.rbac",
"typedConfig": {
"@type": "type.googleapis.com/envoy.extensions.filters.http.rbac.v3.RBAC",
"rules": {
"policies": {
"ns[istio-system]-policy[deny-all]-rule[0]": {
"permissions": [
{
"notRule": {
"any": true
}
}
],
"principals": [
{
"notId": {
"any": true
}
}
]
},
"ns[istioinaction]-policy[webapp-allow-view-default-ns]-rule[0]": {
"permissions": [
{
"andRules": {
"rules": [
{
"orRules": {
"rules": [
{
"header": {
"name": ":method",
"exactMatch": "GET"
}
}
]
}
}
]
}
}
],
"principals": [
{
"andIds": {
"ids": [
{
"orIds": {
"ids": [
{
"filterState": {
"key": "io.istio.peer_principal",
"stringMatch": {
"safeRegex": {
"regex": ".*/ns/default/.*"
...
#
kubectl logs -n istioinaction -l app=webapp -c istio-proxy -f
# 호출 테스트
kubectl exec deploy/sleep -- curl -sSL webapp.istioinaction/api/catalog
...- sleep 서비스는 레거시 워크로드다. The sleep service is a legacy workload.
- 사이트카가 없으므로, ID도 없다. 그러므로 webapp 프록시는 요청이 default 네임이스페이스의 워크로드에서 온 것인지 확인할 수 없다.
- 이를 해결하려면 다음 중 하나를 할 수 있다.
- sleep 서비스에 서비스 프록시 주입하기 → 실습 진행
- webapp에서 미인증 요청 허용하기
- 권장하는 방식은 sleep 서비스에 서비스 프록시를 주입하는 것이다.
- 그렇게 하면 ID를 부트스트랩하고 다른 워크로드와의 상호 인증을 수행해서 다른 워크로드가 요청의 출처와 네임스페이스를 확인 할 수 있다.
- 그러나 시연을 위해, 첫 번째 접근법이 불가능해(예를 들면, 팀 전체가 휴가 중이라서) 어쩔 수 없이 두 번째 접근법(덜 안전한)을 취해야 한다고 해보자.
- 미인증 요청을 허용하는 것이다.
[ 실습 ]
#
kubectl label ns default istio-injection=enabled
kubectl delete pod -l app=sleep
#
docker exec -it myk8s-control-plane istioctl proxy-status
NAME CLUSTER CDS LDS EDS RDS ECDS ISTIOD VERSION
sleep-6f8cfb8c8f-wncwh.default Kubernetes SYNCED SYNCED SYNCED SYNCED NOT SENT istiod-8d74787f-n4c7b 1.17.8
...
# 호출 테스트 : webapp
kubectl exec deploy/sleep -- curl -sSL webapp.istioinaction # default -> webapp 은 성공
...
kubectl exec deploy/sleep -- curl -sSL webapp.istioinaction/api/catalog
error calling Catalog service
docker exec -it myk8s-control-plane istioctl proxy-config log deploy/webapp -n istioinaction --level rbac:debug
kubectl logs -n istioinaction -l app=webapp -c istio-proxy -f # webapp -> catalog 는 deny-all 로 거부됨
[2025-05-04T02:36:49.857Z] "GET /items HTTP/1.1" 403 - via_upstream - "-" 0 19 0 0 "-" "beegoServer" "669eb3d6-f59a-99e8-80cb-f1ff6c0faf99" "catalog.istioinaction:80" "10.10.0.16:3000" outbound|80||catalog.istioinaction.svc.cluster.local 10.10.0.14:33066 10.200.1.46:80 10.10.0.14:48794 - default
[2025-05-04T02:36:49.856Z] "GET /api/catalog HTTP/1.1" 500 - via_upstream - "-" 0 29 1 1 "-" "curl/8.5.0" "669eb3d6-f59a-99e8-80cb-f1ff6c0faf99" "webapp.istioinaction" "10.10.0.14:8080" inbound|8080|| 127.0.0.6:38191 10.10.0.14:8080 10.10.0.17:59998 outbound_.80_._.webapp.istioinaction.svc.cluster.local default
# 호출 테스트 : catalog
kubectl logs -n istioinaction -l app=catalog -c istio-proxy -f
kubectl exec deploy/sleep -- curl -sSL catalog.istioinaction/items # default -> catalog 은 성공
# 다음 실습을 위해 default 네임스페이스 원복
kubectl label ns default istio-injection-
kubectl rollout restart deploy/sleep
docker exec -it myk8s-control-plane istioctl proxy-status
kubectl exec deploy/sleep -- curl -sSL webapp.istioinaction # 거부 확인
[ 실행 결과 - 한 눈에 보기 ]
9.3.6 미인증 레거시 워크로드에서 온 요청 허용하기
- Allowing requests from non-authenticated legacy workloads
더보기
- 미인증 워크로드에서 온 요청을 허용하려면 from 필드를 삭제해야 한다.
- 아래 정책을 webapp에만 적용하기 위해 app:webapp 셀렉터를 추가한다.
- 이렇게 하면 catalog 서비스에는 여전히 상호 인증이 필요하다. This way, the catalog service still requires mutual authentication.
# cat ch9/allow-unauthenticated-view-default-ns.yaml
apiVersion: "security.istio.io/v1beta1"
kind: "AuthorizationPolicy"
metadata:
name: "webapp-allow-unauthenticated-view-default-ns"
namespace: istioinaction
spec:
selector:
matchLabels:
app: webapp
rules:
- to:
- operation:
methods: ["GET"][ 실습 ]
#
kubectl apply -f ch9/allow-unauthenticated-view-default-ns.yaml
kubectl get AuthorizationPolicy -A
NAMESPACE NAME AGE
istio-system deny-all 12h
istioinaction webapp-allow-unauthenticated-view-default-ns 14s
istioinaction webapp-allow-view-default-ns 11h
# 여러개의 정책이 적용 시에 우선순위는?
docker exec -it myk8s-control-plane istioctl proxy-config listener deploy/webapp.istioinaction --port 15006 -o json | jq
...
"name": "envoy.filters.http.rbac",
"typedConfig": {
"@type": "type.googleapis.com/envoy.extensions.filters.http.rbac.v3.RBAC",
"rules": {
"policies": {
"ns[istio-system]-policy[deny-all]-rule[0]": {
"permissions": [
{
"notRule": {
"any": true
}
}
],
"principals": [
{
"notId": {
"any": true
}
}
]
},
"ns[istioinaction]-policy[webapp-allow-unauthenticated-view-default-ns]-rule[0]": {
"permissions": [
{
"andRules": {
"rules": [
{
"orRules": {
"rules": [
{
"header": {
"name": ":method",
"exactMatch": "GET"
}
}
]
}
}
]
}
}
],
"principals": [
{
"andIds": {
"ids": [
{
"any": true
}
]
}
}
]
},
"ns[istioinaction]-policy[webapp-allow-view-default-ns]-rule[0]": {
"permissions": [
{
"andRules": {
"rules": [
{
"orRules": {
"rules": [
{
"header": {
"name": ":method",
"exactMatch": "GET"
}
}
]
}
}
]
}
}
],
"principals": [
{
"andIds": {
"ids": [
{
"orIds": {
"ids": [
{
"filterState": {
"key": "io.istio.peer_principal",
"stringMatch": {
"safeRegex": {
"regex": ".*/ns/default/.*"
}
...
# 호출 테스트 : webapp
kubectl exec deploy/sleep -- curl -sSL webapp.istioinaction # default -> webapp 은 성공
...
kubectl logs -n istioinaction -l app=webapp -c istio-proxy -f # webapp -> catalog 는 deny-all 로 거부됨
kubectl exec deploy/sleep -- curl -sSL webapp.istioinaction/api/catalog
error calling Catalog service
# (옵션) 호출 테스트 : catalog
kubectl logs -n istioinaction -l app=catalog -c istio-proxy -f
kubectl exec deploy/sleep -- curl -sSL catalog.istioinaction/items
- webapp 은 sleep 서비스에서 요청을 허용했지만, 메시 범위 전체 거부 정책이 catalog 서비스로의 후속 요청을 거부헀다.
- 다음절에서 해결해보자.
[ 실행 결과 - 한 눈에 보기 ]
9.3.7 특정 서비스 어카운트에서 온 요청 허용하기
- Allowing requests from a single service account
더보기
- 트래픽이 webapp 서비스에서 왔는지 인증할 수 있는 간단한 방법은 트래픽에 주입된 서비스 어카운트를 사용하는 것이다.
- 서비스 어카운트 정보는 SVID에 인코딩돼 있으며, 상호 인증 중에 그 정보를 검증하고 필터 메타데이터에 저장한다.
- 다음 정책은 catalog 서비스가 필터 메타데이터를 사용해 서비스 어카운트가 webapp인 워크로드에서 온 트래픽만 허용하도록 설정한다.
# cat ch9/catalog-viewer-policy.yaml
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"] # Allows requests with the identity of webapp
to:
- operation:
methods: ["GET"][ 실습 ]
#
kubectl apply -f ch9/catalog-viewer-policy.yaml
kubectl get AuthorizationPolicy -A
NAMESPACE NAME AGE
istio-system deny-all 13h
istioinaction catalog-viewer 10s
istioinaction webapp-allow-unauthenticated-view-default-ns 61m
istioinaction webapp-allow-view-default-ns 12h
#
docker exec -it myk8s-control-plane istioctl proxy-config listener deploy/catalog.istioinaction --port 15006 -o json
...
"principals": [
{
"andIds": {
"ids": [
{
"orIds": {
"ids": [
{
"filterState": {
"key": "io.istio.peer_principal",
"stringMatch": {
"exact": "spiffe://cluster.local/ns/istioinaction/sa/webapp"
}
...
# 호출 테스트 : sleep --(미인증 레거시 허용)--> webapp --(principals webapp 허용)--> catalog
kubectl exec deploy/sleep -- curl -sSL webapp.istioinaction
kubectl exec deploy/sleep -- curl -sSL webapp.istioinaction/api/catalog
kubectl logs -n istioinaction -l app=webapp -c istio-proxy -f
kubectl logs -n istioinaction -l app=catalog -c istio-proxy -f
# (옵션) 호출 테스트 : catalog
kubectl exec deploy/sleep -- curl -sSL catalog.istioinaction/items
...- 그러나 워크로드 ID가 도난당한 경우 피해를 가능한 한 최소한의 범위로 제한하도록 엄격한 인가 정책을 갖고 있다는 점이 더 중요하다.
- But more importantly, we have strict authorization policies in place so that if the identity of a workload is stolen, the damage will be limited to the smallest scope possible.
[ 실행 결과 - 한 눈에 보기 ]
9.3.8 정책의 조건부 적용
- Conditional matching of policies
더보기
- 가끔 어떤 정책은 특정 조건이 충족되는 경우에만 적용되기도 한다.
- 사용자가 관리자일 때는 모든 작업을 허용하는 식이다.
- 이는 다음 에제처럼 인가 정책의 when 속성을 사용해 구현할 수 있다.
apiVersion: "security.istio.io/v1beta1"
kind: "AuthorizationPolicy"
metadata:
name: "allow-mesh-all-ops-admin"
namespace: istio-system
spec:
rules:
- from:
- source:
requestPrincipals: ["auth@istioinaction.io/*"]
when:
- key: request.auth.claims[groups] # 이스티오 속성을 지정한다
values: ["admin"] # 반드시 일치해야 하는 값의 목록을 지정한다- 이 정책은 다음 두 조건이 모두 충족될 때만 요청을 허용한다.
- 첫째, 토큰은 요청 주체 auth@istioinaction.io/* 가 발급한 것이어야 한다.
- 둘째, JWT에 값이 ‘admin’인 group 클레임 claim이 포함돼 있어야 한다.
- 또는 notValues 속성을 사용해 이 정책을 적용하지 않아야 하는 값들을 정의할 수도 있다.
- 조건에서 사용할 수 있는 이스티오 속성 전체 목록은 이스티오 문서에서 찾을 수 있다.
- https://istio.io/latest/docs/reference/config/security/conditions/
☞ Principals vs. request principals 차이점 source 를 정의하는 문서를 보면 https://istio.io/latest/docs/reference/config/security/authorization-policy/#Source from 절에서 요청의 주체를 인식하는 방법에는 Principals , request principals 가 있다는 것을 알 수 있다. Principals 은 PeerAuthentication 으로 설정한 상호 TLS 커넥션의 참가자인 것과 달리, request principals 는 최종 사용자 Request Authentication 용이며 JWT에서 온다는 점에서 차이가 있다.
9.3.9 값 비교 표현식 이해하기
- Understanding value-match expressions
더보기
- 앞 선 예제에서 값이 항상 정확히 일치할 필요는 없다는 것을 확인했다.
- 이스티오는 규칙을 더 다양하게 만들 수 있도록 간단한 비교 표현식을 지원한다.
- Exact matching of values 일치. 예를 들어 GET은 값이 정확히 일치해야 한다.
- Prefix matching of values 접두사 (매칭)비교. 예를 들어 /api/catlog* 는 /api/catalog/1 과 같이 접두사로 시작하는 모든 값에 부합한다.
- Suffix matching of values 접미사 (매칭)비교. 예를 들어 *.istioinaction.io 는 login.istioinaction.io 와 같이 모든 서브도메인에 부합한다.
- Presence matching 존재성 (매칭)비교. 모든 값에 부합하며 *로 표기한다. 이는 필드가 존재해야 하지만, 값은 중요하지 않아 어떤 값이든 괜찮음을 의미한다.
- 정책 규칙이 어떻게 평가되는지 이해하기 UNDERSTANDING HOW POLICY RULES ARE EVALUATED
더보기
정책 규칙을 이해하기 위해 좀 더 복잡한 규칙이 어떤 요청에 적용되는지 구체적으로 분석해보자
apiVersion: "security.istio.io/v1beta1"
kind: "AuthorizationPolicy"
metadata:
name: "allow-mesh-all-ops-admin"
namespace: istio-system
spec:
rules:
- from: # 첫 번째 규칙
- source:
principals: ["cluster.local/ns/istioinaction/sa/webapp"]
- source:
namespace: ["default"]
to:
- operation:
methods: ["GET"]
paths: ["/users*"]
- operation:
methods: ["POST"]
paths: ["/data"]
when:
- key: request.auth.claims[group]
values: ["beta-tester", "admin", "developer"]
- to: # 두 번째 규칙
- operation:
paths: ["*.html", "*.js", "*.png"]
- 위 인가 정책이 요청에 적용되려면, 첫 번째 규칙이나 두 번째 규칙에 해당해야 한다.
- 첫 번째 규칙에 해당하는 경우를 좀 더 자세히 살펴보자.
- from: # 소스들 Sources
- source:
principals: ["cluster.local/ns/istioinaction/sa/webapp"]
- source:
namespace: ["default"]
to: # operations 들
- operation:
methods: ["GET"]
paths: ["/users*"]
- operation:
methods: ["POST"]
paths: ["/data"]
when: # 조건들 Conditions
- key: request.auth.claims[group]
values: ["beta-tester", "admin", "developer"]- 요청이 이 규칙에 해당하려면, 세 가지 속성에서 모두 부합해야 한다.
- source 목록에서 정의한 source 중 하나가 operation 목록에서 정의한 operation 과 맞아야 하고, 모든 조건이 부합해야 한다.
- 다시 말해 from 에서 정의한 source 가 to 에 정의한 operation 중 하나와 AND 연산되고, 둘 다 when 에서 지정한 조건들 모두와 AND 연산된다.
☞ operation 에 어떻게 해당하는지 이해하기 위해 operation을 좀 더 자세히 살펴보자.
to: # operations 들
- operation: # 첫 번째 operation
methods: ["GET"] # 첫 번째 operation에 해당하려면 일치해야 하는 두 속성
paths: ["/users*"] # 첫 번째 operation에 해당하려면 일치해야 하는 두 속성
- operation: # 첫 번째 operation
methods: ["POST"] # 두 번째 operation에 해당하려면 일치해야 하는 두 속성
paths: ["/data"] # 두 번째 operation에 해당하려면 일치해야 하는 두 속성- 이 규칙에서 operation 이 부합하려면, 첫 번째나 두 번째 operation이 부합해야 한다.
- operation 이 부합하려면 모든 속성이 부합해야 한다. 즉, 모든 속성이 AND로 연결된다.
☞ when 속성의 경우도 AND로 연결되기 때문에 모든 조건이 부합해야 한다.
9.3.10 인가 정책이 평가되는 순서 이해하기
- Understanding the order in which authorization policies are evaluated
더보기
https://istio.io/v1.17/docs/concepts/security/#implicit-enablement
- 한 워크로드에 많은 정책이 적용되고 순서를 이해하기 어려울 때 정책의 복잡성이 대두된다.
- 많은 솔루션이 priority 필드를 사용해 순서를 정의한다.
- 이스티오는 정책 평가에 다른 접근법을 사용한다.
- CUSTOM policies are evaluated first. CUSTOM 정책이 가장 먼저 평가된다.
- 추후 외부 인가 서버와 통합할 때 CUSTOM 정책의 사례를 보여줄 것이다.
- DENY policies are evaluated next. If no DENY policy is matched . . .
- 다음으로 DENY 정책이 평가된다. 일치하는 DENY 정책이 없으면…
- ALLOW policies are evaluated. If one matches, the request is allowed. Otherwise. . .
- ALLOW 정책이 평가된다. 일치하는 것이 있으면 허용된다. 그렇지 않으면…
- According to the presence or absence of a catch-all policy, we have two outcomes: 일반 정책의 존재 유무에 따라 두 가지 결과가 나타난다.
- When a catch-all policy is present, it determines whether the request is approved. 일반 정책이 존재하면, 일반 정책이 요청 승인 여부를 결정한다.
- When a catch-all policy is absent, the request is: 일반 정책이 없으면, 요청은 다음과 같다.
- Allowed if there are no ALLOW policies, or it’s ALLOW 정책이 없으면 허용된다.
- Rejected when there are ALLOW policies but none matches. ALLOW 정책이 있지만 아무것도 해당되지 않으면 거부된다.
- CUSTOM policies are evaluated first. CUSTOM 정책이 가장 먼저 평가된다.
- 조건에 따라 동작이 바뀌므로, 그림 9.11 같은 흐름도를 사용하면 더 이해하기 쉬울 수 있다.
- 흐름이 조금 복잡하지만, 일반 DENY 정책을 정의하면 휠씬 간단해진다.
- 요청을 거부하는 CUSTOM과 DENY 정책이 없으면, 허용할 ALLOW 정책이 있는지만 확인하면 된다.
- 지금까지 워크로드 사이의 요청에 대한 인증 및 인가를 다뤘다.
- 다음 절에서는 최종 사용자 인증 및 인가 기능을 살펴본다.
[ 인증과 인가 - Authentication and Authorization ]
더보기
1. 인증 (Authentication)
- 인증은 클라이언트의 신원을 확인하는 과정으로, Istio에서는 주로 JWT(JSON Web Token)를 사용하여 요청의 유효성을 검증합니다. 이를 위해 RequestAuthentication 리소스를 사용하여 특정 워크로드에서 지원하는 인증 방법을 정의합니다.
1-1. 주요 특징
- JWT 검증: 요청 헤더에 포함된 JWT를 검증하여 사용자의 신원을 확인합니다.
- 유연한 정책 적용: 인증 정책은 네임스페이스 수준 또는 특정 워크로드에 적용할 수 있습니다.
- 인증 실패 처리: 잘못된 인증 정보가 포함된 요청은 거부되며, 인증 정보가 없는 요청은 허용되지만 인증된 ID는 부여되지 않습니다.
1-2. 사용 예시
apiVersion: security.istio.io/v1beta1
kind: RequestAuthentication
metadata:
name: jwt-auth
namespace: foo
spec:
selector:
matchLabels:
app: httpbin
jwtRules:
- issuer: "https://accounts.google.com"
jwksUri: "https://www.googleapis.com/oauth2/v3/certs"
2. 인가 (Authorization)
- 인가는 인증된 주체가 특정 리소스에 접근할 수 있는 권한이 있는지를 결정하는 과정입니다. Istio에서는 AuthorizationPolicy 리소스를 사용하여 이러한 접근 제어를 구현합니다. - Ref. Link
2-1. 주요 특징
- 정책 기반 접근 제어: ALLOW, DENY, CUSTOM, AUDIT 등의 액션을 통해 세밀한 접근 제어가 가능합니다.
- 다양한 조건 설정: 요청의 소스, 대상, 작업(Operation), 조건(Conditions) 등을 기반으로 정책을 정의할 수 있습니다.
- 우선순위 평가: CUSTOM → DENY → ALLOW 순으로 정책이 평가되며, 일치하는 정책이 없을 경우 기본적으로 요청이 허용됩니다.
2-2. 사용 예시
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
name: allow-httpbin
namespace: foo
spec:
selector:
matchLabels:
app: httpbin
action: ALLOW
rules:
- from:
- source:
principals: ["cluster.local/ns/default/sa/sleep"]
to:
- operation:
methods: ["GET"]
paths: ["/info*"]
when:
- key: request.auth.claims[iss]
values: ["https://accounts.google.com"]
이 정책은 foo 네임스페이스의 httpbin 애플리케이션에 대해, default 네임스페이스의 sleep 서비스 계정으로부터의 요청 중 JWT의 발급자가 https://accounts.google.com인 경우에만 /info 경로에 대한 GET 요청을 허용합니다. - Ref. Link
[ 인증과 인가의 차이점 ]
| 항목 | 인증 (Authentication) | 인가 (Authorization) |
| 목적 | 요청자의 신원 확인 | 요청자의 리소스 접근 권한 결정 |
| Istio 리소스 | RequestAuthentication | AuthorizationPolicy |
| 주요 구성 요소 | JWT, mTLS, 인증서 | 정책, 규칙, 조건 |
| 평가 시점 | 요청 수신 시 초기 단계 | 인증 후, 요청 처리 전에 |
| 결과 | 요청자의 신원 정보 제공 | 요청 허용 또는 거부 결정 |
9.4 최종 사용자 인증 및 인가
☞ https://netpple.github.io/docs/istio-in-action/Istio-ch9-securing-4-end-user-auth
▶ 사전지식 : Service Account Token Volume Projection, Admission Control, JWT(JSON Web Token), OIDC
더보기
https://research.securitum.com/jwt-json-web-token-security/
https://coffeewhale.com/kubernetes/authentication/http-auth/2020/05/03/auth02/
https://jwt.io/
1. SA Token Volume Projection
- '서비스 계정 토큰'의 시크릿 기반 볼륨 대신 'projected volume' 사용
☞ Service Account Token (SAT) Volume Projection - 링크
Kubernetes의 Service Account Token Volume Projection은 보안성과 유연성을 향상시키기 위해 도입된 기능으로, 기존의 정적이고 장기 유효한 토큰 대신 시간 제한이 있는 동적 토큰을 Pod에 마운트할 수 있도록 지원합니다.
[ 주요 개념 및 동작 방식 ]
- 기존 방식의 한계:
- 과거에는 ServiceAccount가 생성되면 자동으로 Secret 객체가 생성되고, 해당 토큰이 Pod에 마운트되었습니다.
- 이러한 토큰은 만료되지 않아 보안 취약점이 있었으며, 수동으로 키를 회전해야 했습니다.
- Token Volume Projection의 도입:
- TokenRequest API를 통해 audience와 만료 시간이 지정된 토큰을 생성하고, 이를 Pod에 projected volume으로 마운트할 수 있습니다.
- 이 방식은 Kubernetes v1.20부터 기본적으로 활성화되었으며, v1.21에서는 BoundServiceAccountTokenVolume 기능이 베타로 승격되었습니다.
- 토큰의 특성:
- 시간 제한: 기본적으로 1시간의 유효 기간을 가지며, kubelet이 자동으로 갱신합니다.
- audience 지정: 토큰의 사용 대상을 명확히 지정하여 오용을 방지합니다.
- Pod 및 ServiceAccount에 바인딩: Pod 또는 ServiceAccount가 삭제되면 토큰도 무효화됩니다.
[ 장점 및 보안강화 ]
- 보안성 향상: 시간 제한과 audience 지정으로 토큰의 오용을 방지합니다.
- 자동 갱신: kubelet이 토큰을 자동으로 갱신하여 관리 부담을 줄입니다.
- 유연한 구성: Pod 수준에서 토큰의 속성을 세밀하게 설정할 수 있습니다.
2. JWT
☞ Bearer type - JWT(JSON Web Token) X.509 Certificate의 lightweight JSON 버전
- Bearer type 경우, 서버에서 지정한 어떠한 문자열도 입력할 수 있습니다. 하지만 굉장히 허술한 느낌을 받습니다.
- 이를 보완하고자 쿠버네티스에서 Bearer 토큰을 전송할 때 주로 JWT (JSON Web Token) 토큰을 사용합니다.
- JWT는 X.509 Certificate와 마찬가지로 private key를 이용하여 토큰을 서명하고 public key를 이용하여 서명된 메세지를 검증합니다.
- 이러한 메커니즘을 통해 해당 토큰이 쿠버네티스를 통해 생성된 valid한 토큰임을 인증할 수 있습니다.
- X.509 Certificate의 lightweight JSON 버전이라고 생각하면 편리합니다.
- jwt는 JSON 형태로 토큰 형식을 정의한 스펙입니다. jwt는 쿠버네티스에서 뿐만 아니라 다양한 웹 사이트에서 인증, 권한 허가, 세션관리 등의 목적으로 사용합니다.
- Header: 토큰 형식와 암호화 알고리즘을 선언합니다.
- Payload: 전송하려는 데이터를 JSON 형식으로 기입합니다.
- Signature: Header와 Payload의 변조 가능성을 검증합니다.
- 각 파트는 base64 URL 인코딩이 되어서 .으로 합쳐지게 됩니다.
(심화 참고) JWT 소개 추천 영상 - 생활코딩 , 코딩애플
3. OIDC
- 사용자를 인증해 사용자에게 액세스 권한을 부여할 수 있게 해주는 프로토콜 ⇒ [커피고래]님 블로그 OpenID Connect - 링크
- OAuth 2.0 : 권한허가 처리 프로토콜, 다른 서비스에 접근할 수 있는 권한을 획득하거나 반대로 다른 서비스에게 권한을 부여할 수 있음 - 생활코딩
- 위임 권한 부여 Delegated Authorization, 사용자 인증 보다는 제한된 사람에게(혹은 시스템) 제한된 권한을 부여하는가, 예) 페이스북 posting 권한
- Access Token : 발급처(OAuth 2.0), 서버의 리소스 접근 권한
- OpenID : 비영리기관인 OpenID Foundation에서 추진하는 개방형 표준 및 분산 인증 Authentication 프로토콜, 사용자 인증 및 사용자 정보 제공(id token) - 링크
- ID Token : 발급처(OpenID Connect), 유저 프로필 정보 획득
- OIDC OpenID Connect = OpenID 인증 + OAuth2.0 인가, JSON 포맷을 이용한 RESful API 형식으로 인증 - 링크
- iss: 토큰 발행자
- sub: 사용자를 구분하기 위한 유니크한 구분자
- email: 사용자의 이메일
- iat: 토큰이 발행되는 시간을 Unix time으로 표기한 것
- exp: 토큰이 만료되는 시간을 Unix time으로 표기한 것
- aud: ID Token이 어떤 Client를 위해 발급된 것인지.
- IdP Open Identify Provider : 구글, 카카오와 같이 OpenID 서비스를 제공하는 신원 제공자.
- OpenID Connect에서 IdP의 역할을 OAuth가 수행 - 링크
- RP Relying Party : 사용자를 인증하기 위해 IdP에 의존하는 주체
9.4.1 JSON 웹 토큰이란 무엇인가? - wiki* (실습~)
더보기
서버는 클라이언트가 제시한 토큰을 검증하기 위해 JWKS를 가져온다.
- 이스티오에서 JWT를 사용해 최종 사용자 인증 및 인가를 지원한다는 사실은 앞서 간단히 언급했다.
- 요청의 인증 및 인가가 작동하는 방식을 자세히 다루기 전에 JWT를 간단히 살펴보자.
- 이 주제에 대한 기본 지식을 이미 갖췄다면 다음 절로 건너뛰어도 된다.
- JWT는 클라이언트르 서버에 인증하는 데 사용하는 간단한 클레임 표현이다. A JWT is a compact claims representation used to authenticate a client to a server.
- JWT는 다음 세 가지 부분으로 이뤄져 있다.
- 헤더 : 유형 및 해싱 알고리듬으로 구성
- 페이로드 : 사용자 클레임 포함
- 서명 : JWT의 진위 여부를 파악하는 데 사용
- 이 세 부분, 즉 헤더, 페이로드, 서명이 점(.)으로 구분되고 Base64 URL로 인코딩되기 때문에 JWT는 HTTP 요청으로 사용하기에 매우 적합하다.
- ch9/enduser/user.jwt 에 있는 토큰의 내용물을 확인해보고, 페이로드를 디코딩해보자.
#
cat ./ch9/enduser/user.jwt
# 디코딩 방법 1
jwt decode $(cat ./ch9/enduser/user.jwt)
# 디코딩 방법 2
cat ./ch9/enduser/user.jwt | cut -d '.' -f1 | base64 --decode | sed 's/$/}/' | jq
cat ./ch9/enduser/user.jwt | cut -d '.' -f2 | base64 --decode | sed 's/$/"}/' | jq
{
"exp": 4745145038, # 만료 시간 Expiration time
"group": "user", # 'group' 클레임
"iat": 1591545038, # 발행 시각 Issue time
"iss": "auth@istioinaction.io", # 토큰 발행자 Token issuer
"sub": "9b792b56-7dfa-4e4b-a83f-e20679115d79" # 토큰의 주체 Subject or principal of the token
}- 이 데이터는 주체 subject 에 대한 클레임을 표현한다. 클레임 덕분에 서비스는 클라이언트의 ID 및 인가를 판단할 수 있다. The claims enable the service to determine the identity and authorization of a client.
- 예를 들어 이 토큰이 사용자 그룹에 있는 주체에 속한다고 해보자. 서비스는 이 정보를 사용해 이 주체의 접근 수준을 결정할 수 있다.
- 클레임을 신뢰하려면 토큰이 검증될 수 있어야 한다. For claims to be trusted, the token needs to be verifiable.
☞ JWT는 어떻게 발행되고 검증되는가? HOW IS A JWT ISSUED AND VALIDATED?
- JWT(JSON 웹 토큰)는 인증 서버에서 발급되는데, 인증 서버는 토큰을 서명하는 비밀 키와 검증하기 위한 공개 키를 갖고 있다.
- 공개 키는 JWKS JSON Web Key Set, JSON 웹 키셋 라고 하며, well-known HTTP 엔드포인트에 노출된다.
- 서비스는 이 엔드포인트에서 공개 키를 가져와 인증 서버가 발급한 토큰을 검증할 수 있다.
- 인증 서버는 여러 솔루션으로 준비할 수 있다.
- 애플리케이션 백엔드 프레임워크에서 구현할 수 있다.
- OpenIAM 혹은 Keycloak 등의 서비스로, 자체적으로 구현할 수 있다.
- Auth0, Okta 등의 서비스형 ID Identity-as-a-Service 솔루션으로 구현할 수 있다.
- 그림 9.12는 서버가 토큰을 검증하는 데 JWKS를 어떻게 사용하는지 시각화한다.
- JWKS는 서명을 복호화하는 데 사용하는 공개 키를 포함한다.
- 서명을 복호화하고 토큰 데이터의 해시값과 비교하는데, 일치하면 토큰 클레임을 신뢰할 수 있다.
- 인증서버는 “토큰 서명”을 위한 private key 와 “토큰 검증”을 위한 public key를 가지고 있음
- 인증서버에서 private key 로 서명한 JWT (JSON Web Token) 을 발급
- 인증서버의 public key는 JWKS (JSON Web Key Set) 형태의 HTTP 엔드포인트로 제공
- 서비스는 인증서버에서 발급된 JWT 를 검증하기 위해 필요한 public key를 JWKS 에서 찾습니다
- public key로 JWT 서명을 복호화 하여 얻은 해시값과 JWT 토큰 데이터의 해시값을 비교하여
- 해시값이 동일할 경우 토큰 claim에 변조가 없었음을 보장하므로 신뢰할 수 있습니다.
9.4.2 인그레스 게이트웨이에서의 최종 사용자 인증 및 인가 - 실습
- End-user authentication and authorization at the ingress gateway
더보기
- 이스티오 워크로드가 JWT로 최종 사용자 요청을 인증하고 인가하도록 설정할 수 있다. Istio workloads can be configured to authenticate and authorize end-user requests with JWTs.
- 최종 사용자란 ID 제공자에게 인증받고 ID와 클레임을 나타내는 토큰을 발급받은 사용자를 말한다. End user means the user that was authenticated by an identity provider and received a token issued to represent its identity and claims.
- 최종 사용자 인가는 모든 워크로드 수준에서 수행할 수 있지만, 보통은 이스티오 인그레스 게이트웨이에서 수행한다.
- 이렇게 하면 유효하지 않은 요청을 조기에 거부하므로 성능이 좋아진다. This improves performance, as invalid requests are rejected early on.
- 또한 요청에서 JWT를 제거하는데, 후속 서비스가 사고로 유출되거나 악의적인 사용자가 재전송 공격 replay attack 에 사용하는 것을 방지하기 위해서다.
[ 실습 환경 구성 ]
#
kubectl delete virtualservice,deployment,service,\
destinationrule,gateway,peerauthentication,authorizationpolicy --all -n istioinaction
#
kubectl delete peerauthentication,authorizationpolicy -n istio-system --all
# 삭제 확인
kubectl get gw,vs,dr,peerauthentication,authorizationpolicy -A
# 실습 환경 배포
kubectl apply -f services/catalog/kubernetes/catalog.yaml -n istioinaction
kubectl apply -f services/webapp/kubernetes/webapp.yaml -n istioinaction
cat ch9/enduser/ingress-gw-for-webapp.yaml
kubectl apply -f ch9/enduser/ingress-gw-for-webapp.yaml -n istioinaction
9.4.3 RequestAuthentication으로 JWT 검증하기*
- Validating JWTs with RequestAuthentication
[ 들어가며 ]
더보기
부록 C.6 필터 메타데이터에서 검증된 데이터 수집
요청을 인증 및 인가하도록 서비스 프록시를 구성하는 리소스
- RequestAuthentication 리소스의 주목적은 JWT를 검증하고, 유효한 토큰의 클레임을 추출하고, 이 클레임을 필터 메타데이터에 저장하는 것이다.
- 이 필터 메타데이터는 인가 정책이 조치를 취하는 근거로 사용한다.
- 필터 메타데이터란 서비스 프록시에서 필터 간 요청을 처리하는 동안 사용할 수 있는 키-값 쌍의 모음을 말한다.
- 이스티오 사용자로서 이것은 대부분 구현 세부 사항에 해당한다.
- 예를 들어 클레임 group: admin 이 있는 요청이 검증되면 이 값은 필터 메타데이터로 저장되며, 필터 메타데이터는 인가 정책이 요청을 허용하거나 거부하는 데 사용한다.
- 최종 사용자 요청에 따라 결과는 셋 중 하나가 된다.
- 유효한 토큰을 갖고 있는 요청은 클러스터로 받아들여지며, 이들의 클레임은 필터 메타데이터 형태로 정책에 전달된다.
- 유효하지 않은 토큰을 갖고 있는 요청은 거부된다.
- 토큰이 없는 요청은 클러스터로 받아들여지지만 요청 ID가 없다. 즉, 어떤 클레임도 필터 메타데이터에 저장되지 않는다.
- JWT가 있는 요청과 JWT가 없는 요청은 무엇이 다를까?
- JWT가 있는 요청은 RequestAuthentication 필터로 검증되고 JWT 클레임이 커넥션 필터 메타데이터에 저장돼 있는 반면,
- JWT가 없는 요청은 커넥션 필터 메타데이터에 클레임이 없다.
- 여기서 암시하는 중요한 세부 사항은 RequestAuthentication 리소스 그 자체는 인가를 적용하지 않는다(’인가를 강제하지 않는다’)는 것이다. 토큰 검증과 claim 추출을 통해 인증의 유효성을 검증하고 인가에서 활용할 정보를 저장하는 역할을 한다. An important implicit detail here is that RequestAuthentication resources by themselves do not enforce authorizations.
- 즉, 인가를 위해서는 여전히 AuthorizationPolicy 가 필요하다. You still need an AuthorizationPolicy for that.
☞ 다음 절에서는 RequestAuthentication 리소스를 만들고, 앞서 언급한 경우 모두를 실제 예제와 함께 보여준다.
▶ RequestAuthentication 리소스 만들기 CREATING A REQUESTAUTHENTICATION RESOURCE
더보기
- 다음 RequestAuthentication 리소스는 이스티오의 인그레스 게이트웨이에 적용된다.
- 이는 인그레스 게이트웨이가 auth@istioinaction.io 에서 발급한 토큰을 검증하도록 설정한다.
# cat ch9/enduser/jwt-token-request-authn.yaml
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" # 발급자 Expected issuer
jwks: | # 특정 JWKS로 검증
{ "keys":[ {"e":"AQAB","kid":"CU-ADJJEbH9bXl0tpsQWYuo4EwlkxFUHbeJ4ckkakCM","kty":"RSA","n":"zl9VRDbmVvyXNdyoGJ5uhuTSRA2653KHEi3XqITfJISvedYHVNGoZZxUCoiSEumxqrPY_Du7IMKzmT4bAuPnEalbY8rafuJNXnxVmqjTrQovPIerkGW5h59iUXIz6vCznO7F61RvJsUEyw5X291-3Z3r-9RcQD9sYy7-8fTNmcXcdG_nNgYCnduZUJ3vFVhmQCwHFG1idwni8PJo9NH6aTZ3mN730S6Y1g_lJfObju7lwYWT8j2Sjrwt6EES55oGimkZHzktKjDYjRx1rN4dJ5PR5zhlQ4kORWg1PtllWy1s5TSpOUv84OPjEohEoOWH0-g238zIOYA83gozgbJfmQ"}]}
#
kubectl apply -f ch9/enduser/jwt-token-request-authn.yaml
kubectl get requestauthentication -A
#
docker exec -it myk8s-control-plane istioctl proxy-config listener deploy/istio-ingressgateway.istio-system
docker exec -it myk8s-control-plane istioctl proxy-config listener deploy/istio-ingressgateway.istio-system --port 8080 -o json
...
"httpFilters": [
{
"name": "istio.metadata_exchange",
"typedConfig": {
"@type": "type.googleapis.com/envoy.extensions.filters.http.wasm.v3.Wasm",
"config": {
"vmConfig": {
"runtime": "envoy.wasm.runtime.null",
"code": {
"local": {
"inlineString": "envoy.wasm.metadata_exchange"
}
}
},
"configuration": {
"@type": "type.googleapis.com/envoy.tcp.metadataexchange.config.MetadataExchange"
}
}
}
},
{
"name": "envoy.filters.http.jwt_authn",
"typedConfig": {
"@type": "type.googleapis.com/envoy.extensions.filters.http.jwt_authn.v3.JwtAuthentication",
"providers": {
"origins-0": {
"issuer": "auth@istioinaction.io",
"localJwks": {
"inlineString": "{ \"keys\":[ {\"e\":\"AQAB\",\"kid\":\"CU-ADJJEbH9bXl0tpsQWYuo4EwlkxFUHbeJ4ckkakCM\",\"kty\":\"RSA\",\"n\":\"zl9VRDbmVvyXNdyoGJ5uhuTSRA2653KHEi3XqITfJISvedYHVNGoZZxUCoiSEumxqrPY_Du7IMKzmT4bAuPnEalbY8rafuJNXnxVmqjTrQovPIerkGW5h59iUXIz6vCznO7F61RvJsUEyw5X291-3Z3r-9RcQD9sYy7-8fTNmcXcdG_nNgYCnduZUJ3vFVhmQCwHFG1idwni8PJo9NH6aTZ3mN730S6Y1g_lJfObju7lwYWT8j2Sjrwt6EES55oGimkZHzktKjDYjRx1rN4dJ5PR5zhlQ4kORWg1PtllWy1s5TSpOUv84OPjEohEoOWH0-g238zIOYA83gozgbJfmQ\"}]}\n"
},
"payloadInMetadata": "auth@istioinaction.io"
}
},
"rules": [
{
"match": {
"prefix": "/"
},
"requires": {
"requiresAny": {
"requirements": [
{
"providerName": "origins-0"
},
{
"allowMissing": {}
}
]
}
}
}
],
"bypassCorsPreflight": true
}
},
{
"name": "istio_authn",
"typedConfig": {
"@type": "type.googleapis.com/istio.envoy.config.filter.http.authn.v2alpha1.FilterConfig",
"policy": {
"origins": [
{
"jwt": {
"issuer": "auth@istioinaction.io"
}
}
],
"originIsOptional": true,
"principalBinding": "USE_ORIGIN"
},
"skipValidateTrustDomain": true
...[ 실행 결과 - 한 눈에 보기 ]
☞ 이하 발급 내용은 istio-listener 에서 확인
▶ 유효한 발행자의 토큰이 있는 요청은 받아들여진다 REQUESTS WITH TOKENS FROM VALID ISSUERS ARE ACCEPTED
더보기
- 유효한 JWT로 요청해보자
#
cat ch9/enduser/user.jwt
USER_TOKEN=$(< ch9/enduser/user.jwt)
jwt decode $USER_TOKEN
# 호출
curl -H "Authorization: Bearer $USER_TOKEN" \
-sSl -o /dev/null -w "%{http_code}" webapp.istioinaction.io:30000/api/catalog
# 로그
docker exec -it myk8s-control-plane istioctl proxy-config log deploy/istio-ingressgateway -n istio-system --level rbac:debug
kubectl logs -n istio-system -l app=istio-ingressgateway -f
☞ 워크로드에 적용된 인가 정책 AuthorizationPolicy 이 없으므로 기본적으로 허용 ALLOW 된다.
[ 실행 결과 - 한 눈에 보기 ]
1. JWT 환경변수 지정 및 decoding 확인
2. 웹 호출 확인
▶ 유효하지 않은 발행자의 토큰이 있는 요청은 거부된다 REQUESTS WITH TOKENS FROM INVALID ISSUERS ARE REJECTED
더보기
- 유효하지 않은 JWT로 요청해보자
#
cat ch9/enduser/not-configured-issuer.jwt
WRONG_ISSUER=$(< ch9/enduser/not-configured-issuer.jwt)
jwt decode $WRONG_ISSUER
...
Token claims
------------
{
"exp": 4745151548,
"group": "user",
"iat": 1591551548,
"iss": "old-auth@istioinaction.io", # 현재 설정한 정책의 발급자와 다름 issuer: "auth@istioinaction.io"
"sub": "79d7506c-b617-46d1-bc1f-f511b5d30ab0"
}
...
# 호출
curl -H "Authorization: Bearer $WRONG_ISSUER" \
-sSl -o /dev/null -w "%{http_code}" webapp.istioinaction.io:30000/api/catalog
# 로그
kubectl logs -n istio-system -l app=istio-ingressgateway -f
[2025-05-04T06:36:22.089Z] "GET /api/catalog HTTP/1.1" 401 - jwt_authn_access_denied{Jwt_issuer_is_not_configured} - "-" 0 28 1 - "172.18.0.1" "curl/8.7.1" "2e183b2e-0968-971d-adbc-6b149171912b" "webapp.istioinaction.io:30000" "-" outbound|80||webapp.istioinaction.svc.cluster.local - 10.10.0.5:8080 172.18.0.1:65436 - -[ 실행 결과 - 한 눈에 보기 ]
** 401 : jwt_authn_access_denied
▶ 토큰이 없는 요청은 클러스터로 받아들여진다 REQUESTS WITHOUT TOKENS ARE ADMITTED INTO THE CLUSTER
더보기
- 토큰 없이 curl 요청 실행
# 호출
curl -sSl -o /dev/null -w "%{http_code}" webapp.istioinaction.io:30000/api/catalog
# 로그
kubectl logs -n istio-system -l app=istio-ingressgateway -f☞ 응답 코드 요청이 클러스터로 받아들여졌음을 보여준다.
- 토큰이 없는 요청은 거부될 것으로 예상할 수 있으므로 혼란스러울 수 있다.
- 그러나 실제로는 애플리케이션의 프론트엔드에 서비스를 제공하는 등 요청에 토큰이 없는 시나리오가 많이 있다.
- 이런 이유로, 토큰이 없는 요청을 거부하려면 다음에 설명할 약간의 추가 작업이 필요하다.
▶ JWT가 없는 요청 거부하기 DENYING REQUESTS WITHOUT JWTS
더보기
- JWT가 없는 요청 거부하려면 명시적으로 거부하는 AuthorizationPolicy 리소스를 만들어야 한다.
- 이 정책은 requestPrincipals 속성이 없는 source 에서 온 모든 요청에 적용되며, (action 속성에 지정된 대로) 요청을 거부한다.
- requestPrincipals의 초기화 방식을 하게 되면 놀랄지도 모르는데, 바로 JWT의 발행자 issuer 와 주체 subject 클레임을 ‘iss/sub’ 형태로 결합한 것이다. You might be surprised where requestPrincipals is initialized: it is composed of the issuer and subject JWT claims (concatenated in the format iss/sub).
- 클레임은 RequestPrincipals 리소스로 인증되고, AuthorizationPolicy 필터 등 다른 필터가 사용할 수 있도록 커넥션 메타데이터로 가공된다.
# cat ch9/enduser/app-gw-requires-jwt.yaml # vi/vim, vscode 에서 포트 30000 추가
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
name: app-gw-requires-jwt
namespace: istio-system
spec:
selector:
matchLabels:
app: istio-ingressgateway
action: DENY
rules:
- from:
- source:
notRequestPrincipals: ["*"] # 요청 주체에 값이 없는 source는 모두 해당된다
to:
- operation:
hosts: ["webapp.istioinaction.io:30000"] # 이 규칙은 이 특정 호스트에만 적용된다
## ports: ["30000"]
#
kubectl apply -f ch9/enduser/app-gw-requires-jwt.yaml
#
kubectl get AuthorizationPolicy -A
NAMESPACE NAME AGE
istio-system app-gw-requires-jwt 2m14s
docker exec -it myk8s-control-plane istioctl proxy-config listener deploy/istio-ingressgateway.istio-system --port 8080 -o json
...
{
"name": "envoy.filters.http.rbac",
"typedConfig": {
"@type": "type.googleapis.com/envoy.extensions.filters.http.rbac.v3.RBAC",
"rules": {
"action": "DENY",
"policies": {
"ns[istio-system]-policy[app-gw-requires-jwt]-rule[0]": {
"permissions": [
{
"andRules": {
"rules": [
{
"orRules": {
"rules": [
{
"header": {
"name": ":authority",
"stringMatch": {
"exact": "webapp.istioinaction.io:30000",
"ignoreCase": true
}
}
}
]
}
}
]
}
}
],
"principals": [
{
"andIds": {
"ids": [
{
"notId": {
"orIds": {
"ids": [
{
"metadata": {
"filter": "istio_authn",
"path": [
{
"key": "request.auth.principal"
}
],
"value": {
"stringMatch": {
"safeRegex": {
"regex": ".+"
...
# 호출 1
curl -sSl -o /dev/null -w "%{http_code}" webapp.istioinaction.io:30000/api/catalog
403
# 호출 2
curl -H "Authorization: Bearer $USER_TOKEN" \
-sSl -o /dev/null -w "%{http_code}" webapp.istioinaction.io:30000/api/catalog
# 로그
kubectl logs -n istio-system -l app=istio-ingressgateway -f
[2025-05-04T07:04:01.791Z] "GET /api/catalog HTTP/1.1" 403 - rbac_access_denied_matched_policy[ns[istio-system]-policy[app-gw-requires-jwt]-rule[0]] - "-" 0 19 0 - "172.18.0.1" "curl/8.7.1" "41678cf6-6ef8-986e-beb4-4e5af46e7a26" "webapp.istioinaction.io:30000" "-" outbound|80||webapp.istioinaction.svc.cluster.local - 10.10.0.5:8080 172.18.0.1:65424 - -[ 실행 결과 - 한 눈에 보기 ]
1) JWT 없는 요청 명시적 거부 정책 적용
2) 서비스 호출 및 결과 확인
☞ 이제 토큰 없이 요청을 보내고, 요청 주체가 없기 때문에 인가하는 데 실패하는 것을 확인했다.
▶JWT 클레임에 기반한 다양한 접근 수준 - DIFFERENT LEVELS OF ACCESS BASED ON JWT CLAIMS
더보기
- 유저별로 다른 접근 정책 설정해보자.
- 이 예제에서는 일반 사용자가 API에서 데이터를 읽는 것은 허용하지만 새 데이터를 쓰거나 기존 데이터를 바꾸는 것은 금지한다.
- 한편, 관리자에게는 모든 권한을 허용할 것이다. 각 토큰들은 클레임이 다름.
# 일반 사용자 토큰 : 'group: user' 클레임
jwt decode $(cat ch9/enduser/user.jwt)
...
{
"exp": 4745145038,
"group": "user",
"iat": 1591545038,
"iss": "auth@istioinaction.io",
"sub": "9b792b56-7dfa-4e4b-a83f-e20679115d79"
}
# 관리자 토큰 : 'group: admin' 클레임
jwt decode $(cat ch9/enduser/admin.jwt)
...
{
"exp": 4745145071,
"group": "admin",
"iat": 1591545071,
"iss": "auth@istioinaction.io",
"sub": "218d3fb9-4628-4d20-943c-124281c80e7b"
}
- 일반 사용자가 webapp 에서 데이터를 읽을 수 있게 허용하도록 AuthorizationPolicy 리소스 설정
# cat ch9/enduser/allow-all-with-jwt-to-webapp.yaml # vi/vim, vscode 에서 포트 30000 추가
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
name: allow-all-with-jwt-to-webapp
namespace: istio-system
spec:
selector:
matchLabels:
app: istio-ingressgateway
action: ALLOW
rules:
- from:
- source:
requestPrincipals: ["auth@istioinaction.io/*"] # 최종 사용자 요청 주체를 표현 Represents the end-user request principal
to:
- operation:
hosts: ["webapp.istioinaction.io:30000"]
methods: ["GET"]
- 관리자에게 모든 작업을 허용하는 AuthorizationPolicy 리소스 설정
# cat ch9/enduser/allow-mesh-all-ops-admin.yaml
apiVersion: "security.istio.io/v1beta1"
kind: "AuthorizationPolicy"
metadata:
name: "allow-mesh-all-ops-admin"
namespace: istio-system
spec:
selector:
matchLabels:
app: istio-ingressgateway
action: ALLOW
rules:
- from:
- source:
requestPrincipals: ["auth@istioinaction.io/*"]
when:
- key: request.auth.claims[group]
values: ["admin"] # 이 클레임을 포함한 요청만 허용.[ 실습 ]
#
kubectl apply -f ch9/enduser/allow-all-with-jwt-to-webapp.yaml
kubectl apply -f ch9/enduser/allow-mesh-all-ops-admin.yaml
#
kubectl get authorizationpolicy -A
NAMESPACE NAME AGE
istio-system allow-all-with-jwt-to-webapp 5s
istio-system allow-mesh-all-ops-admin 5s
istio-system app-gw-requires-jwt 34m
#
docker exec -it myk8s-control-plane istioctl proxy-config listener deploy/istio-ingressgateway.istio-system --port 8080 -o json
...
"policies": {
"ns[istio-system]-policy[allow-all-with-jwt-to-webapp]-rule[0]": {
"permissions": [
{
"andRules": {
"rules": [
{
"orRules": {
"rules": [
{
"header": {
"name": ":authority",
"stringMatch": {
"exact": "webapp.istioinaction.io:30000",
"ignoreCase": true
...
"ns[istio-system]-policy[allow-mesh-all-ops-admin]-rule[0]": {
"permissions": [
{
"andRules": {
"rules": [
{
"any": true
}
]
}
}
],
"principals": [
{
"andIds": {
"ids": [
{
"orIds": {
"ids": [
{
"metadata": {
"filter": "istio_authn",
"path": [
{
"key": "request.auth.principal"
}
],
"value": {
"stringMatch": {
"prefix": "auth@istioinaction.io/"
}
}
}
}
]
}
},
{
"orIds": {
"ids": [
{
"metadata": {
"filter": "istio_authn",
"path": [
{
"key": "request.auth.claims"
},
{
"key": "group"
}
],
"value": {
"listMatch": {
"oneOf": {
"stringMatch": {
"exact": "admin"
...
# 수집된 메타데이터를 관찰하고자 서비스 프록시에 rbac 로거 설정
## 기본적으로 envoy rbac 로거는 메타데이터를 로그에 출력하지 않는다. 출력을 위해 로깅 수준을 debug 로 설정하자
docker exec -it myk8s-control-plane istioctl proxy-config log deploy/istio-ingressgateway -n istio-system --level rbac:debug
# 일반유저 : [GET]과 [POST] 호출
USER_TOKEN=$(< ch9/enduser/user.jwt)
curl -H "Authorization: Bearer $USER_TOKEN" \
-sSl -o /dev/null -w "%{http_code}\n" webapp.istioinaction.io:30000/api/catalog
curl -H "Authorization: Bearer $USER_TOKEN" \
-XPOST webapp.istioinaction.io:30000/api/catalog \
--data '{"id": 2, "name": "Shoes", "price": "84.00"}'
# 로그
kubectl logs -n istio-system -l app=istio-ingressgateway -f
...
, dynamicMetadata: filter_metadata {
key: "envoy.filters.http.jwt_authn"
value {
fields {
key: "auth@istioinaction.io"
value {
struct_value {
fields {
key: "exp"
value {
number_value: 4745145038
}
}
fields {
key: "group"
value {
string_value: "user"
}
}
...
[2025-05-04T07:39:27.597Z] "POST /api/catalog HTTP/1.1" 403 - rbac_access_denied_matched_policy[none] - "-" 0 19 1 - "172.18.0.1" "curl/8.7.1" "677a3c73-20a1-935a-b039-e2a8beae9d1b" "webapp.istioinaction.io:30000" "-" outbound|80||webapp.istioinaction.svc.cluster.local - 10.10.0.5:8080 172.18.0.1:57196 - -
# 관리자 : [GET]과 [POST] 호출
ADMIN_TOKEN=$(< ch9/enduser/admin.jwt)
curl -H "Authorization: Bearer $ADMIN_TOKEN" \
-sSl -o /dev/null -w "%{http_code}\n" webapp.istioinaction.io:30000/api/catalog
curl -H "Authorization: Bearer $ADMIN_TOKEN" \
-XPOST webapp.istioinaction.io:30000/api/catalog \
--data '{"id": 2, "name": "Shoes", "price": "84.00"}'
# 로그
kubectl logs -n istio-system -l app=istio-ingressgateway -f
- 관리자가 catalog 에 새 아이템을 만들 수 있도록 허용하고 있음을 확인함
[ 실행 결과 - 한 눈에 보기 ]
1) 코드 수정 및 정책 적용
2) 서비스 호출 테스트 결과 확인 ( 일반 사용자는 GET 만 허용 )
☞ Admin 유저는 모든 Action이 가능하다!!
9.5 커스텀 외부 인가 서비스와 통합하기
☞ https://netpple.github.io/docs/istio-in-action/Istio-ch9-securing-5-external_authz
[ 들어가며 - 외부 인가 서비스 호출 ]
더보기
외부 서버에서 요청을 인가받도록 CUSTOM 정책 사용하기
- SPIFFE를 기반으로 구축된 이스티오의 인증 메커니즘이 서비스 인가를 구축할 수 있는 기반을 제공하는 방법을 살펴봤다.
- 이스티오는 엔보이의 기본 RBAC 기능을 사용해 인가를 구현한다.
- 그런데 인가에 좀 더 정교한 커스텀 메커니즘이 필요하면 어떻게 해야 할까?
- 요청을 허용할지 여부를 결정할 때 외부 인가 서비스를 호출하도록 이스티오의 서비스 프록시를 설정할 수 있다.
- 그림 9.13에서 서비스 프록시에 들어온 요청은 프록시가 외부 인가(ExtAuthz) 서비스를 호출하는 동안 잠시 멈춘다.
- 외부 인가 서비스는 애플리케이션 사이드카로 메시 안에 존재하거나 메시 바깥에 존재할 수 있다.
- 외부 인가는 엔보이의 CheckRequest API를 구현해야 한다 - Code
- 이 API를 구현하는 외부 인가 서비스의 예를 들면 다음과 같다.
- Open Policy Agent (https://www.openpolicyagent.org/docs/latest/envoy-tutorial-istio)
- Signal Sciences (www.signalsciences.com/blog/integrations-envoy-proxy-support)
- Gloo Edge Ext Auth (https://docs.solo.io/gloo-edge/latest/guides/security/auth/extauth)
- Istio sample Ext Authz (https://github.com/istio/istio/tree/release-1.9/samples/extauthz)
- 외부 인가 서비스는 프록시가 인가를 집행하는 데 사용하는 ‘허용’이나 ‘거부’ 메시지를 반환한다. The ExtAuthz service returns an “allow” or “deny” message that the proxy then uses to enforce authorizations.
☞ ExtAuthz performance tradeoffs 외부 인가 성능 트레이드오프 요청 경로 중에 외부 인가 서비스를 호출하기 때문에 이 방법을 사용할 때는 지연 시간 증가에 대비해야 한다. 이스티오의 내장 인가 기능은 대체로 충분하고 유연하게 작동하지만, 완벽히 통제해야 한다면 외부 인가 서비스를 호출하면서 생기는 성능 트레이드오프를 평가해야 한다. 이전 단락에서 언급했듯이, 외부 인가 서비스를 애플리케이션 사이드카로 배포해 네트워크 오버헤드를 최소화할 수 있다. https://istio.io/latest/docs/tasks/security/authorization/authz-custom/
9.5.1 외부 인가 실습 - Hands-on with external authorization (실습~)
더보기
Step1. 실습 환경 초기화
# 기존 인증/인가 정책 모두 삭제
kubectl delete authorizationpolicy,peerauthentication,requestauthentication --all -n istio-system
# 실습 애플리케이션 배포
kubectl apply -f services/catalog/kubernetes/catalog.yaml -n istioinaction
kubectl apply -f services/webapp/kubernetes/webapp.yaml -n istioinaction
kubectl apply -f services/webapp/istio/webapp-catalog-gw-vs.yaml -n istioinaction
kubectl apply -f ch9/sleep.yaml -n default
# 이스티오 샘플에서 샘플 외부 인가 서비스 배포
docker exec -it myk8s-control-plane bash
-----------------------------------
#
ls -l istio-$ISTIOV/samples/extauthz/
total 24
-rw-r--r-- 1 root root 4238 Oct 11 2023 README.md
drwxr-xr-x 3 root root 4096 Oct 11 2023 cmd
drwxr-xr-x 2 root root 4096 Oct 11 2023 docker
-rw-r--r-- 1 root root 1330 Oct 11 2023 ext-authz.yaml
-rw-r--r-- 1 root root 2369 Oct 11 2023 local-ext-authz.yaml
cat istio-$ISTIOV/samples/extauthz/ext-authz.yaml
apiVersion: v1
kind: Service
metadata:
name: ext-authz
labels:
app: ext-authz
spec:
ports:
- name: http
port: 8000
targetPort: 8000
- name: grpc
port: 9000
targetPort: 9000
selector:
app: ext-authz
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: ext-authz
spec:
replicas: 1
selector:
matchLabels:
app: ext-authz
template:
metadata:
labels:
app: ext-authz
spec:
containers:
- image: gcr.io/istio-testing/ext-authz:latest
imagePullPolicy: IfNotPresent
name: ext-authz
ports:
- containerPort: 8000
- containerPort: 9000
kubectl apply -f istio-$ISTIOV/samples/extauthz/ext-authz.yaml -n istioinaction
# 빠져나오기
exit
-----------------------------------
# 설치 확인 : ext-authz
kubectl get deploy,svc ext-authz -n istioinaction
NAME READY UP-TO-DATE AVAILABLE AGE
deployment.apps/ext-authz 1/1 1 1 72s
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/ext-authz ClusterIP 10.200.1.172 <none> 8000/TCP,9000/TCP 72s
# 로그
kubectl logs -n istioinaction -l app=ext-authz -c ext-authz -f
- 배포한 ext-authz 서비스는 아주 간단해서 들어온 요청에 x-ext-authz 헤더가 있고 그 값이 allow 인지만 검사한다.
- 이 헤더가 요청에 들어 있으면 요청은 허용되고, 들어 있지 않으면 요청은 거부된다.
- 요청의 다른 속성을 평가하도록 외부 인가 서비스를 직접 작성하거나, 상술한 기존 서비스 중 하나를 사용할 수 있다.
[ 실습 결과 - 한 눈에 보기 ]
9.5.2 이스티오에 외부 인가 설정하기 Configuring Istio for ExtAuthz
더보기
- 이스티오가 새로운 외부 인가 서비스를 인식하도록 설정해야 한다.
- 이를 위해서는 이스티오 meshconfig 설정에서 extensionProviders 를 설정해야 한다.
- 이 설정은 istio-system 네임스페이스의 istio configmap에 있다.
- 이 configmap 을 수정해 새 외부 인가 서비스에 대한 적절한 설정을 추가해보자.
# includeHeadersInCheck (DEPRECATED)
KUBE_EDITOR="nano" kubectl edit -n istio-system cm istio
--------------------------------------------------------
...
extensionProviders:
- name: "sample-ext-authz-http"
envoyExtAuthzHttp:
service: "ext-authz.istioinaction.svc.cluster.local"
port: "8000"
includeRequestHeadersInCheck: ["x-ext-authz"]
...
--------------------------------------------------------
# 확인
kubectl describe -n istio-system cm istio
- 이스티오가 envoyExtAuthz 서비스의 HTTP 구현체인 새 확장 sample-ext-authz-http 를 인식하도록 설정했다. We’ve configured Istio to be aware of a new extension called sample-ext-authz-http, an HTTP implementation of the envoyExtAuthz service.
- 이 서비스는 에 ext-authz.istioinaction.svc.cluster.local 위치하는 것으로 정의했는데, 앞 절에서 봤던 쿠버네티스 서비스에 맞춘 것이다.
- 외부 인가 서비스에 전달할 헤더를 구성할 수 있는데, 이 설정에서는 x-ext-authz 헤더를 전달한다. We can configure what headers to pass along to the ExtAuthz service: in this configuration, we pass along the x-ext-authz header.
- 예제 외부 인가 서비스에서는 이 헤더를 인가 결과를 결정하는 데 사용한다. In our example ExtAuthz service, this header is used to determine an authorization result
- 이 외부 인가 기능을 사용하기 위한 마지막 단계는 이 기능을 사용하도록 AuthorizationPolicy 리소스를 설정하는 것이다.
- 어떻게 동작하는지 살펴보자.
9.5.3 커스텀 AuthorizationPolicy 리소스 사용하기 Using a custom AuthorizationPolicy resource
더보기
- 앞 절에서는 action 이 DENY 혹은 ALLOW 인 AuthorizationPolicy 리소스를 만들었다.
- 이 절에서는 action 이 CUSTOM 인 AuthorizationPolicy 를 만들고 정확히 어떤 외부 인가 서비스를 사용할지 지정해본다.
# 아래 AuthorizationPolicy 는 istioinaction 네임스페이스에 webapp 워크로드에 적용되며,
# sample-ext-authz-http 이라는 외부 인가 서비스에 위임한다.
cat << EOF | kubectl apply -f -
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
name: ext-authz
namespace: istioinaction
spec:
selector:
matchLabels:
app: webapp
action: CUSTOM # custom action 사용
provider:
name: sample-ext-authz-http # meshconfig 이름과 동일해야 한다
rules:
- to:
- operation:
paths: ["/*"] # 인가 정책을 적용할 경로
EOF
#
kubectl get AuthorizationPolicy -A
NAMESPACE NAME AGE
istioinaction ext-authz 98s- 호출 확인
#
docker exec -it myk8s-control-plane istioctl proxy-config log deploy/webapp -n istioinaction --level rbac:debug
kubectl logs -n istioinaction -l app=webapp -c istio-proxy -f
kubectl logs -n istioinaction -l app=ext-authz -c ext-authz -f
# 헤더 없이 호출
kubectl -n default exec -it deploy/sleep -- curl webapp.istioinaction/api/catalog
denied by ext_authz for not found header `x-ext-authz: allow` in the request
kubectl logs -n istioinaction -l app=webapp -c istio-proxy -f
2025-05-04T08:33:04.765006Z debug envoy rbac external/envoy/source/extensions/filters/http/rbac/rbac_filter.cc:114 checking request: requestedServerName: , sourceIP: 10.10.0.18:55834, directRemoteIP: 10.10.0.18:55834, remoteIP: 10.10.0.18:55834,localAddress: 10.10.0.20:8080, ssl: none, headers: ':authority', 'webapp.istioinaction'
':path', '/api/catalog'
':method', 'GET'
':scheme', 'http'
'user-agent', 'curl/8.5.0'
'accept', '*/*'
'x-forwarded-proto', 'http'
'x-request-id', 'ffd44f00-19ff-96b7-868b-8f6b09bd447d'
, dynamicMetadata: thread=31
2025-05-04T08:33:04.765109Z debug envoy rbac external/envoy/source/extensions/filters/http/rbac/rbac_filter.cc:130 shadow denied, matched policy istio-ext-authz-ns[istioinaction]-policy[ext-authz]-rule[0]thread=31
2025-05-04T08:33:04.765170Z debug envoy rbac external/envoy/source/extensions/filters/http/rbac/rbac_filter.cc:167 no engine, allowed by default thread=31
[2025-05-04T08:33:04.764Z] "GET /api/catalog HTTP/1.1" 403 UAEX ext_authz_denied - "-" 0 76 5 4 "-" "curl/8.5.0" "ffd44f00-19ff-96b7-868b-8f6b09bd447d" "webapp.istioinaction" "-" inbound|8080|| - 10.10.0.20:8080 10.10.0.18:55834 - -
kubectl logs -n istioinaction -l app=ext-authz -c ext-authz -f
2025/05/04 08:35:26 [HTTP][denied]: GET webapp.istioinaction/api/catalog, headers: map[Content-Length:[0] X-B3-Parentspanid:[58148c96f61496a3] X-B3-Sampled:[1] X-B3-Spanid:[960b8d911e81c217] X-B3-Traceid:[ce6c5622c32fd238a934fbf1aa4a9de0] X-Envoy-Expected-Rq-Timeout-Ms:[600000] X-Envoy-Internal:[true] X-Forwarded-Client-Cert:[By=spiffe://cluster.local/ns/istioinaction/sa/default;Hash=491c5bf23be281a5c0c2e798eba242461dfdb7b178d4a4cd842f9eedb05ae47d;Subject="";URI=spiffe://cluster.local/ns/istioinaction/sa/webapp] X-Forwarded-For:[10.10.0.20] X-Forwarded-Proto:[https] X-Request-Id:[964138e3-d955-97c9-b9a5-dfc88cc7f9c5]], body: []
# 헤더 적용 호출
kubectl -n default exec -it deploy/sleep -- curl -H "x-ext-authz: allow" webapp.istioinaction/api/catalog
kubectl logs -n istioinaction -l app=webapp -c istio-proxy -f
2025-05-04T08:37:40.618775Z debug envoy rbac external/envoy/source/extensions/filters/http/rbac/rbac_filter.cc:114 checking request: requestedServerName: , sourceIP: 10.10.0.18:36150, directRemoteIP: 10.10.0.18:36150, remoteIP: 10.10.0.18:36150,localAddress: 10.10.0.20:8080, ssl: none, headers: ':authority', 'webapp.istioinaction'
':path', '/api/catalog'
':method', 'GET'
':scheme', 'http'
'user-agent', 'curl/8.5.0'
'accept', '*/*'
'x-ext-authz', 'allow'
'x-forwarded-proto', 'http'
'x-request-id', 'b446ddf8-fb2e-9dd7-ba01-6e31fac717da'
, dynamicMetadata: thread=30
2025-05-04T08:37:40.618804Z debug envoy rbac external/envoy/source/extensions/filters/http/rbac/rbac_filter.cc:130 shadow denied, matched policy istio-ext-authz-ns[istioinaction]-policy[ext-authz]-rule[0] thread=30
2025-05-04T08:37:40.618816Z debug envoy rbac external/envoy/source/extensions/filters/http/rbac/rbac_filter.cc:167 no engine, allowed by default thread=30
[2025-05-04T08:37:40.622Z] "GET /items HTTP/1.1" 200 - via_upstream - "-" 0 502 2 2 "-" "beegoServer" "b446ddf8-fb2e-9dd7-ba01-6e31fac717da" "catalog.istioinaction:80" "10.10.0.19:3000" outbound|80||catalog.istioinaction.svc.cluster.local 10.10.0.20:60848 10.200.1.165:80 10.10.0.20:45874 - default
[2025-05-04T08:37:40.618Z] "GET /api/catalog HTTP/1.1" 200 - via_upstream - "-" 0 357 6 4 "-" "curl/8.5.0" "b446ddf8-fb2e-9dd7-ba01-6e31fac717da" "webapp.istioinaction" "10.10.0.20:8080" inbound|8080|| 127.0.0.6:43721 10.10.0.20:8080 10.10.0.18:36150 - default
kubectl logs -n istioinaction -l app=ext-authz -c ext-authz -f
2025/05/04 08:36:34 [HTTP][allowed]: GET webapp.istioinaction/api/catalog, headers: map[Content-Length:[0] X-B3-Parentspanid:[f9bc85c800aaaa05] X-B3-Sampled:[1] X-B3-Spanid:[bf6cc58161f7ca25] X-B3-Traceid:[af1c826a362ce0382e219cd21afe1fe7] X-Envoy-Expected-Rq-Timeout-Ms:[600000] X-Envoy-Internal:[true] X-Ext-Authz:[allow] X-Forwarded-Client-Cert:[By=spiffe://cluster.local/ns/istioinaction/sa/default;Hash=491c5bf23be281a5c0c2e798eba242461dfdb7b178d4a4cd842f9eedb05ae47d;Subject="";URI=spiffe://cluster.local/ns/istioinaction/sa/webapp] X-Forwarded-For:[10.10.0.20] X-Forwarded-Proto:[https] X-Request-Id:[c9b43ce7-25d4-94ae-b684-1565ad36f533]], body: [][ Summary ]
더보기
- PeerAuthentication 은 피어 간 인증을 정의하는 데 사용하며, 엄격한 인증 요구 사항을 적용하면 트래픽이 암호화돼 도청할 수 없다.
- PERMISSIVE 정책은 이스티오 워크로드가 암호화된 트래픽과 평문 트래픽을 모두 수용할 수 있게 해서 다운타임 없이 천천히 마이그레이션할 수 있도록 해준다.
- AuthorizationPolicy 는 워크로드 ID 인증서나 최종 사용자 JWT에서 추출한 검증 가능한 메타데이터를 근거로 서비스 사이의 요청이나 최종 사용자의 요청을 인가(허용, 차단)하는 데 사용한다.
- RequestAuthentication 은 JWT가 포함된 최종 사용자 요청을 인증하는 데 사용한다.
- AuthorizationPolicy 에서 CUSTOM action을 사용하면 외부 인가 서비스를 통합할 수 있다.
[ 중요 - 실습 후 자원정리 ]
## 1. cluster 삭제
kind delete cluster --name myk8s
## 2. /etc/hosts 파일에 추가했던 도메인 제거
vi /etc/hosts[ 참고 링크 모음 ]
더보기
☞ 생활코딩 What is JWT : Youtube
☞ JWT 대충 쓰면 님들 코딩인생 끝남 (코딩애플) : Youtube
☞ 기타 주요 사례 및 기본 지식 링
- Introducing the Istio v1beta1 Authorization Policy - Blog
- 토스ㅣSLASH 23 - 고객 불안을 0으로 만드는 토스의 Istio Zero Trust - Link , PDF*
- 토스ㅣSLASH 22 - 은행 앱에도 Service Mesh 도입이 가능한가요? - Link , PDF*
- *Istio Authentication & Authorization https://bluehorn07.github.io/2024/03/14/istio-authentication-and-authorization/*
- *Istio TLS 관련 사전 지식 https://bluehorn07.github.io/2024/02/24/istio-pre-requisites-tls-network/*
- *Istio Security https://bluehorn07.github.io/2024/03/03/istio-security/*
- *Istio Internals: xDS https://www.anyflow.net/sw-engineer/istio-internals-by-xds*
- *Istio overview: Security https://www.anyflow.net/sw-engineer/istio-overview-3*
☞ Ubuntu 24.04 에 jwt 설치 https://lindevs.com/install-jwt-cli-on-ubuntu
☞ Configure a Pod to Use a Projected Volume for Storage
https://kubernetes.io/blog/2019/03/21/a-guide-to-kubernetes-admission-controllers/
[ 도전과제 모음 ]
더보기
도전과제1 Istio 1.17 공식 문서에 ‘Security’ 와 ‘Security Best Practices’ 내용 정리
도전과제2 Istio 1.17 공식 문서에 ‘Authentication’ 내용들 정리 - Docs
도전과제3 Istio 1.17 공식 문서에 ‘Authorization’ 내용들 정리 - Docs
도전과제4 Istio 1.17 공식 문서에 ‘SPIRE’ 내용 정리 - Docs
도전과제5 Istio 1.17 공식 문서에 인증/인가 관련 Reference 내용들 정리 - Docs
- PeerAuthentication - Docs
- Authorization Policy - Docs
- Authorization Policy Conditions - Docs
- Authorization Policy Normalization - Docs
- RequestAuthentication - Docs
- JWTRule - Docs
도전과제6 Istio 에 JWT 를 KeyCloak 연동 설정 해보기 - Blog , 악분님 , keycloak(old)
'ISTIO' 카테고리의 다른 글
| ISTIO 4주차 - Observability (0) | 2025.04.28 |
|---|---|
| Istio-3주차 Istio Traffic 제어 및 복원력 (0) | 2025.04.19 |
| Istio 2주차 - Envoy, Istio Gateway (0) | 2025.04.14 |
| Istio 1주차 - Istio 소개, 첫걸음 (0) | 2025.04.07 |
'ISTIO' Related Articles
more
