Revise authz page
Improve how we explain authz, and remove some existing duplication. Co-Authored-By: Rita Zhang <rita.z.zhang@gmail.com>pull/45195/head
parent
ed0951f7af
commit
f833f4f671
|
@ -41,7 +41,7 @@ evaluated on its merits.
|
|||
- [ ] A process exists for periodic access review, and reviews occur no more
|
||||
than 24 months apart.
|
||||
- [ ] The [Role Based Access Control Good Practices](/docs/concepts/security/rbac-good-practices/)
|
||||
is followed for guidance related to authentication and authorization.
|
||||
are followed for guidance related to authentication and authorization.
|
||||
|
||||
After bootstrapping, neither users nor components should authenticate to the
|
||||
Kubernetes API as `system:masters`. Similarly, running all of
|
||||
|
|
|
@ -7,39 +7,53 @@ reviewers:
|
|||
title: Authorization Overview
|
||||
content_type: concept
|
||||
weight: 30
|
||||
description: >
|
||||
Details of Kubernetes authorization mechanisms and supported authorization modes.
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
Learn more about Kubernetes authorization, including details about creating
|
||||
policies using the supported authorization modules.
|
||||
|
||||
Kubernetes authorization takes place following
|
||||
[authentication](/docs/reference/access-authn-authz/authentication/).
|
||||
Usually, a client making a request must be authenticated (logged in) before its
|
||||
request can be allowed; however, Kubernetes also allows anonymous requests in
|
||||
some circumstances.
|
||||
|
||||
For an overview of how authorization fits into the wider context of API access
|
||||
control, read
|
||||
[Controlling Access to the Kubernetes API](/docs/concepts/security/controlling-access/).
|
||||
|
||||
<!-- body -->
|
||||
In Kubernetes, you must be authenticated (logged in) before your request can be
|
||||
authorized (granted permission to access). For information about authentication,
|
||||
see [Controlling Access to the Kubernetes API](/docs/concepts/security/controlling-access/).
|
||||
|
||||
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.
|
||||
## Authorization verdicts {#determine-whether-a-request-is-allowed-or-denied}
|
||||
|
||||
## 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 authorization of API requests takes place within the API server.
|
||||
The API server evaluates all of the request attributes against all policies,
|
||||
potentially also consulting external services, and then allows or denies the
|
||||
request.
|
||||
|
||||
(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.)
|
||||
All parts of an API request must be allowed by some authorization
|
||||
mechanism in order to proceed. In other words: access is denied by default.
|
||||
|
||||
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.
|
||||
{{% note %}}
|
||||
Access controls and policies that
|
||||
depend on specific fields of specific kinds of objects are handled by
|
||||
{{< glossary_tooltip text="admission controllers" term_id="admission-controller" >}}.
|
||||
|
||||
Kubernetes admission control happens after authorization has completed (and,
|
||||
therefore, only when the authorization decision was to allow the request).
|
||||
{{% /note %}}
|
||||
|
||||
When multiple [authorization modules](#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. An overall deny verdict means that
|
||||
the API server rejects the request and responds with an HTTP 403 (Forbidden)
|
||||
status.
|
||||
|
||||
## Request attributes used in authorization
|
||||
|
||||
## Review Your Request Attributes
|
||||
Kubernetes reviews only the following API request attributes:
|
||||
|
||||
* **user** - The `user` string provided during authentication.
|
||||
|
@ -47,202 +61,149 @@ Kubernetes reviews only the following API request attributes:
|
|||
* **extra** - A map of arbitrary string keys to string values, provided by the authentication layer.
|
||||
* **API** - Indicates whether the request is for an API resource.
|
||||
* **Request path** - Path to miscellaneous non-resource endpoints like `/api` or `/healthz`.
|
||||
* **API request verb** - API verbs like `get`, `list`, `create`, `update`, `patch`, `watch`, `delete`, and `deletecollection` are used for resource requests. To determine the request verb for a resource API endpoint, see [Determine the request verb](/docs/reference/access-authn-authz/authorization/#determine-the-request-verb).
|
||||
* **API request verb** - API verbs like `get`, `list`, `create`, `update`, `patch`, `watch`, `delete`, and `deletecollection` are used for resource requests. To determine the request verb for a resource API endpoint, see [request verbs and authorization](/docs/reference/access-authn-authz/authorization/#determine-the-request-verb).
|
||||
* **HTTP request verb** - Lowercased HTTP methods like `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.
|
||||
* **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 {{< glossary_tooltip text="API Group" term_id="api-group" >}} being accessed (for resource requests only). An empty string designates the _core_ [API group](/docs/reference/using-api/#api-groups).
|
||||
|
||||
## Determine the Request Verb
|
||||
### Request verbs and authorization {#determine-the-request-verb}
|
||||
|
||||
#### Non-resource requests {#request-verb-non-resource}
|
||||
|
||||
**Non-resource requests**
|
||||
Requests to endpoints other than `/api/v1/...` or `/apis/<group>/<version>/...`
|
||||
are considered "non-resource requests", and use the lower-cased HTTP method of the request as the verb.
|
||||
For example, a `GET` request to endpoints like `/api` or `/healthz` would use `get` as the verb.
|
||||
are considered _non-resource requests_, and use the lower-cased HTTP method of the request as the verb.
|
||||
For example, making a `GET` request using HTTP to endpoints such as `/api` or `/healthz` would use **get** as the verb.
|
||||
|
||||
**Resource requests**
|
||||
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
|
||||
#### Resource requests {#request-verb-resource}
|
||||
|
||||
To determine the request verb for a resource API endpoint, Kubernetes maps the HTTP verb
|
||||
used and considers whether or not the request acts on an individual resource or on a
|
||||
collection of resources:
|
||||
|
||||
HTTP verb | request verb
|
||||
----------|---------------
|
||||
POST | create
|
||||
GET, HEAD | get (for individual resources), list (for collections, including full object content), watch (for watching an individual resource or collection of resources)
|
||||
PUT | update
|
||||
PATCH | patch
|
||||
DELETE | delete (for individual resources), deletecollection (for collections)
|
||||
HTTP verb | request verb
|
||||
--------------|---------------
|
||||
`POST` | **create**
|
||||
`GET`, `HEAD` | **get** (for individual resources), **list** (for collections, including full object content), **watch** (for watching an individual resource or collection of resources)
|
||||
`PUT` | **update**
|
||||
`PATCH` | **patch**
|
||||
`DELETE` | **delete** (for individual resources), **deletecollection** (for collections)
|
||||
|
||||
{{< caution >}}
|
||||
The `get`, `list` and `watch` verbs can all return the full details of a resource. In terms of the returned data they are equivalent. For example, `list` on `secrets` will still reveal the `data` attributes of any returned resources.
|
||||
+The **get**, **list** and **watch** verbs can all return the full details of a resource. In
|
||||
terms of access to the returned data they are equivalent. For example, **list** on `secrets`
|
||||
will reveal the **data** attributes of any returned resources.
|
||||
{{< /caution >}}
|
||||
|
||||
Kubernetes sometimes checks authorization for additional permissions using specialized verbs. For example:
|
||||
|
||||
* Special cases of [authentication](/docs/reference/access-authn-authz/authentication/)
|
||||
* **impersonate** verb on `users`, `groups`, and `serviceaccounts` in the core API group, and the `userextras` in the `authentication.k8s.io` API group.
|
||||
* [Authorization of CertificateSigningRequests](/docs/reference/access-authn-authz/certificate-signing-requests/#authorization)
|
||||
* **approve** verb for CertificateSigningRequests, and **update** for revisions to existing approvals
|
||||
* [RBAC](/docs/reference/access-authn-authz/rbac/#privilege-escalation-prevention-and-bootstrapping)
|
||||
* `bind` and `escalate` verbs on `roles` and `clusterroles` resources in the `rbac.authorization.k8s.io` API group.
|
||||
* [Authentication](/docs/reference/access-authn-authz/authentication/)
|
||||
* `impersonate` verb on `users`, `groups`, and `serviceaccounts` in the core API group, and the `userextras` in the `authentication.k8s.io` API group.
|
||||
* **bind** and **escalate** verbs on `roles` and `clusterroles` resources in the `rbac.authorization.k8s.io` API group.
|
||||
|
||||
## Authorization Modes {#authorization-modules}
|
||||
## Authorization context
|
||||
|
||||
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.
|
||||
|
||||
## Authorization modes {#authorization-modules}
|
||||
|
||||
The Kubernetes API server may authorize a request using one of several authorization modes:
|
||||
|
||||
* **Node** - A special-purpose authorization mode that grants permissions to kubelets based on the pods they are scheduled to run. To learn more about using the Node authorization mode, see [Node Authorization](/docs/reference/access-authn-authz/node/).
|
||||
* **ABAC** - Attribute-based access control (ABAC) defines an access control paradigm whereby access rights are granted to users through the use of policies which combine attributes together. The policies can use any type of attributes (user attributes, resource attributes, object, environment attributes, etc). To learn more about using the ABAC mode, see [ABAC Mode](/docs/reference/access-authn-authz/abac/).
|
||||
* **RBAC** - Role-based access control (RBAC) is a method of regulating access to computer or network resources based on the roles of individual users within an enterprise. In this context, access is the ability of an individual user to perform a specific task, such as view, create, or modify a file. To learn more about using the RBAC mode, see [RBAC Mode](/docs/reference/access-authn-authz/rbac/)
|
||||
* When specified RBAC (Role-Based Access Control) uses the `rbac.authorization.k8s.io` API group to drive authorization decisions, allowing admins to dynamically configure permission policies through the Kubernetes API.
|
||||
* To enable RBAC, start the apiserver with `--authorization-mode=RBAC`.
|
||||
* **Webhook** - A WebHook is an HTTP callback: an HTTP POST that occurs when something happens; a simple event-notification via HTTP POST. A web application implementing WebHooks will POST a message to a URL when certain things happen. To learn more about using the Webhook mode, see [Webhook Mode](/docs/reference/access-authn-authz/webhook/).
|
||||
* **AlwaysAllow** - This mode allows all requests. Use this authorization mode only if you do not require authorization for your API requests (for example, for testing).
|
||||
* **AlwaysDeny** - This mode blocks all requests. Use this authorization mode only for testing.
|
||||
* **ABAC** - [Attribute-Based Access Control](/docs/reference/access-authn-authz/abac/) (ABAC) mode defines an access control paradigm whereby access rights are granted to users through the use of policies which combine attributes together. The policies can use any type of attributes (user attributes, resource attributes, object, environment attributes, etc).
|
||||
* **RBAC** - [Role-based access control](/docs/reference/access-authn-authz/rbac/) (RBAC) is a method of regulating access to computer or network resources based on the roles of individual users within an enterprise. In this context, access is the ability of an individual user to perform a specific task, such as view, create, or modify a file.
|
||||
* Kubernetes RBAC uses the `rbac.authorization.k8s.io` API group to drive authorization decisions, allowing you to dynamically configure permission policies through the Kubernetes API.
|
||||
* **Node** - A special-purpose authorization mode that grants permissions to kubelets based on the pods they are scheduled to run. To learn more about the Node authorization mode, see [Node Authorization](/docs/reference/access-authn-authz/node/).
|
||||
* **Webhook** - Kubernetes [webhook mode](/docs/reference/access-authn-authz/webhook/) for authorization makes a synchronous HTTP callout, blocking the request until the remote HTTP service responds to the query.
|
||||
|
||||
#### Checking API Access
|
||||
{{< warning >}}
|
||||
Enabling the `AlwaysAllow` mode bypasses authorization; do not use this on a cluster where
|
||||
you do not trust **all** potential API clients, including the workloads that you run.
|
||||
|
||||
`kubectl` provides the `auth can-i` subcommand for quickly querying the API authorization layer.
|
||||
The command uses the `SelfSubjectAccessReview` API to determine if the current user can perform
|
||||
a given action, and works regardless of the authorization mode used.
|
||||
Authorization mechanisms typically return either a _deny_ or _no opinion_ result; see
|
||||
[authorization verdicts](#determine-whether-a-request-is-allowed-or-denied) for more on this.
|
||||
Activating the `AlwaysAllow` means that if all other authorizers return “no opinion”,
|
||||
the request is allowed. For example, `--authorization-mode=AlwaysAllow,RBAC` has the
|
||||
same effect as `--authorization-mode=AlwaysAllow` because Kubernetes RBAC does not
|
||||
provide negative (deny) access rules.
|
||||
|
||||
You should not use the `AlwaysAllow` mode on a Kubernetes cluster where the API server
|
||||
is reachable from the public internet.
|
||||
{{< /warning >}}
|
||||
|
||||
```bash
|
||||
kubectl auth can-i create deployments --namespace dev
|
||||
```
|
||||
### Authorization mode configuration {#choice-of-authz-config}
|
||||
|
||||
The output is similar to this:
|
||||
You can configure the Kubernetes API server's authorizer chain using either
|
||||
[command line arguments](#using-flags-for-your-authorization-module) only or, as a beta feature,
|
||||
using a [configuration file](#using-configuration-file-for-authorization).
|
||||
|
||||
```
|
||||
yes
|
||||
```
|
||||
You have to pick one of the two configuration approaches; setting both `--authorization-config`
|
||||
path and configuring an authorization webhook using the `--authorization-mode` and
|
||||
`--authorization-webhook-*` command line arguments is not allowed.
|
||||
If you try this, the API server reports an error message during startup, then exits immediately.
|
||||
|
||||
```shell
|
||||
kubectl auth can-i create deployments --namespace prod
|
||||
```
|
||||
### Command line authorization mode configuration {#using-flags-for-your-authorization-module}
|
||||
|
||||
The output is similar to this:
|
||||
{{< feature-state state="stable" for_k8s_version="v1.8" >}}
|
||||
|
||||
```
|
||||
no
|
||||
```
|
||||
You can use the following modes:
|
||||
|
||||
Administrators can combine this with [user impersonation](/docs/reference/access-authn-authz/authentication/#user-impersonation)
|
||||
to determine what action other users can perform.
|
||||
* `--authorization-mode=ABAC` (Attribute-based access control mode)
|
||||
* `--authorization-mode=RBAC` (Role-based access control mode)
|
||||
* `--authorization-mode=Webhook` (Webhook authorization mode)
|
||||
* `--authorization-mode=Node` (Node authorizer)
|
||||
* `--authorization-mode=AlwaysDeny` (always denies requests)
|
||||
* `--authorization-mode=AlwaysAllow` (always allows requests; carries security risks)
|
||||
|
||||
```bash
|
||||
kubectl auth can-i list secrets --namespace dev --as dave
|
||||
```
|
||||
You can choose more than one authorization mode; for example:
|
||||
`--authorization-mode=Node,Webhook`
|
||||
|
||||
The output is similar to this:
|
||||
Kubernetes checks authorization modules based on the order that you specify them
|
||||
on the API server's command line, so an earlier module has higher priority to allow
|
||||
or deny a request.
|
||||
|
||||
```
|
||||
no
|
||||
```
|
||||
You cannot combine the `--authorization-mode` command line argument with the
|
||||
`--authorization-config` command line argument used for
|
||||
[configuring authorization using a local file](#using-configuration-file-for-authorization-mode).
|
||||
|
||||
Similarly, to check whether a ServiceAccount named `dev-sa` in Namespace `dev`
|
||||
can list Pods in the Namespace `target`:
|
||||
For more information on command line arguments to the API server, read the
|
||||
[`kube-apiserver` reference](/docs/reference/command-line-tools-reference/kube-apiserver/).
|
||||
|
||||
```bash
|
||||
kubectl auth can-i list pods \
|
||||
--namespace target \
|
||||
--as system:serviceaccount:dev:dev-sa
|
||||
```
|
||||
<!-- keep legacy hyperlinks working -->
|
||||
<a id="configuring-the-api-server-using-an-authorization-config-file" />
|
||||
|
||||
The output is similar to this:
|
||||
|
||||
```
|
||||
yes
|
||||
```
|
||||
|
||||
`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 only 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.
|
||||
* `SelfSubjectRulesReview` - A review which returns the set of actions a user can perform within a namespace. Useful for users to quickly summarize their own access, or for UIs to hide/show actions.
|
||||
|
||||
These APIs can be queried by creating normal Kubernetes resources, where the response "status"
|
||||
field of the returned object is the result of the query.
|
||||
|
||||
```bash
|
||||
kubectl create -f - -o yaml << EOF
|
||||
apiVersion: authorization.k8s.io/v1
|
||||
kind: SelfSubjectAccessReview
|
||||
spec:
|
||||
resourceAttributes:
|
||||
group: apps
|
||||
resource: deployments
|
||||
verb: create
|
||||
namespace: dev
|
||||
EOF
|
||||
```
|
||||
|
||||
The generated `SelfSubjectAccessReview` is:
|
||||
```yaml
|
||||
apiVersion: authorization.k8s.io/v1
|
||||
kind: SelfSubjectAccessReview
|
||||
metadata:
|
||||
creationTimestamp: null
|
||||
spec:
|
||||
resourceAttributes:
|
||||
group: apps
|
||||
resource: deployments
|
||||
namespace: dev
|
||||
verb: create
|
||||
status:
|
||||
allowed: true
|
||||
denied: false
|
||||
```
|
||||
|
||||
## Using Flags for Your Authorization Module
|
||||
|
||||
You must include a flag in your policy to indicate which authorization module
|
||||
your policies include:
|
||||
|
||||
The following flags can be used:
|
||||
|
||||
* `--authorization-mode=ABAC` Attribute-Based Access Control (ABAC) mode allows you to configure policies using local files.
|
||||
* `--authorization-mode=RBAC` Role-based access control (RBAC) mode allows you to create and store policies using the Kubernetes API.
|
||||
* `--authorization-mode=Webhook` WebHook is an HTTP callback mode that allows you to manage authorization using a remote REST endpoint.
|
||||
* `--authorization-mode=Node` Node authorization is a special-purpose authorization mode that specifically authorizes API requests made by kubelets.
|
||||
* `--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. Modules are checked in order
|
||||
so an earlier module has higher priority to allow or deny a request.
|
||||
|
||||
## Configuring the API Server using an Authorization Config File
|
||||
### Configuring the API Server using an authorization config file {#using-configuration-file-for-authorization}
|
||||
|
||||
{{< feature-state feature_gate_name="StructuredAuthorizationConfiguration" >}}
|
||||
|
||||
The Kubernetes API server's authorizer chain can be configured using a
|
||||
configuration file.
|
||||
As a beta feature, Kubernetes lets you configure authorization chains that can include multiple
|
||||
webhooks. The authorization items in that chain can have well-defined parameters that validate
|
||||
requests in a particular order, offering you fine-grained control, such as explicit Deny on failures.
|
||||
|
||||
This feature enables the creation of authorization chains with multiple webhooks with well-defined parameters that validate requests in a particular order and allows fine-grained control – such as explicit Deny on failures. The configuration file approach even allows you to specify [CEL](/docs/reference/using-api/cel/) rules to pre-filter requests before they are dispatched to webhooks, helping you to prevent unnecessary invocations. The API server also automatically reloads the authorizer chain when the configuration file is modified. An example configuration with all possible values is provided below.
|
||||
The configuration file approach even allows you to specify
|
||||
[CEL](/docs/reference/using-api/cel/) rules to pre-filter requests before they are dispatched
|
||||
to webhooks, helping you to prevent unnecessary invocations. The API server also automatically
|
||||
reloads the authorizer chain when the configuration file is modified.
|
||||
|
||||
You must specify the path to the authorization configuration using the `--authorization-config`command line argument. If you want to keep using command line flags instead of a configuration file, those will continue to work as-is. To gain access to new authorization webhook capabilities like multiple webhooks, failure policy, and pre-filter rules, switch to putting options in an `--authorization-config` file.
|
||||
You specify the path to the authorization configuration using the
|
||||
`--authorization-config` command line argument.
|
||||
|
||||
Starting Kubernetes v{{< skew currentVersion >}}, the configuration file format is
|
||||
beta-level, and only requires specifying `--authorization-config` since the `StructuredAuthorizationConfiguration` feature gate is enabled by default.
|
||||
If you want to use command line arguments instead of a configuration file, that's also a valid and supported approach.
|
||||
Some authorization capabilities (for example: multiple webhooks, webhook failure policy, and pre-filter rules)
|
||||
are only available if you use an authorization configuration file.
|
||||
|
||||
{{< caution >}}
|
||||
If you want to keep using command line flags to configure authorization instead of a configuration file, those will continue to work as-is.
|
||||
#### Example configuration {#authz-config-example}
|
||||
|
||||
When the feature is enabled, setting both `--authorization-config` and
|
||||
configuring an authorization webhook using the `--authorization-mode` and
|
||||
`--authorization-webhook-*` command line flags is not allowed. If done, there
|
||||
will be an error and API Server would exit right away.
|
||||
|
||||
Authorization Config file reloads when an observed file event occurs or a 1 minute poll is encountered. All non-webhook authorizer types are required to remain unchanged in the file on reload. Reload must not add or remove Node or RBAC
|
||||
authorizers. They can be reordered, but cannot be added or removed.
|
||||
|
||||
When configuring the authorizer chain using a config file, make sure all the
|
||||
apiserver nodes have the file. Take a note of the apiserver configuration
|
||||
when upgrading/downgrading the clusters. For example, if upgrading to v1.29+
|
||||
clusters and using the config file, you would need to make sure the config file
|
||||
exists before upgrading the cluster. When downgrading to v1.28, you would need
|
||||
to add the flags back to their bootstrap mechanism.
|
||||
{{< /caution >}}
|
||||
|
||||
```yaml
|
||||
{{< highlight yaml "linenos=false,hl_lines=2-4" >}}
|
||||
---
|
||||
#
|
||||
# DO NOT USE THE CONFIG AS IS. THIS IS AN EXAMPLE.
|
||||
#
|
||||
|
@ -341,37 +302,167 @@ authorizers:
|
|||
failurePolicy: NoOpinion
|
||||
connectionInfo:
|
||||
type: InClusterConfig
|
||||
```
|
||||
{{< /highlight >}}
|
||||
|
||||
When configuring the authorizer chain using a configuration file, make sure all the
|
||||
control plane nodes have the same file contents. Take a note of the API server
|
||||
configuration when upgrading / downgrading your clusters. For example, if upgrading
|
||||
from Kubernetes {{< skew currentVersionAddMinor -1 >}} to Kubernetes {{< skew currentVersion >}},
|
||||
you would need to make sure the config file is in a format that Kubernetes {{< skew currentVersion >}}
|
||||
can understand, before you upgrade the cluster. If you downgrade to {{< skew currentVersionAddMinor -1 >}},
|
||||
you would need to set the configuration appropriately.
|
||||
|
||||
#### Authorization configuration and reloads
|
||||
|
||||
Kubernetes reloads the authorization configuration file when the API server observes a change
|
||||
to the file, and also on a 60 second schedule if no change events were observed.
|
||||
|
||||
{{< note >}}
|
||||
You must ensure that all non-webhook authorizer types remain unchanged in the file on reload.
|
||||
|
||||
A reload **must not** add or remove Node or RBAC authorizers (they can be reordered,
|
||||
but cannot be added or removed).
|
||||
{{< /note >}}
|
||||
|
||||
## Privilege escalation via workload creation or edits {#privilege-escalation-via-pod-creation}
|
||||
|
||||
Users who can create/edit pods in a namespace, either directly or through a [controller](/docs/concepts/architecture/controller/)
|
||||
such as an operator, could escalate their privileges in that namespace.
|
||||
Users who can create/edit pods in a namespace, either directly or through an object that
|
||||
enables indirect [workload management](/docs/concepts/architecture/controller/), may be
|
||||
able to escalate their privileges in that namespace. The potential routes to privilege
|
||||
escalation include Kubernetes [API extensions](/docs/concepts/extend-kubernetes/#api-extensions)
|
||||
and their associated {{< glossary_tooltip term_id="controller" text="controllers" >}}.
|
||||
|
||||
{{< caution >}}
|
||||
System administrators, use care when granting access to create or edit workloads.
|
||||
Details of how these can be misused are documented in [escalation paths](/docs/reference/access-authn-authz/authorization/#escalation-paths)
|
||||
As a cluster administrator, use caution when granting access to create or edit workloads.
|
||||
Some details of how these can be misused are documented in
|
||||
[escalation paths](/docs/reference/access-authn-authz/authorization/#escalation-paths).
|
||||
{{< /caution >}}
|
||||
|
||||
### Escalation paths {#escalation-paths}
|
||||
- Mounting arbitrary secrets in that namespace
|
||||
- Can be used to access secrets meant for other workloads
|
||||
- Can be used to obtain a more privileged service account's service account token
|
||||
- Using arbitrary Service Accounts in that namespace
|
||||
|
||||
There are different ways that an attacker or untrustworthy user could gain additional
|
||||
privilege within a namespace, if you allow them to run arbitrary Pods in that namespace:
|
||||
|
||||
- Mounting arbitrary Secrets in that namespace
|
||||
- Can be used to access confidential information meant for other workloads
|
||||
- Can be used to obtain a more privileged ServiceAccount's service account token
|
||||
- Using arbitrary ServiceAccounts in that namespace
|
||||
- Can perform Kubernetes API actions as another workload (impersonation)
|
||||
- Can perform any privileged actions that Service Account has
|
||||
- Mounting configmaps meant for other workloads in that namespace
|
||||
- Can be used to obtain information meant for other workloads, such as DB host names.
|
||||
- Can perform any privileged actions that ServiceAccount has
|
||||
- Mounting or using ConfigMaps meant for other workloads in that namespace
|
||||
- Can be used to obtain information meant for other workloads, such as database host names.
|
||||
- Mounting volumes meant for other workloads in that namespace
|
||||
- Can be used to obtain information meant for other workloads, and change it.
|
||||
|
||||
{{< caution >}}
|
||||
System administrators should be cautious when deploying CRDs that
|
||||
change the above areas. These may open privilege escalations paths.
|
||||
This should be considered when deciding on your RBAC controls.
|
||||
As a system administrator, you should be cautious when deploying CustomResourceDefinitions
|
||||
that let users make changes to the above areas. These may open privilege escalations paths.
|
||||
Consider the consequences of this kind of change when deciding on your authorization controls.
|
||||
{{< /caution >}}
|
||||
|
||||
## Checking API access
|
||||
|
||||
`kubectl` provides the `auth can-i` subcommand for quickly querying the API authorization layer.
|
||||
The command uses the `SelfSubjectAccessReview` API to determine if the current user can perform
|
||||
a given action, and works regardless of the authorization mode used.
|
||||
|
||||
|
||||
```bash
|
||||
kubectl auth can-i create deployments --namespace dev
|
||||
```
|
||||
|
||||
The output is similar to this:
|
||||
|
||||
```
|
||||
yes
|
||||
```
|
||||
|
||||
```shell
|
||||
kubectl auth can-i create deployments --namespace prod
|
||||
```
|
||||
|
||||
The output is similar to this:
|
||||
|
||||
```
|
||||
no
|
||||
```
|
||||
|
||||
Administrators can combine this with [user impersonation](/docs/reference/access-authn-authz/authentication/#user-impersonation)
|
||||
to determine what action other users can perform.
|
||||
|
||||
```bash
|
||||
kubectl auth can-i list secrets --namespace dev --as dave
|
||||
```
|
||||
|
||||
The output is similar to this:
|
||||
|
||||
```
|
||||
no
|
||||
```
|
||||
|
||||
Similarly, to check whether a ServiceAccount named `dev-sa` in Namespace `dev`
|
||||
can list Pods in the Namespace `target`:
|
||||
|
||||
```bash
|
||||
kubectl auth can-i list pods \
|
||||
--namespace target \
|
||||
--as system:serviceaccount:dev:dev-sa
|
||||
```
|
||||
|
||||
The output is similar to this:
|
||||
|
||||
```
|
||||
yes
|
||||
```
|
||||
|
||||
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 only 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.
|
||||
SelfSubjectRulesReview
|
||||
: A review which returns the set of actions a user can perform within a namespace. Useful for users to quickly summarize their own access, or for UIs to hide/show actions.
|
||||
|
||||
These APIs can be queried by creating normal Kubernetes resources, where the response `status`
|
||||
field of the returned object is the result of the query. For example:
|
||||
|
||||
```bash
|
||||
kubectl create -f - -o yaml << EOF
|
||||
apiVersion: authorization.k8s.io/v1
|
||||
kind: SelfSubjectAccessReview
|
||||
spec:
|
||||
resourceAttributes:
|
||||
group: apps
|
||||
resource: deployments
|
||||
verb: create
|
||||
namespace: dev
|
||||
EOF
|
||||
```
|
||||
|
||||
The generated SelfSubjectAccessReview is similar to:
|
||||
|
||||
{{< highlight yaml "linenos=false,hl_lines=11-13" >}}
|
||||
apiVersion: authorization.k8s.io/v1
|
||||
kind: SelfSubjectAccessReview
|
||||
metadata:
|
||||
creationTimestamp: null
|
||||
spec:
|
||||
resourceAttributes:
|
||||
group: apps
|
||||
resource: deployments
|
||||
namespace: dev
|
||||
verb: create
|
||||
status:
|
||||
allowed: true
|
||||
denied: false
|
||||
{{< /highlight >}}
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
* To learn more about Authentication, see **Authentication** in [Controlling Access to the Kubernetes API](/docs/concepts/security/controlling-access/).
|
||||
* To learn more about Authentication, see [Authentication](/docs/reference/access-authn-authz/authentication/).
|
||||
* For an overview, read [Controlling Access to the Kubernetes API](/docs/concepts/security/controlling-access/).
|
||||
* To learn more about Admission Control, see [Using Admission Controllers](/docs/reference/access-authn-authz/admission-controllers/).
|
||||
* Read more about [Common Expression Language in Kubernetes](/docs/reference/using-api/cel/).
|
||||
|
|
Loading…
Reference in New Issue