eMudhra CA 침해: Kubernetes 노드 패치만으로는 충분하지 않은 이유

2026년 10월, 인증 기관인 eMudhra가 인증서 서명용 개인 키 8개를 무작위 384비트 값이 아니라 1바이트 숫자(4, 56, 66, 115, 155, 156, 230, 237)로 생성했다는 사실을 한 연구자가 발견했습니다. 이 때문에 누구나 공개된 CA 인증서에서 1초도 안 되는 시간에 개인 키를 복구할 수 있었습니다. 영향을 받는 TLS 서명 키를 복구한 사람은 자신이 통제하지 않는 도메인의 인증서를 발급할 수 있습니다. 여기에 트래픽까지 가로채거나 우회시킬 수 있는 공격자는, 침해된 발급자를 여전히 신뢰하는 클라이언트를 상대로 정상 서비스를 사칭할 수 있습니다. 사용 중인 인증서가 eMudhra에서 발급된 것이 아니더라도 연결은 위험에 노출될 수 있습니다. 클라이언트가 위조된 인증서를 수락하면, 공격자는 해당 연결로 전송되는 자격 증명과 요청 데이터를 받아 보고 변조된 응답을 돌려줄 수 있습니다.

주요 브라우저에는 영향을 받는 인증서를 차단하는 업데이트가 배포되었지만, 그 보호가 Kubernetes까지 자동으로 적용되지는 않습니다. 노드, 컨테이너 이미지, 애플리케이션 런타임, 클러스터 구성은 저마다 신뢰할 인증서를 제공하거나 자체 검증 규칙을 적용할 수 있습니다. 어디를 조치해야 하는지는 실행 중인 구성 요소가 실제로 무엇을 사용하는지에 따라 달라집니다.

Kubernetes는 신뢰 정보를 어디에 두는가

Kubernetes 클러스터는 하나의 공유 트러스트 스토어를 사용하지 않습니다. 컨테이너 런타임은 보통 노드의 인증서에 의존하고, 애플리케이션은 이미지 안에 자체 번들을 포함할 수 있으며, 언어 런타임이 또 다른 인증서 집합을 제공하기도 합니다. 추가 CA 번들을 Kubernetes 구성에 저장해 워크로드에 마운트할 수도 있습니다.

이 사본들은 각각 따로 업데이트됩니다. 또한 실행 중인 프로세스는 업데이트 이전에 로드한 인증서를 계속 유지할 수 있으므로, 파일을 수정했다고 해서 애플리케이션의 신뢰 판단까지 바로잡히는 것은 아닙니다. 이어지는 섹션에서는 각 계층에서 무엇을 업데이트해야 하는지, 그리고 언제 재시작이나 다시 로드가 필요한지 설명합니다.

이번 문제는 영향을 받는 퍼블릭 발급자를 신뢰하는 연결에 해당합니다. 프라이빗 클러스터 CA나 메시 CA만 신뢰하도록 제한된 연결은 이번 사고로 자동으로 노출되지 않습니다.

아래 다이어그램은 일반적인 이미지 가져오기와 애플리케이션 연결을 비교합니다. 애플리케이션은 TLS 구성에 따라 표시된 소스 중 하나 이상을 사용할 수 있습니다.

노드의 신뢰 정보와 워크로드의 신뢰 정보는 서로 다른 경로로 업데이트됩니다. 실행 중인 각 클라이언트는 변경된 인증서를 다시 로드해야 합니다.

1. 노드: 컨테이너 런타임과 컨트롤 플레인

Kubernetes가 이미지를 내려받을 때, kubelet은 containerd나 CRI-O 같은 컨테이너 런타임에 이미지를 가져오도록 요청합니다. 런타임은 레지스트리에 연결하고, 노드가 신뢰하는 CA를 사용해 레지스트리의 HTTPS 인증서를 검증합니다. containerd나 CRI-O에 구성한 레지스트리 전용 CA는 그 풀을 대체하는 것이 아니라 풀에 추가되므로, 해당 레지스트리에도 노드 번들이 그대로 적용됩니다.

그 신뢰 구성이 침해된 발급자를 여전히 수락한다면, 네트워크 경로상의 공격자가 레지스트리를 사칭할 수 있습니다. 이는 워크로드가 시작되기 전에 일어나는 일이므로, 워크로드 이미지 안의 인증서를 업데이트해도 다운로드는 보호되지 않습니다.

