K8s認証を理解する

序文

この記事では、K8s の認証モジュールについて紹介します。 4 つの認証モードの概要を説明します。この記事では、日常生活で最もよく使用される RBAC 認証モードについて例を挙げて説明します。

認証の概要

「K8s 認証の理解」では、kubectl クライアントまたは REST リクエストを介して K8s クラスターにアクセスする場合でも、最終的には API サーバーを経由してリソースを操作し、Etcd を通過する必要があることを説明しました。全体のプロセスは以下の図 1 に示されており、4 つの段階に分けられます。

図1 K8s APIリクエストアクセスプロセス

リクエストイニシエーターは K8s API リクエストを作成し、これは認証、承認、および AdmissionControl の 3 つの段階で検証されます。最後に、リクエストは K8s オブジェクトの変更操作に変換され、etcd に保持されます。

認証は主に、リクエスト元にアクセスできるかどうかという問題を解決します。つまり、認証に合格すれば、正当なリクエストオブジェクトとみなすことができます。したがって、要求元のオブジェクトがどのリソースにアクセスできるか、およびこれらのリソースに対してどのような操作を実行できるかを決定することが、認証で実現する必要があることです。

認証の最終的な目的は、要求オブジェクトを区別し、操作の範囲を制限し、実行したい操作を完了するために最小限の権限を使用できるようにすることで、セキュリティをさらに確保することです。権限制御を分割する方法は多数あります。 K8s は、Node、ABAC、RBAC、Webhook の 4 つの認証モードを提供します。

デフォルトでは、図 2 に示すように、/etc/kubernates/manifests/kube-apiserver.yaml ファイルから apiserver を起動したときの認証モードを確認できます。

図2 kube-apiserverの認証パラメータ

利用可能なパラメータを表 1 に示します。

表1 認証モジュールパラメータ識別表

パラメータ設定	意味	一般的な使用シナリオ
--認証モード=ABAC	属性ベースのアクセス制御 (ABAC) の使用	ユーザー名またはグループ名に基づいてクラスターリソースへのアクセスを制御します。小規模な組織や開発チームに適しています。
--認証モード=RBAC	ロールベースのアクセス制御 (RBAC) を使用する	ServiceAccount をカスタマイズし、リソースをバインドして役割に基づいてリソースのアクセス権を制御します。大規模な組織や開発および運用チームに適しています。
--authorization-mode=Webhook	HTTPコールバックモードを使用し、リモートRESTエンドポイントを使用して認証を管理できます。	認証ロールを外部サービスに渡して処理します。 Webhook 認証モジュールをカスタマイズしてクラウドプラットフォーム全体のアプリケーションへのアクセスを集中制御するなど、独自のニーズに応じて認証戦略をカスタマイズおよび拡張します。
--authorization-mode=ノード	kubelet によって発行された API リクエストの認証を実行する	ノードIDを検証して、必要な権限を持つ認証済みノードのみがK8sクラスターに接続できるようにします。
--authorization-mode=常に拒否	すべてのリクエストをブロック	通常はテストのみに使用されます
--authorization-mode=常に許可	すべてのリクエストを許可する	APIリクエストに認証が不要なシナリオ

図 2 に示すように、複数の認証モジュールを同時に設定できます (複数のモジュールはカンマで区切られます)。先頭のモジュールが最初に実行されます。いずれかのモードで要求が許可または拒否された場合、他の認証モジュールとのネゴシエーションなしに、その決定が直ちに返されます。

ノード認証

ノード認証は、kubelet によって行われた API リクエストを承認するために設計された特別な認証モードです。ノード認証により、kubelet は読み取り操作と書き込み操作に分割された API 操作を実行できます。読み取り操作の制御範囲は、kubelet ノードポッドにバインドされたサービス、エンドポイント、ノード、ポッド、シークレット、構成マップ、PVC、および永続ボリュームです。書き込み操作の範囲は、主にノードとノードのステータス、ポッドとポッドのステータス、およびイベントです。 kubelet が自身のノードのみを変更するように制限する場合は、Apiserver の起動時に NodeRestriction アクセスプラグインも有効にする必要があります (図 2 の 2 番目の赤いボックスを参照)。

ノード認証モジュールが有効になると、Kubellet は図 3 に示すように、特定のルールを持つ資格情報を使用して承認を取得する必要があります。

図3. Kubeletの証明書資格情報

