目次


Kubernetes ベースのアプリケーションを対象とした継続的インテグレーション/継続的デリバリー (CI/CD) セキュア・コンテナー・イメージ・パイプラインを実装する上での IBM のベスト・プラクティス

安全で信頼できる Kubernetes インスタンスの動作を確実にする

Comments

概要

この記事では、Kubernetes ベースのアプリケーションを対象とした継続的インテグレーション/継続的デリバリー (CI/CD) セキュア・コンテナー・イメージ・パイプラインを実装する上での IBM のベスト・プラクティスを紹介します。このパイプラインは、あらゆるコンテナー・イメージを最初にスキャンして脆弱性の有無を確認し、その使用を承認するメカニズムです。このメカニズムにより、インスタンスのセキュリティーも、以降にインスタンス化されるコンテナーのセキュリティーも保証されます。

Kubernetes コンテナー・イメージと CI/CD セキュア・イメージ・パイプラインの概要

Kubernetes を使用すると、マイクロサービスを使ってアプリケーションを柔軟に拡張することができます。Kubernetes では、個々のコンテナー内にアプリケーションの特定の構成部分を収容し、コンテナーの数を増やすことによって、アプリケーションの拡張とリリース需要量の増加に迅速かつ効率的に対応できるようにします。コンテナー・イメージはさまざまなリソースから作成されますが、リソースによっては検証可能なものも、そうでないものもあります。

したがって、適切なセキュリティー・ポスチャーを確立するとともに、コンテナー・イメージを本番環境で使用する前にその信ぴょう性を確実に検証する手法を確立することが必要不可欠となります。コンテナー・イメージの信ぴょう性を検証できなければ、重大なセキュリティー違反や、Kubernetes インスタンス内での壊滅的なアプリケーション障害が発生する恐れがあります。コンテナー・イメージの信ぴょう性を確実に検証する手法に従って、目的にそぐわないコンテナー・イメージを除外し、適切かつ検証可能なコンテナー・イメージのみが本番環境で使用されるよう徹底しなければなりません。

こうした手法の 1 つとなるのが、継続的インテグレーション/継続的デリバリー (CI/CD) セキュア・コンテナー・イメージ・パイプラインです。このパイプラインを通して、現在または過去を問わずにあらゆる類の脆弱性、あるいは各コンテナー・イメージ内での情報露出のリスクを検出し (いずれにしても、コンテナー・イメージの内容次第です)、その上で、そのイメージを本番環境で使用するかどうかを承認または拒否します。コンテナー・イメージ OS が完全に更新されないようなシナリオでは、このパイプラインによって関連する更新が適用されるようにします。

最終的に、本番環境にふさわしいコンテナー・イメージだけを、Kubernetes インスタンスで使用するプライベート・イメージ・レジストリーにプッシュします。

この記事では、コンテナー化プロセスについてある程度の知識を持っている読者を対象に、Kubernetes CI/CD セキュア・コンテナー・イメージ・パイプラインの現在の実装と、このパイプラインを使用する際のベスト・プラクティスについて説明します。

パイプラインの使用法

Kubernetes CI/CD コンテナー・イメージ・パイプラインの定義とこのパイプラインの仕組み

このパイプラインでは、Kubernetes インスタンスのプライベート・レジストリーに含まれるコンテナー・イメージを継続的に評価します。つまり、レジストリー内のイメージを継続的にスキャンして、本番環境で使用するのに適しているかどうかを評価します。本番環境で使用できるだけセキュアであると見なされたコンテナー・イメージはレジストリー内に残される一方、セキュアでないと見なされたイメージはレジストリーから削除されます。

セキュアなイメージであれば、新しいどのコンテナー・インスタンス内にでも伝播できます。このようにして、Kubernetes が随時、セキュアなイメージだけを使用して (例えば SoftLayer 内で) 新しいコンテナーをインスタンス化するようにします。セキュアなコンテナー・イメージを Kubernetes によってロールアウトし、Kubernetes インスタンス内の既存のコンテナー・イメージとその内容をサイト上で更新することもできます。

Kubernetes インスタンスの「必要最小限の人にしか知らせないで行うアクセス制御/職務の分離」パラダイムに関しては、特定の数あるいは最小限の個人にだけ、アプリケーション・イメージへのアクセス権限 (例えば、イメージの生成、イメージのデプロイ、またはイメージ・ライブラリーのキュレーションを行う権限) を割り当てる必要があります。 さらに、誰一人として承認なしでは変更を加えられないようにアクセス制御を構成する必要もあります。そのために必要となるのは、「技術承認担当者」です。理想的には、ピアあるいは技術チームのリードがこの役割を担当します。以上のベスト・プラクティスにより、個人が妨害行為を行ったりインスタンス全体に損傷を与えたりすること (例えば、イメージを作成してデプロイするなど) が回避されることになります。チームにこのような役割分担に対応できるだけの数のメンバーがいないとしたら、インスタンスに対する権限を割り当てた承認担当者を置いてください。

