You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Extend resource validation doc to include NGF resources (#1399)
Problem: The resource validation doc does not include information
on how we validate NGINX Gateway Fabric resources.
Solution: Add a section on NGINX Gateway Fabric resources to the resource validation doc.
Copy file name to clipboardExpand all lines: site/content/overview/resource-validation.md
+69-6
Original file line number
Diff line number
Diff line change
@@ -1,12 +1,16 @@
1
1
---
2
-
title: "Gateway API Resource Validation"
2
+
title: "Resource Validation"
3
3
weight: 800
4
4
toc: true
5
5
docs: "DOCS-000"
6
6
---
7
7
8
8
## Overview
9
9
10
+
This document describes how NGINX Gateway Fabric validates Gateway API and NGINX Gateway Fabric Kubernetes resources.
11
+
12
+
## Gateway API Resource Validation
13
+
10
14
NGINX Gateway Fabric validates Gateway API resources for several reasons:
11
15
12
16
-_Robustness_: to gracefully handle invalid resources.
@@ -15,7 +19,7 @@ NGINX Gateway Fabric validates Gateway API resources for several reasons:
15
19
16
20
The process involves four different steps, explained in detail in this document, with the goal of making sure that NGINX continues to handle traffic even if invalid Gateway API resources were created.
17
21
18
-
## Step 1 - OpenAPI Scheme validation by Kubernetes API Server
22
+
###Step 1 - OpenAPI Scheme validation by Kubernetes API Server
19
23
20
24
The Kubernetes API server validates Gateway API resources against the OpenAPI schema embedded in the Gateway API CRDs. For example, if you create an HTTPRoute with an invalid hostname "cafe.!@#$%example.com", the API server will reject it with the following error:
21
25
@@ -29,7 +33,7 @@ The HTTPRoute "coffee" is invalid: spec.hostnames[0]: Invalid value: "cafe.!@#$%
29
33
30
34
{{< note >}}While unlikely, bypassing this validation step is possible if the Gateway API CRDs are modified to remove the validation. If this happens, Step 4 will reject any invalid values (from NGINX perspective).{{< /note >}}
31
35
32
-
## Step 2 - CEL or Webhook validation by Kubernetes
36
+
###Step 2 - CEL or Webhook validation by Kubernetes
33
37
34
38
-**Kubernetes 1.25 and later - CEL validation by Kubernetes API Server**
35
39
@@ -60,7 +64,7 @@ The HTTPRoute "coffee" is invalid: spec.hostnames[0]: Invalid value: "cafe.!@#$%
60
64
61
65
{{< note >}}Bypassing this validation step is possible if the webhook is not running in the cluster. If this happens, Step 3 will reject the invalid values.{{< /note >}}
62
66
63
-
## Step 3 - Webhook validation by NGINX Gateway Fabric
67
+
###Step 3 - Webhook validation by NGINX Gateway Fabric
64
68
65
69
To ensure that the resources are validated with the webhook validation rules, even if the webhook is not running, NGINX Gateway Fabric performs the same validation. However, NGINX Gateway Fabric performs the validation _after_ the Kubernetes API server accepts the resource.
66
70
@@ -80,7 +84,7 @@ Events:
80
84
81
85
{{< note >}}This validation step always runs and cannot be bypassed. NGINX Gateway Fabric will ignore any resources that fail the webhook validation, like in the example above. If the resource previously existed, NGINX Gateway Fabric will remove any existing NGINX configuration for that resource.{{< /note >}}
82
86
83
-
## Step 4 - Validation by NGINX Gateway Fabric
87
+
###Step 4 - Validation by NGINX Gateway Fabric
84
88
85
89
This step catches the following cases of invalid values:
86
90
@@ -117,7 +121,7 @@ Status:
117
121
118
122
{{< note >}}This validation step always runs and cannot be bypassed.{{< /note >}}
119
123
120
-
## Confirm validation
124
+
###Confirm validation
121
125
122
126
To confirm that a resource is valid and accepted by NGINX Gateway Fabric, check that the **Accepted** condition in the resource status has the Status field set to **True**. For example, in a status of a valid HTTPRoute, if NGINX Gateway Fabric accepts a parentRef, the status of that parentRef will look like this:
123
127
@@ -141,3 +145,62 @@ Status:
141
145
```
142
146
143
147
{{< note>}}Make sure the reported observed generation is the same as the resource generation.{{< /note >}}
148
+
149
+
## NGINX Gateway Fabric Resource Validation
150
+
151
+
### Step 1 - OpenAPI Scheme validation by Kubernetes API Server
152
+
153
+
The Kubernetes API server validates NGINX Gateway Fabric resources against the OpenAPI schema embedded in the NGINX Gateway Fabric CRDs. For example, if you create an NginxGateway with an invalid logging level, "some-level", the API server will reject it with the following error:
154
+
155
+
```shell
156
+
kubectl apply -f nginx-gateway-config.yaml
157
+
```
158
+
159
+
```text
160
+
The NginxGateway "nginx-gateway-config" is invalid: spec.logging.level: Unsupported value: "some-level": supported values: "info", "debug", "error"
161
+
```
162
+
163
+
{{< note >}}While unlikely, bypassing this validation step is possible if the NGINX Gateway Fabric CRDs are modified to remove the validation. If this happens, Step 2 will report an error in the resource's status.{{< /note >}}
164
+
165
+
### Step 2 - Validation by NGINX Gateway Fabric
166
+
167
+
This step validates the settings in the NGINX Gateway Fabric CRDs and rejects invalid resources. The validation error is reported via the status and as an Event. For example:
Message: Failed to update control plane configuration: logging.level: Unsupported value: "some-level": supported values: "info", "debug", "error"
181
+
Observed Generation: 1
182
+
Reason: Invalid
183
+
Status: False
184
+
Type: Valid
185
+
```
186
+
187
+
Event:
188
+
189
+
```text
190
+
Warning UpdateFailed 1s (x2 over 1s) nginx-gateway-fabric-nginx Failed to update control plane configuration: logging.level: Unsupported value: "some-level": supported values: "info", "debug", "error"
191
+
```
192
+
193
+
### Confirm validation
194
+
195
+
To confirm that a resource is valid and accepted by NGINX Gateway Fabric, check that the **Valid** condition in the resource status has the Status field set to **True**. For example, the status of a valid NginxGateway will look like this:
0 commit comments