Kubernetes クラスタのセキュリティメカニズムの詳細な説明

[[320833]]

この記事では、Kubernetes のセキュリティ メカニズムを中心に、一連の概念、技術的なポイント、メカニズムを使用してクラスター アクセスのセキュリティを確保する方法について説明します。関連するキーワードは、api-server、認証、承認、アドミッション コントロール、RBAC、サービス アカウント、クライアント証明書認証、Kubernetes ユーザー、トークン認証などです。関連する技術的なポイントは些細で数多くありますが、メカニズム全体を理解した後はそれらを簡単につなげることができるため、Kubernetes クラスターのセキュリティ メカニズムを十分に理解できます。

Kubernetes API サーバーの安全なアクセス メカニズム

kube-apiserver は、Kubernetes クラスター全体と REST API サービスへの入り口です。提供される API は、さまざまな Kubernetes リソース オブジェクト (Pod、RC、Service など) の追加、削除、変更、クエリを実装します。 API サーバーは、クラスター内のさまざまな機能モジュール間の相互作用と通信のハブでもあり、クラスター全体のバスとデータ センターでもあります。

これは API サーバーの重要性を示しています。クラスターと対話するには、kubectl、さまざまな言語で提供されるクライアント ライブラリを使用するか、REST リクエストを送信します。実際、基盤となるレイヤーは、HTTP REST リクエストの形式で API サーバーと対話します。では、アクセスのセキュリティ メカニズムはどのように保証されるのでしょうか?いかなるリクエストも受け入れて対応することは不可能です。 API サーバーは、独自の柔軟なセキュリティ メカニズムを提供します。各リクエストが API サーバーに到達すると、認証 -> 承認 -> アドミッション コントロールの 3 つのセキュリティ レベルを通過します。以下の 3 つのセキュリティ レベルを通過したリクエストにのみ応答します。

認証

認証段階の作業は、ユーザーの ID を識別することです。 HTTP ベース、HTTP トークン、TLS、サービス アカウント、OpenID Connect など、サポートされている認証方法は多数あります。API サーバーの起動時に、複数の認証方法を同時に指定することができ、これらの方法はクライアント要求を認証するために 1 つずつ使用されます。いずれかの認証方法が渡される限り、API サーバーは認証が成功したとみなします。 Kubernetes の上位バージョンのデフォルトの認証方法は TLS です。 TLS 認証スキームでは、各ユーザーは独自の X.509 クライアント証明書を持ち、API サーバーは構成された証明機関 (CA) を通じてクライアント証明書を検証します。

承認

承認段階では、リクエストに対応する権限があるかどうかが判断されます。認証方法には、AlwaysDeny、AlwaysAllow、ABAC、RBAC、Node など、多数あります。API サーバーの起動時に複数の認証モードが同時に有効になっている場合、Kubernetes はすべてのモジュールをチェックします。いずれかが承認された場合、リクエストは承認されます。すべてのモジュールが拒否された場合、要求は拒否されます (HTTP ステータス コード 403)。 Kubernetes の上位バージョンで有効になっているデフォルトの認証方法は、RBAC と Node です。

入場管理

アドミッション コントロールは、操作がクラスターの要件を満たしているかどうかを判断します。アドミッション コントロールには、「アドミッション コントローラー」のリストが装備されています。 API サーバーに送信される各リクエストは、各アドミッション コントローラーのチェックに合格する必要があります。チェックが失敗した場合、API サーバーは呼び出し要求を拒否します。これは、Web プログラミングのインターセプターに少し似ています。具体的な詳細はここでは説明しません。詳細については、「Admission Controllers の使用」を参照してください。

Kubernetes 認証方法: クライアント証明書 (TLS)

