問題の説明:
私は、docker を使用して nginx と haproxy (その他のコンテナー) を実行する Web サービスを持っています。これらの docker イメージをプライベート docker hub レジストリ経由で提供したいので、各顧客がコンテナー (nginx と haproxy) に独自の証明書をマウントできるように、イメージに tls 証明書を組み込みたくありません。
haproxy コンテナを保護するために、ルート権限なしで実行します (docker-compose で 1000 を超えるポートが 1000 未満のポートにマッピングされます)。nginx コンテナは公式の nginx イメージに基づいているため、サービスが開始するときにのみルートを使用し、その後 nginx ユーザーに変更します。
コンテナをさらに安全にするために、docker-remapping (デフォルトの dockremap ユーザーによるデフォルト設定) を設定しました。
問題：
TLS 証明書の公開キーと秘密キーは、ユーザー「nobody」としてコンテナーにマウントされているため、haproxy コンテナーと nginx コンテナーは、ファイルの読み取りに異なる (非ルート) ユーザーを使用するため、これらのファイルを読み取ることができません。
解決策(これまでのところ):
tls ファイルを誰でも読み取り可能にすることができます (例: 644)。これは機能しますが、非常に安全でない解決策です。
haproxy イメージの場合と同じように独自の nginx イメージを構築し、コンテナ ユーザーを nobody グループに追加して、証明書のアクセス許可を 640 に変更することができます。これは醜いハックです。
docker の再マッピングを削除して、nginx および haproxy コンテナー内のユーザーと同じ uid で証明書ファイルをマウントできるようにします。これにより、docker の再マッピングのセキュリティが失われ、証明書ファイルは haproxy および nginx コンテナー内のユーザーと同じ uid を必要とすることになります。
プライベート Docker リポジトリの既存のイメージをベース イメージとして使用し、インストール中 (およびベース イメージまたは証明書ファイルの更新時) に顧客のサーバー上で新しいイメージを構築します。顧客のサーバー上の Docker ビルド ファイルは非常にシンプルで、適切な権限で SSL 証明書ファイルをコンテナーにコピーすることのみを目的としています。
質問：
マウントされたファイルに正しい uid が設定されるように、ホストの uid をコンテナ内のユーザーの uid にマップする方法はありますか?