説明
1～1023 のポートは、従来システムサービスで使われてきました。ホストで公開するポートとコンテナー内の待ち受けポートは区別が必要です。低い番号のポートを公開するだけで、コンテナーに root 権限が付与されるわけではありません。
低い番号のポートで待ち受けるための権限は、ネットワーク名前空間の ip_unprivileged_port_start 設定にも左右されます。一般的なアプリケーションでは、可能なら高い番号のポートを使い、不要な NET_BIND_SERVICE を削除してください。
想定される影響
- 不要なネットワーク capability は、サービス侵害後に使える権限を増やします。
- 必要以上に公開したサービスには、外部からアクセスが試みられる場合があります。
- プロトコルの要件を確認せずにポートを変更すると、サービスが停止するおそれがあります。
対処方法
- ホストの公開ポートとコンテナーの待ち受けポートが必要な理由をそれぞれ確認してください。変更可能なアプリケーションでは 1024 以上のポートを検討してください。
- 不要な
NET_BIND_SERVICEを削除し、実際のユーザーと名前空間の設定で正常動作をテストしてください。 - DHCP などで必要なプロトコルのポートは維持し、ネットワークアクセスを制限してください。高い番号のポートも認証やファイアウォールの代わりにはなりません。
例
DHCP クライアントはサーバーの UDP ポート 67 に要求を送ります。二つ目は 6700/udp で待ち受ける別のアプリケーション用の例で、DHCP サーバーの代替設定ではありません。APP_IMAGE にそのイメージを指定してください。
変更前
yaml
services:
dhcpd:
image: networkboot/dhcpd:latest
ports:
- "67:67/udp"
変更後
yaml
services:
app:
image: ${APP_IMAGE:?set APP_IMAGE}
ports:
- "6700:6700/udp"
cap_drop:
- NET_BIND_SERVICE
補足:
- 変更前: DHCP サーバーの UDP ポート 67 を公開します。プロトコルで必要なポートであることを踏まえ、アクセス範囲と実際の権限を確認してください。
- 変更後: ポートを変更できるアプリケーションで高い番号のポートを使い、不要な capability を削除する例です。ネットワーク公開範囲は別途制限してください。