Kubernetesの権限管理に関する徹底的な議論

Kubernetes は主に API サーバーを通じて外部サービスを提供します。このようなシステムでは、セキュリティ制限が課されていない場合、リクエストが悪用され、クラスター全体が崩壊する可能性があります。

これを考慮して、Kubernetes は API にアクセスするユーザーに対して、認証と承認という対応するセキュリティ制御を提供します。認証はユーザーが誰であるかという問題を解決し、認可はユーザーが何ができるかという問題を解決します。適切な権限制御を通じてのみ、クラスターシステム全体のセキュリティと信頼性が保証されます。

次の図は、API アクセスに必要な 3 つのステップ、つまり認証、承認、アクセスを示しています。この章ではリソース管理に重点を置いているため、アクセスについては説明しません。

認証

認証とは、ユーザーが Kubernetes にログインできるかどうか、つまりユーザーが API サーバーにリクエストを送信できるかどうかを指します。

Kubernetes には、次の 2 種類のユーザーが存在します。

通常ユーザー: 外部ユーザー
サービスアカウント: 内部ユーザー

ユーザーの認証

通常ユーザー

通常のユーザーは Kubernetes から独立しており、Kubernetes によって管理されません。これらのユーザーは次のとおりです。

秘密鍵を配布できる実在の人物
Google アカウントなどのユーザーサービスを提供するサードパーティベンダー
ユーザー名とパスワードのリストを保存するファイル

ユーザーが Kubernetes 内に存在せず、Kubernetes によって管理されていない場合、どのように認証するのでしょうか?

一般的なアプリケーションシステムの場合、ユーザーはユーザー名とパスワードを提供します。サーバーは、それらを受信すると、それらがデータベースに存在し、有効であるかどうかを確認します。一致すれば認証は成功し、一致しなければ認証は失敗します。

では、Kubernetes ではこれをどのように実現するのでしょうか?

API 呼び出しを通じて通常のユーザーを追加することはできませんが、Kubernetes は証明書を通じてユーザーを巧みに認証します。つまり、有効な証明書を提供できる限り、どのユーザーでも Kubernetes ユーザー認証に合格できます。

ユーザー認証後、Kubernetes は証明書内の CN をユーザー名として使用し (たとえば、証明書に「/CN=joker」がある場合、ユーザー名は Joker になります)、組織をユーザーグループとして使用します。ユーザーの権限は、ユーザー名とユーザーグループにバインドされたロールによって決定されます。

サービスアカウント

サービスアカウントは Kubernetes によって管理されます。これらは特定の名前空間にバインドされており、API サーバー自体によって、または kubectl クライアントツールを使用するなどして API を呼び出すことによって作成できます。

通常のユーザーとは異なり、サービスアカウントには対応する Kubernetes オブジェクトがあります。サービスアカウントを作成すると、対応するシークレットが作成され、対応するパスワード情報が保存されます (バージョン 1.24.x では、対応するシークレットは作成されません)。作成されたポッドにサービスアカウントが指定されると、そのシークレットがポッドにマウントされ、ポッド内のプロセスが Kubernetes API にアクセスできるようになります。

認証戦略

Kubernetes には次の認証方法があります。

クライアント証明書
無記名トークン
アイデンティティ認証プロキシ
認証プラグインによる HTTP 基本認証

HTTP リクエストが API サーバーに送信されると、Kubernetes はリクエストから次の情報を関連付けます。

ユーザー名: ユーザー名。エンドユーザーを識別するために使用される文字列。例: kube-admin または [email protected]

UID: ユーザーID。ユーザーの一意のIDを表します。

グループ: 論理的に関連するユーザーのグループを表すユーザーグループ。

追加フィールド: 拡張フィールド、認証に必要なその他の情報

複数の認証方法を同時に有効にした場合、最初に認証に成功した認証方法が検証され、他の方法は認証されなくなることに注意してください。同時に、api-server は認証方法の順序を保証しません。正常に認証されたすべてのユーザーは、グループ「system:authenticated」に追加されます。