図から、kubelet が証明書資格情報を使用していることがわかります。ここで、O=system:nodes はグループを表し、CN=system:node:paas-cnp-k8s-kce-01 はユーザー名を表します。これは、グループ名は system:nodes、ユーザー名は system:node:<nodeName> でなければならないという Node 認証モジュールの要件を満たしています。 <nodeName> はデフォルトでホスト名に設定されますが、kubelet --hostname-override オプションで指定され、kubelet によって提供されるホスト名と完全に一致する必要があります。

system:nodes は、K8s の組み込みユーザーグループです。図 4 に示すように、デフォルトの ClusterRoleBinding を使用できます。

図4 system:nodesのClusterRoleBindingの内容

これは ClusterRole system:node を指しており、subjects コンテンツがない、つまり system:node:paas-cnp-k8s-kce-01 ユーザーまたは system:nodes グループにバインドされていないことがわかります。これは、K8s では認証に RBAC を使用する代わりに、ノード認証モジュールに基づいて kubelet がノード上のリソースを読み取り、変更することを制限しているためです (RBAC コンテンツの一部については以下で詳しく説明します)。

ABAC認証

属性アクセス制御に基づいて、K8s はユーザーまたはグループに付与されるアクセスポリシーを表現できます。 RBAC との違いは、ポリシーが任意のタイプの属性 (ユーザー属性、リソース属性、オブジェクト、環境など) によって記述されることです。

ABAC モードを有効にするには、図 2 と同様に、apiserver を起動するときに --authorization-mode=ABAC と --authorization-policy-file=<ポリシーファイルパス> を指定する必要があります。図 5 は、K8s 公式サイトで提供されているサンプルポリシーファイルです。

図5 ABACポリシーインスタンスファイルの内容

ファイル内の各行は JSON オブジェクトであり、バージョン管理属性 "apiVersion": "abac.authorization.kubernetes.io/v1beta1" および "kind": "Policy" は、将来のバージョン管理と変換を容易にするために K8s 自体によって使用される固定の書き込み方法として理解できます。 spec 部分。user は --token-auth-file からのユーザー文字列であり、指定されたユーザー名はこのファイル内の文字列と一致する必要があります。グループは認証されたユーザーのグループと一致する必要があり、system:authenticated はすべての認証されたリクエストと一致します。 system:unauthenticated は、認証されていないすべてのリクエストに一致します。その他の一致する属性は主にアクセス対象のアクセスを記述するもので、リソース属性と非リソース属性に分かれています（具体的な定義については公式サイトを参照してください）。 readonly: 主に、リソースに対して get、list、watch 操作のみが許可されるか、および非リソース属性に対して get 操作のみが許可されるかを制限します。

例えば：

 {"apiVersion": "abac.authorization.kubernetes.io/v1beta1", "kind": "Policy", "spec": {"user": "alice", "namespace": "*", "resource": "*", "apiGroup": "*"}}

これは、ユーザー alice がすべての名前空間内のすべてのリソースに対して任意の操作を実行できることを意味します。

 {"apiVersion": "abac.authorization.kubernetes.io/v1beta1", "kind": "Policy", "spec": {"user": "bob", "namespace": "projectCaribou", "resource": "pods", "readonly": true}}

つまり、ユーザー bob は、名前空間が projectCaribou である Pod に対してのみ、リスト、取得、および監視操作を実行できます。

ServiceAccount の ABAC 制御。サービスアカウントは、system:serviceaccount:<namespace>:<serviceaccountname> の形式で ABAC ユーザー名を自動的に生成します。新しい名前空間を作成すると、K8s は現在の名前空間に default という名前の ServiceAccount を作成します。ここで、名前空間の下にあるすべての権限を持つために、名前空間 test を持つ default という名前の ServiceAccount が必要であると仮定すると、次のようなルールを追加できます。

 {"apiVersion":"abac.authorization.kubernetes.io/v1beta1","kind":"Policy","spec":{"user":"system:serviceaccount:test:default","namespace":"test","resource":"*","apiGroup":"*"}}

ABAC はユーザーアクセスをある程度分割しますが、新しい ABAC ポリシーが追加された場合、それを有効にするには API サーバーを再起動する必要があることがわかりました。リソースのアクセス権も細かく設定されており、読み取り専用かどうかのみを制御します。ユーザー規模が大きくなると、これではニーズを満たすことは到底できません。大規模な組織内のチームをより細かく管理および制御するには、K8s RBAC 認証モジュールが必要です。

