＃6075があなたに必要なものを与えるのだろうか

秘密のコンテナはそれを少し安全にするかもしれませんが、言及されたすべてのポイントはまだ立っています。

+1この機能も便利だと思います。 特に、たとえばプライベートgitリポジトリからのソフトウェアを必要とするコンテナを構築する場合。 コンテナでリポジトリキーを共有する必要はなく、代わりに「docker build ...」で、おそらく実行中のsshを介して、ロック解除されたSSHキーにアクセスするための他の方法を使用できるようにしたいと思います。 -エージェント。

+1。 Dockerで足を濡らし始めたばかりで、これが最初に直面した障壁でした。 Dockerがビルド中にホストボリュームをマウントできない/マウントできないことに気付く前に、VOLUMEを使用して認証ソックスをマウントしようとしばらく時間を費やしました。

パスワードなしのSSHキーのコピーが横になっていて、それをコンテナーにコピーしてからビルド中に削除するという仕組みが間違っていると感じたくありません。 私はEC2内で作業を行っていますが、秘密鍵をそこにコピーすることについても気分がよくありません（パスワードなしかどうかは関係ありません）。

私のユースケースは、鉄筋を使用してerlangプロジェクトを構築することです。 案の定、最初のリポジトリのクローンを作成し、Dockerfileを使用してイメージに追加できますが、プロジェクトにあるプライベートな依存関係では機能しません。 ホストマシンでプロジェクトをビルドし、その結果を新しいDockerイメージに追加することもできると思いますが、Dockerであるサンドボックスでビルドしたいと思います。

同じユースケースを持つ他の人々は次のとおりです： https ：

SSH_AUTH_SOCKを採用してください。非常に便利です。

ありがとう

編集：Dockerがどのように機能するか（FSレイヤー）について詳しく知ったので、ビルド中にSSHキーを追加し、後で削除することに関して説明したことを行うことは不可能です。 キーは、一部のFSレイヤーに引き続き存在します。

+ 1、SSH_AUTH_SOCKを使用できることは非常に便利です！

プライベートリポジトリかパブリックリポジトリかに関係なく、SSHキーを使用してGithubで認証します。

これは、私のgit cloneコマンドがgit clone [email protected]:razic/my-repo.gitようになっていることを意味します。

docker run間に、ホストの~/.sshディレクトリをコンテナにボリュームマウントできます。 sshはすべて問題ありません。 しかし私は、マウントすることはできません私の~/.sshの間にdocker build 。

：+1：ビルド中のssh転送用。

私が理解しているように、これは間違った方法です。 正しい方法は、開発マシンでDockerイメージを作成し、それをDockerサーバーにコピーすることです。

@ SevaUA-いいえ、それは正しくありません。 このリクエストは、 docker build...実行する際の制限によるものです。 docker run ...実行する場合のように、変数をこのステージにエクスポートすることはできません。 runコマンドを使用すると、実行中に変数をDockerコンテナーにエクスポートできますが、ビルドではこれを許可しません。 この制限は、コンテナを構築するときにdockerdがどのように機能するかに基づいて部分的に意図されています。 しかし、これを回避する方法はいくつかあり、説明されているユースケースは有効なものです。 したがって、このリクエストは、何らかの方法でこの機能をビルドに実装しようとしています。

私は＃6697（シークレットストア/ボールト）のアイデアが好きで、マージするとこれでうまくいくかもしれません。しかし、それがうまくいかない場合は、man-in-the-middle透過プロキシsshを実行することもできます。 Dockerデーモンの外部で、Dockerデーモントラフィックをインターセプトします（内部ではありません）。 または、すべてのgit + sshリクエストは、githubまたは最終的に最終的に必要なものに透過的にプロキシするローカル定義のホストに対するものである可能性があります。

その考えはすでに提起されています（コメント2を参照）。 それは問題を解決しません。

ビルド中のssh転送の+1。

docker buildでのSSHエージェント転送の+1

npminstallなどのビルド中のssh転送の+1。

OSXでの実行中にssh転送が機能するようになった人はいますか？ ここに質問をしました： http ：

+1 =（

この障害にもぶつかるだけです。 npm installを実行しようとすると、プライベートリポジトリがポイントされます。 セットアップは次のようになります。
host -> vagrant -> dockerはssh-agentでhost -> vagrant -! docker転送できます

+1
「dockerbuild」中にsshエージェントを機能させる方法を見つけようとしているときにこれを押してください。

前の人と同じ+1。 Dockerイメージを構築するときに1つ以上のプライベートgitリポジトリ（たとえば、 bundle installとnpm installを考えてください）にアクセスする必要がある場合、この問題に対する最善の解決策のようです。

Dockerの実行中にホスト〜/ .sshディレクトリをコンテナにボリュームマウントできますが、sshはすべて問題ありません。

@razicそれをどのように

すべてのコンテナが特定のユーザーまたは権限で実行されていることを確認しない限り、それを実行できますか？

SSH_AUTH_SOCKへの+1

@tonivdvは、この問題に関する最初のコメントのdocker runコマンドを確認しています。 SSH_AUTH_SOCKによって参照されるパスをコンテナ内の/tmp/ssh_auth_sockにバインドマウントし、コンテナ内のSSH_AUTH_SOCKをそのパスに設定します。

@ md5 @razicと@tonivdvが次のようにマウントについて話していると思います： -v ~/.ssh:/root/.ssh:roですが、これを行うと、.sshファイルはrootによって所有されないため、セキュリティチェックに失敗します。

@KyleJamesWalkerうん、それは私がことであり、それはしばらく前の私の試みの1つだったので、 @ razicを読んだとき、それを機能させることができたのですが、どうしたらいいのだろうと思っていました:)

@tonivdv可能かどうかも知りたいのですが、最後に試したときは何も見つかりませんでした。

+1 Dockerを使用して使い捨ての開発環境を構築することに興味がありますが、完全に機能させることはできません。 これはその点で大いに役立ちます。

一時的な解決策を探している人には、ブルートフォース攻撃を使用する修正があります。

https://github.com/atrauzzi/docker-laravel/blob/master/images/php-cli/entrypoint.sh

エントリポイントスクリプト全体が必要なため、決して望ましいソリューションではありませんが、機能します。

@atrauzzi興味深いアプローチ。 開発環境では、ベースイメージを作成し、その中にsshキーを直接コピーします。 実行ごとに提供する必要がないという利点があります。 そして、そのメイジから継承するすべての画像には、デフォルトでキーも含まれています。 しかし、私たちの方法では、明らかにそれを公に共有することはできません; p

+1これは素晴らしいでしょう

@tonivdvスクリプトの対象となるコンテナは、CLIツールの単なるホストであるため、頻繁に作成および破棄されます。 もちろん、操作は1回だけ自由に行えます。 ただし、誰かが設定を変更してコンテナを介してコマンドを再実行した場合は、毎回新しいコピーである必要があります。

@atrauzziわかりました。 あなたのアプローチは、プライベートsshキーを必要とする可能性のあるDockerイメージで採用する必要があります。 たとえば、プライベートリポジトリの場合、コンポーザーイメージにはエントリポイントスクリプトを含める必要があります。 少なくともdockerにネイティブソリューションが付属するまでは。

：+1：ビルドによるssh転送用

ここにも必需品！

@atrauzzi現在、私が本当に気に入っている別のアプローチを使用しています。 sshを含むデータボリュームコンテナを作成しています。 別のコンテナにsshキーを使用したい場合は、次のコマンドで簡単に使用できます。

docker run -ti --volumes-from ssh-data ...

このように、各画像にエントリポイントを配置する必要がなく、すべての画像で機能します。

そのコンテナを作成するには、次のようにします

docker run \
  --name ssh-data \
  -v /root/.ssh \
  -v ${USER_PRIVATE_KEY}:/root/.ssh/id_rsa \
  busybox \
  sh -c 'chown -R root:root ~/.ssh && chmod -R 400 ~/.ssh'

これが他の人を助けることができることを願っています:)

乾杯

@ tonivdv-誰かがSSH設定を追加または更新する必要がある場合、それらを再インポートする必要があるため、私は私のアプローチを採用しました。 私が使用している特定のコンテナーは、単一のコマンドを実行するように構築されたコンテナーであるため、実行するたびに、コピーを取得して最新であることを確認します。

@atrauzziうん、わかりました。 そうは言っても、sshボリュームコンテナを正しく維持するかどうかはユーザー次第です。 彼は必要に応じて別のものを使用することもできます。 また、オプションで、スクリプトを使用してオンザフライで生成できます。 しかし、私は唯一の良い解決策があるとは思いません。 それはすべてニーズに依存します。 他の人が自分のニーズに基づいてどのソリューションを選択できるように、共有したかっただけです。 これについてすぐにブログを書きたいと思っています。私もあなたの解決策を転送します！ 乾杯

私はあなたのコンテナを実行している人々がsshキーでいっぱいのデータ専用コンテナを維持することを要求しません。 関係しているようです。

@atrauzziボリュームコンテナが存在する必要があるのは事実ですが、ユーザーが正しく実行しすぎると、そのsshキーを共有する必要がありますか？ したがって、sshボリュームコンテナが必要であることに加えて、実行の観点から見た両方のソリューションの唯一の違いは次のとおりです。

docker run ... --volumes-from ssh-data ... php-cli ...

と

docker run ... -v ~/.ssh:/path/.host-ssh ... php-cli ..

正しい？ または私は何か他のものが欠けていますか:)

しかし、私はあなたがそれをあなたのやり方でやっている理由を完全に理解しています。 ただし、たとえば他の人の作曲家の画像を使用したい場合は、ボリュームからの方法ですぐに使用できます。 少なくとも、「エントリポイントハック」を使用して独自のイメージを作成することは避けられます。

私が言ったように、両方とも回避策であり、両方とも長所と短所があります。

乾杯

この機能のステータスについてDockerチームから最新情報を入手できれば本当に素晴らしいと思います。 具体的には、 docker buildからのSSH認証。

もう1年になります。 このための実際のユースケースの実用性を考えると、ちょっと驚くべきことです。 現在、実行中のコンテナをコミットすることで動的にイメージを生成しています。 アプリケーションのリポジトリにDockerfileを含めることはできません。 これは事実上すべての流れを壊します。 これが解決されるまで、ComposeやSwarmなどのDockerサービスでアプリケーションを実際に使用することはできません。

アップデートをいただければ幸いです。 どうぞよろしくお願いします。

/ cc @phemmer