クライアント証明書

認証にクライアント証明書を使用する場合は、Kubernetes に有効な証明書を提供する必要があります。この証明書は、外部証明書または Kubernetes 自体によって承認された証明書にすることができます。

外部証明書の場合は、API サーバーを起動してクライアント証明書の有効性を検証するときに、--client-ca-file=SOMEFILE パラメータを使用して外部証明書の CA およびその他の情報を入力する必要もあります。

認証が成功すると、Kubernetes は証明書の Subject CN をユーザー名として使用し、組織をユーザーグループ (グループ) として使用します。

無記名トークン

ベアラートークンを使用して HTTP クライアントを認証する場合、API サーバーは Bearer 形式の値を持つ Authorization という HTTP ヘッダーを期待します。ベアラートークンは、HTTP のエンコードおよび引用メカニズムを使用して、HTTP ヘッダーの値フィールドに配置できる文字シーケンスである必要があります。たとえば、ベアラートークンが 31ada4fd-adec-460c-809a-9e56ceb75269 の場合、HTTP ヘッダーには次のように表示されます。

承認:所有者31 ada4fd - adec - 460c - 809a - 9e56ceb75269

Kubernetes では、ベアラートークンを使用する方法がいくつかあります。

静的トークンファイル
サービスアカウントトークン
OpenID Connect トークン (OIDC トークン)

静的トークンファイル

静的トークンを使用する場合、API サーバーは --token-auth-file=SOMEFILE を介して外部から CSV ファイルをインポートし、API サーバーはこのファイルから対応するユーザー名とユーザーグループを読み取ります。

クライアントがリクエストを行うと、API サーバーはリクエストヘッダー内の Bearer トークンとファイル内のトークンを比較し、トークンが有効かどうかを判断します。

サービスアカウントトークン

サービスアカウントが手動または自動で作成されると、Kubernetes は自動的にサービスアカウントトークンを作成します。 v1.24 より前では、対応するシークレットが作成され、対応する名前空間に保存されます。 v1.24 以降では、シークレットは別途作成されなくなりました。代わりに、Pod が起動されると、kubelet は TokenRequest API を通じてトークンを生成し、それを Pod にマウントします。

前述のように、サービスアカウントは主にポッドに API サーバーにアクセスする機能を提供します。 Pod が作成されると、サービスアカウントトークンが Pod にマウントされ、Pod は API サーバーにアクセスできるようになります。

もちろん、サービスアカウントトークンは Pod 上だけでなく外部でも使用できます。 Kubernetes Cluster Management のクラスターインストールの章では、Kubernetes Dashboard にアクセスするためにトークンを使用する方法が紹介されており、このときにサービスアカウントトークンも使用されます。

OpenID Connect トークン

OpenID Connect は OAuth2 認証方式です。 Kubernetes は、OAuth2 トークンレスポンス内の ID トークンを認証アクセスのベアラートークンとして使用できます。

プロセスは次のとおりです。

アイデンティティプロバイダにログインする
アイデンティティサービスでは、access_token、id_token、refresh_tokenが提供されます。
kubectlを使用する場合は、id_tokenを--tokenフラグ値として設定するか、kubeconfigに直接追加します。
kubectlはid_tokenをAuthorizationというヘッダーに入れてAPIサーバーに送信します。
APIサーバーは、構成で参照されている証明書をチェックして、JWTの署名が有効であることを確認する責任があります。
id_tokenの有効期限が切れていないか確認する
ユーザーに操作を実行する権限があることを確認する
認証が成功すると、APIサーバーはkubectlに応答を返します。
kubectlはユーザーにフィードバックを提供する

ユーザーが認証に使用する方法に関係なく、認証に合格しても、ユーザーが操作する権限を持っていることを意味するわけではありません。最初の防御線を通過するだけです。次のステップは、ユーザーが特定の操作権限を持っているかどうかを判断するために認証を実行することです。

