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

Fix relative links issue in zh content (#13312)

Browse Source 
* `http://kubernetes.io/docs/` -> `/docs/`

* `https://kubernetes.io/docs/` -> `/docs/`
This commit is contained in:
chenrui
2019-03-20 20:55:36 -04:00
committed by Kubernetes Prow Robot
parent 868899b059
commit 61ee18e87b
37 changed files with 117 additions and 135 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/zh/docs/concepts/configuration/secret.md
+2 -2
View File
@@ -548,13 +548,13 @@ spec:
### 客户端使用 Secret API
当部署与 secret API 交互的应用程序时，应使用诸如 [RBAC](https://kubernetes.io/docs/admin/authorization/rbac/) 之类的 [授权策略](https://kubernetes.io/docs/admin/authorization/) 来限制访问。
当部署与 secret API 交互的应用程序时，应使用诸如 [RBAC](/docs/admin/authorization/rbac/) 之类的 [授权策略](/docs/admin/authorization/) 来限制访问。
Secret 中的值对于不同的环境来说重要性可能不同，例如对于 Kubernetes 集群内部（例如 service account 令牌）和集群外部来说就不一样。即使一个应用程序可以理解其期望的与之交互的 secret 有多大的能力，但是同一命名空间中的其他应用程序却可能不这样认为。
由于这些原因，在命名空间中 `watch` 和 `list` secret 的请求是非常强大的功能，应该避免这样的行为，因为列出 secret 可以让客户端检查所有 secret 是否在该命名空间中。在群集中`watch` 和 `list` 所有 secret 的能力应该只保留给最有特权的系统级组件。
需要访问 secrets API 的应用程序应该根据他们需要的 secret 执行 `get` 请求。这允许管理员限制对所有 secret 的访问，同时设置 [白名单访问](https://kubernetes.io/docs/admin/authorization/rbac/#referring-to-resources) 应用程序需要的各个实例。
需要访问 secrets API 的应用程序应该根据他们需要的 secret 执行 `get` 请求。这允许管理员限制对所有 secret 的访问，同时设置 [白名单访问](/docs/admin/authorization/rbac/#referring-to-resources) 应用程序需要的各个实例。
为了提高循环获取的性能，客户端可以设计引用 secret 的资源，然后 `watch` 资源，在引用更改时重新请求 secret。此外，还提出了一种 [”批量监控“ API](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/bulk_watch.md) 来让客户端 `watch` 每个资源，该功能可能会在将来的 Kubernetes 版本中提供。