前のセクションで見たように、Kubernetes を認証する方法は多数あります。ここでは、HTTPS 双方向認証とも呼ばれるクライアント証明書 (TLS) 認証方法について簡単に説明します。通常、https ウェブサイトにアクセスする場合、認証は一方向で行われます。サーバーの ID を検証するのはクライアントのみであり、サーバーはクライアントの ID を気にしません。 HTTPS ハンドシェイク プロセス (一方向認証) を見てみましょう。

1. クライアントはサーバーに Client Hello メッセージを送信します。
2. サーバーは Server Hello メッセージと独自の証明書をクライアントに返信します。
3. クライアントはサーバーの証明書の正当性をチェックします。証明書のチェックに合格すると、両者から送信されたメッセージに基づいてプレマスター キーが生成され、サーバーの証明書内の公開キーを使用してプレマスター キーが暗号化され、サーバーに送信されます。
4. サーバーは独自の秘密鍵を使用してプレマスター キーを復号化し、両者がネゴシエートしたアルゴリズムと交換されたメッセージを通じてセッション キーを生成し (この対称鍵は両者間の後続のデータ暗号化に使用され、クライアントも同じ方法で同じ鍵を生成できます)、ハンドシェイクの終了を示すメッセージをクライアントに返信します。後続のメッセージはネゴシエートされた対称キーで暗号化されます。

HTTPS 双方向認証のプロセスは、上記のステップ 3 で同時に独自の証明書を使用してサーバーに応答し、次にサーバーがステップ 4 で受信したクライアント証明書の正当性を検証することで、クライアントの検証の目的を達成します。これは、関連する CA 証明書が自己署名されていることを除いて、Kubernetes で使用されるメカニズムです。

Kubernetes の認可方式 RBAC の紹介

ロールベースのアクセス制御 (RBAC) は Kubernetes によって提供される認証戦略であり、新しいクラスターでもデフォルトで有効になっています。 RBAC はロールをロール バインディングから分離します。ロールとは、クラスター リソースを操作するための定義済みの権限のセットを指します。一方、ロール バインディングは、ロールをユーザー、グループ、またはサービス アカウント エンティティにバインドし、それによってこれらのエンティティに権限を付与します。 RBAC 認証方法は非常に柔軟であることがわかります。エンティティに権限を付与するには、対応するロールをバインドするだけです。 RBAC メカニズムの場合、Kubernetes は Role、ClusterRole、RoleBinding、ClusterRoleBinding の 4 つの API リソースを提供します。

ロール: 単一の名前空間内のリソースへのアクセスを許可するためにのみ使用できるため、定義時に名前空間を指定する必要があります。次の例は、Pod への読み取りアクセスを許可するために使用される、デフォルトの名前空間内の Role オブジェクトの定義を示しています。

種類: 役割
 
 apiバージョン: rbac。認証.k8s.io/v1beta1 
 
メタデータ: 
 
名前空間:デフォルト  
 
名前: ポッドリーダー
 
ルール: 
 
 - apiGroups: [ "" ] # 空の文字列""はコアAPIグループの使用を示します  
 
リソース: [ "ポッド" ] 
 
動詞: [ 「取得する」 、 「見る」 、 「一覧表示する」 ]

ClusterRole: クラスター全体のリソースにアクセスできるクラスター全体のロール。次の ClusterRole 定義の例は、特定の名前空間またはすべての名前空間 (バインド方法によって異なります) のシークレットへの読み取りアクセス権をユーザーに付与するために使用できます。

種類: ClusterRole 
 
 apiバージョン: rbac。認証.k8s.io/v1beta1 
 
メタデータ: 
 
 # ClusterRoleはクラスタ全体のオブジェクトなので、ここで「namespace」フィールドを定義する必要はありません。 
 
名前: シークレットリーダー
 
ルール: 
 
 -apiグループ: [ "" ] 
 
リソース: [ "秘密" ] 
 
動詞: [ 「取得する」 、 「見る」 、 「一覧表示する」 ]

