fbpx

[和訳] Docker EEによるKubernetes向けの安全なサプライチェーン #docker #kubernetes #k8s

DockerKubernetes

この記事は1年以上前に投稿されました。情報が古い可能性がありますので、ご注意ください。

本稿は A Secure Supply Chain for Kubernetes (2018/2/28) の和訳です。

コンテナプラットフォームであるDocker Enterprise Edition (Docker EE)は2018年1月のベータ版リリース においてオーケストレーションツールKubernetesを統合しました。これによりKubernetesをSwarmと並行して運用でき、オンプレミス内あるいはクラウド上で、レガシーアプリケーションと新しいアプリケーション両者の実行を、1つのコンテナプラットフォームでサポートできるようになりました。Kubernetesを検討している、またはKubernetesを本番環境にデプロイしている企業向けに、Docker EEはコンテナ化したアプリケーションのライフサイクル全体における一貫したセキュリティを提供します。実行中のアプリケーションを安全に保つほか、Kubernetesを用いてワークロードをデプロイする前段階としてのセキュリティレイヤも新たに追加しました。

Mike Coleman氏 は以前、Kubernetes向けアクセス制御 について言及しました。2月にはDocker EEがいかにしてKubernetesによるサプライチェーンを安全に保つかについて議論を始めました。

ソフトウェアサプライチェーンとは

例えばあなたがお店で何か商品を買うとします。その商品が、素材から製品になり、消費者の手にわたるまでのプロセスをサプライチェーンと呼びます。同様に ソフトウェアサプライチェーン というものがあります。これは開発者のパソコン上のコードから、本番環境で実行するアプリケーションとなるまでのプロセス全体を指します。

ソフトウェアサプライチェーンは各企業や組織によって若干の違いがあるでしょう。それはソフトウェア開発を外注している企業もあれば、CI／CDプロセスを採用している企業もあるからです。また本番用アプリケーションのデプロイ先もさまざまで、多数のクラウド上であったり、オンプレミス上であったりという違いがあります。しかしソフトウェアサプライチェーンがどのような構成であろうと、Docker EEはKubernetesとSwarmの両方を使用するすべての手順を通して、アプリケーションの安全性と信頼性を保ち、ワークフローとうまく適合する一連のソリューションを提供しています。

今回はそのソリューションの一部である、イメージスキャンとセキュリティポリシーによるイメージプロモーションに焦点を当てたいと思います。

Kubernetes向けワークフローの安全な自動化

企業の多くは本番環境にアプリケーションをデプロイする前に、ソフトウェアのバージョンが古い・パッチの未適用が原因である既知の脆弱性がないことの確認を望んでいるでしょう。また組織が大きいほど、実行中のすべてのアプリケーションに影響を及ぼす可能性のある、新たな脆弱性をリスト化しておくことは困難です。

そこでDocker EEは、本番環境におけるアプリケーションのデプロイに先立って行う脆弱性の特定と、既存のアプリケーションに影響を及ぼす新たな脆弱性に対する警告の両面でサポートするための、イメージのセキュリティスキャンを提供しています。セキュリティスキャンは既知の脆弱性のNISTリストに対して、イメージのバイナリレベルのスキャンを行うことによって実行できます。次のスクリーンショットの通り、イメージの各レイヤをくまなくスキャンし、その結果をワークロードに提供します。

Docker EEはまた、リポジトリ間のイメージの動きを自動化するためのポリシーを定義する機能も有しています。これらのイメージプロモーションポリシーは、本番環境に移行するイメージの安全な自動化ワークフローを作成するために、セキュリティスキャンの結果と組み合わせることができます。

例えば、ある開発者がイメージをプッシュおよびプルできる"dev"リポジトリへのアクセスを伴った、新たなKubernetesプロジェクトに取り組んでいるとします。リポジトリにプッシュしたイメージをすべて自動スキャンするように、リポジトリにはイメージスキャンを設定しています。開発者はそのイメージを本番環境に移動する際、"latest"などの特定のタグをそのイメージに追加します。リポジトリにはイメージプロモーションポリシーを設定しています。これにより"latest"とタグ付けされているか否かや、重大な脆弱性の有無を明示し、そのイメージを自動でコピーをしたり、"QA"リポジトリに移します。

今回の例では、QAチームのみがQAフォルダへのアクセス権を有し、他のユーザのアクセス権限の付与を必要に応じて行っています。このセキュリティポリシーは、QAチームに渡す前に開発者が必ずすべての脆弱性を修正する責任があることもまた保証しています。

Docker EEのこれらの機能を組み合わせることで、企業や組織は次のことが可能になります:

  • 大規模なリポジトリ間でのイメージの移動を自動化できる
  • 開発における特定の段階で、セキュリティスキャンの実施の強化を図ることができる
  • 既知の脆弱性を伴うアプリケーションを本番環境でデプロイすることを防ぐことができる
  • 取り扱いに注意が必要なレポジトリ（"production"など）へのアクセスを、適切なポリシーを定義することによって、プロセスにおけるボトルネックを取り除きながら、必要なユーザにのみ権限を付与することができる

これらはすべて、Kubernetesを使用してアプリを本番環境でデプロイすることに先立って行う重要なワークフローです。Docker EEでは、サプライチェーン全体にわたるセキュリティを伴ったコンテナプラットフォームのみを提供しています。Kubernetes向けのDockerによる安全なサプライチェーンの詳細につきましては、次のオンデマンド動画をご覧ください。

Docker EEのKubernetes統合についてもっと知りたい方は:

新規CTA