Skip to main content

Kubernetes設定セキュリティの発表とウェビナーの振り返り

Kubernetes Blog

2020年4月10日

0 分で読めます

4月8日(水)に開催した、Kubernetes設定セキュリティのリリース発表ウェビナーにご参加いただいた皆さま、ありがとうございました。この新機能を皆さまにお使いいただき、ご意見や、Kubernetesアプリケーションのセキュリティを維持するために今後実現してほしいことをお聞きできるのを楽しみにしています。

ウェビナーでは多くのすばらしい質問をいただきました。また、ライブで参加できなかった方も多くいらっしゃるため、概要を簡単に振り返り、イベント中に回答できなかった質問にもお答えします。Q&Aに直接移動するにはこちらをクリックしてください。すぐに使い始めたい方は、「有効にするには?」のセクションまで進んでください。

コードによるワークロードとアプリケーションのデプロイが増加

現在では、ほぼあらゆるものが何らかのコードで設定されています。インフラストラクチャには、Terraform、AWS CloudFormation、Azure Resource Managerなど、さまざまな形式やツールを使っていることでしょう。一方、コンテナの世界ではKubernetesが事実上の標準であり、YAMLやJSON、あるいはHelmのような高水準のツールが使われています。いずれも開発者やDevOps担当者が作成するコードであり、変更を加えたらすぐにアプリケーションをデプロイするために使われます。

「膨大な数の構成」と書かれた図。オレンジ色の円に、Azure ARM 250k+、Terraform 140k+、AWS CF 90k+、Kubernetes 2m+、Compose 600k+、そして「

セキュリティの観点からは、これは懸念すべき状況です。YAMLが怖いという話ではありません(それはまた別の理由で怖いものですが)。Kubernetesにはセキュリティのゲートがほとんどなく、コードが有効であれば、Kubernetesはその実行に最善を尽くします。そのため、適切な制御がコードに実装されているかどうかは、アプリケーションチームに委ねられています。こうした設定を保護するツールは、通常、稼働中のKubernetesワークロードやクラスターを調べて問題を特定します。しかし、問題に気づくのがデプロイ後では手遅れです。特に、週に何度も、場合によっては1日に何度もデプロイする環境ではなおさらです。

Kubernetes設定の問題をソースで検出・修正

Snykが掲げる中核的な目標の一つは、開発者がセキュリティ上の問題に自ら対処しやすくすることです。設定セキュリティという新たな領域でも、私たちは貢献できると考えています。新しいKubernetes設定セキュリティ機能はソースコード管理ツールと連携し、KubernetesのYAML、JSON、Helmチャートを検出して、セキュリティ上の問題がないかチェックします。

purpleco/cloud-native-configsリポジトリ内のKubernetes構成ファイルについて、セキュリティ上の問題の件数を表示するSnykのインターフェース。

開発者のためのKubernetes設定修正s

問題が検出されると、設定ファイル内の該当箇所を直接ハイライト表示するため、変更が推奨される箇所をすばやく確認できます。また、検出された問題について説明を表示し、それぞれの設定がもたらす影響を理解できるようにします。問題ごとにKubernetesのリファレンスドキュメントを探し回る必要はありません。リスクの分類設定はカスタマイズ可能で、必要に応じて特定の設定チェックを無視することもできます。

特権モードで実行されているKubernetesコンテナと、YAMLのsecurityContext設定コードを示すセキュリティ問題パネル。

ウェビナーQ&A

ウェビナーではすばらしい質問をたくさんいただきました。すべての質問に回答できるよう、ここにまとめました。

Q. どのKubernetes環境でも使えますか?

現在は、ソースコードリポジトリ内のKubernetes設定ファイル(YAML、JSON、Helm)をスキャンしています。そのため、ワークロードの実行に使用するKubernetesディストリビューションは問いません。推奨する対策はすべてKubernetesの仕様に基づいているため、どのディストリビューションでも適用できます。

Q. KubernetesのYAMLファイル以外にも対応していますか?

現在、YAML、JSON、Helmチャートを検出し、問題がないかスキャンしています。YAMLジェネレーターやテンプレート処理を行うツールを使用している場合も、サポート対象のファイル形式を検出してスキャンできれば、通常はその多くで機能します。

