Webhook を使用した Kubernetes のタグベースの権限制御の実装

[[387807]]

Kubernetes は名前空間レベルの権限制御をサポートしています。ただし、これが当社の要件を満たさない場合もあります。たとえば、Akraino ICN プロジェクトでは、高度な権限要件がいくつかあり、複数のユーザーが同じ名前空間内の 1 つのリソースを作成、更新、または削除できますが、他のユーザーが作成したオブジェクトを更新または削除することはできません。

この要件を満たすために、Webhook を使用して Kubernetes にラベルベースの権限制御メカニズムを設計および実装しました。通常、Webhook はリソースを認証したり、リソースのデフォルト値を設定したりするために使用されます。この記事では、Webhook を使用して権限を制御します。

ライセンス制度の設計

Kubernetes では、ユーザーまたはサービス アカウントを 1 つ以上のロールにバインドできます。各ロールは権限ルールを定義します。たとえば、次の定義では、sdewan-test ロールがデフォルトの名前空間で Mwan3Rule タイプのカスタム リソース インスタンス (CR) を作成または更新でき、Mwan3Policy CR を取得できることが必要です。

 apiバージョン: rbac。認証.k8s.io/v1
種類: 役割
メタデータ:
  注釈:
名前: sdewan-test
  名前空間:デフォルト 
ルール:
 -apiグループ:
  - 「」  
  リソース：
  -mwan3ルール
  動詞:
  -作成する 
  -アップデート 
 -apiグループ:
  - 「」  
  リソース：
  - mwan3ポリシー
  動詞:
  - 得る

json 形式のアノテーション sdewan-bucket-type-permission を使用してロールを拡張しました。

注釈では、タグベースの権限を定義できます。たとえば、以下に示すロールは sdewan-test ロールの権限を拡張します。sdewan-test は、タグ sdewan-bucket-type=app-intent または sdewan-bucket-type=k8s-service を持つ Mwan3Rule (json キーはカスタム リソース タイプを指定します) CR のみを作成/更新できます。また、ラベル sdewan-bucket-type=app-intent を持つ Mwan3Policy CR のみを取得できます。

実際、ワイルドカードマッチングもサポートしています。たとえば、mwan3* を使用すると、mwan3policies と mwan3rules の両方に一致させることができます。

 apiバージョン: rbac。認証.k8s.io/v1
種類: 役割
メタデータ:
注釈:
  sdewan バケットタイプの権限: |-
    { "mwan3rules" : [ "アプリインテント" , "k8sサービス" ],
 "mwan3policies" : [ "アプリインテント" ] }
名前: sdewan-test
名前空間:デフォルト 
ルール:
 -apiグループ:
 - 「」  
リソース：
 -mwan3ルール
動詞:
 -作成する 
 -アップデート 
 -apiグループ:
 - 「」  
リソース：
 - mwan3ポリシー
動詞:
 - 得る

Kubernetes Webhook は、ロール注釈の解析を担当します。 Admission Webhook とは何かを簡単に説明しましょう。 Webhook は、通常 Kubernetes クラスター内のポッドとして実行される Web サービスと考えることができます。

Kubernetes API がリクエストを受信すると、kube-api はオブジェクトを etcd に保存する前に webhook API を呼び出すことができます。 Webhook が allowed=true を返す場合、kube-api はオブジェクトを etcd に永続化します。それ以外の場合、kube-api はリクエストを拒否します。

Webhook リクエストの本文には、Kubernetes API リクエストを誰が行っているかを示す userInfo というフィールドがあります。 Webhook はユーザー情報からロール情報を取得し、ロール注釈を取得できます。コメントに記述されたタグレベルの権限を CR タグと比較することで、Webhook はリクエストを許可するかどうかを決定できます。

アクセス制御システムの実装

Akraino ICN プロジェクトでは、kubebuilder フレームワークを使用してラベルベースの権限システムを実装しました。ここでの前提は、いくつかのカスタム リソース定義 (CRD) (Mwan3Policy や Mwan3Rule など) と対応するコントローラーが実装されていることです。

Kubebuilder は、基本的な CRD、コントローラー コード、および Webhook コードを生成できます。新しい Webhook を作成するには、次の kubebuilder コマンドを実行します。

 kubebuilderでwebhookを作成--group batch --version v1 --kind CronJob --programmatic-validation  

このコマンドは、コントローラー ランタイム ビルダーを使用して認証 Webhook を作成します。このコマンドは、kube-api サーバーからの https リクエストを受け入れる webhook サーバーも作成します。さらに、http リクエスト本文を解析し、それを CRD 構造インスタンスに変換するコードも生成します。

開発者は、CRD インスタンスの内容を検証するためのコードを記述するだけで済みます。これはほとんどの Webhook 状況で役立ちます。しかし、CRD インスタンスではなく、https リクエストの本文にある UserInfo が必要なので、これは要件を満たしません。

kubebuilder によって生成された webhook サーバーを再利用しましたが、ハンドラーは独自に実装しました。上図はハンドラーの処理フローを示しています。ハンドラは、UserInfo を含む「admission.Request」を入力として受け入れます。ハンドラーでは、ユーザー ロール情報と CR ラベルを取得します。

• ユーザーロール情報を取得します。