認証

認証プロセス

リクエストが認証に合格すると、承認フェーズに入ります。この段階で、Kubernetes はリクエストに必要なリソースにアクセスする権限があるかどうかを確認します。許可があれば、リクエストの処理を開始します。そうでない場合は、不十分な権限が返されます。

API サーバーはすべてのポリシーをチェックし、リクエスト内のアクションを許可するポリシーがあるかどうかを確認します。そうであれば、リクエストの実行が許可されます。それ以外の場合、リクエストは拒否され、403 エラーが返されます。複数の認証モジュールが設定されている場合、リクエストは順番に各テンプレートに対してチェックされます。いずれかのモジュールがチェックに失敗した場合、リクエストは拒否され、それ以上のチェックは実行されません。

Kubernetes が認証を実行する際、主に以下の情報をチェックします。

ユーザー: 認証時に確認されたものと同じ情報
グループ: 認証時にチェックされた情報と同じ
追加: 認証で確認された情報と同じ
API: API リソースですか?
リクエストパス: 非リソース (API リソース) エンドポイント (/healthz など)
API リクエスト動詞: 取得、一覧表示、作成、更新、パッチなどの API アクション、リソースに対する特定のアクション (すべてのポッドの一覧表示など)
HTTP リクエスト動詞: get、post、put などの非リソースリクエストで使用される HTTP アクション
リソース: アクセスを要求されたリソースの名前またはID
サブリソース: アクセスを要求されたサブリソースの名前またはID
名前空間: リソースが配置されている名前空間
API グループ: アクセスを要求された API グループ。 API グループとは、関連するリソースを制御する API のグループを指します。指定されていない場合は、コアAPIグループを表します

認証モジュール

Kubernetes は次の 4 つの認証モードを提供します。

ノード: ノード上で実行されているポッドに基づいて Kubelet を認可する特別な認可モジュール
ABAC: 属性ベースのアクセス制御
RBAC: ロールベースのアクセス制御
Webhook: HTTPリクエストコールバック。WEBアプリケーションを介して、特定の操作を実行する権限があるかどうかを判断します。

ここでは、RBAC (ロールベースのアクセス制御) についてのみ紹介します。実際には、このモードは多くのシナリオで使用されます。

RBAC

RBAC は、Kubernetes でよく使用される認証モードです。その基本的な概念は次のとおりです。

ルール: 異なる API グループに属する操作のセット。

ロール: ロールは、現在の名前空間に適用可能な Kubernetes API オブジェクトを操作するための一連のルールを定義するために使用されます。

ClusterRole: 名前空間によって制限されないクラスターロール。

主体: 行為の対象となる人、つまり規則の対象。

RoleBinding: ロールとアクターをバインドし、名前空間で動作します。

ClusterRoleBinding: 名前空間の制限なしにクラスターのロールとアクターをバインドします。

ロールと ClusterRole

Role と ClusterRole は、関連する権限の一連のルールを定義します。これらの権限は累積的です (操作を拒否するルールはありません)。 Role は Namespace レベルですが、ClusterRole はクラスターレベルです。

役割の定義は次のとおりです。

 apiバージョン: rbac .authorization .k8s .io / v1
種類:役割
メタデータ:
 名前:役割-デモ
 名前空間: devops
ルール:
 -apiグループ: [ "" ]
 リソース: [ "ポッド" 、 "デプロイメント" ]
 動詞: [ 「作成」 、 「削除」 、 「監視」 、 「一覧表示」 、 「取得」 ]

つまり、アクターは devops 名前空間内のポッドとデプロイメントに対して作成、削除、監視、一覧表示、取得操作を実行できるようになります。ロールは名前空間レベルであるため、上記のルールは devops 名前空間に対してのみ有効です。

ClusterRole の定義は次のとおりです。

 apiバージョン: rbac .authorization .k8s .io / v1