RoleBinding: ロールをユーザー エンティティにバインドし、名前空間内でユーザー エンティティにアクセス許可を付与します。また、ClusterRole をユーザー エンティティにバインドすることもサポートします。次の例で定義されている RoleBinding オブジェクトは、デフォルトの名前空間でユーザー jane に pod-reader ロールを付与します。この承認により、ユーザー jane はデフォルトの名前空間から Pod を読み取ることができます。

 # 次のロールバインディング定義により、ユーザー「jane」は「default」名前空間からPod を読み取ることができます。 
 
種類: RoleBinding 
 
 apiバージョン: rbac。認証.k8s.io/v1beta1 
 
メタデータ: 
 
名前:読み取りポッド
 
名前空間:デフォルト  
 
科目: 
 
 - 種類:ユーザー  
 
名前: ジェーン
 
 apiGroup : rbac.authorization.k8s.io 
 
ロールリファレンス: 
 
種類: 役割
 
名前: ポッドリーダー
 
 apiGroup : rbac.authorization.k8s.io

ClusterRoleBinding: ClusterRole をユーザー エンティティにバインドし、ユーザー エンティティにクラスター全体の権限を付与します。次の例で定義されている ClusterRoleBinding により、ユーザー グループ マネージャー内のすべてのユーザーがクラスター内の任意の名前空間のシークレットを読み取ることができるようになります。

 # 次の `ClusterRoleBinding` オブジェクトは、ユーザー グループ"manager"内のすべてのユーザーがクラスター内の任意の名前空間のシークレットを読み取ることを許可します。 
 
種類: ClusterRoleBinding 
 
 apiバージョン: rbac。認証.k8s.io/v1beta1 
 
メタデータ: 
 
名前:読み取り-secrets-グローバル  
 
科目: 
 
 - 種類:グループ  
 
名前: マネージャー
 
 apiGroup : rbac.authorization.k8s.io 
 
ロールリファレンス: 
 
種類: ClusterRole 
 
名前: シークレットリーダー
 
 apiGroup : rbac.authorization.k8s.io

RBAC の詳細な説明については、こちらをご覧ください: https://jimmysong.io/kubernete ... .html

Kubernetes の 2 つのアカウント タイプの概要

Kubernetes には、サービス アカウントと通常のユーザーの 2 種類のユーザーが存在します。 ServiceAccount は Kubernetes によって管理されますが、ユーザー アカウントは外部で管理されます。 Kubernetes はユーザー リストを保存しません。つまり、ユーザーの追加、削除、追加、およびクエリはすべてクラスターの外部で実行されます。 Kubernetes 自体は一般ユーザー向けの管理機能を提供しません。

2 つのアカウントの違い:

• ServiceAccount は Kubernetes の内部リソースですが、通常のユーザーは Kubernetes の外部に存在します。
• ServiceAccount はグローバルではなく特定の名前空間に属しますが、通常のユーザーはグローバルであり、特定の名前空間に固有ではありません。
• ServiceAccount は通常、クラスター内の Pod プロセスが api-server と対話するために使用されますが、通常のユーザーは通常、kubectl または REST リクエストに使用されます。

ServiceAccount の動作

ServiceAccount は Pod が api-server にアクセスするために使用でき、対応する Token は kubectl がクラスターにアクセスしたり kubernetes ダッシュボードにログインしたりするために使用できます。

一般ユーザー向けの実用的なアプリケーション

