nicholasjackson/cnitchContainer Snitchは、Docker Engine上で実行中のプロセスをチェックし、ルートとして実行されているプロセスが見つかった場合に警告を発します。
cnitch（スニッチまたはコンテナスニッチ）は、Dockerコンテナを監視し、rootで実行されているプロセスを特定するためのシンプルなフレームワークおよびコマンドラインツールです。
なぜこれが悪いことなのでしょうか？ mhausenblas による「can I haz non-privileged containers?」 をまだご覧になっていないなら、今すぐアクセスして詳細を入手することをお勧めします。
cnitch を開発中に、アプリケーションのバグだと思われる問題に遭遇しました。cnitch が Docker コンテナ内で自身を root プロセスとして報告していたのです。Dockerfile には明示的に root ではなくユーザーを作成するように記述していたため、なぜこのようなことが起こるのかわかりませんでした。デバッグと検証を重ねた後、Dockerfile を再確認したところ、次の箇所が見つかりました。
FROM alpine
RUN adduser -h /home/cnitch -D cnitch cnitch
COPY ./cmd/cnitch /home/cnitch/
RUN chmod +x /home/cnitch/cnitch
#USER cnitch
ENTRYPOINT ["/home/cnitch/cnitch"]
アプリケーションコンテナをテストして Docker ソケットの権限の問題を調査していた際、USER コマンドをコメントアウトしてしまったようです。なかなかメタな話です。cnitch が cnitch 自身の問題を発見するのに役立ちました。これは統合テストに完全に組み込む予定です。
cnitch は API を介して Docker エンジンに接続し、現在実行中のコンテナを照会します。次に、このコンテナ内で実行されているプロセスを検査し、root ユーザーとして実行されているものを特定します。
root プロセスが見つかると、この情報は設定可能なレポートモジュールに送信され、この情報を監査したりアクションを起こしたりできるようになります。
2017/07/29 16:04:27 Cnitch を起動: Docker プロセスを監視中 at: tcp://172.16.255.128:2376
2017/07/29 16:04:27 root プロセスをチェックする間隔: 10s
2017/07/29 16:05:08 イメージをチェック中: ubuntu, id: 7bd489560a310343c39186500daa680290289c27f7a730524a31355a3aaf0430
2017/07/29 16:05:08 >> 警告: プロセスが root で実行中: tail -f /dev/null pid: 365
現在、cnitch は StatsD および StdOut へのレポート機能を備えています。レポートバックエンドは拡張可能で、任意のバックエンドを簡単にサポートできます。たとえば、ログスタッシュや他のログファイル集約ツールをサポートするバックエンドを構築するのはかなり簡単な作業です。
例外は cnitch.exception.root_process メトリクスを使用してカウントとして statsD エンドポイントに送信されます。メトリクスには cnitch インスタンスの host 名と container 名のタグも付けられます。
StdOut ロガーは単純な出力ロガーで、報告された例外を StdOut に送信します。
cnitch を Docker コンテナ内で実行する場合でも、バイナリとして実行する場合でも、環境変数 DOCKER_HOST にサーバーの URL またはソケットのパスを設定して、Docker API にアクセスできる必要があります。
--hostname=[ホスト名] メトリクス集約に使用する名前または IP アドレス--statsd-server=[ホスト名:ポート] statsd コレクタの URI。省略すると statsd レポートが無効になります--check=[期間 例: 10s (10秒)、1m (1分)]、snitch が root プロセスをスキャンするチェック頻度環境変数 DOCKER_HOST を Docker エンジン API に設定し、必要なフラグを指定して snitch を実行します。
$ cnitch --hostname=myhost --statsd-server=127.0.0.1:8125 --check=10s
cnitch は非特権コンテナで実行され、Docker ソケットを使用して API にアクセスする場合は、cnitch ユーザーを docker グループに追加する必要があります。これは --group-add フラグを使用して実現できます。このフラグには docker ユーザーグループのグループ ID を設定します。
例:
--group-add=$(stat -f "%g" /var/run/docker.sock)
API アクセスに Docker ソケットファイルを使用する例
$ docker run -i -t --rm \
-v /var/run/docker.sock:/var/run/docker.sock \
--group-add=$(stat -f "%g" /var/run/docker.sock) \
-e "DOCKER_HOST:unix:///var/run/docker.sock" \
quay.io/nicholasjackson/cnitch [options]
Mac で Docker Machine を使用している場合、Docker ソケットは VM 内にあるため、stat コマンドを使用してグループ ID を確認することはできません。
./example フォルダ内に、cnitch が statsd にデータをエクスポートする方法を示す Docker Compose スタックの例があります。この例を実行するには:
$ cd ./example
$ docker-compose up
すべてが起動したら、Web ブラウザで http://[docker host ip]:3000 を開くと、Grafana のログイン画面が表示されるはずです。
次の認証情報を使用して Grafana にログインします:
次に、cnitch ダッシュボードを選択します。このダッシュボードには、現在実行中の root プロセスが表示されます。
/var/run/docker.sock を使用して Docker ホストと通信していない場合は、ファイル ./example/docker-compose.yml 内のいくつかの設定を環境に合わせて変更する必要があります。
Docker Bench Security スクリプト https://github.com/docker/docker-bench-security の機能を実装します。
[ ] 1.1 コンテナ用に別のパーティションが作成されていることを確認
[ ] 1.2 コンテナホストが強化されていることを確認
[ ] 1.3 Docker が最新であることを確認
[ ] 1.4 信頼できるユーザーのみが Docker デーモンを制御できることを確認
[ ] 1.5 Docker デーモンに対して監査が設定されていることを確認
[ ] 1.6 Docker ファイルとディレクトリ - /var/lib/docker に対して監査が設定されていることを確認
[ ] 1.7 Docker ファイルとディレクトリ - /etc/docker に対して監査が設定されていることを確認
[ ] 1.8 Docker ファイルとディレクトリ - docker.service に対して監査が設定されていることを確認
[ ] 1.9 Docker ファイルとディレクトリ - docker.socket に対して監査が設定されていることを確認
[ ] 1.10 Docker ファイルとディレクトリ - /etc/default/docker に対して監査が設定されていることを確認
[ ] 1.11 Docker ファイルとディレクトリ - /etc/docker/daemon.json に対して監査が設定されていることを確認
[ ] 1.12 Docker ファイルとディレクトリ - /usr/bin/docker-containerd に対して監査が設定されていることを確認
[ ] 1.13 Docker ファイルとディレクトリ - /usr/bin/docker-runc に対して監査が設定されていることを確認
[ ] 2.1 デフォルトブリッジ上のコンテナ間のネットワークトラフィックが制限されていることを確認
[ ] 2.2 ログレベルが 'info' に設定されていることを確認
[ ] 2.3 Docker が iptables に変更を加えることができることを確認
[ ] 2.4 安全でないレジストリが使用されていないことを確認
[ ] 2.5 aufs ストレージドライバが使用されていないことを確認
[ ] 2.6 Docker デーモンに対して TLS 認証が設定されていることを確認
[ ] 2.7 デフォルトの ulimit が適切に設定されていることを確認
[ ] 2.8 ユーザー名前空間のサポートを有効にする
[ ] 2.9 デフォルトの cgroup の使用が確認されていることを確認
[ ] 2.10 ベースデバイスサイズが必要になるまで変更されないことを確認
[ ] 2.11 Docker クライアントコマンドに対する認証が有効になっていることを確認
[ ] 2.12 集中管理およびリモートログが設定されていることを確認
[ ] 2.13 従来のレジストリ (v1) での操作が無効になっていることを確認
[ ] 2.14 ライブリストアが有効になっていることを確認
[ ] 2.15 ユーザーランドプロキシが無効になっていることを確認
[ ] 2.16 必要に応じてデーモン全体のカスタム seccomp プロファイルが適用されていることを確認
[ ] 2.17 本番環境で実験的な機能が回避されていることを確認
[ ] 2.18 コンテナが新しい権限を取得できないように制限されていることを確認
[ ] 3.x ...
[x] 4.1 コンテナ用のユーザーが作成されていることを確認
[ ] 4.2 コンテナが信頼できるベースイメージを使用していることを確認
[ ] 4.3 コンテナに不要なパッケージがインストールされていないことを確認
[ ] 4.4 イメージがスキャンされ、セキュリティパッチを含むように再構築されていることを確認
[ ] 4.5 Docker のコンテンツトラストが有効になっていることを確認
[ ] 4.6 コンテナイメージに HEALTHCHECK 命令が追加されていることを確認
[ ] 4.7 Dockerfile で update 命令が単独で使用されていないことを確認
[ ] 4.8 イメージ内の setuid および setgid 権限が削除されていることを確認
[ ] 4.9 Dockerfile で ADD の代わりに COPY が使用されていることを確認
[ ] 4.10 Dockerfile にシークレットが保存されていないことを確認
[ ] 4.11 検証済みのパッケージのみがインストールされていることを確認
[ ] 5.x ...
[ ] 6.x ...
[ ] 7.x ...