種類: ClusterRole
メタデータ:
 名前:クラスター-ロール-デモ
ルール:
 -apiグループ: [ "" ]
 リソース： [ "" ]
 動詞: [ 「見る」 、 「一覧表示する」 、 「取得する」 ]

これは、すべてのリソースに対する監視、一覧表示、および取得の権限があることを意味します。

すべての権限を定義する場合は、次のように verbs フィールドを定義できます。

動詞: [ 「取得」 、 「一覧表示」 、 「監視」 、 「作成」 、 「更新」 、 「パッチ」 、 「削除」 ]

RoleBinding と ClusterRoleBinding

ロールバインディングは、ロールで定義されたさまざまな権限を 1 人またはユーザーグループに付与します。ロールバインディングには、関連するサブジェクト (ユーザー、ユーザーグループ、サービスアカウントなどのサブジェクト) のセットと、付与されたロールへの参照が含まれます。名前空間内の権限は RoleBinding オブジェクトを通じて付与できますが、クラスター全体の権限は ClusterRoleBinding オブジェクトを通じて付与されます。

RoleBinding は、同じ名前空間で定義された Role オブジェクトを参照できます。次のように：

 apiバージョン: rbac .authorization .k8s .io / v1
種類: RoleBinding
メタデータ:
 名前:ジョーカー-ロールバインディング
 名前空間: devops
科目:
 -種類:ユーザー
 名前:ジョーカー
 apiグループ: rbac .authorization .k8s .io
ロールリファレンス:
 種類:役割
 名前:役割-デモ
 apiグループ: rbac .authorization .k8s .io

これにより、joker ユーザーと role-demo ロールの間にバインド関係が確立されます。ジョーカーユーザーは、認証システムにおける単なる論理的な概念です。 Keystone などの外部認証サービスを経由するか、API サーバーのユーザー名とパスワードファイルを直接指定する必要があります。

上記の YAML ファイルの重要なフィールドの 1 つは、「件名」を定義する Subjects フィールドです。 kind は対象の種類を示し、次の 3 つの種類があります。

ユーザー: 外部の独立したサービスによって管理されます。管理者は秘密鍵を割り当てます。ユーザーは、KeyStone または Google アカウント、さらにはユーザー名とパスワードのファイルリストを使用できます。ユーザー管理クラスター内に関連付けられたリソースオブジェクトがないため、クラスター内の API を通じてユーザーを管理することはできません。
グループ: 複数のアカウントを関連付けるために使用されます。クラスターには、cluster-admin などのデフォルトグループがあります。
ServiceAccount: サービスアカウントは、Kubernetes API を通じて管理されるユーザーアカウントです。これらは名前空間に関連付けられており、クラスター内で実行されているアプリケーションに適用できます。権限認証は API を通じて完了する必要があります。したがって、クラスター内で権限操作を実行するには、ServiceAccount を使用する必要があります。

もう 1 つの重要なフィールドは roleRef です。これは、RoleBing オブジェクトが Role 名を通じて定義した Role オブジェクトを直接参照できることを定義し、それによってオペレーターとロール間のバインディング関係を定義します。

RoleBinding は名前空間レベルにあります。クラスターレベルの場合は、次のように ClusterRoleBinding を使用します。

 apiバージョン: rbac .authorization .k8s .io / v1
種類: ClusterRoleBinding
メタデータ:
 名前:ジョーカー- clusterrolebinding
科目:
 -種類:ユーザー
 名前:ジョーカー
 apiグループ: rbac .authorization .k8s .io
ロールリファレンス:
 種類: ClusterRole
 名前:クラスター-ロール-デモ
 apiグループ: rbac .authorization .k8s .io

上記の定義では、joker ユーザーは名前空間内のすべてのリソースに対する監視、一覧表示、および取得の権限を持ちます。

サービスアカウント