• X509 クライアント証明書。 API サーバーに --client-ca-file=xxx オプションを指定すると、クライアント証明書の検証が有効になります。 API サーバーはこの ca ファイルを使用して、API リクエストに含まれるクライアント証明書の有効性を検証します。検証が成功すると、API サーバーはクライアント証明書のサブジェクトの CN 属性をこのリクエストのユーザー名として使用します。後ほど、クライアント証明書方式のユーザー向けに特別な実践的な紹介があります。
• 静的トークン ファイル。--token-auth-file=SOMEFILE オプションを指定して、ベアラー トークン認証を有効にします。参照されるファイルは、トークン、ユーザー名、およびユーザー ID を含む csv ファイルです。リクエスト時に、Authorization: Bearer xxx ヘッダー情報を指定して、ベアラー トークンの認証に合格します。
• 静的パスワード ファイル。 --basic-auth-file=SOMEFILE オプションを指定してパスワード認証を有効にします。参照されるファイルは、パスワード、ユーザー名、およびユーザー ID を含む csv ファイルです。リクエスト時に、Authorization ヘッダーを Basic BASE64ENCODED(USER:PASSWORD) に設定する必要があります。

練習: クライアント証明書認証に基づいてクラスターにアクセスするための新しい Kubeconfig を作成する

Kubeconfig ファイルの詳細な説明

Kubernetes クラスターをインストールすると、$HOME/.kube/config ファイルが生成されることがわかります。このファイルは、kubectl コマンドライン ツールがクラスターにアクセスするために使用する認証ファイルであり、Kubeconfig ファイルとも呼ばれます。この Kubeconfig ファイルには多くの重要な情報が含まれています。ファイル構造は以下のとおりです。各フィールドの意味は次のとおりです。

 APIバージョン: v1 
 
クラスター: 
 
 - クラスター: 
 
証明書機関データ: ... 
 
サーバー: https://192.168.26.10:6443 
 
名前: Kubernetes 
 
コンテキスト: 
 
 - コンテクスト： 
 
クラスター: Kubernetes 
 
ユーザー: kubernetes-admin 
 
名前: kubernetes-admin@kubernetes 
 
現在のコンテキスト: kubernetes-admin@kubernetes 
 
種類: 設定
 
設定: {} 
 
ユーザー: 
 
 -名前: kubernetes-admin 
 
ユーザー: 
 
クライアント証明書データ: ... 
 
クライアント-キー -データ: ...

ファイルはクラスター、コンテキスト、ユーザーの 3 つの部分に分かれていることがわかります。

クラスターセクション

api-server アドレス、certificate-authority-data: サーバー側証明書認証用の自己署名 CA ルート証明書 (マスター ノードの /etc/kubernetes/pki/ca.crt ファイルの内容) などのクラスター情報を定義します。

コンテキストセクション

クラスター情報とユーザーのバインド。 kubectl はコンテキストによって提供される情報を通じてクラスターに接続します。

ユーザーセクション

ユーザータイプは複数あります。デフォルトは、クライアント証明書 (x.509 標準証明書) と証明書の秘密キーです。 ServiceAccount トークンにすることもできます。ここでは前者に焦点を当てます。

• client-certificate-data: base64 で暗号化されたクライアント証明書。
• client-key-data: base64 で暗号化された証明書の秘密キー。

リクエストが api-server の認証レベルを通過すると、api-server は受信したクライアント証明書からユーザー情報を取得し、それを後続の承認レベルで使用します。ここでのユーザーはサービス アカウントではなく、クライアント証明書のサブジェクト情報です。O はユーザー グループを表し、CN はユーザー名を表します。これを証明するには、openssl を使用して証明書からこの情報を手動で取得します。

まず、Kubeconfig 証明書のユーザー部分の client-certificate-data フィールドを base64 で復号化し、ファイルを client.crt として保存します。次に、openssl を使用して証明書情報を解析し、S​​ubject 情報を確認します。

 openssl x509- in client.crt-text

クラスターのデフォルトの Kubeconfig クライアント証明書を解析して取得されるサブジェクト情報は次のとおりです。

件名: O=system:masters、CN=kubernetes-admin

証明書にバインドされているユーザー グループは system:masters であり、ユーザー名は kubernetes-admin であることがわかります。デフォルトでは、クラスター内に cluster-admin という ClusterRoleBinding があり、cluster-admin という名前の ClusterRole をユーザー グループ system:masters にバインドします。 cluster-admin という名前の ClusterRole には、クラスター全体のスーパー管理者権限があります。これにより、デフォルトの Kubeconfig が Kubernetes クラスターを操作するための非常に高い権限を持つことができる理由が説明されます。