コンテナー・イメージがセキュアであることをパイプラインで判別する方法

未処理の CVE のすべてを調べて、コンテナー・イメージ OS と、コンテナー・イメージが内在するアプリケーションを確認します。さらに、コンテナー・イメージ OS に十分にパッチが適用されているかどうかを調べます。

要点は次のとおりです。

  1. コンテナー・イメージが本番環境で使用するのに適していると見なされた場合:
    • 今後使用できるように、そのイメージが適切なプライベート・イメージ・レジストリーに追加されます (使用ケース 1)
  2. コンテナー・イメージが本番環境で使用するのに適していないと見なされた場合:
    • そのイメージはプライベート・イメージ・レジストリーに追加されません。該当するイメージがすでにプライベート・イメージ・レジストリー内にある場合は、そのイメージがレジストリーから削除されます (使用ケース 2)

CI/CD セキュア・コンテナー・イメージ・パイプラインのアクター

CI/CD セキュア・コンテナー・イメージ・パイプラインの主なアクターは、開発チーム、AppOps チーム、インフラストラクチャー・チームの 3 つです。

開発チームの定義と役割

開発チームは、Kubernetes インスタンス内にデプロイされるコンテナーのコードを開発します。 開発チームには次の役割があります。

  • 新しい Docker イメージを作成する
  • コンテナーの次のデプロイ要件を識別する
    • 構成ファイル、鍵ストア、外部認証など
      • 新しいインフラストラクチャー
      • 共有ディスク
      • プロキシーなど
    • コンテナーの次の要件を定義する
      • RAM:
      • CPU
      • ディスク容量
  • クラッシュしたコンテナーや応答しないコンテナーの処理手順を策定する
    • コンテナーの廃棄および再起動
    • 自動クリーンアップ
  • インスタンス・アプリケーションのデータ・フローを識別する
  • 他のサービスへの依存関係とサービス・データを明示的に識別する

AppOps チームの定義と役割

AppOps チームは、コンテナー・アプリケーション管理での運用の部分を担当します。 AppOps チームには次の役割があります。

  • 次の情報に基づいて Kubernetes マニフェストを作成する
    • RAM:
    • CPU
    • ディスク容量
  • 次のデプロイメント資産を作成して管理する
    • 構成ファイル、鍵ストア、外部認証など
    • インフラストラクチャー・チームと連絡を取る
    • デフォルトの UCD (UrbanCode Deploy: 環境全体でアプリケーション・デプロイメントを自動化するための IBM のツール) ジョブを更新して必要な環境を反映させる
    • GitHub へのアクセスを自動化するための資格情報を提供する
  • アプリケーションに固有の付随的自動化を作成する
    • 依存関係を持つ他のアプリケーションの自動バージョン・チェックなど

インフラストラクチャー・チームの定義と役割

インフラストラクチャー・チームは、コンテナーの作成およびデプロイ・プロセスで発生したあらゆるインフラストラクチャー上の問題に対処します。

インフラストラクチャー・チームには次の役割があります。

  • Kubernetes、ロギング/モニタリング・スタック、Ansible、および UCD のフレームワーク自動化を作成する
  • SoftLayer® を保守およびスケーリングする
  • SoftLayer インフラストラクチャーと共通コンポーネントをモニタリングする
  • あらゆるクラスター・アプリケーションが必要な通信を行えるようにネットワークを更新する
  • アプリケーション固有の自動化に関して AppOps チームを支援する

使用ケース

使用ケース 1: コンテナー・イメージをテストした結果、Kubernetes インスタンスのプライベート・レジストリー内で使用するのに適切だと見なされた場合

