NGINX Ingress Controller Documentation

NGINX App Protect를 사용한 문제 해결

이 문서에서는 NGINX App Protect WAF 모듈이 활성화된 상태에서 NGINX Ingress Controller를 사용할 때 문제를 해결하는 방법을 설명합니다.

Ingress Controller의 일반적인 문제 해결은 일반적 문제 해결 문서를 확인하세요.

목차

1. 잠재적인 문제
2. 문제 해결방법
 2-1. Ingress Controller 및 App Protect Log 확인
2-2. Ingress 리소스의 이벤트 확인
2-3. APLogConf 이벤트 확인
2-4. APPolicy 이벤트 확인
2-5. 정책 교체
2-6. APPolicy External References의 가용성을 확인하십시오.
3. 디버그 모드에서 App Protect 실행
4. 알려진 문제
4-1. NGINX 구성 Skew
4-2. NGINX Start 또는 Reload 실패

1. 잠재적인 문제

아래 표는 App Protect WAF 모듈이 활성화된 경우 Ingress Controller와 관련된 몇 가지 잠재적인 문제를 분류합니다. 다음 섹션에서 하나 이상의 방법을 사용하여 이러한 문제를 해결하는 방법을 제안합니다.

Problem area증상상문제해결 방법원인
Start.Ingress Controller가 실행되지 않았습니다.Log를 확인합니다.APLogConf 또는 APPolicy가 잘못 구성되었습니다.
APLogConf, APPolicy or Ingress Resource.구성이 적용되지 않았습니다.APLogConf, APPolicy 및 Ingress Resource의 이벤트를 확인하고 Log를 확인하고 정책을 교체합니다.APLogConf 또는 APPolicy가 유효하지 않습니다.
NGINX.처음 시작하거나 변경 후 Reload하는 동안 Ingress Controller NGINX 확인 시간이 초과되었습니다.Unable to fetch version: X 메시지 Log를 확인하세요. APPolicy External References의 가용성을 확인하십시오.App Protect가 활성화된 Ingress 리소스가 너무 많습니다. 알려진 문제의 NGINX fails to start/reload section <#nginx-fails-to-start-or-reload>_를 확인하세요.

2. 문제 해결방법

2-1. Ingress Controller 및 App Protect Log 확인

App Protect Log는 모듈이 활성화될 때 Ingress Controller Log의 일부입니다. Ingress Controller Log를 확인하려면 문제 해결 가이드의 Ingress Controller Log 확인 단계를 따르세요.

App Protect 관련 Log의 경우 APP_PROTECT로 시작하는 메시지를 찾습니다. 예를 들면 다음과 같습니다.

2020/07/10 11:13:20 [notice] 17#17: APP_PROTECT { "event": "configuration_load_success", "software_version": "2.52.1", "completed_successfully":true,"attack_signatures_package":{"revision_datetime":"2020-06-18T10:11:32Z","version":"2020.06.18"}}

2-2. Ingress 리소스의 이벤트 확인

Ingress 리소스의 이벤트 확인 단계를 수행합니다.

2-3. APLogConf 이벤트 확인

APLogConf를 생성하거나 업데이트한 후 NGINX에서 NGINX 구성이 성공적으로 적용되었는지 즉시 확인할 수 있습니다.

$ kubectl describe aplogconf logconf
Name:         logconf
Namespace:    default
. . . 
Events:
  Type    Reason          Age   From                      Message
  ----    ------          ----  ----                      -------
  Normal  AddedOrUpdated  11s   nginx-ingress-controller  AppProtectLogConfig  default/logconf was added or updated

이벤트 섹션에는 구성이 성공적으로 적용되었음을 알려주는 AddedOrUpdated Reason가 있는 Normal 이벤트가 있습니다.

2-4. APPolicy 이벤트 확인

APPolicy를 생성하거나 업데이트한 후 NGINX에서 NGINX 구성이 성공적으로 적용되었는지 즉시 확인할 수 있습니다.

$ kubectl describe appolicy dataguard-alarm
Name:         dataguard-alarm
Namespace:    default
. . . 
Events:
  Type    Reason          Age    From                      Message
  ----    ------          ----   ----                      -------
  Normal  AddedOrUpdated  2m25s  nginx-ingress-controller  AppProtectPolicy default/dataguard-alarm was added or updated

이벤트 섹션에는 구성이 성공적으로 적용되었음을 알려주는 AddedOrUpdated Reason가 있는 Normal 이벤트가 있습니다.

2-5. 정책 교체