読み取り専用権限を持つ新しい Kubeconfig ファイルを作成する

デフォルトの Kubeconfig ファイルに、Linux システムのルート権限に似た高レベルの権限であるスーパー管理者権限が付与されている理由については、上記で説明しました。場合によっては、R&D 担当者がポッドのステータス、ログ、その他の情報を表示できるようにするなど、クラスターのアクセス権限を他の人に公開することがあります。現時点では、システムのデフォルトの Kubeconfig を直接使用することは合理的ではありません。権限が大きすぎるため、クラスターのセキュリティが保証されません。より合理的なアプローチは、クラスターでの誤った操作による誤動作を回避するために、R&D 担当者に読み取り専用権限を持つアカウントを付与することです。

クライアント証明書認証を使用して Kubeconfig ファイルを作成するため、クラスターの自己署名 CA (マスター ノード) から証明書を申請し、RBAC 認証を通じて証明書ユーザーにクラスターへの読み取り専用権限を付与する必要があります。具体的な方法は以下の通りです。

証明書の申請時に、証明書のユーザー名を -subj オプションの developer – CN パラメータに設定すると仮定します。

1. 証明書の秘密鍵を作成します。

 openssl genrsa -アウト開発者。キー2048

2. 上記の秘密キーを使用して csr (証明書署名要求) ファイルを作成します。このファイルでは、件名にユーザー情報を入力する必要があります (CN はユーザー名、O はユーザー グループです)。

 openssl req -new -キー開発者。キー- out developer.csr -subj "/CN=developer"  

/O パラメータは複数回出現できます。つまり、複数のユーザー グループが存在する可能性があります。

3. Kubernetes クラスター (API サーバー) の CA ルート証明書ファイルを見つけます。その場所は、クラスターのインストール方法によって異なります。通常、マスターノードの /etc/kubernetes/pki/ パスにあります。ファイルは 2 つあり、1 つは CA ルート証明書 (ca.crt)、もう 1 つは CA 秘密キー (ca.key) です。

4. クラスターの CA ルート証明書と手順 2 で作成した csr ファイルを使用して、ユーザーに証明書を発行します。

 openssl x509 -req - developer.csr内-CA /etc/kubernetes/pki/ca.crt -CAkey /etc/kubernetes/pki/ca。キー-CAcreateserial -出力developer.crt - 日数 365

この時点で、クライアント証明書が発行されます。後で使用するファイルは、developer.keyとdeveloper.crtです。

RBAC認証に基づいてユーザーに読み取り専用権限を付与する

Kubernetes クラスターには、view という名前のデフォルトの読み取り専用の ClusterRole が既に存在します。 ClusterRole を開発者ユーザーにバインドするだけです。

 kubectlクラスターロールバインディング kubernetes-viewer --clusterrole=view --user=developer を作成します。  

クライアント証明書に基づいて Kubeconfig ファイルを生成する

クライアント証明書は以前に生成されており、証明書内のユーザーにはクラスターの読み取り専用権限が付与されています。次に、クライアント証明書に基づいて Kubeconfig ファイルを生成します。

$HOME/.kube.config をコピーし (developer-config という名前であると仮定)、それに基づいて変更を加えます。

1. contexts セクションで、user フィールドが developer に変更され、name フィールドが developer@kubernetes に変更されます。 (一貫性がある限り、これらの変更には任意の名前を付けることができます);

2. ユーザー セクションの name フィールドが developer に変更され、client-certificate-data フィールドが developer.crt の base64 で暗号化されたコンテンツに変更され、client-key-data が developer.key の base64 で暗号化されたコンテンツに変更されます。

