ping @ewindisch @ diogomonica @ NathanMcCauleyこれは簡単な記事です。 必要だと思われる場合は、説明を自由に変更/更新してください:)

これは便利な情報です：

https://github.com/hashicorp/vault/issues/165

これは次のとおりです。

https://github.com/hashicorp/vault/issues/164

@ dreamcat4一般的な「シークレットAPI」を実装する計画がいくつかあります。これにより、Vault、Keywiz、またはDockerでyou-name-itを使用できますが、すべて同じ方法です。 これは初期の考えであるため、追加の調査が必要になります。

@thaJeztahうん申し訳ありませんが、これらの努力や議論を決して損なうことはしたくありません。 私は、おそらくそれが（そのより長いプロセスの一部として、そして私たちが待っている間に）私たちが今どこまで到達できるかを見るための有用な演習でもあるのではないかと考えています。 次に、現在のプロセスの限界と欠陥を他の人にはっきりと示します。 根底にあるものが欠けており、秘密を改善するために最も追加する必要があります。

また、実行時シークレットとビルド時シークレットのさまざまな状況について検討する価値があります。 エリアオーバーラップエリアもあります。

また、おそらく（dockerの場合）、「メモリ内」の秘密を処理するメカニズムを提供するソリューション間の制限（長所/短所）を検討する価値があるかもしれません。 より多くのファイルベースのシークレットメソッドまたはネットワークベースのメソッド（ローカルシークレットサーバーなど）とは対照的です。 テーブルの現在のハックはどれですか（適切なシークレットAPIまで）。 これは、現在のDocker機能セットに加えてハックを使用することでは達成できなかったdocker secrets APIによって追加された独自の価値（たとえば、より強力なセキュリティ）の一部を理解するのに役立ちます。 しかし、私はセキュリティの専門家ではありません。 ですから、私はそれらのことについてこれほど確実にコメントすることはできません。

@ dreamcat4はい、その通りです。 短期的には、これらのリンクは確かに便利です。

また、実行時シークレットとビルド時シークレットのさまざまな状況について検討する価値があります。 エリアオーバーラップエリアもあります。

ありがとう！ 私の元の説明では、その過程で迷子になっているに違いないと思います。 箇条書きを追加します

しかし、私はセキュリティの専門家ではありません。

私もそうではありません。それが私がセキュリティメンテナに「ping」した理由です。 IMO、これは彼らによって書かれたものでなければなりません😇

@thaJeztah素晴らしい要約。 いつか見つけたら、これを突くようにします。

@diogomonicaは_直接_関連していませんが、ビルド中にSSHキーエージェントを転送するための長いオープン機能のリクエストがあります。 https://github.com/docker/docker/issues/6396コメントの数を考えると、それについても考えてみるとよいでしょう。 （それを実行できるかどうか/実行すべきかどうかを決定する場合でも）

ルート以外のユーザーとしてボリュームをマウントできると仮定すると（不可能だとは思いますが、ユーモアを交えて）、それは秘密をコンテナーに取り込むための好ましいアプローチでしょうか？

もしそうなら、私はへの代替を提唱したい-v host_dir:image_dirデータのみのコンテナを使用することを期待し、のように見えるかもしれない-vc host_dir:image_dir （すなわち、ボリューム・コピー）をhost_dirの内容であることを特徴とする方法データ専用コンテナのimage_dirボリュームにコピーされます。

次に、 secure-data-only containersパラダイムを強調し、それらのボリュームを暗号化できるようにします。

最近、 @ jrslvからの良い記事を読みました。彼は、アプリをビルドするためだけにシークレットを使用して特別なDockerイメージをビルドし、ビルドイメージの実行結果を使用して配布用の別のイメージをビルドすることを提案しています。

したがって、2つのDockerfileがあります。

• Dockerfile.build（ここではすべてのシークレットをコピーするだけです）
• Dockerfile.dist（これはレジストリにプッシュします）

これで、次のようなディストリビューションを構築できます。

# !/bin/sh
docker build -t hello-world-build -f Dockerfile.build .
docker run hello-world-build >build.tar.gz 
docker build -t hello-world -f Dockerfile.dist ^

hello-world-build画像をプッシュすることはないため、秘密は安全です。

詳細については、 @ jrslvの記事を読むことをお勧めしますhttp://resources.codeship.com/ebooks/continuous-integration-continuous-delivery-with-docker

@kepkinを共有していただきありがとうございます！
記事を読み終えたところです。 本当に簡潔です！

ファイルをエクスポートして、別のDockerfileを介してロードするというアイデアが好きです。 「中間レイヤーがビルドキャッシュにある」という問題がなくても、押しつぶされているように感じます。

ただし、開発が複雑になり、簡単にするために3番目のDockerfileが必要になる可能性があることに不安を感じています。

@kepkinは不快ではありませんが、それは意味がありません。 シークレットはtarball内にあり、tarballがプロダクションイメージにADDされているため、間違いなく安全ではありません。tarballを削除しても、押しつぶさずに、いくつかのレイヤーでリークします。

@TomasTomecek例を正しく理解していれば、tarballはイメージレイヤーではなく、ビルドコンテナー内にビルドされたバイナリにすぎません。 たとえば、を参照してください。 https://github.com/docker-library/hello-world/blob/master/update.sh （ここには秘密は含まれていませんが、ビルドコンテナーの簡単な例です）

@TomasTomecekDockerイメージを構築するための秘密について話しています。 たとえば、プライベートGitHubリポジトリからソースコードをチェックアウトするには、sshキーを渡す必要があります。 また、tarballにはビルドアーティファクトのみが含まれていますが、GitHubキーは含まれていません。

@kepkin右、今私はあなたの投稿をもう一度読んでそれを見ることができます。 申し訳ありません。 残念ながら、配布イメージの展開/構築中にシークレットが必要な場合（アーティファクトのフェッチやアーティファクトサービスによる認証など）、問題は解決されません。 しかし、ビルドプロセスとリリースプロセスを分離するための優れたソリューションであることは間違いありません。

@TomasTomecekは、まさに私が実際にアーティファクトをフェッチする方法です。

Docker.buildイメージで、AWSキーとシークレットを必要とするAmazonS3イメージからいくつかのバイナリ依存関係をダウンロードします。 取得して構築した後、必要なものすべてを使用してtarballを作成します。

正規の「ベストプラクティス」の記事（「禁止事項」に記載されている「推奨事項」）はありますか？

DockerComposeがenv_fileオプションをサポートしていることは注目に値します（これに遭遇している私のような人にとっては）。

https://docs.docker.com/compose/compose-file/#env -file

@afeld docker自体にもこの機能があります。http： //docs.docker.com/engine/reference/commandline/run/#set -environment-variables-e-env-env-fileを参照してください。ただし、これらのenv-varは引き続き機能します。同じ場所に表示されるので、「リーク」との違いはありません

私はこのチートシートに出くわしました： http ：

@kepkinこれは、sshキーをdocker buildに渡す方法です。

# serve the ssh private key once over http on a private port.
which ncat
if [ "$?" = "0" ]; then
  ncat -lp 8000 < $HOME/.ssh/id_rsa &
else
  nc -lp 8000 < $HOME/.ssh/id_rsa &
fi
nc_pid=$!
docker build --no-cache -t bob/app .
kill $nc_pid || true

172.17.0.1がDockerゲートウェイIPであるDockerfile内：

RUN \
  mkdir -p /root/.ssh && \
  curl -s http://172.17.0.1:8000 > /root/.ssh/id_rsa && \
  chmod 600 /root/.ssh/id_rsa && chmod 700 /root/.ssh && \
  ssh-keyscan -t rsa,dsa github.com > ~/.ssh/known_hosts && \
  git clone --depth 1 --single-branch --branch prod [email protected]/app.git . && \
  npm i --production && \
  ... && \
  rm -rf /root/.npm /root/.node-gyp /root/.ssh

誰かがもっと簡単なものを持っているなら、私たちに知らせてください。

それで、これの現在の状況は何ですか？

夏の間ずっと長い会話の連鎖があり、この懸念がどれほど広まっているのかを示しています。 これは5月に提出されましたが、まだ開いています。 たとえば、Postgresのパスワードをどのように設定しますか？

@thaJeztahこれを前進させるために何ができるでしょうか？ さまざまな下流プロジェクト全体で多くの目がこの問題に注目していると思います... ej。 https://github.com/rancher/rancher/issues/1269

ここで行われていることは_secret_：Dに保たれていると思います

これは、Dockerを本番スタックに統合する上での最大の問題点です。 これに向けた進捗状況を示すロードマップまたは別のドキュメントがどこかにありますか？

k8sからのこのトピックに関するいくつかの関連コンテンツ。

これを実行時の秘密に対処するための潜在的な方法としてどう思いますか？
https://github.com/docker/docker/issues/19508

この問題は、サポートする必要のあるいくつかのシナリオに集中し、それぞれに一連の指示があることを確認することで最もよく対処できると思います。 それらをどのように実装するかは、プロセスの最後に、ニーズを満たすために組み合わせることができる一貫した機能のセットがあるかどうかよりも重要ではありません。

私が言及しているのを見たいくつかは、かなり正当な懸念であるように思われます：

実行時の資格情報

• linkを共有する2つのコンテナ間で調整されたユーザー/パスワード情報
• 情報をgitリポジトリに入れないようにするのは簡単です
• プッシュされた画像から情報を簡単に除外できます（ローカルコンテナはどうですか？）
• 情報は.bash_historyから簡単に除外できます（おそらくブリッジが遠すぎますか？）
• 一部のアプリケーションは、他の情報を含む構成ファイルの一部としてシークレットを期待します
• 一部のアプリケーションは、環境変数としてシークレットを期待しています
• 一部のアプリケーションでは両方が可能です

私が「簡単」と言うときは、これらの変数を処理するための人間工学的に正しいアプローチがあり、ユーザーが誤って間違ったことをしたり、セキュリティ情報をトリガーしたりするのを防ぎます。 経験のストレスは、間違いに関係するツールに関連する（読む：非難される）ことがよくあります。

ビルド時のクレデンシャル

• プロジェクトは1つ以上のプライベートリポジトリから構築されます（例：package.jsonはgit urlを許可します）
• Builderがパスワードで保護されたプロキシの背後にある可能性があります
• Builderはパスワードで保護されたキャッシュを使用している可能性があります
• エンドユーザーは作業中の画像のみを気にします（つまり、プルまたはFROMを使用し、 docker buildは使用しません）
• プッシュされた画像から情報を簡単に除外できます

最初の編集：

典型的な画像、コンテナに「リーク」されているものとされていないもののドキュメント

• どのファイルが画像に表示されますか（コピーして追加するだけですか？他に何かありますか？）
• イメージが構築された後、どのdocker-machineが保持しますか（特にboot2dockerですが、他のものはどうですか？）
• 環境変数とコマンドライン変数が画像内でどのようにキャプチャされ、どこでキャプチャされるか
• これらの行動の変化に関するPR発行者への期待

ここに大きなものがいくつか欠けているような気がします。 誰かが私が忘れたものを手に入れましたか？

jsonサービスのAPIキー。

たとえば（これは私の実際のユースケースです）、Dockerビルドはプログラムをコンパイルします。APIキーは私を認証し、ビルド製品をBintray.comにアップロードするために必要です。

@ dreamcat4私はあなたが言っていることから

継続的デプロイビルドにDockerイメージを使用し、ビルドが成功したときにビルドアーティファクトをアーカイブにプッシュすることについて話しているのですか？ 個人的には、これをさらに上流で行うことを好みます（たとえば、Jenkinsのビルド後のスクリプト）が、クロスコンパイルする場合は少し注意が必要かもしれません。

私の世界では、ビルドエージェントはバイナリ/アーカイブをビルドし、ビルドプロセスの「アーティファクト」として保持します。他の何かがそれらをインフラストラクチャにプッシュし、gitリポジトリにタグを付けます。これにより、アーティファクトの緊急バックアップが得られます。運用上の問題があり、たとえば、npm、docker、またはArtifactoryリポジトリがアップグレードのためにダウンしているか、ネットワークに問題が発生しています。

私が言いたかったのは、一般的なAPIキーの使用についてでした。 コンテナが（ビルド時または実行時に）対話する必要がある可能性のある、さまざまなオンラインJSON / RESTサービスが多数あります...これにはAPIキーが必要です。 特にビルド関連である必要はありません。

@dreamcatああ、RESTエンドポイントの認証トークン？ これらは、たとえばconfファイルのpostgresパスワードとは大幅に異なる方法で処理されると思いますか、それとも同様に処理しますか？

ええ、これら2つのタイプは、基本的なセキュリティの最小レベルを評価するという観点から、異なる方法で検討する必要があると思います。

API認証トークンは多くの場合次のようになります。

• パスワードではありません
• 取り消すことができます
• 一部（はるかに少ないサブセット）は使い捨てです-捨ててください。 そして本質的に彼ら自身を無効にします。
• 多くの場合、APIサービスは、その範囲が機能のサブセットに限定されています。 （つまり、読み取り専用、または特定のアクションのみをトリガーできます）。

パスワードは次のようになる傾向があります/多くの場合：

• より完全なアカウントアクセス/制御のために。
• 侵害されると、攻撃者によって他の何かに変更される可能性があります（ロックアウト）。 または、挿入された他のバックドア（SQLの場合、データベースに保持されている他のアカウントのデータベース変更など）。
• パスワードであることは、他のアカウントの中でも「同じパスワードの再利用」のリスクをかなり高くします。 Wheras APIキーは常に一意であり、他の目的には使用できない傾向があります。

したがって、これは必ずしも、これら2つのタイプのシークレットソリューションが_異なる必要がある_ことを意味するわけではありません。 許容可能な最小ベースラインレベルのセキュリティは、APIキーの場合は少し低くなる可能性があります。

この最小レベルは、強力なセキュリティを設定することがより複雑で問題がある場合に重要です。 （これは、Dockerシークレットの場合、またはソリューションがどれほど実行可能/エレガントであるかに依存しない場合に当てはまる可能性があります）。

また、パスワードのAPIキーのセキュリティが強化/弱くなる場合があります。 ワンサイズですべてに対応することは不可能です。

