When the Root Changes, Who Stops Trusting Whom

한 줄 요약

istiod 는 기본으로 스스로 만든 루트로 워크로드 인증서를 서명한다. 플러그인 CA 는 조직의 루트가 서명한 중간 CA 를 cacerts Secret 으로 istiod 에 꽂아, 메시의 신원을 조직의 PKI 아래로 들이는 방법이다. 이미 돌고 있는 메시에서 이것을 바꾸는 순간, 옛 루트만 믿는 워크로드와 새 인증서를 받은 워크로드가 서로를 믿지 못한다.

왜 이게 필요했나

자체 서명 루트는 시작하기엔 편하지만 세 가지가 곤란하다. 루트 키가 클러스터 안(istio-ca-secret)에 있어 클러스터가 뚫리면 루트도 뚫린다. 클러스터마다 루트가 달라 두 클러스터의 워크로드가 서로를 믿지 못한다. 그리고 조직의 감사·폐기 체계 밖에 있다.

Istio 문서가 권하는 구조는 이렇다 — 루트 CA 는 보안이 강한 오프라인 기계에 두고, 그 루트로 클러스터마다 중간 CA 를 발급해 각 istiod 에 준다. istiod 는 그 중간 CA 로 워크로드 인증서를 서명하고, 관리자가 준 루트를 신뢰의 뿌리로 워크로드에 뿌린다. 중간 CA 하나가 새어도 루트는 그대로이고, 같은 루트 아래의 클러스터끼리는 서로의 워크로드를 믿는다.

어떻게 동작하나

cacerts 의 네 파일

키	내용
ca-cert.pem	istiod 가 쓸 중간 CA 인증서
ca-key.pem	그 개인 키
root-cert.pem	워크로드에 뿌릴 루트
cert-chain.pem	중간 CA → 루트로 이어지는 사슬

istiod 는 뜰 때 istio-system/cacerts 를 찾는다. 있으면 그것을 쓰고(로그에 cacerts 에서 루트를 읽었다고 남는다), 없으면 스스로 만든 루트를 쓴다. 떠 있는 istiod 는 나중에 생긴 Secret 을 알아채지 않으므로 재시작해야 한다.

워크로드 인증서는 사이드카가 받는다. 사이드카의 에이전트가 키를 만들고 istiod 에 서명을 요청해, 짧게(기본 24시간) 사는 인증서를 받아 Envoy 에 SDS 로 넣고 만료 전에 알아서 갈아 끼운다. 신원은 subject 가 아니라 SAN 의 SPIFFE URI(spiffe://cluster.local/ns/bank/sa/client)에 담긴다. 인가 정책의 principals 가 바로 이 값이라, CA 를 바꿔도 신뢰 도메인이 같으면 정책은 그대로다.

루트를 바꾸는 순간. 새 istiod 는 네임스페이스마다 istio-ca-root-cert 를 새 루트로 바꾸고, 새로 뜬 파드는 새 루트를 믿으며 새 중간 CA 가 서명한 인증서를 받는다. 그런데 이미 떠 있는 사이드카는 옛 루트만 들고 있다. mTLS 는 양쪽이 서로의 사슬을 검증하므로, 새 인증서를 받은 web 과 옛 루트만 믿는 client 사이에서는 연결이 맺어지지 않는다(503). 모두 재시작하거나 인증서가 갈릴 때까지 이 상태가 이어진다.

Istio 1.31 문서의 플러그인 CA 절차는 설치하기 전에 cacerts 를 꽂는 경우를 다룬다. 이미 돌고 있는 메시에서 바꾸면 위의 끊김이 생긴다는 것을 이 실습에서 직접 본다. 그 관찰에서 나오는 결론은 하나다 — 끊기는 이유가 '서로의 루트를 모른다' 이므로, 운영 중에 바꾸려면 모든 워크로드가 새 루트를 믿게 되는 일과 새 CA 로 서명하기 시작하는 일을 나눠 순서를 잡고(두 루트를 함께 믿는 기간), 모두 새 인증서를 받은 뒤에 옛 루트를 빼야 한다.

현장에서 만나는 모습

"cacerts 를 넣었는데 인증서 issuer 가 그대로입니다." istiod 를 재시작하지 않았거나, 파드가 아직 옛 인증서를 쓰고 있다. istiod 로그와 사이드카의 proxy-config secret 을 나눠 본다.

"CA 를 바꾼 뒤 일부 서비스 사이만 503 입니다." 한쪽만 재시작된 쌍이다. 두 사이드카의 ROOTCA 와 워크로드 인증서 issuer 를 나란히 보면 바로 드러난다.

"두 클러스터를 묶었는데 서로 mTLS 가 안 됩니다." 두 istiod 가 서로 다른 루트를 쓰고 있다. 같은 루트 아래 중간 CA 를 각각 꽂아야 한다.

공식 문서: Plug in CA Certificates · Security — PKI · Identity and certificate management

다음 실습에서 할 것

istiod 가 스스로 만든 루트를 먼저 확인하고, 배포판의 Makefile 로 루트와 클러스터용 중간 CA 를 만들어 cacerts 로 꽂는다. web 만 재시작해 한쪽만 새 인증서를 받은 상태의 503 을 겪고, client 까지 재시작해 되살린 뒤, 새 사슬이 우리 루트까지 이어지는지와 신원·수명을 인증서에서 직접 읽는다.