この機能などが必要ないわけではありません。このようなものやビルドの秘密のユースケースは、実装を希望する人からの提案が必要であり、承認された場合は提案の実装が必要になると思います。
また、私はすべてのメンテナーではなく、私自身を代表して話します。

@jfrazelle

私はあなたたちが私たちを無視していないことを知っています:)

したがって、ステータスは次のとおりです。

受け入れられた提案があれば、それを実装することを検討します
およびエンジニアリング帯域幅。

これはあなたにとって正確に聞こえますか？

また、現在、この問題に対処する未解決の提案はありますか？

2015年4月7日（火曜日）に、ジェシーFrazelleの[email protected]は書きました：

この機能などが必要ないというわけではありません。
このようなものやビルドの秘密の場合は、
実装する意思のある人からの提案、そして承認された場合は
提案の実施。
また、私はすべてのメンテナーではなく、私自身を代表して話します。

—
このメールに直接返信するか、GitHubで表示してください
https://github.com/docker/docker/issues/6396#issuecomment-90737847 。

受け入れられた提案があれば、それを実装することを検討します
およびエンジニアリング帯域幅。

はい

そして、私はこれについてのオープンな提案はないと思います。

2015年4月7日火曜日午後2時36分、ザカリーアダムカプラン<
[email protected]>は次のように書いています：

@jfrazelle

私はあなたたちが私たちを無視していないことを知っています:)

したがって、ステータスは次のとおりです。

受け入れられた提案があれば、それを実装することを検討します
およびエンジニアリング帯域幅。

これはあなたにとって正確に聞こえますか？

また、現在、この問題に対処する未解決の提案はありますか？

2015年4月7日（火曜日）には、ジェシーFrazelle [email protected]
書きました：

この機能などが必要ないというわけではありません。
このようなものやビルドの秘密の場合は、
実装する意思のある人からの提案、そして承認された場合は
提案の実施。
また、私はすべてのメンテナーではなく、私自身を代表して話します。

—
このメールに直接返信するか、GitHubで表示してください
https://github.com/docker/docker/issues/6396#issuecomment-90737847 。

—
このメールに直接返信するか、GitHubで表示してください
https://github.com/docker/docker/issues/6396#issuecomment-90738913 。

私が物事を単純化しすぎているかどうかはわかりませんが、ここに私の提案があります：

SSHAGENT：転送＃デフォルトで無視する

設定されている場合、ビルド中に、ソケットと関連する環境変数がコンテナに接続され、そこで使用できます。 これの機械的な部分はすでに存在し、機能しています。 docker buildそれらを接続するだけです。

Dockerコードベース内での作業経験はありませんが、これは私にとって十分に重要であり、それを採用することを検討します。

すごい。 提案書の提出方法はどこで確認できますか？ ありますか
特定のガイドラインまたは問題を開く必要がありますか？

2015年4月7日（火曜日）に、ジェシーFrazelleの[email protected]は書きました：

受け入れられたものがあれば、それを実装することを検討します
提案
およびエンジニアリング帯域幅。

はい

そして、私はこれについてのオープンな提案はないと思います。

2015年4月7日火曜日午後2時36分、ザカリーアダムカプラン<
[email protected]
<_e i = "18">

@jfrazelle

私はあなたたちが私たちを無視していないことを知っています:)

したがって、ステータスは次のとおりです。

受け入れられたものがあれば、それを実装することを検討します
提案
およびエンジニアリング帯域幅。

これはあなたにとって正確に聞こえますか？

また、現在、この問題に対処する未解決の提案はありますか？

2015年4月7日火曜日、Jessie Frazelle < [email protected]
<_e i = "31" />の書き込み：

この機能などが必要ないというわけではありません。
使用する
このようなものやビルドの秘密の場合は、
実装する意思のある人からの提案、そして承認された場合は
提案の実施。
また、私はすべてのメンテナーではなく、私自身を代表して話します。

—
このメールに直接返信するか、GitHubで表示してください
https://github.com/docker/docker/issues/6396#issuecomment-90737847 。

—
このメールに直接返信するか、GitHubで表示してください
https://github.com/docker/docker/issues/6396#issuecomment-90738913 。

—
このメールに直接返信するか、GitHubで表示してください
https://github.com/docker/docker/issues/6396#issuecomment-90739596 。

私はデザイン提案のような意味です
https://docs.docker.com/project/advanced-contributing/#design -proposal

14:39で火、2015年4月7日には、ダニエル・Staudigel [email protected]
書きました：

私が物事を単純化しすぎているかどうかはわかりませんが、ここに私の提案があります：

SSHAGENT：転送＃デフォルトで無視する

設定されている場合、ビルド中に、ソケットと関連する環境変数は次のようになります。
それらが使用できるコンテナに接続されています。 機械部品
これはすでに存在し、機能しています。接続するだけです。
Dockerビルドでそれらを。

Dockerコードベース内での作業経験はありませんが、これは
私にとってそれを引き受けることを検討するのに十分重要です。

—
このメールに直接返信するか、GitHubで表示してください
https://github.com/docker/docker/issues/6396#issuecomment-90739803 。

これは非常に高レベルのアイデアですが、dockerリモートAPIを介して接続する代わりに、dockerがコンテナー内でバンドルされたsshデーモンを使用してinitデーモンを実行した場合はどうなりますか？

これは、多くの問題を解決するために使用できます。

• このデーモンはPID1になり、メインコンテナプロセスはPID 2になります。これにより、シグナルを無視してコンテナが適切にシャットダウンしないというPID1のすべての問題が解決されます。 （＃3793）
• これにより、SSHキーエージェントをクリーンに転送できます。 （＃6396）
• このデーモンは名前空間を開いたままにすることができます（＃12035）
• TTYはデーモンによって作成されます（＃11462）
• ...そしておそらく私が忘れている他の多くの問題。

あなたはhttps://github.com/docker/docker/issues/11529について見たいかもしれません
最初の箇条書き

14:46で火、2015年4月7日には、パトリック・ヘメル[email protected]
書きました：

これは本当にハイレベルなアイデアですが、
docker remote api、dockerはバンドルされたsshを使用してinitデーモンを実行しました
デーモン、コンテナ内？

これは、多くの問題を解決するために使用できます。

• このデーモンはPID1になり、メインコンテナプロセスは次のようになります。
  PID2。これにより、信号を無視するPID1のすべての問題が解決されます。
  コンテナが適切にシャットダウンしていません。 （＃3793
  https://github.com/docker/docker/issues/3793）
• これにより、SSHキーエージェントをクリーンに転送できます。 （＃6396
  https://github.com/docker/docker/issues/6396）
• このデーモンは名前空間を開いたままにすることができます（＃12035
  https://github.com/docker/docker/issues/12035）
• TTYはデーモンによって作成されます（＃11462
  https://github.com/docker/docker/issues/11462）
• ...そしておそらく私が忘れている他の多くの問題。

—
このメールに直接返信するか、GitHubで表示してください
https://github.com/docker/docker/issues/6396#issuecomment-90741192 。

11529は、PID1の問題とはまったく関係ありません。

effingコピーペーストを撃ちます、今私はもう一方をもう一度見つけなければなりません

いいえ、それはそれです、それはあなたが言及していると私が思ったものであるPID 1ゾンビのものを修正します、しかし私がちょうど投稿していたにもかかわらず、その腸はすべてです

@phemmer実装のためのインテリジェントな提案を行うために、私たちを導く専門知識があるようです。

@dtsのようにも見えますが、私はこれに時間を費やすことをいとわないです。

@phemmerと@dtsは、コミュニケーションを容易にするために、このディスカッションをもう少しリアルタイムのチャットクライアントに取り込む方法はありますか？ 私はSlack、Google Chat / Hangout、IRCからアクセスでき、必要に応じて他のものをダウンロードします。

@phemmer実装のためのインテリジェントな提案を行う際に私たちを導く専門知識があるようです

残念ながら実際にはそうではありません:-)
デザインのアイデアを捨てることはできますが、Dockerコードベースのごく一部しか知りません。 この種の変更は大規模になる可能性があります。

ここにはすでにいくつかの提案があります：

@phemmerが提案しました

dockerリモートAPIを介して接続する代わりに、dockerがコンテナー内でバンドルされたsshデーモンを使用してinitデーモンを実行した場合はどうなりますか？

@dtsが提案

SSHAGENT：転送＃デフォルトで無視する
設定されている場合、ビルド中に、ソケットと関連する環境変数がコンテナに接続され、そこで使用できます。 これの機械的な部分はすでに存在し、機能しています。Dockerビルドでそれらを接続するだけです。

@razic提案

docker buildボリュームバインディングを有効にします。

この時点で本当に必要なのは、そのうちの1つを受け入れて、作業を開始できるようにすることです。

@jfrazelle次のステップに進む方法について

私はslack / irc / Gchat / etcの会議に参加できます。これにより、少なくとも要件を収集して合理的な行動方針を決定するために、物事が少し簡単になると思います。

@dtsが提案

SSHAGENT：転送＃デフォルトで無視する

これは、実装ではなく、どのように消費されるかについての単なるアイデアです。 「init / sshデーモン」は、それがどのように実装されるかというアイデアです。 2つは両方とも存在する可能性があります。

@razic提案

Docker実行のボリュームバインディングを有効にします。

残念ながら、これは機能しません。 これがdocker build意味し、すでにボリュームマウントをサポートしているdocker runではないと仮定すると、クライアントはリモートになります（boot2dockerが1つの顕著な例です）。 ボリュームバインドは、クライアントがDockerデーモンと同じホスト上にある場合にのみ機能します。

@razicデザイン提案については、このリンクを参照してください...これらは提案ではありませんhttps://docs.docker.com/project/advanced-contributing/#design -proposal

@phemmer

なぜこれがうまくいかないのか正確に理解できていません。 docker-composeは、 swarmクラスターに対するボリュームマウントで機能します。 ファイル/フォルダがホストシステム上にない場合、存在しないパスで-vを実行した場合と同じ動作をします。

@jfrazelle了解しました。

ファイル/フォルダーがホストシステム上にない場合、ローカルDockerに存在しないパスで-vを実行した場合と同じ動作を実行します。

私はあなたの主張に従うかどうかわかりません。 その動作はこの問題にどのように役立ちますか？
ローカルマシンで/tmp/ssh-UPg6h0をリッスンしているsshキーエージェントがあり、リモートマシンでdockerを実行していて、 docker buildを呼び出すと、そのローカルsshキーエージェントにアクセスできなくなります。 dockerデーモン。 ボリュームマウントはそれを取得せず、 docker buildコンテナはsshキーにアクセスできません。

