Kubernetes のデータセキュリティ

このページでは、Datadog に送信されるデータのセキュリティについて説明します。クラウドやアプリケーションのセキュリティ製品や機能をお探しの場合は、セキュリティのセクションをご覧ください。

このガイドでは、Kubernetes 環境のセキュリティとモニタリングシステムの必要な機能の両方を維持できるように、Datadog Agent のデプロイと構成時に Kubernetes の権限とセキュリティを制御する方法を説明します。

権限と運用上の必要性

Kubernetes セキュリティのコンテキストでは、最小特権の原則とDatadog Agentのような重要なコンポーネントの円滑な運用との間でバランスを取ることが不可欠です。Kubernetes のポッドセキュリティ標準や CIS Benchmarks は、昇格されたアクセス違反を避けるために、頻繁に権限の最小化を強調しますが、Datadog Agent のようなモニタリングツールが最適なパフォーマンスのために特定の権限を要求する可能性があることを認識する必要があります。

よくあるセキュリティ標準違反

Kubernetes ポッドセキュリティアドミッションにおけるリストリクテッドセキュリティレベル

リストリクテッドポッドセキュリティ標準は、組み込みのAdmission Controllerによって強制される最も厳しいセキュリティ標準レベルです。それは、互換性と機能を犠牲にして、ポッドセキュリティのベストプラクティスを適用することを目的としています。想定されるユースケースには、機密性の高い金融情報や個人識別情報 (PII) を処理するアプリケーションが含まれます。

リストリクテッドポッド標準で Datadog Agent を実行すると、Agent が機能するために必要なデータにアクセスできなくなり、それは推奨されません。

hostPID で実行しているポッド

ホストのプロセス ID (PID) ネームスペースで実行しているコンテナは、コンテナ外部で実行しているプロセスを検査することができます。コンテナが ptrace 機能にもアクセスできる場合、これを使用してコンテナ外の特権を昇格させることができます。

DogStatsD は、UDP ポートまたは Unix Domain Socket を介してメトリクスを受信するように構成できます。Unix Domain Socket を使用すると、パフォーマンスの向上、エラー処理、送信元検出などの利点があります。コンテナ内で実行する場合、DogStatsD は、送信元検出が確実に機能するためには、ホストの PID ネームスペース内で実行する必要があります。送信元検出を無効にすることも可能ですが、これにより、DogStatsD によって収集されたメトリクスは、コンテナレベルでのタグ付けがされなくなります。

hostPath ボリューム

Kubernetes で hostPath ボリュームを利用すると、システム資格情報が不注意にも漏洩することや、特権 API への不正アクセスなど、潜在的なセキュリティ脆弱性が発生する可能性があります。しかし、Datadog Agent は、ホストレベルのリソースの効果的な監視のためには、ホストへの直接アクセスが必要です。

hostPath ボリュームはセキュリティ上の懸念事項となり得ますが、Datadog Agent がホストレベルでの監視を必要とするため、これらのマウントは不可欠です。Datadog Agent が必要とする hostPath ボリュームは、必要なパスに限定され、可能な場合は常に読み取り専用モードでマウントされるべきです。

明確に定められた範囲内で以下の hostPath マウントを有効にすることで、組織は、監視のために必要なアクセスを提供しつつ、Kubernetes 環境のセキュリティを保持するバランスを見つけることができます。

マウント説明
procdir読み取り専用モードでマウント。システムチェックに使用。
cgroups読み取り専用モードでマウント。コンテナのメタデータ収集に使用。
os-release-file読み取り専用モードでマウント。OS 検出に使用。
dsdsocket読み書きモードでマウント。DogStatsD ソケット、オプションでポートで構成可能。
apmsocket読み書きモードでマウント。APM ソケット、オプションでポートで構成可能。
passwd読み取り専用モードでマウント。Process Agent がプロセスとユーザを関連付けるために使用。
runtimesocketdir読み取り専用モードでマウント。コンテナのメトリクス収集に使用。

コンテナを root ユーザーとして実行

Kubernetes 環境では、コンテナは任意の Linux ユーザーとして実行できる柔軟性があります。コンテナランタイムのセキュリティ機能によってある程度の制約はあるものの、コンテナを root ユーザーとして実行すると、コンテナからの脱出のリスクが高まる可能性があります。そのため、ベストプラクティスを遵守し、特に通常のワークロードにおいては、コンテナを非 UID 0 ユーザーとして実行することを推奨します。

Datadog Agent のデフォルト構成は、標準的な kubelet やコンテナソケット構成と高い互換性を持つように設計されており、コンテナ内で root ユーザーとして実行されます。このデフォルト構成は、互換性を最大化するために選択されています。Agent を非 root ユーザーとして実行するように構成することは可能ですが、インテグレーションを適切に機能させるためには、特別な考慮事項やホストの基本構成の更新が必要になる場合があります。これらには以下が含まれます。

  • Datadog は dd-agent ユーザー (UID: 100) の使用を推奨します。このユーザーはコンテナイメージ内に作成されます。
    • 注: Agent バージョン 7.47.0 以下では、UID: 101 を使用してください。
  • コンテナランタイムソケットは、Agent ユーザーによるアクセスを許可するように構成する必要があります。
  • ログ収集のためには、kubelet によって生成されたログに Agent ユーザーがアクセスできる必要があります。
  • インテグレーションによっては、ホスト上のコマンドやファイルにアクセスできないために失敗することがあります。

参考資料

お役に立つドキュメント、リンクや記事:

Datadog に送信されるデータの主要カテゴリを確認するドキュメント more more