From e7679e86cdf9d227827f4e90a086f2e9ae3c81a4 Mon Sep 17 00:00:00 2001 From: lovejoy Date: Wed, 6 Jun 2018 04:53:56 +0800 Subject: [PATCH] change direct link to relative link (#8839) --- content/en/docs/concepts/configuration/secret.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/content/en/docs/concepts/configuration/secret.md b/content/en/docs/concepts/configuration/secret.md index a90e1f85d7..4030536bc1 100644 --- a/content/en/docs/concepts/configuration/secret.md +++ b/content/en/docs/concepts/configuration/secret.md @@ -667,8 +667,8 @@ it to read a file. When deploying applications that interact with the secrets API, access should be limited using [authorization policies]( -https://kubernetes.io/docs/admin/authorization/) such as [RBAC]( -https://kubernetes.io/docs/admin/authorization/rbac/). +/docs/reference/access-authn-authz/authorization/) such as [RBAC]( +/docs/reference/access-authn-authz/rbac/). Secrets often hold values that span a spectrum of importance, many of which can cause escalations within Kubernetes (e.g. service account tokens) and to @@ -685,7 +685,7 @@ privileged, system-level components. Applications that need to access the secrets API should perform `get` requests on the secrets they need. This lets administrators restrict access to all secrets while [white-listing access to individual instances]( -https://kubernetes.io/docs/admin/authorization/rbac/#referring-to-resources) that +/docs/reference/access-authn-authz/rbac/#referring-to-resources) that the app needs. For improved performance over a looping `get`, clients can design resources that @@ -748,5 +748,5 @@ Pod level](#use-case-secret-visible-to-one-container-in-a-pod). single node. {{< note >}} -**Note:** As of 1.7 [encryption of secret data at rest is supported](https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/). +**Note:** As of 1.7 [encryption of secret data at rest is supported](/docs/tasks/administer-cluster/encrypt-data/). {{< /note >}}