たとえば、私のbintray APIキー：Dockerfileと同じ.gitリポジトリに保持されています。 したがって、安全を確保するために、PRIVATE git repo（SSH経由でアクセス）に保持されます。 したがって、アクセス権を取得することは、そこで比較的十分に保護されているAPIキーにアクセスすることです。 ただし、Dockerに独自のシークレット機能/保護機能が組み込まれていない場合、ビルドされたDockerイメージには常にプレーンテキストのAPIキーが含まれます。 したがって、結果のDockerビルドイメージは、gitリポジトリのようにプライベートに保つ必要があります...これには、他の誰もビルドログ/ビルドステータスを公に表示/表示できないノックオン（望ましくない効果）があります。

今ではそれは多くの点で理想的ではありません。 しかし、全体的なソリューションは十分に単純であり、実際に機能します（昨日のように）。 将来、もっと良いメカニズムができたら、それに切り替えることを検討したいと思います。 しかし、そのメカニズムが、私がすでに作成した現在のソリューションよりもセットアップに大幅にコストがかかる/複雑である場合はそうではありません。 したがって、APIキーが1つしかない場合は、非常に強力なセキュリティ（歓迎されます）が過剰になる可能性があります。 これは、ある種の新しいNOCAHCEオプション/ Dockerfileコマンドを使用して、Dockerのイメージレイヤーキャッシュから除外する必要があるだけです。

パスワードには、ボールトやansible-vaultのようなものが必要であり、さらに別のパスワードまたはその他の強力に安全な認証メカニズムで暗号化する必要があります。 （これは希望しませんが、セットアップが複雑になる可能性があります）。

実装が慎重に行われた場合、すべての秘密に関連するものを管理および合理化（読み取り：監査、ブレークグラス）するためのクライアント/サーバーモデル（ボールトのような）は良い習慣であり、ほとんどのユースケースをカバーすると思います。 私は個人的に、非ホリスティックなアプローチを採用するのが好きではありません。これは、ベストプラクティスの水準を引き上げる機会だからです。

これは、長時間実行されているクライアント（イメージをデプロイする人の責任）および/またはビルド時のクライアント（ビルダーの責任）を意味します。 たぶん、前者は、実行時に許可されたシークレットを提供するdockerデーモンに転送される可能性があります。

確かに-私は前のコメントに心から同意します。 人々が問題を解決している創造的な方法を賞賛していないわけではありませんが、これが必要な方法ではないと思います-CI / Dと実行時の両方で使用できるソリューションを考えてみましょう、およびコンテナがMesos / Kubernetesなどによってオーケストレーションされる可能性があることを考慮に入れます。

Dockerは問題の領域にいくつかの余分なねじれを提示するので、ここでも少しのドキュメントが役立つと思います。

Vaultの人たちもこれを最後から見ているようです。 私はこのチケットが注目すべきものだと思います：

https://github.com/hashicorp/vault/issues/165

たぶん、これは共同作業が可能なものです。

@jdmarshall

たぶん、これは共同作業が可能なものです。

+1

+1 Docker + Hashi Corp Vault

申し訳ありませんが、より多くの人が参加するにつれてソリューションが複雑になるのは好きではありません。たとえば、Hashi Corp Vaultは、暗号化されたバックエンドストレージを備えた完全なクライアントサーバーソリューションです。 それはかなり多くの可動部品を追加します。 一部のユースケースではこのレベルの複雑さが要求されると確信していますが、ほとんどの場合、そうなるとは思えません。 競合するソリューションがホスト環境変数を使用することである場合、開発者の大多数によって使用されることになると私はかなり確信しています。

開発（例：githubキー）とデプロイ（例：nginx証明書キー、dbクレデンシャル）をカバーするソリューションを探しています。 env varsやビルドツールでホストを汚染したくありません。もちろん、秘密がgithub（暗号化されていない）やdocker imageディレクトリ（プライベートディレクトリであっても）になってしまうことはありません。

@gittycatおそらくいくつかの異なるユースケースがあるという意味で、私はあなたに同意します。 これにより、一部のソリューションは他のソリューションよりも単純になるはずです。

ただし、ENV変数に頼るのは避けたいと思います。

私自身の好みは、ansibleの「ボールト」メカニズムに似たもので単純なキーストレージを実現できるという考えに傾いています。 暗号化されたテキストファイルがビルドコンテキスト内（またはビルドコンテキストの外部/横にあるソース）に保持されている場合。 次に、ロック解除キーを使用すると、そのファイルからプレーンテキストのパスワードやAPIキーなどをロック解除できます。

私は、anisible独自の「ボールト」ソリューションを使用した後に言っているだけです。 これは比較的痛みがなく/シンプルです。 Hashicorpのボールトはより安全ですが、セットアップも難しく、一般的にはより複雑です。 それでも最終的にバックエンドとして使用できなかった技術的な理由はわかりませんが（Docker指向のコマンドラインツールの背後で非表示/簡略化）。

複雑で信頼性が低い可能性のあるHTTPキーストレージサーバーをセットアップする必要がないため、ローカルファイルストレージをお勧めします。 シークレットストレージはセキュリティ上の問題であるため、企業だけでなくすべてのユーザーが利用できるようにする必要があります。 ちょうど私の2セントの意見。

ローカルファイルストレージバックエンドに+1しますが、より高度なユースケースでは、HashicorpVaultのようなソリューションのフルパワーを好みます。 私たちが展開について話しているとき、組織では、秘密を提供および管理する人は、秘密を使用する人以外の人であるという議論があります。 これは、制御力を持つ人の輪を非常に信頼できるセキュリティエンジニアに限定するための一般的なセキュリティ対策です...

これが何らかの用途であるか、機能するかはわかりませんが、実行時にコンテナーにシークレットを挿入する場合を解決するための、少し左フィールドの提案があります（たとえば、postgresパスワード）。

docker run時点でエントリポイントをオーバーライドし、選択したスクリプト（/ sbin / get_secretsなど）に設定できる場合、選択したメカニズム（KMSなど）からシークレットを取得すると、元のエントリポイントが実行されます。 （したがって、コンテナ内にシークレットを含む環境変数を設定することを唯一の目的とする単なるラッパーになります。このようなスクリプトは、実行時にボリュームマウントを介して提供できます。このようなメカニズムでは、シークレットがディスクに書き込まれることはありません（私のペットの1つが嫌いです）、またはdocker（docker inspectの一部ではありません）によってリークされていますが、コンテナー内のプロセス1の環境内にのみ存在することを保証します。これにより12要素が維持されます。

エントリポイントが画像メタデータで使用されていない場合は、すでにこれを行うことができますが、エントリポイントがコマンドをラップするため、cmdのみが使用されます。 前述のように、ラッパーは実行時にvolmountを介してマウントできます。 エントリポイントがすでに画像メタデータで使用されている場合、元のエントリポイントがコンテナ内から（コマンドラインオーバーライドではなく）確認できない限り、現時点ではこれを達成できないと思います-それができるかどうかはわかりません。

最後に、外部の/ sbin / get_secretsを使用して実際のシークレット（postgresパスワードなど）を要求できる従来のenv varインジェクションを介して、暗号化されたワンタイムキーを提供することも可能だと思います。これにより、Dockerに追加のセーフガードが追加されます。ワンタイムキーの漏洩。

これが単なるレイヤー上のレイヤーなのか、それとも問題を解決できる可能性があるのか​​、私にはわかりません。最初の場合はお詫びします。

@ thaJeztah-上記の解決策が機能することを確認できます。シークレットは

@gtmtech興味深い。 get secretsbinaryから元のエントリポイントが何であるかをどのように見つけたかに興味があります。

たぶん、サンプルコードフォルダは、アプローチをデモンストレーション/理解するのを少し簡単にするでしょう。

サンプルコードと作業シナリオはこちら@ dreamcat4 @kaos >

https://github.com/gtmtechltd/secret-squirrel

私は間違っているかもしれませんが、なぜこれらの複雑な方法ですか？ 私は標準のUNIXファイルのパーミッションに依存しています。 ルートでのみ読み取り可能な-v /etc/secrets/docker1:/etc/secretsを使用してすべてのシークレットをdockerに渡すと、コンテナーの起動時にrootとして実行されるスクリプトがあり、関連するプログラム（apache configなど）の適切な場所にシーク​​レットを渡します。 これらのプログラムは起動時にroot権限を削除するため、ハッキングされた場合、後でrootが所有するシークレットを読み取ることはできません。 私が使用するこの方法はどういうわけか欠陥がありますか？

ありがとう@gtmtech :)
残念ながら、標準のエントリポイントはありません。また、Dockerを制御された方法で実行する前にdockerinspectを実行することもできません。しかし私はあなたのアプローチが好きです。

私は間違っているかもしれませんが、なぜこれらの複雑な方法ですか？ 私は標準のUNIXファイルのパーミッションに依存しています。 ルートによってのみ読み取り可能な-v / etc / secrets / docker1：/ etc / secretsを使用して、すべてのシークレットをdockerに渡します。次に、コンテナーの起動時にrootとして実行されるスクリプトがあり、関連するプログラム（apacheなど）の適切な場所にシーク​​レットを渡します。 config）。 これらのプログラムは起動時にroot権限を削除するため、ハッキングされた場合、後でrootが所有するシークレットを読み取ることはできません。 私が使用するこの方法はどういうわけか欠陥がありますか？

やあ、
私は同意し、このアプローチ^^がランタイムシークレットの最良の方法として一般的に推奨されるべきだと思います。 ここにいる他の誰かがそれに対して強い反対を持っていない限り。 その後、その^^でカバーされていない残りのコーナーケース（実行時）も一覧表示できます。

残念ながら、秘密探偵クルクルが離陸するのを見ることができません。それは、ほとんどの一般的な非技術者が学び、人気のある戦略として採用するには複雑すぎるためです。

それで、それは去ります（あなたはおそらくそれをすでに推測しているでしょう）...
ビルド時の秘密！

しかし、それは進歩だと思います！ 久しぶりにどこにも行かなくなったので、物事を半分に減らして、問題全体の約45〜50％を解決するかもしれません。

そして、秘密の周りにまだ問題が残っている場合、少なくともそれらはより具体的/焦点を絞ったものになり、その後も進行/タックルを続けることができます。

はい、あまり詳しくは説明しませんが、これらのアプローチは、提供されているよりも高いレベルのセキュリティが必要なため、現在作業している状況では機能しません。 たとえば、ディスク上で暗号化されていないシークレット、ターゲットプロセスで復号化された後の有効な復号化キー、定期的な暗号化ローテーション、暗号化されたシークレットの単一リポジトリ（サーバー間で分散されていない）などです。 したがって、そのレベルのセキュリティを実行する必要がある人々にとっては、可能なアプローチを提案しました。

secret_squirrelはとにかく、実行可能な解決策をまだ見ることができないスペースでのハックです。Dockerの周りにはまだシークレットAPIが提供されていないか、プラグイン可能なシークレットドライバーがあります。プロセス実行前のコンテナ内の変数ですが、docker createプロセス（またはメタデータ）の一部としてではなく、シークレットに12ファクター準拠するための安全な方法です。おそらく、Docker開発コミュニティは、ビルドを開始するときにそのアイデアを使用できます。秘密-彼らがそれが良いものだと思うなら、api / driver！

ハッピードッキング！

@gtmtechが説明するようなアプローチを使用しており、大きな成功を収めています。 KMSで暗号化されたシークレットを環境変数を介して挿入し、必要に応じてコンテナ内のコードを復号化します。

通常、これには、アプリケーションの前にある単純なシムエントリポイントが含まれます。 現在、シェルと小さなGolangバイナリ（https://github.com/realestate-com-au/shush）を組み合わせてそのシムを実装していますが、pure-Goアプローチのサウンドが気に入っています。

@ gtmtech @ mdubこれをもっと見て喜んでいることは間違いありません。
@ dreamcat4 「複雑」の定義はパスに依存する可能性があると思いますが、これは明らかに問題ありません。 それでも、それはおそらく抽象化可能な判断にはなり得ません。 したがって、Dockerコンテナー内のセキュリティラッパーは、設計レベルではそれほど複雑に見えません。 もう1つの側面は、ベストプラクティスです。これらは、開発者のみの観点からではなく、運用の観点から検討する必要があります。
私の2セント

Vault +1

Vault-1。 Vaultには、多くの人にとって本当に望ましくない操作上の特性（開封）があります。

プラグ可能なAPIを使用するのが最も理にかなっています。

ansibleのボールトもあります。 それはかなり別の獣です。

@gtmtech提案に感謝し、このエントリポイントを書くように促しました。

#!/bin/bash

