From 34d2a2e7f25d8075a86fab21a03f606b73d92ab2 Mon Sep 17 00:00:00 2001 From: Weibin Lin Date: Thu, 14 Sep 2017 06:40:32 +0800 Subject: [PATCH] fix typos in /admin/authorization/rbac.md (#5427) --- docs/admin/authorization/rbac.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/admin/authorization/rbac.md b/docs/admin/authorization/rbac.md index 5eae556f61..23d36f7185 100644 --- a/docs/admin/authorization/rbac.md +++ b/docs/admin/authorization/rbac.md @@ -102,7 +102,7 @@ This allows administrators to define a set of common roles for the entire cluste then reuse them within multiple namespaces. For instance, even though the following `RoleBinding` refers to a `ClusterRole`, -"dave" (the subject) will only be able read secrets in the "development" +"dave" (the subject) will only be able to read secrets in the "development" namespace (the namespace of the `RoleBinding`). ```yaml @@ -258,7 +258,7 @@ A `RoleBinding` or `ClusterRoleBinding` binds a role to *subjects*. Subjects can be groups, users or service accounts. Users are represented by strings. These can be plain usernames, like -"alice", email-style names, like "bob@example.com", or numeric ids +"alice", email-style names, like "bob@example.com", or numeric IDs represented as a string. It is up to the Kubernetes admin to configure the [authentication modules](/docs/admin/authentication/) to produce usernames in the desired format. The RBAC authorization system does