[Azure] SSL/TLS End-to-End (feat Service Mesh)

목차

1. 서비스 메시 개요
2. mTLS(Mutual Transport Layer Security)
3. 적용 시나리오

---

아키텍처

SSL/TLS End-to-End

 

---

1. 서비스 메시 개요

https://qiita.com/ishishow/items/401629972bea46c680f6

 

기본적으로 일반 쿠버네티스를 구성해보면 일반적인 MSA 아키텍처는 왼쪽 이미지와 흡사하다.

그냥 단순 내부 포드끼리의 통신은 kube-proxy를 통해 이루어지는 상태.

 

하지만 서비스 규모의 크기가 작으면 상관없지만 규모가 커지게 되면 포드의 수가 늘어나고 관리 포인트가 늘어나게됨에 따라 운영하는데 있어 부담이 커지게 된다.

 

mTLS , retries/failover, observability, routing decisions 등 트래픽 관리에 있어서 설정되어있는것이 하나도 없다 보니 이런 상태로 서비스 규모가 커지게 되면 나중에 포드마다 일일히 설정해줘야기 때문에 운영이 복잡해진다.

 

그래서 나온 개념이 서비스 메시이다.

여기서 사이드카(Sidecar)라는 개념이 등장하게 되는데 사이드카는 서비스 옆단에 보조컨테이너로 붙어서 서비스가 통신하는걸 사이드카가 대신 통신해줄 수 있는 프록시 형태의 개념이다.

 

즉 사이드카를 기준으로 네트워크 구성이 이루어져있다 보니 상호양방향 암호화 통신인 mTLS, 라우팅 분기, observability 등에 대한 설정이 굉장히 쉬워지는것이다.

 

---

2. mTLS (Mutual Transport Layer Security)

서비스 메시를 적용하게 되면 여러가지 이점이 있지만 현재 아키텍처 구성에 있어서는 암호화가 주 목적이다 보니 mTLS만 살펴보도록 하겠다.

 

https://api7.ai/ko/blog/what-is-service-mesh

  

MSA 아키텍처를 구성하게 되면 엔지니어들은 공용 퍼블릭에 노출된 서비스에만 보안을 신경쓰는 경향이 있다.

클러스터 내부망에 대한 보안을 간과하는 경우가 있는데 이렇게 되면 포드끼리의 통신들은 모두 평문화 통신으로 이루어지기 때문에 MITM 즉 중간자 공격에 굉장히 취약할 수밖에 없다.

 

그래서 서비스 메시의 상호 양방향 암호화 통신인 mTLS를 적용하여 MITM 공격을 사전 예방할 수 있다.

그리고 이런 mTLS는 사이드카만 구현하게 되면 직접 mTLS를 구현할 필요 없이 사이드카 프록시가 자동으로 인증서 교환과 암호화 처리를 해주게 된다.

 

또한 인증서 관리도 istio 같은 컨트롤 플레인이 다 해주다 보니 운영 부담이 감소하는 효과도 있다.

 

---

3. 적용 시나리오

먼저 서비스 메시 부분도 살펴보겠다.

먼저 AKS를 통해 쿠버네티스를 설치 했고, Azure 포탈에서 istio add-on 을 통해 손쉽게 설치하였다.

kubectl create namespace mesh-ns # mesh-ns라는 네임스페이스 생성
kubectl label ns mesh-ns istio-injection- istio.io/rev=asm-1-25 --overwrite # 사이드카 자동 주입 라벨 추가
kubectl get namespace mesh-ns --show-labels

 

먼저 사이드카 라벨을 붙혀줄 네임스페이스를 생성한다.

여기서 원래라면 일반적으로 istio-injection=enable 이라는 라벨을 추가하지만 istio를 add-on으로 설치했다 보니 리비전 기반으로 작동한다.

 

리비전이란? 

• 여러개의 istio 버전을 동시 운영할 수 있는 식별자 같은 개념
• istio 리비전 라벨을 교체해서 네임스페이스 단위로 점진적으로 업데이트 할 수 있음

즉 리비전의 대한 라벨을 붙혀줘야 한다.

namespace에 붙은 리비전 라벨

그리고 이렇게 리비전 라벨이 붙은 네임스페이스에 포드를 생성하면 자동으로 istio-proxy라는 사이트카가 붙는다.

 

 

이제 통신하는 일만 남았지만 한 가지 더 알아야할 것은 mTLS에 대한 mode이다.

PeerAuthentication은 상호 양방향 암호화통신에 대한 규칙을 지정해 줄 수 있는 부분인데 모드게 총 3개가 있다.

 