RBAC認証

RBAC 認証を有効にするには、図 2 に示すように、--authorization-mode 起動パラメータに RBAC を含めます。他のアクセス制御方法と比較して、RBAC には次の利点があります。

クラスター内のリソース権限と非リソース権限の両方が完全にカバーされています。
RBAC はいくつかの API オブジェクトによって実現されます。他の API オブジェクトと同様に、ApiServer を再起動せずに kubectl または API を使用して操作および調整できます。

K8s の RBAC は主に、主体がどのような役割を持っているかという問題を説明して解決します。サブジェクトは K8s 内のユーザーであり、通常のユーザー (User、Group、一般的な kubectl コマンドは一般ユーザーが実行) とサービスアカウント (ServiceAccount、主にクラスタープロセスと K8s 間の API 通信に使用) が含まれます。ロールによって、リソースに対して実行できる操作が決まります。 RBAC では、名前空間レベルの Roles とクラスターレベルの ClusterRole を定義できます。最後に、K8s は RoleBinding と ClusterRoleBinding を通じてユーザーとロールの関係を関連付け、バインドします。 RoleBinding は Role と ClusterRole の両方をバインドでき、ClusterRole は ClusterRole のバインドを指定して、最終的に異なるユーザーが異なるリソースに対して特定の操作を実行する制御を実現します。 Role は特定の名前空間を対象としますが、ClusterRole はクラスター全体に有効であるため、後者はアクセス範囲が広く、Node などのリソースへのアクセスを制限できます。関係図を図 6 に示します。

図6 RBACの全体関係図

ここで、あなたの部署が rbac-team という名前空間で作業していると仮定します。デプロイメントパイプライン用に、deployment-clusterrole という名前の新しい ClusterRole を作成します。この ClusterRole では、Deployment、StatefulSet、および DaemonSet の 3 種類のリソースのみの作成が許可されます。同時に、この ClusterRole を使用するために、rbac-team 名前空間に cicd-test という名前の新しい ServiceAccount を作成します。 K8s では、kubectl クライアントまたは API リソースを使用してこの RBAC 機能を実装できます。

Kubectl クライアントメソッド。

最初のステップでは、次のコマンドを実行して必要な ClusterRole を作成します: kubectl create clusterrole deployment-clusterrole --verb=create --resource=deployments,statefulsets,daemonsets。ここで、--verb は実行できる操作を表し、--reasource は承認された操作のリソーススコープを表します。
ステップ 2: コマンド kubectl -n rbac-team create serviceaccount cicd-test を実行して、必要な ServiceAccount を作成します。
3 番目のステップでは、rbac-test で必要な権限をバインドし、次のコマンドを実行して、新しく作成された ServiceAccount を ClusterRole にバインドします: kubectl -n rbac-team create rolebinding cicd-rolebinding --clusterrole=deployment-clusterrole --serviceaccount=rbac-team:cicd-test。

API リソースメソッド。

最初のステップは、ClusterRole のリソース記述を準備し、図 7 に示すように、cr-deployment.yaml という名前のファイルを作成することです。

図7 デプロイメントクラスタロールリソース

動詞は実行可能な操作を制限するために使用されます。設定可能なパラメータは、「get」、「list」、「watch」、「create」、「update」、「patch」、「delete」、および「exec」です。リソースは、アクセス可能なリソースの範囲を制限するために使用されます。設定可能なパラメータは、「services」、「endpoints」、「pods」、「secrets」、「configmaps」、「crontabs」、「deployments」、「jobs」、「nodes」、「rolebindings」、「clusterroles」、「daemonsets」、「replicasets」、「statefulsets」、「horizontalpodautoscalers」、「replicationcontrollers」、および「cronjobs」です。 apiGroups は、アクセスされるリソースグループを分割するために使用されます。構成可能なパラメータは、「」、「apps」、「autoscaling」、「batch」です。

2 番目のステップでは、ServiceAccount のリソース記述を準備し、図 8 に示すように、sa-cicd.yaml という名前のファイルを作成します。

図8 sa-cicdリソース

3 番目のステップでは、RoleBinding のリソース記述を準備し、図 9 に示すように、rb-cicd.yaml という名前のファイルを作成します。

図9 ロールバインディングリソース