배포판의 CA 업데이트를 설치하거나, 수정된 노드 이미지로 노드를 교체하세요. 그런 다음 이전 인증서를 캐시하고 있는 관련 프로세스를 재시작합니다. 여기에는 컨테이너 런타임과 관련된 노드 및 컨트롤 플레인 구성 요소가 포함됩니다. 새로 시작한 진단 도구는 업데이트된 번들을 사용하더라도, 오래 실행 중인 서비스는 여전히 이전 번들을 사용하고 있을 수 있습니다.

컨트롤 플레인에도 주의가 필요합니다. kubeadm 클러스터에서는 API 서버와 컨트롤러 매니저가 노드의 인증서 디렉터리를 마운트합니다. 이 저장소들은 외부 HTTPS 연결에 사용될 수 있습니다. 예를 들어 어드미션 웹훅 구성에 명시적인 caBundle이 없으면 API 서버는 시스템 루트 인증서를 사용합니다. 번들이 지정되어 있다면 그 번들은 별도로 검토해야 합니다.

kubeadm 컨트롤 플레인 구성 요소에는 지원되는 정적 파드 재시작 절차를 사용하세요. API로 미러 파드 오브젝트를 삭제해도 실제 컨테이너는 재시작되지 않습니다. 다중화된 컨트롤 플레인은 한 번에 한 노드씩 진행하고, 다음 노드로 넘어가기 전에 준비 상태를 확인하세요.

아울러 인증서 검증 수정이 포함된 Kubernetes 및 런타임 릴리스 가운데 해당하는 것을 배포하세요. 매니지드 Kubernetes에서는 컨트롤 플레인과 노드 이미지 롤아웃에 대한 제공업체의 안내를 따르세요. 제공업체의 업데이트가 애플리케이션 이미지나 커스텀 CA 번들을 자동으로 교체해 주지는 않습니다.

2. 이미지: 컨테이너 자체의 트러스트 스토어

노드의 CA 번들을 업데이트해도 그 노드에서 실행되는 컨테이너 이미지 안의 인증서는 업데이트되지 않습니다. 많은 이미지가 자체 /etc/ssl/certs를 포함하고 있으며, 여기에는 이미지를 빌드할 때 설치된 인증서가 들어 있습니다.

연구자의 공개 사이트는 영향을 받는 발급자의 인증서를 제시하는 테스트 엔드포인트를 제공합니다. 다음 명령은 특정 curl 이미지를 사용해 emSign 엔드포인트를 확인합니다.

kubectl run curl --image=curlimages/curl:8.22.0 --restart=Never --rm -i -- \
  -sS -o /dev/null -w '%{http_code}\n' https://dv-g3b-emudhra.we-have-a-problem.com/

아래 비교에서는 CA 패키지를 업데이트한 동일한 노드에서 두 개의 이미지를 사용했습니다.

이전 이미지는 자체 번들이 수정 이전의 것이기 때문에 영향을 받는 인증서를 여전히 수락합니다. 직접 관리하는 이미지는 CA 패키지를 업데이트한 뒤 다시 빌드하고 재배포하세요. 벤더 이미지는 수정이 포함된 릴리스를 사용하고, 실행 중인 파드가 해당 릴리스로 전환되었는지 확인하세요.

이 명령이 확인하는 것은 curl의 신뢰 구성입니다. 같은 컨테이너 안의 애플리케이션은 다른 번들이나 런타임을 사용할 수 있으며, 이 엔드포인트를 거부한다고 해서 다른 모든 인증서 체인이 차단된다는 증거가 되지는 않습니다.

3. 런타임: 애플리케이션의 인증서 검증

애플리케이션이 항상 이미지의 /etc/ssl/certs를 사용하는 것은 아닙니다. 일부 런타임은 자체적으로 신뢰하는 인증서를 포함합니다. 또 어떤 런타임은 트러스트 스토어에 영향을 받는 루트 인증서가 남아 있더라도 침해된 서명 키를 거부하는 코드를 포함하고 있습니다.

Kubernetes의 컨트롤 플레인 구성 요소와 많은 컨트롤러가 Go로 작성되어 있기 때문에 Go는 특히 중요합니다. Go 1.27.3과 1.26.10은 침해된 키가 포함된 인증서 체인을 거부하는 차단 목록을 crypto/x509에 추가했습니다.

세 가지 Go 버전으로 빌드한 테스트 클라이언트가 그 차이를 보여 줍니다. 동일하게 오래된 CA 번들을 사용했을 때의 결과는 다음과 같습니다.

