Service Mesh (5) - Security

☁️ 클클 5기 시즌 1 스터디 : 90DaysOfDevOps 레포지토리를 바탕으로 공부합니다!

 

🧩 82 > Securing your microservices

90DaysOfDevOps/2023/day82.md at main · MichaelCade/90DaysOfDevOps

 

Day82. Securing your microservices

요즘 또 DevSecOps라는 말이 나오면서 보안과 관련된 문제가 중요하게 떠오르고 있는데요?

이쯤에서 잠깐 다시 복습하자면, 서비스 메시는! MSA가 굴린 스노우볼!! 

 

monolithic이라면 하나 안에서 지지고 볶고 하면 문제가 없지만??

MSA에서는 수천 개의 서비스들이 있는데, 결국 이들끼리는 '네트워크'를 통해서 통신을 해야 합니다!

 

그거, 믿을 수 있으세요????????

---

서비스 메시에서 다루는 보안 문제 종류

• Identity
• Policy
• Authorization
• Authentication
• Encrpytion
• Data Loss Prevention

서비스 메시에서 보안 문제 해결하는 방법

• SideCar, Ingress Gateway, 노드 수준 proxy, k8s 계층과 상호작용 하는 service mesh control plane
• 정책, 인증 구성을 Istio control plane에서 할 수 있다 → k8s API에 제공해서 팟과 다른 리소스에 대한 런타임 구성
• k8s CNI 레이어 → 제한된 양의 네트워크 정책 및 암호화 제공
• 서비스 메시 암호화 → 서비스 간 통신을 위한 mutual-TLS(mTLS)
• SPIFFE(Secure Production Identity Framework For Everyone) ID 형식의 강력한 identity 사용하여 인증 제공
• Layer 7 Authorization→ 특정 서비스에 권한을 부여하여 다른 서비스에 대해 작업(HTTP) 수행

무슨 소리인지 정말 모르겠으니, 일단 이런 게 있구나~ 하고 넘어가보자! 뒤에 실습을 하면 조금씩 이해가 간다..!

---

📍Istio Peer AuthN and mTLS

• 메시에 배포된 workload 대한 identify를 발급하고 관리하는 게 중요
• Istio에서는 모든 서비스에 SideCar가 있고 Istiod Control Plane으로부터 identify를 발급받았다면, 서비스를 신뢰하고 검증할 능력이 있다, 즉, Peer AuthN이 mTLS를 사용해서 달성될 수 있다
• Istio에서 Peer AuthN은 서비스에 대해서 구성되어야 하고 워크로드, 네임스페이스, 전체 메시로 범위를 지정할 수 있다.
• Peer AuthN에는 3가지 모드가 있다
  • `PERMISSIVE` (Default) : plain text와 mTLS 둘 다 가능
  • `STRICT` : mTLS 가능한 워크로드만
  • `DISABLE` : mTLS 불가능
• End-user Auth를 JWT(JSON Web Tokens) 사용해서 할 수도 있다

---

이론 모르겠으니 일단 직접 해보자!

🍀 (2)부터 했었던 bookinfo sample 실습 환경을 계속 이어서 진행합니다!

1. 사이드카가 없는 다른 샘플 앱 배포 

kubectl create ns sleep
kubectl get ns

• Output : Service Account, Service, Deployment 생성

---

2. Sleep pod이 bookinfo 앱과 통신할 수 있는지 테스트

→ sleep namespace에서 app=sleep 라벨이 있는 sleep pod에서 default namespace에 있는 productpage에 curl

kubectl exec "$(kubectl get pod -l app=sleep -n sleep -o jsonpath={.items..metadata.name})" -c sleep -n sleep -- curl productpage.default.svc.cluster.local:9080 -s -o /dev/null -w "%{http_code}\\n"

• Output : 200→ OK 성공했다는 의미 (Default는 `PERMISSIVE` 이기 때문)

---

3. Peer AuthN 적용

spec 필드의 mtls에 `STRICT` mode라고 명시해두었다 → mTLS가 아닌 모든 경우 비허용

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

• Output : `peerauthentication.security.istio.io/default created`

---

4. 다시 2번 테스트 반복

Output : 실패!!

 

→ STRICT 모드의 Peer AuthN이 mTLS 워크로드와 통신할 때 mTLS가 아니면 비허용 한다.

---

📍 Istio Layer 7 AuthZ

• AuthZ → 다른 리소스에 대해 어떤 작업을 수행할 수 있는 사람을 세부적으로 제어                                                                           e.g ) 한 서비스가 다른 서비스에 대해 수행할 수 있는 HTTP 작업은?                                                                                                   ( GET을 할 수 있는지, GET은 가능하고 DELETE는 불가능하게 → zero-trust)

• Kiali(전에 그래프 뷰로 모니터링 했던 도구) 같은 도구를 사용해서 service mapping을 만들고 서비스 간 다양한 HTTP 이해 가능
• 사이드카로서 Envoy(Istio용 Proxyv2)가 모든 AuthZ 정책에 대한 정책 적용 지점이다.
  • 정책은 런타임에 요청 승인을 해주는 AuthZ 엔진에 의해 평가받는다.
  • 대상이 되는 사이드카(=Envoy)가 이걸 평가할 책임이 있다.

