From 72810bb2691b5406e8e01f6d2aa5e708f1104f77 Mon Sep 17 00:00:00 2001 From: nishipy <41185206+nishipy@users.noreply.github.com> Date: Fri, 17 Jul 2020 15:25:16 +0900 Subject: [PATCH] Update content/ja/docs/reference/access-authn-authz/authentication.md Co-authored-by: inductor(Kohei) --- content/ja/docs/reference/access-authn-authz/authentication.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/content/ja/docs/reference/access-authn-authz/authentication.md b/content/ja/docs/reference/access-authn-authz/authentication.md index aaf36d8f2e..2aea25d77f 100644 --- a/content/ja/docs/reference/access-authn-authz/authentication.md +++ b/content/ja/docs/reference/access-authn-authz/authentication.md @@ -15,7 +15,7 @@ weight: 10 通常のユーザーは外部の独立したサービスが管理することを想定しています。秘密鍵を配布する管理者、KeystoneやGoogle Accountsのようなユーザーストア、さらにはユーザー名とパスワードのリストを持つファイルなどです。この点では、_Kubernetesは通常のユーザーアカウントを表すオブジェクトを持っていません。_APIコールを介して、通常のユーザーをクラスターに追加することはできません。 -対照的に、サービスアカウントはKubernetes APIによって管理されるユーザーです。サービスアカウントは特定の名前空間にバインドされており、APIサーバーによって自動的に作成されるか、APIコールによって手動で作成されます。サービスアカウントは、 `Secrets`として保存された資格情報のセットに紐付けられています。これをPodにマウントすることで、クラスター内のプロセスがKubernetes APIと通信できるようにします。 +対照的に、サービスアカウントはKubernetes APIによって管理されるユーザーです。サービスアカウントは特定の名前空間にバインドされており、APIサーバーによって自動的に作成されるか、APIコールによって手動で作成されます。サービスアカウントは、`Secrets`として保存された資格情報のセットに紐付けられています。これをPodにマウントすることで、クラスター内のプロセスがKubernetes APIと通信できるようにします。 APIリクエストは、通常のユーザーかサービスアカウントに紐付けられているか、[匿名リクエスト](#anonymous-requests)として扱われます。つまり、ワークステーションで`kubectl`を入力する人間のユーザーから、ノード上の`kubelets`やコントロールプレーンのメンバーまで、クラスター内外の全てのプロセスは、APIサーバーへのリクエストを行う際に認証を行うか匿名ユーザーとして扱われる必要があります。 @@ -709,4 +709,3 @@ Bearerトークンのクレデンシャルを使用するために、プラグ } } ``` -