Red Hat OpenShift 4.20 컨트롤 플레인에서 양자 내성 암호화 지원 심층 분석

양자 컴퓨팅 시대가 다가오면서, 이 기술의 엄청난 처리 능력은 디지털 세계의 암호화 기반에 상당한 위협이 되고 있습니다. 이 문서에서는 Red Hat OpenShift 4.20에서 PQC(post-quantum cryptography)에 대한 새로운 지원을 살펴보고 쿠버네티스 컨트롤 플레인의 핵심 구성 요소인 apiserver, kubelet, 스케줄러 및 controller-manager가 어떻게 강화되는지 중점적으로 다룹니다. 이전 버전의 Go를 사용하는 etcd는 해당되지 않습니다.

양자 위협

RSA 및 타원 곡선 암호화(ECC)와 같이 오늘날 널리 사용되는 공개 키 암호화 시스템은 보안이 강화된 온라인 커뮤니케이션의 기반을 형성합니다. 그러나 이러한 시스템은 대규모 양자 컴퓨터의 공격에 취약하므로 이러한 알고리즘의 기반이 되는 수학적 문제를 놀라운 속도로 해결할 수 있습니다. 이로 인해 공격자가 강력한 양자 컴퓨터에 액세스한 후 미래에 암호를 해독하기 위해 현재 암호화된 트래픽을 기록하는 공격이 발생했습니다. 유휴 상태의 데이터에도 동일한 문제가 적용됩니다. 만약 공격자가 나중에 암호를 해독하기 위해 지금 복사본을 생성하는 경우에도 마찬가지입니다.

이러한 위협에 대응하기 위해 PQC 분야가 등장하여 기존 컴퓨터와 양자 컴퓨터의 공격에 강한 새로운 암호화 알고리즘을 개발했습니다.

쿠버네티스와 OpenShift의 PQC

Red Hat OpenShift는 Cloud Native Computing Foundation(CNCF) 인증 쿠버네티스 배포판이며, Go 프로그래밍 언어로 작성되었습니다. 따라서 OpenShift에서 PQC 지원을 위한 여정은 Go에서 시작됩니다.

Go 1.24 릴리스는 X25519MLKEM768 하이브리드 키 교환 메커니즘에 대한 지원을 도입하여 중요한 이정표를 세웠습니다. X25519MLKEM768은 기존 X25519(타원 곡선 Diffie-Hellman)와 ML-KEM-768(사후 양자 알고리즘)을 결합하는 하이브리드 키 교환입니다. 최종 공유 암호는 두 메커니즘을 결합하여 파생됩니다. 순수한 ML-KEM은 양자 저항을 위해 전적으로 격자 기반 암호화에 의존합니다. X25519MLKEM768은 ML-KEM의 양자 저항과 X25519의 기존 보안을 동시에 제공합니다.

하이브리드 접근 방식은 현재 훨씬 더 강력합니다. ML-KEM은 2024년 8월에야 표준화되었으므로 암호화 측면에서 “최신”으로 간주됩니다. 누군가가 ML-KEM의 격자 가정(양자가 아닌 일반 암호화 분석)에 대한 예기치 않은 고전적인 공격을 발견하면 순수한 ML-KEM 배포가 중단됩니다. 하이브리드를 사용하더라도 X25519가 여전히 보안을 유지합니다.

TLS(Transport Layer Security) 세션의 결과 공유 비밀 키는 구성 요소 알고리즘 중 하나 이상이 손상되지 않는 한 예상되는 보안 수준을 제공합니다. 이는 PQC를 에코시스템에 도입할 수 있는 강력하고 향후 호환 가능한 방법을 제공합니다.

OpenShift 컨트롤 플레인에 PQC 적용

OpenShift 4.20의 PQC 지원은 각 쿠버네티스 구성 요소에서 특정 PQC 플래그를 구성하는 것이 아닙니다. 대신, 이는 기본 Go 버전과 해당 암호화 라이브러리를 통해 강화되는 이러한 구성 요소 간 TLS 통신의 강도에 관한 것입니다.

다음은 PQC 지원이 핵심 OpenShift 구성 요소 간 통신 보안을 강화하는 방법입니다(etcd 상태는 아래에서 별도로 설명).

