Merge 1.10 to master for release (#7861)
* 1.10 update (#7151) * Fix partition value expected behaviour explanation (#7123) Fixes issue #7057 * Correct "On-Premise" to "On-Premises" * Updates the Calico installation page (#7094) * All files for Haufe Groups case study (#7051) * Fix typo (#7127) * fix typo of device-plugins.md (#7106) * fix broken links (#7136) * Updated configure-service-account (#7147) Error from server resolved by escaping kubectl patch serviceaccount default -p '{"imagePullSecrets": [{"name": "myregistrykey"}]}' JSON string by '\' * Remove docs related to 'require-kubeconfig' (#7138) With kubernetes/kubernetes#58367 merged, v1.10 will not use the "require-kubeconfig" flag. The flag has become a no-op solely to ensure existing deployments won't break. * Added Verification Scenario for a Pod that Uses a PVC in Terminating State (#7164) The below PR: https://github.com/kubernetes/kubernetes/pull/55873 modified scheduler in such a way that scheduling of a pod that uses a PVC in Terminating state fails. That's why verification of such scenario was added to documentation. * fix LimitPodHardAntiAffinityTopology name (#7221) * Document the removal of the KubeletConfigFile feature gate (#7140) With kubernetes/kubernetes#58978 merged, the said feature gate is removed. This PR removes texts related to the gate and revises the Feature Gates reference to reflect this change. * deprecate three admission controller (#7363) * Document the removal of Accelerators feature gate (#7389) The `Accelerators` feature gate will be removed in 1.11. 1.10 will be its last mile. References: kubernetes/kubernetes#57384 * Update local storage docs for beta (#7473) * Document that HugePages feature gate is Beta (#7387) The `HugePages` feature gate has graduated to Beta in v1.10. This PR documents this fact. * Add HyperVContainer feature gates (#7502) * Remove the beta reference from Taints and Tolerations doc (#7493) * Kms provider doc (#7479) * Kms provider doc * issue# 7399, Create KMS-provider.md and update encrypt-data.md * address review comments * Document that Device Plugin feature is Beta (1.10) (#7512) * Add docs for CRD features for 1.10 (#7439) * Add docs for CRD features for 1.10 * Add CustomResourcesSubresources to list of feature gates * Add latest changes to custom resources doc * Add crds as abbreviated alias (#7437) * Bring PVC Protection Feature to Beta (#7165) * Bring PVC Protection Feature to Beta The PR: https://github.com/kubernetes/kubernetes/pull/59052 brought PVC Protection feature to beta. That's why the documentation is updated accordingly. * The PVC Protection feature was renamed to Storage Protection. That's why the documentation is updated. * promote PodNodeSelector to stable; document detailed behavior (#7134) * promote PodNodeSelector to stable; document detailed behavior * respond to feedback * Update CPU manager feature enabling (#7390) With `CPUManager` feature graduating to beta. No explicit enabling is required starting v1.10. References: kubernetes/kubernetes#55977 * Adding block volumeMode documentation for local volumes. (#7531) Code review comments. Changed property to field. Address tech review comment. * remove description kubectl --show-all (#7574) --show-all has been deprecated and set to true by default. https://github.com/kubernetes/kubernetes/pull/60210 * fix description about contribute style guide (#7592) * fix description about KUBECONFIG (#7589) s/envrionment/environment * fix description about cni (#7588) s/simultanously/simultaneously/ * fix description about MutatingAdmissionWebhook and ValidatingAdmissionWebhook (#7587) * fix description about persistent volume binding (#7590) s/slighty/slightly/ * Doc change for configurable pod resolv.conf Beta (#7611) * fix description about out of resource handling (#7597) s/threshhold/threshold * fix description about zookeeper (#7598) s/achive/achieve * fix description about kubeadm (#7594) s/compatability/compatibility/ * fix description about kubeadm (#7593) * fix description about kubeadm implementation details (#7595) * fix description about api concepts (#7596) * Storage Protection was renamed to Storage Object in Use Protection (#7576) * Storage Protection was renamed to Storage Object in Use Protection The K8s PR: https://github.com/kubernetes/kubernetes/pull/59901 renamed Storage Protection to Storage Object in Use Protection. That's why the same is also renamed in the documentation. * Moved Storage Object in Use Protection admission plugin description down according to alphabetic order. * Use PSP from policy API group. (#7562) * update kubeletconfig docs for v1.10, beta (#7561) * Update port-forwarding docs (#7575) * add pv protection description (#7620) * fix description about client library (#7634) * Add docs on configuring NodePort IP (#7631) * Document that LocalStorageCapacityIsolation is beta (#7635) A follow-up to the kubernetes/kubernetes#60159 change which has promoted the `LocalStorageCapacityIsolation` feature gate to Beta. * Update CoreDNS docs for beta (#7638) * Update CoreDNS docs for beta * Review comments * Fix typo (#7640) * Update feature gates move to beta (#7662) * Added the inability to use colon ':' character as environment variable names and described workaround (#7657) * merge master to 1.10, with fixes (#7682) * Flag names changed (s/admission-control/enable-admission-plugins); disable-admissions-plugin entry added; removed reference to admission controller/plugins requiring set order (for v1.10), redundant example enabling specific plugin, and redundant version-specific info (#7449) * Documentation for MountPropagation beta (#7655) * Remove job's scale-related operations (#7684) * authentication: document client-go exec plugins (#7648) * authentication: document client-go exec plugins * Update authentication.md * Update local ephemeral storage feature to beta (#7685) Update local ephemeral storage feature to beta * Update docs for windows container resources (#7653) * add server-side print docs (#7671) * Create a task describing Pod process namespace sharing (#7489) * Add external metrics to HPA docs (#7664) * Add external metrics to HPA docs * Update horizontal-pod-autoscale-walkthrough.md * Apply review comments to HPA walkthrough * remove description about "scale jobs" (#7712) * CSI Docs for K8s v1.10 (#7698) * Add a warning about increased memory consumption for audit logging feature. (#7725) Signed-off-by: Mik Vyatskov <vmik@google.com> * Update Audit Logging documentation for 1.10 (#7679) Signed-off-by: Mik Vyatskov <vmik@google.com> * Fix stage names in audit logging documentation (#7746) Signed-off-by: Mik Vyatskov <vmik@google.com> * Feature gate update for release 1.10 (#7742) * State in the docs that the value of default Node labels are not reliable. (#7794) * Kill the reference to --admission-control option (#7755) The `--admission-control` option has been replaced by two new options in v1.10. This PR kills the last appearance of the old option in the doc. * Pvcprotection toc (#7807) * Refreshing installation instructions (#7495) * Refreshing installation instructions Added conjure-up. Updated displays and juju versions to current versions. * Updated anchors * Fixed image value version typo (#7768) Was inconsistent with other values * Update flocker reference to the github repo (#7784) * Fix typo in federation document (#7779) * an user -> a user (#7778) * Events are namespaced (#7767) * fix 'monitoring' link lose efficacy problem' (#7764) * docs/concepts/policy/pod-security-policy.md: minor fix. (#7659) * Update downward-api-volume-expose-pod-information.md (#7771) * Update downward-api-volume-expose-pod-information.md The pod spec puts the downward api files into /etc/podinfo, not directly in /etc. Updated docs to reflect this fact. * Update downward-api-volume-expose-pod-information.md One more spot needed fixing. * Update downward-api-volume-expose-pod-information.md Yet another fix, in the container example. * Add Amadeus Case Study (#7783) * Add Amadeus Case Study * add Amadeus logo * Fixed Cyrillic с in 'kube-proxy-cm' (#7787) There was a typo (wrong character) in kube-proxy-cm.yaml - Cyrillic с (UTF-8 0x0441) was used instead of Latin c. * install-kubectl: choose one installation method (#7705) The previous text layout suggested that all installations had to be done, one after another. * Update install-kubeadm.md (#7781) Add note to kubeadm install instruction to help install in other arch i.e. aarch64, ppc64le etc. * repair failure link (#7788) * repair failure link * repair failure link * do change as required * Update k8s201.md (#7777) * Update k8s201.md Change instructions to download yams files directly from the website (as used in other pages.) Added instructions to delete labeled pod to avoid warnings in the subsequent deployment step. * Update k8s201.md Added example of using the exposed host from the a node running Kubernetes. (This works on AWS with Weave; not able to test it on other variations...) * Gramatical fix to kompose introduction (#7792) The original wording didn't through very well. As much of the original sentence has been preserved as possible, primarily to ensure the kompose web address is see both in text and as a href link. * update amadeus.html (#7800) * Fix a missing word in endpoint reconciler section (#7804) * add toc entry for pvcprotection downgrade issue doc * Pvcprotection toc (#7809) * Refreshing installation instructions (#7495) * Refreshing installation instructions Added conjure-up. Updated displays and juju versions to current versions. * Updated anchors * Fixed image value version typo (#7768) Was inconsistent with other values * Update flocker reference to the github repo (#7784) * Fix typo in federation document (#7779) * an user -> a user (#7778) * Events are namespaced (#7767) * fix 'monitoring' link lose efficacy problem' (#7764) * docs/concepts/policy/pod-security-policy.md: minor fix. (#7659) * Update downward-api-volume-expose-pod-information.md (#7771) * Update downward-api-volume-expose-pod-information.md The pod spec puts the downward api files into /etc/podinfo, not directly in /etc. Updated docs to reflect this fact. * Update downward-api-volume-expose-pod-information.md One more spot needed fixing. * Update downward-api-volume-expose-pod-information.md Yet another fix, in the container example. * Add Amadeus Case Study (#7783) * Add Amadeus Case Study * add Amadeus logo * Fixed Cyrillic с in 'kube-proxy-cm' (#7787) There was a typo (wrong character) in kube-proxy-cm.yaml - Cyrillic с (UTF-8 0x0441) was used instead of Latin c. * install-kubectl: choose one installation method (#7705) The previous text layout suggested that all installations had to be done, one after another. * Update install-kubeadm.md (#7781) Add note to kubeadm install instruction to help install in other arch i.e. aarch64, ppc64le etc. * repair failure link (#7788) * repair failure link * repair failure link * do change as required * Update k8s201.md (#7777) * Update k8s201.md Change instructions to download yams files directly from the website (as used in other pages.) Added instructions to delete labeled pod to avoid warnings in the subsequent deployment step. * Update k8s201.md Added example of using the exposed host from the a node running Kubernetes. (This works on AWS with Weave; not able to test it on other variations...) * Gramatical fix to kompose introduction (#7792) The original wording didn't through very well. As much of the original sentence has been preserved as possible, primarily to ensure the kompose web address is see both in text and as a href link. * update amadeus.html (#7800) * Fix a missing word in endpoint reconciler section (#7804) * add toc entry for pvcprotection downgrade issue doc * revert TOC change * Release 1.10 (#7818) * Refreshing installation instructions (#7495) * Refreshing installation instructions Added conjure-up. Updated displays and juju versions to current versions. * Updated anchors * Fixed image value version typo (#7768) Was inconsistent with other values * Update flocker reference to the github repo (#7784) * Fix typo in federation document (#7779) * an user -> a user (#7778) * Events are namespaced (#7767) * fix 'monitoring' link lose efficacy problem' (#7764) * docs/concepts/policy/pod-security-policy.md: minor fix. (#7659) * Update downward-api-volume-expose-pod-information.md (#7771) * Update downward-api-volume-expose-pod-information.md The pod spec puts the downward api files into /etc/podinfo, not directly in /etc. Updated docs to reflect this fact. * Update downward-api-volume-expose-pod-information.md One more spot needed fixing. * Update downward-api-volume-expose-pod-information.md Yet another fix, in the container example. * Add Amadeus Case Study (#7783) * Add Amadeus Case Study * add Amadeus logo * Fixed Cyrillic с in 'kube-proxy-cm' (#7787) There was a typo (wrong character) in kube-proxy-cm.yaml - Cyrillic с (UTF-8 0x0441) was used instead of Latin c. * install-kubectl: choose one installation method (#7705) The previous text layout suggested that all installations had to be done, one after another. * Update install-kubeadm.md (#7781) Add note to kubeadm install instruction to help install in other arch i.e. aarch64, ppc64le etc. * repair failure link (#7788) * repair failure link * repair failure link * do change as required * Update k8s201.md (#7777) * Update k8s201.md Change instructions to download yams files directly from the website (as used in other pages.) Added instructions to delete labeled pod to avoid warnings in the subsequent deployment step. * Update k8s201.md Added example of using the exposed host from the a node running Kubernetes. (This works on AWS with Weave; not able to test it on other variations...) * Gramatical fix to kompose introduction (#7792) The original wording didn't through very well. As much of the original sentence has been preserved as possible, primarily to ensure the kompose web address is see both in text and as a href link. * update amadeus.html (#7800) * Fix a missing word in endpoint reconciler section (#7804) * Partners page updates (#7802) * Partners page updates * Update to ZTE link * Make using sysctls a task instead of a concept (#6808) Closes: #4505 * add a note when mount a configmap to pod (#7745) * adjust a note format (#7812) * Update docker-cli-to-kubectl.md (#7748) * Update docker-cli-to-kubectl.md Edited the document for adherence to the style guide and word usage. * Update docker-cli-to-kubectl.md * Incorporated the changes suggested. * Mount propagation update to include docker config (#7854) * update overridden config for 1.10 (#7847) * update overridden config for 1.10 * fix config file per comments * Update Extended Resource doc wrt cluster-level resources (#7759)
This commit is contained in:
Jennifer Rondeau
committed by
Steve Perry
Steve Perry
parent
770440d20f
commit
409e77d3e5
@@ -31,8 +31,7 @@ controllers may modify the objects they admit; validating controllers may not.
|
||||
The admission control process proceeds in two phases. In the first phase,
|
||||
mutating admission controllers are run. In the second phase, validating
|
||||
admission controllers are run. Note again that some of the controllers are
|
||||
both. In both phases, the controllers are run in the order specified by the
|
||||
`--admission-control` flag of `kube-apiserver`.
|
||||
both.
|
||||
|
||||
If any of the controllers in either phase reject the request, the entire
|
||||
request is rejected immediately and an error is returned to the end-user.
|
||||
@@ -54,13 +53,12 @@ support all the features you expect.
|
||||
|
||||
## How do I turn on an admission controller?
|
||||
|
||||
The Kubernetes API server supports a flag, `admission-control` that takes a comma-delimited,
|
||||
ordered list of admission control choices to invoke prior to modifying objects in the cluster.
|
||||
For example, the following command line turns on the `NamespaceLifecycle` and the `LimitRanger`
|
||||
admission controller:
|
||||
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.
|
||||
For example, the following command line enables the `NamespaceLifecycle` and the `LimitRanger`
|
||||
admission control plugins:
|
||||
|
||||
```shell
|
||||
kube-apiserver --admission-control=NamespaceLifecyle,LimitRanger ...
|
||||
kube-apiserver --enable-admission-plugins=NamespaceLifecyle,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
|
||||
server if Kubernetes is deployed in a self-hosted way.
|
||||
{: .note}
|
||||
|
||||
## How do I turn off an admission controller?
|
||||
|
||||
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.
|
||||
|
||||
```shell
|
||||
kube-apiserver --disable-admission-plugins=PodNodeSelector,AlwaysDeny ...
|
||||
```
|
||||
|
||||
## What does each admission controller do?
|
||||
|
||||
### AlwaysAdmit
|
||||
### AlwaysAdmit (DEPRECATED)
|
||||
|
||||
Use this admission controller by itself to pass-through all requests.
|
||||
Use this admission controller by itself to pass-through all requests. AlwaysAdmit is DEPRECATED as no real meaning.
|
||||
|
||||
### AlwaysPullImages
|
||||
|
||||
@@ -86,9 +92,9 @@ scheduled onto the right node), without any authorization check against the imag
|
||||
is enabled, images are always pulled prior to starting containers, which means valid credentials are
|
||||
required.
|
||||
|
||||
### AlwaysDeny
|
||||
### AlwaysDeny (DEPRECATED)
|
||||
|
||||
Rejects all requests. Used for testing.
|
||||
Rejects all requests. AlwaysDeny is DEPRECATED as no real meaning.
|
||||
|
||||
### DefaultStorageClass
|
||||
|
||||
@@ -134,7 +140,7 @@ enabling this admission controller.
|
||||
|
||||
### EventRateLimit (alpha)
|
||||
|
||||
This admission controller is introduced in v1.9 to mitigate the problem where the API server gets flooded by
|
||||
This admission controller mitigates the problem where the API server gets flooded by
|
||||
event requests. The cluster admin can specify event rate limits by:
|
||||
|
||||
* Ensuring that `eventratelimit.admission.k8s.io/v1alpha1=true` is included in the
|
||||
@@ -180,7 +186,7 @@ for more details.
|
||||
|
||||
### ExtendedResourceToleration
|
||||
|
||||
This plug-in is introduced in v1.9 to facilitate creation of dedicated nodes with extended resources.
|
||||
This plug-in facilitates creation of dedicated nodes with extended resources.
|
||||
If operators want to create dedicated nodes with extended resources (like GPUs, FPGAs etc.), they are expected to
|
||||
taint the node with the extended resource name as the key. This admission controller, if enabled, automatically
|
||||
adds tolerations for such taints to pods requesting extended resources, so users don't have to manually
|
||||
@@ -188,11 +194,7 @@ add these tolerations.
|
||||
|
||||
### ImagePolicyWebhook
|
||||
|
||||
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:
|
||||
|
||||
```shell
|
||||
--admission-control=ImagePolicyWebhook
|
||||
```
|
||||
The ImagePolicyWebhook admission controller allows a backend webhook to make admission decisions.
|
||||
|
||||
#### Configuration File Format
|
||||
|
||||
@@ -314,7 +316,6 @@ In any case, the annotations are provided by the user and are not validated by K
|
||||
|
||||
### Initializers (alpha)
|
||||
|
||||
This admission controller is introduced in v1.7.
|
||||
The admission controller determines the initializers of a resource based on the existing
|
||||
`InitializerConfiguration`s. It sets the pending initializers by modifying the
|
||||
metadata of the resource to be created.
|
||||
@@ -331,7 +332,7 @@ The annotations added contain the information on what compute resources were aut
|
||||
|
||||
See the [InitialResources proposal](https://git.k8s.io/community/contributors/design-proposals/autoscaling/initial-resources.md) for more details.
|
||||
|
||||
### LimitPodHardAntiAffinity
|
||||
### LimitPodHardAntiAffinityTopology
|
||||
|
||||
This admission controller denies any pod that defines `AntiAffinity` topology key other than
|
||||
`kubernetes.io/hostname` in `requiredDuringSchedulingRequiredDuringExecution`.
|
||||
@@ -414,11 +415,7 @@ This admission controller also protects the access to `metadata.ownerReferences[
|
||||
of an object, so that only users with "update" permission to the `finalizers`
|
||||
subresource of the referenced *owner* can change it.
|
||||
|
||||
### Persistent Volume Claim Protection (alpha)
|
||||
{% assign for_k8s_version="v1.9" %}{% include feature-state-alpha.md %}
|
||||
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.
|
||||
|
||||
### PersistentVolumeLabel
|
||||
### PersistentVolumeLabel (DEPRECATED)
|
||||
|
||||
This admission controller automatically attaches region or zone labels to PersistentVolumes
|
||||
as defined by the cloud provider (for example, GCE or AWS).
|
||||
@@ -426,7 +423,7 @@ It helps ensure the Pods and the PersistentVolumes mounted are in the same
|
||||
region and/or zone.
|
||||
If the admission controller doesn't support automatic labelling your PersistentVolumes, you
|
||||
may need to add the labels manually to prevent pods from mounting volumes from
|
||||
a different zone.
|
||||
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/).
|
||||
|
||||
### PodNodeSelector
|
||||
|
||||
@@ -434,7 +431,7 @@ This admission controller defaults and limits what node selectors may be used wi
|
||||
|
||||
#### Configuration File Format
|
||||
|
||||
PodNodeSelector uses a configuration file to set options for the behavior of the backend.
|
||||
`PodNodeSelector` uses a configuration file to set options for the behavior of the backend.
|
||||
Note that the configuration file format will move to a versioned file in a future release.
|
||||
This file may be json or yaml and has the following format:
|
||||
|
||||
@@ -445,7 +442,7 @@ podNodeSelectorPluginConfig:
|
||||
namespace2: <node-selectors-labels>
|
||||
```
|
||||
|
||||
Reference the PodNodeSelector configuration file from the file provided to the API server's command line flag `--admission-control-config-file`:
|
||||
Reference the `PodNodeSelector` configuration file from the file provided to the API server's command line flag `--admission-control-config-file`:
|
||||
|
||||
```yaml
|
||||
kind: AdmissionConfiguration
|
||||
@@ -457,7 +454,7 @@ plugins:
|
||||
```
|
||||
|
||||
#### Configuration Annotation Format
|
||||
PodNodeSelector uses the annotation key `scheduler.alpha.kubernetes.io/node-selector` to assign node selectors to namespaces.
|
||||
`PodNodeSelector` uses the annotation key `scheduler.kubernetes.io/node-selector` to assign node selectors to namespaces.
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
@@ -468,6 +465,19 @@ metadata:
|
||||
name: namespace3
|
||||
```
|
||||
|
||||
#### Internal Behavior
|
||||
This admission controller has the following behavior:
|
||||
1. If the `Namespace` has an annotation with a key `scheduler.kubernetes.io/nodeSelector`, use its value as the
|
||||
node selector.
|
||||
1. If the namespace lacks such an annotation, use the `clusterDefaultNodeSelector` defined in the `PodNodeSelector`
|
||||
plugin configuration file as the node selector.
|
||||
1. Evaluate the pod's node selector against the namespace node selector for conflicts. Conflicts result in rejection.
|
||||
1. Evaluate the pod's node selector against the namespace-specific whitelist defined the plugin configuration file.
|
||||
Conflicts result in rejection.
|
||||
|
||||
**Note:** `PodTolerationRestriction` is more versatile and powerful than `PodNodeSelector` and can encompass the scenarios supported by `PodNodeSelector`.
|
||||
{: .note}
|
||||
|
||||
### PersistentVolumeClaimResize
|
||||
|
||||
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
|
||||
|
||||
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.
|
||||
|
||||
It is strongly encouraged that this admission controller is configured last in the sequence of admission controllers. This is
|
||||
so that quota is not prematurely incremented only for the request to be rejected later in admission control.
|
||||
|
||||
### SecurityContextDeny
|
||||
|
||||
@@ -557,6 +565,10 @@ This admission controller will deny any pod that attempts to set certain escalat
|
||||
This admission controller implements automation for [serviceAccounts](/docs/user-guide/service-accounts).
|
||||
We strongly recommend using this admission controller if you intend to make use of Kubernetes `ServiceAccount` objects.
|
||||
|
||||
### Storage Object in Use Protection (beta)
|
||||
{% assign for_k8s_version="v1.10" %}{% include feature-state-beta.md %}
|
||||
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.
|
||||
|
||||
### ValidatingAdmissionWebhook (alpha in 1.8; beta in 1.9)
|
||||
|
||||
This admission controller calls any validating webhooks which match the request. Matching
|
||||
@@ -577,7 +589,7 @@ versions >= 1.9).
|
||||
## Is there a recommended set of admission controllers to use?
|
||||
|
||||
Yes.
|
||||
For Kubernetes >= 1.9.0, we strongly recommend running the following set of admission controllers (order matters):
|
||||
For Kubernetes >= 1.9.0, we strongly recommend running the following set of admission controllers (order matters for 1.9 but not >1.10):
|
||||
|
||||
```shell
|
||||
--admission-control=NamespaceLifecycle,LimitRanger,ServiceAccount,PersistentVolumeLabel,DefaultStorageClass,DefaultTolerationSeconds,MutatingAdmissionWebhook,ValidatingAdmissionWebhook,ResourceQuota
|
||||
|
||||
@@ -684,3 +684,159 @@ rules:
|
||||
verbs: ["impersonate"]
|
||||
resourceNames: ["view", "development"]
|
||||
```
|
||||
|
||||
## client-go credential plugins
|
||||
|
||||
{% assign for_k8s_version="v1.10" %}{% include feature-state-alpha.md %}
|
||||
|
||||
`k8s.io/client-go` and tools using it such as `kubectl` and `kubelet` are able to execute an
|
||||
external command to receive user credentials.
|
||||
|
||||
This feature is intended for client side integrations with authentication protocols not natively
|
||||
supported by `k8s.io/client-go` (LDAP, Kerberos, OAuth2, SAML, etc.). The plugin implements the
|
||||
protocol specific logic, then returns opaque credentials to use. Almost all credential plugin
|
||||
use cases require a server side component with support for the [webhook token authenticator](#webhook-token-authentication)
|
||||
to interpret the credential format produced by the client plugin.
|
||||
|
||||
As of 1.10 only bearer tokens are supported. Support for client certs may be added in a future release.
|
||||
|
||||
### Example use case
|
||||
|
||||
In a hypothetical use case, an organization would run an external service that exchanges LDAP credentials
|
||||
for user specific, signed tokens. The service would also be capable of responding to [webhook token
|
||||
authenticator](#webhook-token-authentication) requests to validate the tokens. Users would be required
|
||||
to install a credential plugin on their workstation.
|
||||
|
||||
To authenticate against the API:
|
||||
|
||||
* The user issues a `kubectl` command.
|
||||
* Credential plugin prompts the user for LDAP credentials, exchanges credentials with external service for a token.
|
||||
* Credential plugin returns token to client-go, which uses it as a bearer token against the API server.
|
||||
* API server uses the [webhook token authenticator](#webhook-token-authentication) to submit a `TokenReview` to the external service.
|
||||
* External service verifies the signature on the token and returns the user's username and groups.
|
||||
|
||||
### Configuration
|
||||
|
||||
Credential plugins are configured through [`kubectl` config files](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)
|
||||
as part of the user fields.
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Config
|
||||
users:
|
||||
- name: my-user
|
||||
user:
|
||||
exec:
|
||||
# Command to execute. Required.
|
||||
command: "example-client-go-exec-plugin"
|
||||
|
||||
# API version to use when encoding and decoding the ExecCredentials
|
||||
# resource. Required.
|
||||
#
|
||||
# The API version returned by the plugin MUST match the version encoded.
|
||||
apiVersion: "client.authentication.k8s.io/v1alpha1"
|
||||
|
||||
# Environment variables to set when executing the plugin. Optional.
|
||||
env:
|
||||
- name: "FOO"
|
||||
value: "bar"
|
||||
|
||||
# Arguments to pass when executing the plugin. Optional.
|
||||
args:
|
||||
- "arg1"
|
||||
- "arg2"
|
||||
clusters:
|
||||
- name: my-cluster
|
||||
cluster:
|
||||
server: "https://172.17.4.100:6443"
|
||||
certificate-authority: "/etc/kubernetes/ca.pem"
|
||||
contexts:
|
||||
- name: my-cluster
|
||||
context:
|
||||
cluster: my-cluster
|
||||
user: my-user
|
||||
current-context: my-cluster
|
||||
```
|
||||
|
||||
Relative command paths are interpreted as relative to the directory of the config file. If
|
||||
KUBECONFIG is set to `/home/jane/kubeconfig` and the exec command is `./bin/example-client-go-exec-plugin`,
|
||||
the binary `/home/jane/bin/example-client-go-exec-plugin` is executed.
|
||||
|
||||
```yaml
|
||||
- name: my-user
|
||||
user:
|
||||
exec:
|
||||
# Path relative to the directory of the kubeconfig
|
||||
command: "./bin/example-client-go-exec-plugin"
|
||||
apiVersion: "client.authentication.k8s.io/v1alpha1"
|
||||
```
|
||||
|
||||
### Input and output formats
|
||||
|
||||
When executing the command, `k8s.io/client-go` sets the `KUBERNETES_EXEC_INFO` environment
|
||||
variable to a JSON serialized [`ExecCredential`](
|
||||
https://github.com/kubernetes/client-go/blob/master/pkg/apis/clientauthentication/v1alpha1/types.go)
|
||||
resource.
|
||||
|
||||
```
|
||||
KUBERNETES_EXEC_INFO='{
|
||||
"apiVersion": "client.authentication.k8s.io/v1alpha1",
|
||||
"kind": "ExecCredential",
|
||||
"spec": {
|
||||
"interactive": true
|
||||
}
|
||||
}'
|
||||
```
|
||||
|
||||
When plugins are executed from an interactive session, `stdin` and `stderr` are directly
|
||||
exposed to the plugin so it can prompt the user for input for interactive logins.
|
||||
|
||||
When responding to a 401 HTTP status code (indicating invalid credentials), this object will
|
||||
include metadata about the response.
|
||||
|
||||
```json
|
||||
{
|
||||
"apiVersion": "client.authentication.k8s.io/v1alpha1",
|
||||
"kind": "ExecCredential",
|
||||
"spec": {
|
||||
"response": {
|
||||
"code": 401,
|
||||
"header": {
|
||||
"WWW-Authenticate": [
|
||||
"Bearer realm=ldap.example.com"
|
||||
]
|
||||
},
|
||||
},
|
||||
"interactive": true
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
The executed command is expected to print an `ExceCredential` to `stdout`. `k8s.io/client-go`
|
||||
will then use the returned bearer token in the `status` when authenticating against the
|
||||
Kubernetes API.
|
||||
|
||||
```json
|
||||
{
|
||||
"apiVersion": "client.authentication.k8s.io/v1alpha1",
|
||||
"kind": "ExecCredential",
|
||||
"status": {
|
||||
"token": "my-bearer-token"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
Optionally, this output can include the expiry of the token formatted as a RFC3339 timestamp.
|
||||
If an expiry is omitted, the bearer token is cached until the server responds with a 401 HTTP
|
||||
status code.
|
||||
|
||||
```json
|
||||
{
|
||||
"apiVersion": "client.authentication.k8s.io/v1alpha1",
|
||||
"kind": "ExecCredential",
|
||||
"status": {
|
||||
"token": "my-bearer-token",
|
||||
"expirationTimestamp": "2018-03-05T17:30:20-08:00"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
@@ -67,7 +67,7 @@ DELETE | delete (for individual resources), deletecollection (for collections
|
||||
|
||||
Kubernetes sometimes checks authorization for additional permissions using specialized verbs. For example:
|
||||
|
||||
* [PodSecurityPolicy](/docs/concepts/policy/pod-security-policy/) checks for authorization of the `use` verb on `podsecuritypolicies` resources in the `extensions` API group.
|
||||
* [PodSecurityPolicy](/docs/concepts/policy/pod-security-policy/) checks for authorization of the `use` verb on `podsecuritypolicies` resources in the `policy` API group.
|
||||
* [RBAC](/docs/admin/authorization/rbac/#privilege-escalation-prevention-and-bootstrapping) checks for authorization
|
||||
of the `bind` verb on `roles` and `clusterroles` resources in the `rbac.authorization.k8s.io` API group.
|
||||
* [Authentication](/docs/admin/authentication/) layer checks for authorization of the `impersonate` verb on `users`, `groups`, and `serviceaccounts` in the core API group, and the `userextras` in the `authentication.k8s.io` API group.
|
||||
|
||||
@@ -45,7 +45,7 @@ This group and user name format match the identity created for each kubelet as p
|
||||
|
||||
To enable the Node authorizer, start the apiserver with `--authorization-mode=Node`.
|
||||
|
||||
To limit the API objects kubelets are able to write, enable the [NodeRestriction](/docs/admin/admission-controllers#NodeRestriction) admission plugin by starting the apiserver with `--admission-control=...,NodeRestriction,...`
|
||||
To limit the API objects kubelets are able to write, enable the [NodeRestriction](/docs/admin/admission-controllers#NodeRestriction) admission plugin by starting the apiserver with `--enable-admission-plugins=...,NodeRestriction,...`
|
||||
|
||||
## Migration considerations
|
||||
|
||||
|
||||
@@ -628,6 +628,7 @@ These roles include:
|
||||
* system:controller:node-controller
|
||||
* system:controller:persistent-volume-binder
|
||||
* system:controller:pod-garbage-collector
|
||||
* system:controller:pv-protection-controller
|
||||
* system:controller:pvc-protection-controller
|
||||
* system:controller:replicaset-controller
|
||||
* system:controller:replication-controller
|
||||
|
||||
@@ -21,9 +21,15 @@ the following:
|
||||
* They need to be compiled into kube-apiserver.
|
||||
* They are only configurable when the apiserver starts up.
|
||||
|
||||
<<<<<<< HEAD
|
||||
1.7 introduced two alpha features, *Initializers* and *External Admission
|
||||
Webhooks*, that address these limitations. These features allow admission
|
||||
controllers to be developed out-of-tree and configured at runtime.
|
||||
=======
|
||||
Two features, *Admission Webhooks* (beta in 1.9) and *Initializers* (alpha),
|
||||
address these limitations. They allow admission controllers to be developed
|
||||
out-of-tree and configured at runtime.
|
||||
>>>>>>> 4ac258363735f8d35150e4dcd0213516fcdc83b9
|
||||
|
||||
This page describes how to use Admission Webhooks and Initializers.
|
||||
|
||||
@@ -240,7 +246,7 @@ perform its assigned task and remove its name from the list.
|
||||
*Initializers* is an alpha feature, so it is disabled by default. To turn it on,
|
||||
you need to:
|
||||
|
||||
* Include "Initializers" in the `--admission-control` flag when starting
|
||||
* Include "Initializers" in the `--enable-admission-plugins` flag when starting
|
||||
`kube-apiserver`. If you have multiple `kube-apiserver` replicas, all should
|
||||
have the same flag setting.
|
||||
|
||||
@@ -294,3 +300,160 @@ the pods will be stuck in an uninitialized state.
|
||||
|
||||
Make sure that all expansions of the `<apiGroup, apiVersions, resources>` tuple
|
||||
in a `rule` are valid. If they are not, separate them in different `rules`.
|
||||
<<<<<<< HEAD
|
||||
|
||||
## External Admission Webhooks
|
||||
|
||||
### What are external admission webhooks?
|
||||
|
||||
External admission webhooks are HTTP callbacks that are intended to receive
|
||||
admission requests and do something with them. What an external admission
|
||||
webhook does is up to you, but there is an
|
||||
[interface](https://github.com/kubernetes/kubernetes/blob/v1.7.0-rc.1/pkg/apis/admission/v1alpha1/types.go)
|
||||
that it must adhere to so that it responds with whether or not the
|
||||
admission request should be allowed.
|
||||
|
||||
Unlike initializers or the plugin-style admission controllers, external
|
||||
admission webhooks are not allowed to mutate the admission request in any way.
|
||||
|
||||
Because admission is a high security operation, the external admission webhooks
|
||||
must support TLS.
|
||||
|
||||
### When to use admission webhooks?
|
||||
|
||||
A simple example use case for an external admission webhook is to do semantic validation
|
||||
of Kubernetes resources. Suppose that your infrastructure requires that all `Pod`
|
||||
resources have a common set of labels, and you do not want any `Pod` to be
|
||||
persisted to Kubernetes if those needs are not met. You could write your
|
||||
external admission webhook to do this validation and respond accordingly.
|
||||
|
||||
### How are external admission webhooks triggered?
|
||||
|
||||
Whenever a request comes in, the `GenericAdmissionWebhook` admission plugin will
|
||||
get the list of interested external admission webhooks from
|
||||
`externalAdmissionHookConfiguration` objects (explained below) and call them in
|
||||
parallel. If **all** of the external admission webhooks approve the admission
|
||||
request, the admission chain continues. If **any** of the external admission
|
||||
webhooks deny the admission request, the admission request will be denied, and
|
||||
the reason for doing so will be based on the _first_ external admission webhook
|
||||
denial reason. _This means if there is more than one external admission webhook
|
||||
that denied the admission request, only the first will be returned to the
|
||||
user._ If there is an error encountered when calling an external admission
|
||||
webhook, that request is ignored and will not be used to approve/deny the
|
||||
admission request.
|
||||
|
||||
**Note** In kubernetes versions earlier than v1.10, the admission chain depends
|
||||
only on the order of the `--admission-control` option passed to `kube-apiserver`.
|
||||
In versions v1.10 and later, the `--admission-control` option is replaced by the
|
||||
`--enable-admission-plugins` and the `--disable-admission-plugins` options.
|
||||
The order of plugins for these two options no longer matters.
|
||||
{: .note}
|
||||
|
||||
### Enable external admission webhooks
|
||||
|
||||
*External Admission Webhooks* is an alpha feature, so it is disabled by default.
|
||||
To turn it on, you need to
|
||||
|
||||
* Include "GenericAdmissionWebhook" in the `--enable-admission-plugins` flag when
|
||||
starting the apiserver. If you have multiple `kube-apiserver` replicas, all
|
||||
should have the same flag setting.
|
||||
|
||||
* Enable the dynamic admission controller registration API by adding
|
||||
`admissionregistration.k8s.io/v1alpha1` to the `--runtime-config` flag passed
|
||||
to `kube-apiserver`, e.g.
|
||||
`--runtime-config=admissionregistration.k8s.io/v1alpha1`. Again, all replicas
|
||||
should have the same flag setting.
|
||||
|
||||
### Write a webhook admission controller
|
||||
|
||||
See [caesarxuchao/example-webhook-admission-controller](https://github.com/caesarxuchao/example-webhook-admission-controller)
|
||||
for an example webhook admission controller.
|
||||
|
||||
The communication between the webhook admission controller and the apiserver, or
|
||||
more precisely, the GenericAdmissionWebhook admission controller, needs to be
|
||||
TLS secured. You need to generate a CA cert and use it to sign the server cert
|
||||
used by your webhook admission controller. The pem formatted CA cert is supplied
|
||||
to the apiserver via the dynamic registration API
|
||||
`externaladmissionhookconfigurations.clientConfig.caBundle`.
|
||||
|
||||
For each request received by the apiserver, the GenericAdmissionWebhook
|
||||
admission controller sends an
|
||||
[admissionReview](https://github.com/kubernetes/kubernetes/blob/v1.7.0-rc.1/pkg/apis/admission/v1alpha1/types.go#L27)
|
||||
to the relevant webhook admission controller. The webhook admission controller
|
||||
gathers information like `object`, `oldobject`, and `userInfo`, from
|
||||
`admissionReview.spec`, sends back a response with the body also being the
|
||||
`admissionReview`, whose `status` field is filled with the admission decision.
|
||||
|
||||
### Deploy the webhook admission controller
|
||||
|
||||
See [caesarxuchao/example-webhook-admission-controller deployment](https://github.com/caesarxuchao/example-webhook-admission-controller/tree/master/deployment)
|
||||
for an example deployment.
|
||||
|
||||
The webhook admission controller should be deployed via the
|
||||
[deployment API](/docs/api-reference/{{page.version}}/#deployment-v1beta1-apps).
|
||||
You also need to create a
|
||||
[service](/docs/api-reference/{{page.version}}/#service-v1-core) as the
|
||||
front-end of the deployment.
|
||||
|
||||
### Configure webhook admission controller on the fly
|
||||
|
||||
You can configure what webhook admission controllers are enabled and what
|
||||
resources are subject to the admission controller via creating
|
||||
externaladmissionhookconfigurations.
|
||||
|
||||
We suggest that you first deploy the webhook admission controller and make sure
|
||||
it is working properly before creating the externaladmissionhookconfigurations.
|
||||
Otherwise, depending whether the webhook is configured as fail open or fail
|
||||
closed, operations will be unconditionally accepted or rejected.
|
||||
|
||||
The following is an example `externaladmissionhookconfiguration`:
|
||||
|
||||
```yaml
|
||||
apiVersion: admissionregistration.k8s.io/v1alpha1
|
||||
kind: ExternalAdmissionHookConfiguration
|
||||
metadata:
|
||||
name: example-config
|
||||
externalAdmissionHooks:
|
||||
- name: pod-image.k8s.io
|
||||
rules:
|
||||
- apiGroups:
|
||||
- ""
|
||||
apiVersions:
|
||||
- v1
|
||||
operations:
|
||||
- CREATE
|
||||
resources:
|
||||
- pods
|
||||
failurePolicy: Ignore
|
||||
clientConfig:
|
||||
caBundle: <pem encoded ca cert that signs the server cert used by the webhook>
|
||||
service:
|
||||
name: <name of the front-end service>
|
||||
namespace: <namespace of the front-end service>
|
||||
```
|
||||
|
||||
For a request received by the apiserver, if the request matches any of the
|
||||
`rules` of an `externalAdmissionHook`, the `GenericAdmissionWebhook` admission
|
||||
controller will send an `admissionReview` request to the `externalAdmissionHook`
|
||||
to ask for admission decision.
|
||||
|
||||
The `rule` is similar to the `rule` in `initializerConfiguration`, with two
|
||||
differences:
|
||||
|
||||
* The addition of the `operations` field, specifying what operations the webhook
|
||||
is interested in;
|
||||
|
||||
* The `resources` field accepts subresources in the form or resource/subresource.
|
||||
|
||||
Make sure that all expansions of the `<apiGroup, apiVersions,resources>` tuple
|
||||
in a `rule` are valid. If they are not, separate them to different `rules`.
|
||||
|
||||
You can also specify the `failurePolicy`. As of 1.7, the system supports `Ignore`
|
||||
and `Fail` policies, meaning that upon a communication error with the webhook
|
||||
admission controller, the `GenericAdmissionWebhook` can admit or reject the
|
||||
operation based on the configured policy.
|
||||
|
||||
After you create the `externalAdmissionHookConfiguration`, the system will take a few
|
||||
seconds to honor the new configuration.
|
||||
=======
|
||||
>>>>>>> 4ac258363735f8d35150e4dcd0213516fcdc83b9
|
||||
|
||||
@@ -11,7 +11,7 @@ spec:
|
||||
- /bin/sh
|
||||
- -c
|
||||
- /usr/local/bin/kube-apiserver --address=127.0.0.1 --etcd-servers=http://127.0.0.1:4001
|
||||
--cloud-provider=gce --admission-control=NamespaceLifecycle,LimitRanger,SecurityContextDeny,ServiceAccount,ResourceQuota
|
||||
--cloud-provider=gce --enable-admission-plugins=NamespaceLifecycle,LimitRanger,SecurityContextDeny,ServiceAccount,ResourceQuota
|
||||
--service-cluster-ip-range=10.0.0.0/16 --client-ca-file=/srv/kubernetes/ca.crt
|
||||
--basic-auth-file=/srv/kubernetes/basic_auth.csv --cluster-name=e2e-test-bburns
|
||||
--tls-cert-file=/srv/kubernetes/server.cert --tls-private-key-file=/srv/kubernetes/server.key
|
||||
|
||||
@@ -33,11 +33,9 @@ To enable X509 client certificate authentication to the kubelet's HTTPS endpoint
|
||||
To enable API bearer tokens (including service account tokens) to be used to authenticate to the kubelet's HTTPS endpoint:
|
||||
|
||||
* ensure the `authentication.k8s.io/v1beta1` API group is enabled in the API server
|
||||
* start the kubelet with the `--authentication-token-webhook`, `--kubeconfig`, and `--require-kubeconfig` flags
|
||||
* start the kubelet with the `--authentication-token-webhook` and `--kubeconfig` flags
|
||||
* the kubelet calls the `TokenReview` API on the configured API server to determine user information from bearer tokens
|
||||
|
||||
**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.
|
||||
|
||||
## Kubelet authorization
|
||||
|
||||
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:
|
||||
To subdivide access to the kubelet API, delegate authorization to the API server:
|
||||
|
||||
* ensure the `authorization.k8s.io/v1beta1` API group is enabled in the API server
|
||||
* start the kubelet with the `--authorization-mode=Webhook`, `--kubeconfig`, and `--require-kubeconfig` flags
|
||||
* start the kubelet with the `--authorization-mode=Webhook` and the `--kubeconfig` flags
|
||||
* the kubelet calls the `SubjectAccessReview` API on the configured API server to determine whether each request is authorized
|
||||
|
||||
**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.
|
||||
|
||||
The kubelet authorizes API requests using the same [request attributes](/docs/admin/authorization/#request-attributes) approach as the apiserver.
|
||||
|
||||
The verb is determined from the incoming request's HTTP verb:
|
||||
|
||||
@@ -198,7 +198,6 @@ When starting the kubelet, if the file specified by `--kubeconfig` does not exis
|
||||
**Note:** The following flags are required to enable this bootstrapping when starting the kubelet:
|
||||
|
||||
```
|
||||
--require-kubeconfig
|
||||
--bootstrap-kubeconfig="/path/to/bootstrap/kubeconfig"
|
||||
```
|
||||
|
||||
|
||||
Reference in New Issue
Block a user