コンテナー・イメージが Kubernetes 環境内で使用するのに適切であると見なされると、そのイメージが本番環境にデプロイされます。その際に使用されるデプロイ手法は、他の環境で適用されるものと同じです。現在、次のアプリケーション・プロセスが使用されています。

  • 開発チームがアプリケーションの Docker イメージを Artifactory にプッシュして使用できるようにします
    (Artifcatory は、CI/CD ツールや DevOps ツールに統合されるリポジトリー・マネージャ―です。Artifcatory によって、セキュアなクラスター化された高可用性 Docker レジストリーをサポートすることで、アプリケーションで開発から本番に至るまでソース・コード成果物をトラッキングできるようになります)。
  • AppOps チームがチーム固有の git リポジトリー内の構成ファイルを更新し、Kubernetes マニフェスト内の変更とアプリケーションの構成を構成ファイルに反映します。
    • UCD には、SVT、CTE (クラスター・テスト環境)、本番環境用などの環境定義があります。AppOps チームはこのすべての環境で同じデプロイ・プロセスに従ってコンテナーをデプロイします。
    • UCD には、アクセス管理、デプロイのスケジューリング、変更管理を対象とした制御が組み込まれています。この UCD で、環境内で行われたすべてのデプロイメントの監査証跡を維持します。
  • AppOps チームが UCD を使用して git 構成を環境に同期させます。
  • AppOps チームが UCD を使用してイメージを QA 環境にデプロイします。
    • 生成されたログは、各環境/アプリケーションの UCD 履歴の一部として利用可能になります。
  • UCD 環境によって継続的「ハードビート」ヘルス・チェックが開始されます。Jenkins デプロイによって駆動されるこのヘルス・チェックは、AppOps チームが保守する本番環境/アプリケーションごとに、デプロイメントに対して実行されます。
    • 環境内で基本的なユーザー・プロセス全体が機能しなくなった場合 (データベースが利用できなくなり、顧客に影響を及ぼしている場合など)、Slack と PagerDuty によって高優先度のアラートが生成されます。
    • エンド・ツー・エンドのユーザー・プロセスを、デプロイ済みアプリケーションごとに、そのアプリケーションに合わせて構成する必要があります。

現在、すべての環境で Nessus スキャンが有効にされています。さらに、Artifactory 内の Docker リポジトリー内部での Kritis とイメージ・スキャンが検討されているところです。 Kubernetes 環境の完全性を確保するために、デプロイ済みコンテナーのすべてに対して継続的にセキュリティー・テストと機能テストが実行されます。

イメージが本番環境内で使用するのに適切であると判断される条件

コンテナー・コードをスキャンした結果、コンテナーのすべてのコンポーネントに脆弱性がないことが確実になり、QA がコンテナーを承認した場合、そのコンテナー・イメージは本番環境で使用するのに適切であると見なされます。 CI/CD パイプラインに沿ってコンテナーが開発からテスト、CTE などの段階を経る間、コンテナーのテストが継続的に行われます。テストには、機能の検証、リグレッション、パフォーマンス、セキュリティー、さらにその他の関連する側面が含まれます。 イメージがテストに合格して本番環境に移される基準は、開発者チームが主体となり、AppOps チームと連携して決定されます。CI/CD パイプラインに沿ってコンテナーが開発からテスト、CTE などの段階を経る間、コンテナーのテストが継続的に行われます。 テストには、機能の検証、リグレッション、パフォーマンス、セキュリティー、さらにその他の関連する側面が含まれます。イメージがテストに合格して本番環境に移される基準は、開発者チームが主体となり、AppOps チームと連携して決定されます。

使用ケース 2: コンテナー・イメージがテストされた結果、Kubernetes インスタンスのプライベート・レジストリー内で使用するのに適切ではないと見なされた場合

現在一般的な手法となっているのは、イメージを追加するだけのメカニズムです。古いイメージは必ずしも既存のレジストリーから削除されるわけではありません。そうせずに、必要なすべてのパッチとセキュリティー・フィックスが適用された新しいイメージが追加されて、CI/CD パイプラインを辿っていきます。最終的には、レジストリーから不要なイメージを取り除くか、非推奨となったイメージを削除する適切なプロセスとメカニズムを検討することになるはずですが、いずれにしても CI/CD プロセスに大きな影響を与えることはありません。Kubernetes マニフェストは SCM (サプライ・チェーン管理) 内で管理され、すべての環境でまったく同じように生成されることから、古いイメージやセキュアでないイメージが使用されると、検証プロセスの非常に早い段階でそれが判明します。

イメージが本番環境で使用するのに適切でないと判断される条件: イメージが Kubernetes インスタンス内で使用するのに適切でないと見なされるのは、イメージの継続的評価の何らかの時点でセキュリティーまたはアプリケーションの欠陥が発見された場合です。

