From f169101727973bca22d48ed81eaf004c58eabbd3 Mon Sep 17 00:00:00 2001 From: Mike Danese Date: Fri, 1 Dec 2017 15:19:29 -0800 Subject: [PATCH 1/3] line wrap --- docs/admin/authorization/index.md | 66 ++++++++++++++++++++++--------- 1 file changed, 48 insertions(+), 18 deletions(-) diff --git a/docs/admin/authorization/index.md b/docs/admin/authorization/index.md index a35b356457d23..a0d72e91bff62 100644 --- a/docs/admin/authorization/index.md +++ b/docs/admin/authorization/index.md @@ -8,20 +8,33 @@ title: Overview --- {% capture overview %} -Learn more about Kubernetes authorization, including details about creating policies using the supported authorization modules. +Learn more about Kubernetes authorization, including details about creating +policies using the supported authorization modules. {% endcapture %} {% capture body %} -In Kubernetes, you must be authenticated (logged in) before your request can be authorized (granted permission to access). For information about authentication, see [Accessing Control Overview](/docs/admin/accessing-the-api/). +In Kubernetes, you must be authenticated (logged in) before your request can be +authorized (granted permission to access). For information about authentication, +see [Accessing Control Overview](/docs/admin/accessing-the-api/). -Kubernetes expects attributes that are common to REST API requests. This means that Kubernetes authorization works with existing organization-wide or cloud-provider-wide access control systems which may handle other APIs besides the Kubernetes API. +Kubernetes expects attributes that are common to REST API requests. This means +that Kubernetes authorization works with existing organization-wide or +cloud-provider-wide access control systems which may handle other APIs besides +the Kubernetes API. ## Determine Whether a Request is Allowed or Denied -Kubernetes authorizes API requests using the API server. It evaluates all of the request attributes against all policies and allows or denies the request. All parts of an API request must be allowed by some policy in order to proceed. This means that permissions are denied by default. +Kubernetes authorizes API requests using the API server. It evaluates all of the +request attributes against all policies and allows or denies the request. All +parts of an API request must be allowed by some policy in order to proceed. This +means that permissions are denied by default. -(Although Kubernetes uses the API server, access controls and policies that depend on specific fields of specific kinds of objects are handled by Admission Controllers.) +(Although Kubernetes uses the API server, access controls and policies that +depend on specific fields of specific kinds of objects are handled by Admission +Controllers.) -When multiple authorization modules are configured, each is checked in sequence, and if any module authorizes the request, then the request can proceed. If all modules deny the request, then the request is denied (HTTP status code 403). +When multiple authorization modules are configured, each is checked in sequence, +and if any module authorizes the request, then the request can proceed. If all +modules deny the request, then the request is denied (HTTP status code 403). ## Review Your Request Attributes Kubernetes reviews only the following API request attributes: @@ -33,14 +46,15 @@ Kubernetes reviews only the following API request attributes: * **Request path** - Path to miscellaneous non-resource endpoints like `/api` or `/healthz`. * **API request verb** - API verbs `get`, `list`, `create`, `update`, `patch`, `watch`, `proxy`, `redirect`, `delete`, and `deletecollection` are used for resource requests. To determine the request verb for a resource API endpoint, see **Determine the request verb** below. * **HTTP request verb** - HTTP verbs `get`, `post`, `put`, and `delete` are used for non-resource requests. - * **Resource** - The ID or name of the resource that is being accessed (for resource requests only) ---* For resource requests using `get`, `update`, `patch`, and `delete` verbs, you must provide the resource name. + * **Resource** - The ID or name of the resource that is being accessed (for resource requests only) -- For resource requests using `get`, `update`, `patch`, and `delete` verbs, you must provide the resource name. * **Subresource** - The subresource that is being accessed (for resource requests only). * **Namespace** - The namespace of the object that is being accessed (for namespaced resource requests only). * **API group** - The API group being accessed (for resource requests only). An empty string designates the [core API group](/docs/concepts/overview/kubernetes-api/). ## Determine the Request Verb -To determine the request verb for a resource API endpoint, review the HTTP verb used and whether or not the request acts on an individual resource or a collection of resources: +To determine the request verb for a resource API endpoint, review the HTTP verb +used and whether or not the request acts on an individual resource or a +collection of resources: HTTP verb | request verb ----------|--------------- @@ -87,8 +101,9 @@ $ kubectl auth can-i list secrets --namespace dev --as dave no ``` -`SelfSubjectAccessReview` is part of the `authorization.k8s.io` API group, which exposes the -API server authorization to external services. Other resources in this group include: +`SelfSubjectAccessReview` is part of the `authorization.k8s.io` API group, which +exposes the API server authorization to external services. Other resources in +this group include: * `SubjectAccessReview` - Access review for any user, not just the current one. Useful for delegating authorization decisions to the API server. For example, the kubelet and extension API servers use this to determine user access to their own APIs. * `LocalSubjectAccessReview` - Like `SubjectAccessReview` but restricted to a specific namespace. @@ -125,7 +140,8 @@ status: ## Using Flags for Your Authorization Module -You must include a flag in your policy to indicate which authorization module your policies include: +You must include a flag in your policy to indicate which authorization module +your policies include: The following flags can be used: @@ -136,12 +152,18 @@ The following flags can be used: * `--authorization-mode=AlwaysDeny` This flag blocks all requests. Use this flag only for testing. * `--authorization-mode=AlwaysAllow` This flag allows all requests. Use this flag only if you do not require authorization for your API requests. -You can choose more than one authorization module. If one of the modes is `AlwaysAllow`, then it overrides the other modes and all API requests are allowed. +You can choose more than one authorization module. If one of the modes is +`AlwaysAllow`, then it overrides the other modes and all API requests are +allowed. ## Versioning -For version 1.2, clusters created by kube-up.sh are configured so that no authorization is required for any request. +For version 1.2, clusters created by kube-up.sh are configured so that no +authorization is required for any request. -As of version 1.3, clusters created by kube-up.sh are configured so that the ABAC authorization modules are enabled. However, its input file is initially set to allow all users to do all operations. The cluster administrator needs to edit that file, or configure a different authorizer to restrict what users can do. +As of version 1.3, clusters created by kube-up.sh are configured so that the +ABAC authorization modules are enabled. However, its input file is initially set +to allow all users to do all operations. The cluster administrator needs to edit +that file, or configure a different authorizer to restrict what users can do. {% endcapture %} {% capture whatsnext %} @@ -153,7 +175,15 @@ As of version 1.3, clusters created by kube-up.sh are configured so that the A ## Privilege escalation via pod creation -Users who have ability to create pods in a namespace can potentially escalate their privileges within that namespace. They can create pods that access secrets the user cannot themselves read, or that run under a service account with different/greater permissions. - -**Caution:** System administrators, use care when granting access to pod creation. A user granted permission to create pods (or controllers that create pods) in the namespace can: read all secrets in the namespace; read all config maps in the namespace; and impersonate any service account in the namespace and take any action the account could take. This applies regardless of authorization mode. +Users who have ability to create pods in a namespace can potentially escalate +their privileges within that namespace. They can create pods that access +secrets the user cannot themselves read, or that run under a service account +with different/greater permissions. + +**Caution:** System administrators, use care when granting access to pod +creation. A user granted permission to create pods (or controllers that create +pods) in the namespace can: read all secrets in the namespace; read all config +maps in the namespace; and impersonate any service account in the namespace and +take any action the account could take. This applies regardless of authorization +mode. {: .caution} From 3732136b7719dcb591dcee2fa5d8dd4d8c53f032 Mon Sep 17 00:00:00 2001 From: Mike Danese Date: Fri, 1 Dec 2017 15:21:23 -0800 Subject: [PATCH 2/3] short circuit deny --- docs/admin/authorization/index.md | 13 +++++++------ 1 file changed, 7 insertions(+), 6 deletions(-) diff --git a/docs/admin/authorization/index.md b/docs/admin/authorization/index.md index a0d72e91bff62..542899b45e1d3 100644 --- a/docs/admin/authorization/index.md +++ b/docs/admin/authorization/index.md @@ -32,9 +32,10 @@ means that permissions are denied by default. depend on specific fields of specific kinds of objects are handled by Admission Controllers.) -When multiple authorization modules are configured, each is checked in sequence, -and if any module authorizes the request, then the request can proceed. If all -modules deny the request, then the request is denied (HTTP status code 403). +When multiple authorization modules are configured, each is checked in sequence. +If any authorizer approves or denies a request, that decision is immediately +returned and no other authorizer is consulted. If all modules have no opinion on +the request, then the request is denied. A deny returns an HTTP status code 403. ## Review Your Request Attributes Kubernetes reviews only the following API request attributes: @@ -136,6 +137,7 @@ spec: verb: create status: allowed: true + denied: false ``` ## Using Flags for Your Authorization Module @@ -152,9 +154,8 @@ The following flags can be used: * `--authorization-mode=AlwaysDeny` This flag blocks all requests. Use this flag only for testing. * `--authorization-mode=AlwaysAllow` This flag allows all requests. Use this flag only if you do not require authorization for your API requests. -You can choose more than one authorization module. If one of the modes is -`AlwaysAllow`, then it overrides the other modes and all API requests are -allowed. +You can choose more than one authorization module. Modules are checked in order +so an earlier module has higher priority to allow or deny a request. ## Versioning For version 1.2, clusters created by kube-up.sh are configured so that no From 26f123691bd9756d0d8acc0d9e81e8e3beeef944 Mon Sep 17 00:00:00 2001 From: Mike Danese Date: Fri, 8 Dec 2017 09:29:14 -0800 Subject: [PATCH 3/3] address comments --- docs/admin/authorization/index.md | 14 +++----------- 1 file changed, 3 insertions(+), 11 deletions(-) diff --git a/docs/admin/authorization/index.md b/docs/admin/authorization/index.md index 542899b45e1d3..5d778d7b802d9 100644 --- a/docs/admin/authorization/index.md +++ b/docs/admin/authorization/index.md @@ -157,15 +157,6 @@ The following flags can be used: You can choose more than one authorization module. Modules are checked in order so an earlier module has higher priority to allow or deny a request. -## Versioning -For version 1.2, clusters created by kube-up.sh are configured so that no -authorization is required for any request. - -As of version 1.3, clusters created by kube-up.sh are configured so that the -ABAC authorization modules are enabled. However, its input file is initially set -to allow all users to do all operations. The cluster administrator needs to edit -that file, or configure a different authorizer to restrict what users can do. - {% endcapture %} {% capture whatsnext %} * To learn more about Authentication, see **Authentication** in [Controlling Access to the Kubernetes API](/docs/admin/accessing-the-api/). @@ -176,8 +167,9 @@ that file, or configure a different authorizer to restrict what users can do. ## Privilege escalation via pod creation -Users who have ability to create pods in a namespace can potentially escalate -their privileges within that namespace. They can create pods that access +Users who have the ability to create pods in a namespace can potentially +escalate their privileges within that namespace. They can create pods that +access their privileges within that namespace. They can create pods that access secrets the user cannot themselves read, or that run under a service account with different/greater permissions.