diff --git a/content/en/blog/_posts/2016-08-00-Security-Best-Practices-Kubernetes-Deployment.md b/content/en/blog/_posts/2016-08-00-Security-Best-Practices-Kubernetes-Deployment.md index d95c3e5e4bb6a..74bb85843ad28 100644 --- a/content/en/blog/_posts/2016-08-00-Security-Best-Practices-Kubernetes-Deployment.md +++ b/content/en/blog/_posts/2016-08-00-Security-Best-Practices-Kubernetes-Deployment.md @@ -205,7 +205,7 @@ Reference [here](http://kubernetes.io/docs/api-reference/v1/definitions/#_v1_pod -In case you are running containers with elevated privileges (--privileged) you should consider using the “DenyEscalatingExec” admission control. This control denies 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. For more details on admission controls, see the Kubernetes [documentation](http://kubernetes.io/docs/admin/admission-controllers/). +In case you are running containers with elevated privileges (--privileged) you should consider using the “DenyEscalatingExec” admission control. This control denies 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. For more details on admission controls, see the Kubernetes [documentation](http://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/). 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/cluster-administration/cluster-administration-overview.md b/content/en/docs/concepts/cluster-administration/cluster-administration-overview.md index df22d5c6d527e..e46a8025a1894 100644 --- a/content/en/docs/concepts/cluster-administration/cluster-administration-overview.md +++ b/content/en/docs/concepts/cluster-administration/cluster-administration-overview.md @@ -54,7 +54,7 @@ Note: Not all distros are actively maintained. Choose distros which have been te * [Authorization](/docs/reference/access-authn-authz/authorization/) is separate from authentication, and controls how HTTP calls are handled. -* [Using Admission Controllers](/docs/admin/admission-controllers/) explains plug-ins which intercepts requests to the Kubernetes API server after authentication and authorization. +* [Using Admission Controllers](/docs/reference/access-authn-authz/admission-controllers/) explains plug-ins which intercepts requests to the Kubernetes API server after authentication and authorization. * [Using Sysctls in a Kubernetes Cluster](/docs/concepts/cluster-administration/sysctl-cluster/) describes to an administrator how to use the `sysctl` command-line tool to set kernel parameters . diff --git a/content/en/docs/concepts/configuration/taint-and-toleration.md b/content/en/docs/concepts/configuration/taint-and-toleration.md index 07b5af707cb2a..c989e7e23021a 100644 --- a/content/en/docs/concepts/configuration/taint-and-toleration.md +++ b/content/en/docs/concepts/configuration/taint-and-toleration.md @@ -160,7 +160,7 @@ pods that shouldn't be running. A few of the use cases are a particular set of users, you can add a taint to those nodes (say, `kubectl taint nodes nodename dedicated=groupName:NoSchedule`) and then add a corresponding toleration to their pods (this would be done most easily by writing a custom -[admission controller](/docs/admin/admission-controllers/)). +[admission controller](/docs/reference/access-authn-authz/admission-controllers/)). The pods with the tolerations will then be allowed to use the tainted (dedicated) nodes as well as any other nodes in the cluster. If you want to dedicate the nodes to them *and* ensure they *only* use the dedicated nodes, then you should additionally add a label similar @@ -176,12 +176,12 @@ hardware (e.g. `kubectl taint nodes nodename special=true:NoSchedule` or `kubectl taint nodes nodename special=true:PreferNoSchedule`) and adding a corresponding toleration to pods that use the special hardware. As in the dedicated nodes use case, it is probably easiest to apply the tolerations using a custom -[admission controller](/docs/admin/admission-controllers/)). +[admission controller](/docs/reference/access-authn-authz/admission-controllers/). 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 2c995e4a60c41..9172616e2e0be 100644 --- a/content/en/docs/concepts/extend-kubernetes/extend-cluster.md +++ b/content/en/docs/concepts/extend-kubernetes/extend-cluster.md @@ -152,9 +152,9 @@ Kubernetes provides several built-in authentication methods, and an [Authenticat ### Dynamic Admission Control -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: +After a request is authorized, if it is a write operation, it also goes through [Admission Control](/docs/reference/access-authn-authz/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/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks) can be used. Admission Webhooks can reject creations or updates. * [Initializers](/docs/reference/access-authn-authz/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 a4b4528562d40..43f7d62895619 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 a9bb82659f614..ca1788de24335 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 c410b6578c010..f81950f7c26c9 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 03e5817629a6b..20a28f977bc1a 100644 --- a/content/en/docs/concepts/workloads/controllers/garbage-collection.md +++ b/content/en/docs/concepts/workloads/controllers/garbage-collection.md @@ -86,7 +86,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/authentication.md b/content/en/docs/reference/access-authn-authz/authentication.md index 07aad28e32685..16aad74e2587d 100644 --- a/content/en/docs/reference/access-authn-authz/authentication.md +++ b/content/en/docs/reference/access-authn-authz/authentication.md @@ -184,7 +184,7 @@ If unspecified, the API server's TLS private key will be used. Service accounts are usually created automatically by the API server and associated with pods running in the cluster through the `ServiceAccount` -[Admission Controller](/docs/admin/admission-controllers/). Bearer tokens are +[Admission Controller](/docs/reference/access-authn-authz/admission-controllers/). Bearer tokens are mounted into pods at well-known locations, and allow in-cluster processes to talk to the API server. Accounts may be explicitly associated with pods using the `serviceAccountName` field of a `PodSpec`. diff --git a/content/en/docs/reference/access-authn-authz/controlling-access.md b/content/en/docs/reference/access-authn-authz/controlling-access.md index 63b8b4afcd5f5..0873e6c85317b 100644 --- a/content/en/docs/reference/access-authn-authz/controlling-access.md +++ b/content/en/docs/reference/access-authn-authz/controlling-access.md @@ -124,7 +124,7 @@ rejects, then the request is immediately rejected. In addition to rejecting objects, admission controllers can also set complex defaults for fields. -The available Admission Control Modules are described [here](/docs/admin/admission-controllers/). +The available Admission Control Modules are described [here](/docs/reference/access-authn-authz/admission-controllers/). Once a request passes all admission controllers, it is validated using the validation routines for the corresponding API object, and then written to the object store (shown as step **4**). diff --git a/content/en/docs/reference/access-authn-authz/rbac.md b/content/en/docs/reference/access-authn-authz/rbac.md index 42f231b48d9d4..b3b31a36ad9f7 100644 --- a/content/en/docs/reference/access-authn-authz/rbac.md +++ b/content/en/docs/reference/access-authn-authz/rbac.md @@ -556,7 +556,8 @@ 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/command-line-tools-reference/feature-gates.md b/content/en/docs/reference/command-line-tools-reference/feature-gates.md index 9c4a4fba10da2..127a8caafe5dc 100644 --- a/content/en/docs/reference/command-line-tools-reference/feature-gates.md +++ b/content/en/docs/reference/command-line-tools-reference/feature-gates.md @@ -193,7 +193,7 @@ Each feature gate is designed for enabling/disabling a specific feature: - `HugePages`: Enable the allocation and consumption of pre-allocated [huge pages](/docs/tasks/manage-hugepages/scheduling-hugepages/). - `HyperVContainer`: Enable [Hyper-V isolation](https://docs.microsoft.com/en-us/virtualization/windowscontainers/manage-containers/hyperv-container) for Windows containers. - `Intializers`: Enable the [dynamic admission control](/docs/reference/access-authn-authz/extensible-admission-controllers/) - as an extension to the built-in [admission controllers](/docs/admin/admission-controllers/). + as an extension to the built-in [admission controllers](/docs/reference/access-authn-authz/admission-controllers/). When the `Initializers` admission controller is enabled, this feature is automatically enabled. - `KubeletConfigFile`: Enable loading kubelet configuration from a file specified using a config file. See [setting kubelet parameters via a config file](/docs/tasks/administer-cluster/kubelet-config-file/) for more details. 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 a1cbe7f786ff7..342149e7cebe8 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/reference/access-authn-authz/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/reference/access-authn-authz/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/setup/scratch.md b/content/en/docs/setup/scratch.md index 175c7f69ea261..ad87cfcb8e35d 100644 --- a/content/en/docs/setup/scratch.md +++ b/content/en/docs/setup/scratch.md @@ -608,7 +608,7 @@ Here are some apiserver flags you may need to set: - `--tls-cert-file=/srv/kubernetes/server.cert` - `--tls-private-key-file=/srv/kubernetes/server.key` - `--enable-admission-plugins=$RECOMMENDED_LIST` - - See [admission controllers](/docs/admin/admission-controllers/) for recommended arguments. + - See [admission controllers](/docs/reference/access-authn-authz/admission-controllers/) for recommended arguments. - `--allow-privileged=true`, only if you trust your cluster user to run pods as root. If you are following the firewall-only security approach, then use these arguments: 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 986149901f389..0512f8b09a586 100644 --- a/content/en/docs/tasks/administer-cluster/securing-a-cluster.md +++ b/content/en/docs/tasks/administer-cluster/securing-a-cluster.md @@ -55,9 +55,8 @@ an integrated [Role-Based Access Control (RBAC)](/docs/reference/access-authn-au set of permissions bundled into roles. These permissions combine verbs (get, create, delete) with 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/reference/access-authn-authz/node/) -and [RBAC](/docs/reference/access-authn-authz/rbac/) authorizers together, in combination with the -[NodeRestriction](/docs/admin/admission-controllers/#noderestriction) admission plugin. +actions a client might want to perform. It is recommended that you use the [Node](/docs/reference/access-authn-authz/node/) and [RBAC](/docs/reference/access-authn-authz/rbac/) authorizers together, in combination with the +[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 diff --git a/content/en/docs/user-journeys/users/cluster-operator/intermediate.md b/content/en/docs/user-journeys/users/cluster-operator/intermediate.md index 5c02bf11926f0..b3c02c8824872 100644 --- a/content/en/docs/user-journeys/users/cluster-operator/intermediate.md +++ b/content/en/docs/user-journeys/users/cluster-operator/intermediate.md @@ -61,7 +61,7 @@ In Kubernetes, you configure access control: * [Controlling Access to the Kubernetes API](/docs/reference/access-authn-authz/controlling-access/) * [Authenticating](/docs/reference/access-authn-authz/authentication/) -* [Using Admission Controllers](/docs/admin/admission-controllers/) +* [Using Admission Controllers](/docs/reference/access-authn-authz/admission-controllers/) You also configure authorization. That is, you determine not just how users and services authenticate to the API server, or whether they have access, but also what resources they have access to. Role-based access control (RBAC) is the recommended mechanism for controlling authorization to Kubernetes resources. Other authorization modes are available for more specific use cases.