@@ -124,7 +124,7 @@ authorizers:
124
124
kubeConfigFile : /kube-system-authz-webhook.yaml
125
125
matchConditions :
126
126
- expression : |
127
- request.resourceAttributes. namespace == 'kube-system'
127
+ has( request.resourceAttributes) && (request.resourceAttributes. namespace == 'kube-system')
128
128
- expression : |
129
129
!('system:serviceaccounts:kube-system' in request.user.groups)
130
130
- type : Node
@@ -214,6 +214,15 @@ path to a file on the disk. Setting both `--authorization-config-file` and
214
214
configuring an authorization webhook will not be allowed. If the user does that,
215
215
there will be an error and API Server would exit right away.
216
216
217
+ The configuration would be validated at startup and the API server will fail to
218
+ start if the configuration is invalid.
219
+
220
+ The API server will periodically reload the configuration. If it changes, the
221
+ new configuration will be used for the Authorizer chain. If the new configuration
222
+ is invalid, the last known valid configuration will be used. Logging and metrics
223
+ would be used to signal success/failure of a config reload so that cluster admins
224
+ can have observability over this process.
225
+
217
226
The proposed structure is illustrated below :
218
227
219
228
> The sample configuration describes all the fields, their defaults and possible
@@ -290,7 +299,7 @@ authorizers:
290
299
# in the version specified by subjectAccessReviewVersion in the request variable.
291
300
# Documentation on CEL: https://kubernetes.io/docs/reference/using-api/cel/
292
301
- expression : |
293
- request.resourceAttributes. namespace == 'kube-system'
302
+ has( request.resourceAttributes) && (request.resourceAttributes. namespace == 'kube-system')
294
303
- expression : |
295
304
!('system:serviceaccounts:kube-system' in request.user.groups)
296
305
- type : Node
@@ -372,6 +381,9 @@ Labels {along with possible values}:
372
381
- ` code` {4xx, 5xx}
373
382
- ` decision` {Deny, NoOpinion}
374
383
384
+ 5. `apiserver_authorization_step_configuration_reload_failure_count`
385
+
386
+ This metric would track the number of times the configuration has been reloaded.
375
387
376
388
# ## Test Plan
377
389
0 commit comments