前の 2 つの手順で clusterrole と ServiceAccount をバインドします。ここで、subjects は承認されたサブジェクトを示します。承認されたオブジェクトがユーザーまたはグループの場合、次のフラグメントに似たサブジェクトを使用できます (グループの場合は、kind の値を Group に変更するだけです)。

 - kind: User name: "test-user" apiGroup: rbac.authorization.k8s.io

4 番目のステップでは、kubectl -f を使用して上記のリソースをそれぞれ適用し、サブジェクトとロールの作成とバインドを完了します。

K8s プロセスリソースが権限分割に上記の ID 資格情報を使用する必要がある場合は、図 9 に示すように、リソース宣言ファイルで構成するだけで済みます。

図10 ポッドリソースはServiceAccountを使用する

これは、特定のアプリケーションのサービスアカウントに権限を付与する最も安全で推奨される方法でもあります。

API サーバーのデフォルトの ClusterRole および ClusterRoleBinding オブジェクトの多くには、「system:」というプレフィックスが付けられています。これらのオブジェクトを変更すると、クラスター障害が発生する可能性があります。たとえば、Node 認証モジュールで言及されている system:node の場合、この ClusterRole は kubelet の権限を定義します。このクラスターのロールが変更されると、kubelet は動作を停止します。

すべてのデフォルトの ClusterRoles と RoleBindings には、ラベル kubernetes.io/bootstrapping: rbac-defaults が付けられています。

Webhook認証

Webhook モードを有効にする方法は ABAC モードと似ています。 apiserver を起動するときにポリシーを指定するには、--authorization-mode=ABAC と HTTP 構成ファイルを指定する必要があります。 --authorization-webhook-config-file=<ポリシーファイルパス> パラメータを使用できます。ポリシーファイルの構成では、kubeconfig ファイルの形式が使用されます。ユーザー部分は APIServer の Webhook を表し、クラスターはリモートサービスを表します。図11はK8s公式サイトに掲載されている例です。

図11 Webhookポリシーの設定例

認証時に、API サーバーはアクションを記述する JSON オブジェクトを生成します。リソースタイプの要求の場合、その内容には主にアクセス対象のリソースまたは要求の特性が含まれます (図 12 を参照)。

図12 リソースタイプWebhook認証リクエストの例

図 12 から、リクエストはユーザー jane、サブジェクトはグループ 1 とグループ 2 であり、リクエストされたリソースは kittensandpoines 名前空間の pods リソースであり、リソースはグループ unicorn.example.org に属し、リクエストされた操作はリソース情報の取得であることがわかります。 Webhook サービス URL がこの要求に同意すると、図 13 に示す形式で応答本文を返すことができます。

図13 Webhookリクエストの同意応答の例

図 13 からわかるように、SubjectAccessReview のステータスオブジェクト情報の値を入力するだけで済みます。要求を拒否する場合は、図の応答が返されます。 14 または図15 が返される可能性があります。

図14 Webhookリクエスト拒否応答例1

図15 Webhookリクエスト拒否応答例2

図 14 と図 15 はどちらも要求を拒否し、拒否の理由を示しています。違いは、図 14 の拒否応答に denied:true という情報が追加されていることです。つまり、複数の認証モジュールを構成すると、この応答が返されるとすぐに要求が拒否されます。 (デフォルトでは、認証モジュールが複数ある場合、Webhook は拒否後に他のモジュールを介して認証できます。他のモジュールも失敗するか存在しない場合にのみアクセスが禁止されます。)

リソースパス以外のアクセスの場合、生成された JSON リクエストの例を図 16 に示します。

図16 リソースパス以外のリクエストに対するWebhook認証リクエストの例

要約する

認証は主に、「誰がどのリソースに対してどのような操作を実行できるか」という問題を解決することです。 K8s には 4 つの主要な認証モジュールがあり、認証フェーズの第 2 段階で実行されます。 Node モジュールは主に、kubelet が APIServer にアクセスする必要があるシナリオ向けです。 ABAC は主にユーザーとグループの通常のユーザーを対象としており、大まかな制御が可能です。 RBAC は通常のユーザーに使用でき、ServiceAccount の管理にも使用でき、制御が非常に繊細で、よく使用される K8s 認証方法です。 Webhook は主にカスタム認証ロジックをカスタマイズするために使用され、クラウド全体の集中認証に使用できます。