Kubernetesにおけるセキュリティ対策への取組み（ポリシー制御）
クラウドネイティブNow

1. 概要

クラウドネィティブへの移行が進み、Kubernetesを利用したコンテナ環境を活用するシーンが急増してきた昨今、実行中のコンテナに対する脆弱性を検出して防止するといったセキュリティ対策が重要となってきています。
Amazon EKS(Elastic Kubernetes Service)に代表されるようなマネージドサービスの登場によりKubernetesは以前に比べて活用のハードルは下がっているものの、podを中心としたリソースのセキュリティ対策等についてはEKS BestPractice Guide等を参考にしっかりと検討しておく必要があります。
特にKubernetesでのセキュリティ対策としてはポリシー制御が重要であり、本記事では "KyvernoによるKubernetes環境のポリシー制御 "と" Amazon Managed Service for PrometheusおよびAmazon Managed Service for Grafnaによるオブザーバビリティ（可観測性）の確保" について記載します。そのうえで、Kyvernoで実現できることを説明し、Kyvernoのインストール方法、基本的な設定例を記載ししたうえで、具体的な例として、Kyverno導入後、メトリクスをPrometheusを利用して収集し、取得した データをGrafanaを利用してデータの可視化、分析を行うといった実運用で活用できるような一連の設定例を記載します。

2. Kubernetesでのポリシー制御

Kubernetesは、クラスタ内でコンテナ化されたアプリケーションを組織化し、オーケストレーションすることを約束する、ポータブルで拡張性の高い環境として登場しました。
しかしながら、Kubernetes環境でのセキュリティに関する問題は多く指摘されており、Red Hatの最新のレポートによると、セキュリティ問題の70%はKubernetesの設定ミスだといわれているます。一般的に、設定ミスはポリシーが不十分であったり、ポリシーが設定されていないことが原因となっています。
Kubernetesにおける基本的なポリシー制御として、Pod間のネットワークトラフィックをセキュアに保つためのNetworkPolicy、Podの権限やアクセスポリシーを制御するPSA（Pod Security Admission controller）、リソースの使用量を管理するQuotas and Limit Rangeがあります。
Kubernetes のセキュリティを向上させるためには、必要以上の権限を持ったPodを作成したり、意図しない権限昇格を行いコンテナが実行されるのを防ぐためにクラスタ内またはNamespace内でのセキュリティポリシーの標準化を行い、誤った設定の pod が作成されるのをブロックすることが重要となります。今回はセキュリティポリシーの標準化を行うにあたって、Podの権限やアクセスポリシーを制御するPSA（Pod Security Admission controller）について説明します。

PSAを導入するには以下のようにlabels:pod-security.kubernetes.io/enforce:を指定しポリシーに違反した際の実際の挙動について、3つのモード（enforce・warn・audit）で3つのレベル（privileged・baseline・restricted）を選択することができます。 以下の例だとtest-namespaceのnamespaceに対してenforceのモードでbaselineのレベルのポリシーが適用されていることになります。

labelsを追加するだけでポリシーの適用ができるため、導入コストがかかりません。
しかしながら、PSAは設定が非常にシンプルである反面、拡張性に乏しい側面もあります。また、すでに導入済みのミドルウェアとPSAの相性が悪いといったケースもあり、PSAの導入自体が難しいといった課題もあります。
この課題を解決するためには、カスタマイズ可能なポリシー制御ができる専用のポリシーエンジンを導入する必要があります。

3. コードによるポリシー管理（Policy-as-code）の必要性

クラウドをはじめとする技術が次々と導入される中、ネットワークチームやセキュリティチーム、コンプライアンスチームが自動化技術なしで開発部門や業務要件の動向に追従していくことが困難となっています。
このような中で、コードによるインフラ管理（IaC：Infrastructure-as-Code）、コードによるセキュリティ管理（SaC：Security-as-Code）といったアプローチが、クラウド環境やマイクロサービスを保護する上で大きな役割を果たすようになっています。
これらのアプローチは全体としてクラウドセキュリティを確保するために協調して働き、デプロイまたはプロセスの開始時点ら統合的なセキュリティを確立することによって、脅威やリスクの阻止に貢献しています。
コードによるポリシー管理（またはコンプライアンス管理）は、システムで使用するポリシーの実装、管理、変更追跡を行う有力な手段であり、採用したポリシーがクラウドネイティブシステムの4C’s（Code：コード、Container：コンテナ、 Cluster：クラスタ、Cloud：クラウド）上で適用・運用されていることを保証する上でも有用です。

4. Kubernetesでのポリシーエンジン

ポリシーエンジンとして提供されている中に以下のようなものがあります。

• OPA/GateKeeper
• Kyverno
• jsPolicy

それぞれのポリシーエンジンで特徴が異なるが、今回はポリシーエンジンとしての導⼊が容易でポリシー定義もシンプルなKyvernoを使ってEKS環境に導⼊していきます。

5. Kyvernoとは

Kyverno は、ポリシーを使⽤して Kubernetes リソースの構成を検証、変更、⽣成できる Kubernetesネイティブポリシーエンジンです。いわゆるPolicy-as-code(PaC)ソリューションの１つとなります。
2020年11⽉10⽇にCNCF(Cloud Native Computing Foundation)に採択されており、2023年1⽉現在はincubating projectとして認定されています。
特徴としては、以下のようなものがあります。

