イメージセキュリティからワークロードセキュリティへ

これは、KubernetesのAppSec戦略構築に関する全4回シリーズの第3回です。第1回はこちら、第2回はこちらをご覧ください。

以前の記事では、組織がコンテナを導入するなかで、アプリケーションのパッケージ化が開発者へと移行していることを取り上げました。しかし、システム管理から開発へと移っているのはパッケージ化だけではなく、構成管理も同様です。

Kubernetesと構成管理の課題

Kubernetes APIは、クラウドネイティブシステムを構築するための強力な抽象化レイヤーです。しかし、APIが豊富な機能を備えていることの意図しない結果として、開発者が大量の構成を主にYAMLで手作業で記述するようになりました。たとえば、次のKubernetes Deploymentの定義を見てみましょう。

apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
labels:
app: nginx
spec:
replicas: 3
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.7.9
ports:
- containerPort: 80

こうした構成ファイルは、多くの場合ソース管理システムに保存されます。アプリケーションコードと一緒に保存されることもあれば、別々に保存されることもあります。GitHubだけでも、公開されているKubernetesの構成ファイルは150万件を超えています。

デフォルトでは安全でない設定

残念ながら、Kubernetesでは構成できる範囲が広いため、さまざまな潜在的なセキュリティ上の問題が生じます。Ian Coldwater氏とDuffie Cooley氏による発表The Path Less Travelledでは、セキュリティの観点からKubernetesのデフォルト設定に関する問題がうまくまとめられています。設定されないことが多い一般的な構成項目には、次のようなものがあります。

こうした構成項目自体は脆弱性ではありませんが、一般に、イメージ内の脆弱性を攻撃者が悪用しやすくします。エクスプロイトが発生した場合、構成によって被害が拡大する可能性もあります。リスクへの露出度は、保有する脆弱性だけでなく、それらが存在する状況にも左右されます。

SDLC全体における構成管理

イメージの脆弱性の場合と同様に、開発者が担うセキュリティ責任が増えるなかで、SDLCの観点から安全な設定を実現するうえでの課題を考えることは興味深いものです。

コンテナイメージのテストと同様、各段階にはそれぞれ異なるトレードオフがあります。1つの段階だけでテストすると、迅速なフィードバックを得られる一方で制御が弱まることもあれば、その逆もあります。イメージの脆弱性への対応と同様に、成熟した最新のセキュリティプロセスでは、複数の段階で構成をテストすることが重要です。

まとめ

アプリケーションを構成するのは、パッケージ化に使うイメージだけではありません。実行に使う構成も含まれます。これまでは、この2つを別々のセキュリティ領域として捉えることが多くありました。しかし、多くの場合、開発者向けのコンテナセキュリティに関する議論は、イメージの脆弱性だけに焦点を当ててきました。アプリケーションセキュリティの責任が開発チームへと移るなかで、イメージの脆弱性と構成の関係を理解し、両方を安全に保つツールを活用することがますます重要になっています。