ユーザー情報はリクエスト本文にあります。 userinfo からロール情報を取得するには、ハンドラーは kube-api からユーザーのロール情報を要求する必要があります。ハンドラーは、認証としてサービス アカウント トークンを使用して、kube-api にリクエストを送信します。まず、ハンドラーはユーザーのロール バインディング情報を取得するための要求を送信します。次に、ロール バインディング情報からロール情報を取得するための 2 番目の要求を送信します。デフォルトでは、ロールバインディング リソースには ".subjects" フィールドにインデクサーがありません。つまり、ロールバインディングに次のインデクサーを追加しない限り、kube-api リクエストでロールバインディングをフィルター処理することはできません。

 err = mgr.GetFieldIndexer().IndexField(context.Background(), &rbacv1.RoleBinding{}, ".subjects" , func(rawObjruntime.Object) []string {
 var フィールド値[]文字列
ロールバインディング := rawObj.(*rbacv1.RoleBinding)
 _の場合、subject := range rolebinding.Subjects {
        subject.Kind == "ServiceAccount"の場合{
                fieldValues ​​= append(fieldValues, fmt.Sprintf( "system:serviceaccount:%s:%s" , subject.Namespace, subject.Name ) )
        }それ以外{
                fieldValues ​​= append(fieldValues, subject.Name )
        }
 }
フィールド値を返す

• CR情報を取得する

ユーザーからのリクエストには、リソースの作成、更新、または削除などがあります。作成または更新リクエストの場合、ハンドラーはリクエスト本体から CR 情報を抽出します。削除リクエストの場合、ハンドラーはインスタンス全体ではなく、CR 名のみを取得できます。したがって、CR情報を取得するにはkube-apiを呼び出す必要があります。

• ロールと ClusterRole を検討する

ClusterRole では、ロールに加えて、ユーザー権限も定義できます。違いは、Role は常に単一の名前空間内の権限を定義するのに対し、ClusterRole はクラスター全体にわたる権限を定義できることです。したがって、ClusterRole の注釈も確認する必要があります。ロール情報を解析するときは、CR と同じ名前空間を持つロールのみを考慮します。

テストと実験

ここでは、タグベースの権限をテストして実験する方法を説明します。 ICN では、この機能はいくつかの CRD/コントローラーとともに kubebuilder を介して開発されます。 Webhook は https をサポートしますが、http はサポートしません。そのため、Webhook サーバーの認証が必要になります。

cert-manager プラグインを使用して、Webhook サーバーの証明書を入力します。同時に、kube-api が webhook リクエストを送信するときに証明書を使用できるように、証明書を webhook 構成に挿入します。開発またはローカル テストのユースケースで、Webhook が Pod ではなくローカルから実行される場合は、証明書を手動で構成する必要があります。

ネットワーク接続が確立されると、テスト用のロールとロール バインディングを作成できます。次のロールを作成し、ユーザーにバインドしてみましょう。

 apiバージョン: rbac。認証.k8s.io/v1
種類: 役割
メタデータ:
名前空間:デフォルト 
名前:作成意図
注釈:
  sdewan バケットタイプの権限: |-
    { "mwan3policies" : [ "アプリインテント" ] }
ルール:
 - apiグループ: [ "batch.sdewan.akraino.org" ]
リソース: [ "mwan3policies" ]
動詞: [ 「取得」 、 「監視」 、 「一覧表示」 、 「削除」 、 「作成」 ]

ユーザーは「sdewan-bucket-type:app-intent」タグ付きの mwan3policies を作成できますが、他のタグは作成できません。ここでの具体的な例としては、ユーザーは下の左側の CR は作成できますが、下の右側の CR は作成できないことが挙げられます。

下記の右側の CR を作成しようとすると、「サーバーからのエラー (ロールに権限がありません): 「config/samples/batch_v1alpha1_mwan3policy.yaml」の作成時にエラーが発生しました」というエラー メッセージが表示されます。

結論は

Webhook は Kubernetes の優れた機能であり、Kubernetes の柔軟性を高めます。開発者はこれを使用して多くの便利な機能を実装できます。

Controller-runtime プロジェクトはビルダー ツールを提供しており、これを使用して、検証 Webhook と変更 Webhook の 2 種類の Webhook を簡単に作成できます。検証 Webhook は kube-api リソースを検証するために使用され、ミュート Webhook はデフォルト値の設定など、リソース フィールドの値を更新できます。

場合によっては、これら 2 種類の Webhook のどちらも要件を満たさないことがあります。たとえば、この記事では、リソース本体に含まれていないユーザー情報を取得する必要があります。この場合、ビルダー ツールを使用するのではなく、ハンドラー コードの大部分を自分で開発する必要があります。

参考リンク:

Kubebuilder ブック: https://book.kubebuilder.io/introduction.html

コントローラーランタイムドキュメント: https://github.com/kubernetes-sigs/controller-runtime/blob/master/pkg/doc.go

Akraino SDEWAN エージェント設計: https://wiki.akraino.org/display/AK/Sdewan+config+Agent

ラベルベースの権限制御パッチ: https://gerrit.akraino.org/r/c/icn/sdwan/+/3509

※この記事の一部は https://01.org/kubernetes/blogs/chengli3/2020/implement-label-based-permission-control-kubernetes-using-webhook から翻訳したものです。違反行為があった場合は削除いたしますのでご連絡ください。