
DoS Protected 리소스
Note: 이 기능은 AppProtectDos가 포함된 NGINX Plus에서만 사용할 수 있습니다.
Note: 이 기능은 NGINX Plus NGINX App Protect Dos 모듈을 사용하여 구현됩니다.
목차
1. DoS Protected 리소스 사양
1-1. DosProtectedResource.apDosPolicy
1-2. DosProtectedResource.apDosMonitor
1-3. 잘못된 DoS Protected 리소스
1-4. 검증
1-4-1. 구조 검증
1-4-2.포괄적인 검증
1. DoS Protected 리소스 사양
다음은 Dos Protected 리소스의 예입니다.
apiVersion: appprotectdos.f5.com/v1beta1
kind: DosProtectedResource
metadata:
name: dos-protected
spec:
enable: true
name: "my-dos"
apDosMonitor:
uri: "webapp.example.com"
Field | 설명 | Type | Required |
---|---|---|---|
enable | NGINX App Protect DoS를 활성화합니다. | bool | No |
name | 보호된 객체의 이름(최대 63자)입니다. | string | No |
apDosMonitor.uri | 원하는 보호 객체에 대한 대상입니다. App Protect DoS 모니터 기본값: None, “Host” 헤더 또는 대상 IP+Port에서 도착하고 가져오는 첫 번째 요청에서 URL이 추출됩니다. | string | No |
apDosMonitor.protocol | 서버가 http1/http2/grpc에서 수신하는지 확인합니다. App Protect DoS 모니터 기본값: http1. | enum | No |
apDosMonitor.timeout | NGINX App Protect DoS가 응답을 기다려야 하는 시간(s)을 결정합니다. App Protect DoS 모니터 기본값: http1/http2의 경우 10초, grpc의 경우 5초. | int64 | No |
apDosPolicy | dos의 App Protect DoS 정책입니다. 선택적 Namespace를 허용합니다. | string | No |
dosSecurityLog.enable | 보안 Log를 활성화합니다. | bool | No |
dosSecurityLog.apDosLogConf | App Protect DoS Log conf 리소스입니다. 선택적 Namespace를 허용합니다. | string | No |
dosSecurityLog.dosLogDest | 보안 Log의 Log 대상입니다. 허용되는 변수는 syslog:server=<ip-address | localhost | dns-name>:<port> , stderr , <absolute path to file> . 기본값은 'syslog:server=127.0.0.1:514' 입니다. | string | No |
1-1. DosProtectedResource.apDos 정책
apDosPolicy
는 ApDosPolicy
로 정의된 정책 구성에 대한 참조(Namespace/Name
형식의 한정된 식별자)입니다.
1-2. DosProtectedResource.apDosMonitor
이것은 NGINX App Protect DoS가 보호된 객체의 스트레스 Level을 모니터링하는 방법입니다. 모니터 요청은 localhost(127.0.0.1)에서 전송됩니다.
1-3. 잘못된 DoS Protected 리소스
NGINX는 다음 조건 중 하나가 충족되면 DoS Protected 리소스를 유효하지 않은 것으로 처리합니다.
DoS Protected 리소스가 포괄적인 유효성 검사를 통과하지 못습니다.
DoS Protected 리소스가 클러스터에 없습니다.
1-4. 검증
DoS Protected 리소스에 대해 두 가지 유형의 유효성 검사를 사용할 수 있습니다.
kubectl
및 Kubernetes API 서버에서 수행되는 구조적 유효성 검사.- Ingress Controller가 수행하는 포괄적인 유효성 검사입니다.
1-4-1. 구조 검증
dos 보호 리소스에 대한 사용자 정 리소스 정의에는 리소스의 모든 필드 유형을 설명하는 구조적 OpenAPI 스키마가 포함됩니다.
구조적 스키마를 위반하는 리소스를 생성(또는 업데이트)하려고 하면(예: 리소스가 enable
필드에서 bool 대신 문자열 값을 사용함) kubectl
및 Kubernetes API 서버가 리소스를 거부합니다.
kubectl
유효성 검사의 예:
$ kubectl apply -f apdos-protected.yaml
error: error validating "examples/app-protect-dos/apdos-protected.yaml": error validating data: ValidationError(DosProtectedResource.spec.enable): invalid type for com.f5.appprotectdos.v1beta1.DosProtectedResource.spec.enable: got "string", expected "boolean"; if you choose to ignore these errors, turn validation off with --validate=false
- Kubernetes API 서버 유효성 검사의 예:
$ kubectl apply -f access-control-policy-allow.yaml --validate=false
The DosProtectedResource "dos-protected" is invalid: spec.enable: Invalid value: "string": spec.enable in body must be of type boolean: "string"
리소스가 구조적 유효성 검사를 통과하면 Ingress Controller의 포괄적인 유효성 검사가 실행됩니다.
1-4-2.포괄적인 검증
Ingress Controller는 dos Protected 리소스의 필드를 검증합니다. 리소스가 유효하지 않으면 Ingress Controller가 리소스를 거부합니다. 리소스는 클러스터에 계속 존재하지만 Ingress Controller는 이를 무시합니다.
kubectl
을 사용하여 Ingress Controller가 DoS Protected 리소스 구성을 성공적으로 적용했는지 확인할 수 있습니다. 예제 dos-protected dos protected
리소스의 경우 다음을 실행할 수 있습니다.
$ kubectl describe dosprotectedresource dos-protected
. . .
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal AddedOrUpdated 12s (x2 over 18h) nginx-ingress-controller Configuration for default/dos-protected was added or updated
구성이 성공적으로 적용되었음을 알리는 AddedOrUpdated 이유가 있는 Normal 이벤트가 이벤트 섹션에 어떻게 포함되어 있는지 확인하십시오.
잘못된 리소스를 생성하면 Ingress Controller가 이를 거부하고 Rejected 이벤트를 내보냅니다. 예를 들어 dosSecurityLog/dosLogDest
필드에서 bad
URI로 dos-protected
dos Protected 리소스를 만들면 다음과 같은 결과를 얻게 됩니다.
$ kubectl describe policy webapp-policy
. . .
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Warning Rejected 2s nginx-ingress-controller error validating DosProtectedResource: dos-protected invalid field: dosSecurityLog/dosLogDest err: invalid log destination: bad, must follow format: <ip-address | localhost | dns name>:<port> or stderr
이벤트 섹션에 Rejected 이유가 있는 경고 이벤트가 어떻게 포함되어 있는지 확인하십시오.
Note: 기존 리소스를 유효하지 않게 만들면 Ingress Controller가 이를 거부합니다.