メッシュが実際に強制するものを見る

LabHub 에서 이어서 보기

한국어 원문으로 표시합니다.

이 실습은 진짜 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}' 로 확인하던 습관은 이제 사이드카가 있는데도 없다고 답합니다.

단계

istioctl version 과 주입 라벨을 확인해 /root/ica/install.txt 에 저장하세요.
web 파드(nginx)를 만들고, istio-proxy 가 어디에 들어갔는지 확인해 /root/ica/sidecar.txt 에 저장하세요. spec.containers 와 spec.initContainers 를 둘 다 찍어야 합니다.
strict PeerAuthentication 으로 mTLS 를 STRICT 로 만들고, 메시 안과 밖에서 각각 요청해 /root/ica/mtls.txt 에 저장하세요.
web-vs VirtualService 로 /teapot 경로만 418 을 돌려주게 하고 결과를 /root/ica/routing.txt 에 저장하세요.
web-authz AuthorizationPolicy 로 특정 서비스어카운트만 허용하고, 허용된 쪽과 아닌 쪽을 시험해 /root/ica/authz.txt 에 저장하세요.
워크로드의 SPIFFE 신원을 확인해 /root/ica/identity.txt 에 저장하세요.
메시 밖 워크로드(nomesh 네임스페이스)를 두고, STRICT 로 한 번에 넘어가면 왜 위험한지를 /root/ica/outside.txt 에 적으세요.
/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: 라벨을 붙이기 전에 만든 파드를 그대로 두고 "정책이 안 먹는다" 고 하는 것. 사이드카가 없으면 아무것도 적용되지 않습니다.

무엇이 떠 있는가

istioctl version 과 주입 라벨을 확인해 /root/ica/install.txt 에 저장하세요.

istioctl version 으로 컨트롤 플레인과 데이터 플레인 버전을 함께 봅니다. 그리고 default 네임스페이스의 istio-injection 라벨을 확인하세요.

사이드카는 어디에 들어가나

web 파드(nginx)를 만들고, istio-proxy 가 어디에 들어갔는지 확인해 /root/ica/sidecar.txt 에 저장하세요. spec.containers 와 spec.initContainers 를 둘 다 찍어야 합니다.

.spec.containers 와 .spec.initContainers 를 둘 다 찍어 보세요. 요즘 Istio 는 네이티브 사이드카를 씁니다.

STRICT 가 실제로 막는다

strict PeerAuthentication 으로 mTLS 를 STRICT 로 만들고, 메시 안과 밖에서 각각 요청해 /root/ica/mtls.txt 에 저장하세요.

메시 안(사이드카 있는 파드)과 메시 밖(사이드카 없는 네임스페이스)에서 각각 요청해 보세요. 밖에서는 응답 코드조차 오지 않습니다.

규칙 순서가 결과를 바꾼다

web-vs VirtualService 로 /teapot 경로만 418 을 돌려주게 하고 결과를 /root/ica/routing.txt 에 저장하세요.

http 목록은 위에서부터 먼저 맞는 것을 씁니다. 구체적인 규칙을 위에, 포괄 규칙을 아래에 두세요.

신원으로 허용한다

web-authz AuthorizationPolicy 로 특정 서비스어카운트만 허용하고, 허용된 쪽과 아닌 쪽을 시험해 /root/ica/authz.txt 에 저장하세요.

principals 에 SPIFFE 형식의 서비스어카운트를 씁니다. 거부는 403 입니다.

신원은 어디에 담기나

워크로드의 SPIFFE 신원을 확인해 /root/ica/identity.txt 에 저장하세요.

istioctl proxy-config secret <파드> 로 사이드카가 들고 있는 인증서를 봅니다. SAN 에 SPIFFE URI 가 들어 있습니다.

STRICT 로 한 번에 넘어가면 안 되는 이유

메시 밖 워크로드(nomesh 네임스페이스)를 두고, STRICT 로 한 번에 넘어가면 왜 위험한지를 /root/ica/outside.txt 에 적으세요.

메시 밖 워크로드가 하나라도 남아 있으면 STRICT 는 그 통신을 즉시 끊습니다. PERMISSIVE 로 단계를 나누는 이유를 적으세요.

무엇을 배웠나

/root/ica/report.md 에 sidecar_location=, authz_denied_code=, mesh_identity= 세 줄과 설명을 쓰세요.

sidecar_location=, authz_denied_code=, mesh_identity= 세 줄과 함께, 두 종류의 '안 된다' 를 어떻게 구분하는지 적으세요.