istio other crd

_posts/development/istio/2024-03-14-istio-authentication-and-authorization.md

@@ -4,16 +4,16 @@ toc: true
 toc_sticky: true
 categories: ["Kubernetes", "Istio"]
 excerpt: "Auth와 Authz를 istio 인프라 레벨에서 구현하기!"
-last_modified_at: 2024-03-15
+last_modified_at: 2024-03-23
 ---
 
 ![](/images/meme/dump-head.png){: .align-center style="max-width: 400px" }
 
-istio를 사용하면 Authentication과 Authorization을 Envoy Proxy 레벨에서 수행할 수 있다. 이건 Auth & Authz 로직을 어플리케이션에서 구현이 없어도 워크로드를 보호할 수 있도록 하는 기능 같다!!
+istio를 사용하면 Authentication과 Authorization을 Envoy Proxy 레벨에서 수행할 수 있다. 이건 AuthN & AuthZ 로직을 어플리케이션에서 구현이 없어도 워크로드를 보호할 수 있도록 하는 기능 같다!!
 
 # 사전 준비: helloworld 예제
 
-Istio 예제로 제공되는 helloworld 예제를 활용해서 Istio의 Auth&Authz을 검증해보자. 자세한 예제는 이전에 적어둔 [Istio 'helloworld' 데모](https://bluehorn07.github.io/2024/02/05/istio-helloworld-demo/) 포스트에서 확인할 수 있다.
+Istio 예제로 제공되는 helloworld 예제를 활용해서 Istio의 AuthN&AuthZ을 검증해보자. 자세한 예제는 이전에 적어둔 [Istio 'helloworld' 데모](https://bluehorn07.github.io/2024/02/05/istio-helloworld-demo/) 포스트에서 확인할 수 있다.
 
 일단 위의 명령어로 워크로드를 띄우고
 
@@ -72,10 +72,13 @@ spec:
   rules:
   - from:
     - source:
+       # format: issuer/subject
        requestPrincipals: ["[email protected]/[email protected]"]
 EOF
 ```
 
+이때 "issuer"는 토큰을 발급한 주체(인증서버), "subject"는 토큰을 발급받은 주체(사용자, 서비스계정)을 표현한다.
+
 ## JWT 실어서 요청 보내기 
 
 `RequestAuthentication`과 `AuthorizationPolicy` 리소스를 추가하고 난 뒤에 요청을 보내면, 아래와 같이 요청이 거부 된다.

_posts/development/istio/2024-03-22-istio-memo-collections.md

@@ -54,6 +54,9 @@ https://istio.io/latest/docs/reference/config/networking/virtual-service/
 - Retry Policy 세팅 가능
   - ???: 삼세번은 봐준다
   - `DR`에는 outlier detection이 있다.
+- Fault Injection
+  - delay
+  - abort
 - CORS Policy 세팅 가능
 
 하지만 모두 K8s Service로 존재하는 워크로드, 또는 엔드포인트가 명확한 타깃(`naver.com`)을 대상으로만 할 수 있다.
@@ -127,7 +130,7 @@ spec:
         host: productpage.nsA.svc.cluster.local
 ```
 
-# 동일 host에 2개 VirtualService가 있는 경우
+## 동일 host에 2개 VirtualService가 있는 경우
 
 ```yaml
 # duplicate-host-vs.yaml
@@ -193,7 +196,8 @@ Envoy에 `gRPC` Access Log를 활성화 하려면 켜는 옵션이라고 한다.
 Istio 메쉬 전체에 트래픽 규칙을 적용하는게 가능하다!! 아래 리소스들을 istio 메쉬의 root namespace, 보통 `istio-system`에 생성하면 메쉬의 모든 워크로드에 해당 규칙이 적용된다!
 
 - `DestinationRule`
-- ...
+- `EnvoyFilter`
+- `ProxyConfig`
 
 이때, 리소스를 사용하는 순서는 보통 워크로드가 떠있는 곳의 네임스페이스에 존재하는 Istio 리소스스를 먼저 확인하고, 그게 없으면 root ns의 Istio 리소스를 보게 된다고 한다.
 
@@ -239,6 +243,18 @@ root 네임스페이스에 정의한 DR과 워크로드 네임스페이스에 
 
 TODO: ...
 
+# Merged Prometheus telemetry
+
+https://istio.io/latest/docs/ops/integrations/prometheus/#option-1-metrics-merging
+
+Istio의 Envoy Proxy들은 그들의 metric을 프로메테우스 metric 형식으로 노출함. Envoy Proxy의 메트릭은 Pod의 `15090` 포트로 노출됨.
+
+그런데 어떤 Pod들은 isito proxy를 도입하기 이전부터 자체적으로 Prometheus 메트릭을 노출하고 있었을 수도 있음. 그렇게 되면, istio proxy의 메트릭도 노출되고 App이 원래 노출하던 메트릭도 같이 있게 됨. (이렇게 되면 뭔가 간섭이 있나봄??)
+
+그래서 istio는 친절하게도(?) 기존 App이 노출하는 프로메테우스 메트릭이 있다면 그걸 병합(merge)해서 "merged prometheus telemtry"의 포트인 `15020`에 쏴준다고 함.
+
+이렇게 두 프메 메트릭을 병합하는 옵션은 IstioOp를 설치할 때 `meshConfig.enablePrometheusMerge` 옵션에 의해 설정되는데, 기본값이 `true`라서 Istio proxsy가 주입되었다면 기존 App 메트릭이 병합되게 될 것임. 그리고 위의 옵션에 따라 istio proxy가 주입된 Pod은 프메 Scrape을 위한 `prometheus.io/xxx` annot이 이것저것 붙게 된다고 함. 만약, 기존에 이미 `prometheus.io/xxx` annot이 있었다면 overwrite 됨.... ㅋㅋ
+
 # Istio Ingress Controller
 
 https://istio.io/latest/docs/tasks/traffic-management/ingress/kubernetes-ingress/
@@ -282,6 +298,27 @@ K8s Gateway API를 사용할 때, istio 리소스를 어떻게 호환 시켜야
 
 TODO: 요건 아직 K8s 표준 API가 아닌 것 같아서 ICA 시험에 안 나올 것 같음 ㅋㅋㅋ 나중에 다시 찾아보는 걸로!
 
+# Istio Reserved Ports
+
+https://istio.io/latest/docs/ops/deployment/requirements/
+
+외부로 직접 노출된 port만 적음. internal port는 생략! 대부분이 `150xx` 포트임.
+
+## Envoy Proxy
+
+- `15001`: Envoy outbound
+- `15006`: Envoy inbound
+- `15021`: Health checks
+- `15020`: Merged Prometheus telemetry from Istio agent, Envoy, and application	
+  - 왜 프메 메트릭을 병합(?)한 포트가 있는지는 요 포스트의 위쪽에 문단에 적어둠!
+- `15090`: Envoy Prometheus telemetry	
+
+## Istiod
+
+- `15014`: Control plane monitoring
+- `15017`: Webhook container port
+- `15010`, `15012`: XDS and CA services
+
 # Istio ControlZ
 
 ![](https://istio.io/latest/docs/ops/diagnostic-tools/controlz/ctrlz.png)

_posts/development/istio/2024-03-23-istio-crd-others-memo.md

@@ -0,0 +1,86 @@
+---
+title: "Istio CRD 중에 지엽적인 나머지 것들 정리"
+toc: true
+toc_sticky: true
+categories: ["Kubernetes", "Istio"]
+excerpt: "아니 Istio에 이런 리소스도 있었어 싶은 것들을 아주 간단히 정리해봤다: "
+last_modified_at: 2024-03-23
+---
+
+```bash
+$ kubectl get crd | grep istio
+authorizationpolicies.security.istio.io    2024-03-22T07:07:06Z
+destinationrules.networking.istio.io       2024-03-22T07:07:07Z
+envoyfilters.networking.istio.io           2024-03-22T07:07:07Z
+gateways.networking.istio.io               2024-03-22T07:07:07Z
+istiooperators.install.istio.io            2024-03-22T07:07:07Z
+peerauthentications.security.istio.io      2024-03-22T07:07:07Z
+proxyconfigs.networking.istio.io           2024-03-22T07:07:07Z
+requestauthentications.security.istio.io   2024-03-22T07:07:07Z
+serviceentries.networking.istio.io         2024-03-22T07:07:07Z
+sidecars.networking.istio.io               2024-03-22T07:07:07Z
+telemetries.telemetry.istio.io             2024-03-22T07:07:07Z
+virtualservices.networking.istio.io        2024-03-22T07:07:07Z
+wasmplugins.extensions.istio.io            2024-03-22T07:07:07Z
+workloadentries.networking.istio.io        2024-03-22T07:07:07Z
+workloadgroups.networking.istio.io         2024-03-22T07:07:07Z
+```
+
+ICA 시험 준비할 때, 위의 명령어를 쳐서 나온 Istio 리소스들을 모두 공부하겠다는 다짐을 했다 ㅋㅋㅋ `VirtualService` `DestinationRule`, `Gateway`은 Istio를 처음 공부할 때부터 봤던 것들이고, `IstioOperator`는 istio 설치랑 Mesh Config 살펴보면서 깊게 공부 했고, `ServiceEntry`는 Egress Gateway 때 공부했고,  `AuthorizationPolicy`, `PeerAuthentication`, `RequestAuthentication`, `Sidecar`는 Istio의 Security 관련해서 공부할 때 살펴봤다.
+
+이제 나머지 남은 것들은 진짜진짜 접할 기회도 거의 없었고, Istio 공부하면서 본 테크 영상이나 블로그에서 거의 등장 안 하던 것들이다. 그런데 시험에는 뭐가 나올지 모르니... 일단 공부는 다 해봤다... (장하다 나 자신...)
+
+이미 살펴본 것들은
+- `VirtualService`, `DestinnationRule`, `Gateway`
+- `IstioOperator`
+- `ServiceEntry`
+- `AuthorizationPolicy`, `PeerAuthentication`, `RequestAuthentication`, `Sidecar`
+
+진짜 쩌리들로 ICA 시험에 안 나올 것 같은 것들...
+
+- `WorkloadGroup`, `WorkloadEntry`
+- `Telemtry`
+- `WasmPlugin`
+- `EnvoyFilter`
+- `ProxyConfig`
+
+그래도 한번씩 문서는 다 살펴봤으니!! 공부한게 아까워서라도 여기에 정리해두겠다!! ❤️‍🔥
+
+# WorkloadGroup & WorkloadEntry`
+
+요건 Istio의 [Virtual Machine Archtecture](https://bluehorn07.github.io/2024/03/23/istio-virtual-machine-architecture/) 살펴보면서 공부하고 정리 해뒀다 ㅎㅎ
+
+# Telemtry
+
+TODO...
+
+# WasmPlugin
+
+https://istio.io/latest/docs/reference/config/proxy_extensions/wasm-plugin/
+
+WebAssembly 플러그인?이라는데, WebAssembly는 아직 뭔지도 잘 모르고 써본 적도 없어서 WASM을 공부했음 ㅋㅋ
+
+[니코쌤의 WASM 설명](https://youtu.be/KjgDxBLv0bM?si=9In7rTUrV6FAE3TQ)
+
+# EnvoyFilter
+
+https://istio.io/latest/docs/reference/config/networking/envoy-filter/
+
+Istio Pilot이 만든 Envoy Configuration을 커스텀할 수 있는 리소스. 단, 잘못 건드리면 재앙이 벌어질 수도 있으니 주의할 것!
+
+![](https://miro.medium.com/v2/resize:fit:2000/format:webp/0*RM-Rif51UiVlZmYC)
+
+이때, "filter"는 Envoy에서 유래만 용어로 Envoy가 트래픽을 처리하는 프로세스 중 하나를 일컫는다. Envoy 안에 filter는 여러개가 존재할 수 있으며 이들은 순서대로 처리된다. 그래서 filter chain라고 부른다.
+
+# ProxyConfig
+
+https://istio.io/latest/docs/reference/config/networking/proxy-config/
+
+요건 Envoy Proxy 관련해 몇가지 커스텀을 할 수 있는데, 커스텀 하는 것들이 단순해서 이해는 쉽다 ㅋㅋ
+
+`concurrency`를 조정해 Envoy Proxy가 몇개의 thread를 사용할 수 있을지 커스텀. 기본값은 `2`, 2개 쓰레드다.
+
+`environmentVariables`는 Envoy Porxy에 추가 Env Variable를 정의할 수 있는 필드.
+
+`image`는 Envoy Proxy의 이미지 타입을 명시하는 부분임. `default` 값에서 `distroless`, `debug` 등으로 바꿀 수 있다. 참고로 `distroless`는 리눅스 배포판(distribution, distro)에 포함되는 소프트웨어가 포함되지 않은 이미지임. 그래서 완전 초-경량임!!
+