• PERMISSIVE : mTLS를 지원하되, 평문 트래픽도 허용
• STRICT : 반드시 mTLS만 허용 (사이드카가 없는 Pod는 차단)
• DISABLE : 암호화 안함

* 본인은 직접 암호화 통신을 하는지 테스트 해봐야 하기 떄문에 강제로 mTLS 통신이 되는 STRICT 모드로 진행하였다.

 

mesh-ns 안에 nginx 서비스를 올린 상태

 

nginx 서비스를 올려서 FQDN인 http://nginx.mesh-ns.svc.cluster.local/ 을 통해 통신을 해보겠다.

 

테스트

• kubectl -n mesh-ns exec -it curl-mesh -c curl -- \ curl -sS http://nginx.mesh-ns.svc.cluster.local​
• kubectl -n plain-ns exec -it curl-plain -c curl -- \ curl -v --max-time 5 http://nginx.mesh-ns.svc.cluster.local​

첫 번째 명령어는 istio 라벨이 있는 curl-mesh 포드로 통신하는 것이고, 두 번째 명령어는 curl-plain 포드로 통신하는 것이다.

둘의 차이점을 비교해보겠다.

 

curl-mesh 포드와 curl-plain 포드 통신 비교

 

예상한대로 왼쪽 이미지는 curl-mesh 포드로 통신한 결과이다.

successfully 메시지가 뜨면서 통신이 정상적으로 이루어진 반면 사이드카가 없는 curl-plain 포드로 통신한 결과는 오른쪽 이미지 처럼 TLS 세션이 끊킨 것을 확인 해볼수 있다.

 

이제 Ingress 부분을 살펴보겠다.

istio의 네임스페이스

istio 포드

istio ingress 서비스

 

네임스페이스, 포드, 서비스를 조회해보면 알겠지만 istio-add-on을 설치하게 되면 이렇게 자동으로 만들어진다.

그래서 ingress 서비스에 보이는 EXTERNAM_IP를 통해 Application Gateway에서 백엔드 요청으로 보낼 수 있다.

 

 

ingress 규칙

 

외부에서 내부로 들어오는 ingress에 대한 규칙을 지정해 준 것이다.

아키텍처가 자체가 SSL/TLS End-to-End로 구성이되어있어서 모든 구간이 암호화가 되어있다.

 

즉 AG에서 백엔드로 가는 내부 통신 또한 암호화가 되어있다 보니 백엔드 ingress 부분에서 인증서를 보내주어야 한다.

그래서 어떤 호스트로 왔고 그 호스트에 대한 인증서를 검증해주는 부분인 것이다.

그 밑에 버추얼 호스트는 그렇게 허용된 트래픽을 어느 포드 서비스로 보낼지에 대한 규칙이다.

 

이제 AG 부분을 건드려줘야 하는데 AG의 수신기에 대한 부분에 인증서를 적용해줘야 한다.

Let's Encrypt 공인 CA로 발급하여서 PFX 로 변환하여 업로드 하면 된다.

프론트로 노출되는 부분이기 때문에 공인 CA기관에서 발급해야 한다.

 

백엔드 설정 부분인데 공인 CA인 경우에는 그냥 '예' 로만 하면 되지만 본인은 Openssl로 사설 CA로 발급받았기 때문에 따로 인증서를 CER로 변환해주어서 업로드 해주었다.

 

AG에서 백엔드로 가는 요청은 내부 통신이기 때문에 굳이 공인 CA로 발급할 필요가 없다.

 

상태 프로브

* 주의

• 프로브 테스트는 FQDN 도메인으로 할 것
• 백엔드 풀은 Ingress External ip로 설정

---

결과

 

SSL 통신으로 잘 접속되는걸 확인 할 수 있다.

 

---

추가

비용으로 인해 중간에 구독이 끊켜 AG 리소스가 Stop이 될 수 있음.

그럴땐 직접 AG를 Start 해줘야 함

 

원래 표준 v2 Scope 에서는 Always Running 설계 됐고, stop/start 기능도 추가됐지만 풀 매니지드 API 기능으로만 먼저 열려 있어서 CLI로 작업해줘야 한다.

 

az network application-gateway show \
  -g open_sessions -n ag-mesh \
  --query "{prov:provisioningState,op:operationalState}"

 

이렇게 확인 해보면 

{
  "op": "Stopped",
  "prov": "Succeeded"
}

 

이렇게 뜨지만,

 

az network application-gateway start \
  --resource-group open_sessions \
  --name ag-mesh

 

이렇게 start 명령어를 통해 실행시켜주면 

{
  "op": "Running",
  "prov": "Succeeded"
}

 

이렇게 실행이 되는걸 확인할 수 있다.

이로써 다시 AG 리소스를 통해 백엔드 서버로 접속이 가능해진다.