From 5323c317e8462c7765e52ecfb95f4b4373b2afde Mon Sep 17 00:00:00 2001 From: 196Ikuchil <196thinline@gmail.com> Date: Wed, 30 Mar 2022 01:00:39 +0900 Subject: [PATCH 01/14] add:translate concepts/security/controlling-access.md --- .../concepts/security/controlling-access.md | 164 ++++++++++++++++++ 1 file changed, 164 insertions(+) create mode 100644 content/ja/docs/concepts/security/controlling-access.md diff --git a/content/ja/docs/concepts/security/controlling-access.md b/content/ja/docs/concepts/security/controlling-access.md new file mode 100644 index 0000000000..39dc38c12d --- /dev/null +++ b/content/ja/docs/concepts/security/controlling-access.md @@ -0,0 +1,164 @@ +--- +title: Kubernetes APIへのアクセス制御 +content_type: concept +--- + + +このページではKubernetes APIへのアクセス制御の概要を説明します。 + + + +[Kubernetes API](/ja/docs/concepts/overview/kubernetes-api/)には`kubectl`やクライアントライブラリ、あるいはRESTリクエストを用いてアクセスします。 + APIアクセスには、人間のユーザーと[Kubernetesサービスアカウント](/docs/tasks/configure-pod-container/configure-service-account/)の両方が認証可能です。 +リクエストがAPIに到達すると、次の図のようにいくつかの段階を経ます。 + +![Kubernetes APIリクエストの処理手順図](/images/docs/admin/access-control-overview.svg) + +## トランスポート層のセキュリティ +一般的なKubernetesクラスターでは、APIはTLSで保護された443番ポートで提供されます。 +APIサーバーは証明書を提示します。 +この証明書は、プライベート認証局(CA)を用いて署名することも、一般に認知されているCAと連携した公開鍵基盤に基づき署名することも可能です。 + +クラスターがプライベート認証局を使用している場合、接続を信頼し、傍受されていないと確信できるように、クライアント上の`~/.kube/config`に設定されたそのCA証明書のコピーが必要です。 + +クライアントは、この段階でTLSクライアント証明書を提示することができます。 + +## 認証 +TLSが確立されると、HTTPリクエストは認証のステップに移行します。 +これは図中のステップ**1**に該当します。 +クラスター作成スクリプトまたはクラスター管理者は、1つまたは複数のAuthenticatorモジュールを実行するようにAPIサーバーを設定します。 +Authenticatorについては、[認証](/ja/docs/reference/access-authn-authz/authentication/)で詳しく説明されています。 + +認証ステップへの入力はHTTPリクエスト全体ですが、通常はヘッダとクライアント証明書の両方、またはどちらかを調べます。 + +認証モジュールには、クライアント証明書、パスワード、プレーントークン、ブートストラップトークン、JSON Web Tokens(サービスアカウントに使用)などがあります。 + +複数の認証モジュールを指定することができ、その場合、1つの認証モジュールが成功するまで、それぞれを順番に試行します。 + +認証できない場合、HTTPステータスコード401で拒否されます。 +そうでなければ、ユーザーは特定の`username`として認証され、そのユーザー名は後続のステップでの判断に使用できるようになります。 +また、ユーザーのグループメンバーシップを提供する認証機関と、提供しない認証機関がある。 + +Kubernetesはアクセス制御の決定やリクエストログにユーザー名を使用しますが、`User`オブジェクトを持たず、ユーザー名やその他のユーザーに関する情報をAPIはに保存しません。 + +## 認可 + +リクエストが特定のユーザーからのものであると認証された後、そのリクエストは認可される必要があります。 +これは図のステップ**2**に該当します。 + +リクエストには、リクエスト者のユーザー名、リクエストされたアクション、そのアクションによって影響を受けるオブジェクトを含める必要があります。 +既存のポリシーで、ユーザーが要求されたアクションを完了するための権限を持っていると宣言されている場合、リクエストは承認されます。 + +例えば、Bobが以下のようなポリシーを持っている場合、彼は名前空間`projectCaribou`内のPodのみを読むことができます。 + +```json +{ + "apiVersion": "abac.authorization.kubernetes.io/v1beta1", + "kind": "Policy", + "spec": { + "user": "bob", + "namespace": "projectCaribou", + "resource": "pods", + "readonly": true + } +} +``` +Bobが次のようなリクエストをした場合、Bobは名前空間`projectCaribou`のオブジェクトを読むことが許可されているので、このリクエストは認可されます。 + +```json +{ + "apiVersion": "authorization.k8s.io/v1beta1", + "kind": "SubjectAccessReview", + "spec": { + "resourceAttributes": { + "namespace": "projectCaribou", + "verb": "get", + "group": "unicorn.example.org", + "resource": "pods" + } + } +} +``` +Bobが名前空間`projectCaribou`のオブジェクトに書き込み(`create`または`update`)のリクエストをした場合、承認は拒否されます。 +また、もしボブが`projectFish`のような別の名前空間にあるオブジェクトを読み込む(`get`)リクエストをした場合も、承認は拒否されます。 + +Kubernetesの認可では、組織全体またはクラウドプロバイダー全体の既存のアクセス制御システムと対話するために、共通のREST属性を使用する必要があります。 +これらの制御システムは、Kubernetes API以外のAPIとやり取りする可能性があるため、REST形式を使用することが重要です。 + +Kubernetesは、ABACモード、RBACモード、Webhookモードなど、複数の認可モジュールをサポートしています。 +管理者はクラスターを作成する際に、APIサーバーで使用する認証モジュールを設定します。 +複数の認可モジュールが設定されている場合、Kubernetesは各モジュールをチェックし、いずれかのモジュールがリクエストを認可した場合、リクエストを続行することができます。 +すべてのモジュールがリクエストを拒否した場合、リクエストは拒否されます(HTTPステータスコード403)。 + +サポートされている認可モジュールを使用したポリシー作成の詳細を含む、Kubernetesの認可については、[認可](/docs/reference/access-authn-authz/authorization/)を参照してください。 + + +## Admission Control +Admission Controlモジュールは、リクエストを変更したり拒否したりすることができるソフトウェアモジュールです。 +認可モジュールが利用できる属性に加えて、Admission Controlモジュールは、作成または修正されるオブジェクトのコンテンツにアクセスすることができます。 + +アドミッションコントローラーは、オブジェクトの作成、変更、削除、または接続(プロキシ)を行うリクエストに対して動作します。 +アドミッションコントローラーは、単にオブジェクトを読み取るだけのリクエストには動作しません。 +複数のアドミッションコントローラーが設定されている場合は、順番に呼び出されます。 + +これは図中のステップ**3**に該当します。 + +認証・認可モジュールとは異なり、いずれかのアドミッションコントローラーモジュールが拒否した場合、リクエストは即座に拒否されます。 + +オブジェクトを拒否するだけでなく、アドミッションコントローラーは、フィールドに複雑なデフォルトを設定することもできます。 + +利用可能なAdmission Controlモジュールは、[アドミッションコントローラー](/docs/reference/access-authn-authz/admission-controllers/)に記載されています。 + +リクエストがすべてのアドミッションコントローラーを通過すると、対応するAPIオブジェクトの検証ルーチンを使って検証され、オブジェクトストアに書き込まれます(図のステップ **4**に該当します)。 + + +## APIサーバーのIPとポート + +これまでの説明は、APIサーバーのセキュアポートに送信されるリクエストに適用されます(典型的なケース)。 +APIサーバーは、実際には2つのポートでサービスを提供することができます。 + + +デフォルトでは、Kubernetes APIサーバーは2つのポートでHTTPを提供します。 + + 1. `localhost`ポート: + + - テストとブートストラップ用で、マスターノードの他のコンポーネント(スケジューラ、コントローラマネージャ)がAPIと通信するためのものです。 + - TLSは使用しません。 + - デフォルトポートは8080です。 + - デフォルトのIPはlocalhostですが、`--insecure-bind-address`フラグで変更することができます。 + - リクエストは認証と認可のモジュールを**バイパス**します。 + - リクエストは、Admission Controlモジュールによって処理されます。 + - ホストにアクセスする必要があるため、保護されています。 + + 2. “セキュアポート”: + + - 可能な限りこちらを使用してください。 + - TLSを使用します。証明書は`--tls-cert-file`フラグで、鍵は`--tls-private-key-file`フラグで設定します。 + - デフォルトポートは6443です。`--secure-port`フラグで変更することができます。. + - デフォルトのIPは、最初の非localhostのネットワークインターフェースです。`--bind-address`フラグで変更することができます。 + - リクエストは、認証・認可モジュールによって処理されます。 + - リクエストは、Admission Controlモジュールによって処理されます。 + - 認証・認可モジュールが実行されます。 + +## {{% heading "whatsnext" %}} + +認証、認可、APIアクセス制御に関する詳しいドキュメントはこちらをご覧ください。 + +- [認証](/ja/docs/reference/access-authn-authz/authentication/) + - [ブートストラップトークンでの認証](/docs/reference/access-authn-authz/bootstrap-tokens/) +- [アドミッションコントローラー](/docs/reference/access-authn-authz/admission-controllers/) + - [動的Admission Control](/docs/reference/access-authn-authz/extensible-admission-controllers/) +- [認可](/docs/reference/access-authn-authz/authorization/) + - [ロールに基づいたアクセス制御](/ja/docs/reference/access-authn-authz/rbac/) + - [属性に基づいたアクセス制御](/docs/reference/access-authn-authz/abac/) + - [Nodeの認可](/docs/reference/access-authn-authz/node/) + - [Webhookの認可](/docs/reference/access-authn-authz/webhook/) +- [証明書の署名要求](/docs/reference/access-authn-authz/certificate-signing-requests/) + - [CSRの承認](/docs/reference/access-authn-authz/certificate-signing-requests/#approval-rejection)と[証明書の署名](/docs/reference/access-authn-authz/certificate-signing-requests/#signing)を含む +- サービスアカウント + - [Developer guide](/docs/tasks/configure-pod-container/configure-service-account/) + - [Administration](/docs/reference/access-authn-authz/service-accounts-admin/) + +以下についても知ることができます。 +- PodがAPIクレデンシャルを取得するために[Secrets](/ja/docs/concepts/configuration/secret/#service-accounts-automatically-create-and-attach-secrets-with-api-credentials)を使用する方法について。 + From b86b858735932d39ee0672b9e04e99ae7081fdca Mon Sep 17 00:00:00 2001 From: 196Ikuchil <196thinline@gmail.com> Date: Wed, 30 Mar 2022 01:15:32 +0900 Subject: [PATCH 02/14] =?UTF-8?q?fix:change=20=E3=81=8C=E3=81=82=E3=82=8B?= =?UTF-8?q?=20to=20=E3=81=8C=E3=81=82=E3=82=8A=E3=81=BE=E3=81=99?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- content/ja/docs/concepts/security/controlling-access.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/security/controlling-access.md b/content/ja/docs/concepts/security/controlling-access.md index 39dc38c12d..fe6708952e 100644 --- a/content/ja/docs/concepts/security/controlling-access.md +++ b/content/ja/docs/concepts/security/controlling-access.md @@ -37,7 +37,7 @@ Authenticatorについては、[認証](/ja/docs/reference/access-authn-authz/au 認証できない場合、HTTPステータスコード401で拒否されます。 そうでなければ、ユーザーは特定の`username`として認証され、そのユーザー名は後続のステップでの判断に使用できるようになります。 -また、ユーザーのグループメンバーシップを提供する認証機関と、提供しない認証機関がある。 +また、ユーザーのグループメンバーシップを提供する認証機関と、提供しない認証機関があります。 Kubernetesはアクセス制御の決定やリクエストログにユーザー名を使用しますが、`User`オブジェクトを持たず、ユーザー名やその他のユーザーに関する情報をAPIはに保存しません。 From 9fa798cd48dbab54e267d7ef2834b176e9e2c4a1 Mon Sep 17 00:00:00 2001 From: 196Ikuchil <196thinline@gmail.com> Date: Wed, 30 Mar 2022 20:55:48 +0900 Subject: [PATCH 03/14] add:localize diagram --- .../concepts/security/controlling-access.md | 2 +- .../docs/admin/access-control-overview-ja.svg | 139 ++++++++++++++++++ 2 files changed, 140 insertions(+), 1 deletion(-) create mode 100644 static/images/docs/admin/access-control-overview-ja.svg diff --git a/content/ja/docs/concepts/security/controlling-access.md b/content/ja/docs/concepts/security/controlling-access.md index fe6708952e..fa55f4d3f0 100644 --- a/content/ja/docs/concepts/security/controlling-access.md +++ b/content/ja/docs/concepts/security/controlling-access.md @@ -12,7 +12,7 @@ content_type: concept APIアクセスには、人間のユーザーと[Kubernetesサービスアカウント](/docs/tasks/configure-pod-container/configure-service-account/)の両方が認証可能です。 リクエストがAPIに到達すると、次の図のようにいくつかの段階を経ます。 -![Kubernetes APIリクエストの処理手順図](/images/docs/admin/access-control-overview.svg) +![Kubernetes APIリクエストの処理手順図](/images/docs/admin/access-control-overview-ja.svg) ## トランスポート層のセキュリティ 一般的なKubernetesクラスターでは、APIはTLSで保護された443番ポートで提供されます。 diff --git a/static/images/docs/admin/access-control-overview-ja.svg b/static/images/docs/admin/access-control-overview-ja.svg new file mode 100644 index 0000000000..d24e7119ab --- /dev/null +++ b/static/images/docs/admin/access-control-overview-ja.svg @@ -0,0 +1,139 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + ユーザー + Pod​(Kubernetes​サービスアカウント) + 認証 + 認可 + アドミッション​コントロール + APIサーバー + \ No newline at end of file From b22c87c411f8c8fc6767a09ea62619c49b5a9ed3 Mon Sep 17 00:00:00 2001 From: 196Ikuchil <196thinline@gmail.com> Date: Wed, 30 Mar 2022 20:59:59 +0900 Subject: [PATCH 04/14] =?UTF-8?q?fix:change=20admission=20control=20to=20?= =?UTF-8?q?=E3=82=A2=E3=83=89=E3=83=9F=E3=83=83=E3=82=B7=E3=83=A7=E3=83=B3?= =?UTF-8?q?=E3=82=B3=E3=83=B3=E3=83=88=E3=83=AD=E3=83=BC=E3=83=AB?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- .../concepts/security/controlling-access.md | 20 +++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/content/ja/docs/concepts/security/controlling-access.md b/content/ja/docs/concepts/security/controlling-access.md index fa55f4d3f0..109335c0e7 100644 --- a/content/ja/docs/concepts/security/controlling-access.md +++ b/content/ja/docs/concepts/security/controlling-access.md @@ -9,7 +9,7 @@ content_type: concept [Kubernetes API](/ja/docs/concepts/overview/kubernetes-api/)には`kubectl`やクライアントライブラリ、あるいはRESTリクエストを用いてアクセスします。 - APIアクセスには、人間のユーザーと[Kubernetesサービスアカウント](/docs/tasks/configure-pod-container/configure-service-account/)の両方が認証可能です。 +APIアクセスには、人間のユーザーと[Kubernetesサービスアカウント](/docs/tasks/configure-pod-container/configure-service-account/)の両方が認証可能です。 リクエストがAPIに到達すると、次の図のようにいくつかの段階を経ます。 ![Kubernetes APIリクエストの処理手順図](/images/docs/admin/access-control-overview-ja.svg) @@ -93,9 +93,9 @@ Kubernetesは、ABACモード、RBACモード、Webhookモードなど、複数 サポートされている認可モジュールを使用したポリシー作成の詳細を含む、Kubernetesの認可については、[認可](/docs/reference/access-authn-authz/authorization/)を参照してください。 -## Admission Control -Admission Controlモジュールは、リクエストを変更したり拒否したりすることができるソフトウェアモジュールです。 -認可モジュールが利用できる属性に加えて、Admission Controlモジュールは、作成または修正されるオブジェクトのコンテンツにアクセスすることができます。 +## アドミッションコントロール +アドミッションコントロールモジュールは、リクエストを変更したり拒否したりすることができるソフトウェアモジュールです。 +認可モジュールが利用できる属性に加えて、アドミッションコントロールモジュールは、作成または修正されるオブジェクトのコンテンツにアクセスすることができます。 アドミッションコントローラーは、オブジェクトの作成、変更、削除、または接続(プロキシ)を行うリクエストに対して動作します。 アドミッションコントローラーは、単にオブジェクトを読み取るだけのリクエストには動作しません。 @@ -107,9 +107,9 @@ Admission Controlモジュールは、リクエストを変更したり拒否し オブジェクトを拒否するだけでなく、アドミッションコントローラーは、フィールドに複雑なデフォルトを設定することもできます。 -利用可能なAdmission Controlモジュールは、[アドミッションコントローラー](/docs/reference/access-authn-authz/admission-controllers/)に記載されています。 +利用可能なアドミッションコントロールモジュールは、[アドミッションコントローラー](/docs/reference/access-authn-authz/admission-controllers/)に記載されています。 -リクエストがすべてのアドミッションコントローラーを通過すると、対応するAPIオブジェクトの検証ルーチンを使って検証され、オブジェクトストアに書き込まれます(図のステップ **4**に該当します)。 +リクエストがすべてのアドミッションコントローラーを通過すると、対応するAPIオブジェクトの検証ルーチンを使って検証され、オブジェクトストアに書き込まれます(図のステップ**4**に該当します)。 ## APIサーバーのIPとポート @@ -122,12 +122,12 @@ APIサーバーは、実際には2つのポートでサービスを提供する 1. `localhost`ポート: - - テストとブートストラップ用で、マスターノードの他のコンポーネント(スケジューラ、コントローラマネージャ)がAPIと通信するためのものです。 + - テストとブートストラップ用で、マスターノードの他のコンポーネント(スケジューラ、コントローラマネージャー)がAPIと通信するためのものです。 - TLSは使用しません。 - デフォルトポートは8080です。 - デフォルトのIPはlocalhostですが、`--insecure-bind-address`フラグで変更することができます。 - リクエストは認証と認可のモジュールを**バイパス**します。 - - リクエストは、Admission Controlモジュールによって処理されます。 + - リクエストは、アドミッションコントロールモジュールによって処理されます。 - ホストにアクセスする必要があるため、保護されています。 2. “セキュアポート”: @@ -137,7 +137,7 @@ APIサーバーは、実際には2つのポートでサービスを提供する - デフォルトポートは6443です。`--secure-port`フラグで変更することができます。. - デフォルトのIPは、最初の非localhostのネットワークインターフェースです。`--bind-address`フラグで変更することができます。 - リクエストは、認証・認可モジュールによって処理されます。 - - リクエストは、Admission Controlモジュールによって処理されます。 + - リクエストは、アドミッションコントロールモジュールによって処理されます。 - 認証・認可モジュールが実行されます。 ## {{% heading "whatsnext" %}} @@ -147,7 +147,7 @@ APIサーバーは、実際には2つのポートでサービスを提供する - [認証](/ja/docs/reference/access-authn-authz/authentication/) - [ブートストラップトークンでの認証](/docs/reference/access-authn-authz/bootstrap-tokens/) - [アドミッションコントローラー](/docs/reference/access-authn-authz/admission-controllers/) - - [動的Admission Control](/docs/reference/access-authn-authz/extensible-admission-controllers/) + - [動的アドミッションコントロール](/docs/reference/access-authn-authz/extensible-admission-controllers/) - [認可](/docs/reference/access-authn-authz/authorization/) - [ロールに基づいたアクセス制御](/ja/docs/reference/access-authn-authz/rbac/) - [属性に基づいたアクセス制御](/docs/reference/access-authn-authz/abac/) From a3d98f8ed84e08478589d73596db6812dbaadcfd Mon Sep 17 00:00:00 2001 From: 196Ikuchil <196thinline@gmail.com> Date: Wed, 30 Mar 2022 21:01:42 +0900 Subject: [PATCH 05/14] =?UTF-8?q?fix:change=20=E5=88=B6=E5=BE=A1=20to=20?= =?UTF-8?q?=E3=82=B3=E3=83=B3=E3=83=88=E3=83=AD=E3=83=BC=E3=83=AB?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- .../docs/concepts/security/controlling-access.md | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/content/ja/docs/concepts/security/controlling-access.md b/content/ja/docs/concepts/security/controlling-access.md index 109335c0e7..874811771b 100644 --- a/content/ja/docs/concepts/security/controlling-access.md +++ b/content/ja/docs/concepts/security/controlling-access.md @@ -1,10 +1,10 @@ --- -title: Kubernetes APIへのアクセス制御 +title: Kubernetes APIへのアクセスコントロール content_type: concept --- -このページではKubernetes APIへのアクセス制御の概要を説明します。 +このページではKubernetes APIへのアクセスコントロールの概要を説明します。 @@ -39,7 +39,7 @@ Authenticatorについては、[認証](/ja/docs/reference/access-authn-authz/au そうでなければ、ユーザーは特定の`username`として認証され、そのユーザー名は後続のステップでの判断に使用できるようになります。 また、ユーザーのグループメンバーシップを提供する認証機関と、提供しない認証機関があります。 -Kubernetesはアクセス制御の決定やリクエストログにユーザー名を使用しますが、`User`オブジェクトを持たず、ユーザー名やその他のユーザーに関する情報をAPIはに保存しません。 +Kubernetesはアクセスコントロールの決定やリクエストログにユーザー名を使用しますが、`User`オブジェクトを持たず、ユーザー名やその他のユーザーに関する情報をAPIはに保存しません。 ## 認可 @@ -82,8 +82,8 @@ Bobが次のようなリクエストをした場合、Bobは名前空間`project Bobが名前空間`projectCaribou`のオブジェクトに書き込み(`create`または`update`)のリクエストをした場合、承認は拒否されます。 また、もしボブが`projectFish`のような別の名前空間にあるオブジェクトを読み込む(`get`)リクエストをした場合も、承認は拒否されます。 -Kubernetesの認可では、組織全体またはクラウドプロバイダー全体の既存のアクセス制御システムと対話するために、共通のREST属性を使用する必要があります。 -これらの制御システムは、Kubernetes API以外のAPIとやり取りする可能性があるため、REST形式を使用することが重要です。 +Kubernetesの認可では、組織全体またはクラウドプロバイダー全体の既存のアクセスコントロールシステムと対話するために、共通のREST属性を使用する必要があります。 +これらのコントロールシステムは、Kubernetes API以外のAPIとやり取りする可能性があるため、REST形式を使用することが重要です。 Kubernetesは、ABACモード、RBACモード、Webhookモードなど、複数の認可モジュールをサポートしています。 管理者はクラスターを作成する際に、APIサーバーで使用する認証モジュールを設定します。 @@ -142,15 +142,15 @@ APIサーバーは、実際には2つのポートでサービスを提供する ## {{% heading "whatsnext" %}} -認証、認可、APIアクセス制御に関する詳しいドキュメントはこちらをご覧ください。 +認証、認可、APIアクセスコントロールに関する詳しいドキュメントはこちらをご覧ください。 - [認証](/ja/docs/reference/access-authn-authz/authentication/) - [ブートストラップトークンでの認証](/docs/reference/access-authn-authz/bootstrap-tokens/) - [アドミッションコントローラー](/docs/reference/access-authn-authz/admission-controllers/) - [動的アドミッションコントロール](/docs/reference/access-authn-authz/extensible-admission-controllers/) - [認可](/docs/reference/access-authn-authz/authorization/) - - [ロールに基づいたアクセス制御](/ja/docs/reference/access-authn-authz/rbac/) - - [属性に基づいたアクセス制御](/docs/reference/access-authn-authz/abac/) + - [ロールに基づいたアクセスコントロール](/ja/docs/reference/access-authn-authz/rbac/) + - [属性に基づいたアクセスコントロール](/docs/reference/access-authn-authz/abac/) - [Nodeの認可](/docs/reference/access-authn-authz/node/) - [Webhookの認可](/docs/reference/access-authn-authz/webhook/) - [証明書の署名要求](/docs/reference/access-authn-authz/certificate-signing-requests/) From 1e1ab08a4311727cd09238c4f81c47ae66bac1ff Mon Sep 17 00:00:00 2001 From: 196Ikuchil <196thinline@gmail.com> Date: Thu, 31 Mar 2022 00:26:38 +0900 Subject: [PATCH 06/14] fix:delete localized image --- .../concepts/security/controlling-access.md | 2 +- .../docs/admin/access-control-overview-ja.svg | 139 ------------------ 2 files changed, 1 insertion(+), 140 deletions(-) delete mode 100644 static/images/docs/admin/access-control-overview-ja.svg diff --git a/content/ja/docs/concepts/security/controlling-access.md b/content/ja/docs/concepts/security/controlling-access.md index 874811771b..2b4ee1315f 100644 --- a/content/ja/docs/concepts/security/controlling-access.md +++ b/content/ja/docs/concepts/security/controlling-access.md @@ -12,7 +12,7 @@ content_type: concept APIアクセスには、人間のユーザーと[Kubernetesサービスアカウント](/docs/tasks/configure-pod-container/configure-service-account/)の両方が認証可能です。 リクエストがAPIに到達すると、次の図のようにいくつかの段階を経ます。 -![Kubernetes APIリクエストの処理手順図](/images/docs/admin/access-control-overview-ja.svg) +![Kubernetes APIリクエストの処理手順図](/images/docs/admin/access-control-overview.svg) ## トランスポート層のセキュリティ 一般的なKubernetesクラスターでは、APIはTLSで保護された443番ポートで提供されます。 diff --git a/static/images/docs/admin/access-control-overview-ja.svg b/static/images/docs/admin/access-control-overview-ja.svg deleted file mode 100644 index d24e7119ab..0000000000 --- a/static/images/docs/admin/access-control-overview-ja.svg +++ /dev/null @@ -1,139 +0,0 @@ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ユーザー - Pod​(Kubernetes​サービスアカウント) - 認証 - 認可 - アドミッション​コントロール - APIサーバー - \ No newline at end of file From bffd0b822a8d136007542484f03854ec65bb07d7 Mon Sep 17 00:00:00 2001 From: 196Ikuchil <22634362+196Ikuchil@users.noreply.github.com> Date: Mon, 4 Apr 2022 21:10:11 +0900 Subject: [PATCH 07/14] Update content/ja/docs/concepts/security/controlling-access.md Co-authored-by: Toshiaki Inukai <82919057+t-inu@users.noreply.github.com> --- content/ja/docs/concepts/security/controlling-access.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/security/controlling-access.md b/content/ja/docs/concepts/security/controlling-access.md index 2b4ee1315f..60d9495a02 100644 --- a/content/ja/docs/concepts/security/controlling-access.md +++ b/content/ja/docs/concepts/security/controlling-access.md @@ -122,7 +122,7 @@ APIサーバーは、実際には2つのポートでサービスを提供する 1. `localhost`ポート: - - テストとブートストラップ用で、マスターノードの他のコンポーネント(スケジューラ、コントローラマネージャー)がAPIと通信するためのものです。 + - テストとブートストラップ用で、マスターノードの他のコンポーネント(スケジューラー、コントローラーマネージャー)がAPIと通信するためのものです。 - TLSは使用しません。 - デフォルトポートは8080です。 - デフォルトのIPはlocalhostですが、`--insecure-bind-address`フラグで変更することができます。 From 2bee59baf6e0ecd84f7b8cb0ba1ab040163164a4 Mon Sep 17 00:00:00 2001 From: 196Ikuchil <22634362+196Ikuchil@users.noreply.github.com> Date: Mon, 4 Apr 2022 21:10:19 +0900 Subject: [PATCH 08/14] Update content/ja/docs/concepts/security/controlling-access.md Co-authored-by: Toshiaki Inukai <82919057+t-inu@users.noreply.github.com> --- content/ja/docs/concepts/security/controlling-access.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/security/controlling-access.md b/content/ja/docs/concepts/security/controlling-access.md index 60d9495a02..605b1e2fd9 100644 --- a/content/ja/docs/concepts/security/controlling-access.md +++ b/content/ja/docs/concepts/security/controlling-access.md @@ -134,7 +134,7 @@ APIサーバーは、実際には2つのポートでサービスを提供する - 可能な限りこちらを使用してください。 - TLSを使用します。証明書は`--tls-cert-file`フラグで、鍵は`--tls-private-key-file`フラグで設定します。 - - デフォルトポートは6443です。`--secure-port`フラグで変更することができます。. + - デフォルトポートは6443です。`--secure-port`フラグで変更することができます。 - デフォルトのIPは、最初の非localhostのネットワークインターフェースです。`--bind-address`フラグで変更することができます。 - リクエストは、認証・認可モジュールによって処理されます。 - リクエストは、アドミッションコントロールモジュールによって処理されます。 From 31b82a7bd9b5aff4a6b4e289acf582dc067fa7fc Mon Sep 17 00:00:00 2001 From: 196Ikuchil <22634362+196Ikuchil@users.noreply.github.com> Date: Mon, 4 Apr 2022 21:13:39 +0900 Subject: [PATCH 09/14] Update content/ja/docs/concepts/security/controlling-access.md Co-authored-by: Toshiaki Inukai <82919057+t-inu@users.noreply.github.com> --- content/ja/docs/concepts/security/controlling-access.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/security/controlling-access.md b/content/ja/docs/concepts/security/controlling-access.md index 605b1e2fd9..4ca53beea6 100644 --- a/content/ja/docs/concepts/security/controlling-access.md +++ b/content/ja/docs/concepts/security/controlling-access.md @@ -80,7 +80,7 @@ Bobが次のようなリクエストをした場合、Bobは名前空間`project } ``` Bobが名前空間`projectCaribou`のオブジェクトに書き込み(`create`または`update`)のリクエストをした場合、承認は拒否されます。 -また、もしボブが`projectFish`のような別の名前空間にあるオブジェクトを読み込む(`get`)リクエストをした場合も、承認は拒否されます。 +また、もしBobが`projectFish`のような別の名前空間にあるオブジェクトを読み込む(`get`)リクエストをした場合も、承認は拒否されます。 Kubernetesの認可では、組織全体またはクラウドプロバイダー全体の既存のアクセスコントロールシステムと対話するために、共通のREST属性を使用する必要があります。 これらのコントロールシステムは、Kubernetes API以外のAPIとやり取りする可能性があるため、REST形式を使用することが重要です。 From 98f256137623c0458594883689db8fd47f466ca7 Mon Sep 17 00:00:00 2001 From: 196Ikuchil <196thinline@gmail.com> Date: Mon, 4 Apr 2022 21:25:03 +0900 Subject: [PATCH 10/14] fix:add auditing section --- .../docs/concepts/security/controlling-access.md | 16 +++++++++++----- 1 file changed, 11 insertions(+), 5 deletions(-) diff --git a/content/ja/docs/concepts/security/controlling-access.md b/content/ja/docs/concepts/security/controlling-access.md index 4ca53beea6..2f1f1f5ba7 100644 --- a/content/ja/docs/concepts/security/controlling-access.md +++ b/content/ja/docs/concepts/security/controlling-access.md @@ -14,7 +14,7 @@ APIアクセスには、人間のユーザーと[Kubernetesサービスアカウ ![Kubernetes APIリクエストの処理手順図](/images/docs/admin/access-control-overview.svg) -## トランスポート層のセキュリティ +## トランスポート層のセキュリティ {#transport-security} 一般的なKubernetesクラスターでは、APIはTLSで保護された443番ポートで提供されます。 APIサーバーは証明書を提示します。 この証明書は、プライベート認証局(CA)を用いて署名することも、一般に認知されているCAと連携した公開鍵基盤に基づき署名することも可能です。 @@ -23,7 +23,7 @@ APIサーバーは証明書を提示します。 クライアントは、この段階でTLSクライアント証明書を提示することができます。 -## 認証 +## 認証 {#Authentication} TLSが確立されると、HTTPリクエストは認証のステップに移行します。 これは図中のステップ**1**に該当します。 クラスター作成スクリプトまたはクラスター管理者は、1つまたは複数のAuthenticatorモジュールを実行するようにAPIサーバーを設定します。 @@ -41,7 +41,7 @@ Authenticatorについては、[認証](/ja/docs/reference/access-authn-authz/au Kubernetesはアクセスコントロールの決定やリクエストログにユーザー名を使用しますが、`User`オブジェクトを持たず、ユーザー名やその他のユーザーに関する情報をAPIはに保存しません。 -## 認可 +## 認可 {#Authorization} リクエストが特定のユーザーからのものであると認証された後、そのリクエストは認可される必要があります。 これは図のステップ**2**に該当します。 @@ -93,7 +93,7 @@ Kubernetesは、ABACモード、RBACモード、Webhookモードなど、複数 サポートされている認可モジュールを使用したポリシー作成の詳細を含む、Kubernetesの認可については、[認可](/docs/reference/access-authn-authz/authorization/)を参照してください。 -## アドミッションコントロール +## アドミッションコントロール {#admission-control} アドミッションコントロールモジュールは、リクエストを変更したり拒否したりすることができるソフトウェアモジュールです。 認可モジュールが利用できる属性に加えて、アドミッションコントロールモジュールは、作成または修正されるオブジェクトのコンテンツにアクセスすることができます。 @@ -111,8 +111,14 @@ Kubernetesは、ABACモード、RBACモード、Webhookモードなど、複数 リクエストがすべてのアドミッションコントローラーを通過すると、対応するAPIオブジェクトの検証ルーチンを使って検証され、オブジェクトストアに書き込まれます(図のステップ**4**に該当します)。 +## 監査 {#Auditing} -## APIサーバーのIPとポート +Kubernetesの監査は、クラスター内の一連のアクションを文書化した、セキュリティに関連する時系列の記録を提供します。 +クラスターは、ユーザー、Kubernetes APIを使用するアプリケーション、およびコントロールプレーン自身によって生成されるアクティビティを監査します。 + +詳しくは[監査](/docs/tasks/debug-application-cluster/audit/)をご覧ください。 + +## APIサーバーのIPとポート {#api-server-ports-and-ips} これまでの説明は、APIサーバーのセキュアポートに送信されるリクエストに適用されます(典型的なケース)。 APIサーバーは、実際には2つのポートでサービスを提供することができます。 From 4d8a3381e518a96c06e0fa27dba414ae4277df7d Mon Sep 17 00:00:00 2001 From: 196Ikuchil <196thinline@gmail.com> Date: Mon, 4 Apr 2022 21:27:33 +0900 Subject: [PATCH 11/14] fix:ja documentation --- content/ja/docs/concepts/security/controlling-access.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/security/controlling-access.md b/content/ja/docs/concepts/security/controlling-access.md index 2f1f1f5ba7..cf49a683be 100644 --- a/content/ja/docs/concepts/security/controlling-access.md +++ b/content/ja/docs/concepts/security/controlling-access.md @@ -116,7 +116,7 @@ Kubernetesは、ABACモード、RBACモード、Webhookモードなど、複数 Kubernetesの監査は、クラスター内の一連のアクションを文書化した、セキュリティに関連する時系列の記録を提供します。 クラスターは、ユーザー、Kubernetes APIを使用するアプリケーション、およびコントロールプレーン自身によって生成されるアクティビティを監査します。 -詳しくは[監査](/docs/tasks/debug-application-cluster/audit/)をご覧ください。 +詳しくは[監査](/ja/docs/tasks/debug-application-cluster/audit/)をご覧ください。 ## APIサーバーのIPとポート {#api-server-ports-and-ips} From c649f235f839af161ae89b31e4712194338d2964 Mon Sep 17 00:00:00 2001 From: 196Ikuchil <22634362+196Ikuchil@users.noreply.github.com> Date: Tue, 5 Apr 2022 22:56:23 +0900 Subject: [PATCH 12/14] Update content/ja/docs/concepts/security/controlling-access.md Co-authored-by: Toshiaki Inukai <82919057+t-inu@users.noreply.github.com> --- content/ja/docs/concepts/security/controlling-access.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/security/controlling-access.md b/content/ja/docs/concepts/security/controlling-access.md index cf49a683be..d1ef8f17bb 100644 --- a/content/ja/docs/concepts/security/controlling-access.md +++ b/content/ja/docs/concepts/security/controlling-access.md @@ -23,7 +23,7 @@ APIサーバーは証明書を提示します。 クライアントは、この段階でTLSクライアント証明書を提示することができます。 -## 認証 {#Authentication} +## 認証 {#authentication} TLSが確立されると、HTTPリクエストは認証のステップに移行します。 これは図中のステップ**1**に該当します。 クラスター作成スクリプトまたはクラスター管理者は、1つまたは複数のAuthenticatorモジュールを実行するようにAPIサーバーを設定します。 From f741c87d1ed9977d3954860e3cbfbfe15ca5338c Mon Sep 17 00:00:00 2001 From: 196Ikuchil <22634362+196Ikuchil@users.noreply.github.com> Date: Tue, 5 Apr 2022 22:56:34 +0900 Subject: [PATCH 13/14] Update content/ja/docs/concepts/security/controlling-access.md Co-authored-by: Toshiaki Inukai <82919057+t-inu@users.noreply.github.com> --- content/ja/docs/concepts/security/controlling-access.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/security/controlling-access.md b/content/ja/docs/concepts/security/controlling-access.md index d1ef8f17bb..74409b48d8 100644 --- a/content/ja/docs/concepts/security/controlling-access.md +++ b/content/ja/docs/concepts/security/controlling-access.md @@ -41,7 +41,7 @@ Authenticatorについては、[認証](/ja/docs/reference/access-authn-authz/au Kubernetesはアクセスコントロールの決定やリクエストログにユーザー名を使用しますが、`User`オブジェクトを持たず、ユーザー名やその他のユーザーに関する情報をAPIはに保存しません。 -## 認可 {#Authorization} +## 認可 {#authorization} リクエストが特定のユーザーからのものであると認証された後、そのリクエストは認可される必要があります。 これは図のステップ**2**に該当します。 From e80f838699de1e96a4d394de022c89f4b8fd9b0e Mon Sep 17 00:00:00 2001 From: 196Ikuchil <22634362+196Ikuchil@users.noreply.github.com> Date: Tue, 5 Apr 2022 22:56:43 +0900 Subject: [PATCH 14/14] Update content/ja/docs/concepts/security/controlling-access.md Co-authored-by: Toshiaki Inukai <82919057+t-inu@users.noreply.github.com> --- content/ja/docs/concepts/security/controlling-access.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/security/controlling-access.md b/content/ja/docs/concepts/security/controlling-access.md index 74409b48d8..914733d32c 100644 --- a/content/ja/docs/concepts/security/controlling-access.md +++ b/content/ja/docs/concepts/security/controlling-access.md @@ -111,7 +111,7 @@ Kubernetesは、ABACモード、RBACモード、Webhookモードなど、複数 リクエストがすべてのアドミッションコントローラーを通過すると、対応するAPIオブジェクトの検証ルーチンを使って検証され、オブジェクトストアに書き込まれます(図のステップ**4**に該当します)。 -## 監査 {#Auditing} +## 監査 {#auditing} Kubernetesの監査は、クラスター内の一連のアクションを文書化した、セキュリティに関連する時系列の記録を提供します。 クラスターは、ユーザー、Kubernetes APIを使用するアプリケーション、およびコントロールプレーン自身によって生成されるアクティビティを監査します。