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

Clarified scenarios that could lead to privilege escalation (#29378)

Browse Source 
* Clarified scenarios that could lead to privilege escalation

Made it clearer that it's not just creating pods which enables the privilege escalation. It's all workloads, all reconfiguration of workloads, and conceptually the creation and reconfiguration of custom resources which create workloads.

* Allowing link to priv escalation heading if required

* Update content/en/docs/reference/access-authn-authz/authorization.md

Co-authored-by: Tim Bannister <tim@scalefactory.com>

* Adding further clarifications

* Retitled escalation section

* Apply suggestions from vjftw

Co-authored-by: VJ Patel <VJftw@users.noreply.github.com>

* Clarified CRDs and reduced duplication

* Updating caution based on Geoffrey's comments

* Updating controller comment and linking out to reference docs

Co-authored-by: Tim Bannister <tim@scalefactory.com>
Co-authored-by: VJ Patel <VJftw@users.noreply.github.com>
This commit is contained in:
Richard Tweed
2021-09-25 00:02:21 +01:00
committed by GitHub
parent bb55a9e4fa
commit 780dae2785
1 changed files with 22 additions and 11 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/en/docs/reference/access-authn-authz/authorization.md
+22 -11
View File
@@ -192,22 +192,33 @@ 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.
## Privilege escalation via pod creation
## Privilege escalation via workload creation or edits {#privilege-escalation-via-pod-creation}
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.
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.
{{< 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.
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)
{{< /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
- 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.
- 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.
{{< /caution >}}
## {{% heading "whatsnext" %}}