업데이트된 클라이언트는 영향을 받는 인증서를 거부하면서도 대조용 연결은 계속 수락합니다. 이 보호는 애플리케이션에 컴파일되어 포함됩니다. 패치된 툴체인으로 빌드된 릴리스를 배포하거나, 직접 다시 빌드해 재배포하세요. go.mod에 선언된 버전만으로는 배포된 바이너리를 어떤 툴체인이 빌드했는지 알 수 없습니다. 바이너리의 빌드 메타데이터와 실제 동작을 함께 확인하세요.

Java, Node.js, Python, Rust 애플리케이션도 런타임별 확인이 필요합니다. 런타임의 보안 안내와, Python의 certifi처럼 별도로 번들된 CA 패키지를 검토하세요. 운영체제의 인증서를 업데이트한다고 해서 이러한 사본까지 업데이트되는 것은 아닙니다.

4. 클러스터 구성: Kubernetes 오브젝트 안의 CA 번들

Kubernetes 오브젝트에는 워크로드와 컨트롤러가 연결을 검증하는 데 사용하는 CA 번들이 들어 있을 수 있습니다. 노드나 컨테이너 이미지를 업데이트해도 이렇게 저장된 사본은 교체되지 않습니다.

애플리케이션이 신뢰할 인증서를 전달받는 위치를 검토하세요.

• ConfigMap과 Secret: Argo CD의 argocd-tls-certs-cm, ca.crt가 들어 있는 Secret, Istio나 Kasten이 참조하는 번들 등.
• Kubernetes API 구성: 어드미션 웹훅, APIService, CRD 변환 웹훅에 들어 있는 CA 번들 등.
• 애플리케이션 구성: 커스텀 리소스와 Helm values의 CA 설정, trust-manager가 배포하는 번들 등.

해당 루트 인증서를 식별하려면 이 공개 사이트의 영향을 받는 루트 인증서 목록에 있는 SHA-256 인증서 지문을 사용하세요. 명시적으로 신뢰하도록 설정한, 영향을 받는 중간 CA 인증서도 검토하세요. 같은 종류의 Kubernetes 오브젝트에 저장되어 있다는 이유만으로, 관련 없는 프라이빗 클러스터 또는 메시의 트러스트 앵커를 삭제하지 마세요.

trust-manager를 사용한다면 기본 CA 패키지와 리포지토리 또는 태그 재정의 여부를 확인하세요. v0.25.0까지의 차트는 기본적으로 영향을 받는 패키지를 설치하며, v0.26.0은 수정된 패키지를 설치합니다. 기본 패키지를 업데이트해도 추가 Bundle 소스를 통해 제공되는, 영향을 받는 인증서는 제거되지 않습니다.

사용 가능한 수정 사항과 업그레이드 안내

아래 표는 2026년 11월 9일 기준 스냅샷에 따라 Kubernetes 구성 요소, 매니지드 클러스터, 클라우드 네이티브 도구에 필요한 조치를 정리한 것입니다. 롤아웃을 계획하기 전에, 링크된 각 프로젝트의 안내에서 더 새로운 버전이 있는지 확인하세요. 커스텀 번들, 헬퍼 프로그램, 그 밖의 이미지 변형은 여전히 별도의 확인이 필요합니다.

Kubernetes와 컨테이너 런타임

매니지드 Kubernetes

제공업체의 업데이트가 출시되었다고 해서 그 업데이트가 내 클러스터에 적용되었다는 뜻은 아닙니다. 컨트롤 플레인, 노드 이미지, 롤아웃 상태를 확인한 다음, 고객이 직접 관리하는 워크로드는 별도로 조치하세요.

서비스 메시, 게이트웨이, 네트워킹

인증서, 아이덴티티, 정책

딜리버리와 공급망

컨테이너 빌드, 레지스트리, 스캐닝

옵저버빌리티, 데이터, 플랫폼

결론

eMudhra 침해는 노드를 패치한 뒤에도 Kubernetes 보안 업데이트가 불완전한 상태로 남을 수 있는 이유를 보여 줍니다. 컨테이너는 오래된 CA 번들을 그대로 가지고 있을 수 있고, 애플리케이션은 별도의 런타임 저장소를 사용할 수 있으며, 클러스터 구성은 두 업데이트를 모두 거치고도 남아 있는 인증서를 제공할 수 있습니다. 또한 실행 중인 프로세스는 재시작해야만 수정이 반영될 수 있습니다.

영향을 받는 클라이언트마다 인증서를 어떻게 검증하는지 파악하고, 해당하는 업데이트를 적용한 뒤, 정상 연결은 계속 동작하면서 침해된 체인은 거부되는지 확인하세요. 검증해야 할 결과는 실제로 사용하는 이미지, 구성, 헬퍼 프로그램을 포함한, 실행 중인 플랫폼의 동작입니다.