説明
Docker デーモンソケットをコンテナーにマウントし、プロセスから通信できるようにすると、ホストのコンテナー管理機能へアクセスできます。デーモンの権限によってはホストファイルへのアクセスや特権コンテナーの作成につながるため、通常のアプリケーションには提供しない方が安全です。
実際の影響はソケットの有無、プロセスのアクセス権限、デーモンの構成に左右されます。Kubernetes のすべてのコンテナーランタイムが Docker ソケットを使うわけではありません。
想定される影響
- 侵害されたアプリケーションが、Docker API を通じて他のコンテナーやホストのリソースへアクセスする場合があります。
- 強いデーモン権限がコンテナーの分離を弱め、ノードの侵害につながる場合があります。
対処方法
- 不要な Docker ソケットの host_path ボリュームと volume_mount を削除してください。読み取り専用マウントだけで、状態を変更する Docker API 操作を防げると考えないでください。
- ビルドや管理でデーモンへのアクセスが必要なら、通常のサービスから分離し、許可する操作と主体を限定してください。ホストマウントと特権実行もポリシーで制限してください。
例
変更前は実際に Docker ソケットがあるノードで、ボリュームとマウントを接続する例です。このイメージ自体にソケットへのアクセスが必要なわけではありません。実際のデプロイには保守されているイメージを使ってください。
変更前
hcl
resource "kubernetes_pod" "pod" {
metadata {
name = "terraform-example"
}
spec {
volume {
name = "docker-socket"
host_path {
path = "/var/run/docker.sock"
type = "Socket"
}
}
container {
image = "nginx:1.7.9"
name = "example"
volume_mount {
name = "docker-socket"
mount_path = "/var/run/docker.sock"
}
}
}
}
変更後
hcl
resource "kubernetes_pod" "pod" {
metadata {
name = "terraform-example"
}
spec {
container {
image = "nginx:1.7.9"
name = "example"
}
}
}
補足:
- 変更前: ホストの Docker ソケットをコンテナーにマウントします。プロセスの実際のアクセス権限も影響します。
- 変更後: 不要なソケットのボリュームとマウントを削除します。