サービスアカウントもアカウントの一種ですが、Kubernetes クラスターのユーザー (システム管理者、運用保守担当者、テナントユーザーなど) ではなく、Pod 内で実行されるプロセスに使用されます。これは、Pod 内のプロセスに必要な ID 証明を提供します。

ServiceAccount の承認プロセスを理解するために例を見てみましょう。

（1）まずServiceAccountを定義します。

 APIバージョン: v1
種類:サービスアカウント
メタデータ:
 名前空間: devops
 名前: sa - demo

単純な ServiceAccount には、単純な名前空間と名前のみが必要です。

（2）このServiceAccountに権限を割り当てるためのRoleBinding YAMLファイルを作成します。

 apiバージョン: rbac .authorization .k8s .io / v1
種類:役割
メタデータ:
 名前:役割-デモ
 名前空間: devops
ルール:
 -apiグループ: [ "" ]
 リソース: [ "ポッド" 、 "デプロイメント" ]
 動詞: [ 「作成」 、 「削除」 、 「監視」 、 「一覧表示」 、 「取得」 ]
 ---
 apiバージョン: rbac .authorization .k8s .io / v1
種類: RoleBinding
メタデータ:
 名前: sa -ロールバインディング
 名前空間: devops
科目:
 -種類:サービスアカウント
 名前: sa - demo
 名前空間: devops
ロールリファレンス:
 種類:役割
 名前:役割-デモ
 apiグループ: rbac .authorization .k8s .io

次に、上記で定義した YAML ファイルを作成し、作成後の情報を表示します。

 $ kubectl get sa -n devops
名前 秘密 年齢
デフォルト0 6分25秒
sa -デモ0 6分25秒
$ kubectl ロールを取得-n devops
名前の作成場所
役割-デモ2022 - 07 - 06 T04 : 27 : 02 Z
 $ kubectl ロールバインディングを取得- n devops
名前 役割 年齢
sa -役割結合 役割/役割-デモ6 m50s

次に、ポッドを作成し、sa-demo サービスアカウントを使用します。

 APIバージョン: v1
種類:ポッド
メタデータ:
 名前: pod - sa - demo
 名前空間: devops
仕様:
 serviceAccountName : sa -デモ
 コンテナ:
 -名前:ポッド- sa -デモ
 画像: nginx
 imagePullPolicy : IfNotPresent

次のようにしてポッド情報を表示します。

 $ kubectl get po - n devops ポッド- sa -デモ- oyaml
 APIバージョン: v1
種類:ポッド
メタデータ:
 注釈:
 cni .projectcalico .org /コンテナID : c0820de4319bb6915602c84132ff83a63f62abaa1e9c706bad04e64661455d30
 cni.projectcalico.org/podIP : 172.16.51.225/32
 cni.projectcalico.org/podIPs : 172.16.51.225/32
 kubectl .kubernetes .io /最後に適用された構成: |
 { "apiVersion" : "v1" 、 "kind" : "Pod" 、 "metadata" : { "annotations" : { } 、 "name" : "pod-sa-demo" 、 "namespace" : "devops" } 、 "spec" : { "containers" : [ { "image" : "nginx" 、 "imagePullPolicy" : "IfNotPresent" 、 "name" : "pod-sa-demo" } ] 、 "serviceAccountName" : "sa-demo" } }
 作成タイムスタンプ: "2022-07-06T04:30:13Z"
 名前: pod - sa - demo
 名前空間: devops
 リソースバージョン: "192831"
 uid : 4f4c7c5a - 53ca - 45f7-94ad - 63e546cfcc62