大まかに言えば、これを解決する方法は2つしかありません。

1.sshキーエージェントソケットをプロキシします。

dockerデーモンはコンテナ内にunixドメインソケットを作成し、何かがそれに接続するたびに、実際にdocker buildコマンドを実行しているクライアントにその接続をプロキシします。

コンテナ内のUNIXドメインソケットへの接続は任意の数になる可能性があるため、これを実装するのは難しい場合があります。 これは、Dockerデーモンとクライアントが任意の数の接続をプロキシする必要があること、またはデーモンがsshエージェントプロトコルを話し、要求を多重化できる必要があることを意味します。

ただし、docker remote APIがWebSocketをサポートするようになったため（この問題が作成された時点ではサポートされていませんでした）、これはそれほど難しいことではないかもしれません。

2.実際のSSHデーモンを起動します

sshエージェントをハッキングする代わりに、クライアントからコンテナへの実際のssh接続を使用します。 dockerクライアントにはsshクライアントがバンドルされているか、リモートコンテナにsshを呼び出します。
これは、コンテナへの接続の実装方法に取って代わるため、はるかに大規模な変更になります。 ただし、Dockerがそれを処理する必要がなくなり、標準プロトコルに移行することもできます。
これは、他の問題を解決する可能性もあります（ここで説明したよう

したがって、最終的にははるかに大規模な変更が行われますが、より適切な解決策になる可能性があります。
現実的には、規模の関係で、これが起こるとは思えません。

@phemmer

私はあなたの主張に従うかどうかわかりません。 その動作はこの問題にどのように役立ちますか？

これの最も一般的な使用例は、SSH認証を必要とするプライベートリポジトリでホストされている依存関係を持つイメージを構築する人々であるためです。

SSHキーを持つマシンでイメージをビルドします。 とても簡単です。

ローカルマシンで/ tmp / ssh-UPg6h0をリッスンしているsshキーエージェントがあり、リモートマシンでdockerを実行していて、docker buildを呼び出すと、そのローカルsshキーエージェントにdockerデーモンにアクセスできません。

知っている。 誰も気にしない？ 認証ソケットにアクセスできるマシンでdocker buildを実行します。

私が言おうとしているのは.... docker-compose使用すると、ファイルが実際にホスト上にあるかどうかにswarmクラスターに対してボリュームコマンドを使用できます。 。

Dockerビルドのボリュームマウントについても同じことを行う必要があります。

| ファイルはシステム上にあります| アクション|
| ：-| ：-|
| はい| マウント|
| いいえ| なし（実際にはマウントを試みますが、ファイル/フォルダーが存在しない場合は空のフォルダーを作成します。 docker run -v /DOES_NOT_EXIST:/DOES_NOT_EXIST ubuntu ls -la /DOES_NOT_EXIST実行してこれを確認できます）|

swarm背後にある概念の1つは、マルチホストモデルを透過的にすることです。

リモートDockerについて考えているのは良いことですが、それほど重要ではありません。

docker runとまったく同じ方法で、 docker buildボリュームマウントの動作をコピーする必要があります。

https://github.com/docker/compose/blob/master/SWARM.mdから：

マルチコンテナアプリがSwarmでシームレスに動作するのを妨げる主な理由は、アプリが相互に通信できるようにすることです。異なるホスト上のコンテナ間のプライベート通信を有効にすることは、ハッキングされていない方法で解決されていません。

長期的には、ネットワークはマルチホストモデルによりよく適合するように見直されています。 今のところ、リンクされたコンテナは同じホストで自動的にスケジュールされます。

@phemmerおそらく、あなたが説明した問題の解決策について人々が考えていると思います。 あなたが説明している問題は、別のhttps://github.com/docker/docker/issues/7249のように聞こえ

私のアプローチを採用する場合： Dockerビルドでボリュームマウントを許可するだけです（マウントしようとしているファイルが実際にシステム上にあるかどうかに関係なく、この問題を閉じて、 https：//github.com/で作業を開始でき

@ cpuguy83プロポーザルを作成する前に、＃7133を見ていて、直接関連しているように見えることに気づきました。

ここにいくつか単語を追加していただけますか？ ＃7133は、この問題を修正するという私の提案に実際に関連しています。これは、 docker buildがボリュームをサポートできるようにすることです。

@razicこれは、 VOLUME /foo実際にボリュームを作成し、ビルド中にそれをコンテナーにマウントするという事実に関連しています。これは一般的に望ましくあり

また、bind-mountsを使用してファイルをビルドコンテナーに取り込むことに基づく提案は、おそらくうまくいかないでしょう。
＃6697を参照

docker buildで-vを実行すると、コード実行パスが異なる可能性があります。
ボリュームを作成してビルド中にマウントする代わりに、
dockerfilesのボリュームが参照されない現在の動作。 と
代わりに、CLIへの引数を使用して実行する場合にのみ-vに作用します。

2015年4月8日（水曜日）には、ブライアン・ゴフの[email protected]は書きました：

@razichttps ：//github.com/razicそれはVOLUMEという事実に関連しています
/ fooは実際にボリュームを作成し、その間にコンテナにマウントします
ビルド。これは一般的に望ましくありません。

また、bind-mountsを使用してファイルを取得することに基づく提案も言います
ビルドコンテナはおそらく飛ぶことはありません。
＃6697を参照https://github.com/docker/docker/pull/6697

—
このメールに直接返信するか、GitHubで表示してください
https://github.com/docker/docker/issues/6396#issuecomment-90905722 。

@ cpuguy83説明してくれてありがとう。

6697また、すでに閉鎖されており、＃10310は実質的に＃6697の複製であるため、飛行しません。

+1、私は今日、Bowerを使用してクライアント側の依存関係をインストールするRailsアプリのイメージを構築しようとしているときにこれをヒットしました。 依存関係の1つが[email protected]:angular/bower-angular-i18n.gitを指している場合、そこでgitが失敗するため、bowerが失敗し、イメージの構築も失敗します。

私はvagrantが何をするのか本当に好きです。 Vagrantfileに単一のforward_agent構成がある場合、これはvagrantゲストに対して解決されます。 Dockerはこのようなものを実装できますか？

また、補足として、これはイメージの構築中に発生しています。 誰かが既存の回避策を知っていますか？

私の回避策は、新しいRSAキーペアを生成し、githubで公開キーをセットアップし（フィンガープリントを追加）、Dockerイメージに秘密キーを追加することでした。

ADD keys/docker_rsa /srv/.ssh/id_rsa

これは避けたいのですが、今のところ許容できると思います。 他の提案はありがたいです！

誰がもっと子犬を殺したのかわかりません。 それを行ってくれたあなた、または今のところより良い方法を提供していないDocker。

いずれにせよ、私はおそらく今週末に提案を提出するつもりです。 @ cpuguy83は、人々が少なくともこれについて考え、考えられる解決策について話し合っているというのは正しいことです。 したがって、この時点では、私たちが何かに同意し、誰かにそれに取り組んでもらうだけの問題です。 これは、現在Dockerに対する私の最大の不満のひとつであるため、私は完全にそれに取り組むことにしました。

@razicこれはかなり一般的なユースケースなので、これも調べてくれてありがとう。 回避策としては、動作します。 おそらく、キーは使用後にイメージから削除される可能性があります。結局のところ、キーはgithubからアプリケーションのコードを取得するためにのみ使用されます。

@fullofcaffeine Dockerが内部でどのように機能するかは100％

@razic良い点。

この制限を回避するために、（ローカルHTTPサーバーから）秘密鍵をダウンロードし、鍵を必要とするコマンドを実行し、後で鍵を削除するというアイデアを試してきました。

これらすべてを単一のRUNで実行するため、画像には何もキャッシュされません。 Dockerfileでの表示は次のとおりです。

RUN ONVAULT npm install --unsafe-perm

この概念に関する最初の実装は、 https：//github.com/dockito/vaultで入手できます

唯一の欠点は、HTTPサーバーを実行する必要があるため、Dockerハブがビルドされないことです。

どう考えているか教えてください ：）

+1
これが実装されるのを楽しみにしています。開発環境用のコンテナをセットアップするのに役立ちます

+ 1、boot2dockでssh-agentを転送する必要があります

この制限を回避するために、3つのステップのプロセスを実行することになりました。

1. SSHが必要な依存関係なしでDockerコンテナを構築し、最後のステップでソースを追加します
2. 共有ボリュームを介してソースをマウントし、さらに共有ボリュームを介してSSH_AUTH_SOCKを実行し、ビルドステップを実行して、sshを必要とする出力（たとえば、githubがホストするruby gem）を共有ボリュームに書き戻します
3. docker buildを再実行します。これにより、gemがソースディレクトリに配置されているため、ソースの追加が再トリガーされます。

その結果、SSHキーを含まないSSH-authを介して依存関係がプルされたDockerイメージが作成されます。

OSXのboot2docker環境でdocker run sshエージェント転送を最小限の手間で有効にするスクリプトを作成しました。 ビルドの問題が解決しないことはわかっていますが、一部のユーザーには役立つ可能性があります。

https://gist.github.com/rcoup/53e8dee9f5ea27a51855

Forward sshキーエージェントはAmazonEC 2 Containerサービスなどのサービスで機能しますか？ これには、コンテナのデプロイに使用しているすべてのプラットフォームまたはPaaSで利用できるとは限らない特定のソフトウェアが必要になるように思われます。

より一般的な、万能のソリューションが必要です。

現在、環境変数を使用しています。 bashスクリプトは、秘密鍵（および既知のホスト）変数を取得し、それをid_rsaファイルとknown_hostsファイルに出力します。 それは機能しますが、私はまだそのようなソリューションのセキュリティへの影響を評価していません。

FWIW、コンテナ化されたssh-agentとボリューム共有は、最小限のグーファリーでうまく機能することがわかりました。

https://github.com/whilp/ssh-agent

ただし、これに対する一流のサポートがあれば素晴らしいと思います。

_run_と_build_で機能するものを区別することが重要です。 @whilpのソリューションは_run_でうまく機能しますが、_build_中に他のDockerのボリュームにアクセスできないため、_build_では機能しません。 したがって、なぜこのチケットはまだ痛い、開いた痛みです。

@rvowlesうん、同意した。 一連のrun / commit呼び出しを介して（つまり、Dockerfileを使用せずに）コンテナーを生成するために何かをまとめました。 これは私の特定のユースケースでは理にかなっていますが、エージェント転送などの一般的なサポート（ビルド時間を含む）は非常に役立ちます。