• API 서버: 쿠버네티스 컨트롤 플레인의 중앙 허브로서 API 서버와의 모든 통신은 중요한 보안 지점입니다. ML-KEM 지원 TLS를 통해 컨트롤 플레인 통신은 향후 암호 해독을 목적으로 현재 암호화된 트래픽을 기록하는 공격으로부터 보호됩니다.
• Kubelet: 각 노드에서 실행되는 Kubelet은 API 서버와 통신하여 노드 상태 업데이트를 제공하고 포드 사양을 수신합니다. 이 통신은 이제 보안 강화를 위해 하이브리드 PQC 키 교환을 통합하여 이 링크의 무결성과 기밀성을 확인하는 데 도움이 됩니다.
• 스케줄러 및 controller-manager: 스케줄러와 controller-manager는 API 서버와 지속적으로 상호작용하여 스케줄링 결정을 내리고 클러스터의 상태를 관리합니다. 또한 이러한 상호 작용은 ML-KEM 지원 TLS로 보호되어 애플리케이션을 계속 실행하는 로직과 운영의 보안을 강화합니다.

Red Hat의 관점

많은 산업 규정에서 2035년까지 PQC를 요구하지 않지만, Red Hat은 PQC로의 전환을 위해 적극적으로 노력하고 있습니다. Red Hat은 최근 문서 “양자적 미래를 위한 조직 준비”에서 PQC 여정을 지금 시작하는 것의 중요성을 강조합니다. 또한 PQC를 Red Hat Enterprise Linux(RHEL)에 통합하기 위해 수행 중인 작업은 OpenShift의 방향을 보여주는 강력한 지표입니다. OpenShift 4.20에 PQC 기능이 포함된 것은 상당한 발전입니다.

Go 버전 불일치

관리자가 중요하게 고려해야 할 사항은 클러스터의 다양한 구성 요소 간에 Go 버전이 일치하지 않을 수 있다는 것입니다. 예를 들어 ML-KEM 인식 Go 버전으로 빌드된 kubectl 클라이언트가 이전 API 서버와 통신하는 경우 TLS 핸드셰이크가 묵시적으로 기존 암호화 알고리즘으로 다운그레이드될 수 있습니다. 이로 인해 명시적인 경고 없이 PQC 보호가 손실됩니다. 따라서 OpenShift 환경의 모든 구성 요소에서 PQC를 지원하는 호환 버전을 실행하고 있는지 확인해야 합니다.

etcd는 어떠한가요?

핵심 컨트롤 플레인 구성 요소가 ML-KEM 지원 TLS의 이점을 누리는 반면, etcd의 경우는 별개의 역할과 개발 철학에 뿌리를 두고 있습니다. 전체 클러스터에 대한 최종 정보 소스인 etcd의 절대적인 우선순위는 안정성, 데이터 무결성, 성능입니다. etcd 프로젝트는 의도적으로 Kubernetes에 비해 더 보수적인 Go 버전 관리 일정을 유지 관리합니다. Kubernetes 프로젝트는 새로운 기능과 성능 개선 사항을 신속하게 사용하기 위해 최신 Go 릴리스를 채택하는 경우가 많지만, etcd 팀은 안정적인 릴리스를 위해 더 오래되고 검증된 Go 버전을 고수함으로써 안정성을 우선시합니다. 이러한 의도적인 지연은 새로운 Go 런타임이 etcd와 같은 중요한 구성 요소에 도입되기 전에 더 광범위한 커뮤니티에서 잠재적인 문제를 철저히 검사하는 데 도움이 됩니다.

즉각적인 PQC 지원이 없는 것은 실수가 아니라 이러한 안정성 우선 접근 방식의 직접적인 결과입니다. Go 1.24에 도입된 PQC 알고리즘을 etcd에서 공식적으로 지원하려면 먼저 해당 Go 버전을 현재 Go 1.23을 사용하는 etcd의 안정적인 릴리스 분기에 채택해야 합니다. 이 프로세스에는 Raft 합의 프로토콜, I/O 대기 시간 또는 복구 작업에 부정적인 영향이 없는지 확인하는 광범위한 검증이 포함됩니다. 향후 릴리스에서 etcd의 양자 안전 지원을 기대해 주시기 바랍니다.

향후 전망

OpenShift 4.20에 통합된 PQC는 클라우드 네이티브 컴퓨팅을 위한 양자 준비된 미래를 개발하기 위해 Red Hat이 선제적인 접근 방식을 취하고 있음을 보여줍니다. 디지털 서명 및 인증서에 대한 PQC는 아직 초기 단계이지만 TLS에서 하이브리드 키 교환을 구현하는 것은 중요한 첫 단계입니다.