こんにんちは、Red Hat でソリューション・アーキテクトをしています花田です。
本日は、コンテナ向けのセキュリティ製品である RHACS (Red Hat Advanced Cluster Security for Kubernetes) をご紹介したいと思います。 RHACS と言うとちょっと長いので、以降 ACS と呼びます。
ACS とは
ACS とは一言で言うと Red Hat の提供する Kubernetes 向けのセキュリティ製品です。
元になったのは、Red Hat 社が 2021年の1月に買収した StackRox 社の製品です。 現在は、マニュアルも Red Hat 風のスタイルに統一され、こちらから参照できるようになっています。
ACS の構成
ACS のアーキクテクチャーは、コンテナ形式で提供される Central と呼ばれる管理サーバーと、Central の管理対象となる Kubernetes クラスターに別れます。
上の図では、Central と Central の管理対象である Kubernetes クラスターは分かれて描かれていますが、Central のインストール先も Kubernetes クラスターですので、自分自身のインストール先を管理対象とする事も可能です。
サポート対象の環境は、Central のソフトウェアを導入する Kubernetes クラスターと、Central の管理対象となりセキュリティを管理される側の Kubernetes クラスターで別になっています。サポート環境については、こちらのドキュメントをご参照下さい。
現在、Central のインストール先としてサポートされているのは、基本的に OpenShift 4 の環境になります。ただ、StackRox 社時代は、OpenShift 以外の Kubernetes 環境もサポートされていた歴史的な経緯もあり、通常の Kubernetes 環境にも 技術的にはインストールは可能とされていますが、現在は限定的なサポート(Commercially Reasonable Support)となっています。
また、ACS リリース当初は、Central のサポートは、ユーザーがインストールした OpenShift 4 環境のみのサポートでしたが、現在では OSD *1 / ARO *2 / ROSA *3等の OpenShift 4のマネージドサービス環境 もCentral のインストール先としてサポートされるようになっています。
Central の管理対象となる Kubernetes は、OpenShift だけでなく、EKS、GKE、AKSもサポート対象としてカバーしています。
ダッシュボード
インストールされた ACS にログインすると、管理対象の Kubernetes クラスターのセキュリティの状態を示す専用のダッシュボードが現れます。このダッシュボードは OpenShift のダッシュボードとは別で、ACS が提供しているものです。
管理者はこのダッシュボードを見て、日々のセキュリティにまつわるタスクをこなしていく事になります。
ACS 内で生成されたアラートなどは、Slack 等のコミュニケーションツールや、 splunk や sumo logic と言ったログ管理システムや email 等にフォワードできるようになっています。
イメージ・レジストリとの統合
ACSは、Amazon ECR や、Docker Hub、Google Container Registry、IBM Cloud Container Registry、 Microsoft Azure Container Registry (ACR)、Red Hat Quay 等の Docker Registry HTTP API をサポートする各種イメージ・レジストリと統合する事ができます。
イメージ・レジストリと統合する事で、イメージの詳細の情報を取得したり、イメージのスキャンなどを行う事ができるようになります。
尚、ACS 自体には、イメージ・レジストリのソフトウェアそのものは付属していないのでご注意下さい。
ACS の基本コンセプト
ACSでは、コンテナが Build されて、Kubernetes 上に Deploy され、その後、運用に入って実際にコンテナが稼働している状況 (Run) と言ったコンテナのライフサイクルの各フェーズにおいて、セキュリティ対策を提供しています。
それぞれのフェーズで、脆弱性のスキャンだけでなく、適用するセキュリティのポリシーをユーザーが作成する事が可能です。
コンテナのビルドプロセスとの統合
コンテナのビルドのプロセスは、通常 CLIでの操作を前提としているので、ビルドプロセスとセキュリティの検査を統合するには、CLIのツールが必用になってきます。
多くの脆弱性スキャン製品がそうであるように、ACS も roxctl と呼ばれるCLIツールを提供しています。
roxctl CLI
roxctl コマンドは、実行時に ACS の Central に問い合わせを行います。
このコマンドを使用してコンテナのビルドプロセスにおける脆弱性スキャンや、ACS内でユーザーが定義したセキュリティ・ポリシーに違反していないかスキャンを行う事ができます。
例えば以下のようなコマンドでイメージがセキュリティポリシーに適合しているがスキャンをする事が可能です。
roxctl image check --image <image_name> -e $ROX_CENTRAL_ADDRESS
KubeLinter
英語で Lint Remover と言うと、毛玉や糸くずを取るツールの事を指します。プログラミングの世界では、開発者の書いたプログラムの構文を解析して様々なチェックしてくれるツールの事をLinter と呼びます。
Kubernetes の世界では、YAML地獄 と呼ばれる用語があるくらいに YAMLのマニフェスト・ファイルをたくさん書かなければいけません。
これらの YAMLのファイルは構文ミスがあれば、Kubernetes 側が受け付けてくれませんが、省略しても良い記述などについては、構文が合っている限りは受け付けてくれます。
ですので、開発者は省略しても大丈夫な記述は省略しがちですし、記述するのが面倒なので、セキュリティ的に甘い設定の記述をしがちです。
開発者が(主に楽をするために) 省略しがちな設定や、甘めのセキュリティの指定の記述を事前にチェックしてくれる KuberLinter というツールがあります。
KubeLinter は、現状、ACS に製品として含まれているツールではないのですが、StackRox 社によって開発されて、OpenSource として公開されています。
製品に含まれているものではないため、製品解説のこのブログで詳細は取り扱いませんが、代わりに こちらに簡単な使い勝手の記事を書きましたのでよろしければご参照下さい。
ポリシーの作成
ACS では、ユーザーが「ポリシー」を作成する事ができます。このポリシーを使って、作成しているイメージや、イメージをデプロイするための Kubernetes の Deployment のマニフェストの内容をチェックする事ができます。
上記の左側の例は、コンテナのイメージに、Alpine Linux のパッケージ管理ツールである apk が含まれてないかチェックするポリシーの例です。
コンテナは完成したアプリケーション・イメージですので、パッケージ管理ツールは、イメージが完成した後は必要のないツールになります。残っていると攻撃者に対して新規のパッケージを追加する機会を与えてしまう可能性があるので、こう言ったポリシーが作れるようになっています。
ポリシーで行える事はたくさんあり、全てはここではご紹介できませんが、上記のようなイメージに含まれるコンポーネントのチェックの他にも、マニフェスト内の annotation のチェックや、CPU や Memory のリクエスト量のチェック等の構成にまつわるもの、ある一定レベル以上の CVSS (Common Vulnerability Scoring System) スコアを持つ脆弱性が含まれていないか等もチェックする事が可能です。
また、ACS では、前述のように、Build 、Deploy、Runの３段階でコンテナのライフサイクルを区分しています。
作成されたポリシーは、この３つのどの段階で適用するか選べるようになっています。(内容によっては、特定のフェーズでしか設定できないものもあります)
稼働中の脆弱性の報告
ビルドした時には、脆弱性が特に無かったイメージでも、時間の経過とともに脆弱性が発見されていきます。そのため、デプロイされたコンテナも定期的に脆弱性のスキャンを行う必要があります。
一般的にこれらの稼働中のコンテナのスキャンは、実際に実行されているコンテナをスキャンすると、コンテナの稼働に影響があるので、コンテナをPULLしてきたイメージ・レジストリに対して行います。コンテナはイメージで、実行される度にコンテナデプロイ用のマニフェストに記述されている、コンテナのレジストリからPULLされてくるので、実行中のイメージを確認しなくても良いという特徴があります。
ACS では稼働中のコンテナのイメージの脆弱性のチェックを定期的にスキャンして行うようになっています。また、前述のポリシーを使って一定の期間、更新が無いイメージを含む Deployment を通知する事も可能です。
脆弱性の検知は、Kubernetes の Deployment 単位毎に評価結果がまとめられて表示されます。脆弱性管理のダッシュボード上から、危険度の高い Deployment → コンテナに含まれる CVE → 各CVE情報の詳細 という流れで情報を追いかける事ができるようになっています。
Network の Baseline とプロセスのランタイム検知
ACS では、ある時点でのコンテナの通信のアクセス先やポートなどの情報を教えてくれます。正常な状態の通信先を Baseline として記録しておく事で、Baselineから外れた通信を検知する事ができます。
その他にも、コンテナ内でのシェルや、コマンド実行を検知する事も可能です。
また、コンテナ内で実行される怪しいプロセスの検知も行う事ができます。bash 等の起動だったり、コンテナ内に追加のパッケージをインストールするための yum や dnf などの起動を検知する事が可能です。
Process の Baseline と Baseline に存在しないプロセスの検知
ACS は、Network の Baseline と同様に Deployment 内で起動される プロセスに対しても Baseline を作成します。Baseline には存在しないプロセスの実行を検知する事が可能です。
コンプライアンスの準拠状況
ACS には、CIS Benchmark(Docker, Kubernetes) 、HIPPA 、NIST (SP800-190 / 800-53)、PCI-DSS等のコンプライアンスへの遵守状況をレポートするダッシュボードが組み込まれています。
これらのコンプライアンチェック機能は、デフォルトで ACS に組み込まれています。
コアな OpenShfit ユーザーであれば、OpenShift (OKE / OCP) にも Compliance Operator という機能が提供されており、似たようなコンプライアンスチェック機能がある事をご存じだと思います。
OpenShift 本体の Compliance Operator と、ACS のコンプライアンスの機能は、現状ではそれぞれ並行して開発が進められています。
どちらが良い。とは一概には言えないのですが、Compliance Operator は、基本 CLI による操作になる一方で、ACS では GUIから管理するのが基本的なスタイルになっていて、レポートの生成までサポートしているなど、使い勝手の面などで違いがあります。
まとめ
本ブログでは、Kubernetes 向けのセキュリティ管理ツールである ACS (Advanced Cluster Security) の機能概要について簡単にご紹介してみました。
Enterprise 環境への Kubernetes の適用が進むにつれて、コンテナ環境のセキュリティについても注目が集まってきています。煩雑なコンテナセキュリティの管理を楽にするツールとして、ACS をご検討頂ければ幸いです。