注: 証明書をbase64で暗号化する場合は、--wrap=0パラメータを指定します。

• 猫開発者.crt | base64 –ラップ=0
• cat 開発者キー | base64 –ラップ=0

次に、新しく作成した Kubeconfig ファイルの使用をテストします。

 [root@master ~]# kubectl –kubeconfig developer-config –context=developer@kubernetes ポッドを取得します
 
名前準備完了 ステータス 再起動 年齢
 
 nginx-deployment-5754944d6c-dqsdj 1/1 実行中 0 5d9h 
 
 nginx-deployment-5754944d6c-q675s 1/1 実行中 0 5d9h 
 
 [root@master ~]# kubectl –kubeconfig developer-config –context=developer@kubernetesポッド nginx-deployment-5754944d6c-dqsdjを削除します
 
サーバーからのエラー (禁止): ポッド「nginx-deployment-5754944d6c-dqsdj」は禁止されています:ユーザー「developer」は、名前空間「 default 」のAPIグループ「」内のリソース「pods」を削除できません

新しく作成された Kubeconfig ファイルが使用可能であり、書き込み権限が禁止されていることが分かります。これは、先ほど設定した RBAC 権限メカニズムが有効になっていることを意味します。

練習: Kubeconfig またはトークンを使用して Kubernetes ダッシュボードにログインする

Kubernetes ダッシュボードのアクセス アドレスを開くと、最初にログイン認証ページが表示されます。選択できるログイン認証方法は、Kubeconfig とトークンの 2 つです。

実際、どちらの方法でもサービス アカウントのトークンが必要です。 Kubeconfig 方式の場合、ファイルに Token フィールドがないため、クラスターのデフォルトの Kubeconfig: $HOME/.kube/config ファイルを直接使用してログインすることはできません。そのため、ローカルの Kubeconfig ファイルを直接選択してログインすると、エラーが報告されます。正しい使用方法は、サービス アカウントのトークンを取得し、そのトークンを $HOME/.kube/config ファイルに追加することです。ダッシュボードにログインする具体的な方法は次の 2 つです。

準備

まず、どちらの方法もサービス アカウントが必要なので、最初にサービス アカウントを作成し、次にテスト用にこのサービス アカウントに表示権限 (RBAC 承認) を付与します。ダッシュボードにログインすると、クラスター内のリソースを表示することはできますが、変更することはできません。

1. サービス アカウントを作成します (デフォルトの名前空間内)。

 kubectlサービスアカウントを作成します。kube-dashboard-reader

2. システムに組み込まれている ClusterRole:view ロールを、前の手順で作成したサービス アカウントにバインドし、クラスター全体のリソースに対する読み取り専用権限を付与します。

 kubectlクラスターロールバインディング kube-dashboard-readerを作成します--clusterrole=view --serviceaccount=default:kube-dashboard-reader  

3. サービス アカウント トークンを取得します。

 kubectl シークレットを取得します `kubectl シークレットを取得します -nデフォルト| grep kube-dashboard-reader | awk '{print $1}' ` -o jsonpath={.data.token} -nデフォルト|ベース64 -d

Kubeconfigを使用してダッシュボードにログインする

$HOME/.kube/config をコピーし、内容を変更して、準備作業で取得したトークンをファイルに追加します。これを Kubeconfig の Users の下の User 部分に追加し、次のように入力します。

 ... 
 
ユーザー: 
 
 -名前: kubernetes-admin 
 
ユーザー: 
 
クライアント証明書データ: ... 
 
クライアント-キー -データ: ... 
 
 token: <これは上記で取得したトークンです...>

次に、ログイン インターフェイスで Kubeconfig ラジオ ボタンを選択し、ファイルを選択してダッシュボードに正常にログインします。

トークンを使用してダッシュボードにログインする

ログイン インターフェイスで [トークン] ラジオ ボタンを選択し、準備中に取得したトークンを貼り付けて正常にログインします。