펜리젠트 헤더

실제로 중요한 Ingress-NGINX CVE: 패치 경로, 실제 폭발 반경 및 안전함을 증명하는 방법

1. "ingress-nginx cve" 검색이 급증하는 이유

심각도가 높은 Ingress-NGINX 권고가 떨어지면 엔지니어링 팀은 일반적으로 두 가지 즉각적인 문제에 직면하게 됩니다. 첫 번째는 "오늘은 뭘 해야 하나요?" 문제를 해결해야 합니다. CVE 설명은 추상적인 경우가 많기 때문에 엔지니어는 CVE를 영향을 받는 버전, 수정된 버전 및 구체적인 완화 단계로 직접 연결할 수 있는 맵이 필요합니다.

두 번째는 "증명" 문제를 해결해야 합니다. 보안 팀과 감사자에게는 "패치를 적용했다"는 구두 확인 이상의 것이 필요합니다. 티켓을 종료하려면 명령어, 로그, 구성 차이점 등의 증거가 필요합니다.

이 가이드에서는 자세한 내용은 생략합니다. 2026년의 현재 공개 환경, 2025년의 'IngressNightmare'가 주는 교훈, 클러스터가 실제로 안전한지 확인하는 방법에 중점을 둡니다.

실제로 중요한 Ingress-NGINX CVE: 패치 경로, 실제 폭발 반경 및 안전함을 증명하는 방법

이 가이드에 대한 간단한 용어집

  • Ingress: 라우팅 규칙(HTTP/HTTPS)을 정의하는 쿠버네티스 오브젝트입니다.
  • 컨트롤러: 해당 규칙을 읽고 NGINX 바이너리를 구성하는 파드(ingress-nginx)입니다.
  • 입장 컨트롤러: 컨트롤러가 보기 전에 API 요청을 가로채서 인그레스 구문의 유효성을 검사하는 "바운서"(ValidatingWebhook)입니다.
  • 주석: 인그레스 오브젝트에 첨부된 메타데이터를 통해 NGINX 동작(종종 인젝션 공격의 벡터)을 사용자 정의합니다.
  • 비밀: TLS 인증서를 보유한 쿠버네티스 오브젝트. 기본적으로 많은 컨트롤러가 모든 시크릿을 마운트하여 가치가 높은 대상을 생성합니다.

2. 현재 2026년 인그레스-엔진스 공개: CVE, 심각도, 고정 버전

2.1 티켓에 인용할 수 있는 공식 패치 라인

아래 나열된 취약점을 해결하려면 Ingress-NGINX 컨트롤러를 다음 버전(또는 그 이상) 중 하나로 업그레이드해야 합니다:

  • 안정적인 트랙: v1.13.7
  • 최신 기능 트랙: v1.14.3

참고: 팀은 v1.14.x에 도입된 잠재적으로 중단될 수 있는 기능을 강제로 적용하지 않고도 안정 버전에서 보안 패치를 사용할 수 있도록 두 가지 트랙이 존재합니다.

2.2 CVE-2026-24512: rules.http.paths.path를 통한 구성 주입

이것이 이번 배치의 중요한 취약점입니다. 이는 안전하지 않은 입력 유효성 검사와 관련이 있습니다. rules.http.paths.path 필드에 추가합니다. 공격자(또는 제한된 권한을 가진 사용자)가 악성 경로로 인그레스를 생성하는 경우, 원시 NGINX 구성 지시어를 삽입할 수 있습니다.

실질적인 위험: 인그레스 컨트롤러는 높은 권한으로 실행되기 때문에(종종 클러스터의 모든 시크릿을 읽고 TLS를 처리하기 위해), "인그레스 쓰기 권한"은 사실상 "클러스터 시크릿 손상"과 동일합니다.

2.3 CVE-2026-1580: 어노테이션 기반 인젝션 변형

24512의 형제라고 생각하세요. 같은 종류의 버그(명령/설정 주입)이지만 경로 필드가 아닌 특정 사용자 제어 어노테이션을 통해 트리거됩니다. 진입점은 다르지만 결과(컨트롤러 컨텍스트 내에서 코드 실행)는 동일합니다.

2.4 CVE-2026-24513: 인증 URL 보호 우회

