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

Merge pull request #30656 from chenxuc/authn-authz-1

Browse Source 
[zh] sync auth docs
This commit is contained in:
Kubernetes Prow Robot
2021-12-14 17:16:18 -08:00
committed by GitHub
parent e43c5ce2f1 655b153a8a
commit 1154e19be3
5 changed files with 188 additions and 37 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/zh/docs/reference/access-authn-authz/abac.md
+4 -4
View File
@@ -38,7 +38,7 @@ Attribute-based access control (ABAC) defines an access control paradigm whereby
To enable `ABAC` mode, specify `--authorization-policy-file=SOME_FILENAME` and `--authorization-mode=ABAC` on startup.
The file format is [one JSON object per line](http://jsonlines.org/). There
should be no enclosing list or map, just one map per line.
should be no enclosing list or map, only one map per line.
Each line is a "policy object", where each such object is a map with the following
properties:
@@ -73,7 +73,7 @@ properties:
基于 `ABAC` 模式，可以这样指定策略文件 `--authorization-policy-file=SOME_FILENAME`。
此文件格式是 [JSON Lines](https://jsonlines.org/)，不应存在封闭的列表或映射，每行一个映射。
此文件格式是 [JSON Lines](https://jsonlines.org/)，不应存在外层的列表或映射，每行应只有一个映射。
每一行都是一个策略对象，策略对象是具有以下属性的映射：
@@ -258,7 +258,7 @@ Kubectl 使用 api-server 的 `/api` 和 `/apis` 端点来发现服务资源类
```
<!--
[Complete file example](http://releases.k8s.io/{{< param "githubbranch" >}}/pkg/auth/authorizer/abac/example_policy_file.jsonl)
[Complete file example](http://releases.k8s.io/{{< param "fullversion" >}}/pkg/auth/authorizer/abac/example_policy_file.jsonl)
## A quick note on service accounts
@@ -270,7 +270,7 @@ system:serviceaccount:<namespace>:<serviceaccountname>
-->
[完整文件示例](https://releases.k8s.io/{{< param "githubbranch" >}}/pkg/auth/authorizer/abac/example_policy_file.jsonl)
[完整文件示例](https://releases.k8s.io/{{< param "fullversion" >}}/pkg/auth/authorizer/abac/example_policy_file.jsonl)
## 服务帐户的快速说明
content/zh/docs/reference/access-authn-authz/admission-controllers.md
+22
View File
@@ -1171,8 +1171,30 @@ PodNodeSelector 允许 Pod 强制在特定标签的节点上运行。
另请参阅 PodTolerationRestriction 准入插件，该插件可防止 Pod 在特定污点的节点上运行。
{{< /note >}}
### PodSecurity {#podsecurity}
{{< feature-state for_k8s_version="v1.22" state="alpha" >}}
<!--
This is the replacement for the deprecated [PodSecurityPolicy](#podsecuritypolicy) admission controller
defined in the next section. This admission controller acts on creation and modification of the pod and
determines if it should be admitted based on the requested security context and the
[Pod Security Standards](/docs/concepts/security/pod-security-standards/).
See the [Pod Security Admission documentation](/docs/concepts/security/pod-security-admission/)
for more information.
-->
这是下节已被废弃的 [PodSecurityPolicy](#podsecuritypolicy) 准入控制器的替代品。
此准入控制器负责在创建和修改 Pod 时根据请求的安全上下文和
[Pod 安全标准](/zh/docs/concepts/security/pod-security-standards/)
来确定是否可以执行请求。
更多信息请参阅 [Pod 安全性准入控制器](/zh/docs/concepts/security/pod-security-admission/)。
### PodSecurityPolicy {#podsecuritypolicy}
{{< feature-state for_k8s_version="v1.21" state="deprecated" >}}
<!--
This admission controller acts on creation and modification of the pod and determines if it should be admitted
based on the requested security context and the available Pod Security Policies.
content/zh/docs/reference/access-authn-authz/authorization.md
+81 -22
View File
@@ -224,6 +224,10 @@ a given action, and works regardless of the authorization mode used.
```shell
kubectl auth can-i create deployments --namespace dev
```
<!-- The output is similar to this: -->
输出类似于：
```
yes
```
@@ -231,6 +235,10 @@ yes
```shell
kubectl auth can-i create deployments --namespace prod
```
<!-- The output is similar to this: -->
输出类似于：
```
no
```
@@ -246,16 +254,39 @@ 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 Service Account named `dev-sa` in Namespace `dev`
can list Pods in the Namespace `target`:
-->
类似地，检查名字空间 `dev` 里的 `dev-sa` 服务账号是否可以列举名字空间 `target` 里的 Pod：
```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 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.
* `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.
@@ -352,36 +383,64 @@ 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.
-->
## 通过创建 Pod 提升权限
## 通过创建或编辑工作负载提升权限 {#privilege-escalation-via-pod-creation}
能够在名字空间中创建 Pod 的用户可能会提升其在该名字空间内的权限。
他们可以创建在该名字空间内访问其权限的 Pod。
他们可以创建 Pod 访问用户自己无法读取的 Secret，或者在具有不同/更高权限的
服务帐户下运行的 Pod 。
能够在名字空间中创建或者编辑 Pod 的用户，
无论是直接操作还是通过[控制器](/zh/docs/concepts/architecture/controller/)（例如，一个 Operator）来操作，
都可以提升他们在该名字空间内的权限。
{{< 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)
-->
系统管理员在授予对 Pod 创建的访问权限时要小心。
被授予在名字空间中创建 Pod（或创建 Pod 的控制器）的权限的用户可以：
读取名字空间中的所有 Secret；读取名字空间中的所有 ConfigMap；
并模拟名字空间中的任意服务账号并执行账号可以执行的任何操作。
无论采用何种鉴权方式，这都适用。
系统管理员在授予对工作负载的创建或编辑的权限时要小心。
关于这些权限如何被误用的详细信息请参阅
[提升途径](#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.
-->
### 提升途径 {#escalation-paths}
- 挂载该名字空间内的任意 Secret
- 可以用来访问其他工作负载专用的 Secret
- 可以用来获取权限更高的服务账号的令牌
- 使用该名字空间内的任意服务账号
- 可以用另一个工作负载的身份来访问 Kubernetes API（伪装）
- 可以执行该服务账号的任意特权操作
- 挂载该名字空间里其他工作负载专用的 ConfigMap
- 可以用来获取其他工作负载专用的信息，例如数据库主机名。
- 挂载该名字空间里其他工作负载的卷
- 可以用来获取其他工作负载专用的信息，并且更改它。
{{< 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.
-->
系统管理员在部署改变以上部分的 CRD 的时候要小心。
它们可能会打开权限提升的途径。
在决定你的 RBAC 控制时应该考虑这方面的问题。
{{< /caution >}}
## {{% heading "whatsnext" %}}
<!--
content/zh/docs/reference/access-authn-authz/rbac.md
+63 -11
View File
@@ -149,6 +149,7 @@ Because they are cluster-scoped, you can also use them to grant access to:
* cluster-scoped resources (like {{< glossary_tooltip text="nodes" term_id="node" >}})
* non-resource endpoints (like `/healthz`)
* namespaced resources (like Pods), across all namespaces
For example: you can use a ClusterRole to allow a particular user to run
`kubectl get pods -all-namespaces`
-->
@@ -159,8 +160,9 @@ ClusterRole 可以和 Role 相同完成授权。
* 集群范围资源（比如 {{< glossary_tooltip text="节点（Node）" term_id="node" >}}）
* 非资源端点（比如 `/healthz`）
* 跨名字空间访问的名字空间作用域的资源（如 Pods），比如，你可以使用
ClusterRole 来允许某特定用户执行 `kubectl get pods --all-namespaces`
* 跨名字空间访问的名字空间作用域的资源（如 Pods）
比如，你可以使用 ClusterRole 来允许某特定用户执行 `kubectl get pods --all-namespaces`
<!--
Here is an example of a ClusterRole that can be used to grant read access to
@@ -429,11 +431,16 @@ rules:
{{< note >}}
<!--
You cannot restrict `create` or `deletecollection` requests by resourceName. For `create`, this
limitation is because the object name is not known at authorization time.
You cannot restrict `create` or `deletecollection` requests by their resource name.
For `create`, this limitation is because the name of the new object may not be known at authorization time.
If you restrict `list` or `watch` by resourceName, clients must include a `metadata.name` field selector in their `list` or `watch` request that matches the specified resourceName in order to be authorized.
For example, `kubectl get configmaps --field-selector=metadata.name=my-configmap`
-->
你不能针对 `create` 或者 `deletecollection` 请求来实施 resourceName 限制。
对于 `create` 操作而言，这是因为在鉴权时还不知道对象名称。
你不能使用资源名字来限制 `create` 或者 `deletecollection` 请求。
对于 `create` 请求而言，这是因为在鉴权时可能还不知道新对象的名字。
如果你使用 resourceName 来限制 `list` 或者 `watch` 请求，
客户端必须在它们的 `list` 或者 `watch` 请求里包含一个与指定的 resourceName 匹配的 `metadata.name` 字段选择器。
例如，`kubectl get configmaps --field-selector=metadata.name=my-configmap`
{{< /note >}}
<!--
@@ -1051,12 +1058,18 @@ When used in a <b>RoleBinding</b>, it gives full control over every resource in
Allows admin access, intended to be granted within a namespace using a <b>RoleBinding</b>.
If used in a <b>RoleBinding</b>, allows read/write access to most resources in a namespace,
including the ability to create roles and rolebindings within the namespace.
It does not allow write access to resource quota or to the namespace itself.
This role does not allow write access to resource quota or to the namespace itself.
This role also does not allow write access to Endpoints in clusters created
using Kubernetes v1.22+. More information is available in the
["Write Access for Endpoints" section](#write-access-for-endpoints).
-->
允许管理员访问权限，旨在使用 <b>RoleBinding</b> 在名字空间内执行授权。
如果在 <b>RoleBinding</b> 中使用，则可授予对名字空间中的大多数资源的读/写权限，
包括创建角色和角色绑定的能力。
但是它不允许对资源配额或者名字空间本身进行写操作。
此角色不允许对资源配额或者名字空间本身进行写操作。
此角色也不允许对 Kubernetes v1.22+ 创建的 Endpoints 进行写操作。
更多信息参阅[“Endpoints 写权限”小节](#write-access-for-endpoints)。
</td>
</tr>
<tr>
@@ -1071,12 +1084,17 @@ Allows read/write access to most objects in a namespace.
This role does not allow viewing or modifying roles or role bindings.
However, this role allows accessing Secrets and running Pods as any ServiceAccount in
the namespace, so it can be used to gain the API access levels of any ServiceAccount in
the namespace.
the namespace. This role also does not allow write access to Endpoints in
clusters created using Kubernetes v1.22+. More information is available in the
["Write Access for Endpoints" section](#write-access-for-endpoints).
-->
允许对名字空间的大多数对象进行读/写操作。
它不允许查看或者修改角色或者角色绑定。
不过，此角色可以访问 Secret，以名字空间中任何 ServiceAccount 的身份运行 Pods，
所以可以用来了解名字空间内所有服务账户的 API 访问级别。
此角色也不允许对 Kubernetes v1.22+ 创建的 Endpoints 进行写操作。
更多信息参阅[“Endpoints 写操作”小节](#write-access-for-endpoints)。
</td>
</tr>
<tr>
@@ -1327,10 +1345,10 @@ Role for the <a href="https://github.com/kubernetes/node-problem-detector">node-
<td>无</td>
<td>
<!--
Allows access to the resources required by most <a href="/docs/concepts/storage/persistent-volumes/#provisioner">dynamic volume provisioners</a>.
Allows access to the resources required by most <a href="/docs/concepts/storage/persistent-volumes/#dynamic">dynamic volume provisioners</a>.
-->
允许访问大部分
<a href="/docs/concepts/storage/persistent-volumes/#provisioner">动态卷驱动
<a href="/zh/docs/concepts/storage/persistent-volumes/#dynamic">动态卷驱动
</a>
所需要的资源。</td>
</tr>
@@ -1957,6 +1975,40 @@ In order from most secure to least secure, the approaches are:
--group=system:serviceaccounts
```
<!--
## Write access for Endpoints
Kubernetes clusters created before Kubernetes v1.22 include write access to
Endpoints in the aggregated "edit" and "admin" roles. As a mitigation for
[CVE-2021-25740](https://github.com/kubernetes/kubernetes/issues/103675), this
access is not part of the aggregated roles in clusters that you create using
Kubernetes v1.22 or later.
Existing clusters that have been upgraded to Kubernetes v1.22 will not be
subject to this change. The [CVE
announcement](https://github.com/kubernetes/kubernetes/issues/103675) includes
guidance for restricting this access in existing clusters.
If you want new clusters to retain this level of access in the aggregated roles,
you can create the following ClusterRole:
{{< codenew file="access/endpoints-aggregated.yaml" >}}
-->
## Endpoints 写权限 {#write-access-for-endpoints}
在 Kubernetes v1.22 之前版本创建的集群里，
"edit" 和 "admin" 聚合角色包含对 Endpoints 的写权限。
作为 [CVE-2021-25740](https://github.com/kubernetes/kubernetes/issues/103675) 的缓解措施，
此访问权限不包含在 Kubernetes 1.22 以及更高版本集群的聚合角色里。
升级到 Kubernetes v1.22 版本的现有集群不会包括此变化。
[CVE 公告](https://github.com/kubernetes/kubernetes/issues/103675)
包含了在现有集群里限制此访问权限的指引。
如果你希望在新集群的聚合角色里保留此访问权限，你可以创建下面的 ClusterRole：
{{< codenew file="access/endpoints-aggregated.yaml" >}}
<!--
## Upgrading from ABAC
content/zh/examples/access/endpoints-aggregated.yaml
+18
View File
@@ -0,0 +1,18 @@
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
annotations:
kubernetes.io/description: |-
Add endpoints write permissions to the edit and admin roles. This was
removed by default in 1.22 because of CVE-2021-25740. See
https://issue.k8s.io/103675. This can allow writers to direct LoadBalancer
or Ingress implementations to expose backend IPs that would not otherwise
be accessible, and can circumvent network policies or security controls
intended to prevent/isolate access to those backends.
labels:
rbac.authorization.k8s.io/aggregate-to-edit: "true"
name: custom:aggregate-to-edit:endpoints # you can change this if you wish
rules:
- apiGroups: [""]
resources: ["endpoints"]
verbs: ["create", "delete", "deletecollection", "patch", "update"]