Google Cloudとコンテナの継続的なセキュリティ
本文の内容は、2019年10月29日にSysdigのEric Carterが投稿したブログ(https://sysdig.com/blog/sysdig-2019-container-usage-report/)を元に日本語に翻訳・再構成した内容となっております。
本日、Sysdig 2019 Container Usage Reportをリリース致しました。 Kubernetesの勢いが継続し、クラウドネイティブアーキテクチャーの採用が拡大する事により、利用パターンだけでなく、プロセスや組織構造も変化しています。今年の驚くべき洞察の1つは、5分間未満しか存続しないコンテナの数が2倍に増加したことです。サービスがより動的に成長するにつれて、クラウドチームはセキュリティをDevOpsプロセスに統合する必要性を認識しています。2019年のUsage Reportの一部として、お客様がコンテナーやKubernetesなどをどのように使用しているかに関するさまざまな詳細に加え、セキュリティとコンプライアンスの詳細を調査を新たに追加しています。
Sysdig Secure DevOps Platformは、インフラストラクチャー、アプリケーション、およびコンテナの実際の状況を把握でき、世界中のさまざまな業界の企業で活用されています。 今年は、SaaSユーザーとオンプレミスのSysdigユーザーの両方からの詳細を組み込み、200万をはるかに超えるデプロイされたコンテナ全体のエンタープライズ企業の使用状況のスナップショットをレポートします。
では、結果を掘り下げて(dig)いきましょう！
2018年のレポートでは、Open Container Initiative（OCI）が代替コンテナーランタイムの先駆けとしてどのように役立っているかを説明しました。これは2019年に大々的に起こり、コンテナ化により18％の大きなシェアを獲得しました。 公平を期すために、Dockerはcontainerdを使用していることに着目ください。Dockerエンジンは、以前は高レベルと低レベルの両方のランタイム機能を実装していました。 これらは、個別のcontainerdプロジェクトとruncプロジェクトに分割されました。
今年はCRI-Oがデビューしました。 驚いたことの1つは、これまでの採用率が小さいことです。 Kubernetesの軽量ランタイムであるCRI-Oは、2016年にRed Hatで開始され、2019年にCNCF®に採用されました。Red Hat OpenShiftを実行しているお客様がv3からv4に移行するにつれて、使用率が増加すると予想されます。v3で使われていたDockerエンジンは、V4でCRI-Oに置き換わります。
過去1年間で、ホストあたりのコンテナーの数の中央値は30に倍増し、2018年は15、2017年は10でした。
この数は、いくつかの要因に基づいて増加すると予期していました。
2019年のノードあたりの最大密度は250コンテナで、2018年から38％増加しました。
事実上のコンテナオーケストレーションツールとして利用されている、Kubernetesがオーケストレーターの77％のシェアを占めることは驚くことではありません。 Red Hat OpenShiftとRancher（どちらもKubernetesで構築）を追加すると、その数は89％に拡大します。 現在の内訳は次のとおりです。
Sysdigプラットフォームをオンプレミスでデプロイする企業のデータを抽出すると、オーケストレーションの状況は大きく変わります。 このセグメントでは、Red Hat OpenShift Container Platformがトップです。 主に、これらの組織（通常、より大規模でリスクを回避する）はKubernetesの利点を活用したい一方で、OpenShiftなどの商業的にサポートされているオンプレミスのPlatform-as-a-Service（PaaS）ソリューションを使用することを好んでいると考えられます。
また、2019年のレポートでは、パブリッククラウドの使用の内訳についても調査しています。 今すぐダウンロードして詳細を確認してください。
「セキュリティを左へシフト」は、セキュリティを開発ライフサイクルの初期段階に組み込むことを指す話題フレーズになりました。 実際、コンテナを扱う組織は、セキュリティとコンプライアンスをDevOpsワークフローに統合する必要性を認識しています。 コンテナとKubernetesのセキュリティとコンプライアンスの状態に関する洞察を提供するために、脆弱性スキャン、ランタイムセキュリティ、およびCISコンプライアンスに関するデータを分析しました。
お客様は、イメージをスキャンして、CI/CDパイプラインおよびコンテナーレジストリ内のコンテナーの脆弱性を識別、ブロック、および解消します。 全体のレポートでは、使用中のレジストリ、パブリックリポジトリとプライベートリポジトリから取得したイメージの割合を確認します。 また、イメージの脆弱性をスキャンする際の成功/失敗率もサンプリングします。 ここに私たちが学んだいくつかの事柄があります。
パブリックリポジトリとプライベートリポジトリからPullされるコンテナの数は？ イメージの40％がパブリックソースからのものであることがわかりました。
パブリックリポジトリのコンテナイメージを使用するリスクは、セキュリティの脆弱性について検証またはチェックされるものがほとんどないことです。 Docker Hubを例にとると、「Certified」、「Official」、および「Verified Publisher」のイメージは信頼できる可能性があります。 ただし、ホストされている約300万のイメージのうち、これらの指定が含まれているのは1％未満です。 リスクを軽減するために、クラウドチームは、組織での使用が承認されているコンテナレジストリを定義するポリシーを作成しています。
コンテナーイメージのソースに関係なく、実稼働環境にデプロイする前に既知の脆弱性を識別するためにイメージスキャンを実行することは、手抜きすべきではないベストプラクティスです。脆弱性のリスクの範囲を定量化するために、5日間にわたってスキャンされたイメージの合否率をサンプリングしました。 イメージの半分以上が失敗しました。つまり、重大度が高またはそれ以上の既知の脆弱性があることがわかりました。
開発において既知の脆弱性に対処したら、クラウドチームはポリシーを設定して異常な振る舞いを検出し、運用環境でセキュリティアラートをトリガーする必要があります。 組織は、Kubernetesのランタイムセキュリティへの対処し始めている状況です。しかし、悠長に対応を行うべき状況ではありません。 過去12か月間に、Sysdigが提供したCNCFオープンソースランタイムセキュリティプロジェクトであるFalcoのDocker Hub Pullは670万を超えました。これは、前年比252％の増加です。
Falcoのポリシーを使用してランタイムセキュリティを自動化を実現しているSysdig Secureからお客様が受け取るアラートの量で測定されたポリシー違反を調査しました。 これは、コンテナユーザーが最も頻繁に発生するランタイムセキュリティリスクのタイプを示しています。 コンテナランタイムのセキュリティリスクの主なものは次のとおりです。
完全版のusage reportでは、頻度の高い順に上位10件の違反を詳細に説明し、想定される脅威の説明も記載しています。
リスクを軽減し、PCI-DSS、HIPAA、GDPRなどのコンプライアンス基準を満たすために、組織はホストとコンテナーを一連のベストプラクティスに照らして定期的にチェックする必要があります。Sysdig SecureにおけるDockerをチェックするためのCISベンチマークを使用して実行された監査は、改善の余地を明らかにします。たとえば、中央値では、コンテナホストが次のようになっていることがわかりました。
オープンソースは、エンタープライズコンピューティングの現実を変えました。 インフラストラクチャだけでなく、特にアプリケーション開発全体のイノベーションを促進します。Sysdigは、コンテナー内のプロセスを自動検出して、お客様が運用環境で実行するクラウドネイティブサービスを構成するソリューションを即座に把握できます。トップ10は次のとおりです。
今年の新顔は、Javaの使用を追い抜くNode.jsとGo（別名golang）の登場です。Javaは長い間、最も著名なプログラミング言語の1つです。DevOpsとCloudチームは、使いやすさも理由の1つとして、Googleエンジニアが作成したGoなどの新しいオプションを好むようです。たとえば、JavaScriptランタイムであるNode.jsを使用すると、サーバーだけでなくブラウザーでも同様に実行されるコードを簡単に作成できます。また、JavaScriptで記述されたクエリをサポートするCouchDBやMongoDBなどの新世代のデータベースにも適しています。
コンテナー、コンテナーイメージ、およびサービスの存続期間（または短期間）の測定値は、2018年のレポートで最も人気のあるデータポイントの1つでした。 開発とランタイムの両方の観点から、最新のアプリケーションがどれだけ動的であるかを反映しています。
コンテナのライフスパンを年ごとに比較すると、10秒以内で生存しているコンテナの数が22％に倍増していることがわかりました。 実際、5分以内で存続するコンテナの数も2倍に増加しました。
多くのコンテナは、関数を実行し、その関数が完了したときに終了するのに十分な長さである必要があります。 秒は短いように見えるかもしれませんが、一部のプロセスでは、必要なのはそれだけです。 バッチジョブのような有限のタスクを実行するKubernetesジョブの使用の増加が、この成長に貢献したと考えています。 実際、特に短期間タスクを実行するのに適したサーバーレスプラットフォームでは、短いライフスパンが延びると予想されます。
コンテナのエフェメラルな性質は、このテクノロジーのユニークな利点の1つです。 同時に、一時的なコンテナは、セキュリティ、健全さ、およびパフォーマンスの問題を把握する上での課題になる可能性があります。 短時間のプロセスに照らしてリアルタイムの可視性を提供するリアルタイムの監視、セキュリティ、コンプライアンスツールは、運用を成功させるための鍵と言えます。
コンテナは、アジャイルな取り組みにおいて必須です。 多くの場合、コンテナ化されたマイクロサービスとして、コードの開発とリリースを加速します。 コンテナイメージの半分以上が、1週間以内に置き換えられている事がわかりました。これは、コードのリリース間隔の短縮を反映しています。 さらに、CI/CDパイプラインは、開発者チームがこれまでよりも速いペースでソフトウェアの更新をデリバーするのを支援していることを示しています。
カスタムメトリクスは、開発者とDevOpsチームにコードをインストルメントして一意のメトリクスを収集する方法を提供します。 3つの主力ソリューションであるJMX、StatsD、およびPrometheusのうち、過去1年間でPrometheusが使用中のトップソリューションとして注目されました。 実際、Prometheusのメトリクス使用量は、カスタムメトリックを使用する顧客全体で前年比で130％増加しました。 JMXメトリクス（Javaアプリ用）およびStatsDは、Prometheusをサポートする新しいプログラミングフレームワークの使用がそれぞれ45％および17％減少しています。
完全版のレポートをチェックして、Sysdigの顧客が使用している上位のPrometheusメトリクスとエクスポーターも確認してください！
Sysdigユーザーによって設定されたアラートは、クラウドチームがコンテナー運用を最も混乱させるものと見なすものを示しています。最も一般的に使用されるアラート条件は、リソースの使用率と稼働時間に焦点を合わせながら、Kubernetesインフラストラクチャに移行しています。Sysdigの顧客全体で使用されている800以上の固有のアラート条件のうち、上位3つを以下に示します。
さらに、アラートは、特定のタグまたはKubernetes /クラウドラベルに合わせて微調整または「スコープ」できます。 たとえば、上記のアラートの例を使用して、「istio-system」などの個々のネームスペース、またはそのネームスペース内の「envoy」などの特定のポッド名に対してcpu.used.percentアラートを指定できます。 完全版レポートの上位のアラートスコープを確認してください。
いくつのクラスターを運用していますか？ ノードごとに実行されるPodの数 Kubernetes Jobsを使用している人はいますか？ 2019年のレポートでは、これらの質問などに回答しています。 お客様がKubernetesでデプロイしているサンプルを次に示します。
一部の顧客は、いくつかのクラスター（小規模、一部は大規模）を維持していますが、他の顧客は、さまざまなサイズの多くのクラスター資産を所有しています。 次のグラフは、Sysdigプラットフォームユーザーのクラスター数とクラスターごとのノードの分布を示しています。
シングルクラスター、かつ、比較的少数のノードのみを使用している多数の顧客群は、Kubernetesの使用が初期段階にある事を示しています。また、パブリッククラウドで管理対象のKubernetesサービスを使用すると、これらのデータポイントに影響することも認識しています。 Amazon Elastic Kubernetes Service（EKS）、Google Kubernetes Engine（GKE）、Azure Kubernetes Service（AKS）、IBM Cloud Kubernetes Service（IKS）などのサービスを使用すると、ユーザーは必要に応じてクラスターをすばやく起動および破棄できます。
ポッドはKubernetesでデプロイ可能な最小のオブジェクトです。 これらには、共有ストレージとネットワークを備えた1つ以上のコンテナと、コンテナの実行方法の仕様が含まれています。Sysdigプラットフォームユーザー全体の内訳は次のとおりです。
ポッドは、プロセスが完了するか、リソースが不足してポッドがノードから削除されるか、ノードが失敗するまで、ノードに残ります。 Sysdigプラットフォームユーザー全体のノードごとのポッドのスナップショットは次のとおりです。
Kubernetesのネームスペース、デプロイメント、StatefulSets、およびJobsに関する洞察は、完全版のレポートに記述しています。
前回のusage report以来から、コンテナ密度が倍増している状況は、使い方が成熟し、採択率が加速していることを示しています。今回で３回目となる年次のレポートでは、大規模拡大が予期される状況に企業が準備を始めていると洞察されます。
詳細については、Sysdig 2019 Container Usage Reportの完全版を今すぐダウンロードしてください。