이 취약점은 구성에 따라 달라집니다. 이 취약점은 클러스터에 영향을 미칩니다. 인증 URL 어노테이션을 추가하세요. 백엔드가 외부 인증을 무시하도록 잘못 구성된 경우 X-코드 헤더를 사용하고 사용자 지정 401/403 오류 페이지를 사용하는 경우 공격자가 인증 검사를 우회할 수 있습니다.

주요 요점: 기본 기본 제공 백엔드는 안전합니다. 팀이 업스트림 헤더 로직의 유효성을 검사하지 않고 사용자 지정 오류 처리 구성 요소를 교체하면 위험이 크게 증가합니다.

2.5 CVE-2026-24514: 입장 컨트롤러 DoS

이는 어드미션 컨트롤러를 표적으로 하는 서비스 거부 기법입니다. 공격자는 특수하게 제작된 대량의 요청을 전송하여 메모리 소비를 급증시켜 컨트롤러 포드가 OOMKilled(메모리 부족)되게 하거나 노드에 심각한 압력을 가할 수 있습니다.

요약 매트릭스

CVE영향전제 조건수정됨먼저 확인
CVE-2026-24512RCE / 비밀 도난인그레스 생성 권한v1.13.7 / v1.14.3누가 Ingress를 만들 수 있나요?
CVE-2026-1580RCE / 비밀 도난인그레스 생성 권한v1.13.7 / v1.14.3사용된 특정 주석
CVE-2026-24513인증 우회사용자 정의 오류 페이지 + AuthURLv1.13.7 / v1.14.3nginx.ingress.kubernetes.io/auth-url 사용법
CVE-2026-24514DoS(가용성)입학 API에 대한 네트워크 액세스v1.13.7 / v1.14.3입학 웹훅 도달 가능성

3. 2025년 기준은 여전히 엔지니어들이 참조하는 기준입니다: IngressNightmare

3.1 CVE-2025-1974 및 "입학 표면" 교훈

2025년, 업계는 다음과 같은 뼈아픈 교훈을 얻었습니다. 입장 컨트롤러 를 공격 표면으로 사용합니다. 그리고 쿠버네티스 블로그 의 연구 Wiz 는 우리가 종종 NGINX 데이터 플레인에 초점을 맞추는 반면, 어드미션 웹훅(관리 플레인)에는 동일한 네트워크 제한이 없는 경우가 많다고 강조했습니다.

인그레스를 강화하는 것은 단순히 NGINX 구성에 관한 것이 아니라 이를 관리하는 Kubernetes API 구성 요소를 보호하는 것입니다.

3.2 "43% 취약"의 실제 의미

기억하실 수 있습니다. Wiz's 연구 결과에 따르면 "43%의 클러스터가 취약하다"고 합니다. 이를 책임감 있게 해석하는 것이 중요합니다. 이 수치는 43%의 클러스터가 실제로 손상되었다는 뜻이 아닙니다. 이는 스캔한 환경 중 43%의 클러스터가 조합 취약한 버전, 노출된 대시보드/웹훅, 과도하게 허용된 RBAC 등입니다. 다음을 측정합니다. 노출 가능성능동적 악용이 아닙니다.

3.3 2026년에도 여전히 적용되는 재사용 가능한 엔지니어링 컨트롤

2025년 'IngressNightmare'에 대한 개선 사항은 2026년 방어의 토대가 될 것입니다:

  1. 입학 엔드포인트 도달 가능성: 로드밸런서를 통해 입학 컨트롤러가 공용 인터넷에 노출되지 않도록 합니다.
  2. RBAC: 제한 생성/업데이트 인그레스 개체에 대한 권한을 설정합니다.
  3. 비밀 범위 지정: 컨트롤러를 실행하지 마십시오. -모든 네임스페이스 감시 플래그를 사용해야 합니다.

4. 빠른 분류: 클러스터 내 노출 결정

참고: 이 명령은 식별 및 유효성 검사 전용입니다. 프로덕션 클러스터에 대해 익스플로잇 스크립트를 실행하지 마세요.

4.1 컨트롤러 버전 및 설치 방법 확인

먼저 실행 중인 이미지 태그를 가져옵니다.

Bash