NOTE: 이 방법은 외부 참조를 사용하는 경우에만 적용됩니다. 외부 참조의 항목이 변경되지만 APPolicy의 사양이 변경되지 않은 경우(정책을 다시 적용하는 경우에도) kubernetes는 업데이트를 감지하지 못합니다. 이 경우 리소스를 강제로 교체할 수 있습니다. 이렇게 하면 리소스가 제거되고 다시 추가되어 Reload가 트리거됩니다. 예를 들어:

kubectl replace appolicy -f your-policy-manifest.yaml --force

2-6. APPolicy External References의 가용성을 확인하십시오.

NOTE: 이 방법은 NGINX App Protect 정책에서 외부 참조를 사용하는 경우에만 적용됩니다.

정책의 External References를 호스팅하는 서버를 확인하려면:

kubectl get appolicy mypolicy -o jsonpath='{.items[*].spec.policy.*.link}' | tr ' ' '\n'

http://192.168.100.100/resources/headersettings.txt

여러 가지 방법으로 http 요청에 걸리는 총 시간을 확인할 수 있습니다. curl 사용:

curl -w '%{time_total}' http://192.168.100.100/resources/headersettings.txt

3. 디버그 모드에서 App Protect 실행

수신 컨트롤러가 디버그 모드를 사용하도록 설정하면 설정이 App Protect WAF 모듈에도 적용됩니다. 자세한 내용은 디버그 모드에서 NGINX 실행을 참조하십시오.

4. 알려진 문제

새 구성을 적용하기 위해 NGINX를 변경하면 Ingress Controller가 자동으로 NGINX를 Reload합니다. 이러한 문제의 발생은 일반적으로 클러스터에서 App Protect가 활성화된 많은 수의 Ingress 리소스와 관련이 있습니다.

NGINX가 새 구성을 적용해야 하는 변경을 수행하면 Ingress Controller가 NGINX를 자동으로 Reload합니다. App Protect WAF 모듈을 활성화하지 않으면 일반적인 Reload 시간은 약 150ms입니다. App Protect WAF 모듈이 활성화되어 있고 여러 Ingress 리소스에서 사용 중인 경우 이러한 Reload는 대신 몇 초가 걸릴 수 있습니다.

4-1. NGINX 구성 Skew

Ingress Controller의 인스턴스를 두 개 이상 실행 중인 경우 Reload 시간이 길어지면 인스턴스의 NGINX 구성이 동기화되지 않을 수 있습니다. Ingress Controller가 Kubernetes 리소스를 처리하는 방법에 순서가 없기 때문에 이러한 현상이 발생할 수 있습니다. 모든 인스턴스가 Reload를 완료한 후에는 구성이 동일합니다.

이러한 불일치를 줄이려면 Ingress Controller에서 처리하는 여러 리소스에 변경 사항을 동시에 적용하지 않는 것이 좋습니다.

4-2. NGINX Start 또는 Reload 실패

Ingress Controller가 처음 시작되거나 NGINX를 Reload해야 하는 변경 사항이 있을 때마다 Ingress Controller는 Reload가 성공했는지 확인합니다. 이 확인을 위한 제한 시간은 일반적으로 4초입니다. App Protect가 활성화된 경우 이 제한 시간은 20초입니다.

이 제한 시간은 구성을 확인하기에 충분해야 합니다. 그러나 App Protect가 활성화된 수많은 Ingress 리소스가 Ingress Controller에서 동시에 처리되는 경우 제한 시간을 더 연장해야 할 수 있습니다. 이러한 요구사항이 필요한 경우의 예는 다음과 같습니다.

  • 한 번에 많은 양의 Ingress 리소스를 적용해야 합니다.
  • App Protect가 활성화된 Ingress 리소스가 이미 있는 클러스터에서 처음으로 Ingress Controller를 실행하고 있습니다.

nginx-reload-timeout cli-argument를 설정하여 이 제한 시간을 늘릴 수 있습니다.

사용자 정의 서명 기능을 사용하는 경우 APUserSig를 업데이트하려면 다른 AppProtect 리소스에 비해 NGINX Plus에서 Reload하는 데 더 많은 시간이 필요합니다. 따라서 이 기능을 사용하려는 경우 nginx-reload-timeout을 30초로 늘리는 것이 좋습니다.

Nginx App Protect 정책에서 External References를 사용하는 경우 참조된 리소스를 호스팅하는 서버가 사용 가능한지, 서버의 응답 시간이 가능한 짧은지 확인하십시오(APPolicy External References의 가용성 확인 섹션 참조). Ingress Controller 시작 중에 참조를 사용할 수 없으면 Pod가 시작되지 않습니다. Reload하는 동안 리소스를 사용할 수 없는 경우 Reload가 실패하고 NGINX Plus는 이전의 올바른 구성을 사용합니다.