コンテナ・Kubernetes環境向けセキュリティ・モニタリング プラットフォーム

本文の内容は、2021年2月18日にKaizhe Huangが投稿したブログ(https://sysdig.com/blog/kubernetes-admission-controllers/)を元に日本語に翻訳・再構成した内容となっております。

アドミッションコントローラーは強力なKubernetesネイティブ機能で、クラスター上での実行を許可するものを定義してカスタマイズするのに役立ちます。

ウォッチドッグとして、クラスターに入るものを制御することができます。ウォッチドッグは、多すぎるリソースを要求するデプロイメントを管理したり、ポッドのセキュリティポリシーを適用したり、脆弱なイメージのデプロイをブロックしたりすることができます。


この記事では、Kubernetes のアドミッションコントローラーとは何か、そしてそのwebhookを使ってイメージスキャンを実装する方法を学びます。

アドミッションコントローラーはKubernetesクラスターへのドアを守る

アドミッションコントローラーは、オブジェクトが永続化される前に Kubernetes API へのリクエストをインターセプトして処理しますが、リクエストが認証されて認可された後に処理します。

これらのコントローラーは kube-apiserver バイナリにコンパイルされてシップされ、クラスター管理者が -enable-admission-plugins と -admission-control-config-file フラグを使用してのみ有効化と設定を行うことができます。

利用可能なアドミッションコントローラーのほとんどは、非常に限定的な機能を有しています。

例えば、LimitRangerは、Kubernetesデプロイメント内のオブジェクトのどれもがNamespaceのLimitRangeオブジェクトで指定された制約に違反していないことを検証します。また、デフォルトのリソースリミットやリクエストなど、何も指定していないPodへのリクエストを変異させることもできます。

--enable-admission-plugins=NamespaceLifecycle,LimitRanger,ServiceAccount,DefaultStorageClass,DefaultTolerationSeconds,MutatingAdmissionWebhook,ValidatingAdmissionWebhook,Priority,ResourceQuota,PodSecurityPolicy

アドミッションコントローラーは #Kubernetes クラスターへの扉を守ってくれます。リソースのリクエストからイメージのブロックまで、本当に便利です。それらを発見してください!

Click to tweet

Kubernetesのアドミッションコントローラーの力

アドミッションコントローラーは、DevOpsの生活の中で実存的な質問に答えることができます：

• ポッドはリソースを要求しすぎていないか？
• マイクロサービスポッドの生成に使用されるベースイメージは安全か？
• 他のデプロイメントと比較して、このデプロイメントの優先度は？
• これらのポッド/デプロイメントにリンクされているサービスアカウントには、現在どのような特権が付与されているか? 彼らは最小特権の原則を守っているか？

また、行動を起こすこともできます。

クラスターのリソースが不足していたり、イメージが安全でなかったりすると、 ポッドの実行をブロックすることができます。また、先ほど見たように、ポッドからのリソース要求を変更するために要求を変異させることもできます。

おそらく、標準的なデプロイメントにあらかじめ設定済みのKubernetesアドミッションコントローラーをいくつか実行していると思います。組み込みと思われがちなKubernetesのいくつかの側面は、実際にはこれらのコントローラーによってエンフォースされています。

• LimitRanger：前述したように、リソースのリミットやリクエストを管理します。
• PodSecurityPolicy：ポッドの作成と変更に作用し、要求されたセキュリティコンテキストと利用可能なポッドセキュリティポリシーに基づいて、それが許可されるべきかどうかを判断します。
• PersistentVolumeClaimResize：入ってくるPersistentVolumeClaimのサイズ変更要求をチェックするための追加の検証を実装します。

繰り返しになりますが、これらはすべてリクエストがetcdに永続化される前、つまり実行される前に行われます。これが、Kubernetesアドミッションコントローラーが、クラスターに予防的なセキュリティ制御をデプロイするための完璧な候補となる理由です。

webhookでKubernetesアドミッションコントローラーを拡張する

これまでに説明してきたこれらの機能はすべて、信頼性の高い安全なサービスを実行するために不可欠なものです。

しかし、各組織にはそれぞれ独自のポリシーやベストプラクティスのデフォルトセットがあるため、このような高度に特殊な制御だけでは十分ではないかもしれません。

幸いなことに、Kubernetesはあなたをカバーしてくれます。

Kubernetes APIの機能は、webhookを使用することで、ベースコードに複雑さを加えることなく、拡張したりカスタマイズしたりすることができます。

Kubernetes APIサーバーは、登録されたwebhookを呼び出しますが、これはかなり標準的なインターフェースです。これにより、アドミッションコントローラーは、任意のサードパーティ製コードと簡単に統合することができます。

これらの3つの特定のアドミッションコントローラーを使用することで、Webhookを介してAPIの機能を拡張することができます。

• ImagePolicyWebhook ：イメージを許可するかどうかを決定する
• MutatingAdmissionWebhook：リクエストを変更します。
• ValidatingAdmissionWebhook：リクエストの実行を許可すべきかどうかを判断します。

独自のKubernetesアドミッションコントローラーWebhookを実装する

さて、アドミッションコントローラーがどのように動作するかわかったので、この力を使ってどんな素晴らしいことができるか見てみましょう。

ImagePolicyWebhook を実装することを想像してみましょう。

まず、kube-apiserver を起動する際に webhook が有効になっていることを確認する必要があります。

kube-apiserver --enable-admission-plugins=ImagePolicyWebhook ...

kube-apiserver --admission-control-config-file=admission-config.yaml ...

admission-config.yaml の例には、AdmissionConfiguration オブジェクトが含まれています。

apiVersion: apiserver.config.k8s.io/v1
kind: AdmissionConfiguration
plugins:
- name: ImagePolicyWebhook
  configuration:
    imagePolicy:
      kubeConfigFile: <path-to-kubeconfig-file>
      allowTTL: 50
      denyTTL: 50
      retryBackoff: 500
      defaultAllow: true

そして、webhookサーバをkubeconfigファイルに設定します。

# clusters refers to the remote service.
clusters:
- name: name-of-remote-imagepolicy-service
  cluster:
    certificate-authority: /path/to/ca.pem    # CA for verifying the remote service.
    server: https://images.example.com/policy # URL of remote service to query. Must use 'https'.
# users refers to the API server's webhook configuration.
users:
- name: name-of-api-server
  user:
    client-certificate: /path/to/cert.pem # cert for the webhook admission controller to use
    client-key: /path/to/key.pem          # key matching the cert

設定オプションと代替案の詳細については ImagePolicyWebhook のドキュメントを参照してください。

これで、HTTP サーバーが webhook リクエストに応答するようにコード化できます。

Kubernetes API サーバーがデプロイメントのリクエストを受信すると、webhook は次のような JSON リクエストを受信します：

{
  "apiVersion":"imagepolicy.k8s.io/v1alpha1",
  "kind":"ImageReview",
  "spec":{
    "containers":[
      {
        "image":"myrepo/myimage:v1"
      }
    ],
    "namespace":"mynamespace"
  }
}

そして、あなたのサーバでこのリクエストを処理することができます。例えば、そのイメージが脆弱性や設定ミスを含んでいないことを確認するために、そのイメージをイメージスキャナーで照合します。

この例では、そのイメージが会社のポリシーに適合していないため、以下の JSON ペイロードで応答しています。

{
  "apiVersion": "imagepolicy.k8s.io/v1alpha1",
  "kind": "ImageReview",
  "status": {
    "allowed": false,
    "reason": "image runs as root"
  }
}

リクエストの一部分を拒否しているため、APIリクエスト全体が即座に拒否され、イメージがデプロイされず、エンドユーザーにエラーが返されます。

イメージスキャンのためのKubernetesアドミッションコントローラー

イメージスキャンを実装することは、Kubernetesのセキュリティを実装する際の最初のステップの1つであるべきです。イメージスキャンは、脆弱性や設定ミスを検出するための便利なメカニズムです。

イメージスキャンのベストプラクティスに従っているのであれば、CI/CDパイプラインやレジストリのセキュリティはすでに確保されているでしょう。

では、なぜアドミッションコントローラーでもイメージスキャンを行う必要があるのでしょうか？

医療服を着たライアン・レイノルズは、手術用マスクを外しながら、なぜかと尋ねています。

あなたが興味を持つかもしれない2つのユースケースがあります：

マニュアルでのデプロイはまだ発生する可能性があります。例えば、急ぎでマニュアルでデプロイを行うためにプロトコルをスキップしたり、クラスターにデプロイされたイメージへのアクセスを得る攻撃者がイメージスキャナをスキップしたりすることがあります。

また、Kubernetes固有のコンテキストに依存するルールもあります。例えば、1つのイメージを特定のネームスペースに制限したい場合などです。

このトピックをもっと深く掘り下げたい場合は、"アドミッションコントローラーでイメージスキャンを利用し、Kubernetesランタイムを保護"の記事をお見逃しなく。この記事では、イメージスキャンについて詳しく説明し、そのようなソリューションを実装するのに役立つガイドラインを提供しています。

まとめ

アドミッションコントローラーは、組織のポリシーをエンフォースするのに役立つ強力なKuberentesネイティブツールです。

りみっっとやリクエスト、ポッドのセキュリティポリシーなど、Kubernetesの多くの基本的な機能は、Admissionコントローラーの助けを借りて実装されています。

Kubernetes APIサーバーをwebhooksで拡張できることは、イメージスキャンの実装のような非常に興味深い機能への扉を開きます。

これらは探索する価値があります!

Sysdig Admission Controllerは、イメージスキャンのためのアドミッションコントローラーを活用しています。コンプライアンスコントロールにマッピングされた既存のスキャンポリシーを再利用したり、チームに脆弱性を報告したり。わずか数分でセットアップが完了します。今すぐ無料トライアルを申し込んでください！

Sysdigに関するお問い合わせはこちらから