はじめに
Kubernetesのドキュメントって英語だし、英検3級レベルで英語力のない私にはつらい・・・
そして、一回(google翻訳を使って)訳しながら読んでまた忘れてまた(google翻訳を使って)訳すを繰り返すのをやめたい。
調べるときは全文を見ずに、必要な部分だけを見てたりするので、公式ドキュメントを訳しながら全体を理解していこうと思う。
英語読むのめんどくせーーーとなっている人の助けになればと思い公開した
注意事項
- 基本的にGoogle翻訳のまんまです。
- 一応、意味が分かるようには訳してるつもりですが、ちょいちょい意味分からない部分もあります。
誤訳がある可能性があるので、最後はちゃんと公式ドキュメントを読みましょう - 私の知りたい部分からやるので、訳す部分はバラバラになります。
- 公式ドキュメントに記載されていない部分(自分で調べた部分とか)は_italic_で記載しています。
- V1.10でのドキュメントを記載
Master-Node communication
この文章は、マスター(本当のapiserver)とKubernetesクラスタ間の通信パスをカタログ化します。その目的は、ユーザーがインストールをカスタマイズして、信頼できないネットワーク(またはクラウドプロバイダーの完全なパブリックIP)でクラスタを実行できるようにネットワーク構成を強化することです。
Cluster -> Master
クラスタからマスタへの通信パスはAPIserverで終了します。(他のマスターコンポーネントのいずれもリモートサービスを公開しないように設計されています。)典型的なdeploymentでは、apiserverは1つまたは複数の形式のクライアント認証を有効にして、セキュアなHTTPSポート(443)でリモート接続を待機するように構成されています。特に匿名の要求またはサービスアカウントのトークンが許可されている場合は、1つ以上の認可の形式を有効にする必要があります。
ノードには、有効なクライアントの資格情報と共にapiserverに安全に接続できるように、クラスタのパブリックルート証明書をプロビジョニングする必要があります。たとえば、デフォルトのGCEデプロイメントでは、kubeletに提供されるクライアント証明書はクライアント証明書の形式になっています。kubeletクライアント証明書の自動プロビジョニングについては、kubelet TLS bootstrapping （リンク切れだった）
apiserverに接続したいPodはサービスアカウントを利用することで安全に行うことが出来るため、KubernetesはPodに公開ルート証明書と有効なベアラトークンをインスタンス化する際にPodに自動的に注入します。kubernetesサービス(全ての名前空間内)は、仮想IPアドレスで構成され、(kube-proxy経由で)apiserver上のHTTPSエンドポイントにリダイレクトされます。
また、マスターコンポーネントはセキュアポートを介してクラスタapiserverと通信します。
その結果、クラスタ(ノード上で動作するノードおよびポッド)からマスターへの通信のデフォルトの動作モードは、デフォルトで保護され、信頼できないネットワーク および/または パブリックネットワークで実行される可能性があります。
Master -> Cluster
マスター(apiserver)からクラスターへの2つの主要な通信パスがあります。1つ目は、クラスタ内の各ノードで実行されるapiserverからkubeletプロセスです。2つ目は、apiserverのプロキシ機能を使用して、apiserverから任意のノード、pod、またはサービスにアクセスすることです。
apiserver -> kubelet
apiserverからkubeletへの接続は、次の目的で使用されます。
- podのログを取得します。
- 実行中のpodに(kubectlを介して)接続する。
- kubeletのポート転送機能を提供します。
これらの接続は、kubeletのHTTPSエンドポイントで終了します。デフォルトでは、apiserverは、接続をman-in-the-middle攻撃の対象とするkubeletのサービング証明書を検証せず、信頼出来ないネットワークや公的なネットワーク上で実行することはunsafeです。
man-in-the-middle攻撃が何なのかよく分からなかったから一応調べた。
中間者攻撃のことだった。MITM attackとも呼ばれ、通信経路中に悪意の持った第三者が介入して、通信を傍受・改ざんするような攻撃のこと。
この接続を確認するには、--kubeletcertificate-authorityフラグを使用して、kubeletのサービス証明書の確認に使用するルート証明書バンドルをapiserverに提供します。
これが不可能な場合は、必要に応じてapiserverとkubeletの間でSSHトンネリングを使用して、信頼できないネットワークまたはパブリックネットワークに接続しないようにします。
最後にkublet APIを保護するために、Kubeletの認証および/または認可を有効にする必要があります。
apiserver -> nodes, pods, and services
apiserverからノード、pod、またはサービスへの接続はデフォルトのプレーンHTTP接続にデフォルトで設定されているため、認証も暗号化もされません。https:をAPI URLのノード,podまたはサービス名にプレフィックスすることで、セキュアなHTTPS接続を行うことは出来ませんが、HTTPSエンドポイントによって提供される証明書の検証やクライアントの認証情報の提供は行われないため、完全性を保証するものではありません。これらの接続は、現在、信頼できないネットワークや公的なネットワーク上で実行することは 安全ではありません。