既存のコンテナー・イメージ・テスト製品: 以下にリストアップする製品は、プライベート・リポジトリー内に配置されたコンテナー・イメージをスキャンして、既知となっているすべての脆弱性または情報漏洩のリスクとは無縁であることを検証し、スキャン結果をユーザーに報告します。

  • Grafeas: Grafeas は、最近 IBM がサポートするようになったオープンソース・プロジェクトです。このプロジェクトでは、Kubernetes およびマイクロサービス・ソフトウェア・サプライ・チェーンに監査とガバナンスの機能を提供することを目的としています。個々の機能コンポーネントを実行する、数々の関連するコンテナーから Kubernetes クラスターが構成される場合、そこにはマイクロサービスが存在します。新しいコードがデプロイされる前に、Kubernetes では Grafeas API を使用して、すべての関連情報を検証することができます。コードに脆弱性がないことが認められると、本番環境にそのコードをデプロイできます。
  • Kritis: Kritis は Google のツールです。このツールは、上記の Grafeas によって生成されたデータを使用して、コンテナーが Kubernetes クラスターのデプロイ時に実行すべきポリシー、実行すべきでないポリシーを判断します。
  • Docker Cloud: Docker Cloud では、ビルド前のイメージを保管したり、Docker イメージをビルドするためのソース・コードにリンクしたりできます。さらに、生成された Docker イメージを Kubernetes インスタンスのプライベート・イメージ・レジストリーにプッシュする前に検証することもできます。
  • Docker Hub: Docker Hub は、イメージをユーザーと共有したり、Docker Cloud へのリンクを共有したりするために使用できる、クラウド・ベースのリポジトリーです。また、このイメージ共有プロセスに関連するイメージ検証コンポーネントもあります。

まとめ

全体的に見て、セキュア・コンテナー・イメージ・パイプラインによって Kubernetes インスタンス内でインスタンス化される Kubernetes コンテナーのセキュリティーと完全性を確保することができます。インスタンスのセキュリティーを確保するには、イメージをイメージ・レジストリーに送信する前に各イメージを承認する権限を持つ担当者、そしてイメージを実際のコンテナーとしてインスタンス化する権限を持つ担当者を決めなければなりません。イメージの承認担当者とデプロイ担当者の間での職務の分離が、不適切なコンテナーや不正なコンテナーが決して使用されないようにするための鍵となります。

承認されたコンテナーが厳格な標準に常に適合するよう確実にするプロセスにおいては、開発チーム、AppOps チーム、インフラストラクチャー・チームがシームレスに協力します。このプロセスの各段階にコンテナーを進めるために採用されているのが、UCD (Urban Code Deploy) です。UCD はまた、コンテナーに障害が発生した場合に適切な担当者が通知されるようにコンテナーのモニタリングが構成されるよう支援します。

この Kubernetes CI/CD セキュア・コンテナー・イメージ・パイプラインの構造と運用に、付随するベスト・プラクティスを統合することにより、Kubernetes インスタンスの安全かつ信頼性の高い、エラー・フリーの運用が確実になります。需要を満たすために随時、コンテナーとその内容を迅速にスケーリングできるようでなければならない高可用性 Kubernetes 環境では例外なく、このベスト・プラクティスに従うことが不可欠です。

現在のベスト・プラクティス

Kubernetes プライベート・リポジトリー内のすべてのコンテナー・イメージに何らかのスキャン・メカニズムを適用することをお勧めします。その一例として、http://imagescanner.bluemix.net/ にアクセスして、無料で利用できる IBM Image Scanning Service を調べてください。

これからのベスト・プラクティス

将来的には、Kubernetes 環境に Grafeas と Kritis をデプロイする必要が出てくるかもしれません。その一方で、CI/CD パイプラインでは TaaS (Testing as a Service) Artifactory を使用していることを考えると、JFrog XrayAquaSec を利用してコンテナーの脆弱性スキャンを実行できる可能性があります。Kubernetes 環境内のプライベート・レジストリーに必ずしもこの Artifactory が必要というわけではありませんが、Artifactory を採用すれば、これが CI/CD プロセス全体ですべてのコンテナー・イメージが通過する単一の通過点になります。これにより、すべての環境に Grafeas と Kritis をインストールしなくても、セキュリティー・スキャンのあらゆるメリットを得ることが可能になります。


ダウンロード可能なリソース


関連トピック


コメント

コメントを登録するにはサインインあるいは登録してください。

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=DevOps, セキュリティ
ArticleID=1064595
ArticleTitle=Kubernetes ベースのアプリケーションを対象とした継続的インテグレーション/継続的デリバリー (CI/CD) セキュア・コンテナー・イメージ・パイプラインを実装する上での IBM のベスト・プラクティス
publish-date=01312019