릴리즈

Linux 커널 CVE 50개 이상 패치 및 CA 인증서 업데이트만 포함된 순수 보안 패치 릴리스입니다. 기능 변경은 없습니다.

• security50개 이상의 커널 CVE 패치 — 노드 재부팅을 빠르게 예약하세요

  이번 릴리스는 2025년 및 일부 2026년 사전 공개 CVE를 포함해 대량의 커널 취약점을 수정했습니다. 네트워킹과 드라이버 서브시스템 전반에 걸친 광범위한 공격 표면이 다뤄졌습니다. Flatcar는 기본적으로 자동 업데이트를 사용하지만, FLUO나 Kured로 자동 재부팅을 제어하거나 비활성화한 경우 노드가 실제로 업데이트를 적용했는지 확인하세요. 최근 재부팅이 없는 노드는 이 취약점들에 그대로 노출된 상태입니다.

• securityCA 인증서 번들 NSS 3.124 업데이트 — 커스텀 PKI 설정을 검토하세요

  NSS 3.124 업데이트로 특정 루트 CA가 추가되거나 신뢰 목록에서 제거될 수 있습니다. 시스템 트러스트 스토어에 의존하거나 커스텀 CA 번들을 시스템 번들 위에 덧붙인 경우, 노드 업데이트 후 TLS 핸드셰이크가 정상 동작하는지 반드시 검증하세요. 일반 설정에서는 위험도가 낮지만, 내부 서비스에서 특정 중간 CA에 의존하는 경우 조용히 장애가 발생할 수 있습니다.

• enhancement업데이트 그룹이 stable 채널을 추적 중인지 확인하세요

  이런 보안 패치 전용 릴리스에서 가장 빠른 대응 방법은 노드가 stable 채널에 등록되어 자동 업데이트가 활성화된 상태를 유지하는 겁니다. 일관성을 위해 특정 이미지 버전을 고정해 뒀다면, 지금이 재검토할 좋은 시점입니다. Container Linux Config 또는 Butane 스펙에서 업데이트 전략이 'off'로 설정되어 있지 않은지 확인하세요.

Flatcar LTS 4081.3.8은 보안 중심 업데이트입니다. 커널 12개 패치 버전(6.6.128~6.6.141) 분량의 CVE 수정과 ca-certificates 갱신만 포함하며, 기능이나 설정 변경은 없으니 패치만 적용하면 됩니다.

• security4081.3.7 이하 버전은 즉시 업그레이드 필요

  이번 릴리스는 6.6.128부터 6.6.141까지 12개 커널 패치 버전을 한 번에 포함하며, 드라이버·파일시스템·네트워킹 서브시스템 전반의 메모리 안전성 및 use-after-free 취약점 수백 건을 수정합니다. 4081.3.7 이하 버전을 운영 중이라면 일반 유지보수가 아니라 필수 업그레이드로 취급하고 우선순위를 높이세요.

• enhancementca-certificates 갱신 후 TLS 신뢰 저장소 확인

  ca-certificates가 NSS 3.124(3.123.1 포함)로 갱신되었습니다. 인증서 번들 버전을 고정하거나 자체 신뢰 저장소를 Flatcar 위에 얹어 쓰고 있다면, 업데이트 후 TLS 검증이 정상 동작하는지 확인하세요. NSS 릴리스마다 특정 루트 CA를 제외하거나 신뢰 목록에서 빼는 경우가 있습니다.

Flatcar stable-4593.2.1은 보안 전용 업데이트입니다. Linux 커널 CVE 130개 이상을 패치하고 커널을 6.12.87로 올렸습니다. 적용하려면 노드를 재부팅해야 합니다.

• securityLinux 커널 CVE 130개 이상 패치 — 노드 재부팅 필요

  이번 릴리스는 CVE-2026-31xxx 및 CVE-2026-43xxx 시리즈에 걸쳐 130개 이상의 Linux 커널 CVE를 패치하며, 커널을 6.12.82부터 6.12.87까지 한꺼번에 올립니다. 안정 커널 백포트 배치가 대규모로 적용된 경우이므로 우선순위를 높게 두세요. update-operator를 사용 중이라면 롤링 재시작을 확인하고, 수동 관리 환경이라면 stable-4593.2.0 노드를 변경 주기에 맞춰 drain 후 재부팅하세요.

