Convert site to Hugo (#8316)
This commit converts content and layout to use Hugo.
This commit is contained in:
Bjørn Erik Pedersen
committed by
k8s-ci-robot
k8s-ci-robot
parent
7745f0e0c5
commit
7f3b633aa0
@@ -0,0 +1,156 @@
|
||||
---
|
||||
approvers:
|
||||
- erictune
|
||||
- lavalamp
|
||||
- deads2k
|
||||
- liggitt
|
||||
title: 概述
|
||||
content_template: templates/concept
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
学习有关 Kubernetes 授权的更多信息，包括有关使用支持的授权模块创建策略的详细信息。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
在 Kubernetes 里，您必须经过身份验证(登录)，才能授权您的请求(授予访问权限).。有关认证的信息，请参阅[访问控制概述](/docs/admin/access-the-api/)。
|
||||
|
||||
Kubernetes 提供通用的 REST API 请求。这意味着 Kubernetes 授权可以与现有的组织或云提供商的访问控制系统一起使用，该系统可以处理除 Kubernetes API 之外的其他 API。
|
||||
|
||||
## 确定请求是允许还是被拒绝
|
||||
Kubernetes 使用 API 服务器授权 API 请求。它根据所有策略评估所有请求属性，并允许或拒绝请求。某些策略必须允许 API 请求的所有部分继续进行，这意味着默认情况下是拒绝权限。
|
||||
|
||||
(虽然 Kubernetes 使用 API 服务器，访问控制和依赖特定类型对象的特定领域策略由 Admission 控制器处理。)
|
||||
|
||||
当配置多个授权模块时，按顺序检查每个模块，如果有任何模块授权请求，则可以继续执行该请求。如果所有模块拒绝请求，则拒绝该请求(HTTP状态代码403)。
|
||||
|
||||
## 查看您的请求属性
|
||||
|
||||
Kubernetes 仅查看以下API请求属性:
|
||||
|
||||
* **user** - 验证期间提供的 `user` 字符串
|
||||
* **group** - 认证用户所属的组名列表
|
||||
* **“extra"** - 由认证层提供的任意字符串键到字符串值的映射
|
||||
* **API** - 指示请求是否用于API资源
|
||||
* **Request path** - 诸如`/api`或`/healthz`的其他非资源端点的路径(请参阅[kubectl](#kubectl)).
|
||||
* **API request verb** - API 动词 `get`，`list`，`create`，`update`，`patch`，`watch`，`proxy`，`redirect`，`delete`和`deletecollection`用于资源请求。要确定资源 API 端点的请求动词，请参阅**确定下面的请求动词**.
|
||||
* **HTTP request verb** - HTTP动词`get`，`post`，`put`和`delete`用于非资源请求
|
||||
* **Resource** - 正在访问的资源的ID或名称(仅适用于资源请求)
|
||||
--* 对于使用`get`, `update`, `patch`, 和 `delete`动词的资源请求，您必须提供资源名称。
|
||||
* **Subresource** - 正在访问的子资源(仅用于资源请求)
|
||||
* **Namespace** - 正在被访问的对象的命名空间(仅针对命名空间的资源请求)
|
||||
* **API group** - 正在访问的API组(仅用于资源请求). 一个空字符串指定[核心 API 组](/docs/api/).
|
||||
|
||||
## 确定请求动词
|
||||
|
||||
要确定资源 API 端点的请求动词，请查看所使用的HTTP动词以及请求是否对单个资源或资源集合进行操作:
|
||||
|
||||
HTTP动词| 请求动词
|
||||
---------- | ---------------
|
||||
POST | 创建
|
||||
GET，HEAD | 获取(个人资源)，列表(集合)
|
||||
PUT | 更新
|
||||
PATCH | 补丁
|
||||
DELETE| 删除(个人资源)，删除(收藏)
|
||||
|
||||
Kubernetes 有时会使用专门的动词检查授权以获得额外的权限。例如:
|
||||
|
||||
* [PodSecurityPolicy](/docs/concepts/policy/pod-security-policy/)在`extensions` API组中的`podsecuritypolicies`资源上检查`use`动词的授权。
|
||||
* [RBAC](/docs/admin/authorization/rbac/#privilege-escalation-prevention-and-bootstrapping) 在`rbac.authorization.k8s.io` API组中的`roles`和`clusterroles`资源上检查`bind`动词的授权。
|
||||
* [认证](/docs/admin/authentication/) 在核心API组中的`users`，`groups`和`serviceaccounts`上的`impersonate`动词的授权以及`authentication.k8s.io` API组中的`userextras`进行层次检查。
|
||||
|
||||
## 授权模块
|
||||
* **ABAC模式** - 基于属性的访问控制(ABAC)定义了访问控制范例，通过使用将属性组合在一起的策略来授予用户访问权限。策略可以使用任何类型的属性(用户属性，资源属性，对象，环境属性等)。要了解有关使用ABAC模式的更多信息，请参阅[ABAC模式](/docs/admin/authorization/abac/)
|
||||
* **RBAC模式** - 基于角色的访问控制(RBAC)是一种根据企业内个人用户的角色来调整对计算机或网络资源的访问的方法。在这种情况下，访问是单个用户执行特定任务(例如查看，创建或修改文件)的能力。要了解有关使用RBAC模式的更多信息，请参阅[RBAC模式](/docs/admin/authorization/rbac/)
|
||||
*当指定 "RBAC"(基于角色的访问控制)使用 "rbac.authorization.k8s.io" API组来驱动授权决定时，允许管理员通过Kubernetes API动态配置权限策略.
|
||||
.. *截至1.6 RBAC模式是测试版.
|
||||
.. *要启用RBAC，请使用 `--authorization-mode=RBAC` 启动 apiserver.
|
||||
* **Webhook模式** - WebHook 是HTTP回调:发生事件时发生的HTTP POST; 通过HTTP POST简单的事件通知. 实施 WebHooks 的 Web 应用程序将在某些事情发生时向URL发送消息. 要了解有关使用Webhook模式的更多信息，请参阅[Webhook模式](/docs/admin/authorization/webhook/)
|
||||
* **自定义模块** - 您可以创建使用Kubernetes的自定义模块. 要了解更多信息，请参阅下面的**自定义模块**。
|
||||
|
||||
### 自定义模块
|
||||
可以相当容易地开发其他实现,APIserver 调用 Authorizer 接口：
|
||||
|
||||
```go
|
||||
type Authorizer interface {
|
||||
Authorize(a Attributes) error
|
||||
}
|
||||
```
|
||||
|
||||
以确定是否允许每个API操作.
|
||||
|
||||
授权插件是实现此接口的模块.授权插件代码位于 `pkg/auth/authorizer/$MODULENAME` 中。
|
||||
|
||||
授权模块可以完全实现，也可以拨出远程授权服务。 授权模块可以实现自己的缓存，以减少具有相同或相似参数的重复授权调用的成本。 开发人员应该考虑缓存和撤销权限之间的交互。
|
||||
|
||||
#### 检查API访问
|
||||
|
||||
Kubernetes 将 `subjectaccessreviews.v1.authorization.k8s.io` 资源公开为允许外部访问API授权者决策的普通资源。 无论您选择使用哪个授权器，您都可以使用`SubjectAccessReview`发出一个`POST`，就像webhook授权器的`apis/authorization.k8s.io/v1/subjectaccessreviews` 端点一样，并回复一个响应。 例如：
|
||||
|
||||
|
||||
```bash
|
||||
kubectl create --v=8 -f - << __EOF__
|
||||
{
|
||||
"apiVersion": "authorization.k8s.io/v1",
|
||||
"kind": "SubjectAccessReview",
|
||||
"spec": {
|
||||
"resourceAttributes": {
|
||||
"namespace": "kittensandponies",
|
||||
"verb": "get",
|
||||
"group": "unicorn.example.org",
|
||||
"resource": "pods"
|
||||
},
|
||||
"user": "jane",
|
||||
"group": [
|
||||
"group1",
|
||||
"group2"
|
||||
],
|
||||
"extra": {
|
||||
"scopes": [
|
||||
"openid",
|
||||
"profile"
|
||||
]
|
||||
}
|
||||
}
|
||||
}
|
||||
__EOF__
|
||||
|
||||
--- snip lots of output ---
|
||||
|
||||
I0913 08:12:31.362873 27425 request.go:908] Response Body: {"kind":"SubjectAccessReview","apiVersion":"authorization.k8s.io/v1","metadata":{"creationTimestamp":null},"spec":{"resourceAttributes":{"namespace":"kittensandponies","verb":"GET","group":"unicorn.example.org","resource":"pods"},"user":"jane","group":["group1","group2"],"extra":{"scopes":["openid","profile"]}},"status":{"allowed":true}}
|
||||
subjectaccessreview "" created
|
||||
```
|
||||
|
||||
这对于调试访问问题非常有用，因为您可以使用此资源来确定授权者授予哪些访问权限。
|
||||
|
||||
## 为您的授权模块使用标志
|
||||
|
||||
您的策略中必须包含一个标志，以指出您的策略包含哪个授权模块:
|
||||
|
||||
可以使用以下标志:
|
||||
- `--authorization-mode=ABAC` 基于属性的访问控制(ABAC)模式允许您使用本地文件配置策略。
|
||||
- `--authorization-mode=RBAC` 基于角色的访问控制(RBAC)模式允许您使用Kubernetes API创建和存储策略.
|
||||
- `--authorization-mode=Webhook` WebHook是一种HTTP回调模式，允许您使用远程REST管理授权。
|
||||
- `--authorization-mode=AlwaysDeny` 此标志阻止所有请求. 仅使用此标志进行测试。
|
||||
- `--authorization-mode=AlwaysAllow` 此标志允许所有请求. 只有在您不需要API请求授权的情况下才能使用此标志。
|
||||
|
||||
您可以选择多个授权模块. 如果其中一种模式为 `AlwaysAllow`，则覆盖其他模式，并允许所有API请求。
|
||||
|
||||
## 版本控制
|
||||
|
||||
对于版本 1.2，配置了 kube-up.sh 创建的集群，以便任何请求都不需要授权。
|
||||
|
||||
从版本 1.3 开始，配置由 kube-up.sh 创建的集群，使得 ABAC 授权模块处于启用状态。但是，其输入文件最初设置为允许所有用户执行所有操作，集群管理员需要编辑该文件，或者配置不同的授权器来限制用户可以执行的操作。
|
||||
|
||||
{{% /capture %}}
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
* 要学习有关身份验证的更多信息，请参阅**身份验证**[控制访问 Kubernetes API](docs/admin/access-the-api/)。
|
||||
* 要了解有关入学管理的更多信息，请参阅[使用 Admission 控制器](docs/admin/admission-controllers/)。
|
||||
*
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
@@ -0,0 +1,142 @@
|
||||
---
|
||||
approvers:
|
||||
- erictune
|
||||
- lavalamp
|
||||
- deads2k
|
||||
- liggitt
|
||||
title: ABAC 模式
|
||||
content_template: templates/concept
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
基于属性的访问控制（Attribute-based access control - ABAC）定义了访问控制范例，其中通过使用将属性组合在一起的策略来向用户授予访问权限。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
## 策略文件格式
|
||||
|
||||
基于 `ABAC` 模式，可以这样指定策略文件 `--authorization-policy-file=SOME_FILENAME`。
|
||||
|
||||
此文件是 JSON 格式[每行都是一个JSON对象](http://jsonlines.org/)，不应存在封闭的列表或映射，每行只有一个映射。
|
||||
|
||||
每一行都是一个 "策略对象"，策略对象是具有以下映射的属性:
|
||||
|
||||
- 版本控制属性:
|
||||
- `apiVersion`，字符串类型: 有效值为"abac.authorization.kubernetes.io/v1beta1"，允许版本控制和转换策略格式。
|
||||
- `kind`，字符串类型: 有效值为 "Policy"，允许版本控制和转换策略格式。
|
||||
- `spec` 配置为具有以下映射的属性:
|
||||
- 匹配属性:
|
||||
- `user`，字符串类型; 来自 `--token-auth-file` 的用户字符串，如果你指定`user`，它必须与验证用户的用户名匹配。
|
||||
- `group`，字符串类型; 如果指定`group`，它必须与经过身份验证的用户的一个组匹配，`system:authenticated`匹配所有经过身份验证的请求。`system:unauthenticated`匹配所有未经过身份验证的请求。
|
||||
- 资源匹配属性:
|
||||
- `apiGroup`，字符串类型; 一个 API 组。
|
||||
- 例: `extensions`
|
||||
- 通配符: `*`匹配所有 API 组。
|
||||
- `namespace`，字符串类型; 一个命名空间。
|
||||
- 例如: `kube-system`
|
||||
- 通配符: `*` 匹配所有资源请求。
|
||||
- `resource`，字符串类型; 资源类型。
|
||||
- 例:`pods`
|
||||
- 通配符: `*`匹配所有资源请求。
|
||||
- 非资源匹配属性:
|
||||
- `nonResourcePath`，字符串类型; 非资源请求路径。
|
||||
- 例如:`/version`或`/apis`
|
||||
- 通配符:
|
||||
- `*` 匹配所有非资源请求。
|
||||
- `/foo/*` 匹配`/foo/`的所有子路径。
|
||||
- `readonly`，键入 boolean，如果为 true，则表示该策略仅适用于 get，list 和 watch 操作。
|
||||
|
||||
**注意:** 未设置的属性与类型设置为零值的属性相同(例如空字符串，0、false)，然而未知的应该可读性优先。
|
||||
|
||||
在将来，策略可能以 JSON 格式表示，并通过 REST 界面进行管理。
|
||||
|
||||
## 授权算法
|
||||
|
||||
请求具有与策略对象的属性对应的属性。
|
||||
|
||||
当接收到请求时，确定属性。 未知属性设置为其类型的零值（例如: 空字符串，0，false）。
|
||||
|
||||
设置为`“*"`的属性将匹配相应属性的任何值。
|
||||
|
||||
检查属性的元组，以匹配策略文件中的每个策略。 如果至少有一行匹配请求属性，则请求被授权（但可能会在稍后验证失败）。
|
||||
|
||||
要允许任何经过身份验证的用户执行某些操作，请将策略组属性设置为 `"system:authenticated“`。
|
||||
|
||||
要允许任何未经身份验证的用户执行某些操作，请将策略组属性设置为`"system:authentication“`。
|
||||
|
||||
要允许用户执行任何操作，请使用 apiGroup，命名空间，
|
||||
资源和 nonResourcePath 属性设置为 `“*"`的策略.
|
||||
|
||||
要允许用户执行任何操作，请使用设置为`“*”` 的 apiGroup，namespace，resource 和 nonResourcePath 属性编写策略。
|
||||
|
||||
## Kubectl
|
||||
|
||||
Kubectl 使用 api-server 的 `/api` 和 `/apis` 端点进行协商客户端/服务器版本。 通过创建/更新来验证发送到API的对象操作，kubectl 查询某些 swagger 资源。 对于API版本"v1", 那就是`/swaggerapi/api/v1` ＆ `/swaggerapi/ experimental/v1`。
|
||||
|
||||
当使用 ABAC 授权时，这些特殊资源必须明确通过策略中的 `nonResourcePath` 属性暴露出来(参见下面的[例子](#examples)):
|
||||
|
||||
* `/api`，`/api/*`，`/apis`和`/apis/*` 用于 API 版本协商.
|
||||
* `/version` 通过 `kubectl version` 检索服务器版本.
|
||||
* `/swaggerapi/*` 用于创建/更新操作.
|
||||
|
||||
要检查涉及到特定kubectl操作的HTTP调用，您可以调整详细程度：
|
||||
|
||||
kubectl --v=8 version
|
||||
|
||||
## 例子
|
||||
|
||||
1. Alice 可以对所有资源做任何事情:
|
||||
|
||||
```json
|
||||
{"apiVersion": "abac.authorization.kubernetes.io/v1beta1", "kind": "Policy", "spec": {"user": "alice", "namespace": "*", "resource": "*", "apiGroup": "*"}}
|
||||
```
|
||||
2. Kubelet 可以读取任何pod:
|
||||
|
||||
```json
|
||||
{"apiVersion": "abac.authorization.kubernetes.io/v1beta1", "kind": "Policy", "spec": {"user": "kubelet", "namespace": "*", "resource": "pods", "readonly": true}}
|
||||
```
|
||||
3. Kubelet 可以读写事件:
|
||||
|
||||
```json
|
||||
{"apiVersion": "abac.authorization.kubernetes.io/v1beta1", "kind": "Policy", "spec": {"user": "kubelet", "namespace": "*", "resource": "events"}}
|
||||
```
|
||||
4. Bob 可以在命名空间“projectCaribou"中读取 pod:
|
||||
|
||||
```json
|
||||
{"apiVersion": "abac.authorization.kubernetes.io/v1beta1", "kind": "Policy", "spec": {"user": "bob", "namespace": "projectCaribou", "resource": "pods", "readonly": true}}
|
||||
```
|
||||
5. 任何人都可以对所有非资源路径进行只读请求:
|
||||
|
||||
```json
|
||||
{"apiVersion": "abac.authorization.kubernetes.io/v1beta1", "kind": "Policy", "spec": {"group": "system:authenticated", "readonly": true, "nonResourcePath": "*"}}
|
||||
{"apiVersion": "abac.authorization.kubernetes.io/v1beta1", "kind": "Policy", "spec": {"group": "system:unauthenticated", "readonly": true, "nonResourcePath": "*"}}
|
||||
```
|
||||
|
||||
[完整文件示例](http://releases.k8s.io/{{< param "githubbranch" >}}/pkg/auth/authorizer/abac/example_policy_file.jsonl)
|
||||
|
||||
## 服务帐户的快速说明
|
||||
|
||||
服务帐户自动生成用户。 用户名是根据命名约定生成的:
|
||||
|
||||
```shell
|
||||
system:serviceaccount:<namespace>:<serviceaccountname>
|
||||
```
|
||||
创建新的命名空间也会导致创建一个新的服务帐户：
|
||||
|
||||
```shell
|
||||
system:serviceaccount:<namespace>:default
|
||||
```
|
||||
|
||||
例如，如果要将 API 的 kube-system 完整权限中的默认服务帐户授予，则可以将此行添加到策略文件中:
|
||||
|
||||
```json
|
||||
{"apiVersion":"abac.authorization.kubernetes.io/v1beta1","kind":"Policy","spec":{"user":"system:serviceaccount:kube-system:default","namespace":"*","resource":"*","apiGroup":"*"}}
|
||||
```
|
||||
|
||||
需要重新启动 apiserver 以获取新的策略行.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
@@ -0,0 +1,143 @@
|
||||
---
|
||||
approvers:
|
||||
- erictune
|
||||
- lavalamp
|
||||
- deads2k
|
||||
- liggitt
|
||||
title: Webhook Mode
|
||||
content_template: templates/concept
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
WebHook 是一种 HTTP 回调：某些条件下触发的 HTTP POST 请求；通过 HTTP POST 发送的简单事件通知。一个基于 web 应用实现的 WebHook 会在特定事件发生时把消息发送给特定的 URL 。
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture body %}}
|
||||
具体来说，当在判断用户权限时，`Webhook` 模式会使 Kubernetes 查询外部的 REST 服务。
|
||||
|
||||
## 配置文件格式
|
||||
|
||||
`Webhook` 模式需要一个 HTTP 配置文件，通过 `--authorization-webhook-config-file=SOME_FILENAME` 的参数声明。
|
||||
|
||||
配置文件的格式使用 [kubeconfig](/docs/concepts/cluster-administration/authenticate-across-clusters-kubeconfig/)。
|
||||
在文件中，"users" 代表着 API 服务器的 webhook，而 "cluster" 代表着远程服务。
|
||||
|
||||
使用 HTTPS 客户端认证的配置例子：
|
||||
|
||||
```yaml
|
||||
# clusters 代表远程服务。
|
||||
clusters:
|
||||
- name: name-of-remote-authz-service
|
||||
cluster:
|
||||
certificate-authority: /path/to/ca.pem # 对远程服务进行身份认证的CA。
|
||||
server: https://authz.example.com/authorize # 远程服务的查询 URL. 必须使用 'https'。
|
||||
|
||||
# users 代表 API 服务器的 webhook 配置.
|
||||
users:
|
||||
- name: name-of-api-server
|
||||
user:
|
||||
client-certificate: /path/to/cert.pem # webhook plugin 使用的 cert。
|
||||
client-key: /path/to/key.pem # cert 所对应的 key。
|
||||
|
||||
# kubeconfig 文件必须有 context 。 需要提供一个给 API 服务器。
|
||||
current-context: webhook
|
||||
contexts:
|
||||
- context:
|
||||
cluster: name-of-remote-authz-service
|
||||
user: name-of-api-server
|
||||
name: webhook
|
||||
```
|
||||
|
||||
|
||||
## 请求载荷
|
||||
|
||||
在做认证决策时，API 服务器会 POST 一个 JSON 序列化的 api.authorization.v1beta1.SubjectAccessReview 对象来描述这个动作。这个对象包含了描述用户请求的字段，同时也包含了需要被访问资源或者请求特征的具体信息。
|
||||
|
||||
需要注意的是 webhook API 对象与其他 Kubernetes API 对象一样都同样都服从 [版本兼容规则](/docs/api/) 。
|
||||
实施人员应该了解 beta 对象的更宽松的兼容性承诺，同时确认请求的 "apiVersion" 字段以确保能被正确地反序列化。
|
||||
此外，API 服务器还必须启用 `authorization.k8s.io/v1beta1` API 扩展组(`--runtime-config=authorization.k8s.io/v1beta1=true`)。
|
||||
|
||||
|
||||
一个请求内容的例子：
|
||||
|
||||
```json
|
||||
{
|
||||
"apiVersion": "authorization.k8s.io/v1beta1",
|
||||
"kind": "SubjectAccessReview",
|
||||
"spec": {
|
||||
"resourceAttributes": {
|
||||
"namespace": "kittensandponies",
|
||||
"verb": "get",
|
||||
"group": "unicorn.example.org",
|
||||
"resource": "pods"
|
||||
},
|
||||
"user": "jane",
|
||||
"group": [
|
||||
"group1",
|
||||
"group2"
|
||||
]
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
远程服务被预期能填写请求和反馈的 SubjectAccessReviewStatus 字段，无论是允许访问还是拒绝访问。
|
||||
反馈内容的 "spec" 字段是被忽略的，也是可以被省略的。当请求是被允许的时候，返回的响应如下例所示：
|
||||
|
||||
```json
|
||||
{
|
||||
"apiVersion": "authorization.k8s.io/v1beta1",
|
||||
"kind": "SubjectAccessReview",
|
||||
"status": {
|
||||
"allowed": true
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
|
||||
如拒绝，远程服务器会返回：
|
||||
|
||||
```json
|
||||
{
|
||||
"apiVersion": "authorization.k8s.io/v1beta1",
|
||||
"kind": "SubjectAccessReview",
|
||||
"status": {
|
||||
"allowed": false,
|
||||
"reason": "user does not have read access to the namespace"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
|
||||
对于非资源的路径访问是这么发送的：
|
||||
|
||||
```json
|
||||
{
|
||||
"apiVersion": "authorization.k8s.io/v1beta1",
|
||||
"kind": "SubjectAccessReview",
|
||||
"spec": {
|
||||
"nonResourceAttributes": {
|
||||
"path": "/debug",
|
||||
"verb": "get"
|
||||
},
|
||||
"user": "jane",
|
||||
"group": [
|
||||
"group1",
|
||||
"group2"
|
||||
]
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
|
||||
非资源类的路径包括：`/api`, `/apis`, `/metrics`, `/resetMetrics`,
|
||||
`/logs`, `/debug`, `/healthz`, `/swagger-ui/`, `/swaggerapi/`, `/ui`, and
|
||||
`/version`。 客户端需要访问 `/api`, `/api/*`, `/apis`, `/apis/*`, 和 `/version` 以便
|
||||
能发现服务器上有什么资源和版本。对于其他非资源类的路径访问在没有 REST API 访问限制的情况下拒绝。
|
||||
|
||||
|
||||
更多信息可以参考 uthorization.v1beta1 API 对象和
|
||||
[webhook.go](https://git.k8s.io/kubernetes/staging/src/k8s.io/apiserver/plugin/pkg/authorizer/webhook/webhook.go).
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
Reference in New Issue
Block a user