---

마찬가지로 일단 해보자

 

1. 모든 HTTP 기반 동작을 막기

kubectl apply -f - <<EOF
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: allow-nothing
  namespace: default
spec:
  {}
EOF

• Output : `authorizationpolicy.security.istio.io/allow-nothing created`
• 확인 : 위에서와 같이 sleep Pod에 접근해보자

kubectl exec "$(kubectl get pod -l app=sleep -o jsonpath={.items..metadata.name})" -c sleep  -- curl productpage.default.svc.cluster.local:9080 -s -o /dev/null -w "%{http_code}\\n"

• Output : `403` (= Forbidden...or Not Authorized) *원래 `200`(=OK)으로 나왔었다

---

2. 서비스 정책 지정

서비스↔ 서비스 통신을 허용하기 위해서 리퀘스트 경로에서 서비스의 정책을 적용해주자

다음 4개에서 AuthZ 정책을 지정해줘야 한다(위에 그림에서 자물쇠 있는 화살표들)
1. User client to product page.
2. From Product Page to Details
3. From product-page to reviews
4. From reviews to ratings

👉🏻 AuthZ 정책 구성 요소
- `apiVersion` : 이게 Istio 리소스/CRD(CustomResourceDefinitions)임을 명시
- `spec` : 어느 리소스가 HTTP 요청 인바운드를 받고, 메소드(e.g GET)는 무엇인지
        - `action` : 위 리소스에서 발생할 수 있는 동작 (ALLOW)

 

kubectl apply -f - <<EOF
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: "get-productpage"
  namespace: default
spec:
  selector:
    matchLabels:
      app: productpage # product page인 서비스에 접근하는 것에 대해서
  action: ALLOW # 허용한다
  rules:
  - to:
    - operation:
        methods: ["GET"] # GET만 
EOF

 

→ 외부 클라이언트가 Product-page에 대해 HTTP GET만 가능하도록 해준다 (나머지는 거절)

• Output : `authorizationpolicy.security.istio.io/get-productpage created`

직접 외부에서 `localhost/productpage`로 접근해서 확인해보자! → curl로 하면 200(=OK)으로 나오게 된다

• BUT 웹 브라우저로 접속해보면 아직 Details와 Reviews에 대해서는 불가능하기 때문에 불러오지 못 하는 것을 확인할 수 있다!

---

이제 위에서 말한 나머지 3개도 차례 차례 허용해보자

3. Productpage → Reviews Get 허용

product-page가 reviews 서비스로부터 HTTP GET 하는 걸 허용해보자

kubectl apply -f - <<EOF
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: "get-reviews"
  namespace: default
spec:
  selector:
    matchLabels:
      app: reviews
  action: ALLOW
  rules:
  - from:
    - source:
        principals: ["cluster.local/ns/default/sa/bookinfo-productpage"]
    to:
    - operation:
        methods: ["GET"]
EOF

• `rules` : principal을 통해서 요청의 source를 명시해준다. → bookinfo-productpage의 service account를 해준다
• output : `authorizationpolicy.security.istio.io/get-reviews created`

---

4. Reviews → Ratings GET 허용

마찬가지로 reviews가 ratings로부터 데이터를 얻어오는 것을 허용하는 정책을 적용해보자

kubectl apply -f - <<EOF
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: "get-ratings"
  namespace: default
spec:
  selector:
    matchLabels:
      app: ratings
  action: ALLOW
  rules:
  - from:
    - source:
        principals: ["cluster.local/ns/default/sa/bookinfo-reviews"]
    to:
    - operation:
        methods: ["GET"]
EOF

• output : `authorizationpolicy.security.istio.io/get-ratings created`

---

5. Product → Details GET 허용

마지막으로 productpage가 details로부터 데이터를 얻어오는 것을 허용하는 정책을 적용해보자

kubectl apply -f - <<EOF
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: "get-details"
  namespace: default
spec:
  selector:
    matchLabels:
      app: details
  action: ALLOW
  rules:
  - from:
    - source:
        principals: ["cluster.local/ns/default/sa/bookinfo-productpage"]
    to:
    - operation:
        methods: ["GET"]
EOF

• output : `authorizationpolicy.security.istio.io/get-details created`

---

6. 결과 확인

localhost/productpage에 다시 들어가면, 이제는 Details와 Reviews와 Ratings 모두 잘 보이는 것을 확인할 수 있다!

 

---

🍀 추천 영상

만약 위 실습을 다 했다면 이 영상을 보시는 걸 추천드립니다! 원래 라면 0% 알아 들을 내용을 20% 정도는 이해할 수 있게 됩니다! 앞부분에 mTLS 관련 설명도 있어서 좋은 것 같아요~

https://youtu.be/4sJd6PIkP_s?si=IWbBRCfBICkkx8WP