問題の説明：
dockerを使用してnginxとhaproxy（および他のコンテナ）を実行するWebサービスがあります。個人用Dockerハブレジストリを介してこれらのDockerイメージを提供したいので、各顧客が自分の証明書をコンテナ（nginxとhaproxy）にマウントできるように、イメージにTLS証明書を構築したくありません。
haproxyコンテナを保護するためにroot権限なしで実行します（1000以上のポートはdocker-composeから1000未満のポートにマップされます）。 nginxコンテナは公式のnginxイメージに基づいているため、サービスの開始時にのみルートを使用し、その後nginxユーザーに変更されます。
コンテナをさらに保護するためにdocker-remappingを設定しました（デフォルト設定ではデフォルトのDockerremapユーザーを使用）。
質問：
TLS 証明書の公開鍵と秘密鍵はユーザー「nobody」としてコンテナにインストールされるため、haproxy コンテナと nginx コンテナは root 以外のユーザーを使用してファイルを読み取るため、これらのファイルを読み取ることはできません。
解決策（今まで）：
tlsファイルを読みやすいように作成できます（例：644）。それはうまくいくが恐ろしいほど安全ではないソリューションです。
haproxy イメージで行ったように、独自の nginx イメージを構築し、コンテナー ユーザーをなしグループに追加することで、証明書権限を 640 に変更できます。これは醜いハッキングです。
nginxコンテナとhaproxyコンテナのユーザーと同じuidを使用して証明書ファイルをマウントできるように、Dockerの再マッピングを削除しました。これは、docker-remappingのセキュリティが失われ、証明書ファイルにhaproxyコンテナとnginxコンテナのユーザーと同じuidが必要であることを意味します。
インストールプロセス中（およびプライマリイメージまたは証明書ファイルを更新するとき）、カスタマーサーバーに新しいイメージをビルドし、プライベートDockerリポジトリの既存のイメージをプライマリイメージとして使用します。私のクライアントサーバーのdockerビルドファイルは非常にシンプルで、正しい権限を使用してSSL証明書ファイルをcontsinersにコピーします。
質問：
マウントされたファイルが正しいuidを持つように、ホストuidをコンテナ内のユーザーuidにマップする方法はありますか？