whentimeslows/website
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Update authorization links (#9465)

Browse Source 
* update authorization links

* remove cn content and fix link targets
This commit is contained in:
Bob Killen
2018-07-18 18:07:24 -04:00
committed by k8s-ci-robot
parent f140cbc6f2
commit bf109b4dfa
12 changed files with 16 additions and 16 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/en/docs/reference/access-authn-authz/authentication.md
+1 -1
View File
@@ -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:
content/en/docs/reference/access-authn-authz/controlling-access.md
+1 -1
View File
@@ -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
content/en/docs/reference/command-line-tools-reference/kubelet-authentication-authorization.md
+1 -1
View File
@@ -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:
content/en/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping.md
+1 -1
View File
@@ -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.