add docs/concepts/security/api-server-bypass-risks.md

Translate docs/concepts/security/api-server-bypass-risks.md into Japanese

content/ja/docs/concepts/security/api-server-bypass-risks.md

@@ -0,0 +1,81 @@
+---
+title: Kubernetes API サーバーのバイパスリスク
+description: >
+  APIサーバーおよびその他のコンポーネントに関するセキュリティアーキテクチャ情報
+content_type: concept
+weight: 90
+---
+
+<!-- overview -->
+
+Kubernetes APIサーバーは、外部のユーザーやサービスがクラスターにアクセスするためのメインエントリーポイントです。
+
+この役割の一環として、APIサーバーには監査ログや{{< glossary_tooltip text="アドミッションコントローラー" term_id="admission-controller" >}}など、いくつかの重要なセキュリティ制御が組み込まれています。しかし、これらの制御をバイパスしてクラスターの構成やコンテンツを変更する方法も存在します。
+
+このページでは、Kubernetes APIサーバーに組み込まれたセキュリティ制御をどのようにバイパスできるかについて説明し、クラスター管理者やセキュリティアーキテクトがこれらのバイパスが適切に制限されていることを確認できるようにします。
+
+<!-- body -->
+
+## スタティックPod {#static-pods}
+
+各ノードの{{< glossary_tooltip text="kubelet" term_id="kubelet" >}}は、指定されたディレクトリに保存されたマニフェストや特定のURLから取得したマニフェストを[**スタティック Pod**](/ja/docs/tasks/configure-pod-container/static-pod)としてロードして直接管理します。APIサーバーはこれらのスタティックPodを管理しません。書き込み権限を持つ攻撃者がこの場所にアクセスできる場合、スタティックPodの設定を変更したり、新しいスタティックPodを追加することが可能です。
+
+スタティックPodはKubernetes APIの他のオブジェクトにアクセスできません。例えば、クラスター内のSecretをマウントするような設定はできません。しかし、これらのPodは、基盤となるノードからhostPathマウントを使用するなど、他のセキュリティに敏感な操作を実行することができます。
+
+デフォルトでは、kubeletは{{< glossary_tooltip text="ミラー Pod" term_id="mirror-pod">}}を作成して、スタティックPodがKubernetes APIに表示されるようにします。しかし、攻撃者がPodを作成する際に無効なネームスペース名を使用した場合、そのPodはKubernetes APIに表示されず、影響を受けたホストにアクセスできるツールでしか検出できません。
+
+スタティックPodがアドミッションコントロールに失敗した場合、kubeletはPodをAPIサーバーに登録しませんが、Podはノード上で実行されます。詳細については、[kubeadm issue #1541](https://github.com/kubernetes/kubeadm/issues/1541#issuecomment-487331701).
+を参照してください。
+
+### 緩和策 {#static-pods-mitigations}
+
+- ノードに必要な場合のみ[kubeletのスタティックPodマニフェスト機能を有効にする](/docs/tasks/configure-pod-container/static-pod/#static-pod-creation)。
+- スタティックPod機能を使用するノードでは、スタティックPodマニフェストディレクトリやURLへのファイルシステムアクセスを、アクセスが必要なユーザーに制限する。
+- kubeletの設定パラメータやファイルへのアクセスを制限し、攻撃者がスタティックPodのパスやURLを設定できないように防ぎます。
+- スタティックPodマニフェストやkubelet設定ファイルをホストするディレクトリやWebストレージへのアクセスを定期的に監査し、集中報告する。
+
+## The kubelet API {#kubelet-api}
+
+kubeletは、通常クラスターのワーカーノードでTCPポート10250で公開されているHTTP APIを提供します。Kubernetesディストリビューションによっては、コントロールプレーンノードでもAPIが公開されている場合があります。このAPIへの直接アクセスにより、ノード上で実行されているPodの情報、Podのログ、および各コンテナ内でのコマンド実行が可能になります。
+
+KubernetesクラスターのユーザーがNodeオブジェクトのサブリソースへのRBACアクセスを持つ場合、そのアクセスはkubelet APIとのやり取りを許可するものと見なされます。許可されたサブリソースアクセスに応じて、詳細なアクセス権が変わります。詳細は[kubeletの認可](/docs/reference/access-authn-authz/kubelet-authn-authz/#kubelet-authorization)を参照してください。
+
+kubelet APIへの直接アクセスはアドミッションコントロールの対象ではなく、Kubernetesの監査ログにも記録されません。攻撃者がこのAPIへの直接アクセスを持つと、特定のアクションを検出または防止する制御をバイパスできる可能性があります。
+
+kubelet APIは、さまざまな方法でリクエストを認証するように設定できます。デフォルトでは、kubeletの設定は匿名アクセスを許可しています。ほとんどのKubernetesプロバイダーは、デフォルトでウェブフックおよび証明書認証を使用するように変更しています。これにより、コントロールプレーンが呼び出し元が`nodes` APIリソースやサブリソースにアクセスする権限を持っているかどうかを確認します。デフォルトの匿名アクセスでは、このような確認が行われません。
+
+### 緩和策 {#mitigations}
+
+- [RBAC](/docs/reference/access-authn-authz/rbac/)などのメカニズムを使用して、nodes APIオブジェクトのサブリソースへのアクセスを制限する。このアクセスは、監視サービスなど必要な場合にのみ付与する。
+- kubeletポートへのアクセスを制限する。指定された信頼できるIPアドレス範囲のみがポートにアクセスできるようにする。
+- [kubelet認証](/docs/reference/access-authn-authz/kubelet-authn-authz/#kubelet-authentication)をウェブフックまたは証明書モードに設定することを確認する。
+- 認証されていない「読み取り専用」kubeletポートがクラスターで有効になっていないことを確認する。
+
+## The etcd API
+
+Kubernetesクラスターは、etcdをデータストアとして使用しています。`etcd`サービスはTCPポート2379で待ち受けています。このAPIにアクセスする必要があるのは、Kubernetes APIサーバーおよびバックアップツールのみです。直接アクセスすることで、クラスター内のデータを開示または変更することが可能になります。
+
+etcd APIへのアクセスは通常、クライアント証明書認証によって管理されます。etcdが信頼する認証局から発行された任意の証明書は、etcd内に保存されているデータへの完全なアクセスを許可します。
+
+etcdへの直接アクセスはKubernetesのアドミッションコントロールの対象ではなく、Kubernetesの監査ログにも記録されません。攻撃者がAPIサーバーのetcdクライアント証明書の秘密鍵を取得した場合(または新しい信頼できるクライアント証明書を作成できる場合)、クラスターのSecretへのアクセスやアクセスルールの変更によって、クラスター管理者権限を取得することができます。Kubernetes RBAC権限を引き上げなくても、etcdを操作できる攻撃者は任意のAPIオブジェクトを取得したり、新しいワークロードをクラスター内に作成したりすることができます。
+
+多くのKubernetesプロバイダーは、etcdに相互TLS(クライアントとサーバーがそれぞれの証明書を検証する認証方式)を使用するように設定しています。etcd APIには認可の機能もありますが、広く受け入れられている実装は存在しません。したがって、etcdクライアントへのアクセス権を持つ証明書があれば、etcdへの完全なアクセスが可能です。通常、ヘルスチェックにのみ使用されるetcdクライアント証明書も、完全な読み書きアクセスを許可する可能性があります。
+
+### 緩和策 {#etcd-api-mitigations}
+
+- etcdが信頼する認証局を最小限にする。通常、APIサーバーのみがこのCAで署名されたクライアント証明書を使用できるようにする。
+- etcdのクライアント証明書や鍵へのアクセスを、厳重に制限する。
+- クラスター内のどのコンポーネントがどのクライアント証明書を使用しているかを定期的に確認する。
+
+## コンテナランタイムソケット {#runtime-socket}
+
+Kubernetesクラスターの各ノードでは、コンテナと対話するためのアクセスがコンテナランタイムによって制御されています。複数のコンテナランタイムを設定している場合もあります。通常、コンテナランタイムはkubeletがアクセスできるUnixソケットを公開します。このソケットにアクセスできる攻撃者は、新しいコンテナを起動したり、実行中のコンテナと対話したりすることができます。
+
+クラスターレベルでは、このアクセスの影響は、侵害されたノード上で実行されているコンテナがSecretsやその他の機密データにアクセスできるかどうかによって異なります。攻撃者がこれらのデータを利用して他のワーカーノードやコントロールプレーンコンポーネントの権限をエスカレートする可能性があります。
+
+### 緩和策 {#runtime-socket-mitigations}
+
+- コンテナランタイムソケットへのファイルシステムアクセスを厳格に制御します。可能であれば、このアクセスを`root`ユーザーのみに制限します。
+- ノード上で実行されている他のコンポーネントからkubeletを隔離するために、Linuxカーネルの名前空間などのメカニズムを使用します。
+- コンテナランタイムソケットを含む[`hostPath`マウント](/docs/concepts/storage/volumes/#hostpath)の使用を制限または禁止します。これには、コンテナランタイムソケットを直接含むものや親ディレクトリをマウントするものが含まれます。また、`hostPath`マウントは読み取り専用に設定し、ディレクトリ制限を回避するリスクを軽減します。
+- ノードへのユーザーアクセスを制限し、特にスーパーユーザーアクセスを制限します。