istio 관련 포스팅 작성 중

pages/msa/add-jwt-verification-proxy-to-istio.mdx

@@ -44,14 +44,21 @@ istiod-8454df4fbb-7z8xz                 1/1     Running   0          2m
 ## RequestAuthentication 와 AuthorizationPolicy 셋팅하기
 
 
+`RequestAuthentication`: 들어오는 요청의 JWT 토큰을 검증하고, 성공 시 “인증 정보(principal/claims)”를 Istio 내부에 전달
+
+`AuthorizationPolicy`: 검증된 “인증 정보”를 토대로, 요청을 허용(allow)하거나 거부(deny)
+
+
 ### RequestAuthentication 란?
 
 **RequestAuthentication**은 HTTP 요청에서 JWT 검증을 수행하기 위한 리소스.
-jwt를 검증하여 유효하지 않을 경우 요청을 거절시키는 역할을 한다
-단순 jwt 검증만 할거라면 사실 이것만 있으면 됨
-
-exp 와 시그니처가 검증에 쓰인다 
+기본적으로 `Authorization` 헤더에 붙어오는 jwt 를 검증하며, 검증 결과 유효하지 않은 jwt일 경우 거절한다.
+`Authorization` 헤더가 없을 경우 검증 자체를 생략하여 요청을 그냥 패스시켜버린다
+`Authorization` 헤더가 없는 요청에 대한 거절은 아래 나올 `AuthorizationPolicy` 를 이용해야한다
 
+검증 항목
+- `exp`
+- `시그니처`
 
 ```yaml filename="requestAuthentication-yaml "
 apiVersion: security.istio.io/v1
@@ -411,9 +418,69 @@ spec:
 ```
 
 
+## 인증이 불필요한 API 요청은 JWT 검증 패스시키기
+
+JWT 검증 필요없이 요청할 수 있는 public 한 API 가 있을 수 있다
+그러면 istio에서 해당 API 에 대한 요청이면 JWT 검증을 패스시키는 기능이 필요하다
+
+### RequestAuthentication 만 설정되어 있는 경우
 
+그냥 Authorization 헤더 없이 요청을 보내면 검증 자체를 패스해버린다
+
+### RequestAuthentication + AuthorizationPolicy 로 설정되어 있는 경우
+
+대부분 이 방식을 사용할 것이다
+
+`RequestAuthentication` 의 경우 그냥 `Authorization` 헤더 없이 요청을 보내면 검증 자체를 패스해버린다
+
+그러면 남은건 `AuthorizationPolicy` 인데
+
+```yaml filename="authorization-policy.yaml"
+apiVersion: security.istio.io/v1
+kind: AuthorizationPolicy
+metadata:
+  name: jwt-authz-policy
+  namespace: istio-test
+spec:
+  selector:
+    matchLabels:
+      app: my-server
+  rules:
+      - to:
+        - operation:
+            paths: ["/hello"]
 ```
 
+위와 같이 to.operation.paths 만 지정하면 그냥 통과다,
+만약 유효하지 않은 jwt를 보냈을 경우 `거절` 하고 싶으면 아래와 같이 `from.source.requestPrincipals` 를 같이 지정해야한다
+
+```yaml filename="authorization-policy.yaml"
+apiVersion: security.istio.io/v1
+kind: AuthorizationPolicy
+metadata:
+  name: jwt-authz-policy
+  namespace: istio-test
+spec:
+  selector:
+    matchLabels:
+      app: my-server
+  rules:
+    - from:
+        - source:
+            requestPrincipals: ["*"] 
+      to:
+        - operation:
+            paths: ["/hello"]
+```
+
+
+
+
+
+
+
+
+
 
 
 

pages/msa/istio-grpc-path-based-jwt-authentication-or-authentication-exception-handling-method.mdx

@@ -3,6 +3,9 @@
 istio 가 서비스 메시로 동작하는 환경에서 grpc 통신을 사용할 경우, public api같이 일부 api들은 jwt 인증을 예외처리할 필요가 있다
 단순 rest api 였으면 그냥 path 기반으로 하면된는데 grpc는 어떻게 할 수 있는지 알아보자
 
+
+
+
 ## path 기반 예외
 
 grpc 에서도 path 기반 예외가 유효하다
@@ -79,7 +82,6 @@ spec:
             paths: ["/Greeter/SayHello"]
 ```
 
-## 
 
 
 

pages/msa/istio-proxy-ssl.mdx

@@ -1,6 +1,48 @@
+import { Callout } from "nextra/components";
+
 #  istio 에서 ssl/tls 통신
 
-istio 외부 -> istio 내부 : ingress gateway 사용
-istio 내부 -> istio 내부 : 사이드카 프록시(envoy) 사용
+## istio 외부 -> istio 내부
+
+- ingress gateway 사용
+
+---
+
+## istio 내부 -> istio 내부
+
+- 사이드카 프록시(envoy) 사용
+- Istio에서 mTLS가 활성화된 상태라면, 애플리케이션(서비스 A, B) 입장에서 일반 gRPC 호출을 하더라도 사이드카 프록시(Envoy)가 통신 구간을 자동으로 TLS로 암호화해줌
+
+
+### PeerAuthentication 를 이용한 특정 namespace 내의 모든 서비스에 ssl/tls 지정
+
+네임스페이스 내의 모든 서비스에 대해 mTLS 모드를 `STRICT`로 설정
+
+  <Callout type="info" emoji="🧑🏻‍💻">
+  **mTLS란?**
+
+      양방향 TLS 통신,
+      우리가 보통 사용하는 HTTPS 의 경우 단방향 TLS로, Client만 인증서 검증을 진행하는데 mTLS는 양쪽 다 인증서 검증을 진행한다
+  </Callout>
+
+
+```yml filename="SamplePeerAuthentication.yml"
+apiVersion: security.istio.io/v1
+kind: PeerAuthentication
+metadata:
+  name: ssl-test-policy
+  namespace: istio-test
+spec:
+  mtls:
+    mode: STRICT
+```
+
+**STRICT** : 서비스 간 통신 시 반드시 mTLS를 사용한다는 의미
+
+### namespace-level vs mesh-level
+
+**namespace-level 설정:** 위 예시처럼 특정 네임스페이스에만 적용할 수도 있음
+
+**mesh-level 설정:** PeerAuthentication 리소스를 `istio-system` 네임스페이스에 `name: default`로 생성하면, 전체 mesh에 적용할 수도 있음