메시가 실제로 강제하는 것을 본다

이 실습은 진짜 Istio 에서 돕니다

VM 안에 k3s + Istio 가 실제로 떠 있습니다. 사이드카가 진짜로 주입되고,
mTLS 가 진짜로 강제되며, VirtualService 가 진짜로 트래픽을 돌립니다.

ICA 과정의 다른 실습은 CRD 만 적재된 가짜 클러스터에서 돕니다. 거기서는
kubectl apply 가 통과할 뿐 아무것도 일어나지 않습니다.

처음 뜨는 데 2~3분 걸립니다.

목표

사이드카가 어디에 주입되는지 확인하고, mTLS 와 인가 정책이 실제로
무엇을 막는지 응답 코드로 구분합니다.

왜 중요한가

서비스 메시의 가치는 "설정을 썼다" 가 아니라 "그 설정이 강제된다" 입니다.
그런데 강제되지 않는 상태가 정상처럼 보인다는 것이 이 주제의 함정입니다.

가장 흔한 것이 사이드카 미주입입니다. 네임스페이스에 라벨을 붙이기 전에
만든 파드는 사이드카가 없습니다. 파드는 Running 이고 서비스도 응답합니다.
그런데 트래픽이 메시를 통과하지 않으므로 mTLS 도 인가 정책도 라우팅도
아무것도 적용되지 않습니다. **보안 정책을 다 써 두고 아무것도 지켜지지 않는
상태**가 됩니다.

그리고 요즘은 확인 방법 자체가 바뀌었습니다. Istio 는 이제 쿠버네티스의
네이티브 사이드카를 씁니다. istio-proxy 가 spec.containers 가 아니라
spec.initContainers 에 들어갑니다(restartPolicy: Always 로). 그래서
kubectl get pod -o jsonpath='{.spec.containers[*].name}' 로 확인하던 습관은
이제 사이드카가 있는데도 없다고 답합니다.

단계

1. istioctl version 과 주입 라벨을 확인해 /root/ica/install.txt 에 저장하세요.
2. web 파드(nginx)를 만들고, istio-proxy 가 어디에 들어갔는지 확인해 /root/ica/sidecar.txt 에 저장하세요. spec.containers 와 spec.initContainers 를 둘 다 찍어야 합니다.
3. strict PeerAuthentication 으로 mTLS 를 STRICT 로 만들고, 메시 안과 밖에서 각각 요청해 /root/ica/mtls.txt 에 저장하세요.
4. web-vs VirtualService 로 /teapot 경로만 418 을 돌려주게 하고 결과를 /root/ica/routing.txt 에 저장하세요.
5. web-authz AuthorizationPolicy 로 특정 서비스어카운트만 허용하고, 허용된 쪽과 아닌 쪽을 시험해 /root/ica/authz.txt 에 저장하세요.
6. 워크로드의 SPIFFE 신원을 확인해 /root/ica/identity.txt 에 저장하세요.
7. 메시 밖 워크로드(nomesh 네임스페이스)를 두고, STRICT 로 한 번에 넘어가면 왜 위험한지를 /root/ica/outside.txt 에 적으세요.
8. /root/ica/report.md 에 sidecar_location=, authz_denied_code=, mesh_identity= 세 줄과 설명을 쓰세요.

참고

• 라벨을 붙인 뒤에 만든 파드만 주입됩니다. 이미 있던 파드는 kubectl rollout restart 나 재생성이 필요합니다.
• 사이드카가 있는 파드에 kubectl exec 할 때는 -c <앱컨테이너> 를 주는 편이 안전합니다. 안 주면 기본 컨테이너가 무엇인지에 따라 달라집니다.
• Istio 의 인가 거부는 403 입니다(RBAC: access denied). mTLS 미충족은 연결 자체가 리셋되어 응답 코드가 없습니다(curl 이 000 이나 exit 56). 이 둘을 구분하는 것이 진단의 핵심입니다.
• SPIFFE 신원은 spiffe://cluster.local/ns/<네임스페이스>/sa/<서비스어카운트> 형식입니다. istioctl proxy-config secret <파드> 로 인증서를 볼 수 있습니다.
• 흔한 실수 1: VirtualService 의 http 목록 순서. 위에서부터 먼저 맞는 규칙을 쓰므로, 포괄 규칙을 위에 두면 아래 규칙이 영영 안 걸립니다.
• 흔한 실수 2: 라벨을 붙이기 전에 만든 파드를 그대로 두고 "정책이 안 먹는다" 고 하는 것. 사이드카가 없으면 아무것도 적용되지 않습니다.

단계 8개

1. 무엇이 떠 있는가
2. 사이드카는 어디에 들어가나
3. STRICT 가 실제로 막는다
4. 규칙 순서가 결과를 바꾼다
5. 신원으로 허용한다
6. 신원은 어디에 담기나
7. STRICT 로 한 번에 넘어가면 안 되는 이유
8. 무엇을 배웠나