`# 배포 이미지 확인 kubectl -n ingress-nginx get deploy ingress-nginx-controller -o jsonpath='{.spec.template.spec.containers[0].image}'

헬름을 통해 설치한 경우 차트 버전 확인

헬름 목록 -n ingress-nginx`

4.2 입학 기능이 활성화되어 있고 연결 가능한지 확인하기

ValidatingWebhook이 존재하는지, 어디를 가리키는지 확인합니다.

Bash

kubectl 유효성 검사 웹훅 구성 ingress-nginx-admission -o yaml

위험 점검: 보세요. 서비스 정의와 관련된 정의입니다. 서비스 유형이 로드밸런서 또는 NodePort를 클릭하고 방화벽 규칙을 확인하세요. 인터넷에서 허용 포트(일반적으로 8443)에 액세스할 수 있는 경우 CVE-2026-24514(DoS)의 위험 점수가 높습니다.

4.3 "인그레스를 변조할 수 있는 사람" 찾기(RBAC 현실 확인)

인그레스 CVE(24512/1580)에는 인그레스 객체를 생성하거나 편집할 수 있는 기능이 필요합니다. 권한을 확인하세요:

Bash

# 특정 사용자/서비스 계정이 인그레스를 생성할 수 있는지 확인 kubectl auth can-i create ingress --as system:serviceaccount:default:pipeline-bot -n production

이것이 중요한 이유: 많은 조직에서 CI/CD 봇 또는 '개발자'의 역할은 광범위합니다. PR:L (풀 리퀘스트: 라이브) 액세스. 손상된 개발자 계정이 인그레스 매니페스트를 게시할 수 있는 경우 컨트롤러를 악용할 수 있습니다.

4.4 비밀 폭발 반경 평가

컨트롤러가 손상된 경우 어떤 일이 발생하는지 파악하세요.

Bash

# 컨트롤러의 서비스 어카운트에 바인딩된 클러스터롤을 확인한다. kubectl get clusterrole -l app.kubernetes.io/name=ingress-nginx

클러스터 역할에 다음이 포함된 경우 비밀 동사와 함께 get 또는 목록 클러스터 범위에서 컨트롤러가 손상되면 전체 클러스터 비밀이 노출됩니다.

실제로 중요한 Ingress-NGINX CVE: 패치 경로, 실제 폭발 반경 및 안전함을 증명하는 방법

5. 완화 플레이북: 업그레이드 기간 전에 수행할 수 있는 작업

5.1 유일한 내구성 있는 해결책: 업그레이드

바이너리를 교체하는 것 외에는 '패치'가 없습니다. 다음 버전으로 업그레이드 계획 v1.13.7 또는 v1.14.3 즉시 삭제합니다. 다음 내용을 참조하세요. 쿠버네티스 보안 공지 해시 확인을 위해.

5.2 취약성 등급별 부분 완화 조치

즉시 업그레이드할 수 없는 경우(예: 변경 동결 창을 기다리는 중):

  • 주입용(CVE-2026-24512 / 1580):
    • 특정 어노테이션 또는 정규식 패턴이 포함된 인그레스 오브젝트를 거부하도록 외부 정책 엔진(OPA/Kyverno)을 구현합니다. 경로.
    • 일시적으로 RBAC 제한: 제거 생성/패치 관리자가 아닌 사용자의 인그레스 권한.
  • 인증 우회(CVE-2026-24513)의 경우:
    • 백엔드 구성을 확인합니다. 사용자 지정 오류 페이지에서 헤더의 유효성을 엄격하게 검사하거나 기본 백엔드로 되돌릴 수 있는지 확인합니다.
  • DoS(CVE-2026-24514)의 경우:
    • 컨트롤러 네임스페이스에 더 엄격한 리소스 할당량을 적용합니다.
    • 네트워크 정책을 사용하여 어드미션 웹훅 포트(8443)에 대한 액세스를 쿠버네티스 API 서버로만 제한하세요.

5.3 "클러스터 관리자로서의 컨트롤러"의 현실을 줄이는 컨트롤