ビルド中に/ etc / hostsにコンテナを実行するためのIPが含まれていますか？ その場合、1つの解決策は、キーを提供するコンテナーを開始し、ビルド中にそのコンテナーにカールすることです。

docker build間にSSHエージェントを使用する方法についてブログに書いたことを知っておくとよいでしょう-http ：//aidanhs.com/blog/post/2015-10-07-dockerfiles-reproducibility-トリック/＃_ streamlining_your_experience_using_an_ssh_agent

単一のコンテナを開始する必要があります。 開始すると、SSHエージェントアクセスはDockerfileに3行追加するだけで問題なく機能するはずです。これ以上、キーをコンテナーに公開する必要はありません。

いくつかの注意点：Docker> = 1.8が必要であり、Docker Hub自動ビルドでは機能しません（明らかに）。 セキュリティに関する注意事項もお読みください。 問題が発生した場合は、投稿でリンクしているsshagentgithubリポジトリで問題を提起してください。

また、 @ aidanhsと同様の方法でこの問題を解決しました。
https://github.com/mdsol/docker-ssh-exec

これを可能にするための進展はありましたか？ 権限と所有権が台無しになっているため、ホストの~/.sshディレクトリをバインドマウントできません。

これは、バインドマウントが特定のuid / gidとアクセス許可を強制できるようにすることで解決できるのではないでしょうか？

@ atrauzzibind -
これはFUSE（bindfsなど）を介して実行できますが、通常のバインドマウントだけでは実行できません。

@ cpuguy83それは、私が対処する必要のない道を本当に私を連れて行き始めます。 特に、Windowsベースのホストを使用している場合。

ここにユーザーフレンドリーなオプションはありませんか？ 延期されているだけの問題があるような気がします。

@atrauzzi確かに、短期的に解決するのは簡単な問題ではありません（とにかくシームレスではありません）。

+1これは、他の点では単純なNode.jsアプリDockerfileの大きなブロッカーです。 私は多くのノードアプリに取り組んできましたが、NPMの依存関係としてプライベートGithubリポジトリを持たないアプリはめったに見られません。

回避策として、 @ apeaceを、gitサブモジュールとしてgitリポジトリに追加してみてください。 そうすれば、それらはコンテキスト内にあり、ビルド中に追加することができます。本当にきれいにしたい場合は、それぞれの.gitファイルを削除または無視してください。 Dockerビルドでは、ローカルディレクトリを使用してインストールできます。 何らかの理由で本格的なgitリポジトリが必要な場合は、 .gitファイルがdockerビルドに存在しないことを確認し、 .git/modules/<repo>を<path>/<repo>/.gitとして追加します。 これにより、クローンが作成されたかのように、通常のリポジトリであることが確認されます。

その提案に感謝します@jakirkham 、しかし私たちは長い間NPM依存関係としてプライベートリポジトリを使用してきました、私は通常のnpm installワークフローを壊したくありません。

今のところ、機能するソリューションがありますが、それは厄介です。 我々は持っています：

• NPMの依存関係として使用するリポジトリへの読み取り専用アクセス権を持つGithubユーザーとチームを作成しました
• Dockerfileがあるリポジトリにそのユーザーの秘密鍵をコミットしました
• 代わりのDockerfileでは、 RUN npm install我々やるRUN GIT_SSH='/code/.docker/git_ssh.sh' npm install

git_ssh.shは、次のようなスクリプトです。

#!/bin/sh
ssh -o StrictHostKeyChecking=no -i /code/.docker/deploy_rsa "$@"

それは機能しますが、sshキーエージェントを転送する方がはるかに優れており、セットアップ作業が大幅に少なくなります。

：+1：
ビルド時にプライベートリポジトリからのアクセスを必要とする多くのユースケースがあるため、この機能リクエストがまだ実装されていないことを信じることができません。

プライベートリポジトリへのアクセスを必要とするさまざまな組み込みシステム開発環境用のコンテナを構築しようとしています。 ホストsshキーのサポートを追加することは素晴らしい機能です。 SOや他のページで飛行する最も一般的な方法は安全ではなく、この機能のサポートがない限り、秘密鍵を使用したレイヤーが広まります。

：+1：

：+1：これは永遠に必要です。

こんにちは@apeace 、あなたがそれを見たかどうかはわかりませんが、この問題の回避策について以前にコメントしました。

これは、スクリプトとWebサーバーの組み合わせです。 https://github.com/dockito/vaultをどう思い

@pirelenitoを使用すると、ビルドのレイヤー内でキーを引き続き使用できるようになりませんか？ その場合、ビルドプロセスにDockito Valutを追加することは、私たちにとって価値がありません。私にとっては、現在行っていることと同じように「ジェンキー」に思えます。 私は提案に感謝します！

@apeace ONVAULTスクリプトはキーをダウンロードし、コマンドを実行してすぐにキーを削除します。 これはすべて同じコマンドで行われるため、最終レイヤーにはキーが含まれません。

@apeace Medidataでは、 -ssh-execと呼ばれる作成した小さなツールを使用しています。 結果のビルドイメージにはdocker-ssh-execバイナリのみが残り、シークレットは残りません。 また、 Dockerfileへの1単語の変更のみが必要なため、非常に「フットプリントが少ない」のです。

ただし、Dockerネイティブのみのソリューションを_本当に_使用する必要がある場合は、会社のブログ投稿に記載されているように、これを行うための組み込みの方法があります。 Docker 1.9では、 --build-argパラメーターを使用して、一時的な値をビルドプロセスに渡すことができます。 プライベートSSHキーをARGとして渡し、ファイルシステムに書き込み、 git checkout実行してから、キーを_delete_することができます。これらはすべて1つのRUN範囲内です。 docker-ssh-execクライアントが行うことです）。 これは醜いDockerfileになりますが、外部ツールは必要ありません。

お役に立てれば。

@benton同様の解決策を考え出しました。 :)

@pirelenitoと@bentonに感謝し

編集：以下は実際には安全ではありません：

ちなみに、結果の画像にSSHキーを残さずに、Githubからプライベートリポジトリをチェックアウトする方法は次のとおりです。

まず、次のDockerfile user/repo-nameをプライベートリポジトリへのパスに置き換えます（チェックアウトにsshが使用されるように、 [email protected]プレフィックスを保持していることを確認してください）。

FROM ubuntu:latest

ARG SSH_KEY
ENV MY_REPO [email protected]:user/repo-name.git

RUN apt-get update && apt-get -y install openssh-client git-core &&\
    mkdir -p /root/.ssh && chmod 0700 /root/.ssh && \
    ssh-keyscan github.com >/root/.ssh/known_hosts

RUN echo "$SSH_KEY" >/root/.ssh/id_rsa &&\
    chmod 0600 /root/.ssh/id_rsa &&\
    git clone "${MY_REPO}" &&\
    rm -f /root/.ssh/id_rsa

次に、コマンドでビルドします

docker build --tag=sshtest --build-arg SSH_KEY="$(cat ~/.ssh/path-to-private.key)" .

正しいパスをSSH秘密鍵に渡します。

^ Docker1.9を使用

@benton docker inspect sshtestとdocker history sshtestの出力を詳しく調べたいと思うかもしれません。 コンテナコンテキスト自体の内部で利用できない場合でも、最終的な画像のメタデータには秘密があることがわかると思います...

@ljrittle良いスポッティング。 VARを使用する場合、キーは確かにそこにあります。 ここでも外部の回避策が必要だと思います。

おそらく、ネイティブソリューションがまだ開発されていない理由の1つは、いくつかの回避策が実施されているためです。 しかし、組み込みのソリューションがユーザーにより良いサービスを提供し、Dockerの「バッテリーを含む」哲学に適合するという点で他のほとんどの人に同意します。

ドキュメントから...

注：githubキー、ユーザー資格情報などのシークレットを渡すためにビルド時変数を使用することはお勧めしません。

（https://docs.docker.com/engine/reference/builder/#arg）

ファイルへのパスがこれに当てはまるとは思いません。メモは、コンソールログにわかりやすいパスワード/トークンを表示することについてです。

@jcrombezをフォローしていません。 この例では、sshキーを変数としてARG介して渡します。 したがって、それは適用されます。

セキュリティリスクの観点から、これは非常に異なります。

docker build --tag=sshtest --build-arg SSH_KEY="$(cat ~/.ssh/path-to-private.key)" .

これより ：

docker build --tag=sshtest --build-arg SSH_KEY="mykeyisthis" .

誰かがあなたのターミナルログを見つけた場合、結果は同じではありません。
しかし、私はセキュリティの専門家ではありません。私が気付いていない他の理由で、これはまだ危険かもしれません。

コマンドラインでは、私は推測します。

ただし、 @ ljrittleが指摘し、 @ bentonが認めたように、 --build-arg / ARGを使用する方法はすべてビルドでコミットされます。 したがって、それを調べると、キーに関する情報が明らかになります。 どちらも最終的なDockerコンテナーに状態を残し、その側で同じ脆弱性を被ります。 したがって、dockerがこれを行わないことを推奨する理由。

_USER POLL_

_更新の通知を受け取る最良の方法は、このページの_Subscribe_ボタンを使用することです。_

問題について「+1」または「私もこれもあります」というコメントは使用しないでください。 自動的に
スレッドを短くするために、これらのコメントを収集してください。

以下にリストされている人々は、+ 1のコメントを残して、この問題に賛成しています。

@ fletcher91
@benlemasurier
@dmuso
@probepark
@saada
@ianAndrewClark
@jakirkham
@galindro
@luisguilherme
@akurkin
@allardhoeve
@SevaUA
@sankethkatta
@kouk
@cliffxuan
@ kotlas92
@taion

_USER POLL_

_更新の通知を受け取る最良の方法は、このページの_Subscribe_ボタンを使用することです。_

問題について「+1」または「私もこれもあります」というコメントは使用しないでください。 自動的に
スレッドを短くするために、これらのコメントを収集してください。

以下にリストされている人々は、+ 1のコメントを残して、この問題に賛成しています。

@parknicker
@dursk
@adambiggs

セキュリティリスクの観点から、これは非常に異なります。

docker build --tag=sshtest --build-arg SSH_KEY="$(cat ~/.ssh/path-to-private.key)" .

bashの履歴を除けば、まったく同じです。 その情報が行き着く可能性のある場所はたくさんあります。

