diff --git a/content/cn/docs/concepts/containers/images.md b/content/cn/docs/concepts/containers/images.md index 11f902444889c..484843d77beaa 100644 --- a/content/cn/docs/concepts/containers/images.md +++ b/content/cn/docs/concepts/containers/images.md @@ -284,10 +284,10 @@ spec: - 使用集群自动伸缩比手动配置node工作的更好 - 或者，在更改集群node配置不方便时，使用`imagePullSecrets` 1. 使用专有镜像的集群，有更严格的访问控制 - - 保证[AlwaysPullImages admission controller](/docs/admin/admission-controllers/#alwayspullimages)开启。否则，所有的pod都可以使用镜像 + - 保证[AlwaysPullImages admission controller](/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages)开启。否则，所有的pod都可以使用镜像 - 将敏感数据存储在"Secret"资源中，而不是打包在镜像里 1. 多租户集群下，每个租户需要自己的私有仓库 - - 保证[AlwaysPullImages admission controller](/docs/admin/admission-controllers/#alwayspullimages)开启。否则，所有租户的所有的pod都可以使用镜像 + - 保证[AlwaysPullImages admission controller](/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages)开启。否则，所有租户的所有的pod都可以使用镜像 - 私有仓库开启认证 - 为每个租户获取仓库凭证，放置在secret中，并发布到每个租户的namespace下 - 租户将secret增加到每个namespace下的imagePullSecrets中 diff --git a/content/cn/docs/concepts/policy/resource-quotas.md b/content/cn/docs/concepts/policy/resource-quotas.md index 5054cb7f25c49..357c2a4b709c7 100644 --- a/content/cn/docs/concepts/policy/resource-quotas.md +++ b/content/cn/docs/concepts/policy/resource-quotas.md @@ -12,14 +12,14 @@ title: 资源配额 资源配额的工作方式如下： -- 不同的团队在不同的namespace下工作。 目前这是自愿的， 但计划通过ACL (Access Control List 访问控制列表) +- 不同的团队在不同的namespace下工作。 目前这是自愿的， 但计划通过ACL (Access Control List 访问控制列表) 使其变为强制性的。 - 管理员为每个namespace创建一个或多个资源配额对象。 -- 用户在namespace下创建资源 (pods、 services等)，同时配额系统会跟踪使用情况，来确保其不超过 +- 用户在namespace下创建资源 (pods、 services等)，同时配额系统会跟踪使用情况，来确保其不超过 资源配额中定义的硬性资源限额。 -- 如果资源的创建或更新违反了配额约束，则请求会失败，并返回 HTTP状态码 `403 FORBIDDEN` ，以及说明违反配额 +- 如果资源的创建或更新违反了配额约束，则请求会失败，并返回 HTTP状态码 `403 FORBIDDEN` ，以及说明违反配额 约束的信息。 -- 如果namespace下的计算资源 （如 `cpu` 和 `memory`）的配额被启用，则用户必须为这些资源设定请求值（request） +- 如果namespace下的计算资源 （如 `cpu` 和 `memory`）的配额被启用，则用户必须为这些资源设定请求值（request） 和约束值（limit），否则配额系统将拒绝Pod的创建。 提示: 可使用 LimitRange 准入控制器来为没有设置计算资源需求的Pod设置默认值。 作为示例，请参考 [演练](/docs/tasks/administer-cluster/quota-memory-cpu-namespace/) 来避免这个问题。 @@ -86,7 +86,7 @@ title: 资源配额 | `persistentvolumeclaims` | namespace下允许存在的[PVC](/docs/user-guide/persistent-volumes/#persistentvolumeclaims)的数量。 | | `pods` | namespace下允许存在的非终止状态的pod数量。 如果pod 的 `status.phase 为 Failed 或 Succeeded` ， 那么其处于终止状态。 | | `replicationcontrollers` | namespace下允许存在的replication controllers的数量。 | -| `resourcequotas` | namespace下允许存在的 [resource quotas](/docs/admin/admission-controllers/#resourcequota) 的数量。 | +| `resourcequotas` | namespace下允许存在的 [resource quotas](/docs/reference/access-authn-authz/admission-controllers/#resourcequota) 的数量。 | | `services` | namespace下允许存在的service的数量。 | | `services.loadbalancers` | namespace下允许存在的load balancer类型的service的数量。 | | `services.nodeports` | namespace下允许存在的node port类型的service的数量。 | diff --git a/content/en/blog/_posts/2018-01-00-Extensible-Admission-Is-Beta.md b/content/en/blog/_posts/2018-01-00-Extensible-Admission-Is-Beta.md index 0a05159e68766..2f9ef3e537d85 100644 --- a/content/en/blog/_posts/2018-01-00-Extensible-Admission-Is-Beta.md +++ b/content/en/blog/_posts/2018-01-00-Extensible-Admission-Is-Beta.md @@ -11,7 +11,7 @@ The admission stage of API server processing is one of the most powerful tools f ## What is Admission? -[Admission](https://kubernetes.io/docs/admin/admission-controllers/#what-are-they) is the phase of [handling an API server request](https://blog.openshift.com/kubernetes-deep-dive-api-server-part-1/) that happens before a resource is persisted, but after authorization. Admission gets access to the same information as authorization (user, URL, etc) and the complete body of an API request (for most requests). +[Admission](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/#what-are-they) is the phase of [handling an API server request](https://blog.openshift.com/kubernetes-deep-dive-api-server-part-1/) that happens before a resource is persisted, but after authorization. Admission gets access to the same information as authorization (user, URL, etc) and the complete body of an API request (for most requests). [![](https://2.bp.blogspot.com/-p8WGg2BATsY/WlfywbD_tAI/AAAAAAAAAJw/mDqZV0dB4_Y0gXXQp_1tQ7CtMRSd6lHVwCK4BGAYYCw/s640/Screen%2BShot%2B2018-01-11%2Bat%2B3.22.07%2BPM.png)](http://2.bp.blogspot.com/-p8WGg2BATsY/WlfywbD_tAI/AAAAAAAAAJw/mDqZV0dB4_Y0gXXQp_1tQ7CtMRSd6lHVwCK4BGAYYCw/s1600/Screen%2BShot%2B2018-01-11%2Bat%2B3.22.07%2BPM.png) diff --git a/content/en/docs/concepts/configuration/taint-and-toleration.md b/content/en/docs/concepts/configuration/taint-and-toleration.md index 07b5af707cb2a..e2fabb6e97e01 100644 --- a/content/en/docs/concepts/configuration/taint-and-toleration.md +++ b/content/en/docs/concepts/configuration/taint-and-toleration.md @@ -181,7 +181,7 @@ For example, it is recommended to use [Extended Resources](/docs/concepts/configuration/manage-compute-resources-container/#extended-resources) to represent the special hardware, taint your special hardware nodes with the extended resource name and run the -[ExtendedResourceToleration](/docs/admin/admission-controllers/#extendedresourcetoleration) +[ExtendedResourceToleration](/docs/reference/access-authn-authz/admission-controllers/#extendedresourcetoleration) admission controller. Now, because the nodes are tainted, no pods without the toleration will schedule on them. But when you submit a pod that requests the extended resource, the `ExtendedResourceToleration` admission controller will diff --git a/content/en/docs/concepts/containers/images.md b/content/en/docs/concepts/containers/images.md index dc6c31f8585b3..523a562dbdb23 100644 --- a/content/en/docs/concepts/containers/images.md +++ b/content/en/docs/concepts/containers/images.md @@ -27,7 +27,7 @@ you can do one of the following: - set the `imagePullPolicy` of the container to `Always`; - use `:latest` as the tag for the image to use; -- enable the [AlwaysPullImages](/docs/admin/admission-controllers/#alwayspullimages) admission controller. +- enable the [AlwaysPullImages](/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages) admission controller. If you did not specify tag of your image, it will be assumed as `:latest`, with pull image policy of `Always` correspondingly. @@ -315,10 +315,10 @@ common use cases and suggested solutions. - It will work better with cluster autoscaling than manual node configuration. - Or, on a cluster where changing the node configuration is inconvenient, use `imagePullSecrets`. 1. Cluster with a proprietary images, a few of which require stricter access control. - - Ensure [AlwaysPullImages admission controller](/docs/admin/admission-controllers/#alwayspullimages) is active. Otherwise, all Pods potentially have access to all images. + - Ensure [AlwaysPullImages admission controller](/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages) is active. Otherwise, all Pods potentially have access to all images. - Move sensitive data into a "Secret" resource, instead of packaging it in an image. 1. A multi-tenant cluster where each tenant needs own private registry. - - Ensure [AlwaysPullImages admission controller](/docs/admin/admission-controllers/#alwayspullimages) is active. Otherwise, all Pods of all tenants potentially have access to all images. + - Ensure [AlwaysPullImages admission controller](/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages) is active. Otherwise, all Pods of all tenants potentially have access to all images. - Run a private registry with authorization required. - Generate registry credential for each tenant, put into secret, and populate secret to each tenant namespace. - The tenant adds that secret to imagePullSecrets of each namespace. diff --git a/content/en/docs/concepts/extend-kubernetes/extend-cluster.md b/content/en/docs/concepts/extend-kubernetes/extend-cluster.md index 0b4519ada40fd..bf8e873435aee 100644 --- a/content/en/docs/concepts/extend-kubernetes/extend-cluster.md +++ b/content/en/docs/concepts/extend-kubernetes/extend-cluster.md @@ -154,7 +154,7 @@ Kubernetes provides several built-in authentication methods, and an [Authenticat After a request is authorized, if it is a write operation, it also goes through [Admission Control](/docs/admin/admission-controllers/) steps. In addition to the built-in steps, there are several extensions: -* The [Image Policy webhook](/docs/admin/admission-controllers/#imagepolicywebhook) restricts what images can be run in containers. +* The [Image Policy webhook](/docs/reference/access-authn-authz/admission-controllers/#imagepolicywebhook) restricts what images can be run in containers. * To make arbitrary admission control decisions, a general [Admission webhook](/docs/admin/extensible-admission-controllers/#admission-webhooks) can be used. Admission Webhooks can reject creations or updates. * [Initializers](/docs/admin/extensible-admission-controllers/#initializers) are controllers that can modify objects before they are created. Initializers can modify initial object creations but cannot affect updates to objects. Initializers can also reject objects. diff --git a/content/en/docs/concepts/policy/pod-security-policy.md b/content/en/docs/concepts/policy/pod-security-policy.md index 9a1771980aab5..e9e617ddfb206 100644 --- a/content/en/docs/concepts/policy/pod-security-policy.md +++ b/content/en/docs/concepts/policy/pod-security-policy.md @@ -51,9 +51,9 @@ administrator to control the following: Pod security policy control is implemented as an optional (but recommended) [admission -controller](/docs/admin/admission-controllers/#podsecuritypolicy). PodSecurityPolicies +controller](/docs/reference/access-authn-authz/admission-controllers/#podsecuritypolicy). PodSecurityPolicies are enforced by [enabling the admission -controller](/docs/admin/admission-controllers/#how-do-i-turn-on-an-admission-control-plug-in), +controller](/docs/reference/access-authn-authz/admission-controllers/#how-do-i-turn-on-an-admission-control-plug-in), but doing so without authorizing any policies **will prevent any pods from being created** in the cluster. diff --git a/content/en/docs/concepts/policy/resource-quotas.md b/content/en/docs/concepts/policy/resource-quotas.md index c6d42462784b6..4d2e4b323c3cb 100644 --- a/content/en/docs/concepts/policy/resource-quotas.md +++ b/content/en/docs/concepts/policy/resource-quotas.md @@ -154,7 +154,7 @@ The following types are supported: | `persistentvolumeclaims` | The total number of [persistent volume claims](/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims) that can exist in the namespace. | | `pods` | The total number of pods in a non-terminal state that can exist in the namespace. A pod is in a terminal state if `.status.phase in (Failed, Succeeded)` is true. | | `replicationcontrollers` | The total number of replication controllers that can exist in the namespace. | -| `resourcequotas` | The total number of [resource quotas](/docs/admin/admission-controllers/#resourcequota) that can exist in the namespace. | +| `resourcequotas` | The total number of [resource quotas](/docs/reference/access-authn-authz/admission-controllers/#resourcequota) that can exist in the namespace. | | `services` | The total number of services that can exist in the namespace. | | `services.loadbalancers` | The total number of services of type load balancer that can exist in the namespace. | | `services.nodeports` | The total number of services of type node port that can exist in the namespace. | diff --git a/content/en/docs/concepts/storage/dynamic-provisioning.md b/content/en/docs/concepts/storage/dynamic-provisioning.md index e21e0b3659db5..ee8c0777d8d3f 100644 --- a/content/en/docs/concepts/storage/dynamic-provisioning.md +++ b/content/en/docs/concepts/storage/dynamic-provisioning.md @@ -110,7 +110,7 @@ dynamically provisioned if no storage class is specified. A cluster administrato can enable this behavior by: - Marking one `StorageClass` object as *default*; -- Making sure that the [`DefaultStorageClass` admission controller](/docs/admin/admission-controllers/#defaultstorageclass) +- Making sure that the [`DefaultStorageClass` admission controller](/docs/reference/access-authn-authz/admission-controllers/#defaultstorageclass) is enabled on the API server. An administrator can mark a specific `StorageClass` as default by adding the diff --git a/content/en/docs/concepts/storage/persistent-volumes.md b/content/en/docs/concepts/storage/persistent-volumes.md index 7c17119f7f94d..898b8c16bc24a 100644 --- a/content/en/docs/concepts/storage/persistent-volumes.md +++ b/content/en/docs/concepts/storage/persistent-volumes.md @@ -59,7 +59,7 @@ provisioning to occur. Claims that request the class `""` effectively disable dynamic provisioning for themselves. To enable dynamic storage provisioning based on storage class, the cluster administrator -needs to enable the `DefaultStorageClass` [admission controller](/docs/admin/admission-controllers/#defaultstorageclass) +needs to enable the `DefaultStorageClass` [admission controller](/docs/reference/access-authn-authz/admission-controllers/#defaultstorageclass) on the API server. This can be done, for example, by ensuring that `DefaultStorageClass` is among the comma-delimited, ordered list of values for the `--enable-admission-plugins` flag of the API server component. For more information on API server command line flags, @@ -466,7 +466,7 @@ equal to `""` is always interpreted to be requesting a PV with no class, so it can only be bound to PVs with no class (no annotation or one set equal to `""`). A PVC with no `storageClassName` is not quite the same and is treated differently by the cluster depending on whether the -[`DefaultStorageClass` admission plugin](/docs/admin/admission-controllers/#defaultstorageclass) +[`DefaultStorageClass` admission plugin](/docs/reference/access-authn-authz/admission-controllers/#defaultstorageclass) is turned on. * If the admission plugin is turned on, the administrator may specify a diff --git a/content/en/docs/concepts/workloads/controllers/garbage-collection.md b/content/en/docs/concepts/workloads/controllers/garbage-collection.md index ed4aa90cfe7ee..49dcd700b77ab 100644 --- a/content/en/docs/concepts/workloads/controllers/garbage-collection.md +++ b/content/en/docs/concepts/workloads/controllers/garbage-collection.md @@ -89,7 +89,7 @@ the owner object. Note that in the "foregroundDeletion", only dependents with `ownerReference.blockOwnerDeletion` block the deletion of the owner object. -Kubernetes version 1.7 added an [admission controller](/docs/admin/admission-controllers/#ownerreferencespermissionenforcement) that controls user access to set +Kubernetes version 1.7 added an [admission controller](/docs/reference/access-authn-authz/admission-controllers/#ownerreferencespermissionenforcement) that controls user access to set `blockOwnerDeletion` to true based on delete permissions on the owner object, so that unauthorized dependents cannot delay deletion of an owner object. diff --git a/content/en/docs/reference/access-authn-authz/rbac.md b/content/en/docs/reference/access-authn-authz/rbac.md index 70f8a77506da4..34479fd4f6343 100644 --- a/content/en/docs/reference/access-authn-authz/rbac.md +++ b/content/en/docs/reference/access-authn-authz/rbac.md @@ -556,7 +556,7 @@ The permissions required by individual control loops are contained in the system:node None in 1.8+ Allows access to resources required by the kubelet component, including read access to all secrets, and write access to all pod status objects. -As of 1.7, use of the Node authorizer and NodeRestriction admission plugin is recommended instead of this role, and allow granting API access to kubelets based on the pods scheduled to run on them. +As of 1.7, use of the Node authorizer and NodeRestriction admission plugin is recommended instead of this role, and allow granting API access to kubelets based on the pods scheduled to run on them. Prior to 1.7, this role was automatically bound to the `system:nodes` group. In 1.7, this role was automatically bound to the `system:nodes` group if the `Node` authorization mode is not enabled. In 1.8+, no binding is automatically created. diff --git a/content/en/docs/reference/setup-tools/kubeadm/implementation-details.md b/content/en/docs/reference/setup-tools/kubeadm/implementation-details.md index 35de6b056b5b6..7f33dde9ea1a6 100644 --- a/content/en/docs/reference/setup-tools/kubeadm/implementation-details.md +++ b/content/en/docs/reference/setup-tools/kubeadm/implementation-details.md @@ -239,17 +239,17 @@ Other API server flags that are set unconditionally are: - `--allow-privileged` to `true` (required e.g. by kube proxy) - `--requestheader-client-ca-file` to `front-proxy-ca.crt` - `--enable-admission-plugins` to: - - [`Initializers`](/docs/admin/admission-controllers/#initializers-alpha) to enable [Dynamic Admission Control](/docs/admin/extensible-admission-controllers/). - - [`NamespaceLifecycle`](/docs/admin/admission-controllers/#namespacelifecycle) e.g. to avoid deletion of + - [`Initializers`](/docs/reference/access-authn-authz/admission-controllers/#initializers-alpha) to enable [Dynamic Admission Control](/docs/admin/extensible-admission-controllers/). + - [`NamespaceLifecycle`](/docs/reference/access-authn-authz/admission-controllers/#namespacelifecycle) e.g. to avoid deletion of system reserved namespaces - - [`LimitRanger`](/docs/admin/admission-controllers/#limitranger) and [`ResourceQuota`](/docs/admin/admission-controllers/#resourcequota) to enforce limits on namespaces - - [`ServiceAccount`](/docs/admin/admission-controllers/#serviceaccount) to enforce service account automation - - [`PersistentVolumeLabel`](/docs/admin/admission-controllers/#persistentvolumelabel) attaches region or zone labels to + - [`LimitRanger`](/docs/reference/access-authn-authz/admission-controllers/#limitranger) and [`ResourceQuota`](/docs/reference/access-authn-authz/admission-controllers/#resourcequota) to enforce limits on namespaces + - [`ServiceAccount`](/docs/reference/access-authn-authz/admission-controllers/#serviceaccount) to enforce service account automation + - [`PersistentVolumeLabel`](/docs/reference/access-authn-authz/admission-controllers/#persistentvolumelabel) attaches region or zone labels to PersistentVolumes as defined by the cloud provider (This admission controller is deprecated and will be removed in a future version. It is not deployed by kubeadm by default with v1.9 onwards when not explicitly opting into using `gce` or `aws` as cloud providers) - - [`DefaultStorageClass`](/docs/admin/admission-controllers/#defaultstorageclass) to enforce default storage class on `PersistentVolumeClaim` objects - - [`DefaultTolerationSeconds`](/docs/admin/admission-controllers/#defaulttolerationseconds) - - [`NodeRestriction`](/docs/admin/admission-controllers/#noderestriction) to limit what a kubelet can modify + - [`DefaultStorageClass`](/docs/reference/access-authn-authz/admission-controllers/#defaultstorageclass) to enforce default storage class on `PersistentVolumeClaim` objects + - [`DefaultTolerationSeconds`](/docs/reference/access-authn-authz/admission-controllers/#defaulttolerationseconds) + - [`NodeRestriction`](/docs/reference/access-authn-authz/admission-controllers/#noderestriction) to limit what a kubelet can modify (e.g. only pods on this node) - `--kubelet-preferred-address-types` to `InternalIP,ExternalIP,Hostname;` this makes `kubectl logs` and other API server-kubelet communication work in environments where the hostnames of the nodes aren't resolvable diff --git a/content/en/docs/tasks/administer-cluster/securing-a-cluster.md b/content/en/docs/tasks/administer-cluster/securing-a-cluster.md index eb9ab0e7283b6..8337734395ebc 100644 --- a/content/en/docs/tasks/administer-cluster/securing-a-cluster.md +++ b/content/en/docs/tasks/administer-cluster/securing-a-cluster.md @@ -56,7 +56,7 @@ set of permissions bundled into roles. These permissions combine verbs (get, cre resources (pods, services, nodes) and can be namespace or cluster scoped. A set of out of the box roles are provided that offer reasonable default separation of responsibility depending on what actions a client might want to perform. It is recommended that you use the [Node](/docs/admin/authorization/node/) and [RBAC](/docs/admin/authorization/rbac/) authorizers together, in combination with the -[NodeRestriction](/docs/admin/admission-controllers/#noderestriction) admission plugin. +[NodeRestriction](/docs/reference/access-authn-authz/admission-controllers/#noderestriction) admission plugin. As with authentication, simple and broad roles may be appropriate for smaller clusters, but as more users interact with the cluster, it may become necessary to separate teams into separate