폭발 반경을 영구적으로 줄이려면:

  • 범위 비밀: 다음을 사용하여 컨트롤러를 실행합니다. -워치 네임스페이스 (네임스페이스당 하나의 컨트롤러) 대신 클러스터 전체가 아닌 컨트롤러를 사용합니다.
  • 네트워크 정책: 컨트롤러를 격리합니다. 컨트롤러는 트래픽을 라우팅하는 엔드포인트(남북) 및 API 서버와만 통신해야 합니다. 광범위한 동-서 방향 액세스가 없어야 합니다.

6. 확인: 해결을 증명하는 방법

6.1 업그레이드 후 확인

업그레이드 후, 실행 중인 파드가 새 이미지 sha256을 사용하고 있는지 확인한다.

Bash

kubectl get pods -n ingress-nginx -o jsonpath="{.items[*].spec.containers[*].image}"

6.2 연속 감지 신호

보안팀은 의심스러운 활동이 있는지 Kubernetes 감사 로그를 모니터링해야 합니다:

  • 주석 업데이트가 급증했습니다: 다음에 대한 업데이트 빈도가 높습니다. nginx.ingress.kubernetes.io/* 주석.
  • 비정상적인 웹훅 트래픽: 입장 서비스를 대상으로 예상치 못한 대용량 트래픽이 발생했습니다.

감사 쿼리 로직 예시:

동사=생성 또는 동사=패치 AND 리소스=접속 AND 사용자 != [알려진_관리자_사용자] AND 응답=2xx

6.3 실용적인 보안 회귀 체크리스트

플랫폼 팀은 모든 Ingress 업그레이드에 대해 이 회귀 테스트를 채택해야 합니다:

  1. 버전: 컨트롤러가 패치된 버전을 실행하고 있나요?
  2. 노출: 입학 웹훅이 공용 인터넷에서 차단되어 있나요?
  3. RBAC: 권한이 최소 권한(와일드카드 비밀 액세스 없음)인가요?
  4. Config: Is 헤더 내 밑줄 활성화 또는 기타 위험한 플래그가 명시적으로 검토되었나요?

7. CVE 권고를 반복 가능한 검증으로 전환하기

CVE 권고사항은 데이터는 제공하지만 워크플로는 제공하지 않습니다. Penligent는 파괴적인 익스플로잇 테스트 없이도 "패치를 적용했다고 생각한다"와 "수정 사항을 확인했다" 사이의 간극을 메워줍니다.

위험한 익스플로잇 코드를 실행하는 대신 Penligent를 사용하여 클러스터의 노출에 대한 자동화된 비침입 감사를 실행할 수 있습니다. Penligent는 허용 컨트롤러의 접근 가능성을 즉시 매핑하고, 실행 중인 버전을 CVE 데이터베이스와 비교하여 검증하고, 컨트롤러의 서비스 계정에 대한 RBAC 폭발 반경을 매핑할 수 있습니다. 이렇게 하면 수정 티켓에 직접 첨부할 수 있는 검증 가능한 증거 보고서가 생성됩니다.

8. 부록: CVE 참조 표 및 업그레이드 결정 트리

8.1 한 페이지 분량의 CVE 표(엔지니어 친화적)

연도CVE유형고정 버전
2026CVE-2026-24512구성 주입v1.13.7, v1.14.3
2026CVE-2026-1580주석 주입v1.13.7, v1.14.3
2026CVE-2026-24513인증 우회v1.13.7, v1.14.3
2026CVE-2026-24514DoSv1.13.7, v1.14.3
2025CVE-2025-1974입장 우회v1.12.x

8.2 업그레이드 의사 결정 트리

  1. 현재 버전을 확인합니다:
    • 만약 < v1.13.7: 긴급 상황. 다음으로 업그레이드 v1.13.7 (안정) 즉시.
    • 만약 v1.14.0 - v1.14.2: 업그레이드 v1.14.3.
  2. 72시간 안에 업그레이드할 수 있나요?
    • 예: 유지 관리 기간 예약하기. 이미지 샤를 확인합니다.
    • 아니요:
      • 인터넷에서 입학 웹훅을 차단합니다.
      • 제한 인그레스 만들기 관리자 전용 RBAC.
      • 다음에 대한 로그 모니터링 rules.http.paths.path 이상 징후.

추가 읽기

게시물을 공유하세요:
관련 게시물
ko_KRKorean