if [ -d "/var/secrets" ]; then
  tmpfile="$(mktemp)"
  for file in /var/secrets/*
  do
    if [ -f $file ]; then
      file_contents=$(cat $file)
      filename=$(basename "$file")
      underscored_filename="${filename//-/_}"
      capitalized_filename=${underscored_filename^^}
      echo "export $capitalized_filename=$file_contents" >> $tmpfile
    fi
  done

  source $tmpfile
  rm -f $tmpfile
fi

exec "$@"

このようにDockerfile追加するだけです（ chmod + xを忘れないでください）：

ENTRYPOINT ["/app/docker-entrypoint.sh"]

そして出来上がり。 実行時に利用可能なENV変数。 十分です:)

私が正しく理解していれば、 /var/secretsディレクトリはボリュームを介してマウントする必要がありますか？
また、シークレットがディスクに書き込まれていないというコメントがある場合、ディスクに書き込んでから削除するのはどれほど悪いことですか？

良いですね！ ただし、ファイルを安全に削除するには、 shredを使用する必要があります。

2016年3月3日（木曜日）には、フアン・イグナシオ・Donoso [email protected]
書きました：

私が正しく理解していれば、/ var / secretsディレクトリは
ボリュームは正しいですか？
また、ディスクに書き込まれていない秘密についてのコメントがある場合、どのように
悪いのは、それらをディスクに書き込んでから削除することです???

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

ルイ・マリニョ

@gtmtechの「秘密

ADD shush_linux_amd64 /usr/local/bin/shush
ENTRYPOINT ["/usr/local/bin/shush", "exec", "--"]

これにより、 KMS_ENCRYPTED_xxx不変変数が復号化され、結果が環境に戻されます。

https://github.com/realestate-com-au/shush#use -as-a-command-shim

したがって、スレッドは「これらのことは何もしないでください.....」で始まります。

...しかし、これらのことを代わりに実行してください...ほとんど拒否/クローズされたさまざまな提案/ハックのみが表示されます。

今のところ公式のベストプラクティスは何ですか？ Dockerユーザーとして、私たちがすべきではないことの長いリストを見るのは少しイライラしますが、公式の代替案は提供されていません。 私は何かが足りないのですか？ 存在しませんか？ 舞台裏で物事が起こっていることは確かであり、これはDockerチームが取り組んでいることですが、現時点では、正規の解決策が提示されるまで、秘密の管理をどのように処理するのが最善でしょうか。

@alexkolson
私が理解している限り、実行時にシークレットが必要な場合は、ボリューム（ファイルシステムシークレット）またはHashiCorp Vault（ネットワークシークレット）などのサービスを使用する必要があります。

ビルド時の秘密については、もっと複雑です。
ボリュームはビルド時にサポートされないため、コンテナーを使用してファイルシステムを変更するコマンドを実行し、dockercommitを使用する必要があります。

したがって、不足しているのは、 docker commitを使用せずに、Dockerfile以外を使用せずにビルド時にシークレットを管理する機能です。

シークレットにファイルシステムを使用することは安全ではなく、Dockerデーモンはシークレットを安全に提供するためのAPIを提供する必要があるとさえ言う人もいます（ネットワーク/ファイアウォール/自動マウントボリュームを使用しますか？）。 しかし、このAPIがどのように見えるか、そしてそれをどのように使用するかについては、誰も考えていません。

env varsの欠点について考えるとき、次のようなDocker以外の特定の問題について考えます。

1. 本番Webサーバーに残されたすべてのenv変数または忘れられたphpinfoをキャッチするログを集約するため、シークレットと構成に正しく注意してください。
2. おそらく、env変数を公開するトロイの木馬です。信頼できないソフトウェアを実行しないでください。
3. SQLインジェクションなどの弱点を悪用する攻撃-入力を検証し、Webアプリファイアウォールを使用します。

このスレッドの上部に示されている弱点：

コンテナ内の任意のプロセスからアクセスできるため、簡単に「リーク」されます

上から1と2をクロスアプライします。 合法ですが、注意して対処しましたか？ さらに、Dockerコンテナは、フルスタックWebサーバーよりもはるかに少ないプロセスを実行します。

env varのconfigはどうですか？しかし、secret env varsには暗号化された値があり、アプリにはコードのキーがありますか？ キーはコード内にあるため、これは単なる難読化ですが、キー変数とenv変数の両方にアクセスするにはエクスプロイトが必要になります。 おそらく、構成管理を使用して、アプリコードではなくDockerホストのキーを管理します。 ルージュプロセスや偶発的なリークには役立つ可能性がありますが、キーを持っている人からのインジェクション攻撃には明ら​​かに役立ちません。

画像の中間レイヤーに保存され、Docker検査で表示されます

実行時に設定するのではなく、環境変数をDockerイメージに焼き付けているのですか、それとも私はこれを誤解していますか？ シークレットをアーティファクトに戻すことはありませんか？ はいsudo docker inspect container_nameはenv varを提供しますが、私の本番サーバー上にある場合、ivはすでに失われています。 sudo docker inspect image_nameは、実行時に設定されたenvvarsにアクセスできません。

コンテナにリンクされているコンテナと共有

代わりにリンクと新しいネットワークを使用しないのはどうですか？

Dockerの問題のように見え、普遍的ではない唯一の問題はリンクです...

docker build間に秘密を処理するための良い方法を必要とする人々の陣営に私を入れてください。 一部のphpプロジェクトにはcomposerを使用し、依存関係についてはいくつかのプライベートgithubリポジトリを参照します。 つまり、コンテナ内にすべてを構築する場合は、これらのプライベートリポジトリにアクセスするためにsshキーが必要です。

Dockerについて有益だと思う他のいくつかのことを打ち負かすことなく、この苦境を処理するための適切で賢明な方法を見つけられませんでした（ docker squash ）。

これで、アプリケーションの一部をコンテナーの外に構築し、 COPYを使用して最終製品をコンテナーに取り込むことに回帰する必要がありました。 まあ。

docker buildは、シークレットなどの一時的なデータを処理して、最終的な輸送コンテナに入らないようにするための機能が必要だと思います。

Dockerビルドには、シークレットなどの一時的なデータを処理するための機能が必要だと思います

これは哲学的な問題であり、技術的な問題です。 このような一時的なデータは、Dockerの本質的な利点である再現性を損なうことになります。

Dockerの哲学は、Dockerfileとコンテキストでイメージを構築するのに十分であるということです。
結果のイメージの外部にコンテキストが必要な場合は、ネットワークからそれをフェッチし、ファイルシステムへの書き込みをスキップする必要があります。 すべてのDockerfile行がファイルシステムスナップショットになるためです。

シークレットをイメージの一部にすべきでない場合は、エフェメラルコンテナを実行できます。これにより、シークレットで保護されたすべてのリソースがミラーリング/プロキシされ、シークレットのないアクセスが提供されます。 ミラーリング、ところで、別の理論的根拠があります： https ：

sshキー自体も共有できますが、その使用法を制御することはできません。

@ bhamilton-idexxプライベートリポジトリへの認証が短命のトークンで機能することを確認すれば、Dockerイメージに秘密が保持されていることを心配する必要はありません。
ビルドシステムに1時間のttlでトークンを生成させ、これを環境変数としてDockerビルドで使用できるようにします。
ビルドは必要なビルドの詳細を取得できますが、ビルドが完了した直後にシークレットがタイムアウトし、その攻撃ベクトルが閉じられます。

これらのスレッドの束を今読んでいて、ここでいくつかのユースケースを解決し、秘密の外のユースケースを持つ1つの機能は、ファイルをコンテナにコピーするdocker run --addフラグです。 DockerfilesのADDステートメント

この記事はA +ですhttp://elasticcompute.io/2016/01/21/runtime-secrets-with-docker-containers/

それは確かに素晴らしい記事です。 とてもよく読んだ。 そしてまさに私たちが見たいと思っていたようなものです。

ところで：

また、記事から見逃されているように見える他の秘密のツールがいくつか見つかりました。 繰り返し/重複してすみません。 ここでもまだ言及されていることに気づいていませんでした：

時間の秘密を構築する：

https://github.com/defunctzombie/docket

実行時の秘密：

https://github.com/ehazlett/docker-volume-libsecret

人々はどう思いますか？ どうもありがとう。

私のため：

これらの新しいツール^^は今とてもよく見えます。 そして、私たちがこのチケットを最初に始めたとき、それらは確かに存在していませんでした。 しかし、私が今感じている主なことは、まだ最も欠けているままです：

DockerHubでビルド時のシークレットの機能が向上しています。 どちらが貧弱で、どちらかを選択する必要があります。 一方のソリューションのメリットをもう一方のソリューションのメリットのために放棄する必要があります。 機能の全体的なセットに応じて、より重要になります。 ローカルの建物は秘密を安全に保つために間違いなく優れていますが、他の点ではDockerhubよりも当然悪いです。

新しい画像形式を使用する、docketに似た別のツールを作成しました。

https://github.com/AngryBytes/docker-surgery

この実装では、最初にSECRETSとコメントされたシークレットを含むレイヤーを作成し、次にFROM変更してDockerfileのコピーを作成し、ビルドして、最後にすべてのSECRETSレイヤーを結果のイメージから削除します。

これをハッキングすることには常に注意が必要です。Dockerにリベースまたはレイヤースプライシング機能が組み込まれていると、うねりが発生します。 すべてのソリューションは舞台裏でdocker save / docker loadダンスを行わなければならないため、現在中間レイヤーを削除するのは時間がかかります。

さらに、ビルドキャッシュが壊れています。 現在、コメント付きのシークレットレイヤーを作成するためにdocker commitを使用していますが、これらのレイヤーの適切なキャッシュを維持することは、まだ多くの作業であり、実行する可能性は低いです。 Dockerfileを使用してシークレットレイヤーを作成すると、これを解決できる場合がありますが、レイヤーにコメントを付ける手段がないため、後で何を削除するかを正確に特定することは困難です。

@Vanuan [Dockerfile]は再現性がありません。 RUNコマンドは、2回の実行でまったく同じイメージを取得することをあなたと私が合理的に期待できないことを保証します。 どうして？ ほとんどの場合、人々はRUNを使用してネットワークリソースにアクセスするためです。 私と同じ画像が必要な場合は、独自の画像「FROM」を作成する必要があります。 他の配置では同じ画像が得られません。 他の配置では同じ画像を得ることができません。 すべての永続的な再現性は、DockerfileではなくDockerHubからもたらされます。

エフェメラルデータを取得できない理由の唯一の防御策が、Dockerがエフェメラルデータをすべて削除できると考えているためである場合は、RUN命令を非推奨にする必要があります。

@stephank少し異なるアプローチをとる

そしてそれは、VOLUMEのプロジェクトコードで「ビルドマネージャー」を実行することです。 次に、マネージャーは、マネージャーのボリュームを使用してプロジェクトコードをマウントする、個別のコンテナーで任意の数のビルドツールを実行します。 したがって、ビルドされたアーティファクトやその他の生成されたファイルはマネージャーボリュームに保持され、各ビルドステップのビルドパイプラインに沿って実行されます。 最後に、マネージャーは、生成されたビルド結果を使用して、最終的なプロダクションイメージをビルドできます。 途中で必要なシークレットは、マネージャーやビルドコンテナーで利用できますが、最終的なイメージでは利用できません。 Dockerイメージウィザードは使用されておらず、ビルドキャッシュは期待どおりに機能します。

ビルドパイプラインがどのように見えるかは、ビルド要件を構成するスペックファイルを使用するプロジェクト次第です。

実際のところ、私はこのツールについてかなり誇大宣伝されており、オープンソースとしてリリースできるようになるのを待っています（会社のポリシーガイドラインが採用されるのを待っています）。

@kaos一方では、ストックのDockerツールから逸脱したくありませんでした。 一方で、イメージ構築ツール同士の競争はもっとあるはずだと思います。 面白そうですね！ 😀

@thaJeztah for environment（12-factor）secrets、Inspectによる環境変数のリークを防ぐためにTwistlock（+ Scalock）を介してDockerデーモンをロックダウンしています。 これをより適切な現実にするために、inspectを介して特権情報をそれほど漏らさないDockerネイティブの機能があれば素晴らしいと思います。

@alexkolson X、Y、Zを軽減しない限り、このスレッドの鍵は「DONT DO THIS」だと思います。これは明らかにエンジニアリングのテーマであり、一般的な問題には常に「解決策」があります。 とはいえ、実際の回避策を開始できるように、何をすべきでないのか、なぜそれを行うのかについての教育が重要です。 悪魔は常にデフォルトになっているので、新しいユーザーが何が危険にさらされているかを確実に理解する必要があります。

Dockerの経験があまりないので、皆さんの何人かが私を助けてくれるかもしれません。
HashicorpsVaultを使用して秘密を取得しました。

私が基本的に行ったことは、ビルド引数としてトークンを渡すことでした。トークンを使用して、Vaultから機密情報をフェッチできます。 これはビルド時に発生し、Vaultが「封印解除」（データのフェッチ用に開いている）状態の場合にのみ成功します。 使用済みトークンを作成すると、取り消されます。

しかし、私はまだいくつかの一般的な問題に直面していると思います。

• 機密データが変更された場合は、新しい画像を作成する必要があります
• 画像が盗まれたりハッキングされたりした場合、機密データは画像内にあります。

docker inspectで使用済みトークンを見つけることは可能ですが、使用できなくなりました。
シークレットストアでのアクセスを可能な限り制限するために、ビルド時にのみhashicorpsボールトを封印および開封することを選択しました。 また、実行時にデータをフェッチするときにシークレットを保存しておくオプションもありませんでした。

それで、私はそれをどれほどひどくしましたか（私が大きな時間を台無しにしたかどうかを言っても大丈夫です;））誰かが私が物事をより安全にするためのヒントとコツを持っていますか？

@weemenAFAIKで画像に秘密を保存することもお勧めできません。 イメージには、クレデンシャル（Vaultトークンを含む）が組み込まれていない必要があります。 代わりに、コンテナにVaultのapp-id authバックエンドを使用して、読み込み時にシークレットを取得します。 使用しているアプリスタックに応じて、何らかの方法でコンテナのメモリに保存します。

また、Vaultはaws authバックエンドに取り組んでおり、AWSをクラウドプロバイダーとして使用している場合に将来的に役立ちます。

@ jaredm4このステートメントを明確にしていただけますか？：

「代わりに、コンテナにVaultのapp-id authバックエンドを使用して、読み込み時にシークレットを取得します。使用しているアプリスタックに応じて、何らかの方法でコンテナのメモリにシークレットを保存します。」

Vault（またはKeywhizなど）からシークレットをいつ/どこで取得するかはまだわかりません。 これは、Dockerが実行され、実行コマンドに渡される前に実行されますか？ これは、コンテナの初期化中のある時点で発生していますか（ある場合は、例があります）？ アプリケーションは必要なときにこれらを取得する必要がありますか？ たとえば、私のRailsアプリにはGoogle APIキーが必要ですが、キーが必要なときにボールトを呼び出すためにRails内に何かを記述しますか？

Vaultのようなものを使用する必要性と、それを構成する方法については明確だと思います。サービスを利用し、railsの起動時にymlファイルを更新して準備する方法については明確ではありません。

ここでのガイダンスをいただければ幸いです。 ありがとう

確かに@mcmatthewですが、私はまだVaultをマスターしようとしているので、私の経験はかなり軽いと言って前置きする必要があります。

私がコーディングしようとしてきた方法は、コンテナに渡す情報は、コードがVaultで認証できるようにするために必要な情報だけであるということです。 app-idバックエンドを使用している場合、それはapp-id自体であり、Vaultのアドレスになります。

コンテナの起動時に、Railsアプリはまだシークレットを持っていないことに気付き、Vaultからシークレットをフェッチする必要があります。 app-idが提供されており、何らかの方法でuser-id生成する必要があります。 このユーザーIDの生成はユーザーが決定する必要がありますが、ドキュメントには、「通常、MACアドレスやインスタンスIDなどのマシンに固有の値、またはこれらの一意の値からハッシュされた値」と記載されています。

Railsアプリでapp-idとuser-idの準備ができたら、VaultのAPIを使用して/ loginできます。 そこから、API呼び出しを行って、必要なシークレットを取得できます。

ここで、メモリに保存することの意味を明確にします。これは、使用しているアプリの種類によって異なりますが、Railsを使用すると、Railsがアクセスできるようにするユーザーランド変数キャッシュにシークレットを保存する方法が必要です。 Vaultから何度も取得するのではなく、すべてのリクエストをメモリから秘密にします（想像できるように遅いでしょう）。 Railsでのキャッシュに関するこのガイドをご覧ください。 つまり、セクション2.0ですが、ディスクではなくmemory_cacheを使用していることを確認してください。

最後に、どのようにコーディングする場合でも、特別なDockerエントリポイントスクリプトなどを使用せずに、Railsでコーディングするようにしてください。 Railsはメモリ内のシークレットを検出し、存在しない場合はそれらをフェッチする必要があります。

それがお役に立てば幸いです。 少し高いレベルですが、これが私たちがそれに取り組むことを計画した方法です。

明確でないのは、何を秘密にしておくべきか、app-id、user-id、またはその両方です。

わかりました。答えは両方ともhttps://www.vaultproject.io/docs/auth/app-id.htmlです。
しかし、それが単なるファイアウォールアクセスよりも安全である理由はまだ明らかではありません。
多分それは各ホストシークレットがアプリケーション（ポリシー）シークレットと結び付けられるべきであるということですか？
つまり、ホストのシークレットにアクセスできる場合、そのシークレット名を知っていれば、特定のアプリケーションにアクセスできますか？

ここで、2つのトークンをどこかに保存する必要がありますか？

@Vanuan両方とも、可能な限り秘密にしておく必要があります。

app-idの主な目的は、ポリシーを介してVault内の特定のシークレットへのアクセスを制限することです。 app-idにアクセスできる人は誰でも、そのapp-idのポリシーのシークレットにアクセスできます。 app-idは、デプロイメント戦略によって提供される必要があります。 たとえば、Chefを使用している場合は、パラメータバッグ（またはOpsWorksの場合はCustomJSON）に設定できます。 ただし、それ自体では、誰もがVaultにアクセスすることはできません。 そのため、Chefにアクセスした人は、Vaultにアクセスできなくなります。

ユーザーIDはChefから提供されたものではないため、特定のマシンに関連付ける必要があります。 アプリがインスタンス間で冗長にスケーリングされる場合、各インスタンスには独自のユーザーIDが必要です。 このユーザーIDがどこから来たのかは実際には問題ではありませんが（提案はありますが）、アプリIDをデプロイしたのと同じ場所（つまり、Chef）から来たものであってはなりません。 彼らが言ったように、それは他の方法でスクリプト化することができます。 インスタンスのスケーリングに使用するソフトウェアが何であれ、ユーザーIDをインスタンス/ Dockerコンテナーに提供し、ユーザーIDをアプリIDに承認することができます。 インスタンスを動的にスケーリングしない場合は、手動で行うこともできます。 人間が新しいインスタンスを追加するたびに、新しいユーザーIDを作成し、それをapp-idに承認し、最適な方法でインスタンスに提供します。

これはファイアウォールインスタンスよりも優れていますか？ 状況によると思います。 ファイアウォールはVault（afaik）のシークレットへのアクセスを制限しません。誰かがあなたのインスタンスにアクセスした場合、その人はあなたのVaultに簡単に侵入する可能性があります。

このように、彼らがパズルのすべてのピースを手に入れるのは難しいです。 さらに一歩進めるために、app-idでは、使用する必要のあるCIDRブロックも使用できます。 誰かが何らかの方法でapp-idとuser-idを取得した場合でも、そのネットワークに接続していなければVaultにアクセスできませんでした。

（繰り返しますが、これは私ができる限りドキュメントを調べた後の私の解釈です）

@Vanuan @mcmatthewすばらしい質問です！ @ jaredm4この説明に本当に感謝します、これは確かに私を助けます。 これは、より実用的な実装を探しているすべての人にとって非常に便利です!! 今後2週間の時間があれば、もう一度やり直します。

@thaJeztah ：

コンテナ内の任意のプロセスからアクセスできるため、簡単に「リーク」されます

この主張を支持できますか？ 非特権プロセスは、非親プロセスの環境変数にアクセスできません。 https://help.ubuntu.com/community/EnvironmentVariables#Process_localityを参照して

コンテナに設定された環境変数（ --envまたは--env-file介して）は、コンテナ内の任意のプロセスからアクセスできます。

もちろん、彼らはエントリーポイントプロセスの子なので。 シークレット環境変数の設定をできるだけ早く解除するのは、そのプロセス、またはシェルなどの場合はあなたの仕事です。

さらに重要なのは、0以外の異なるユーザーIDを持つプロセスが、コンテナーの内部および/または外部でこれらの環境変数にアクセスできるかどうかです。 コンテナ内で使用するソフトウェアが適切に特権を削除する場合も、これは当てはまりません。

話題から外れていることは知っていますが、この問題がほぼ1年間続いていることに気付いた人はいますか？ 明日はその記念日です。 👏

コンテナプロセスがプロセスメモリ内の環境変数を読み取り、（環境内で）それらの設定を解除することは可能でしょうか？ これにより、実行時のセキュリティに関する懸念のほとんどが修正されますか？

@davibeの問題は、コンテナまたはそのプロセスが再起動すると、それらのenv変数が失われ、それらを回復する方法がないことです。

試しましたが、再起動後もenv変数が残っているようです。

dade<strong i="6">@choo</strong>:~/work/grocerest(master)$ cat test.js
console.log("FOO value: " + process.env.FOO);
delete(process.env.FOO);
console.log("FOO value after delete: " + process.env.FOO);

dade<strong i="7">@choo</strong>:~/work/grocerest(master)$ docker run --name test -it -e FOO=BAR -v $(pwd):/data/ node node /data/test.js
FOO value: BAR
FOO value after delete: undefined

dade<strong i="8">@choo</strong>:~/work/grocerest(master)$ docker restart test
test

dade<strong i="9">@choo</strong>:~/work/grocerest(master)$ docker logs test
FOO value: BAR
FOO value after delete: undefined
FOO value: BAR
FOO value after delete: undefined

たぶんdocker-runはbashの子として私のことを実行していますか？ すべきではないと思います。

@davibe ：

unset 'SECRET_ENV_VAR'

このすべての主な問題/機能は、Dockerにrootとしてログインすることです。したがって、トークン、ボリューム、変数、暗号化キーなど、コンテナー内に配置したものはすべて検査できます。 .. なんでも。

したがって、1つのアイデアは、コンテナからsudoとsuを削除し、 ENTRYPOINTまたはCMD前にUSERコマンドを追加することです。 コンテナを実行している人は誰でもrootとして実行する機会がないはずです（私が間違っていなければ）。したがって、実際に彼から何かを隠すことができます。

別のアイデア（最良のIMHO）は、ユーザーとグループの概念をDockerソケットとコンテナーに追加して、GROUP-AがTAG-Bのコンテナーにアクセスでき、USER-CがGROUP-に属していることを示すことです。そのため、それらのコンテナにアクセスできます。 操作ごとの権限である場合もあります（GROUP-AはTAG-Bの開始/停止にアクセスでき、GROUP-Bはexecにアクセスでき、GROUP-Cはrm / inspectにアクセスできます）。

これを数時間調査した後、ビルド時のシークレットに対して公式に推奨される解決策や回避策がないように思われるとは信じられません。https：//github.com/dockito/vaultのようなものが唯一の実行可能なオプションのようです。ビルド時の秘密（結果のイメージ全体を押しつぶしたり、最初に手動でビルドしたりすることはできません）。 残念ながら、 https：//github.com/dockito/vaultはsshキーに非常に固有であるため、githttpsクレデンシャルストアファイルをホストするためにもそれを適応させようとしています...

永遠のように思えた後（当初は2015年第4四半期のリリースが予定されていたと聞きました）、AWSECSはついにIAMの役割をDockerアプリにもたらすという約束をブログ投稿です。

このようなKMSの良さと組み合わせることは、実行可能な短期的な解決策のようです。 理論的には、特定のプリンシパル/ IAMロールにシークレットをバインドして、非認証ロールがすべきでないことを要求しないようにし、安全なストレージをKMSに任せる必要があります。

まだ試していませんが、私の短いリストにあります...

Kubernetesには、多くのChef暗号化データバッグを思い出させる秘密の処理もあるようです。

これは、このスレッドの要点であるプラットフォームに依存しないOSSの方法ではないことを理解しています。
しかし、何かを必要としているインフラストラクチャスペースで遊んでいる人々のために、これら2つのオプションを公開したかったのです。

私はこの点で役立つかもしれない何かに出くわしました： https ：

これはdockerv1.10.0から利用できるように見えますが、今まで気づいていませんでした。 この時点で私が傾倒している解決策は、 https：//www.vaultproject.io/を使用してシークレットを保存および取得し、/ secretsまたはその性質のものにマウントされたtmpfsファイルシステムのコンテナー内に保存することだと思います。 。 コンテナでIAMロールを有効にする新しいECS機能により、VaultのAWS EC2認証を使用して、シークレット自体への承認を保護できるはずです。 （プラットフォームに依存しない場合は、アプリID認証を使用する傾向があるかもしれません。）

いずれにせよ、私にとって欠けていたのは、秘密が取得されたら安全に置く場所でした。 tmpfsオプションは私には良いオプションのようです。 唯一欠けているのは、ECSがまだこのパラメーターをサポートしていないように見えることです。そのため、今日これを送信しました： https ：

全体として、それはかなり包括的な解決策のように思えます。

@CameronGo 、ポインタをありがとう。 私が正しく理解していれば、これはビルドでうまく使用することはできませんか、それともできますか？

@NikolausDemmel申し訳ありませんが、あなたは正しいです。 これは実行時の秘密の解決策にすぎず、ビルド時間ではありません。 私たちの環境では、ビルドタイムシークレットはGitからコードを取得するためにのみ使用されます。 Jenkinsがこれを処理し、Gitアクセスのクレデンシャルを保存します。 同じソリューションがここにいるすべての人のニーズに対応しているかどうかはわかりませんが、ビルドタイムシークレットの他のユースケースについてはわかりません。

Jenkinsがこれを処理し、Gitアクセスのクレデンシャルを保存します。

それはdockerでどのように機能しますか？ または、コンテナ自体の内部にgit cloneしませんか？

この問題を完全に読んだ後、要件が大きく異なる「ビルド時」と「実行時」のシークレットについて別々の問題に分割することで、大きなメリットが得られると思います。

あなたが私のようで、あなたが今何をすべきかを決めようとしてここに来るなら、FWIW私が決めた解決策を、何か良いことが起こるまで説明します。

ランタイムシークレットについては、 http：//kubernetes.io/docs/user-guide/secrets/を使用することにしました

ビルド時の秘密について-プライベートコードを配布する以外に、他のビルド時の秘密のユースケースは考えられません。 この時点で、ホスト側で「秘密」の何かを実行し、生成されたpackage / jar / Wheel / repo / etcを追加するよりも良い解決策はありません。 画像に。 一部のコメントで示唆されているように、ホスト側でパッケージを生成する1つのLOCを保存することは、sshキーの公開やプロキシサーバーの実行の複雑さを危険にさらす価値はありません。

たぶん、docker runフラグと同様に、dockerビルドに「-v」フラグを追加するとうまくいくでしょうか？ ホストとイメージの間で一時的にディレクトリを共有しますが、キャッシュまたは生成されたイメージで空に見えることも確認します。

私は現在、 Vaultを使用したソリューションに取り組んでいます：

1. BuilderマシンにはVaultがインストールされており、トークンがローカルに保存されています
2. ビルドが開始されると、ビルダーマシンは、数分間のみ有効な新しい一時トークンを要求します（ビルドに基づいて、1時間でも許容されます）
3. トークンをビルド引数として挿入します
4. DockerイメージにはVaultもインストールされており（またはビルド中にインストールおよび削除され）、このトークンを使用して実際のシークレットをフェッチできます

同じコマンド内でシークレットを削除することが重要です。そのため、dockerが特定のレイヤーをキャッシュするときに、残りがなくなります。 （もちろん、これはビルドタイムシークレットにのみ適用されます）

これはまだ作成していませんが、作業中です。

@kozikowのコメントにいくらか関連してい

特にビルド時の秘密ではないかもしれませんが、RUN curlコマンドを介してビルド済みのアーティファクトをダウンロードできるようにするために、Dockerfileでビルド時にパスワードを（保護する）ユースケースが必要です。 ビルド時のダウンロードでは、アーティファクトを取得するために認証するユーザー資格情報が必要です。そのため、現在、Dockerfileで環境変数としてパスワードを渡します（まだ開発中です）。 OpenShiftを使用しているため、ビルドはバックグラウンドで自動的に行われ、Dockerfileの環境変数は、他のdocker buildコマンドと同様に、ビルド中にログに出力されます。 これにより、開発者を含め、ログにアクセスできるすべての人にパスワードが表示されます。 Dockerのビルド中に使用できるようにパスワードを送信する方法を必死に考えていますが、パスワードがログに出力されないか、どのレイヤーにも存在しなくなります。

また、 @ wpalmerがこのスレッドを実行時とビルド時に分割することについて言ったことを、2番目に

誰かが思いついた（実行時の）秘密のメカニズムについて、いくつかのテストを定義することは価値があると思います。 このスレッドには、非常に弱いセキュリティを提唱している人がたくさんいるからです。

まず、私は次のことを提案します。

• 秘密はdockerinspectに表示されません
• プロセス1が開始された後、コンテナーからアクセス可能なファイル（ボリュームにマウントされたファイルを含む）内でシークレットを使用することはできません。
• シークレットは/ proc / 1 / cmdlineでは利用できません
• シークレットは暗号化された形式でコンテナに送信されます

これらのいずれかに違反する上記の解決策には問題があります。

シークレットが従うべき動作の定義に同意できれば、少なくともそれは目的に合わない無限の解決策を取り除くでしょう。

@gtmtech素晴らしい提案:)

プロセス1が開始された後、コンテナーからアクセス可能なファイル（ボリュームにマウントされたファイルを含む）内でシークレットを使用することはできません。

私はこれに同意するかどうかわかりません。 コンテナから（理想的にはメモリ内で）アクセスする必要があることに同意しますが、アプリケーションが「起動」するのに時間がかかり、その下からファイルが削除されない場合がいくつかあります。 コンテナの実行中（停止時に削除される）のメモリ内の何かは、もう少し良いアプローチだと思います。

実行時要件のリストに追加します。

• 最初のシークレットをブートストラップするときのコンテナ認証/承認。

たとえば、VaultはAppRoleバックエンドで承認を提供しますが、コンテナが自分自身を識別する方法に関してはません。

Nick Sullivanは、数週間前にClouflareのPALプロジェクトについて

アプリケーションの観点から、これに対処する方法は3つあります。

1. 環境変数からシークレットを取得します。
2. ファイルから秘密を取得します。
3. 別のシステムから秘密を取得します。

上記の1と＃2は、ほとんどのアプリケーションがこのメカニズムをサポートしているため、一般的に最も一般的です。 ＃3は「クラム」が最も少ないため、おそらくより理想的ですが、アプリケーションはこのために特別に開発する必要があり、多くの場合、秘密を取得するための資格情報が必要です。

Dockerは、汎用性とさまざまなユースケースのサポートがすべてです。 これに基づいて、1。と2.は、どちらもシステムに「クラム」を残しているという事実にもかかわらず、アプリケーションの観点から最も魅力的です。

私が確かに使用する一般的なアプローチの1つは、エントリポイントスクリプトを介してシークレットを挿入することです（たとえば、AWSでcredstashやプレーンKMSなどのツールを使用し、IAMロールと組み合わせる）。 この点で、実際にはエントリポイントスクリプトで上記の＃3を実行し、＃1（環境変数を設定）または＃2（ファイルへの書き込み）を実行します。 このアプローチは動的であり、＃1（環境変数）の場合、DockerログまたはDocker検査で資格情報を公開しません。

エントリポイントアプローチの良いところは、シークレット管理の懸念をアプリケーションから分離していることです。

これは、Dockerが独自のエントリポイントスクリプトをロールする必要がないように機能を追加できる領域です。 Dockerはプラグインが大好きで、コンテナーのライフサイクルへのフックを提供し、「シークレット」プロバイダープラグインをサポートできます。このプラグインは、基本的に手動のエントリポイントスクリプトの機能を実行し、（内部環境変数またはファイルを介して）コンテナーにシークレットを挿入します。 したがって、Hashicorp Vaultシークレットプロバイダー、AWS KMSシークレットプロバイダーなどを使用できます。Dockerは、RSA暗号化（デジタル証明書を介して）を使用した独自のプロバイダーを使用できます。 この全体の概念は、コンテナファイルシステムにシークレットを表示するKubernetesのシークレットの概念と大まかに似ています。

もちろん、シークレットプロバイダーへのアクセスをどのように承認するかは複雑です。これは、今日直面している問題です。 Hashicorpを使用すると、認証用に1回限り/時間制限のあるトークンを発行して渡すことができます。AWSでは、IAMロールであり、前述のDocker RSA暗号化アプローチでは、DockerEngine公開証明書を使用して暗号化されたシークレットを渡すだけです。

このスレッドは素晴らしいです。 このようなスレッドが増えて、コミュニティの人々やあらゆる分野の人々が自分の経験、考え、解決策を共有できるようになることを願っています。

「シークレットゼロ」の問題は注意が必要です。 ビルド時または実行時？ どちらにも長所と短所があり、明らかなセキュリティ対策と欠陥があります（そしてハッキングと回避策があります！）。

そうは言っても、私はパス/キーの管理がアプリケーションやサービスにどのように影響するかについて多くのことを考えてきました。

今後数か月で取り組む予定のことは、キーと値のペアを介して共有のグローバル構成バッキングサービスを構築し、Consulによって配布され、環境変数として利用できるようにすることです（または、環境変数の使用がサポートされていない場合は注入されます）。 これは、安全でない値のみをサポートします。 安全のために、Vaultに移行し、データベースやその他の依存関係のように、バッキングサービスのように扱います。

コード、構成、およびシークレットは、バッキングサービスを介して提供されます。 この場合、Stash、Consul、Vaultを使用します。 依存関係がアップしている限り、必要に応じて構成とシークレットをプルする機能もアップします。

私はこれを固溶体としてどこにも見たことがないので、ここに投稿します。 ただし、このスレッドの目的に戻すために、Docker /シークレットの問題を回避するために実験するアプローチの1つです。 実行するフレームワークやプラットフォームに依存するのではなく、これをネイティブにサポートするアプリケーションを構築します。

ビルド時のシークレットに関して、 RockerのMOUNTディレクティブは、ビルド時に_only_存在する一時的なディレクトリとファイルを作成するのに役立つことが証明されています。 それらのテンプレート機能のいくつかもこの状況で役立つかもしれませんが、私はまだそれらを完全に使用していません。

この機能がDockerコアのBuilderプラグインとして実装されることを望んでいます（およびRockerfilesが持つ他の便利な機能のいくつか）！

現在OPにある4つの提案はすべて、シークレットストレージに関するものだと思い

Dockerはシークレット/パスワードを_dockerインスタンス_に渡すのを容易にする必要があると思いますが、これらのシークレットの保存/管理はdockerの範囲外です（そしてそうあるべきです）。

_秘密を渡す_とき、これが通常ログに記録されることを除いて、実行パラメーターはほぼ完璧だと思います。 だから私はこれを非平文パラメータ機能に絞り込み

_シークレットの管理方法_については、自作のbashスクリプトから、 Kubernetesなどのソフトウェアによる統合まで、ユーザーが望むことは何でも言えます。

@ agilgur5が先に述べたように、ロッカーマウントのようにMOUNTを実装するだけの何が問題になっていますか？ この非常に簡単なユースケースを満たすために、チームがdocker buildコマンドを効果的にフォークしなければならなかったほど、この議論が長く続いたとは信じられません。 ミックスに別のHTTPサーバーが必要ですか？ 接吻。

私はこのサブジェットの周りでとても多くの時間を過ごしました...

今のところ、ビルドフェーズでシークレットを管理するために私が見つけた最善の方法は、2つのステップ内でビルドすることです。つまり、2つのDockerファイルです。 ここに良い例があります。

[Habitus]（http://www.habitus.io/）は別のオプションのようですが、私の場合、主にCIサーバーとユーザーのコンピューターでビルドプロセスを維持したいという理由で、別のツールを追加したくありません。シンプル/同じ。

そして、docker-in-docker（dind）の方法はどうですか？

ここでは、上記で説明したようにdindを使用してビルドする2つのステップの例を示します： https ：

コメントしてください...

面白い。 OpenShiftがどのようにビルドするかを思い出させてくれます。

コマンドラインでパスワードを渡しているように見えます。 それを回避する方法はありますか？

ここには、ビルド時のシークレットに関する進行中のPRがあることに注意してください。 https://github.com/docker/docker/pull/28079 （サービスのランタイムシークレットはdocker 1.13にあります。https：//github.com/docker/docker/pull/27794を参照してください）

@thaJeztah ：
＃28079について、過去2年間にこのテーマに関する多くのPRが失敗したのを見たとき、私は少し悲観的です...
依存関係として群れを持ちたくありません。 私の顧客の一部は、別のクラスターオーケストレーターを使用しています。

@cassiussa ：
どういう意味かわかりませんか？
1 /パスワードは最終的なイメージではない「コンテナビルダー」に渡されました。 このビルダーは、Dockerビルドを実行し、Dockerfile.realeaseに基づいてイメージを生成します。 この最終的な画像の履歴に保存されている秘密はありません。
2 /パスワードをコマンドラインに渡したくない場合は、docker-compose（例）を自由に使用してください

@BenoitNorrin将来的には非群れに拡大されるかもしれないと思いますが、 @ diogomonicaはそれについてもっと知っているかもしれません

それのように聞こえます：

バッキングストアはSwarmであり、Linux専用であるため、これは現在Swarmモード専用です。 これは、Windowsサポート、さまざまなバッキングストアなどの潜在的な改善を伴う、Dockerでの将来のシークレットサポートの基盤です。

それがロッカーと同じように実装されていれば素晴らしいでしょう、
シンプルで、「エンタープライズ」である必要はありません。

2016年11月29日火曜日、15：53 Michael Warkentin、 notifications @ github.com
書きました：

それのように聞こえます：

これは現在、バッキングストアがSwarmであり、
これはLinux専用です。 これは、将来の秘密のサポートの基盤です
Windowsサポートなどの潜在的な改善を伴うDocker、異なる
バッキングストアなど

—
コメントしたのでこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/docker/docker/issues/13490#issuecomment-263608915 、
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/AAZk5vlLwsBHHTTbUS_vvx-qTuwnkp6Oks5rDEpjgaJpZM4Eq021
。

解決策は、 docker-composeファイルから渡された情報の一部を暗号化することだと思います。

たとえば、 docker inspectを実行すると、暗号化された情報が_encrypted_として表示/マークされます。 次に、 docker inspect --encryption-key some_key_fileは、暗号化されていないすべての暗号化された情報を表示します。

一方、コンテナ内では、アプリは、使用するためにこの暗号化された情報にアクセスして復号化するためのさまざまなメカニズムを実装できる必要があります。

暗号化は_鍵だと思います_ :)

目的は、私の（本当に、本当に、本当に一般的な）ユースケースを構築することです
認証を必要とするgitサーバーからのソフトウェアプロジェクト
プロジェクトとその依存関係。 ロッカーはマウントを許可することでそれを釘付けにしました
ビルド中のファイルまたはディレクトリ（この場合はSSHエージェントソケット）

2017年1月3日火曜日、04：14 Hisa、 notifications @ github.comは次のように書いています。

解決策は、渡された情報の一部を暗号化することだと思います
docker-composeファイルから。

たとえば、docker inspectを実行すると、暗号化された情報は次のようになります。
暗号化されたものとして表示/マークさ
some_key_fileは、暗号化されていないすべての暗号化された情報を表示します。

一方、コンテナ内ではアプリが実装できる必要があります
この暗号化された情報にアクセスして復号化し、使用するためのさまざまなメカニズム。

暗号化が鍵だと思い

—
コメントしたのでこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/docker/docker/issues/13490#issuecomment-270049742 、
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/AAZk5qEphZo5SR9vOWVL5dck50EPadpVks5rOcsUgaJpZM4Eq021
。

言及されていないので、AWS ECSでのシークレットの処理に関する別の良い記事があります： //aws.amazon.com/blogs/security/how-to-manage-secrets-for-amazon-ec2-container- service-based-applications-by-using-amazon-s3-and-docker /

Docker1.13に新しい「dockersecret」コマンドがあります。 この問題は、その機能のドキュメントがここで説明するユースケースに適している場合に解決できるはずです。

docker secretコマンドは、現在Docker Swarm（つまり、docker services）にのみ適用されるように見えるため、現在、汎用Dockerコンテナーには実行できません。

また、 docker secretは実行時シークレットのみを管理し、ビルド時シークレットは管理しません。

わお。 製品管理チームの誰もこれまで考えたことのないようなものです
認証されていないオープンソースソフトウェア以外のものが取得されるユースケース
Dockerコンテナ、またはGolang以外の言語で構築されています。
依存関係はコピーされて貼り付けられます。申し訳ありませんが、「バージョン管理」されてGitリポジトリに保存されます。

人々がどれほど信じられないほど鈍感になるのか理解できません。 それだけ
私が考えることができる説明は、製品管理チームはそうではないということです
開業医と製品を使用したことがありません。 私はよくこれを見ます
組織が基づいて雇用するときに特徴が現れる
jira /アジャイルスキル。

私は2019年まで、または誰かがその時意味を見るときはいつでもロッカーを使い続けます。

2017年1月22日、23：47 Shane StClair、 notifications @ github.comは次のように書いています。

また、Dockerシークレットは実行時シークレットのみを管理し、ビルド時シークレットは管理しません。

—
コメントしたのでこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/docker/docker/issues/13490#issuecomment-274370450 、
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/AAZk5vJVJe4OeypWd1Cwqmh8Gzyn8P-mks5rU-qqgaJpZM4Eq021
。

私はその最後のコメントを取り戻します、ごめんなさい、私はベントしています。 ただそれを欲求不満
単純なエッジケースは、しばしば何かを押し付ける機会のように見えます
領事のように、または単にではなく、本当に過剰に設計されたものを作成する
ビルド時のマウントと同じくらい簡単なものを実装します。

2017年1月23日月曜日、 09 ： admin @ binarytemple.co.ukは次のように書いています。

わお。 製品管理チームの誰もこれまで考えたことのないようなものです
認証されていないオープンソースソフトウェア以外のものが取得されるユースケース
Dockerコンテナ、またはGolang以外の言語で構築されています。
依存関係はコピーされて貼り付けられます。申し訳ありませんが、「バージョン管理」されてGitリポジトリに保存されます。

人々がどれほど信じられないほど鈍感になるのか理解できません。 それだけ
私が考えることができる説明は、製品管理チームはそうではないということです
開業医と製品を使用したことがありません。 私はよくこれを見ます
組織が基づいて雇用するときに特徴が現れる
jira /アジャイルスキル。

2019年まで、または誰かが意味を理解するたびにロッカーを使い続けます
それから。

2017年1月22日、23：47 Shane StClair、 notifications @ github.com
書きました：

また、Dockerシークレットは実行時シークレットのみを管理し、ビルド時シークレットは管理しません。

—
コメントしたのでこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/docker/docker/issues/13490#issuecomment-274370450 、
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/AAZk5vJVJe4OeypWd1Cwqmh8Gzyn8P-mks5rU-qqgaJpZM4Eq021
。

@binarytemple誰もが今、すべての機能を望んでいます。 準備ができていない場合は、準備ができていません。 新機能の範囲を制限することは間違いなく悪いことではありません。範囲が制限されていても、常に改善の余地があるからです。

誰かが機能を取り入れることに本当に夢中になっている場合は、そのための作業にどのように貢献できるかについて、メンテナに相談する必要があります。

secretコマンドがユーザーの群れを助けるだけであるという点で@mixjaと同じことは、より一般的な解決策ではないと思いました（永続ボリュームをアタッチする場合のように）。 シークレットをどのように管理するか（シークレットとは何か、誰がシークレットにアクセスできるか）はシステムに大きく依存し、「プラットフォーム」を作成するためにどのビットの有料またはOSSを組み合わせるかによって異なります。 Dockerがプラットフォームの提供に移行しているので、HashicorpがVaultをAtlasに統合しているのと同じように、最初の実装がスウォームベースであることは驚きではありません。それは理にかなっています。

実際、秘密がどのように渡されるかは、 docker runスペースの外にあります。 AWSは、パーミッションとSDKを付与/拒否するロールとポリシーを使用してこの種のことを行います。 Chefは、暗号化されたデータバッグと暗号化された「ブートストラップ」を使用して認証を行います。 K8Sには、 1.13でリリースされたばかりの

これらの実装は2つの陣営に分類されるようです。
1）「プラットフォーム」が提供するボリュームマウントまたは（chef / docker secret / k8s）を介してシークレットを渡します
2）クレデンシャルを渡して外部サービスと通信し、起動時に取得します（iam / credstash / etc）

私は2番目のオプションの線に沿ってもっと何かを見たいと思っていたと思います。 最初のオプションでは、関心の分離が十分ではないと思います（起動を行うことですべてのキーにアクセスできます）が、これは好みであり、システム構築の他のすべてと同様に、誰もがそれを異なる方法で行うのが好きです。

この最初のステップがdockerによって行われたことをお勧めします。また、 docker runより一般的なメカニズムが（キャンプ＃2をサポートするために）これから出てくることを願っています。最初の任務は達成されており、まだ閉じるべきではありません。

お気に入り！
本当にシンプルでありながら非常に効果的なデザイン

@ bacoboy 、 @ mixja-単一ノードの群れと単一コンテナサービスはそれほど悪くありません
docker swarm init、docker service create Replica = 1

私にとって、DockerSwarmが今後コンテナ/サービスを実行するためのデフォルトになることは論理的です。

この新しい群れベースの提案は実行時の秘密に

ビルド時の秘密は重要であり、私が知る限り、この提案はそれらに対処していません。

ビルド時のシークレットを挿入するために、 docker build --squashを使用して次のことを安全に行うことができます。

COPY ssh_private_key_rsa /root/.ssh/id_rsa
RUN git pull ...
RUN rm -rf /root/.ssh/id_rsa

--squashフラグは、Dockerfile全体に対して単一のレイヤーを生成します。秘密の痕跡はありません。

--squashは、実験的なフラグとしてdocker-1.13で使用できます。

@hmalphettesこれは、ビルド間で共有される下位レイヤーの利点を見逃すことを意味します。

これは間違いなくスカッシュの意図ではありません。 私はまだこのような秘密を追加することに非常に注意しています。

@zoidbergwill下位レイヤーは引き続き共有されます。

@ cpuguy83に100％同意します。 秘密を守るためにビルド時間フラグに依存することはかなり危険です。 ビルド時間の提案PRがありました（https://github.com/docker/docker/pull/30637）より多くのフィードバックを得るためにリベースに取り組みます。

@wpalmer自動化されたイメージビルドがある場合、ツールはビルド時のシークレットを取得する方法を知っている必要があります。

たとえば、ビルド時のシークレットをイメージにベイクされたAnsible暗号化ボールトに保持し、そのイメージから実行されているコンテナーに、ボールトのパスワードを保持するランタイムシークレットへのアクセスを許可したい場合があります。

WDYT？

ビルド時のシークレットとランタイムシークレットを混同し続けるのはなぜですか？ docker（またはkubernetesなどの関連ツール）がランタイムシークレットを提供するための優れた方法はすでにたくさんあります。 本当に欠けているのは、ビルド時の秘密だけです。 これらのシークレットは実行時に使用されず、インストール時に使用されます。これは、たとえば内部リポジトリである可能性があります。 このトピックと関連トピックで私が見た（しかしそれに対してもアドバイスされた）唯一の有効な方法は、ビルド時にhttpサーバーをコンテナーに公開することです。 httpサーバーのアプローチは、実際にそれらの秘密に到達するために物事を静かに複雑にします。

+1ビルドタイムシークレット！=ランタイムシークレット

パウロが指摘するように。 内部リポジトリをベイクすることは望ましくありません
画像へのクレデンシャル。

なぜこれがとても理解しにくいのですか？

2017年2月16日木曜日、14：42 Paul van der Linden、 notifications @ github.com
書きました：

ビルド時のシークレットとランタイムシークレットを混同し続けるのはなぜですか？ 三
docker（またはkubernetesなどの関連ツール）が
ランタイムシークレットを提供します。 本当に欠けているのはビルド時間だけです
秘密。 これらのシークレットは実行時に使用されません。
インストール時間。これは、たとえば内部リポジトリである可能性があります。 唯一の
このトピックと関連トピックで見た作業方法（ただし、アドバイスもあります）
それに対して）、ビルド時にhttpサーバーをコンテナに公開しています。
httpサーバーのアプローチでは、実際にアクセスするのが非常に複雑になります。
それらの秘密。

—
あなたが言及されたので、あなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/docker/docker/issues/13490#issuecomment-280348116 、
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/AAZk5h0Z2OGwApVnLNEFWKRdOfGxLOmRks5rdGBagaJpZM4Eq021
。

@ pvanderlinden2つのステップを構築してそれを行うこともできます。
ここに例があります： https ：

前述のように、 @ timkaは、セキュリティ上のリスクをもたらすため、クレデンシャルをイメージに焼き付けることは望ましくありません。 ビルド時間の秘密の提案は次のとおりです： https ：

@BenoitNorrin私の（および他の）ユースケースでそれがどのようになるか
Dockerビルドプロセスを開始すると、インストールする必要のあるパッケージはすでにビルドされています。 ただし、dockerビルドはこれらのパッケージをインストールする必要があり、内部のanacondaリポジトリやpypiサーバー（python）にアクセスする必要があります。 場所とパスワードはもちろんプライベートです。
＃30637は別の試みのようですが、うまくいけば、これはDockerになります！

@timkaメッセージの前半はビルド時の秘密について言及しているようですが、後半は実行時の秘密について明示的に説明しています。 実行時の秘密は単純です。 ビルド時シークレットの現在の「解決策」は、完全に別のステップとして、ランタイムシークレットを使用してプライベートデータをフェッチするコンテナーを事前に実行することです。 次に、通常のdocker buildコマンドを実行する前に、これをツリーにマージします。

ビルド時のシークレットが標準機能である場合の代替手段は、Dockerfile内でこれらのステップを実行することです。

私のツールはこれらのステップを自動的に実行する方法を知っていますが、これを自分でベイクする必要がありました。これは、このような一般的な要望にはややばかげています。

参考までに、ビルド時のシークレットの問題に対処するためにhttps://github.com/abourget/secrets-bridgeを作成しました。

引数として渡すことができる使い捨ての構成を作成します。ビルドプロセス中に、ホストに接続してシークレットを取得し、それらを使用してから、ホストブリッジを強制終了できます。 build-argsがどこかに保存されていても、サーバーが強制終了された瞬間にそれらは役に立たなくなります。

サーバーは、TLSWebSocket通信を介してトンネリングされるSSHエージェント転送をサポートします。 Windowsでも動作します！

アレクサンドル、あなたがしたことは非常に創造的で熟練しています。 それだけ
これらすべてのステップをただジャンプするために必要なことは私を悲しくさせます
'dockerbuild'が 'mount'をサポートした場合と同じことを実現します
すべてがにコピーされるという盲目的な主張ではなく、コマンド
容器。

私は「dockerbuild」を放棄し、代わりにロッカーまたは
私自身の創造物なら何か。

2017年7月13日木曜日、16：23 Alexandre Bourget、 notifications @ github.com
書きました：

参考までに、私はhttps://github.com/abourget/secrets-bridgeを作成して
ビルド時の秘密の問題。

引数として渡すことができる使い捨ての構成を作成します。
ビルドプロセス中に、ホストに接続してフェッチします
シークレットを使用して、ホストブリッジを強制終了できます。 たとえ
build-argsはどこかに保存され、サーバーが役に立たなくなった瞬間に使用できなくなります
殺されます。

サーバーは、TLSを介してトンネリングされたSSHエージェント転送をサポートします
WebSocket通信。 Windowsでも動作します！

—
あなたが言及されたので、あなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/moby/moby/issues/13490#issuecomment-315111388 、またはミュート
スレッド
https://github.com/notifications/unsubscribe-auth/AAZk5hZqTAgPBjS9cFP_IsYNa9wv-yoAks5sNjaBgaJpZM4Eq021
。

最新の秘密の提案は次のとおりです： https ：

前回のDockerCEリリースに含まれている新しい「マルチステージビルド」機能は、私たちの問題の大部分を解決すると思います。

https://docs.docker.com/engine/userguide/eng-image/multistage-build/

コンテナからのコマンドを実行するために生み出されたDockerfile調理が付属しています/devと何も変更が層にそこに記録されなければならない行われません。 dockerはそのマウントポイントを介してユーザーシークレットを配信できますか？ 同様の方法で/dev/initますか？

引数を使用したマルチステージビルドはイメージにリークしませんが、実行中のシステムのプロセスリストの一部としてシークレットを公開するため、これは依然として非常に重要です。そのため、実際には解決されません。

2017年8月です。一方、元の号の「秘密を処理するための古い提案」は、2014年の号にリンクしています。

ビルド時の秘密に対する良い解決策はまだありません。 --build-time-secretフラグを提供したPRは、説明なしでクローズされました。 「では、何が必要ですか？」には何も表示されません。 セクションが実装されています。

その間

新たに設置されたCEOのスティーブシンは、ビジネス顧客に焦点を当てています
販売、マーケティングチームの形成を支援するための7500万ドルの最新ラウンド

UPD。：@ cpuguy83が正しくそして正しく以下に指摘されているように、提案の完全な要約は＃33343にあります。

組み込まれていないことはわかっていますが、今のところsecrets-bridgeはかなりうまく機能します。

@dmitriidこの機能が欠落していることへの不満を理解しています。 ただし、これはオープンソースコミュニティ（または任意のコミュニティ）に対処する方法ではありません。

上記の提案へのリンクを投稿しましたが、私自身を除いて、コメントはまったくありません。

これが最新の秘密の提案です：＃33343

@ cpuguy83すごい！ このディスカッションの最後の3分の1（および他のいくつか）は読むことがたくさんあるので（同時に解決策を探している間）スキップしたので、コメントを本当に逃しました、ごめんなさい:(

このスレッドは2015年に開始されました。

2017年です。

まだハックでひどいものではないビルド時の秘密の解決策がないのはなぜですか？ それは多くの人にとって明らかに大きな問題ですが、それでも実際に良い解決策はありません！

@mshappe

まだハックでひどいものではないビルド時の秘密の解決策がないのはなぜですか？

正しく解決するのは難しい問題であり、文字通り何百万もの人々によって使用されるものだからです。

あなたのすぐ上の私のコメントを見てください：

上記の提案へのリンクを投稿しましたが、私自身を除いて、コメントはまったくありません。
これが最新の秘密の提案です：＃33343

何かが実装されているのを見たい場合は、何かが実装されていないことを訴える以上のことをする必要があります。 提案にコメントしてください！

解決するのはとても簡単です。 それはただ何かを必要とします、そうでないものは何でも
画像に焼き付けました。 そして実際にはそれは非常に簡単に解決でき、使用をやめる
「dockerbuild」を使用して、Python API、ロッカー、またはその他のものを使用します。

21:42の水曜日、2017年8月23日には、ブライアン・ゴフ[email protected]
書きました：

@mshappe https://github.com/mshappe

ハッキングではないビルド時の秘密の解決策がないのはなぜですか
ひどい、まだ？

正しく解決するのは難しい問題であり、
文字通り何百万もの人々によって使用されます。

あなたのすぐ上の私のコメントを見てください：

上記の提案へのリンクを投稿しましたが、コメントは0件しかありません。
私自身を除いて。
これが最新の秘密の提案です：＃33343
https://github.com/moby/moby/issues/33343

何かが実装されているのを見たい場合は、以上のことをする必要があります
何かが実装されていないことを訴えます。 提案にコメントしてください！

—
あなたが言及されたので、あなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/moby/moby/issues/13490#issuecomment-324441280 、またはミュート
スレッド
https://github.com/notifications/unsubscribe-auth/AAZk5oEpcipmfCji1mXz6MOVt0p6-OA6ks5sbIC0gaJpZM4Eq021
。

@binarytemple私は代わりにロッカーを検討し始めましたが、実際には...しかし、この奇妙なメンタルブロックドッカーがビルド時の秘密について持っているように見えるからです。

それは奇妙だ。 私は人々と話します、そして彼らはあらゆる種類の愚かなハックをしています
HTTPサービスを使用するようなもの-すべてを破棄する（監視/詳細
パーミッション/シンプルさ）POSIX / SELinuxコンボが提供します。 私はしません
理解する。 拒否は私には非論理的に思えます。

水で、2017年8月23日、23時03分マイケル・スコットShappe [email protected]
書きました：

@binarytemplehttps ：//github.com/binarytemple私が見始めた
代替手段としてのロッカー、実際には...しかし、この奇妙な理由だけで
メンタルブロックドッカーはビルド時の秘密について持っているようです。

—
あなたが言及されたので、あなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/moby/moby/issues/13490#issuecomment-324461257 、またはミュート
スレッド
https://github.com/notifications/unsubscribe-auth/AAZk5ppZYsOhdfvgotCUk5l41Truo_EEks5sbJOLgaJpZM4Eq021
。

マルチステージDockerビルドは、これらの問題の多くを解決します。

最も単純な形式では、ビルド引数としてシークレットを挿入できます。シークレットは、引数が必要であると明示的に示す画像の画像履歴の一部になります。 neclimdulが指摘しているように、秘密はビルド中にプロセスリストで利用可能になります。 IMOは大きな問題ではありませんが、別のアプローチを採用しています。

ビルドサーバーは、ボリュームとしてマウントされたいくつかのシークレットで実行されるため、f.exのCIコピー。 /mnt/secrets/.npmrcを現在の作業ディレクトリに追加します。 次に、以下のようなDockerfileを使用します。

FROM node:latest
WORKDIR /usr/src/app
COPY .npmrc .
RUN echo '{ "dependencies": [ "lodash" ] }' > package.json
RUN npm install
RUN ls -lah

FROM alpine:latest
WORKDIR /usr/src/app
COPY --from=0 /usr/src/app/node_modules ./node_modules
RUN ls -lah
CMD ["ls", "./node_modules"]

結果のイメージには依存関係がインストールされますが、.npmrcまたはそのコンテンツのトレースは含まれません。

マルチステージビルドを使用すると、ビルド時間の秘密をビルドプロセスに公開する方法を完全に制御できます。 Vaultなどの外部ストアからボリューム（KubernetesのSecretsストアからマウント）を介してシークレットを取得し、リポジトリでgpg暗号化するか、Travisシークレットなどを取得できます。

このユースケースでマルチステージビルドを使用する場合は、シークレットデータがローカルデーモンのタグなしイメージ内に残り、そのイメージが削除されるまで、このデータを後続のビルドでビルドキャッシュに使用できることを確認してください。 ただし、最終的なタグ付きイメージをプッシュするときに、レジストリにプッシュされません。

@androa私はその解決策が好きですが、秘密が作業ディレクトリにコピーされていることについてどう思うかわかりません。 プライベートCIサーバーではおそらく問題ありませんが、保護された場所からファイルをコピーするべきではないローカルの建物にはあまり適していません（コピー自体は、誤って終了する可能性があるため、煩わしく危険です。ソース管理でアップ）。 もう1つのオプションは、より広いDockerビルドコンテキストを使用することですが、ルートボリューム全体を意味する可能性のある多くの一般的なシークレットがあります。 これをローカルおよびCIに適したものにする方法に関する提案はありますか？

これはぞっとします。 自称「世界をリードするソフトウェアコンテナプラットフォーム」は、過去3年間、ビルド時のシークレットをコンテナに安全に渡すことを気にすることはできません。

「私たちはよく知っている」と「間違いを許すソフトウェアを作らない」アプローチと、設計段階での不幸な省略としてせいぜい説明できることによって、DevOpsソフトウェアの必要な機能の1つに向けたサポートと目に見える進歩はありません。 すべてのコミュニティは、誰かがそれらを悪用することを恐れて、マージ対応の改善を提案し、時にはそれを開発することさえもシャットダウンします。 このクラスターの失敗の結果として、Dockerコンテナーのビルドフェーズにのみ必要な秘密鍵を渡すすべての方法では、それらのシークレットをビルド履歴に保存するか、ビルド履歴が決して離れないことを期待してプロセスリストに表示する必要があります。信頼できるマシン、またはプロセスリストを表示することを想定されていない人は誰もいません。 どちらも、最も寛容なセキュリティ監査でさえ失敗します。

この問題は2年以上前から開かれており、その時点で問題についてわかっていたことと、それに対して何をすべきかを要約しています。 まだ解決策はありません。 それは、箱から出して最も複雑な秘密管理スキームをサポートする包括的なソリューションを意味するものではありません。 解決策はまったくなく、ホスト環境変数も、ビルドコンテキスト外のファイルパスからシークレットをロードすることもありません。 最も厳格な条件でさえ安全であると見なすことができるものはありません。

私はこの問題に複数回を述べてきたように@OJezu、その上に基本的に0コメント付きのオープン提案されています。
秘密が押し進められるのを見たい場合は、時間をかけて提案にコメントしてください。

毎日これに取り組んでいる人々を攻撃する銃を撃つ代わりに、次回は質問をして、あなたがコメントしている問題について少なくとも最新のコメントを読んでみてください。

本当に一生懸命働いている人がいると、物事はしばしば行き詰まって見えることがあります。
ビルドについては、この作業のほとんどが今日行われているgithub.com/moby/buildkitを参照してください。

ありがとう。

私は少しほろ酔いです。今日、特にフルタイムで作業されており、デファクトスタンダードとしての地位を確立しているプロジェクトで、問題とならない問題の解決策を見つけるために9時間を費やしたからです。 。 私はこれらのコメントを書いている間、自傷行為を誓ったり止めたりしないように一生懸命努力していました。

私はその問題を調べ、2つの解決策への言及を見ました。1つは4月以降停滞しており、もう1つはすでに閉鎖されています。 コメント0の提案には、4人の参加者、同じ数のコメントがあり、いくつかの明らかな内部ディスカッションについて言及していることに気付かずにはいられません。 しかし、プログラムを実行していない人からの追加のフィードバックが必要な場合は、前のコメントで触れた問題について、より多くの考えを提供できます。

@OJezu

少なくとも1つの簡単な解決策があります。専用のサービス（たとえば、Jenkinsで実行）を使用してアーティファクトを構築します。
そのサービスは、イメージが依存するアーティファクトにアクセスするために必要なすべてのキーを安全にプロビジョニングします。
終了時に、アーティファクトは安全な場所（Jenkinsなど）に配置されます。 これらのアーティファクトにはシークレットは含まれず、binaries / sources / etcを含むディレクトリのみが含まれます。
次に、別のサービス（たとえば、別のJenkinsジョブ）がこれらのビルド済みアーティファクトにアクセスし、イメージレジストリに安全にプッシュできるイメージに変換します。イメージレジストリは、開発者/本番マシンからアクセスするためにrbac / keysを使用して安全に保護されます。

つまり、Dockerイメージのビルドプロセスは、他のビルドシステムと同じです。ビルドパイプラインを配置する必要があります。

@Vanuanすべての言語がパッケージ化とインストールで

例？

Pythonプロジェクトは、ビルド時間ではなく、インストール時間に要件を取り込みます。 私たちの場合、プライベートpypi / condaリポジトリから（パスワードで保護されています）

そう？ インストールをビルドプロセスの一部にしてから、インストールしたパッケージを新しいイメージにコピーします。

ビルドイメージと本番イメージが同じPythonベースイメージに基づいていることを確認する必要があります。

実際、すべてを新しいイメージにコピーすることができます。 ただし、Dockerfileの要点全体が削除されます。 一連のディレクトリをコピーするだけでDockerfileを使用できるのに、なぜDockerfileがあるのでしょうか。

したがって、開発マシンまたはCIのいずれかで、どこでもdocker build .実行するという単純なフローを作成することはできませんが、パッケージをビルドするにはCIに依存する必要があります。 では、なぜDockerを気にする必要があるのでしょうか。 travisファイルを作成したり、bambooでフローを構成したりできます。

プライベートリポジトリから取得できるシークレットを使用して、最初のステージのビルドでpip install requirements.txtだけを使用することはできません。 次に、次のステージのビルドは、最初のステージからサイトパッケージをコピーするだけです。

一連のディレクトリをコピーするだけでDockerfileを使用できるのに、なぜDockerfileがあるのでしょうか。

なぜだめですか？ Dockerfileを使用してビルドすることには一貫性があります。

画像の仕様は、単なるzipファイルの集まりではありません。 環境変数、コマンドライン引数、ボリュームなどがあります

Dockerfileリファレンスを読んでください：
https://docs.docker.com/engine/reference/builder/

DockerfileがMakefileの代わりになると考えて、主にRUN命令に焦点を合わせているようです。 そうではない。 Dockerfileは、1つの目的のみを目的としています。ソースマテリアルからイメージを構築することです。 そのソースマテリアルが何であるか（httpまたはgitリポジトリを介してダウンロードされたバイナリ）は重要ではありません。 Dockerは、特定の条件下でCIシステムとして使用できますが、CIシステムである必要はありません。

travisファイルを作成したり、bambooでフローを構成したりできます。

ビルドプロセスの結果を取得して、イメージやコンテナーを使用せずに別の環境で実行できる場合は、Dockerを気にする必要はありません。 なんで？

ビルドステップが変更された場合にのみ、ビルド間でリセットが保証される、厳密に制御された個別の環境。 CIサーバー（Travisなど）だけでなく、どこでも実行できる機能。ビルド命令をコードに結び付けます。これは、ビルドが異なるコードブランチに変更された場合（たとえば、1つのブランチでのみ実行環境のバージョンを変更した場合）に適していると思います。 開発者のマシンでビルドコンテナを実行する可能性。他の方法では自分のシステムをアップグレードする方法がわからない開発者に環境全体を出荷できますが、他のすべての人と同じ環境でローカルに変更を加えてアプリケーションをビルドできます。

そのすべてが必要ない場合は、lxc + ansibleに固執し、Dockerは必要ありません。

そのためにdocker buildは必要ありません。

そのためにdocker buildは必要ありません。

もちろん、単一の自給自足のDockerfileの代わりに、プロジェクトごとにカスタムのMakefileまたはbuild_image.shスクリプトを提供することもできますが、これには複数の欠点があります。

• クロスプラットフォームの互換性：Dockerfileを提供することで、 docker buildを実行できるすべてのシステムでイメージをビルドできるようになります。 カスタムのMakefileまたはbuild_image.sh提供することで、サポートしたいすべてのプラットフォームでそれらが機能することを手動で確認する必要があります。
• ユーザー向けの既知のインターフェース：dockerを知っている場合は、Dockerfileを見なくても（たとえば、キャッシュなど）、任意のプロジェクトでのdocker buildの動作の一部を知っています。 プロジェクトごとにカスタムのMakefileまたはbuild_image.shがある場合は、最初に、ビルド、クリーンアップ、結果がどこにどのような形式であるかを確認する必要があります。いくつかのキャッシングであり、どのような形式で、..。

ああ、Dockerfileは自給自足にはほど遠いです。 特に開発環境向け。
このことを考慮：

• ほとんどの開発者はdocker buildのさまざまなオプションをすべて知っているわけではありませんが、ほとんどの人はbashスクリプトの実行方法を知っています。
• docker buildは、コンテキストディレクトリによって異なり
• すべてを最初から構築しない限り、 Dockerレジストリに依存し
• 静的に構築されたバイナリに直接コンテナを起動しない限り、 OSリポジトリ（DebianまたはAlpineベースのイメージを使用するかどうか）に依存する可能性があります
• すべてをgitにコミットしない限り、npm、python package index、rubygemsなど、プロジェクトレベルの依存関係があります。 したがって、外部パッケージレジストリまたはそのミラーに依存します
• ほとんどの人がここで気づいたように、パブリックリポジトリに公開できないプライベート依存関係の秘密のパッケージの場所に
• その安全な場所にアクセスするにはシークレットのプロビジョニングが必要であるため、開発者にシークレットを
• Dockefileに加えて、docker-compose.ymlが必要です。これはクロスプラットフォームではありません。それでも、円記号と円記号の違いに依存し

クロスプラットフォームの互換性：Dockerfileを提供することで、dockerbuildを実行できるすべてのシステムでイメージをビルドできるようになります。

Dockerfileは、クロスプラットフォームの互換性を保証しません。 それでも、複数のプラットフォームに複数のDockerfileを提供する必要があります。 「dockerbuildを実行できる」とは、「Linuxを使用する」という意味ではありません。 DockerはWindowsネイティブイメージもサポートしています。 WindowsホストでLinuxマシンを特に対象としたものを実行する場合は、Cygwin + LinuxVMを使用する必要があります。

ああ、x86とARMについては触れませんでした...

ユーザー向けの既知のインターフェース：dockerを知っている場合は、Dockerfileを見なくても、プロジェクトのdockerbuildの動作の一部を知っています。

そうしない限り。 誰もがパラメータや単一のmakeコマンドなしでbashスクリプトを実行する方法を知っています。 docker build 、 docker runまたはdocker-composeすべての異なるコマンドラインオプションを正しく指定する方法を知っている人はほとんどいません。 ラッパーbashまたはcmdスクリプトが必要になることは避けられません。

Dockerの人々が行ったことに敬意を表して、あなたはあまりにも多くのことを求めていると思います。 Mobyprojectには、考えられるすべての開発ワークフローをサポートするほど広い範囲がないのではないかと思います。

私はあなたのすべての点を個別に反駁するつもりはありません。 まず、もちろん、「単一のDockerfile」アプローチがまったく機能しない状況を常に見つけることができます。 ただし、あなたが提起したほとんどすべてのポイント（すべて有効で関連性のあるもの）について、「カスタムスクリプトまたはmakefile」アプローチは同じくらい悪いか悪いかのどちらかであると私は主張します。 一例として、1つのポイント：

ほとんどの開発者はdockerbuildのさまざまなオプションをすべて知っているわけではありませんが、ほとんどの人はbashスクリプトの実行方法を知っています。

私が10のプロジェクトに関与していて、それらがすべてDockerfileを使用している場合、dockerについて1回だけ学ぶ必要がありますが、あなたの提案により、10のまったく異なるビルドスクリプトを学ぶ必要があります。 プロジェクトFooのbuild_image.shのキャッシュをワイプして最初からやり直すにはどうすればよいですか？ それははっきりしていません。 イメージの構築がdocker buildで行われる場合、それは明らかです（Dockerがどのように機能するかを知る必要がありますが、 build_image.shから出てくるイメージを使用するためにもそれを行う必要があります）。

全体として、私や他の人が言いたいのは、/ many /シナリオでは、「単一のDockerfile」アプローチが人々にとって非常にうまく機能しているように見えることです（これがdockerが非常に人気がある理由です）。通常、すべてのリソースに秘密なしでアクセスできるオープンソースの世界。 しかし、リソースの一部にアクセスするためにクレデンシャルが必要な状況で、あなたが愛するようになったのと同じパターンを適用しようとすると、アプローチは失敗します。 それを機能させるための技術的にそれほど複雑ではない方法の多くの提案（および実装）がありましたが、長い間それは何も起こりませんでした（これは何度も上に置かれました）。 したがって、欲求不満。

たとえば、＃33343のリンクされた提案など、人々がこれに力を注いでいることを感謝します。 私の投稿は、何人かの人々が何を、そしてなぜ彼らがここでそれを求めて戻ってくるのかを動機付けることについてです。

Dockerの人々が行ったことに敬意を表して、あなたはあまりにも多くのことを求めていると思います。 Mobyprojectには、考えられるすべての開発ワークフローをサポートするほど広い範囲がないのではないかと思います。

ほとんどの人がここで求めているのはそのようなものではないようですが、カスタムbuild_image.shで使用するよりも安全性が低くない方法でdocker buildシークレットを使用する簡単な方法のためだけです。 build_image.sh 。 このニーズを満たす1つの方法は、ビルドタイムマウントのようです。 それらには欠点があり、おそらくより良い方法がありますが、求められているのは、考えられるすべてのコーナーケースをカバーすることではありません。

申し訳ありませんが、このチケットの各ユーザーのユースケースは少し異なります。 これらはコーナーケースであり、さまざまなソリューションが必要です。

1. 開発マシンで本番イメージを実行したい。 Dockerレジストリを使用する
2. 各開発者が再現可能なビルドを持つように、分散CIシステムが必要です。 docker runを使用してプロジェクトをビルドし、 docker pruneを使用してクリーンアップします
3. 配布できるようにDockerイメージを作成したいと思います。 マルチステージビルドを実行できる専用のCIサーバーを使用します。

@Vanuanなので、基本的には、基本的な環境以外には

この問題を推進する人々は、Dockerの制限をハックする必要がなく、Dockerイメージを使用したよりシンプルでわかりやすいアプローチを望んでいます。

興味のある人のために：私はFTP_PROXYのような「デフォルトでマスクされた」build-argsを利用してコンテキストを構築しようとしました。 docker-buildがこれらのマスクされた引数を画像メタデータや画像レイヤーに公開しないという事実に関しては安全です。

36443は、 SECRETような名前のbuild-argに拡張する試み

ただし、これらのビルド引数のマスクされた性質は将来保証されないため、作業は合理的に拒否されました。

その後の私の最善の策は、 @ AkihiroSudaのアドバイスに従い、 docker build --networkまたはhabitusのようなツールを使用して、一時的なtcpサーバーを介してシークレットを保存/渡すことです。

部分的にコメントしているので、5年後、Dockerが最終的に適切な資格情報管理の方向に小さな一歩を踏み出すことを決定したときに通知を受け取ります。また、現在使用しているハックの概要を説明します。 、他の人を助けるため、または私が知らない穴を開けるために。

次の@mumoshuの問題で、ビルドシークレットにpredefined-argsを使用するヒントがついに得られました。

したがって、基本的に、次のようなマッピングでdocker-composeを使用できます。

  myProject:
    build:
      context: ../myProject/
      args: 
        - HTTPS_PROXY=${NEXUS_USERNAME}
        - NO_PROXY=${NEXUS_PASSWORD}

次に、docker-compose.ymlファイルのあるフォルダーに、NEXUS_USERNAMEとNEXUS_PASSWORDのキーと値のペアを含む「.env」という名前のファイルと、そこに適切な値を作成します。

最後に、Dockerfile自体で、次のようにrunコマンドを指定します。
RUN wget --user $ HTTPS_PROXY --password $ NO_PROXY

また、DockerFileでそれらをARGとして宣言しないでください。

結果のビルドにクレデンシャルが浮かんでいるのをまだどこにも見つけていません...しかし、どこを見ているのかわかりません.....そして、私のプロジェクトの残りの開発者にとっては、それぞれが適切な値を使用して.envファイルを作成します。

@darmbrust私はあなたの解決策を試しましたが、
これが私のcomposeymlです：
バージョン：「3.3」
サービス：

  buildToolsImage:
    image: vsbuildtools2017:web-v6

    build:
      context: .
      dockerfile: ./vsbuild-web-v6-optimized.dockerfile
      args:
        - CONTAINER_USER_PWD=${CONTAINER_USER_CREDS}

ymlファイルの隣にある.envファイルは次のとおりです。

CONTAINER_USER_CREDS=secretpassword

そして、これが私のdockerfileです：

# escape=`
FROM microsoft/dotnet-framework:4.7.2-sdk
# Add non-root user
CMD ["sh", "-c", "echo ${CONTAINER_USER_PWD}"] 
RUN net user userone ${CONTAINER_USER_PWD} /add /Y

そして最後に、これを開始するコマンドは次のようになります。

docker-compose -f docker-compose.buildImage.yml build

イメージをビルドしますが、.envファイルに保存されているパスワードは使用しません。

[警告] 1つ以上のビルド引数[CONTAINER_USER_PWD]が消費されませんでした

ここで何が欠けていますか？
ありがとう！

dockerファイルでhttps://docs.docker.com/engine/reference/builder/#predefined-argsのいずれかを使用する必要があります。 CONTAINER_USER_PWDのような独自の引数名を使用することはできません。

これがトリックの仕組みです。dockerにはpredefined-argsに対して特別な動作があり、宣言せずに使用できます。 そして、それらを宣言せずに使用することにより、それらはどこにも記録されていないように見えます。

docker-composeファイルを使用すると、これらの事前定義された引数をより適切な名前の何かにマップできます。

@darmbrustはい、
でも、臭いと思いませんか？ より良い推奨事項はありますか？
ありがとう！

おそらく、TCPを介してssh-agentクレデンシャルを公開するほど臭くはありません
盗むためのローカルプロセスのためのsocatを介して、しかし実際には、他のものと同じように
秘密に関連して、「dockerbuild」は確かにかなり臭いです。

実は、Docker forMacがUnixドメインを公開できないことを忘れていました
osxホストのソケットをコンテナに接続することで、さらに多くの
ワームの缶。

私の現在の解決策は、Centos VM、GitHubマシンのユーザーアカウントを実行する
クレデンシャルが入り、「ロッカー」（非推奨）ツールを使用してビルドします。

2018年7月26日木曜日、21：49 Sameer Kumar、 notifications @ github.comは次のように書いています。

@darmbrust https://github.com/darmbrustはい、それでうまくいきました。
でも、臭いと思いませんか？ より良い推奨事項はありますか？
ありがとう！

—
あなたが言及されたので、あなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/moby/moby/issues/13490#issuecomment-408230125 、またはミュート
スレッド
https://github.com/notifications/unsubscribe-auth/AAZk5iz1kvCpZ0s65ng4TwL7LmHa9zZvks5uKitDgaJpZM4Eq021
。

このバグ全体が臭いです。 より良い方法は見つかりませんでした...上記の他のいくつかのアプローチがありますが、他のすべての安全なアプローチでは、情報を画像にフィードするために小さなhttpサーバーを立ち上げる必要があると思います。 臭いは少ないかもしれませんが、より複雑で、より多くのツール、より多くの可動部品があります。

誰かが「良い」解決策を見つけたかどうかはわかりません...私たちは皆、Dockerの人々がそれについて何かをするのを待っています...このバグは2015年に書かれたので、息を止めないでください。まだロードマップを提案していましたが、解決策ははるかに少ないです。

それはとてもシンプルで明白で、ボリュームのマウントを可能にします（ファイルまたは
ディレクトリ）ビルド中にコンテナに。

これは技術的な制限ではなく、秘密を許可しないという決定です
の動作を維持するために-チェックアウト、ビルドの実行、同じ入力、同じ
出力、キャッシュを無効にする場合はビルド引数を変更します。

問題は、抽象化がますます漏れやすくなっていることです
あらゆる種類の厄介で安全でないハックを使用して「秘密」を取得する人々と
コンテナに。

ニュースフラッシュ、ローカルホスト上でもTCP経由でSSHキーリングを公開する
安全で、どちらも環境変数を介してクレデンシャルを渡していません（ヒント、実行
ps、または/ procファイルシステムのピーク）、コマンド引数、および環境変数はすべて、世界中に公開されています。

golangコードの開発者にとって、これはコピーアンドペーストであるため、従来は問題になりませんでした。
依存関係管理ツールを使用するのではなく、プロジェクトへの依存関係を、golang開発者はこのプラクティスを「ベンダー」と呼びます。

ビルドシステムが存在する他のエコシステムで作業している人のために
Git、または認証を必要とするリポジトリから依存関係をフェッチすることは、大きな問題です。

の線に沿ってどこかにスタートアップルールがあると確信しています。
「ユーザーが製品をどのように、またはなぜ使用するかを知っていると思い込まないでください」。

2018年7月26日木曜日、22：00 Dan Armbrust、 notifications @ github.comは次のように書いています。

このバグ全体が臭いです。 私はより良い方法を見つけていません...あります
上記の他のいくつかのアプローチですが、他のすべての安全なアプローチだと思います
情報をにフィードするために小さなhttpサーバーを立ち上げる必要があります
画像。 多分臭いは少ないですが、より複雑で、より多くのツール、より感動的です
部品。

誰かが「良い」解決策を見つけたかどうかわからない...私たちは皆立ち往生している
Dockerの人々がそれについて何かをするのを待っています...
このバグは2015年に作成されて以来、彼らは提案すらしていません。
ロードマップはまだですが、解決策ははるかに少ないです。

—
あなたが言及されたので、あなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/moby/moby/issues/13490#issuecomment-408233258 、またはミュート
スレッド
https://github.com/notifications/unsubscribe-auth/AAZk5nvbBTj4BAv5TtELNIHhJN8mU0Ctks5uKi38gaJpZM4Eq021
。

@binarytemple Docker / mobyに取り組んだことのある人は誰でも（その背後にいるエンジニアのように）、問題が何であるかを正確に知っており、それに直面したことさえあります。

ボリュームは、それ自体が信じられないほどリークの多いソリューションです。
コメントストリームで少し言及された、これを合理的な方法で解決しようとする提案があります（https://github.com/moby/moby/issues/33343）

ここでの主なことは、「たまたま機能する抽象化」ではなく、「正しい」抽象化を提供することです...もちろん、これは、この場合だけでなく、多くの人にとって苦痛であることを私たちは知っています。

最近、ビルダーで多くの作業が行われていますが、これは必ずしも表示されているわけではありませんが、この取り組みの成果は今後数か月で現れ始めます。
まず、Docker 18.06には、 https：//github.com/moby/buildkitに基づく代替のビルダー実装が付属してい
「これはどのように私を助けますか？」と思うかもしれません。 Buildkitは、Dockerビルダーではるかに柔軟になることを可能にする多くの低レベルのプリミティブを提供します。 独自のビルドパーサー（拡張されたDockerfileパーサーから完全に異なるものまで何でもかまいません）を提供できるようにすることさえできます。 パーサーは「Dockerfile」の上部に指定されており、ファイルの解析に使用する任意の画像です。

今すぐ何かを見たい場合は、buildkit自体を使用して、今日それを実行できます。これは、コンテナー化されたものの上に配置され、カスタム統合を非常に迅速に構築できます。

シークレットマウントのサポートがhttps://github.com/moby/buildkit/pull/522のbuildkitに追加されました。 これらは厳密にtmpfsに表示され、ビルドキャッシュから除外され、構成可能なデータソースを使用できます。 dockerfile構文で公開するPRはまだありませんが、単純な追加である必要があります。

シークレットを使用してイメージを作成するには、2つのソリューションがあります。

多段階ビルド：

FROM ubuntu as intermediate
ARG USERNAME
ARG PASSWORD
RUN git clone https://${USERNAME}:${PASSWORD}@github.com/username/repository.git

FROM ubuntu
# copy the repository form the previous image
COPY --from=intermediate /your-repo /srv/your-repo

次に： docker build --build-arg USERNAME=username --build-arg PASSWORD=password my-image .

イメージビルダーの使用： docker-build-with-secrets

@BenoitNorrin申し訳ありませんが、そのパスワードをホストシステム上のすべてのプロセスに公開しました。 Unixセキュリティ101-コマンド引数としてシークレットを入れないでください。

はい。ただし、セキュリティが少し重要でない使用法がいくつかあります。

• 自分のコンピューターで構築したい
• エンタープライズCIサーバー（jenkinsなど）に基づいて構築します。 ほとんどの場合、プライベートリポジトリ（nexus、git、npmなど）にアクセスできるため、CIはそのための独自のクレデンシャルを持っている可能性があります。
• docker-machineから作成されたVMを使用して、後で削除できます。

それが唯一の問題である@binarytempleの場合、フラグdocker image build --args-file ./my-secret-fileを追加するだけで、この問題全体を簡単に修正できるはずです。 ：考え：

@yajoはそうかもしれません、はい、

残念ながら、これらおよび他の多くのチケットで言及されている回避策のほとんどは、結果のイメージに秘密を公開するか、インストール中にではなくコンパイル時にのみ依存関係が必要な特定の言語でのみ機能します。

@binarytempleは決して発生しませんが、

最大の問題点は私にとって秘密のローテーションです

シークレットとサービスの依存関係のグラフを維持し、各サービスを2回更新する必要があります（元のシークレット名に戻すため）

サービスからシークレットを一覧表示するのは簡単ではないようです（ docker service inspect --format='{{.Spec.TaskTemplate.ContainerSpec.Secrets}}' <some_service>何度か試した後、あきらめました）。 docker secret inspect <secret_name>からサービスの依存関係を一覧表示することも役立ちます。 だから私は今のところその（おおよその）グラフを手動で維持しています。

docker service updateコマンドでデフォルトの/run/secrets/<secret_name>でない場合は、シークレットの宛先も指定する必要があります

シークレットをローテーションする簡単な方法を望んでいます

@caubここにいくつかのCLIヘルプがあります：

フォーマットに関するDockerドキュメントは、残りの検査フォーマットを作成するのに役立ちます。

docker service inspect --format='{{range .Spec.TaskTemplate.ContainerSpec.Secrets}}{{println .SecretName}}{{end}}'

これにより、サービス内のすべてのシークレット名が一覧表示されます。 名前とIDの両方が必要な場合は、次のことができます。

docker service inspect --format='{{range .Spec.TaskTemplate.ContainerSpec.Secrets}}{{println .SecretName .SecretID}}{{end}}' nginx

私は常にCI / CD（サービス更新コマンド）またはスタックファイルにパスをハードコードしているので、ローテーションでその問題は発生しません。

ラベルを使用すると、スタックファイルを使用していない場合にCI / CD自動化で適切なシークレットを識別できます（シークレット名は必要ありません。シークレット名は毎回異なります）。

docker build --secretがついにDocker18.09で利用可能になりましたhttps://medium.com/@tonistiigi/build-secrets-and-ssh-forwarding-in-docker-18-09-ae8161d066

@thaJeztahこの問題を解決する準備はできていますか？

Dockerの古いバージョンでは、ビルドコマンドの前にシークレットをコピーしてマルチステージビルドを使用することが実行可能なオプションですよね？

`` `
ビルドとしてのDebianから
コピー./secret.conf/ path / on / image /
build.shを実行します
..。

Debianから
COPY --from = build..。

@ andriy-fはい、あなたがいる限り、それは機能します。

• （明らかに）秘密を最終段階にコピーしないでください😉、または：
• buildステージ/シークレットが最終イメージの「親」として存在するステージを使用します
• ビルドステージをレジストリに「プッシュ」しないでください
• デーモンが実行されているホストを信頼します。 つまり、「ビルド」ステージがイメージとして保存されることを考慮に入れます。 その画像にアクセスできる人は、あなたの秘密にアクセスできるようになります。

buildkitをビルダーとして使用するときにビルド時間の秘密が可能になりました。 こちらのブログ投稿を参照してくださいhttps://medium.com/@tonistiigi/build-secrets-and-ssh-forwarding-in-docker-18-09-ae8161d066

およびドキュメント。 https://docs.docker.com/develop/develop-images/build_enhancements/

シークレットに使用されるRUN --mountオプションは、すぐにデフォルトの（安定した）Dockerfile構文に移行します

ありがとう@thaJeztahもう少し掘り下げて、投稿直後にその記事を見つけました（以前の投稿は削除されました）。 再度、感謝します！

いいね。 これで、ビルド時間の秘密の質問は終わりです。 ランタイム/開発時間（OS Xではssh）に何かありますか？