Q. どのような設定上の問題を検出できますか?

設定上の問題は数多くあり、今後も順次追加していく予定です。現在検出できる問題は、Snykコンソールの製品設定から確認できます。上部の横方向メニューで「Settings」をクリックし、左側のサブメニューから「Infrastructure as code」を選択すると、検出項目が表示されます。重大度をカスタマイズしたり、検出を無視したりすることもできます。以下の画面で手順をご確認ください。

Infrastructure as Code、設定ファイル検出の有効化、Kubernetesデプロイの設定ミスの検出結果を強調表示したSnykの設定ページ。

Q. この機能を使うには、有料のSnykプランが必要ですか?

いいえ!この機能は、無料・有料を問わず、すべてのSnykユーザーにご利用いただけます。機能は段階的に展開しており、1週間ほどですべてのアカウントで有効になる予定です。オンプレミス版をご利用のお客様は、オンプレミス環境のサポートについてアカウントチームにお問い合わせください。

Q. この機能はいつ利用できるようになりますか?

ほとんどのアカウントですでに有効になっています。現在ご利用いただけない場合も、1週間以内には表示される予定です。アカウントで機能を有効にする必要がある場合があります。詳しい手順は以下をご覧ください(ヒント:「Settings」メニューの「Infrastructure as code」を確認してください)。

利用を開始する

Kubernetes設定セキュリティ機能は簡単に使い始められます。機能や使い方に関する最新情報は、Snykのドキュメントをご覧ください。ここでは概要をご紹介します。

アカウントで機能を有効にします。

新しいSnykアカウントでは、この機能はデフォルトで有効になっているはずです。既存のユーザーは、Kubernetes設定のスキャン機能を有効にする必要がある場合があります。Snykウェブコンソールのメインメニューから「Settings」を開き、サイドメニューで「Infrastructure as code」を選択します。「Enabled」スライダーをクリックしてから、「Save changes」ボタンをクリックすると、設定を確認できます。

Infrastructure as Codeの設定、有効ステータス、「変更を保存」ボタンを強調表示したSnykの設定ページ

SCMからKubernetes設定ファイルをスキャンして修正する

現在、Kubernetes設定のスキャン機能はソースコード管理ツールと連携します。そのため、アカウントでサポート対象のGitリポジトリのいずれかとのインテグレーションを設定する必要があります。リポジトリ内のKubernetes設定ファイルを検出し、推奨される修正を提示します。すでにリポジトリをアカウントに追加してSnykでスキャンしている場合でも、Kubernetes設定ファイルを検出して該当するプロジェクトを作成するには、リポジトリを再度インポートする必要があります。

Kubernetes設定ファイルと脆弱性スキャンのステータスを表示するSnyk Projectsのダッシュボード

新しいKubernetesセキュリティ機能の開発を続けるにあたり、ぜひ皆さまのご意見をお聞かせください。

安全な開発を!

開発者ファーストのコンテナセキュリティ

Snykは、コンテナイメージとKubernetesワークロードの脆弱性を検出し、自動的に修正します。

カテゴリー:

続きを読む

blog feature pypi spoof
Article

オープンソースのメンテナーに、Snyk AI Security Platformをすべて無料で提供

オープンソースのメンテナーは、実際の脆弱性レポートに追われ、優先順位付けや修正、修正版のリリースを迅速に進めるための支援を必要としています。SnykのSecure Developer Programでは、条件を満たすプロジェクトにSnyk AI Security Platformを無料で提供します。

Article

メンテナーアカウント侵害が疑われる中、悪意のあるnode-ipcのバージョンがnpmに公開

2026年5月14日、人気のnpmパッケージnode-ipcの複数の悪意あるバージョンがnpmレジストリに公開されました。現在の公開情報では、node...

blog feature toolkit
Blog

elementary-dataのPyPIパッケージに悪意あるリリース、データエンジニアのクラウド認証情報を窃取

攻撃者はGitHub Actionsのスクリプトインジェクション脆弱性を悪用し、悪意あるバージョンのelementary-data Python CLI(v0.23.3)を公開しました。データエンジニアリング環境のdbtプロファイル、クラウドプロバイダーのキー、SSHシークレットを標的とする認証情報窃取バックドアが埋め込まれていました。