Release 1.9 (#5978)
* Trivial change to open release branch * Undo trivial change * add service ipvs overview * Add instructions on how to setup kubectl * Document conntrack dependency for kube-proxy * Add an a This is kind of jarring / missing an article. I'm guessing it should either be ' to a rack of bare metal servers.' or '...to racks of bare metal servers.'. * adding example responses for common issues - support request - code bug report * Trivial change to open release branch * Undo trivial change * Signed-off-by: Ziqi Zhao <zhaoziqi@qiniu.com> (#5366) Fix the not-working test case yaml for /doc/concepts/storage/volumes.md * kubectl-overview * temp fix for broken pod and deployment links * Update Table of Solutions for Juju * Revise certificates documentation (#5965) * Update review-issues.md Some edits for clarity and condensed language. * Update init-containers.md Fix leading spaces in commands. * Update kubectl-overview.md Fix format. * Update clc.md Fix format. * Update openstack-heat.md The url no need. just highlight. * Typo I believe this should be "users" not "uses" * making explicit hostname uniq requirement * Update scheduling-hugepages.md * Update update-daemon-set.md * fix redirection of PersistentVolume * Update hpa.md * update kubectl instruction * Use the format of kubeadm init * fix spelling error guarnatees to guarantees * add matchLabels description (#6020) * search and replace for k8s.github.io to website (#6019) * fix scale command of object-management (#6011) * Update replicaset.md (#6009) * Update secret.md (#6008) * specify password for mysql image (#5990) * specify password for mysql image * specify password for mysql image * link error for run-stateless-application-deployment.md (#5985) * link error for run-stateless-application-deployment.md * link error for run-stateless-application-deployment.md * Add performance implications of inter-pod affinity/anti-affinity (#5979) * 404 monthly maintenance - October 2017 (#5977) * Updated redirects * More redirects * Add conjure-up to Turnkey Cloud Solutions list (#5973) * Add conjure-up to Turnkey Cloud Solutions list * Changed wording slightly * change the StatefulSet to ReplicaSet in reference (#5968) * Clarification of failureThreshold of probes (#5963) * Mention usage of block storage version param (#5925) Mention usage of block storage version (bs-version) parameter to workaround attachment issues using older K8S versions on an OpenStack cloud with path-based endpoints. Resolves: https://github.com/kubernetes/kubernetes.github.io/issues/5924 * Update sysctl-cluster.md (#5894) Include guide on enabling unsafe sysctls in minikube * Avoid Latin phrases & format note (#5889) * Avoid Latin phrases & format note according the Documentation Style Guide * Update scratch.md * Update scratch.md * resolves jekyll rendering error (#5976) - chinese isn't understood for keys in YAML frontmatter in jekyll, so replaced it with the english equivalent that doesn't throw the following error on rendering: Error reading file src/kubernetes.github.io/cn/docs/concepts/cluster-administration/device-plugins.md: (<unknown>): could not find expected ':' while scanning a simple key at line 4 column 1 * Change VM to pod. (#6022) * Add link to custom metrics. (#6023) * Rephrase core group. (#6024) * Added explanation on context to when joining (#6018) * Update create-cluster-kubeadm.md (#5761) Update Canal version in pod network apply commands * Fixes issue #5620 (#5869) * Fixes issue #5620 Signed-off-by: Brad Topol <btopol@us.ibm.com> * Restructured so that review process is for both current and upcoming releases. Added content describing the use of tech reviewers. * Removed incorrect Kubernetes reviewer link. * Fixed tech reviewer URL to now use website * Update pod-priority-preemption.md fix-wrong-link-to-pod-preemption * pod-security-policy.md: add links to the page about admission plugins. * Adding all files for BlaBlaCar case study (#5857) * Adding all files for BlaBlaCar case study * Update blablacar.html * Fix changed URL for google containers * Add /docs/reference/auto-generated directory * correct the downwardapi redirect * Remove links using "here" * Rename to /docs/reference/generated directory * add Concept template * Change title to just Ingress * Link mistake (#6038) * link mistake * link mistake * skip title check for skip_title_check.txt * skip title check for skip_title_check.txt * remove doesn't exist link. * Fix podpreset task (#5705) * Add a simple pod manifest to pod overview (#5986) * Split PodPreset concept out from task doc (#5984) * Add selector spec description (#5789) * Add selector spec description * Fix selector field explanation * Put orphaned topics in TOC. (#6051) * static-pod example bad format in the final page (#6050) * static-pod example bad format in the final page * static-pod example bad format in the final page * static-pod example bad format in the final page * static-pod example bad format in the final page * static-pod example bad format in the final page * Fix `backoffLimit` field misplacement (#6042) It should be placed in JobSpec according to: https://github.com/kubernetes/kubernetes/blob/master/api/swagger-spec/batch_v1.json#L1488-L1514 * Update addons.md (#6061) * add info about VMware NSX-T CNI plugin (#5987) * add info about VMware NSX-T CNI plugin Hello, I'm VMware Networking and Security Architect and would like to include short information about our CNI plugin implementation similar to what other vendors did Best regards Emil Gagala * Update networking.md * Update networking.md * Update networking.md * Update: Using universal zsh configuration (#5669) * Update install-kubectl.md Zsh is not only oh-my-zsh, so I added universal configuration for zsh that also can be used in prezto. * fix merge error after rebase * Operating etcd cluster for Kubernetes bad format in the final page (#6056) * Operating etcd cluster for Kubernetes bad format in the final page * Update configure-upgrade-etcd.md * Update configure-upgrade-etcd.md * Usage note and warning tags. (#6053) * Usage note and warning tags. * Update configure-upgrade-etcd.md * Update configure-upgrade-etcd.md * Document jekyll includes snippets * Add jekyll includes to docs home toc - Remove extra kubernetes home in toc * document docker cgroupdriver req (#5937) * Update test blacklists (#6063) * Update toc check blacklist * Update title check blacklist * wip * wip * Fix typo * Document unconfined apparmor profile * Revert "Document the unconfined profile for AppArmor" (#6268) * CRD Validation: remove alpha warning, change enable instructions to (#6066) disable * Documented service annotation for AWS ELB SSL policy * kubeadm: add a note about the new `--print-join-command` flag. This is a new flag for the `kubeadm token create` command. * Add a note to PDB page * Improve Kubeadm reference doc (#6103) * automatically-generated kubeadm reference doc * user-mantained kubeadm reference doc * Documentation for CSIPersistentVolume * change replicaset documentation to use apps/v1 APIs * Update service.md ipvs alpha version -> beta version * Updated Deployment concept docs (#6494) * Updated Deployment concept docs * Addressed comments * Documentation for volume scheduling alpha feature * Update admission control docs for webhooks * Improve DNS documentation (#6479) * update ds for 1.9 * Update service.md * Update service.md * Revert "begin updating webhook documentation" (#6575) * Update version numbers to include 1.9 (#6518) * Update site versions for 1.9 * Removed 1.4 docs * Update _config.yml * Update _config.yml * updates for raw block devices * rbac: docs for aggregated cluster roles (#6474) * Added IPv6 information for Kubelet arguments (#6498) * Added IPv6 info to kube-proxy arguments * Added IPv6 information for argument for kubelet * Update PVC resizing documentation (#6487) * Updates for Windows Server version 1709 with K8s v1.8 (#6180) * Updated for WSv1709 and K8s v1.8 * Updated picture and CNI config * Fixed formatting on CNI Config * Updated docs to reference Microsoft/SDN GitHub docs * fix typo * Workaround for Jekyllr frontmatter * Added section on features and limitations, with example yaml files. * Update index.md * Added kubeadm section, few other small fixes * Few minor grammar fixes * Update access-cluster.md with a comment that for IPv6 the user should use [::1] for the localhost * Addressed a number of issues brought up against the base PR * Fixed windows-host-setup link * Rewrite PodSecurityPolicy guide * Update index.md Signed-off-by: Alin Balutoiu <abalutoiu@cloudbasesolutions.com> Signed-off-by: Alin Gabriel Serdean <aserdean@ovn.org> * Spelling correction and sentence capitalization. - Corrected the spelling error for storing, was put in as 'stoing'. - Capitalized list items. - Added '.' at end of sentences in the list items. * Update index.md * Update index.md * Addressed comments and rebased * Fixed formatting * Fixed formatting * Updated header link * Updated hyperlinks * Updated warning * formatting * formatting * formatting * Revert "Update access-cluster.md with a comment that for IPv6" This reverts commit31e4dbdc25. * Revert "fix typo" This reverts commitc05678752d. * Revert "Workaround for Jekyllr frontmatter" This reverts commitb84ac59624. * Fixed grammatical issues and reverted non-related commits * Revert "Rewrite PodSecurityPolicy guide" This reverts commit5d39cfeae4. * Revert "Spelling correction and sentence capitalization." This reverts commit47eed4346e. * Fixed auto-numbering * Minor formatting updates * CoreDNS feature documentation (#6463) * Initial placeholder PR for CoreDNS feature documentation * Remove from admin, add content * Fix missing endcapture * Add to tasks.yml * Review feedback * Postpone Deletion of a Persistent Volume Claim in case It Is Used by a Pod (#6415) * Postpone Deletion of a Persistent Volume Claim in case It Is Used by a Pod A new feature PVC Protection was added into K8s 1.9 that's why this documentation change is needed. * Added tag at the top of each new area. * Fix typo * Fix: switched on in (all kubelets) -> (all K8s components). * Added link to admission controller * Moved PVC Protection configuration into Before you begin section. * Added steps how to verify PVC Protection feature. * Fixes for admission controller plugin description and for PVC Protection description in PVC lifecycle. * Testing official rendering of enumerations (1., 2., 3., etc.) * Re-write to address comments from review. * Fixed definition when a PVC is in active use by a pod. * Change auditing docs page for 1.9 release (#6427) * Change auditing docs page for 1.9 release Signed-off-by: Mik Vyatskov <vmik@google.com> * Address review comments Signed-off-by: Mik Vyatskov <vmik@google.com> * Address review comments Signed-off-by: Mik Vyatskov <vmik@google.com> * Address review comments Signed-off-by: Mik Vyatskov <vmik@google.com> * Fix broken link Signed-off-by: Mik Vyatskov <vmik@google.com> * short circuit deny docs (#6536) * line wrap * short circuit deny * address comments * Add kubeadm 1.9 upgrade docs (#6485) * kubeadm: Improve kubeadm documentation for v1.9 (#6645) * Update admission control docs for webhooks (re-send #6368) (#6650) * Update admission control docs for webhooks * update in response to comments * Revamp rkt and add CRI-O as alternative runtime (#6371) Signed-off-by: Lorenzo Fontana <lo@linux.com> * Documented NLB for Kubernetes 1.9 (#6260) * Added IPV6 information to setup cluster using kubeadm (#6465) * Added IPV6 information to setup cluster using kubeadm * Updated kubeadm.md & create-cluster-kubeadm.md with IPv6 related information * Added IPv6 options for kubeadm --init & automated address binding for kube-proxy based on version of IP configured for API server) * Changes to kubeadm.md as per comments * Modified kubeadm.md and create-cluster-kubeadm.md * Implemented changes requested by zacharysarah * Removed autogenerated kubeadm.md changes * StatefulSet 1.9 updates. (#6550) * updates sts concept and tutorials to use 1.9 apps/v1 * Update statefulset.md * clarify pod name label * Garbage collection updates for 1.9 (#6555) * 1.9 gc policy update * carify deletion * Couple nits for dnsConfig doc (#6652) * Add doc for AllowedFlexVolume (#6563) * Update OpenStack Cloud Provider API support for v1.9 (#6638) * Flex volume is GA. Remove alpha notation. (#6666) * Update generated ref docs for Kubernetes and Federation components. (#6658) * Update generated ref docs for Kubernetes and Federation components. * Rename kubectl-options to kubectl. * Add title to kubectl. * Fix double synopsis. * Update Federation API ref docs for 1.9. (#6636) * Update federation API ref docs. * Move and redirect. * Move generated Federation docs to the generated directory. * Fix titles. * Type * Fix titles * Update auto-generated Kubernetes APi ref docs. (#6646) * Update kubectl commands for 1.9 (#6635) * add ExtendedResourceToleration admission controller (#6618) * Update API reference paths for v1.9 (#6681)
This commit is contained in:
Zach Corleissen
@@ -1,6 +1,6 @@
|
||||
---
|
||||
approvers:
|
||||
- bprashanth
|
||||
- lavalamp
|
||||
- davidopp
|
||||
- derekwaynecarr
|
||||
- erictune
|
||||
@@ -14,44 +14,62 @@ title: Using Admission Controllers
|
||||
|
||||
## What are they?
|
||||
|
||||
An admission control plug-in is a piece of code that intercepts requests to the Kubernetes
|
||||
API server prior to persistence of the object, but after the request is authenticated
|
||||
and authorized. The plug-in code is in the API server process
|
||||
and must be compiled into the binary in order to be used at this time.
|
||||
An admission controller is a piece of code that intercepts requests to the
|
||||
Kubernetes API server prior to persistence of the object, but after the request
|
||||
is authenticated and authorized. The controllers consist of the
|
||||
[list](#what-does-each-admission-controller-do) below, are compiled into the
|
||||
`kube-apiserver` binary, and may only be configured by the cluster
|
||||
administrator. In that list, there are two special controllers:
|
||||
MutatingAdmissionWebhook and ValidatingAdmissionWebhook. These execute the
|
||||
mutating and validating (respectively) [admission control
|
||||
webhooks](/docs/admin/extensible-admission-controllers.md#external-admission-webhooks)
|
||||
which are configured in the API.
|
||||
|
||||
Each admission control plug-in is run in sequence before a request is accepted into the cluster. If
|
||||
any of the plug-ins in the sequence reject the request, the entire request is rejected immediately
|
||||
and an error is returned to the end-user.
|
||||
Admission controllers may be "validating", "mutating", or both. Mutating
|
||||
controllers may modify the objects they admit; validating controllers may not.
|
||||
|
||||
Admission control plug-ins may mutate the incoming object in some cases to apply system configured
|
||||
defaults. In addition, admission control plug-ins may mutate related resources as part of request
|
||||
processing to do things like increment quota usage.
|
||||
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`.
|
||||
|
||||
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.
|
||||
|
||||
Finally, in addition to sometimes mutating the object in question, admission
|
||||
controllers may sometimes have side effects, that is, mutate related
|
||||
resources as part of request processing. Incrementing quota usage is the
|
||||
canonical example of why this is necessary. Any such side-effect needs a
|
||||
corresponding reclamation or reconciliation process, as a given admission
|
||||
controller does not know for sure that a given request will pass all of the
|
||||
other admission controllers.
|
||||
|
||||
## Why do I need them?
|
||||
|
||||
Many advanced features in Kubernetes require an admission control plug-in to be enabled in order
|
||||
Many advanced features in Kubernetes require an admission controller to be enabled in order
|
||||
to properly support the feature. As a result, a Kubernetes API server that is not properly
|
||||
configured with the right set of admission control plug-ins is an incomplete server and will not
|
||||
configured with the right set of admission controllers is an incomplete server and will not
|
||||
support all the features you expect.
|
||||
|
||||
## How do I turn on an admission control plug-in?
|
||||
## 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.
|
||||
|
||||
## What does each plug-in do?
|
||||
## What does each admission controller do?
|
||||
|
||||
### AlwaysAdmit
|
||||
|
||||
Use this plugin by itself to pass-through all requests.
|
||||
Use this admission controller by itself to pass-through all requests.
|
||||
|
||||
### AlwaysPullImages
|
||||
|
||||
This plug-in modifies every new Pod to force the image pull policy to Always. This is useful in a
|
||||
This admission controller modifies every new Pod to force the image pull policy to Always. This is useful in a
|
||||
multitenant cluster so that users can be assured that their private images can only be used by those
|
||||
who have the credentials to pull them. Without this plug-in, once an image has been pulled to a
|
||||
who have the credentials to pull them. Without this admission controller, once an image has been pulled to a
|
||||
node, any pod from any user can use it simply by knowing the image's name (assuming the Pod is
|
||||
scheduled onto the right node), without any authorization check against the image. When this plug-in
|
||||
scheduled onto the right node), without any authorization check against the image. When this admission controller
|
||||
is enabled, images are always pulled prior to starting containers, which means valid credentials are
|
||||
required.
|
||||
|
||||
@@ -61,22 +79,22 @@ Rejects all requests. Used for testing.
|
||||
|
||||
### DefaultStorageClass
|
||||
|
||||
This plug-in observes creation of `PersistentVolumeClaim` objects that do not request any specific storage class
|
||||
This admission controller observes creation of `PersistentVolumeClaim` objects that do not request any specific storage class
|
||||
and automatically adds a default storage class to them.
|
||||
This way, users that do not request any special storage class do not need to care about them at all and they
|
||||
will get the default one.
|
||||
|
||||
This plug-in does not do anything when no default storage class is configured. When more than one storage
|
||||
This admission controller does not do anything when no default storage class is configured. When more than one storage
|
||||
class is marked as default, it rejects any creation of `PersistentVolumeClaim` with an error and administrator
|
||||
must revisit `StorageClass` objects and mark only one as default.
|
||||
This plugin ignores any `PersistentVolumeClaim` updates; it acts only on creation.
|
||||
This admission controller ignores any `PersistentVolumeClaim` updates; it acts only on creation.
|
||||
|
||||
See [persistent volume](/docs/concepts/storage/persistent-volumes/) documentation about persistent volume claims and
|
||||
storage classes and how to mark a storage class as default.
|
||||
|
||||
### DefaultTolerationSeconds
|
||||
|
||||
This plug-in sets the default forgiveness toleration for pods to tolerate
|
||||
This admission controller sets the default forgiveness toleration for pods to tolerate
|
||||
the taints `notready:NoExecute` and `unreachable:NoExecute` for 5 minutes,
|
||||
if the pods don't already have toleration for taints
|
||||
`node.kubernetes.io/not-ready:NoExecute` or
|
||||
@@ -84,26 +102,26 @@ if the pods don't already have toleration for taints
|
||||
|
||||
### DenyExecOnPrivileged (deprecated)
|
||||
|
||||
This plug-in will intercept all requests to exec a command in a pod if that pod has a privileged container.
|
||||
This admission controller will intercept all requests to exec a command in a pod if that pod has a privileged container.
|
||||
|
||||
If your cluster supports privileged containers, and you want to restrict the ability of end-users to exec
|
||||
commands in those containers, we strongly encourage enabling this plug-in.
|
||||
commands in those containers, we strongly encourage enabling this admission controller.
|
||||
|
||||
This functionality has been merged into [DenyEscalatingExec](#denyescalatingexec).
|
||||
|
||||
### DenyEscalatingExec
|
||||
|
||||
This plug-in will deny exec and attach commands to pods that run with escalated privileges that
|
||||
This admission controller will deny exec and attach commands to pods that run with escalated privileges that
|
||||
allow host access. This includes pods that run as privileged, have access to the host IPC namespace, and
|
||||
have access to the host PID namespace.
|
||||
|
||||
If your cluster supports containers that run with escalated privileges, and you want to
|
||||
restrict the ability of end-users to exec commands in those containers, we strongly encourage
|
||||
enabling this plug-in.
|
||||
enabling this admission controller.
|
||||
|
||||
### EventRateLimit (alpha)
|
||||
|
||||
This plug-in is introduced in v1.9 to mitigate the problem where the API server gets flooded by
|
||||
This admission controller is introduced in v1.9 to mitigate 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
|
||||
@@ -137,18 +155,17 @@ EventRateLimit:
|
||||
See the [EventRateLimit proposal](https://git.k8s.io/community/contributors/design-proposals/api-machinery/admission_control_event_rate_limit.md)
|
||||
for more details.
|
||||
|
||||
### GenericAdmissionWebhook (alpha)
|
||||
### ExtendedResourceToleration
|
||||
|
||||
This plug-in is related to the [Dynamic Admission Control](/docs/admin/extensible-admission-controllers)
|
||||
introduced in v1.7.
|
||||
The plug-in calls the webhooks configured via `ExternalAdmissionHookConfiguration`,
|
||||
and only admits the operation if all the webhooks admit it.
|
||||
Currently, the plug-in always fails open.
|
||||
In other words, it ignores the failed calls to a webhook.
|
||||
This plug-in is introduced in v1.9 to facilitate 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
|
||||
add these tolerations.
|
||||
|
||||
### ImagePolicyWebhook
|
||||
|
||||
The ImagePolicyWebhook plug-in allows a backend webhook to make admission decisions. You enable this plug-in by setting the admission-control option as follows:
|
||||
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
|
||||
@@ -185,7 +202,7 @@ clusters:
|
||||
users:
|
||||
- name: name-of-api-server
|
||||
user:
|
||||
client-certificate: /path/to/cert.pem # cert for the webhook plugin to use
|
||||
client-certificate: /path/to/cert.pem # cert for the webhook admission controller to use
|
||||
client-key: /path/to/key.pem # key matching the cert
|
||||
```
|
||||
For additional HTTP configuration, refer to the [kubeconfig](/docs/concepts/cluster-administration/authenticate-across-clusters-kubeconfig/) documentation.
|
||||
@@ -260,18 +277,18 @@ In any case, the annotations are provided by the user and are not validated by K
|
||||
|
||||
### Initializers (alpha)
|
||||
|
||||
This plug-in is introduced in v1.7.
|
||||
The plug-in determines the initializers of a resource based on the existing
|
||||
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.
|
||||
For more information, please check [Dynamic Admission Control](/docs/admin/extensible-admission-controllers).
|
||||
For more information, please check [Dynamic Admission Control](/docs/admin/extensible-admission-controllers.md).
|
||||
|
||||
### InitialResources (experimental)
|
||||
|
||||
This plug-in observes pod creation requests. If a container omits compute resource requests and limits,
|
||||
then the plug-in auto-populates a compute resource request based on historical usage of containers running the same image.
|
||||
This admission controller observes pod creation requests. If a container omits compute resource requests and limits,
|
||||
then the admission controller auto-populates a compute resource request based on historical usage of containers running the same image.
|
||||
If there is not enough data to make a decision the Request is left unchanged.
|
||||
When the plug-in sets a compute resource request, it does this by *annotating* the
|
||||
When the admission controller sets a compute resource request, it does this by *annotating* the
|
||||
the pod spec rather than mutating the `container.resources` fields.
|
||||
The annotations added contain the information on what compute resources were auto-populated.
|
||||
|
||||
@@ -279,69 +296,104 @@ See the [InitialResouces proposal](https://git.k8s.io/community/contributors/des
|
||||
|
||||
### LimitPodHardAntiAffinity
|
||||
|
||||
This plug-in denies any pod that defines `AntiAffinity` topology key other than
|
||||
This admission controller denies any pod that defines `AntiAffinity` topology key other than
|
||||
`kubernetes.io/hostname` in `requiredDuringSchedulingRequiredDuringExecution`.
|
||||
|
||||
### LimitRanger
|
||||
|
||||
This plug-in will observe the incoming request and ensure that it does not violate any of the constraints
|
||||
This admission controller will observe the incoming request and ensure that it does not violate any of the constraints
|
||||
enumerated in the `LimitRange` object in a `Namespace`. If you are using `LimitRange` objects in
|
||||
your Kubernetes deployment, you MUST use this plug-in to enforce those constraints. LimitRanger can also
|
||||
your Kubernetes deployment, you MUST use this admission controller to enforce those constraints. LimitRanger can also
|
||||
be used to apply default resource requests to Pods that don't specify any; currently, the default LimitRanger
|
||||
applies a 0.1 CPU requirement to all Pods in the `default` namespace.
|
||||
|
||||
See the [limitRange design doc](https://git.k8s.io/community/contributors/design-proposals/resource-management/admission_control_limit_range.md) and the [example of Limit Range](/docs/tasks/configure-pod-container/limit-range/) for more details.
|
||||
|
||||
### MutatingAdmissionWebhook (beta in 1.9)
|
||||
|
||||
This admission controller calls any mutating webhooks which match the request. Matching
|
||||
webhooks are called in serial; each one may modify the object if it desires.
|
||||
|
||||
This admission controller (as implied by the name) only runs in the mutating phase.
|
||||
|
||||
If a webhook called by this has side effects (for example, decrementing quota) it
|
||||
*must* have a reconcilation system, as it is not guaranteed that subsequent
|
||||
webhooks or validating admission controllers will permit the request to finish.
|
||||
|
||||
If you disable the MutatingAdmissionWebhook, you must also disable the
|
||||
`MutatingWebhookConfiguration` object in the `admissionregistration/v1beta1`
|
||||
group/version via the `--runtime-config` flag (both are on by default in
|
||||
versions >= 1.9).
|
||||
|
||||
#### Use caution when authoring and installing mutating webhooks
|
||||
|
||||
* Users may be confused when the objects they try to create are different from
|
||||
what they get back.
|
||||
* Built in control loops may break when the objects they try to create are
|
||||
different when read back.
|
||||
* Setting originally unset fields is less likely to cause problems than
|
||||
overwriting fields set in the original request. Avoid doing the latter.
|
||||
* This is a beta feature. Future versions of Kubernetes may restrict the types of
|
||||
mutations these webhooks can make.
|
||||
* Future changes to control loops for built-in resources or third-party resources
|
||||
may break webhooks that work well today. Even when the webhook installation API
|
||||
is finalized, not all possible webhook behaviors will be guaranteed to be supported
|
||||
indefinitely.
|
||||
|
||||
### NamespaceAutoProvision
|
||||
|
||||
This plug-in examines all incoming requests on namespaced resources and checks
|
||||
This admission controller examines all incoming requests on namespaced resources and checks
|
||||
if the referenced namespace does exist.
|
||||
It creates a namespace if it cannot be found.
|
||||
This plug-in is useful in deployments that do not want to restrict creation of
|
||||
This admission controller is useful in deployments that do not want to restrict creation of
|
||||
a namespace prior to its usage.
|
||||
|
||||
### NamespaceExists
|
||||
|
||||
This plug-in checks all requests on namespaced resources other than `Namespace` itself.
|
||||
This admission controller checks all requests on namespaced resources other than `Namespace` itself.
|
||||
If the namespace referenced from a request doesn't exist, the request is rejected.
|
||||
|
||||
### NamespaceLifecycle
|
||||
|
||||
This plug-in enforces that a `Namespace` that is undergoing termination cannot have new objects created in it,
|
||||
and ensures that requests in a non-existent `Namespace` are rejected. This plug-in also prevents deletion of
|
||||
This admission controller enforces that a `Namespace` that is undergoing termination cannot have new objects created in it,
|
||||
and ensures that requests in a non-existent `Namespace` are rejected. This admission controller also prevents deletion of
|
||||
three system reserved namespaces `default`, `kube-system`, `kube-public`.
|
||||
|
||||
A `Namespace` deletion kicks off a sequence of operations that remove all objects (pods, services, etc.) in that
|
||||
namespace. In order to enforce integrity of that process, we strongly recommend running this plug-in.
|
||||
namespace. In order to enforce integrity of that process, we strongly recommend running this admission controller.
|
||||
|
||||
### NodeRestriction
|
||||
|
||||
This plug-in limits the `Node` and `Pod` objects a kubelet can modify. In order to be limited by this admission plugin,
|
||||
This admission controller limits the `Node` and `Pod` objects a kubelet can modify. In order to be limited by this admission controller,
|
||||
kubelets must use credentials in the `system:nodes` group, with a username in the form `system:node:<nodeName>`.
|
||||
Such kubelets will only be allowed to modify their own `Node` API object, and only modify `Pod` API objects that are bound to their node.
|
||||
Future versions may add additional restrictions to ensure kubelets have the minimal set of permissions required to operate correctly.
|
||||
|
||||
### OwnerReferencesPermissionEnforcement
|
||||
|
||||
This plug-in protects the access to the `metadata.ownerReferences` of an object
|
||||
This admission controller protects the access to the `metadata.ownerReferences` of an object
|
||||
so that only users with "delete" permission to the object can change it.
|
||||
This plug-in also protects the access to `metadata.ownerReferences[x].blockOwnerDeletion`
|
||||
This admission controller also protects the access to `metadata.ownerReferences[x].blockOwnerDeletion`
|
||||
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
|
||||
|
||||
This plug-in automatically attaches region or zone labels to PersistentVolumes
|
||||
as defined by the cloud provider, e.g. GCE and AWS.
|
||||
This admission controller automatically attaches region or zone labels to PersistentVolumes
|
||||
as defined by the cloud provider (for example, GCE or AWS).
|
||||
It helps ensure the Pods and the PersistentVolumes mounted are in the same
|
||||
region and/or zone.
|
||||
If the plug-in doesn't support automatic labelling your PersistentVolumes, you
|
||||
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.
|
||||
|
||||
### PodNodeSelector
|
||||
|
||||
This plug-in defaults and limits what node selectors may be used within a namespace by reading a namespace annotation and a global configuration.
|
||||
This admission controller defaults and limits what node selectors may be used within a namespace by reading a namespace annotation and a global configuration.
|
||||
|
||||
#### Configuration File Format
|
||||
PodNodeSelector uses the admission config file `--admission-control-config-file` to set configuration options for the behavior of the backend.
|
||||
@@ -371,13 +423,13 @@ metadata:
|
||||
|
||||
### PersistentVolumeClaimResize
|
||||
|
||||
This plug-in implements additional validations for checking incoming `PersistentVolumeClaim` resize requests.
|
||||
This admission controller implements additional validations for checking incoming `PersistentVolumeClaim` resize requests.
|
||||
**Note:** Support for volume resizing is available as an alpha feature. Admins must set the feature gate `ExpandPersistentVolumes`
|
||||
to `true` to enable resizing.
|
||||
{: .note}
|
||||
|
||||
After enabling the `ExpandPersistentVolumes` feature gate, enabling the `PersistentVolumeClaimResize` admission
|
||||
plug-in is recommended, too. This plug-in prevents resizing of all claims by default unless a claim's `StorageClass`
|
||||
controller is recommended, too. This admission controller prevents resizing of all claims by default unless a claim's `StorageClass`
|
||||
explicitly enables resizing by setting `allowVolumeExpansion` to `true`.
|
||||
|
||||
For example: all `PersistentVolumeClaim`s created from the following `StorageClass` support volume expansion:
|
||||
@@ -400,14 +452,14 @@ For more information about persistent volume claims, see ["PersistentVolumeClaim
|
||||
|
||||
### PodPreset
|
||||
|
||||
This plug-in injects a pod with the fields specified in a matching PodPreset.
|
||||
This admission controller injects a pod with the fields specified in a matching PodPreset.
|
||||
See also [PodPreset concept](/docs/concepts/workloads/pods/podpreset/) and
|
||||
[Inject Information into Pods Using a PodPreset](/docs/tasks/inject-data-application/podpreset)
|
||||
for more information.
|
||||
|
||||
### PodSecurityPolicy
|
||||
|
||||
This plug-in acts on creation and modification of the pod and determines if it should be admitted
|
||||
This admission controller acts on creation and modification of the pod and determines if it should be admitted
|
||||
based on the requested security context and the available Pod Security Policies.
|
||||
|
||||
For Kubernetes < 1.6.0, the API Server must enable the extensions/v1beta1/podsecuritypolicy API
|
||||
@@ -418,7 +470,7 @@ for more information.
|
||||
|
||||
### PodTolerationRestriction
|
||||
|
||||
This plug-in first verifies any conflict between a pod's tolerations and its
|
||||
This admission controller first verifies any conflict between a pod's tolerations and its
|
||||
namespace's tolerations, and rejects the pod request if there is a conflict.
|
||||
It then merges the namespace's tolerations into the pod's tolerations.
|
||||
The resulting tolerations are checked against the namespace's whitelist of
|
||||
@@ -440,47 +492,78 @@ The priority admission controller uses the `priorityClassName` field and populat
|
||||
|
||||
### ResourceQuota
|
||||
|
||||
This plug-in will observe the incoming request and ensure that it does not violate any of the constraints
|
||||
This admission controller will observe the incoming request and ensure that it does not violate any of the constraints
|
||||
enumerated in the `ResourceQuota` object in a `Namespace`. If you are using `ResourceQuota`
|
||||
objects in your Kubernetes deployment, you MUST use this plug-in to enforce quota constraints.
|
||||
objects in your Kubernetes deployment, you MUST use this admission controller to enforce quota constraints.
|
||||
|
||||
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 plug-in is configured last in the sequence of admission control plug-ins. This is
|
||||
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
|
||||
|
||||
This plug-in will deny any pod that attempts to set certain escalating [SecurityContext](/docs/user-guide/security-context) fields. This should be enabled if a cluster doesn't utilize [pod security policies](/docs/user-guide/pod-security-policy) to restrict the set of values a security context can take.
|
||||
This admission controller will deny any pod that attempts to set certain escalating [SecurityContext](/docs/user-guide/security-context) fields. This should be enabled if a cluster doesn't utilize [pod security policies](/docs/user-guide/pod-security-policy) to restrict the set of values a security context can take.
|
||||
|
||||
### ServiceAccount
|
||||
|
||||
This plug-in implements automation for [serviceAccounts](/docs/user-guide/service-accounts).
|
||||
We strongly recommend using this plug-in if you intend to make use of Kubernetes `ServiceAccount` objects.
|
||||
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.
|
||||
|
||||
### ValidatingAdmissionWebhook (alpha in 1.8; beta in 1.9)
|
||||
|
||||
This admission controller calls any validating webhooks which match the request. Matching
|
||||
webhooks are called in parallel; if any of them rejects the request, the request
|
||||
fails. This admission controller only runs in the validation phase; the webhooks it calls may not
|
||||
mutate the object, as opposed to the webhooks called by the `MutatingAdmissionWebhook` admission controller.
|
||||
|
||||
If a webhook called by this has side effects (for example, decrementing quota) it
|
||||
*must* have a reconcilation system, as it is not guaranteed that subsequent
|
||||
webhooks or other validating admission controllers will permit the request to finish.
|
||||
|
||||
If you disable the ValidatingAdmissionWebhook, you must also disable the
|
||||
`ValidatingWebhookConfiguration` object in the `admissionregistration/v1beta1`
|
||||
group/version via the `--runtime-config` flag (both are on by default in
|
||||
versions >= 1.9).
|
||||
|
||||
|
||||
## Is there a recommended set of plug-ins to use?
|
||||
## Is there a recommended set of admission controllers to use?
|
||||
|
||||
Yes.
|
||||
For Kubernetes >= 1.6.0, we strongly recommend running the following set of admission control plug-ins (order matters):
|
||||
For Kubernetes >= 1.9.0, we strongly recommend running the following set of admission controllers (order matters):
|
||||
|
||||
```shell
|
||||
--admission-control=NamespaceLifecycle,LimitRanger,ServiceAccount,PersistentVolumeLabel,DefaultStorageClass,ValidatingAdmissionWebhook,ResourceQuota,DefaultTolerationSeconds,MutatingAdmissionWebhook
|
||||
```
|
||||
|
||||
It's worth reiterating that in 1.9 and up, these happen in a mutating phase
|
||||
and a validating phase, and that e.g. `ResourceQuota` runs in the validating
|
||||
phase, and therefore is the last admission controller to run.
|
||||
`DefaultTolerationSeconds` and `MutatingAdmissionWebhook` appear after it in this
|
||||
list, but they run in the mutating phase.
|
||||
|
||||
For earlier versions, there was no concept of validating vs mutating and the
|
||||
admission controllers ran in the exact order specified.
|
||||
|
||||
For Kubernetes >= 1.6.0, we strongly recommend running the following set of admission controllers (order matters):
|
||||
|
||||
```shell
|
||||
--admission-control=NamespaceLifecycle,LimitRanger,ServiceAccount,PersistentVolumeLabel,DefaultStorageClass,ResourceQuota,DefaultTolerationSeconds
|
||||
```
|
||||
|
||||
For Kubernetes >= 1.4.0, we strongly recommend running the following set of admission control plug-ins (order matters):
|
||||
For Kubernetes >= 1.4.0, we strongly recommend running the following set of admission controllers (order matters):
|
||||
|
||||
```shell
|
||||
--admission-control=NamespaceLifecycle,LimitRanger,ServiceAccount,DefaultStorageClass,ResourceQuota
|
||||
```
|
||||
|
||||
For Kubernetes >= 1.2.0, we strongly recommend running the following set of admission control plug-ins (order matters):
|
||||
For Kubernetes >= 1.2.0, we strongly recommend running the following set of admission controllers (order matters):
|
||||
|
||||
```shell
|
||||
--admission-control=NamespaceLifecycle,LimitRanger,ServiceAccount,ResourceQuota
|
||||
```
|
||||
|
||||
For Kubernetes >= 1.0.0, we strongly recommend running the following set of admission control plug-ins (order matters):
|
||||
For Kubernetes >= 1.0.0, we strongly recommend running the following set of admission controllers (order matters):
|
||||
|
||||
```shell
|
||||
--admission-control=NamespaceLifecycle,LimitRanger,SecurityContextDeny,ServiceAccount,PersistentVolumeLabel,ResourceQuota
|
||||
|
||||
@@ -8,20 +8,34 @@ title: Overview
|
||||
---
|
||||
|
||||
{% capture overview %}
|
||||
Learn more about Kubernetes authorization, including details about creating policies using the supported authorization modules.
|
||||
Learn more about Kubernetes authorization, including details about creating
|
||||
policies using the supported authorization modules.
|
||||
{% endcapture %}
|
||||
|
||||
{% capture body %}
|
||||
In Kubernetes, you must be authenticated (logged in) before your request can be authorized (granted permission to access). For information about authentication, see [Accessing Control Overview](/docs/admin/accessing-the-api/).
|
||||
In Kubernetes, you must be authenticated (logged in) before your request can be
|
||||
authorized (granted permission to access). For information about authentication,
|
||||
see [Accessing Control Overview](/docs/admin/accessing-the-api/).
|
||||
|
||||
Kubernetes expects attributes that are common to REST API requests. This means that Kubernetes authorization works with existing organization-wide or cloud-provider-wide access control systems which may handle other APIs besides the Kubernetes API.
|
||||
Kubernetes expects attributes that are common to REST API requests. This means
|
||||
that Kubernetes authorization works with existing organization-wide or
|
||||
cloud-provider-wide access control systems which may handle other APIs besides
|
||||
the Kubernetes API.
|
||||
|
||||
## Determine Whether a Request is Allowed or Denied
|
||||
Kubernetes authorizes API requests using the API server. It evaluates all of the request attributes against all policies and allows or denies the request. All parts of an API request must be allowed by some policy in order to proceed. This means that permissions are denied by default.
|
||||
Kubernetes authorizes API requests using the API server. It evaluates all of the
|
||||
request attributes against all policies and allows or denies the request. All
|
||||
parts of an API request must be allowed by some policy in order to proceed. This
|
||||
means that permissions are denied by default.
|
||||
|
||||
(Although Kubernetes uses the API server, access controls and policies that depend on specific fields of specific kinds of objects are handled by Admission Controllers.)
|
||||
(Although Kubernetes uses the API server, access controls and policies that
|
||||
depend on specific fields of specific kinds of objects are handled by Admission
|
||||
Controllers.)
|
||||
|
||||
When multiple authorization modules are configured, each is checked in sequence, and if any module authorizes the request, then the request can proceed. If all modules deny the request, then the request is denied (HTTP status code 403).
|
||||
When multiple authorization modules are configured, each is checked in sequence.
|
||||
If any authorizer approves or denies a request, that decision is immediately
|
||||
returned and no other authorizer is consulted. If all modules have no opinion on
|
||||
the request, then the request is denied. A deny returns an HTTP status code 403.
|
||||
|
||||
## Review Your Request Attributes
|
||||
Kubernetes reviews only the following API request attributes:
|
||||
@@ -33,14 +47,15 @@ Kubernetes reviews only the following API request attributes:
|
||||
* **Request path** - Path to miscellaneous non-resource endpoints like `/api` or `/healthz`.
|
||||
* **API request verb** - API verbs `get`, `list`, `create`, `update`, `patch`, `watch`, `proxy`, `redirect`, `delete`, and `deletecollection` are used for resource requests. To determine the request verb for a resource API endpoint, see **Determine the request verb** below.
|
||||
* **HTTP request verb** - HTTP verbs `get`, `post`, `put`, and `delete` are used for non-resource requests.
|
||||
* **Resource** - The ID or name of the resource that is being accessed (for resource requests only)
|
||||
--* For resource requests using `get`, `update`, `patch`, and `delete` verbs, you must provide the resource name.
|
||||
* **Resource** - The ID or name of the resource that is being accessed (for resource requests only) -- For resource requests using `get`, `update`, `patch`, and `delete` verbs, you must provide the resource name.
|
||||
* **Subresource** - The subresource that is being accessed (for resource requests only).
|
||||
* **Namespace** - The namespace of the object that is being accessed (for namespaced resource requests only).
|
||||
* **API group** - The API group being accessed (for resource requests only). An empty string designates the [core API group](/docs/concepts/overview/kubernetes-api/).
|
||||
|
||||
## Determine the Request Verb
|
||||
To determine the request verb for a resource API endpoint, review the HTTP verb used and whether or not the request acts on an individual resource or a collection of resources:
|
||||
To determine the request verb for a resource API endpoint, review the HTTP verb
|
||||
used and whether or not the request acts on an individual resource or a
|
||||
collection of resources:
|
||||
|
||||
HTTP verb | request verb
|
||||
----------|---------------
|
||||
@@ -87,8 +102,9 @@ $ kubectl auth can-i list secrets --namespace dev --as dave
|
||||
no
|
||||
```
|
||||
|
||||
`SelfSubjectAccessReview` is part of the `authorization.k8s.io` API group, which exposes the
|
||||
API server authorization to external services. Other resources in this group include:
|
||||
`SelfSubjectAccessReview` is part of the `authorization.k8s.io` API group, which
|
||||
exposes the API server authorization to external services. Other resources in
|
||||
this group include:
|
||||
|
||||
* `SubjectAccessReview` - Access review for any user, not just the current one. Useful for delegating authorization decisions to the API server. For example, the kubelet and extension API servers use this to determine user access to their own APIs.
|
||||
* `LocalSubjectAccessReview` - Like `SubjectAccessReview` but restricted to a specific namespace.
|
||||
@@ -121,11 +137,13 @@ spec:
|
||||
verb: create
|
||||
status:
|
||||
allowed: true
|
||||
denied: false
|
||||
```
|
||||
|
||||
## Using Flags for Your Authorization Module
|
||||
|
||||
You must include a flag in your policy to indicate which authorization module your policies include:
|
||||
You must include a flag in your policy to indicate which authorization module
|
||||
your policies include:
|
||||
|
||||
The following flags can be used:
|
||||
|
||||
@@ -136,12 +154,8 @@ The following flags can be used:
|
||||
* `--authorization-mode=AlwaysDeny` This flag blocks all requests. Use this flag only for testing.
|
||||
* `--authorization-mode=AlwaysAllow` This flag allows all requests. Use this flag only if you do not require authorization for your API requests.
|
||||
|
||||
You can choose more than one authorization module. If one of the modes is `AlwaysAllow`, then it overrides the other modes and all API requests are allowed.
|
||||
|
||||
## Versioning
|
||||
For version 1.2, clusters created by kube-up.sh are configured so that no authorization is required for any request.
|
||||
|
||||
As of version 1.3, clusters created by kube-up.sh are configured so that the ABAC authorization modules are enabled. However, its input file is initially set to allow all users to do all operations. The cluster administrator needs to edit that file, or configure a different authorizer to restrict what users can do.
|
||||
You can choose more than one authorization module. Modules are checked in order
|
||||
so an earlier module has higher priority to allow or deny a request.
|
||||
|
||||
{% endcapture %}
|
||||
{% capture whatsnext %}
|
||||
@@ -153,7 +167,16 @@ As of version 1.3, clusters created by kube-up.sh are configured so that the A
|
||||
|
||||
## Privilege escalation via pod creation
|
||||
|
||||
Users who have ability to create pods in a namespace can potentially escalate their privileges within that namespace. They can create pods that access secrets the user cannot themselves read, or that run under a service account with different/greater permissions.
|
||||
Users who have the ability to create pods in a namespace can potentially
|
||||
escalate their privileges within that namespace. They can create pods that
|
||||
access their privileges within that namespace. They can create pods that access
|
||||
secrets the user cannot themselves read, or that run under a service account
|
||||
with different/greater permissions.
|
||||
|
||||
**Caution:** System administrators, use care when granting access to pod creation. A user granted permission to create pods (or controllers that create pods) in the namespace can: read all secrets in the namespace; read all config maps in the namespace; and impersonate any service account in the namespace and take any action the account could take. This applies regardless of authorization mode.
|
||||
**Caution:** System administrators, use care when granting access to pod
|
||||
creation. A user granted permission to create pods (or controllers that create
|
||||
pods) in the namespace can: read all secrets in the namespace; read all config
|
||||
maps in the namespace; and impersonate any service account in the namespace and
|
||||
take any action the account could take. This applies regardless of authorization
|
||||
mode.
|
||||
{: .caution}
|
||||
|
||||
@@ -191,6 +191,76 @@ Because resource names are not present in the URL for create, list, watch, and d
|
||||
those verbs would not be allowed by a rule with resourceNames set, since the resourceNames portion of the
|
||||
rule would not match the request.
|
||||
|
||||
### Aggregated ClusterRoles
|
||||
|
||||
As of 1.9, ClusterRoles can be created by combining other ClusterRoles using an `aggregationRule`. The
|
||||
permissions of aggregated ClusterRoles are controller-managed, and filled in by unioning the rules of any
|
||||
ClusterRole that matches the provided label selector. An example aggregated ClusterRole:
|
||||
|
||||
```yaml
|
||||
kind: ClusterRole
|
||||
apiVersion: rbac.authorization.k8s.io/v1
|
||||
metadata:
|
||||
name: monitoring
|
||||
aggregationRule:
|
||||
clusterRoleSelectors:
|
||||
- matchLabels:
|
||||
rbac.example.com/aggregate-to-monitoring: "true"
|
||||
rules: [] # Rules are automatically filled in by the controller manager.
|
||||
```
|
||||
|
||||
Creating a ClusterRole that matches the label selector will add rules to the aggregated ClusterRole. In this case
|
||||
rules can be added to the "monitoring" ClusterRole by creating another ClusterRole that has the label
|
||||
`rbac.example.com/aggregate-to-monitoring: true`.
|
||||
|
||||
```yaml
|
||||
kind: ClusterRole
|
||||
apiVersion: rbac.authorization.k8s.io/v1
|
||||
metadata:
|
||||
name: monitoring-endpoints
|
||||
labels:
|
||||
rbac.example.com/aggregate-to-monitoring: "true"
|
||||
# These rules will be added to the "monitoring" role.
|
||||
rules:
|
||||
- apiGroups: [""]
|
||||
Resources: ["services", "endpoints", "pods"]
|
||||
verbs: ["get", "list", "watch"]
|
||||
```
|
||||
|
||||
The default user-facing roles (described below) use ClusterRole aggregation. This lets admins include rules
|
||||
for custom resources, such as those served by CustomResourceDefinitions or Aggregated API servers, on the
|
||||
default roles.
|
||||
|
||||
For example, the following ClusterRoles let the "admin" and "edit" default roles manage the custom resource
|
||||
"CronTabs" and the "view" role perform read-only actions on the resource.
|
||||
|
||||
```yaml
|
||||
kind: ClusterRole
|
||||
apiVersion: rbac.authorization.k8s.io/v1
|
||||
metadata:
|
||||
name: aggregate-cron-tabs-edit
|
||||
labels:
|
||||
# Add these permissions to the "admin" and "edit" default roles.
|
||||
rbac.authorization.k8s.io/aggregate-to-admin: "true"
|
||||
rbac.authorization.k8s.io/aggregate-to-edit: "true"
|
||||
rules:
|
||||
- apiGroups: ["stable.example.com"]
|
||||
resources: ["crontabs"]
|
||||
verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
|
||||
---
|
||||
kind: ClusterRole
|
||||
apiVersion: rbac.authorization.k8s.io/v1
|
||||
metadata:
|
||||
name: aggregate-cron-tabs-view
|
||||
labels:
|
||||
# Add these permissions to the "view" default role.
|
||||
rbac.authorization.k8s.io/aggregate-to-view: "true"
|
||||
rules:
|
||||
- apiGroups: ["stable.example.com"]
|
||||
resources: ["crontabs"]
|
||||
verbs: ["get", "list", "watch"]
|
||||
```
|
||||
|
||||
#### Role Examples
|
||||
|
||||
Only the `rules` section is shown in the following examples.
|
||||
@@ -402,6 +472,18 @@ They include super-user roles (`cluster-admin`),
|
||||
roles intended to be granted cluster-wide using ClusterRoleBindings (`cluster-status`),
|
||||
and roles intended to be granted within particular namespaces using RoleBindings (`admin`, `edit`, `view`).
|
||||
|
||||
As of 1.9, user-facing roles use [ClusterRole Aggregation](#aggregated-clusterroles) to allow admins to include
|
||||
rules for custom resources on these roles. To add rules to the "admin", "edit", or "view" role, create a
|
||||
ClusterRole with one or more of the following labels:
|
||||
|
||||
```yaml
|
||||
metadata:
|
||||
labels:
|
||||
rbac.authorization.k8s.io/aggregate-to-admin: "true"
|
||||
rbac.authorization.k8s.io/aggregate-to-edit: "true"
|
||||
rbac.authorization.k8s.io/aggregate-to-view: "true"
|
||||
```
|
||||
|
||||
<table>
|
||||
<colgroup><col width="25%"><col width="25%"><col></colgroup>
|
||||
<tr>
|
||||
@@ -546,6 +628,7 @@ These roles include:
|
||||
* system:controller:node-controller
|
||||
* system:controller:persistent-volume-binder
|
||||
* system:controller:pod-garbage-collector
|
||||
* system:controller:pvc-protection-controller
|
||||
* system:controller:replicaset-controller
|
||||
* system:controller:replication-controller
|
||||
* system:controller:resourcequota-controller
|
||||
|
||||
Reference in New Issue
Block a user