仕様:
 コンテナ:
 -画像: nginx
 imagePullPolicy : IfNotPresent
 名前: pod - sa - demo
 リソース： { }
 終了メッセージパス: / dev /終了-ログ
 終了メッセージポリシー:ファイル
 ボリュームマウント:
 - マウントパス: /var/run/secrets/kubernetes.io/serviceaccount
 名前: kube - api - access - vxrcd
 読み取り専用: true
 dnsポリシー: ClusterFirst
 enableServiceLinks : true
 ノード名: kk - node01
 優先ポリシー: PreemptLowerPriority
 優先度: 0
 再起動ポリシー:常に
 schedulerName :デフォルト-スケジューラ
 セキュリティコンテキスト: { }
 サービスアカウント: sa -デモ
 serviceAccountName : sa -デモ
 終了猶予期間秒数: 30
 許容範囲:
 -効果: NoExecute
 キー: node .kubernetes .io /準備ができていません
 演算子:存在する
 許容秒数: 300
 -効果: NoExecute
 キー: node .kubernetes .io /到達不能
 演算子:存在する
 許容秒数: 300
 巻数:
 -名前: kube - API -アクセス- vxrcd
 予測：
 デフォルトモード: 420
 出典:
 -サービスアカウントトークン:
 有効期限秒数: 3607
 パス:トークン
-構成マップ:
 アイテム:
 -キー: ca.crt
 パス: ca.crt
 名前: kube - root - ca.crt
 -下向きAPI :
 アイテム:
 -フィールド参照:
 APIバージョン: v1
 フィールドパス:メタデータ.名前空間
 パス:名前空間

上記から、サービスアカウントトークンが Pod にマウントされていることがわかります。

 $ kubectl exec -it -n devops pod -sa -demo --/bin/sh
 # ls /var/run/secrets/kubernetes.io/serviceaccount
 ca .crt名前空間トークン

このうち、ca と crt は API サーバーへのアクセスに使用されます。

Pod を定義するときに spec.serviceAccountName プロパティを指定しない場合、システムは自動的に default の値を割り当てます。つまり、すべてのユーザーが同じ名前空間でデフォルトのサービスアカウントを使用することになります。

Subjects の種類には、User と ServiceAccount に加えて、ユーザーのグループを意味する Group もあります。 Kubernetes の外部認証サービスを構成する場合、このユーザーグループは外部認証サービスによって提供されます。 Kubernetes 組み込みユーザー ServiceAccount には、ユーザーとユーザーグループの概念もあります。 ServiceAccount の場合、Kubernetes 内の対応するユーザーは次のとおりです。

 system : serviceaccount : <サービスアカウント名>

ユーザーグループは次のとおりです。

 system : serviceaccounts : <名前空間名>

たとえば、次の RoleBinding を定義します。

科目:
 -種類: グループ
 名前:システム:サービスアカウント: devops
 apiグループ: rbac .authorization .k8s .io

つまり、ロールのアクセス許可ルールは、devops 名前空間内のすべての ServiceAccounts に適用されます。

例えば：

科目:
 -種類: グループ
 名前:システム:サービスアカウント
 apiグループ: rbac .authorization .k8s .io

つまり、ロールルールはクラスター全体のすべての ServiceAccount に適用されます。

Kubernetes には、system: で始まる組み込み ClusterRole が多数あり、kubectl get clusterrole を使用して表示できます。

さらに、Kubernetes では、ユーザーが直接使用できるように、次の 4 つの定義済み ClusterRole も提供されています。

cluster-admin: スーパー管理者
admin: 一般的な管理権限
編集: 権限を変更する
表示: 読み取り専用権限

RoleBinding または ClusterRolebinding を定義するときに直接使用できます。

やっと

これで、Kubernetes 権限管理の紹介は終了です。このセクションでは、主に認証と認可の一般的なプロセスと、Kubernetes で認証と認可を実装する方法について説明します。この章を学習すると、どのような認証ユーザーがいるのか、どのような認証戦略があるのか、RBAC を使用して認証を実装する方法を理解できるようになります。

<<: フルスタッククラウドネットワークテクノロジーにおける VPC/VBC の概要

>>: AWS、Google Cloud、Azure: クラウドコンピューティング大手のセキュリティ機能の比較