• Kubernetes リソースとしてのポリシー定義可能
• 専⽤の⾔語を学ぶ必要はなく、ポリシーはYAMLで記述されているためKubernetesマニフェストのように動作
• ラベルセレクタとワイルドカードを利⽤してリソースをマッチング
• ポリシーは、クラスター全体のリソース（kind: ClusterPolicy）またはネームスペースごとのソース（kind: Policy）として定義可能
• gitやkustomize などの使い慣れたツールを使って、ポリシーをコードとして管理可能
• ソフトウェアのsupply chain securityのためのコンテナイメージの検証
• イメージメタデータの検査

6. Kyvernoのアーキテクチャ

KyvernoはKubernetesクラスタ内でAdmission controllerとして動作します。ユーザがmanifestをapplyする際にKubernetesのAPI Serverを経由し、API ServerがKyvernoにAdmission ReviewRequest⾏い、Kyverno側でKubernetesリソースの登録の前にリソース作成時にポリシーに則っているのかの検証を実施、または、リソース作成時にフィールドを追加・削除・変更を⾏います。

7. Kyvernoのインストール

Helmを利⽤して、Kyvernoのインストールを⾏います。

kyvernoのインストールが完了したら、デフォルトのセキュリティポリシーが追加になっていることを確認します。

• BACKGROUND：バックグラウンドスキャン中に既存のリソースにルールを適⽤するかどうかを制御。デフォルトは、true
• VALIDATE ACTION：ポリシー違反時の処理。audit と enforce を選ぶことが可能
  • enforfce
    ポリシー違反の場合、新規リソースの場合は、そのリソースは作成されない
  • audit
    ポリシー違反の場合、ClusterPolicyReport または、PolicyReport というリソースが作成される。ポリシー違反でもそのリソースは作成可能

8. Kyvernoのポリシー編集

前述のデフォルトのセキュリティポリシーに加えて、新しいポリシーの追加を⾏います。
以下ポリシーは、信頼されていない、public registriesからのimageの取得するpodの作成を拒否し、信頼されたレジストリの使⽤をのみを許可するようなポリシーを定義しています。

spec.rules[].validate.pattern.containers[].image にに許可するレジストリを指定することで、安全が確保されないレジストリからのimageの取得を回避することができます。

9. ポリシーの動作検証

前述で設定したポリシーの動作検証としてポリシー違反するPodを適⽤してみます。

ポリシー定義では、ValidationFailureAction：envorceとしているため、違反するPodは起動を⾏うことができません。
このようにしてこのようにして、Kubernetesの設定ミスから発⽣する意図しないセキュリティ問題を防ぐことができます。

10. Observability

ポリシーエンジンを本番環境にて運⽤を⾏う上では、メトリクスやポリシーレポートのデータを監視運⽤するため可観測性（Observability）が重要となります。今回は、kyvernoで収集できるメトリクス及びポリシーレポートをPrometheusで収集・蓄積し、Grafanaのダッシュボードでモニタリングする仕組みを導⼊します。また、AWSのManaged Serviceとして提供される、Amazon Managed Service for Prometheus(AMP)とAmazon Managed Service for Grafna(AMG)を利⽤してよりスケーラビリティな構成とします。

kyvernoではポリシーチェックの結果を可視化し、モニタリングできるようにするためにPolicy Reporterという機能も提供し ています。Prometheus Metricsのエンドポイントを公開しておりGrafanaのような監視ツールで違反を観察するために使⽤することができます。Prometheus Severのtargetにkyvernoのメトリクスとポリシーレポートのメトリクスのエンドポイントを指定することでPrometheus Severがメトリクスを収集します。Prometheus Severのインストール時にあらかじめ作成したAMPの書き込み権限のあるServiceAccountとリモート書き込みを⾏うURLを指定します。これによって、Prometheus Severが収集したメトリクスをAMP側に書き込むことができます。あとは、AMG側でAMPのURLを指定すればダッシュボード上でkyvernoのメトリクスを確認することができます。

さらにkyverno側で公開されているGrafnaのダッシュボードを利⽤することで以下のように収集したメトリクスを可視化することが可能になります。

このようにKubernetes環境にポリシー制御を導⼊することで、⼈⼿の介在によって引き起こされる設定ミスを防ぐことができます。また、PrometheusとGrafnaと連携することで適⽤されたポリシーの可視化とメトリクスをトリガーにアラートが可能になり、クラスタ全体のObservabilityを⾼めることができます。

富⼠通ではこのようにコンテナ環境のセキュリティ対策についてもノウハウを持っております。Kubernetes環境のセキュリティ対応についてお悩み等あれば是⾮ご相談ください。

関連情報

当社が提供する関連サービスの詳細は下記ページをご覧ください

• Red Hat OpenShift Container Platform（Linux/OSS情報）

Kyverno pod-security の詳細は下記ページをご覧ください。

• Kyverno pod-security（Cloud Native Computing Foundationのページへ）

Amazon EKS Best Practices Guide for Security の詳細は下記ページをご覧ください。

• Amazon EKS Best Practices Guide for Security（AWS GitHub Organizationsのページへ）

Monitoring Kyverno with Prometheus の詳細は下記ページをご覧ください。

• Monitoring Kyverno with Prometheus（Nirmataのページへ）