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
Copy file name to clipboardexpand all lines: cn/docs/admin/kubelet-authentication-authorization.md
+2-6
Original file line number
Diff line number
Diff line change
@@ -33,11 +33,9 @@ To enable X509 client certificate authentication to the kubelet's HTTPS endpoint
33
33
To enable API bearer tokens (including service account tokens) to be used to authenticate to the kubelet's HTTPS endpoint:
34
34
35
35
* ensure the `authentication.k8s.io/v1beta1` API group is enabled in the API server
36
-
* start the kubelet with the `--authentication-token-webhook`, `--kubeconfig`, and `--require-kubeconfig` flags
36
+
* start the kubelet with the `--authentication-token-webhook`and the `--kubeconfig` flags
37
37
* the kubelet calls the `TokenReview` API on the configured API server to determine user information from bearer tokens
38
38
39
-
**Note:** The flag `--require-kubeconfig` is deprecated as of Kubernetes 1.8, this will be removed in a future version. You no longer need to use `--require-kubeconfig` in Kubernetes 1.8.
40
-
41
39
## Kubelet authorization
42
40
43
41
Any request that is successfully authenticated (including an anonymous request) is then authorized. The default authorization mode is `AlwaysAllow`, which allows all requests.
@@ -51,11 +49,9 @@ There are many possible reasons to subdivide access to the kubelet API:
51
49
To subdivide access to the kubelet API, delegate authorization to the API server:
52
50
53
51
* ensure the `authorization.k8s.io/v1beta1` API group is enabled in the API server
54
-
* start the kubelet with the `--authorization-mode=Webhook`, `--kubeconfig`, and `--require-kubeconfig` flags
52
+
* start the kubelet with the `--authorization-mode=Webhook`and the `--kubeconfig` flags
55
53
* the kubelet calls the `SubjectAccessReview` API on the configured API server to determine whether each request is authorized
56
54
57
-
**Note:** The flag `--require-kubeconfig` is deprecated as of Kubernetes 1.8, this will be removed in a future version. You no longer need to use `--require-kubeconfig` in Kubernetes 1.8.
58
-
59
55
The kubelet authorizes API requests using the same [request attributes](/docs/admin/authorization/#request-attributes) approach as the apiserver.
60
56
61
57
The verb is determined from the incoming request's HTTP verb:
Copy file name to clipboardexpand all lines: docs/admin/admission-controllers.md
+44-32
Original file line number
Diff line number
Diff line change
@@ -31,8 +31,7 @@ controllers may modify the objects they admit; validating controllers may not.
31
31
The admission control process proceeds in two phases. In the first phase,
32
32
mutating admission controllers are run. In the second phase, validating
33
33
admission controllers are run. Note again that some of the controllers are
34
-
both. In both phases, the controllers are run in the order specified by the
35
-
`--admission-control` flag of `kube-apiserver`.
34
+
both.
36
35
37
36
If any of the controllers in either phase reject the request, the entire
38
37
request is rejected immediately and an error is returned to the end-user.
@@ -54,13 +53,12 @@ support all the features you expect.
54
53
55
54
## How do I turn on an admission controller?
56
55
57
-
The Kubernetes API server supports a flag, `admission-control` that takes a comma-delimited,
58
-
ordered list of admission control choices to invoke prior to modifying objects in the cluster.
59
-
For example, the following command line turns on the `NamespaceLifecycle` and the `LimitRanger`
60
-
admission controller:
56
+
The Kubernetes API server flag `enable-admission-plugins` takes a comma-delimited list of admission control plugins to invoke prior to modifying objects in the cluster.
57
+
For example, the following command line enables the `NamespaceLifecycle` and the `LimitRanger`
**Note**: Depending on the way your Kubernetes cluster is deployed and how the
@@ -70,11 +68,19 @@ deployed as a systemd service, you may modify the manifest file for the API
70
68
server if Kubernetes is deployed in a self-hosted way.
71
69
{: .note}
72
70
71
+
## How do I turn off an admission controller?
72
+
73
+
The Kubernetes API server flag `disable-admission-plugins` takes a comma-delimited list of admission control plugins to be disabled, even if they are in the list of plugins enabled by default.
Use this admission controller by itself to pass-through all requests.
83
+
Use this admission controller by itself to pass-through all requests. AlwaysAdmit is DEPRECATED as no real meaning.
78
84
79
85
### AlwaysPullImages
80
86
@@ -86,9 +92,9 @@ scheduled onto the right node), without any authorization check against the imag
86
92
is enabled, images are always pulled prior to starting containers, which means valid credentials are
87
93
required.
88
94
89
-
### AlwaysDeny
95
+
### AlwaysDeny (DEPRECATED)
90
96
91
-
Rejects all requests. Used for testing.
97
+
Rejects all requests. AlwaysDeny is DEPRECATED as no real meaning.
92
98
93
99
### DefaultStorageClass
94
100
@@ -134,7 +140,7 @@ enabling this admission controller.
134
140
135
141
### EventRateLimit (alpha)
136
142
137
-
This admission controller is introduced in v1.9 to mitigate the problem where the API server gets flooded by
143
+
This admission controller mitigates the problem where the API server gets flooded by
138
144
event requests. The cluster admin can specify event rate limits by:
139
145
140
146
* Ensuring that `eventratelimit.admission.k8s.io/v1alpha1=true` is included in the
@@ -180,19 +186,15 @@ for more details.
180
186
181
187
### ExtendedResourceToleration
182
188
183
-
This plug-in is introduced in v1.9 to facilitate creation of dedicated nodes with extended resources.
189
+
This plug-in facilitates creation of dedicated nodes with extended resources.
184
190
If operators want to create dedicated nodes with extended resources (like GPUs, FPGAs etc.), they are expected to
185
191
taint the node with the extended resource name as the key. This admission controller, if enabled, automatically
186
192
adds tolerations for such taints to pods requesting extended resources, so users don't have to manually
187
193
add these tolerations.
188
194
189
195
### ImagePolicyWebhook
190
196
191
-
The ImagePolicyWebhook admission controller allows a backend webhook to make admission decisions. You enable this admission controller by setting the admission-control option as follows:
192
-
193
-
```shell
194
-
--admission-control=ImagePolicyWebhook
195
-
```
197
+
The ImagePolicyWebhook admission controller allows a backend webhook to make admission decisions.
196
198
197
199
#### Configuration File Format
198
200
@@ -314,7 +316,6 @@ In any case, the annotations are provided by the user and are not validated by K
314
316
315
317
### Initializers (alpha)
316
318
317
-
This admission controller is introduced in v1.7.
318
319
The admission controller determines the initializers of a resource based on the existing
319
320
`InitializerConfiguration`s. It sets the pending initializers by modifying the
320
321
metadata of the resource to be created.
@@ -331,7 +332,7 @@ The annotations added contain the information on what compute resources were aut
331
332
332
333
See the [InitialResources proposal](https://git.k8s.io/community/contributors/design-proposals/autoscaling/initial-resources.md) for more details.
333
334
334
-
### LimitPodHardAntiAffinity
335
+
### LimitPodHardAntiAffinityTopology
335
336
336
337
This admission controller denies any pod that defines `AntiAffinity` topology key other than
@@ -414,27 +415,23 @@ This admission controller also protects the access to `metadata.ownerReferences[
414
415
of an object, so that only users with "update" permission to the `finalizers`
415
416
subresource of the referenced *owner* can change it.
416
417
417
-
### Persistent Volume Claim Protection (alpha)
418
-
{% assign for_k8s_version="v1.9" %}{% include feature-state-alpha.md %}
419
-
The `PVCProtection` plugin adds the `kubernetes.io/pvc-protection` finalizer to newly created Persistent Volume Claims (PVCs). In case a user deletes a PVC the PVC is not removed until the finalizer is removed from the PVC by PVC Protection Controller. Refer to the [PVC Protection](/docs/concepts/storage/persistent-volumes/#persistent-volume-claim-protection) for more detailed information.
420
-
421
-
### PersistentVolumeLabel
418
+
### PersistentVolumeLabel (DEPRECATED)
422
419
423
420
This admission controller automatically attaches region or zone labels to PersistentVolumes
424
421
as defined by the cloud provider (for example, GCE or AWS).
425
422
It helps ensure the Pods and the PersistentVolumes mounted are in the same
426
423
region and/or zone.
427
424
If the admission controller doesn't support automatic labelling your PersistentVolumes, you
428
425
may need to add the labels manually to prevent pods from mounting volumes from
429
-
a different zone.
426
+
a different zone. PersistentVolumeLabel is DEPRECATED and labeling persistent volumes has been taken over by [cloud controller manager](/docs/tasks/administer-cluster/running-cloud-controller/).
430
427
431
428
### PodNodeSelector
432
429
433
430
This admission controller defaults and limits what node selectors may be used within a namespace by reading a namespace annotation and a global configuration.
434
431
435
432
#### Configuration File Format
436
433
437
-
PodNodeSelector uses a configuration file to set options for the behavior of the backend.
434
+
`PodNodeSelector`uses a configuration file to set options for the behavior of the backend.
438
435
Note that the configuration file format will move to a versioned file in a future release.
439
436
This file may be json or yaml and has the following format:
440
437
@@ -445,7 +442,7 @@ podNodeSelectorPluginConfig:
445
442
namespace2: <node-selectors-labels>
446
443
```
447
444
448
-
Reference the PodNodeSelector configuration file from the file provided to the API server's command line flag `--admission-control-config-file`:
445
+
Reference the `PodNodeSelector` configuration file from the file provided to the API server's command line flag `--admission-control-config-file`:
449
446
450
447
```yaml
451
448
kind: AdmissionConfiguration
@@ -457,7 +454,7 @@ plugins:
457
454
```
458
455
459
456
#### Configuration Annotation Format
460
-
PodNodeSelector uses the annotation key `scheduler.alpha.kubernetes.io/node-selector` to assign node selectors to namespaces.
457
+
`PodNodeSelector`uses the annotation key `scheduler.kubernetes.io/node-selector` to assign node selectors to namespaces.
461
458
462
459
```yaml
463
460
apiVersion: v1
@@ -468,6 +465,19 @@ metadata:
468
465
name: namespace3
469
466
```
470
467
468
+
#### Internal Behavior
469
+
This admission controller has the following behavior:
470
+
1. If the `Namespace` has an annotation with a key `scheduler.kubernetes.io/nodeSelector`, use its value as the
471
+
node selector.
472
+
1. If the namespace lacks such an annotation, use the `clusterDefaultNodeSelector` defined in the `PodNodeSelector`
473
+
plugin configuration file as the node selector.
474
+
1. Evaluate the pod's node selector against the namespace node selector for conflicts. Conflicts result in rejection.
475
+
1. Evaluate the pod's node selector against the namespace-specific whitelist defined the plugin configuration file.
476
+
Conflicts result in rejection.
477
+
478
+
**Note:** `PodTolerationRestriction` is more versatile and powerful than `PodNodeSelector` and can encompass the scenarios supported by `PodNodeSelector`.
479
+
{: .note}
480
+
471
481
### PersistentVolumeClaimResize
472
482
473
483
This admission controller implements additional validations for checking incoming `PersistentVolumeClaim` resize requests.
@@ -545,8 +555,6 @@ objects in your Kubernetes deployment, you MUST use this admission controller to
545
555
546
556
See the [resourceQuota design doc](https://git.k8s.io/community/contributors/design-proposals/resource-management/admission_control_resource_quota.md) and the [example of Resource Quota](/docs/concepts/policy/resource-quotas/) for more details.
547
557
548
-
It is strongly encouraged that this admission controller is configured last in the sequence of admission controllers. This is
549
-
so that quota is not prematurely incremented only for the request to be rejected later in admission control.
550
558
551
559
### SecurityContextDeny
552
560
@@ -557,6 +565,10 @@ This admission controller will deny any pod that attempts to set certain escalat
557
565
This admission controller implements automation for [serviceAccounts](/docs/user-guide/service-accounts).
558
566
We strongly recommend using this admission controller if you intend to make use of Kubernetes `ServiceAccount` objects.
559
567
568
+
### Storage Object in Use Protection (beta)
569
+
{% assign for_k8s_version="v1.10" %}{% include feature-state-beta.md %}
570
+
The `StorageObjectInUseProtection` plugin adds the `kubernetes.io/pvc-protection` or `kubernetes.io/pv-protection` finalizers to newly created Persistent Volume Claims (PVCs) or Persistent Volumes (PV). In case a user deletes a PVC or PV the PVC or PV is not removed until the finalizer is removed from the PVC or PV by PVC or PV Protection Controller. Refer to the [Storage Object in Use Protection](/docs/concepts/storage/persistent-volumes/#storage-object-in-use-protection) for more detailed information.
571
+
560
572
### ValidatingAdmissionWebhook (alpha in 1.8; beta in 1.9)
561
573
562
574
This admission controller calls any validating webhooks which match the request. Matching
@@ -577,7 +589,7 @@ versions >= 1.9).
577
589
## Is there a recommended set of admission controllers to use?
578
590
579
591
Yes.
580
-
For Kubernetes >= 1.9.0, we strongly recommend running the following set of admission controllers (order matters):
592
+
For Kubernetes >= 1.9.0, we strongly recommend running the following set of admission controllers (order matters for 1.9 but not >1.10):
0 commit comments