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

Tweak paragraph to kill orphaned fragment

Browse Source
This commit is contained in:
Qiming Teng
2020-07-11 15:46:30 +08:00
parent dab8047c85
commit 031747e460
1 changed files with 8 additions and 5 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/en/docs/reference/access-authn-authz/authentication.md
+8 -5
View File
@@ -20,11 +20,14 @@ This page provides an overview of authenticating.
All Kubernetes clusters have two categories of users: service accounts managed All Kubernetes clusters have two categories of users: service accounts managed
by Kubernetes, and normal users. by Kubernetes, and normal users.
Normal users are assumed to be managed by an outside, independent service. An It is assumed that a cluster-independent service manages normal users in the following ways:
admin distributing private keys, a user store like Keystone or Google Accounts,
even a file with a list of usernames and passwords. In this regard, _Kubernetes - an administrator distributing private keys
does not have objects which represent normal user accounts._ Normal users - a user store like Keystone or Google Accounts
cannot be added to a cluster through an API call. - a file with a list of usernames and passwords
In this regard, _Kubernetes does not have objects which represent normal user
accounts._ Normal users cannot be added to a cluster through an API call.
Even though normal user cannot be added via an API call, but any user that presents a valid certificate signed by the cluster’s certificate authority (CA) is considered authenticated. In this configuration, Kubernetes determines the username from the common name field in the ‘subject’ of the cert (e.g., “/CN=bob”). From there, the role based access control (RBAC) sub-system would determine whether the user is authorized to perform a specific operation on a resource. You can refer to [creating user certificate request](/docs/reference/access-authn-authz/certificate-signing-requests/#user-csr) for more details about this. Even though normal user cannot be added via an API call, but any user that presents a valid certificate signed by the cluster’s certificate authority (CA) is considered authenticated. In this configuration, Kubernetes determines the username from the common name field in the ‘subject’ of the cert (e.g., “/CN=bob”). From there, the role based access control (RBAC) sub-system would determine whether the user is authorized to perform a specific operation on a resource. You can refer to [creating user certificate request](/docs/reference/access-authn-authz/certificate-signing-requests/#user-csr) for more details about this.