この記事はWeChatの公開アカウント「趙華兵」から転載したものです。この記事を転載する場合は、趙華兵の公開アカウントにご連絡ください。
目次
Kubernetes コンポーネント認証 まず、Kubernetes のコンポーネントを見てみましょう。Kubernetes には、独立したプロセスとして実行される複数のコンポーネントが含まれています。これらのコンポーネントは、HTTP/GRPC を介して相互に通信し、クラスター内のアプリケーションの展開と管理を共同で完了します。 Kubernetes コンポーネント、画像ソース: kubernetes.io 図からわかるように、Kubernetes コントロール プレーンには、etcd、kube-api-server、kube-scheduler、kube-controller-manager などのコンポーネントが含まれています。これらのコンポーネントは相互にリモート呼び出しを行います。たとえば、kube-api-server は etcd インターフェースを呼び出してデータを保存し、kube-controller-manager は kube-api-server インターフェースを呼び出してクラスター内のオブジェクトのステータスを照会します。同時に、kube-api-server は動作ノード上の kubelet および kube-proxy とも通信し、動作ノード上でアプリケーションをデプロイおよび管理します。 上記コンポーネント間の相互呼び出しはすべてネットワークを介して実行されます。ネットワーク経由で通信する場合、悪意のある第三者が ID を偽造して情報を盗んだりシステムを攻撃したりするのを防ぐために、両者は互いの ID を確認する必要があります。お互いの身元を確認するには、通信の当事者のどちらかが次の 2 つのことを行う必要があります。
Kubernetes では、ID 証明を提供するためにデジタル証明書が使用されます。デジタル証明書は、日常生活で使用する「身分証明書」と簡単に理解できます。これには、名前、組織などの証明書所有者の身元情報が含まれています。証明書の権限を保証するために、通信する両方の当事者が信頼する CA (証明機関) を使用して証明書が発行されます。これは現実世界で「身分証明書」を発行する政府機関に似ています。デジタル証明書で最も重要なコンテンツは、実際には証明書所有者の公開キーであり、ユーザーの ID を表します。この記事では、読者がデジタル証明書と CA の基本原則をすでに理解していることを前提としています。これについてよくわからない場合、または関連する知識を確認したい場合は、まずこの記事「デジタル証明書の原則」(https://zhaohuabing.com/post/2020-03-19-pki)をお読みください。 CA (証明機関)、画像ソース www.trustauth.cn Kubernetes コンポーネントが相互に通信する場合、TLS を介してプロトコル レベルでデジタル証明書の検証が行われます。通信を確立するときに関連する証明書とキーを提供する以外に、アプリケーション レベルで特別な処理は必要ありません。認証に TLS を使用する方法は 2 つあります。
Kubernetes では、さまざまなコンポーネントによって提供されるインターフェースに、クラスターの内部情報が含まれています。これらのインターフェースに不正にアクセスされると、クラスターのセキュリティに影響が出るため、コンポーネント間の通信には相互 TLS 認証が必要です。つまり、クライアントとサーバーの両方が互いの ID 情報を検証する必要があります。 2 つのコンポーネントが双方向認証を実行する場合、次の証明書関連ファイルが関係します。
「TLS、X509、相互認証の魔法の説明」という記事からの次の図は、相互 TLS 認証の原理をわかりやすく説明しています。 TLS 認証の原理について詳しく知りたい場合は、Medium のオリジナル記事 (https://medium.com/sitewards/the-magic-of-tls-x509-and-mutual-authentication-explained-b2162dec4401) をお読みください。 画像ソース: TLS、X509、相互認証の魔法を解説 Kubernetes で使用される CA と証明書 Kubernetes では多くの証明書が使用されています。この記事では、考えられるすべての証明書を網羅するのではなく、主な証明書について説明します。これらの証明書の使用方法と動作理由を理解すれば、今後遭遇する可能性のある他の証明書ファイルについてもすぐに理解できるようになります。次の図は、Kubernetes で使用される主な証明書とその使用場所を示しています。 Kubernetesで使用される主な証明書 証明書には、上の画像のようにシリアル番号が付けられています。図中の矢印はコンポーネントの呼び出し方向を示しています。矢印の方向はサービス プロバイダーであり、もう一方の端はサービス呼び出し元です。 TLS 双方向認証を実装するには、サービス プロバイダーがサーバー証明書を使用し、サービス呼び出し元がクライアント証明書を提供し、両方の当事者が CA 証明書を使用して相手側が提供した証明書を検証する必要があります。簡潔にするために、上の図では、証明書ユーザーによって提供された証明書のみをマークし、証明書検証者によって使用される CA 証明書はマークしていません。図にマークされている証明書の機能は次のとおりです。
この図から、証明書のメカニズムに詳しい読者は、実際に複数の異なる CA を使用してこれらの証明書を発行できることがわかったかもしれません。相手側の証明書を検証するために使用される CA ルート証明書が通信コンポーネントで正しく構成されている限り、異なる CA を使用して異なる目的で証明書を発行できます。ただし、一般的には、Kubernetes クラスター内のすべての証明書を発行するには、統合 CA を使用することをお勧めします。これは、複数の CA を使用するよりも、クラスター ルート CA を使用する方が管理が容易だからです。複数の CA によって発生する複雑な証明書の構成と更新を回避し、誤った証明書の構成によって発生するクラスター障害を軽減できます。 Kubernetes での証明書の設定 先ほど、Kubernetes クラスターで使用される主な証明書を紹介しました。次に、これらの証明書とそれに対応する秘密鍵および CA ルート証明書を Kubernetes のさまざまなコンポーネントに構成して、各コンポーネントで使用する方法について説明します。ここでは、関連するすべての証明書を発行するためにクラスター ルート CA が使用されることを前提としています。したがって、CA 構成に対応する証明書ファイル名は同じになります。 etcd 証明書の設定 etcd 起動コマンドラインで次の証明書関連のパラメータを設定する必要があります。
kube-apiserver 証明書の設定 kube-apiserver で次の証明書関連のパラメータを設定する必要があります。
kubeconfig を使用して kube-apiserver にアクセスする kube-controller-mananger、kube-scheduler、kube-proxy、kubelet など、Kubernetes の各コンポーネントは、kubeconfig ファイルで構成された情報を使用して kube-apiserver にアクセスします。このファイルには、kube-apiserver のアドレス、kube-apiserver サーバー証明書を検証するための CA 証明書、独自のクライアント証明書と秘密鍵、およびその他のアクセス情報が含まれています。 minikube がインストールされたクラスターでは、生成される kubeconfig 構成ファイルは次のようになります。これら 4 つのファイルは、管理者ユーザー、kube-controller-mananger、kubelet、および kube-scheduler の kubeconfig 構成ファイルです。
controller-manager.conf を開いて確認してみましょう。
ご覧のとおり、kube-apiserver にアクセスするために必要な関連証明書の内容が、base64 エンコーディングを使用してファイルに書き込まれています。他のファイルの内容は、構成されたユーザー名とクライアント証明書が異なることを除いて同様です。 これらのコンポーネントを起動するときは、パラメータに kubeconfig ファイルのパスを指定する必要があります。例えば、kube-controller-manager の起動コマンドは以下のようになります。
サービスアカウント証明書 Kubernetes には、ユーザー アカウントとサービス アカウントの 2 種類のユーザーが存在します。サービス アカウントは主に、ポッドが kube-apiserver にアクセスするために使用されます。ポッドのサービス アカウントを指定すると、Kubernetes はサービス アカウントの JWT トークンを生成し、シークレットを使用してサービス アカウント トークンをポッドにロードします。ポッド内のアプリケーションは、サービス アカウント トークンを使用して API サーバーにアクセスできます。サービス アカウント証明書は、サービス アカウント トークンの生成と検証に使用されます。この証明書の使用方法は、公開鍵と秘密鍵が実際に使用され、証明書を検証する必要がないため、上で紹介した他の証明書とは異なります。 次に示すように、サービス アカウント証明書の公開キーと秘密キーは、それぞれ kube-apiserver と kube-controller-manager のコマンド ライン パラメーターで構成されていることがわかります。
次の図は、Kubernetes でサービス アカウント トークンを生成、使用、検証するプロセスを示しています。 認証方法: クライアント証明書またはトークン? 前回の紹介から、Kubernetes は 2 つのクライアント認証方法を提供していることがわかります。コントロール プレーン コンポーネントはクライアントのデジタル証明書を使用します。クラスターにデプロイされたアプリケーションはサービス アカウント トークンを使用します。 Kubernetes がサービス アカウントの証明書を生成して ID 認証に使用しないのはなぜですか?実際、これが Istio が行うことです。 Istio は各サービス アカウントの証明書を自動的に生成し、その証明書を使用してポッド内のアプリケーション間の双方向 TLS 認証を確立します。 Kubernetes でのこの設計上の決定についての説明は見つかりませんでしたが、理由をご存知でしたら教えてください。 Kubernetes 証明書の発行 Kubernetes は、構成された CA ルート証明書を使用してユーザー証明書を発行できる certificates.k8s.io API を提供します。この API は kube-controller-manager によって実装されており、証明書の発行に使用されるルート証明書は次のコマンドラインで構成されます。 Kubernetes がクラスター ルート CA を使用してユーザー証明書を発行することを期待しているため、kube-controller-manager のコマンド ライン パラメーターでクラスター ルート CA に関連するパラメーターを構成します。
Kubernetes 証明書署名 API の詳細については、「クラスターでの TLS 認証の管理」を参照してください。 TLS ブートストラップを使用して Kubelet 証明書の作成を簡素化する Kubernetes をインストールするときは、各ワーカー ノードで Kubelet の証明書を生成する必要があります。動作中のノードが多数ある場合があるため、Kubelet 証明書を手動で生成するプロセスは面倒です。この問題を解決するために、Kubernetes は TLS ブートストラップ (https://kubernetes.io/zh/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/) を提供し、Kubelet 証明書生成プロセスを簡素化します。原則としては、事前にブートストラップ トークンを提供し、それを介して kubelet が kube-apiserver の証明書発行 API を呼び出して必要な証明書を生成することです。この機能を有効にするには、kube-apiserver で --enable-bootstrap-token-auth を有効にし、kubelet が kube-apiserver にアクセスするために使用するブートストラップ トークン シークレットを作成する必要があります。 kubeadmin を使用してインストールする場合は、kubeadm token create コマンドを使用してトークンを作成できます。 TLS ブートストラップを使用して証明書を生成するプロセスは次のとおりです。
まとめ Kubernetes は、クラスターのセキュリティを確保するために多数の証明書を使用します。これらの証明書の目的と構成を理解することで、Kubernetes のインストール プロセスとコンポーネント構成をより深く理解できるようになります。この記事は、私が学習する過程でまとめた、Kubernetes クラスターで使用される主な証明書の概要です。 Kubernetes に関する私の理解が限られているため、この記事にはいくつかの誤りが避けられません。訂正していただいても結構です。 参照ドキュメント Kubernetes PKI 証明書と要件 (https://kubernetes.io/en/docs/setup/best-practices/certificates/) Kubernetes の難しい方法 (https://github.com/kelseyhightower/kubernetes-the-hard-wa) Kubernetes バイナリのインストール (パート 2) 証明書の詳細 (https://blog..com/13210651/2361208) TLS ブートストラップ (https://kubernetes.io/zh/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/) デジタル証明書の原則 (https://zhaohuabing.com/post/2020-03-19-pki/) |
>>: クラウドとSaaSのセキュリティには包括的なアプローチが必要
オンラインプロモーションの一環としての SEO 最適化は、Web サイトとユーザーをつなぐ重要なリン...
アマゾン ウェブ サービスは、神州太悦がアマゾン ウェブ サービスの世界的な優位性に依拠し、深い技術...
hostusは、2018年7月28日に、中国内外で初めて、hostus香港VPSに関するニュースを発...
一方で、百度は積極的に新しい百度最適化ガイドを編纂しており、他方では、百度は自社製品の脱SEO化を強...
chicagovps.net は、低価格の VPS を提供することで有名な、VPS 業界の英雄的な企...
文/劉燕青「アリババは今、大変な状況に陥っている!」5月28日、国家食品医薬品監督管理局(以下、「C...
1. FacebookのIPO失敗の影響が深刻化:証券会社3社が巨額の損失を主張新浪科技は北京時間5...
k8s でアプリケーションを公開するには 2 つの方法があります。 Kubernetesダッシュボー...
Photonvps は全品 50% オフ。この機会をお見逃しなく。クーポンコード: HALFOFF ...
gigsgigscloudは、CN2 GIA(中国方面はcera提供の50Gbps防御)と国際方面は...
Baiduはウェブサイトのコンテンツを数秒で収集しますが、ホームページはランク付けされませんもちろん...
元宵節にGoogleから弊社に「大きなプレゼント」が届きました。まさに青天の霹靂でした。Google...
crocweb はカナダの中小規模のホスティング会社で、評判はよく知られています。同社のホストは純粋...
今月、boltvm がリリースされたとき、KVM ベースの仮想 VPS が正式に開始され、データセン...
4月末現在、hostkvmは香港クラウドVPS+日本VPS+シンガポールVPSを30%割引、香港CN...