たとえば、APIリクエストをサーバーに記録できると考えてください。

これがdocker build --tag=sshtest --build-arg SSH_KEY="fooobar" .デーモンログです

DEBU[0090] Calling POST /v1.22/build
DEBU[0090] POST /v1.22/build?buildargs=%7B%22SSH_KEY%22%3A%22fooobar%22%7D&cgroupparent=&cpuperiod=0&cpuquota=0&cpusetcpus=&cpusetmems=&cpushares=0&dockerfile=Dockerfile&memory=0&memswap=0&rm=1&shmsize=0&t=sshtest&ulimits=null
DEBU[0090] [BUILDER] Cache miss: &{[/bin/sh -c #(nop) ARG SSH_KEY]}
DEBU[0090] container mounted via layerStore: /var/lib/docker/aufs/mnt/de3530a82a1a141d77c445959e4780a7e1f36ee65de3bf9e2994611513790b8c
DEBU[0090] container mounted via layerStore: /var/lib/docker/aufs/mnt/de3530a82a1a141d77c445959e4780a7e1f36ee65de3bf9e2994611513790b8c
DEBU[0090] Skipping excluded path: .wh..wh.aufs
DEBU[0090] Skipping excluded path: .wh..wh.orph
DEBU[0090] Applied tar sha256:5f70bf18a086007016e948b04aed3b82103a36bea41755b6cddfaf10ace3c6ef to 91f79150f57d6945351b21c9d5519809e2d1584fd6e29a75349b5f1fe257777e, size: 0
INFO[0090] Layer sha256:5f70bf18a086007016e948b04aed3b82103a36bea41755b6cddfaf10ace3c6ef cleaned up

_USER POLL_

_更新の通知を受け取る最良の方法は、このページの_Subscribe_ボタンを使用することです。_

問題について「+1」または「私もこれもあります」というコメントは使用しないでください。 自動的に
スレッドを短くするために、これらのコメントを収集してください。

以下にリストされている人々は、+ 1のコメントを残して、この問題に賛成しています。

@ cj2

単純なRuby / Rackアプリケーションをコンテナ化しようとしています。 Gemfileはいくつかのプライベートgemを参照します。 bundle installが起動してプライベートリポジトリにアクセスしようとすると、このエラーが発生し始めます

Host key verification failed.
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

私はそれを回避することができましたが、秘密鍵を公開せずにはいられませんでした。 それはしません。 ssh認証転送を有効にしてください。

ビルド中のssh転送の+1。 そのため、プライベートリポジトリでgo getを使用することはできません;（

このユースケースを安全な方法で有効にするための+1

_USER POLL_

_更新の通知を受け取る最良の方法は、このページの_Subscribe_ボタンを使用することです。_

問題について「+1」または「私もこれもあります」というコメントは使用しないでください。 自動的に
スレッドを短くするために、これらのコメントを収集してください。

以下にリストされている人々は、+ 1のコメントを残して、この問題に賛成しています。

@lukad

この非常に興味深い議論を読んでいるだけで、簡単な解決策でこれらの問題を解決できるのではないかと思います。 私が考えているのは、スナップショットを撮るときに特定の内部ディレクトリ/ファイルを除外/無視できるようにするDockerfileのオプションです。 それはどれほど難しいでしょうか？

すなわち

EXCLUDE .ssh

これは以降のすべての手順に適用されると思います。したがって、FROMの後に配置すると、キーを好きなだけ追加して通常どおりに作成でき、キーが誤ってイメージに表示されることを心配する必要はありません（許可されています）。それらを必要とするすべてのステップでそれらを追加する必要があるかもしれませんが、それらが画像になってしまうことを心配する必要はありません）

@bentonの提案は正常に機能し、dockerデーモンはデバッグモードの場合にのみid_rsaキーをログに記録します。

ビルド中にキーを公開するさらに便利な方法は次のとおりです。

# Dockerfile
ARG SSH_KEY
RUN eval `ssh-agent -s` > /dev/null \
    && echo "$SSH_KEY" | ssh-add - \
    && git clone [email protected]:private/repository.git

docker build -t my_tag --build-arg SSH_KEY="$(< ~/.ssh/id_rsa)" .

Ha、 docker inspect my_tagを見ると、実際にそこに座っているだけですが、ENVよりも少し整理されていることを除けば、boot-argの実際の値が何であるかはわかりません。

また、id_rsaキーにパスワードがある場合は、悪意のある人間である可能性があります。

# Dockerfile
ARG SSH_KEY
ARG SSH_PASS
RUN eval `ssh-agent -s` > /dev/null \
    && echo "echo $SSH_PASS" > /tmp/echo_ps && chmod 700 /tmp/echo_ps \
    && echo "$SSH_KEY" | SSH_ASKPASS=/tmp/echo_ps DISPLAY= ssh-add - \
    && git clone [email protected]:private/repository.git
    && rm /tmp/echo_ps

docker build -t my_tag --build-arg SSH_KEY="$(< ~/.ssh/id_rsa)" --build-arg SSH_PASS=<bad_idea> .

もちろん、それが遠く離れた場所でさえ良い考えであることを合理化するのは難しいです。しかし、私たちは皆人間だと思います。

確かに、これを行う最大の理由はすべて、ビルド中にプライベートリポジトリに対して「バンドルインストール」または「取得」を行う人々のためであるように思われます。

依存関係をベンダーにしてプロジェクト全体を追加するだけだと思いますが、今すぐに作業を行う必要がある場合もあります。

@SvenDowideit @thaJeztahこの問題の解決策はありますか？ 私はスレッドをフォローしようとしましたが、別のスレッドを閉じて開くまでの間、そして多くの意見があり、Dockerチームがいつ何をするのかわかりません。

最高ですが、実装が必要ですか？

Dockerビルドは、ビルド内でssh-agentを使用して、ホストのsshにプロキシし、キーを知らなくてもキーを使用します。

ssh-agentプロキシについて学んだばかりの人のために： githubが救いの手を差し伸べます

@phemmerのオリジナルのアイデア。

@yordisスレッドには、まだ無料で利用できる「優れた」ソリューションはないと思います。

docker / docker-py＃980からのこのコメントは、sshキーをホストシステムのrootユーザーのキーディレクトリにコピーすると、デーモンがそれらのキーを使用することを示しているようです。 しかし、私はこの点で狂った初心者なので、他の誰かが明確にすることができるかもしれません。

わかりましたが、最高ではありません

Docker1.8のビルド引数を使用してキーを渡します。
警告。

間違いなく悪い考え

多くの人が、ここでキーをビルドコンテキストに一時的に追加してから、すぐに削除することも推奨しています。 キーがコミットの1つに忍び込んだ場合、コンテナを使用する人は誰でも特定のコミットをチェックアウトすることでそのキーにアクセスできるため、非常に危険に聞こえます。

なぜこれはまだどこにも行っていないのですか？

デザインの提案が必要です。この問題は_cah _-_ luttered_であり、現時点ではアイデアはあいまいです。 実際の実装の詳細は、「xを実行した場合はどうなるか」と+1のかすみで失われています。 整理してこの非常に必要な機能に取り掛かるには、可能な解決策を持っている人はを作成する必要があります。 。 。

デザイン提案

次に、この問題を参照してください。

この問題についていくつかのニュースがあります。

先週のDockerConでは、Dockerの「Askthe Experts」パビリオンに最も難しい質問をするように勧められたので、私は行き、励ましのタイトルであるSolutionsArchitectの賢くてフレンドリーなエンジニアと短いチャットをしました。 私は彼にこの問題の簡単な要約を与えました。彼はこれが_only _ docker-composeできると私に保証したので、私が正確に伝えたことを願っています！ 彼が提案した内容の詳細には、多段階のビルド（おそらく、最終的なアプリのビルドとは異なるコンテキストで依存関係を蓄積するため）が含まれ、ビルド時にデータボリュームを使用する必要があるようでした。

残念ながら、私はdocker-composeの経験がないため、すべての詳細を追跡することはできませんでしたが、正確な問題について彼に手紙を書いた場合、彼は解決策で応答すると彼は私に約束しました。 そこで、この未解決のGitHubの問題への参照を含む、十分に明確な電子メールであると私が望むものを書きました。 そして今朝、彼から何かを思いついたときに返事をするという安心感を持って返事をしました。

彼は忙しいので、すぐには何も期待していませんが、彼が問題を理解し、Dockerネイティブのツールセットだけで攻撃する準備ができている限り、これは励みになります。

@bentonこのトピックで説明されていることを行うために、 構成を使用します。

version: '2'
services:
  serviceName:
     volumes:
      - "${SSH_AUTH_SOCK}:/tmp/ssh-agent"
    environment:
      SSH_AUTH_SOCK: /tmp/ssh-agent

ssh-agentがホストマシンで起動し、キーを認識していることを確認します（ssh-add -Lコマンドで確認できます）。

追加が必要な場合があることに注意してください

Host *
  StrictHostKeyChecking no

コンテナの.ssh / configに。

こんにちは@WoZ！ 答えてくれてありがとう、とてもシンプルに見えるので試してみます:)

質問がありますが、Docker Hubの自動ビルドでこれをどのように使用できますか？ 私の今のところ、そこに作成ファイルを使用する方法はありません:(

@garcianavalonはうまく動作しますが、それだけのためだrun 、ないbuild 。 Docker for Macもまだ動作していませんが、ToDoリストに含まれているようです。

編集： https ：

特定のニーズに対応するために、さらに2つの回避策を考え出しました。

1）VPNの背後にあるnpm、pypiなどの独自のパッケージミラーをセットアップします。この方法では、SSHは必要ありません。

2）すでにプライベートリポジトリにアクセスできるすべてのホストマシン。プライベートパッケージをホストマシンにローカルで複製/ダウンロードし、パッケージのインストールを実行してダウンロードし、-vを使用してボリュームをdockerにマップしてから、dockerをビルドします。

現在、オプション2）を使用しています。

docker run限り、 docker-ssh-agent-forwardは洗練されたソリューションを提供しているようで、Mac / Linux用のDocker全体で機能します。

known_hostsファイルをコンテナに作成するのではなく（安全性が低い）、ホストからコピーすることをお勧めします。ssh-agentは既知のホストを転送していないようです。

ただし、Dockerの実行ステップ中にプライベート依存関係をプルする際の基本的な問題は、Dockerビルドキャッシュをバイパスすることです。これは、ビルド時間の観点から非常に重要になる可能性があります。

この制限を回避する1つの方法は、ビルド依存関係宣言（ package.json ）をmd5 / dateし、結果をイメージにプッシュして、ファイルが変更されていない場合は同じイメージを再利用することです。 画像名にハッシュを使用すると、複数の状態をキャッシュできます。 インストール前のイメージダイジェストとも組み合わせる必要があります。

これは、ビルドサーバー用の@aidanhsのソリューションよりも堅牢であるはずですが、それでも大規模にテストする必要があります。

これは、ビルドサーバー用の@aidanhsのソリューションよりも堅牢であるはずですが、それでも大規模にテストする必要があります。

私の特定のソリューションは1.9.0以降機能していません。私が依存していた、1.8.0で導入された機能は意図的ではないことが判明したため、削除されました。

私のソリューションの原則は問題ありませんが（a）マシンが使用しb）適切な場所にエントリを追加できるDNSサーバーがマシンから離れている必要があります）、私は熱心に言うことはできませんもうお勧めします。

追加情報@aidanhsをありがとう！

提案されたソリューションに関するいくつかの更新：依存関係宣言ファイルを追加した直後のベースイメージのハッシュを使用できるため、ハッシュを実際に組み合わせる必要はありません。 さらに、ssh-agentは実行時にのみ使用できるため、known_hostファイルをボリュームとしてマウントする方が適切です。また、接続するすべてのホストのリストが含まれているため、より安全です。

node / npmの完全なソリューションを実装しました。これは、詳細なドキュメントと例とともにここにあります： https ：

もちろん、原則は他のフレームワークにも拡張できます。

ここで同じ問題があります。イメージやベースイメージにクレデンシャルを書き込まずに、Dockerコンテナー内で、ビルド時に多数のプロジェクトをチェックしてビルドするためにSSHクレデンシャルが必要な場合、どのように何かをビルドしますか。

https://github.com/bibendi/dip#dip -ssh

これを回避するには、2段階のビルドプロセスを使用します。 ソース/キー/ビルドの依存関係を含む「ビルド」イメージが作成されます。 ビルドされると、ビルド結果をtarfileに抽出するために実行され、後で「デプロイ」イメージに追加されます。 その後、ビルドイメージが削除され、公開されるのは「デプロイ」イメージだけです。 これには、コンテナ/レイヤーのサイズを低く抑えるという優れた副作用があります。

@ binarytemple-bet365正確にそれを行うエンドツーエンドの例については、 https：//github.com/iheartradio/docker-nodeを参照して

Rockerをチェックしてください。これはクリーンなソリューションです。

@Sodki私はあなたのアドバイスを受けました。 はい、ロッカーはクリーンでよく考えられたソリューションです。 Dockerチームがそのプロジェクトを自分たちの翼の下に置いて、 docker buildを廃止するだけではないのは残念です。 ありがとう。

それでも良い方法はありませんか？ :(

誰かがこの新しいスカッシュを試しましたか？ https://github.com/docker/docker/pull/22641私たちが探しているdockerネイティブソリューションかもしれません。 今それを試して、それがどうなるかを見るために報告してください。

2年以上経っても、これはまだ修正されていません😞Dockerチームに何かしてください

1.13の新しい--squashオプションが機能しているようです。
http://g.recordit.co/oSuMulfelK.gif

私はそれを次のように構築します： docker build -t report-server --squash --build-arg SSH_KEY="$(cat ~/.ssh/github_private_key)" .

したがって、 docker historyまたはdocker inspectと、キーが表示されません。

私のDockerfileは次のようになります。

FROM node:6.9.2-alpine

ARG SSH_KEY

RUN apk add --update git openssh-client && rm -rf /tmp/* /var/cache/apk/* &&\
  mkdir -p /root/.ssh && chmod 0700 /root/.ssh && \
  ssh-keyscan github.com > /root/.ssh/known_hosts

RUN echo "$SSH_KEY" > /root/.ssh/id_rsa &&\
  chmod 0600 /root/.ssh/id_rsa

COPY package.json .

RUN npm install
RUN rm -f /root/.ssh/id_rsa

# Bundle app source
COPY . .

EXPOSE 3000

CMD ["npm","start"]

@ kienpham2000 、スクリーンショットにはまだキーが含まれているようです- --no-truncフラグを使用してdocker historyの出力を確認し、秘密キーがDockerに表示されているかどうかをここに報告してください。歴史？

@ryanschwartzあなたは正しいです、 --no-truncは全体を示しています、これは飛ばないです。

@ kienpham2000
1.13リリースで導入されたもう1つのことは、次のとおりです。

秘密を築く
•—build-secretフラグを使用してビルドタイムシークレットを有効にします
•ビルド中にtmpfsを作成し、シークレットを
ビルド中に使用されるビルドコンテナ。
• https ：

多分これはうまくいくでしょうか？

ビルドシークレットは1.13にはなりませんでしたが、うまくいけば1.14になります。

2016年12月15日午前9時45分、「Alex」 [email protected]は次のように書いています。

@ kienpham2000 https://github.com/kienpham2000
1.13リリースで導入されたもう1つのことは、次のとおりです。

秘密を築く
•—build-secretフラグを使用してビルドタイムシークレットを有効にします
•ビルド中にtmpfsを作成し、シークレットを
ビルド中に使用されるビルドコンテナ。
•＃28079 https://github.com/docker/docker/pull/28079

多分これはうまくいくでしょうか？

—
このスレッドにサブスクライブしているため、これを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/docker/docker/issues/6396#issuecomment-267393020 、またはミュート
スレッド
https://github.com/notifications/unsubscribe-auth/AAdcPDxrctBP2TlCtXen-Y_uY8Y8B09Sks5rIXy2gaJpZM4CD4SM
。

それで1年後：いいえ、これは悪い考えです。 あなたはそれをすべきではありません。 他にもさまざまな解決策があります。 たとえば、Githubはアクセストークンを提供できます。 トークンごとに許可されるアクションを指定できるため、リスクの少ない構成ファイル/環境変数でそれらを使用できます。

解決策は、SSH転送を実装することです。 たとえば、Vagrantのように。

誰かが私にそれを実装するのがなぜそんなに複雑なのか説明できますか？

@ omarabid -

アクセストークンを使用するというあなたの提案に関しては、それらは最終的にレイヤーに保存され、SSHキーと同じように置き去りにするのと同じくらい危険な場合があります。 読み取り専用アクセスしか持っていない場合でも、ほとんどの人は他の人が自分のリポジトリへの読み取り専用アクセスを持っていることを望んでいません。 また、頻繁な失効/ローテーション/配布が発生する必要があります。 これは、「マスター」アクセストークンを使用するよりも、開発者などごとに処理する方が少し簡単です。

いくつかのコメントを述べたビルドシークレットソリューションは、正しい方向への一歩のように見えますが、SSHエージェントを使用する機能が最適です。 SSHエージェントをビルドシークレットと組み合わせて使用​​できるかもしれませんが、よくわかりません。

開発者/ CIシステムがgit / build操作中にSSHエージェントを使用するのは自然なことです。 これは、さまざまなシステムで一括して取り消す/置き換える必要のある、パスワードなしのプレーンテキストの秘密鍵を使用するよりもはるかに安全です。 また、SSHエージェントを使用すると、秘密鍵データがイメージにコミットされる可能性はありません。 最悪の場合、環境変数/ SSH_AUTH_SOCKレムナントがイメージに残されます。

シークレットキーのコンテンツを表示したり、追加のサードパーティのDockerツールを使用したりせずに、この最新の回避策を入手しました（ビルドされたPR中のシークレットボールトがすぐにマージされることを願っています）。

aws cliを使用して、共有秘密鍵をS3からホストの現在のリポジトリにダウンロードしています。 このキーは、KMSを使用して保存時に暗号化されます。 キーがダウンロードされると、Dockerfileはビルドプロセス中にそのキーをコピーし、後で削除します。コンテンツはdocker inspectまたはdocker history --no-trunc表示されません。

最初にS3からホストマシンにgithub秘密鍵をダウンロードします。

# build.sh
s3_key="s3://my-company/shared-github-private-key"
aws configure set s3.signature_version s3v4
aws s3 cp $s3_key id_rsa --region us-west-2 && chmod 0600 id_rsa

docker build -t app_name .

Dockerfileは次のようになります。

FROM node:6.9.2-alpine

ENV id_rsa /root/.ssh/id_rsa
ENV app_dir /usr/src/app

RUN mkdir -p $app_dir
RUN apk add --update git openssh-client && rm -rf /tmp/* /var/cache/apk/* && mkdir -p /root/.ssh && ssh-keyscan github.com > /root/.ssh/known_hosts

WORKDIR $app_dir

COPY package.json .
COPY id_rsa $id_rsa
RUN npm install && npm install -g gulp && rm -rf $id_rsa

COPY . $app_dir
RUN rm -rf $app_dir/id_rsa

CMD ["start"]

ENTRYPOINT ["npm"]

@ kienpham2000 、なぜこのソリューションは画像レイヤーにキーを保持しないのですか？ キーのコピーと削除のアクションは別々のコマンドで実行されるため、キーを持つ必要のあるレイヤーがあります。
私たちのチームは昨日まであなたのソリューションを使用していましたが、改善されたソリューションを見つけました：

• aws s3 cliを使用してキーにアクセスするための事前署名URLを生成し、アクセスを約5分間制限し、この事前署名URLをrepoディレクトリのファイルに保存してから、dockerfileでイメージに追加します。
• dockerfileには、次のすべての手順を実行するRUNコマンドがあります。pre-singURLを使用してsshキーを取得し、npm installを実行して、sshキーを削除します。
  これを1つのコマンドで実行すると、sshキーはどのレイヤーにも保存されませんが、事前署名URLは保存されます。これは、5分後にURLが無効になるため、問題ありません。

ビルドスクリプトは次のようになります。

# build.sh
aws s3 presign s3://my_bucket/my_key --expires-in 300 > ./pre_sign_url
docker build -t my-service .

Dockerfileは次のようになります。

FROM node

COPY . .

RUN eval "$(ssh-agent -s)" && \
    wget -i ./pre_sign_url -q -O - > ./my_key && \
    chmod 700 ./my_key && \
    ssh-add ./my_key && \
    ssh -o StrictHostKeyChecking=no [email protected] || true && \
    npm install --production && \
    rm ./my_key && \
    rm -rf ~/.ssh/*

ENTRYPOINT ["npm", "run"]

CMD ["start"]

@diegocsandrimはそれを指摘してくれてありがとう、私はあなたの解決策が本当に好きです、ここで私たちのものを更新するつもりです。 共有してくれてありがとう！

私はスレッドに少し慣れていませんが、基本的に、人々はPKIによってよりよく解決される問題を解決しようとしているようです。 誰もが必ずしもPKIがより良い解決策となる同じ問題を救おうとしているわけではありませんが、十分な参考資料は、それが考慮されるべきものである可能性があることを示しているようです。

煩わしいようですが、基本的には可能です

• ローカル認証局を作成する
• 証明書を生成するプロセスがあります
• 証明書を発行するプロセスがあります
• 上記の証明書を取り消すプロセスがあります
• sshデーモンにPKIを使用させる

そして、これが実現可能であると人々が感じた場合は、すべての作業が一度うまくいく必要があるので、ぜひそれを作成してオープンソースにしてください。 roumen petrovビルドが安全であり、ソースコードを記録していない（tarをチェックしていない）かどうかはわかりません。したがって、どれほど安全かはわかりません。

https://security.stackexchange.com/questions/30396/how-to-set-up-openssh-to-use-x509-pki-for-authentication

https://jamielinux.com/docs/openssl-certificate-authority/create-the-root-pair.html

@mehmetcodes ：PKIを持っていても、実際には問題は解決しません。 PKIベースのSSH認証を機能させるには、イメージに秘密鍵をロードする必要があります。

ローカル認証局が非常に短命の証明書（たとえば1時間未満）を発行していて、ビルドが成功した直後に証明書を取り消さない限り、これは安全ではありません。

短期間の証明書プロセスを作成することに成功した場合、それは、ビルドが完了した直後に取り消す新しいSSHキーを使用することと大差ありません。

ああ、それよりもさらに厄介ですが、私は何かに取り掛かる必要がありますか、それともなぜそれが野生に存在するのでしょうか？

https://blog.cloudflare.com/red-october-cloudflares-open-source-implementation-of-the-two-man-rule/
https://blog.cloudflare.com/how-to-build-your-own-public-key-infrastructure/

わかりませんが、SSH一時キーはおそらくほとんどのユースケースではるかに優れていますが、特にこのコンテキストでは、私が提案したものを含め、すべての手段について不安なことがあります。

http://blog.cloud66.com/using-ssh-private-keys-securely-in-docker-build/についてどう思います

通常は、代わりにキーを使用してボリュームをマウントするだけですが、Mac / mobyソリューション用のDockerの必要性はありません。

f ..は誰ですか？

@白色

私はMacOSでこれまで持っています：

bash-3.2$ docker run -t -i -v "$SSH_AUTH_SOCK:/tmp/ssh_auth_sock" -e "SSH_AUTH_SOCK=/tmp/ssh_auth_sock" python:3.6 ssh-add -l
docker: Error response from daemon: Mounts denied:
The path /var/folders/yb/880w03m501z89p0bx7nsxt580000gn/T//ssh-DcwJrLqQ0Vu1/agent.10466
is not shared from OS X and is not known to Docker.
You can configure shared paths from Docker -> Preferences... -> File Sharing.
See https://docs.docker.com/docker-for-mac/osxfs/#namespaces for more info.
.

/ var /は、Dockerが苦労しているように見えるエイリアスです。 しかし、$ SSH_AUTH_SOCKパスの前に/private （つまり、解決されたエイリアスパス）を付けると、Dockerはファイルを読み取ることができますが、次のようになります。

bash-3.2$ docker run -t -i -v "/private$SSH_AUTH_SOCK:/tmp/ssh_auth_sock" -e "SSH_AUTH_SOCK=/tmp/ssh_auth_sock" python:3.6 ssh-add -l
Could not open a connection to your authentication agent.

この時点で、私はただ…がどれほど悪いのか疑問に思っています。

docker run -v ~/.ssh:/root/.ssh python:3.6 bash

？

docker build  --build-arg ssh_prv_key="$(cat ~/.ssh/id_rsa_no_pass)" --build-arg ssh_pub_key="$(cat ~/.ssh/id_rsa.pub)" --squash .

そして、Dockerファイル内：

ARG ssh_prv_key
ARG ssh_pub_key

# Authorize SSH Host
RUN mkdir -p /root/.ssh && \
    chmod 0700 /root/.ssh && \
    ssh-keyscan github.com > /root/.ssh/known_hosts

# Add the keys and set permissions
RUN echo "$ssh_prv_key" > /root/.ssh/id_rsa && \
    echo "$ssh_pub_key" > /root/.ssh/id_rsa.pub && \
    chmod 600 /root/.ssh/id_rsa && \
    chmod 600 /root/.ssh/id_rsa.pub

そして、含めることを忘れないでください

RUN rm -f /root/.ssh/id_rsa /root/.ssh/id_rsa.pub

最後のステップとして。

ここでの落とし穴は、秘密鍵をパスワードで保護してはならないということです。

前のコメントの問題は、キーがレイヤーに配置されることです... Dockerファイルの各行は1つのレイヤーであるため、rmは前のレイヤーから削除されません。

docker secretこの問題を解決しませんか？
WDYT @thaJeztah

docker secretは（まだ）ビルド中は利用できず、サービスでのみ利用できます（したがって、まだdocker runでは利用できません）

マルチステージビルドを使用すると、このようなものが機能する可能性があります（私の電話で入力しているので、しばらく前に作成した要点をリンクさせてください）。 https://gist.github.com/thaJeztah/836c4220ec024cf6dd48ffa850f07770

私はもうDockerに関与していませんが、この問題がこれほど長い間存在する可能性はどのようにありますか。 私は声をかけようとはしていませんが、これを修正するために必要な努力を理解するのではなく、これを扱っていたとき、 ruby gemsようなプライベートパッケージをプライベートリポジトリ。

Mobyはこの問題を気にしますか？ 私が推測するほど大したことではないように思われる何かのためにそれがそれほど難しい必要があるのはなぜですか。

ほぼ3年になります😢

@yordis dockerbuilderは1年か2年凍結されました。 Dockerチームは、ビルダーは十分に優れており、他の場所に注力していると述べました。 しかし、これはなくなり、それ以来、ビルダーに2つの変更がありました。 スカッシュとムストリのステージビルド。 そのため、ビルドタイムの​​秘密が途中にある可能性があります。

ssh-agentのランタイム転送には、 https：//github.com/uber-common/docker-ssh-agent-forwardをお勧めし

私が推測するほど大したことではないように思われる何かのためにそれがそれほど難しい必要があるのはなぜですか。

@yordisはこの問題のトップの説明を読んで、これを実装するのは簡単ではありません。 そうは言っても、誰かがこれに関する技術的な設計提案を持っている場合は、議論のために問題またはPRを開いてください。 また、_build_部分については、ビルダーの将来の拡張のためにbuildkitプロジェクトが開始されたことにも注意してください。 https://github.com/moby/buildkit

@thaJeztah必要なスキルがあればいいのですが、そうではありません。

@villlem Dockerチームからのロードマップを知っていますか？

ビルダーの週次レポートはここにあります。 https://github.com/moby/moby/tree/master/reports/builderビルド時間の秘密は、最新のレポートに引き続きリストされていますが、ヘルプを使用できます

@diegocsandrimのソリューションを使用していますが、S3に暗号化されていないSSHキーが

この追加の手順は、キーをDockerイメージから復元できず（ダウンロードするためのURLが5分後に期限切れになる）、AWSから復元できないことを意味します（dockerイメージのみが知っているローテーションパスワードで暗号化されているため） 。

build.shの場合：

BUCKET_NAME=my_bucket
KEY_FILE=my_unencrypted_key
openssl rand -base64 -out passfile 64
openssl enc -aes-256-cbc -salt -in $KEY_FILE -kfile passfile | aws s3 cp - s3://$BUCKET_NAME/$(hostname).enc_key
aws s3 presign s3://$BUCKET_NAME/$(hostname).enc_key --expires-in 300 > ./pre_sign_url
docker build -t my_service

そしてDockerfileで：

COPY . .

RUN eval "$(ssh-agent -s)" && \
    wget -i ./pre_sign_url -q -O - | openssl enc -aes-256-cbc -d -kfile passfile > ./my_key && \
    chmod 700 ./my_key && \
    ssh-add ./my_key && \
    mkdir /root/.ssh && \
    chmod 0700 /root/.ssh && \
    ssh-keyscan github.com > /root/.ssh/known_hosts && \
    [commands that require SSH access to Github] && \
    rm ./my_key && \
    rm ./passfile && \
    rm -rf /root/.ssh/

docker run場合は、.sshを--mount type=bind,source="${HOME}/.ssh/",target="/root/.ssh/",readonlyマウントする必要があります。 読み取り専用は魔法であり、通常のアクセス許可をマスクし、sshは基本的に満足のいく0600のアクセス許可を確認します。 -u root:$(id -u $USER)遊んで、コンテナ内のrootユーザーに、ユーザーと同じグループで作成したファイルを書き込ませることもできます。そうすれば、chmod / chownを使用せずに、完全に書き込まない場合でも、少なくともそれらを読み取ることができます。 。

ついに。

この問題は、多段階ビルドを使用することで、 docker buildだけで解決できると思います。
必要な場所でSSHキーまたはその他のシークレットをCOPYまたはADDするだけで、 RUNステートメントで好きなように使用できます。

次に、2番目のFROMステートメントを使用して新しいファイルシステムを開始し、 COPY --from=builderを使用してシークレットを含まないディレクトリのサブセットをインポートし

（実際にはまだ試していませんが、機能が説明どおりに機能する場合は...）

@bentonマルチステージビルドは説明

次の手法を検証しました。

1. _秘密鍵の場所_をビルド引数としてGITHUB_SSH_KEYなどのマルチステージビルドの最初のステージに渡します
2. ADDまたはCOPYを使用して、認証に必要な場所にキーを書き込みます。 キーの場所が（URLではなく）ローカルファイルシステムパスである場合は、 .dockerignoreファイルに含まれていない必要があります。そうでない場合、 COPYディレクティブは機能しません。 ステップ4でわかるように、これは最終的な画像に影響を及ぼします...
3. 必要に応じてキーを使用してください。 以下の例では、キーはGitHubへの認証に使用されています。 これは、RubyのbundlerおよびプライベートGemリポジトリでも機能します。 この時点で含める必要のあるコードベースの量によっては、 COPY .またはADD .を使用した場合の副作用として、キーを再度追加することになります。
4. 必要に応じてキーを削除します。 キーの場所がローカルファイルシステムパス（URLではない）の場合、 ADD .またはCOPY .実行したときに、コードベースと一緒に追加された可能性があります。これはおそらく_正確にはディレクトリ_です。最終的なランタイムイメージにコピーされるため、キーの使用が終了したら、おそらくRUN rm -vf ${GITHUB_SSH_KEY}ステートメントも含める必要があります。
5. アプリがWORKDIRに完全に組み込まれたら、新しいFROMステートメントで2番目のビルド段階を開始し、目的のランタイムイメージを示します。 必要なランタイム依存関係をインストールしてから、最初のステージのWORKDIRに対してCOPY --from=builderをインストールします。

上記の手法を示すDockerfile例を次に示します。 GITHUB_SSH_KEYビルド引数を指定すると、ビルド時にGitHub認証がテストされますが、キーデータは最終的なランタイムイメージに含まれません。 GITHUB_SSH_KEYは、ファイルシステムパス（Dockerビルドディレクトリ内）またはキーデータを提供するURLにすることができますが、この例ではキー自体を暗号化しないでください。

########################################################################
# BUILD STAGE 1 - Start with the same image that will be used at runtime
FROM ubuntu:latest as builder

# ssh is used to test GitHub access
RUN apt-get update && apt-get -y install ssh

# The GITHUB_SSH_KEY Build Argument must be a path or URL
# If it's a path, it MUST be in the docker build dir, and NOT in .dockerignore!
ARG GITHUB_SSH_KEY=/path/to/.ssh/key

  # Set up root user SSH access for GitHub
ADD ${GITHUB_SSH_KEY} /root/.ssh/id_rsa

# Add the full application codebase dir, minus the .dockerignore contents...
# WARNING! - if the GITHUB_SSH_KEY is a file and not a URL, it will be added!
COPY . /app
WORKDIR /app

# Build app dependencies that require SSH access here (bundle install, etc.)
# Test SSH access (this returns false even when successful, but prints results)
RUN ssh -o StrictHostKeyChecking=no -vT [email protected] 2>&1 | grep -i auth

# Finally, remove the $GITHUB_SSH_KEY if it was a file, so it's not in /app!
# It can also be removed from /root/.ssh/id_rsa, but you're probably not going
# to COPY that directory into the runtime image.
RUN rm -vf ${GITHUB_SSH_KEY} /root/.ssh/id*

########################################################################
# BUILD STAGE 2 - copy the compiled app dir into a fresh runtime image
FROM ubuntu:latest as runtime
COPY --from=builder /app /app

キーデータの_場所_よりも、 GITHUB_SSH_KEYビルド引数でキーデータ自体を渡す方が安全かもしれません。 これにより、キーデータがローカルファイルに保存されてからCOPY .追加された場合に、誤ってキーデータが含まれるのを防ぐことができます。 ただし、これにはechoとシェルリダイレクトを使用してデータをファイルシステムに書き込む必要があり、すべてのベースイメージで機能するとは限りません。 ベースイメージのセットに対して最も安全で実行可能な手法を使用します。

@jbielもう1年、私が見つけた解決策は、Vaultのようなものを使用することです。

これが2つのメソッドへのリンクです（@bentonによって前述されたスカッシュと中間コンテナー）

アクセスが必要なアクションを実行するたびにエージェントがパスフレーズの入力を求めるため、使用しているsshキーにパスフレーズがある場合、現在のアプローチはどちらも機能しないというメモを追加します。 キーフレーズを渡さずにこれを回避する方法はないと思います（これは多くの理由で望ましくありません）

解決する。
bashスクリプトを作成します（〜/ bin / docker-composeなど）：

#!/bin/bash

trap 'kill $(jobs -p)' EXIT
socat TCP-LISTEN:56789,reuseaddr,fork UNIX-CLIENT:${SSH_AUTH_SOCK} &

/usr/bin/docker-compose $@

そして、socatを使用するDockerfileで：

...
ENV SSH_AUTH_SOCK /tmp/auth.sock
...
  && apk add --no-cache socat openssh \
  && /bin/sh -c "socat -v UNIX-LISTEN:${SSH_AUTH_SOCK},unlink-early,mode=777,fork TCP:172.22.1.11:56789 &> /dev/null &" \
  && bundle install \
...
or any other ssh commands will works

次に、 docker-compose build実行します

@bentonなぜRUN rm -vf ${GITHUB_SSH_KEY} /root/.ssh/id*を使用するのですか？ RUN rm -vf /root/.ssh/id*だけではいけませんか？ あるいは、ここでの意図を誤解したのかもしれません。

@bentonそしてまたそれは安全ではありません：

RUN ssh -o StrictHostKeyChecking=no -vT [email protected] 2>&1

指紋を確認する必要があります

私はこの方法でこの問題を解決しました

ARGS USERNAME
ARGS PASSWORD
RUN git config --global url."https://${USERNAME}:${PASSWORD}@github.com".insteadOf "ssh://[email protected]"

次に、

docker build --build-arg USERNAME=use --build-arg PASSWORD=pwd. -t service

ただし、最初は、プライベートgitサーバーがusername:passwordクローンリポジトリをサポートしている必要があります。

コンテナ履歴に保存されている@zeayesRUNコマンド。したがって、あなたのパスワードは他の人に見えるようになります。

正しい; --build-arg / ARGを使用すると、これらの値がビルド履歴に表示されます。 マルチステージビルドを使用する場合は、この手法を使用できます。また、イメージがビルドされるホストを信頼し（つまり、信頼できないユーザーがローカルビルド履歴にアクセスできない場合）、中間ビルドステージはレジストリにプッシュされません。

たとえば、次の例では、 USERNAMEとPASSWORDは最初のステージ（「ビルダー」）の履歴にのみ発生しますが、最終ステージの履歴には含まれません。

FROM something AS builder
ARG USERNAME
ARG PASSWORD
RUN something that uses $USERNAME and $PASSWORD

FROM something AS finalstage
COPY --from= builder /the/build-artefacts /usr/bin/something

最終イメージ（「finalstage」によって生成された）のみがレジストリにプッシュされる場合、 USERNAMEとPASSWORDはそのイメージに含まれません。

_ただし_、ローカルビルドキャッシュ履歴では、これらの変数は引き続き存在します（そして、プレーンテキストでディスクに保存されます）。

次世代ビルダー（ BuildKitを使用）には、ビルド時のシークレットの受け渡しに関連する、より多くの機能があります。 Docker 18.06で実験的な機能として利用できますが、将来のリリースで実験的な機能がなくなり、さらに多くの機能が追加されます（現在のバージョンでシークレット/クレデンシャルがすでに可能かどうかを確認する必要があります）

@kinnalru @thaJeztah thx、私はマルチステージビルドを使用していますが、パスワードはキャッシュコンテナの履歴で確認できます

@zeayesああ！ コピー/貼り付けエラーが発生したようです。 最終段階ではFROM builder ..使用しないでください。 これが完全な例です。 https://gist.github.com/thaJeztah/a​​f1c1e3da76d7ad6ce2abab891506e50

@kinnalruによるこのコメントは、これを行う正しい方法ですhttps://github.com/moby/moby/issues/6396#issuecomment -348103398

この方法では、dockerが秘密鍵を処理することはありません。 また、新しい機能を追加しなくても、今日でも機能します。

それを理解するのに少し時間がかかったので、ここにもっと明確で改善された説明があります。 @kinnalruコードを--network=hostとlocalhostを使用するように変更したので、IPアドレスを知る必要はありません。 （要点はこちら）

これはdocker_with_host_ssh.sh 、Dockerをラップし、 SSH_AUTH_SOCKをローカルホストのポートに転送します。

#!/usr/bin/env bash

# ensure the processes get killed when we're done
trap 'kill $(jobs -p)' EXIT

# create a connection from port 56789 to the unix socket SSH_AUTH_SOCK (which is used by ssh-agent)
socat TCP-LISTEN:56789,reuseaddr,fork UNIX-CLIENT:${SSH_AUTH_SOCK} &
# Run docker
# Pass it all the command line args ($@)
# set the network to "host" so docker can talk to localhost
docker $@ --network='host'

Dockerfileで、ローカルホストを介してホストssh-agentに接続します。

FROM python:3-stretch

COPY . /app
WORKDIR /app

RUN mkdir -p /tmp

# install socat and ssh to talk to the host ssh-agent
RUN  apt-get update && apt-get install git socat openssh-client \
  # create variable called SSH_AUTH_SOCK, ssh will use this automatically
  && export SSH_AUTH_SOCK=/tmp/auth.sock \
  # make SSH_AUTH_SOCK useful by connecting it to hosts ssh-agent over localhost:56789
  && /bin/sh -c "socat UNIX-LISTEN:${SSH_AUTH_SOCK},unlink-early,mode=777,fork TCP:localhost:56789 &" \
  # stuff I needed my ssh keys for
  && mkdir -p ~/.ssh \
  && ssh-keyscan gitlab.com > ~/.ssh/known_hosts \
  && pip install -r requirements.txt

次に、スクリプトを呼び出してイメージを作成できます。

$ docker_with_host_ssh.sh build -f ../docker/Dockerfile .

@cowlicksこのプルリクエストに興味があるかもしれません。これは、ビルド中にSSHエージェントを転送するためのdocker build --sshサポートを追加します。 https://github.com/docker/cli/pull/1419。 Dockerfile構文はまだ公式仕様には含まれていませんが、Dockerfileでsyntax=..ディレクティブを使用して、それをサポートするフロントエンドを使用できます（プルリクエストの例/手順を参照）。

そのプルリクエストは、次の18.09リリースの一部になります。

これは18.09リリースで利用できるようになりました。 このスレッドはリリースノートとミディアムポストの前に出てくるので、ここでクロスポストします。

リリースノート：
https://docs.docker.com/develop/develop-images/build_enhancements/#using -ssh-to-access-private-data-in-builds

ミディアムポスト：
https://medium.com/@tonistiigi/build -secrets-and-ssh-forwarding-in-docker-18-09-ae8161d066

とてもわくわくする。

@kalenpはhttps://github.com/moby/buildkit/issues/760およびhttps://github.com/moby/buildkit/issues/825も参照してください

docker build --sshがあるので、これを閉じることができると思います

ここで関連する作成の問題：docker / compose＃6865。 使用する機能SSHエージェントソケットを作成し、次のリリース候補である1.25.0-rc3（リリース）に到達することが示されているコンテナーに公開します。