• enhancementCA 인증서 NSS 3.123.1 업데이트 — 커스텀 CA 체인 확인

  ca-certificates가 NSS 3.123.1로 올라갔습니다. 컨테이너 내부가 아닌 OS 레벨에서 TLS 인증서 검증을 하는 서비스가 있다면, 노드 재부팅 후 커스텀 CA 체인이나 고정(pinned) 인증서에 영향이 없는지 확인하세요.

metal3-io v0.13.0은 iRMC 드라이버를 제거하고 BMH 펌웨어 스펙을 폐기 예고하면서, HostClaim CRD와 멀티아키텍처 PXE 부팅을 새로 도입한 버전입니다. 업그레이드 전 파괴적 변경 사항 검토가 필수입니다.

• breaking업그레이드 전 iRMC 사용 여부와 BMH.Spec.Firmware 필드를 반드시 점검하세요

  iRMC 드라이버가 삭제되었기 때문에 iRMC BMC 엔드포인트를 가리키는 BareMetalHost 리소스는 업그레이드 즉시 조정이 멈춥니다. BMH.Spec.Firmware는 당장 오류가 나지 않더라도 폐기 예고 상태이므로, 대체 API로의 전환 계획을 지금 수립해야 합니다. 운영 클러스터 작업 전에 BMH 매니페스트와 Helm values 파일 전체를 검색해 두 항목의 사용 여부를 확인하세요.

• breaking관리 클러스터의 CAPI·controller-runtime 호환성을 사전에 확인하세요

  CAPI v1.13.1, controller-runtime v0.23.3 버전 상승은 단순 패치가 아닙니다. 동일한 관리 클러스터에 다른 CAPI 프로바이더가 함께 있다면, 각 프로바이더의 호환성 매트릭스를 지금 확인하세요. 버전 불일치는 CRD 충돌이나 웹훅 오류로 이어질 수 있습니다.

• enhancementHostClaim CRD로 베어메탈 호스트 할당을 선언형으로 전환하세요

  HostClaim·HostClaimSet 리소스를 쓰면 커스텀 컨트롤러 없이 Kubernetes 방식으로 베어메탈 용량을 요청·예약할 수 있습니다. 현재 스크립트나 외부 툴로 호스트 할당을 관리 중이라면, 단순 예약 워크플로는 이제 HostClaim으로 대체 가능한지 평가해볼 시점입니다.

OpenYurt v1.7.0은 엣지 업그레이드 다운타임을 최소화하는 OTA 이미지 사전 캐싱, 레이블 기반 YurtHub 배포, K8s-on-K8s 지원, Kubernetes v1.34 호환성을 추가했습니다. 동시에 여러 deprecated 컴포넌트가 완전히 제거됩니다.

• breaking업그레이드 전 제거된 컴포넌트 사용 여부 점검 필수

  YurtAppOverrider, YurtAppDaemon(컨트롤러 및 웹훅), yurt-coordinator, delegate lease 컨트롤러가 이번 릴리스에서 완전히 삭제됩니다. 매니페스트나 Helm values, 자동화 스크립트에서 이 컴포넌트를 참조하고 있다면 업그레이드 후 조용히 실패하거나 배포가 중단될 수 있습니다. 업그레이드 전 전수 점검이 필요하고, NodePool CRD의 v1beta2 승격 및 enableLeaderElections 필드명 변경도 함께 반영해야 합니다.

• enhancement엣지 DaemonSet 업그레이드에 OTA 이미지 사전 캐싱 도입

  네트워크가 불안정하거나 대역폭이 제한된 엣지 노드에서 DaemonSet을 운영 중이라면, ImagePreHeat 컨트롤러가 업그레이드 다운타임 문제의 실질적인 해결책입니다. 롤아웃 전에 OTA API 엔드포인트로 사전 캐싱을 트리거하고, PodImageReady 조건으로 이미지 준비 상태를 확인한 뒤 실제 업그레이드를 시작하는 흐름을 팀 운영 절차에 반영하세요.

• enhancement엣지 노드 온보딩을 레이블 기반 방식으로 전환

  YurtNodeConversionController 덕분에 노드에 레이블 하나만 붙이면 YurtHub 설치부터 systemd 등록까지 자동으로 처리됩니다. 대규모 엣지 노드 플릿을 운영한다면 운영 부담을 크게 줄일 수 있는 기능입니다. 다만 systemd와 직접 상호작용하는 신규 기능인 만큼, 프로덕션 적용 전에 비중요 노드 풀에서 먼저 검증하는 것을 권장합니다.