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 b49d716a2f5..d95c3e5e4bb 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 @@ -30,7 +30,7 @@ There is work in progress being done in Kubernetes for image authorization plugi **Limit Direct Access to Kubernetes Nodes** You should limit SSH access to Kubernetes nodes, reducing the risk for unauthorized access to host resource. Instead you should ask users to use "kubectl exec", which will provide direct access to the container environment without the ability to access the host. -You can use Kubernetes [Authorization Plugins](http://kubernetes.io/docs/admin/authorization/) to further control user access to resources. This allows defining fine-grained-access control rules for specific namespace, containers and operations. +You can use Kubernetes [Authorization Plugins](http://kubernetes.io/docs/reference/access-authn-authz/authorization/) to further control user access to resources. This allows defining fine-grained-access control rules for specific namespace, containers and operations. **Create Administrative Boundaries between Resources** Limiting the scope of user permissions can reduce the impact of mistakes or malicious activities. A Kubernetes namespace allows you to partition created resources into logically named groups. Resources created in one namespace can be hidden from other namespaces. By default, each resource created by a user in Kubernetes cluster runs in a default namespace, called default. You can create additional namespaces and attach resources and users to them. You can use Kubernetes Authorization plugins to create policies that segregate access to namespace resources between different users. diff --git a/content/en/blog/_posts/2017-04-00-Rbac-Support-In-Kubernetes.md b/content/en/blog/_posts/2017-04-00-Rbac-Support-In-Kubernetes.md index 6a4610a6d0f..84f3c64d774 100644 --- a/content/en/blog/_posts/2017-04-00-Rbac-Support-In-Kubernetes.md +++ b/content/en/blog/_posts/2017-04-00-Rbac-Support-In-Kubernetes.md @@ -13,7 +13,7 @@ The focus of this post is to highlight some of the interesting new capabilities **RBAC vs ABAC** -Currently there are several [authorization mechanisms](https://kubernetes.io/docs/admin/authorization/) available for use with Kubernetes. Authorizers are the mechanisms that decide who is permitted to make what changes to the cluster using the Kubernetes API. This affects things like kubectl, system components, and also certain applications that run in the cluster and manipulate the state of the cluster, like Jenkins with the Kubernetes plugin, or [Helm](https://github.com/kubernetes/helm) that runs in the cluster and uses the Kubernetes API to install applications in the cluster. Out of the available authorization mechanisms, ABAC and RBAC are the mechanisms local to a Kubernetes cluster that allow configurable permissions policies. +Currently there are several [authorization mechanisms](https://kubernetes.io/docs/reference/access-authn-authz/authorization/) available for use with Kubernetes. Authorizers are the mechanisms that decide who is permitted to make what changes to the cluster using the Kubernetes API. This affects things like kubectl, system components, and also certain applications that run in the cluster and manipulate the state of the cluster, like Jenkins with the Kubernetes plugin, or [Helm](https://github.com/kubernetes/helm) that runs in the cluster and uses the Kubernetes API to install applications in the cluster. Out of the available authorization mechanisms, ABAC and RBAC are the mechanisms local to a Kubernetes cluster that allow configurable permissions policies. ABAC, Attribute Based Access Control, is a powerful concept. However, as implemented in Kubernetes, ABAC is difficult to manage and understand. It requires ssh and root filesystem access on the master VM of the cluster to make authorization policy changes. For permission changes to take effect the cluster API server must be restarted. diff --git a/content/en/docs/concepts/architecture/master-node-communication.md b/content/en/docs/concepts/architecture/master-node-communication.md index 013674f210b..580b4d95a2a 100644 --- a/content/en/docs/concepts/architecture/master-node-communication.md +++ b/content/en/docs/concepts/architecture/master-node-communication.md @@ -28,10 +28,10 @@ All communication paths from the cluster to the master terminate at the apiserver (none of the other master components are designed to expose remote services). In a typical deployment, the apiserver is configured to listen for remote connections on a secure HTTPS port (443) with one or more forms of -client [authentication](/docs/reference/access-authn-authz/authentication/) enabled. One or more forms -of [authorization](/docs/admin/authorization/) should be enabled, especially -if [anonymous requests](/docs/reference/access-authn-authz/authentication/#anonymous-requests) or -[service account tokens](/docs/reference/access-authn-authz/authentication/#service-account-tokens) +client [authentication](/docs/reference/access-authn-authz/authentication/) enabled. +One or more forms of [authorization](/docs/reference/access-authn-authz/authorization/) +should be enabled, especially if [anonymous requests](/docs/reference/access-authn-authz/authentication/#anonymous-requests) +or [service account tokens](/docs/reference/access-authn-authz/authentication/#service-account-tokens) are allowed. Nodes should be provisioned with the public root certificate for the cluster 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 97ee3ac7052..df22d5c6d52 100644 --- a/content/en/docs/concepts/cluster-administration/cluster-administration-overview.md +++ b/content/en/docs/concepts/cluster-administration/cluster-administration-overview.md @@ -52,7 +52,7 @@ Note: Not all distros are actively maintained. Choose distros which have been te * [Authenticating](/docs/reference/access-authn-authz/authentication/) explains authentication in Kubernetes, including the various authentication options. -* [Authorization](/docs/admin/authorization/) is separate from authentication, and controls how HTTP calls are handled. +* [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. diff --git a/content/en/docs/imported/community/devel.md b/content/en/docs/imported/community/devel.md index 6f4fe9c510d..cdf8ee6385b 100644 --- a/content/en/docs/imported/community/devel.md +++ b/content/en/docs/imported/community/devel.md @@ -68,7 +68,7 @@ Guide](http://kubernetes.io/docs/admin/). * **Authentication** ([Authentication](http://kubernetes.io/docs/reference/access-authn-authz/authentication/)): The current and planned states of authentication tokens. -* **Authorization Plugins** ([Authorization](http://kubernetes.io/docs/admin/authorization/)): +* **Authorization Plugins** ([Authorization](http://kubernetes.io/docs/reference/access-authn-authz/authorization/)): Authorization applies to all HTTP requests on the main apiserver port. This doc explains the available authorization implementations. diff --git a/content/en/docs/reference/access-authn-authz/authentication.md b/content/en/docs/reference/access-authn-authz/authentication.md index 77e742aac55..3c782dda08a 100644 --- a/content/en/docs/reference/access-authn-authz/authentication.md +++ b/content/en/docs/reference/access-authn-authz/authentication.md @@ -51,7 +51,7 @@ with the request: * Extra fields: a map of strings to list of strings which holds additional information authorizers may find useful. All values are opaque to the authentication system and only hold significance -when interpreted by an [authorizer](/docs/admin/authorization/). +when interpreted by an [authorizer](/docs/reference/access-authn-authz/authorization/). You can enable multiple authentication methods at once. You should usually use at least two methods: 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 cc78d081d80..63b8b4afcd5 100644 --- a/content/en/docs/reference/access-authn-authz/controlling-access.md +++ b/content/en/docs/reference/access-authn-authz/controlling-access.md @@ -104,7 +104,7 @@ Kubernetes authorization requires that you use common REST attributes to interac Kubernetes supports multiple authorization modules, such as ABAC mode, RBAC Mode, and Webhook mode. When an administrator creates a cluster, they configured the authorization modules that should be used in the API server. If more than one authorization modules are configured, Kubernetes checks each module, and if any module authorizes the request, then the request can proceed. If all of the modules deny the request, then the request is denied (HTTP status code 403). -To learn more about Kubernetes authorization, including details about creating policies using the supported authorization modules, see [Authorization Overview](/docs/admin/authorization/). +To learn more about Kubernetes authorization, including details about creating policies using the supported authorization modules, see [Authorization Overview](/docs/reference/access-authn-authz/authorization/). ## Admission Control diff --git a/content/en/docs/reference/command-line-tools-reference/kubelet-authentication-authorization.md b/content/en/docs/reference/command-line-tools-reference/kubelet-authentication-authorization.md index 9056829f831..2e408ff18b5 100644 --- a/content/en/docs/reference/command-line-tools-reference/kubelet-authentication-authorization.md +++ b/content/en/docs/reference/command-line-tools-reference/kubelet-authentication-authorization.md @@ -51,7 +51,7 @@ To subdivide access to the kubelet API, delegate authorization to the API server * start the kubelet with the `--authorization-mode=Webhook` and the `--kubeconfig` flags * the kubelet calls the `SubjectAccessReview` API on the configured API server to determine whether each request is authorized -The kubelet authorizes API requests using the same [request attributes](/docs/admin/authorization/#request-attributes) approach as the apiserver. +The kubelet authorizes API requests using the same [request attributes](/docs/reference/access-authn-authz/authorization/#review-your-request-attributes) approach as the apiserver. The verb is determined from the incoming request's HTTP verb: diff --git a/content/en/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping.md b/content/en/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping.md index f77ebcefc40..1acb9636f89 100644 --- a/content/en/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping.md +++ b/content/en/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping.md @@ -72,7 +72,7 @@ The kube-controller-manager flags are: In 1.7 the experimental "group auto approver" controller is dropped in favor of the new `csrapproving` controller that ships as part of [kube-controller-manager](/docs/admin/kube-controller-manager/) and is enabled by default. -The controller uses the [`SubjectAccessReview` API](/docs/admin/authorization/#checking-api-access) to determine +The controller uses the [`SubjectAccessReview` API](/docs/reference/access-authn-authz/authorization/#checking-api-access) to determine if a given user is authorized to request a CSR, then approves based on the authorization outcome. To prevent conflicts with other approvers, the builtin approver doesn't explicitly deny CSRs, only ignoring unauthorized requests. 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 279ee2f2e8f..2235d5ab124 100644 --- a/content/en/docs/tasks/administer-cluster/securing-a-cluster.md +++ b/content/en/docs/tasks/administer-cluster/securing-a-cluster.md @@ -70,7 +70,7 @@ being terminated and recreated on other nodes. The out of the box roles represen between flexibility and the common use cases, but more limited roles should be carefully reviewed to prevent accidental escalation. You can make roles specific to your use case if the out-of-box ones don't meet your needs. -Consult the [authorization reference section](/docs/admin/authorization/) for more information. +Consult the [authorization reference section](/docs/reference/access-authn-authz/authorization/) for more information. ## Controlling access to the Kubelet diff --git a/content/en/docs/tasks/configure-pod-container/configure-service-account.md b/content/en/docs/tasks/configure-pod-container/configure-service-account.md index 1586ceed1ff..f33d96a792c 100644 --- a/content/en/docs/tasks/configure-pod-container/configure-service-account.md +++ b/content/en/docs/tasks/configure-pod-container/configure-service-account.md @@ -50,7 +50,7 @@ you can see the `spec.serviceAccountName` field has been You can access the API from inside a pod using automatically mounted service account credentials, as described in [Accessing the Cluster](/docs/user-guide/accessing-the-cluster/#accessing-the-api-from-a-pod). -The API permissions a service account has depend on the [authorization plugin and policy](/docs/admin/authorization/#a-quick-note-on-service-accounts) in use. +The API permissions of the service account depend on the [authorization plugin and policy](/docs/reference/access-authn-authz/authorization/#authorization-modules) in use. In version 1.6+, you can opt out of automounting API credentials for a service account by setting `automountServiceAccountToken: false` on the service account: @@ -122,7 +122,7 @@ secrets: then you will see that a token has automatically been created and is referenced by the service account. -You may use authorization plugins to [set permissions on service accounts](/docs/admin/authorization/#a-quick-note-on-service-accounts). +You may use authorization plugins to [set permissions on service accounts](docs/reference/access-authn-authz/authorization/#service-account-permissions). To use a non-default service account, simply set the `spec.serviceAccountName` field of a pod to the name of the service account you wish to use. 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 3d986d32177..8141816fa72 100644 --- a/content/en/docs/user-journeys/users/cluster-operator/intermediate.md +++ b/content/en/docs/user-journeys/users/cluster-operator/intermediate.md @@ -65,7 +65,7 @@ In Kubernetes, you configure access control: 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. -* [Authorization Overview](/docs/admin/authorization/) +* [Authorization Overview](/docs/reference/access-authn-authz/authorization/) * [Using RBAC Authorization](/docs/admin/authorization/rbac/) You should create Secrets to hold sensitive data such as passwords, tokens, or keys. Be aware, however, that there are limitations to the protections that a Secret can provide. See [the Risks section of the Secrets documentation](/docs/concepts/configuration/secret/#risks).