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 1/4] 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トークンのクレデンシャルを使用するために、プラグ } } ``` - From d116185dc0e56f297dd829bfc567b9954676abc4 Mon Sep 17 00:00:00 2001 From: nishipy <41185206+nishipy@users.noreply.github.com> Date: Fri, 17 Jul 2020 15:25:42 +0900 Subject: [PATCH 2/4] Update content/ja/docs/reference/access-authn-authz/authentication.md Co-authored-by: inductor(Kohei) --- content/ja/docs/reference/access-authn-authz/authentication.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/reference/access-authn-authz/authentication.md b/content/ja/docs/reference/access-authn-authz/authentication.md index 2aea25d77f..03698d57d0 100644 --- a/content/ja/docs/reference/access-authn-authz/authentication.md +++ b/content/ja/docs/reference/access-authn-authz/authentication.md @@ -59,7 +59,7 @@ openssl req -new -key jbeda.pem -out jbeda-csr.pem -subj "/CN=jbeda/O=app1/O=app ### 静的なトークンファイル -コマンドラインで `--token-auth-file=SOMEFILE`オプションを指定すると、APIサーバーはファイルからBearerトークンを読み込みます。現在のところ、トークンの有効期限は無く、API サーバーを再起動しない限りトークンのリストを変更することはできません。 +コマンドラインで`--token-auth-file=SOMEFILE`オプションを指定すると、APIサーバーはファイルからBearerトークンを読み込みます。現在のところ、トークンの有効期限は無く、APIサーバーを再起動しない限りトークンのリストを変更することはできません。 トークンファイルは、トークン、ユーザー名、ユーザーUIDの少なくとも3つの列を持つcsvファイルで、その後にオプションでグループ名が付きます。 From 8ce032187125b7c8e3f5e7405076f24b3db9996c Mon Sep 17 00:00:00 2001 From: nishipy <41185206+nishipy@users.noreply.github.com> Date: Fri, 17 Jul 2020 15:25:51 +0900 Subject: [PATCH 3/4] Update content/ja/docs/reference/access-authn-authz/authentication.md Co-authored-by: inductor(Kohei) --- content/ja/docs/reference/access-authn-authz/authentication.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/reference/access-authn-authz/authentication.md b/content/ja/docs/reference/access-authn-authz/authentication.md index 03698d57d0..f30d644f5a 100644 --- a/content/ja/docs/reference/access-authn-authz/authentication.md +++ b/content/ja/docs/reference/access-authn-authz/authentication.md @@ -73,7 +73,7 @@ token,user,uid,"group1,group2,group3" #### リクエストにBearerトークンを含める {#putting-a-bearer-token-in-a-request} -HTTPクライアントからBearerトークン認証を利用する場合、APIサーバーは`Bearer THETOKEN`という値を持つ `Authorization`ヘッダーを待ち受けます。Bearerトークンは、HTTPのエンコーディングとクォート機能を利用してHTTPヘッダーの値に入れることができる文字列でなければなりません。 例えば、Bearerトークンが `31ada4fd-adec-460c-809a-9e56ceb75269`であれば、HTTPのヘッダを以下のようにします。 +HTTPクライアントからBearerトークン認証を利用する場合、APIサーバーは`Bearer THETOKEN`という値を持つ`Authorization`ヘッダーを待ち受けます。Bearerトークンは、HTTPのエンコーディングとクォート機能を利用してHTTPヘッダーの値に入れることができる文字列でなければなりません。例えば、Bearerトークンが`31ada4fd-adec-460c-809a-9e56ceb75269`であれば、HTTPのヘッダを以下のようにします。 ```http Authorization: Bearer 31ada4fd-adec-460c-809a-9e56ceb75269 From 571606abaae3661cee231fb712e838c7cdc0185b Mon Sep 17 00:00:00 2001 From: nishipy <41185206+nishipy@users.noreply.github.com> Date: Fri, 17 Jul 2020 15:26:01 +0900 Subject: [PATCH 4/4] Update content/ja/docs/reference/access-authn-authz/authentication.md Co-authored-by: inductor(Kohei) --- content/ja/docs/reference/access-authn-authz/authentication.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/reference/access-authn-authz/authentication.md b/content/ja/docs/reference/access-authn-authz/authentication.md index f30d644f5a..6cab7899f8 100644 --- a/content/ja/docs/reference/access-authn-authz/authentication.md +++ b/content/ja/docs/reference/access-authn-authz/authentication.md @@ -93,7 +93,7 @@ Authorization: Bearer 781292.db7bc3a58fc5f07e API サーバーの`--enable-bootstrap-token-auth`フラグで、Bootstrap Token Authenticatorを有効にする必要があります。TokenCleanerコントローラーを有効にするには、Controller Managerの`--controllers`フラグを使います。`--controllers=*,tokencleaner`のようにして行います。クラスターをブートストラップするために`kubeadm`を使用している場合は、`kubeadm`がこれを代行してくれます。 -認証機能は `system:bootstrap:`という名前で認証します。これは`system:bootstrappers`グループに含まれます。名前とグループは意図的に制限されており、ユーザーがブートストラップ後にこれらのトークンを使わないようにしています。 ユーザー名とグループは、クラスタのブートストラップをサポートする適切な認可ポリシーを作成するために使用され、`kubeadm`によって使用されます。 +認証機能は`system:bootstrap:`という名前で認証します。これは`system:bootstrappers`グループに含まれます。名前とグループは意図的に制限されており、ユーザーがブートストラップ後にこれらのトークンを使わないようにしています。ユーザー名とグループは、クラスタのブートストラップをサポートする適切な認可ポリシーを作成するために使用され、`kubeadm`によって使用されます。 ブートストラップトークンの認証機能やコントローラーについての詳細な説明、`kubeadm`でこれらのトークンを管理する方法については、[ブートストラップトークン](/docs/reference/access-authn-authz/bootstrap-tokens/)を参照してください。