Update authorization links (#9465)

* update authorization links * remove cn content and fix link targets
2018-07-18 18:07:24 -04:00
parent f140cbc6f2
commit bf109b4dfa
12 changed files with 16 additions and 16 deletions
@@ -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
@@ -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.

@@ -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.

@@ -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:

@@ -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
@@ -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:

@@ -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.

@@ -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

@@ -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.
@@ -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).