目次

• 1. コンテナ・Kubernetesが求められる背景・現状
• 2. Kubernetes 運用における課題
  
  • モニタリングの課題
  • セキュリティの課題
• 3. エンタープライズ領域で実施すべき対策
  
  • モニタリングの対策
  • セキュリティの対策
• 4. まとめ

1. コンテナ・Kubernetesが求められる背景・現状

システム開発では、スピード感のあるサービス提供を実現するアジリティと、環境を問わずデプロイが可能となる一貫性が求められています。それを満たすコンテナとそのオーケストレーションツールであるKubernetes（※1）は、アプリケーション実行基盤としてエンタープライズ領域でも採用が進んでいます。NTTデータでも、決済などのエンタープライズ領域でKubernetesをベースとしたプラットフォームやサービスを活用したことで、アジリティと一貫性を実現した事例が増えてきています。

2. Kubernetes 運用における課題

エンタープライズ領域では、可用性を確保するためのシステム設計、トラブルの予兆や原因を把握するためのモニタリング機構、情報を守るためのセキュリティ対策が重要となります。Kubernetesを採用したシステムにおいては、以下のようなモニタリングとセキュリティに関する課題があり、運用開始後に故障調査やセキュリティ確保で難航することがあります。

モニタリングの課題

図1：モニタリングの課題イメージ

セキュリティの課題

図2：セキュリティの課題イメージ

3. エンタープライズ領域で実施すべき対策

前述したKubernetesのモニタリングとセキュリティの課題に対して、実際にエンタープライズ領域のシステムで実施した内容をもとに、対策のポイントを解説します。

モニタリングの対策

Kubernetesの内部で発生した動作を観測し記録する仕組みが不可欠です。代表的なツールにPrometheus（※2）があり、クラスタ・ホスト・コンテナに関わる様々なメトリクス収集が可能となりますが、Prometheus自身のスケールや複数クラスタのデータを集約管理する仕組みを検討する必要があります。Victoria Metrics（※3）などのツールを利用してメトリクス集約基盤を構築することで、そういった大規模な利用時に発生する問題に対処することができます。
また、環境が複数クラウドに跨がる場合にはSaaSで提供されるモニタリング製品の採用も有効です。例えばSysdig DevOps Platformでは、エージェントの導入によりデータの保存を意識することなくメトリクスの収集が自動的に行われ、Prometheus HTTP APIと互換性を持つため、PromQLを利用してデータの可視化が可能となります。

セキュリティの対策

開発から運用のライフスタイル全体でセキュリティリスクへの対処が必要となります。決済システムなどセキュリティ要求が高いシステムでは、“Application Container Security Guide”（NIST SP 800-190）（※4）で定められた5つのリスクへの網羅的な対処が求められます。

図3：コンテナ活用における5つのセキュリティリスク

（1）コンテナイメージリスクへの対処
コンテナイメージに脆弱性が存在することで、脆弱性を狙った攻撃を受け、情報漏洩やサービス停止といった被害に繋がります。そのためレジストリに登録されたイメージをスキャンし脆弱性を検出することが必要となるのですが、後工程になってからイメージスキャンを開始すると修正工数の増大に繋がるため、開発初期からビルドパイプラインの中でスキャンを実施することが重要です。さらに、検知した脆弱性情報をチケット管理システムと連携することで、脆弱性の把握と対策状況の確認を効率的に実施することができます。
また、ビルド後に発覚した脆弱性や、マルウェアが混入したイメージの実行による被害のリスクに対処するために、実行中のイメージの定期的なスキャンも欠かせません。

（2）コンテナレジストリリスクへの対処
利用しているコンテナレジストリの権限制御を適切に実施し、認証とセキュリティの確保された通信で保護する必要があります。さらに、脆弱性のあるバージョンのデプロイを防ぐため適切なバージョン管理を行わなければなりませんが、アプリケーションとコンテナイメージのバージョンを統合するようにビルドパイプラインを構築することで、管理工数を削減することができます。

（3）コンテナ/ネットワークリスクへの対処
コンテナランタイムの脆弱性や不適切な設定により、コンテナが他のコンテナやホストOSを侵害するリスクがあります。推奨される設定を行ったうえで、ベンチマークモジュールによる評価を行いリスクに対処します。例えば、コンテナランタイムにDockerを使用している場合は、Docker CIS Benchmarkが利用可能です。
また、コンテナから他コンテナやホストOSへの不正アクセスを防ぐため、KubernetesのNetwork Policyを用いてInbound/Outboundの通信を制御し、必要な通信以外を遮断します。さらに、コンテナ間の通信をモニタリングする仕組みを導入し、不要な通信が発生していないかを確認します。

（4）オーケストレータリスクへの対処
KubernetesはRole Based Access Control（RBAC）によりリソースへのアクセスを制御する機構を備えていますが、設定を誤った場合には不正に操作されるリスクが生じます。Pod Security Standards（※5）として推奨されるPodのセキュリティプロファイルが提示されているため、これに準拠したセキュリティ設定を行うことで既知のリスクに対応できます。さらに、CIS Kubernetes Benchmark といったベンチマークモジュールにより監査を行うことが推奨されます。

（5）ホストOSリスクへの対処
特権コンテナの不正使用やホストボリュームのマウントにより、コンテナ内のソフトウェアからホストOSが攻撃を受けるリスクが存在します。Security Policyによりホストファイルシステムのマウントを制限し、ホストボリュームを保護する必要があります。また、ホストOSに脆弱性のあるソフトウェアが混入することを防ぐために、コンテナ専用OSの使用が推奨されます。要件により汎用OSを使用する必要がある場合には、ベンチマークツールを利用して設定のチェックを行います。

これらのリスクに備えた上でもセキュリティ攻撃を受けた場合には、その影響範囲を調査するフォレンジック作業が必要になるため、コンテナ内部のログを記録しておかなければなりません。

コンテナリスクに対して個別に対処する仕組みを整備するには多くの工数を要するため、網羅的に対処するにはコンテナセキュリティ製品の導入が効果的です。Sysdig Secure DevOps Platformは、コンテナリスクに対処する機能を備えると共に、システムコールの記録によりコンテナアクティビティのフルフォレンジックが可能となります。具体的な事例としては、Sysdig導入事例（※6）と活用紹介（※7）において解説しています。

4. まとめ

エンタープライズ領域でのKubernetes利用は今後も増えていくことが予想されますが、前述のとおり、運用を見据えたモニタリングとセキュリティの対策は必須です。また、効率的かつ確実に対処するためには、外部ツール・サービスの活用や開発プロセスとの連携が欠かせません。
NTTデータは、エンタープライズ領域でのコンテナプラットフォーム活用により、アジリティと安定性・セキュリティを両立したデジタルトランスフォーメーションを推進します。