This post is also available in: English (英語) 概要 ここ数年、Docker、Podman、Kubernetesを含むさまざまなコンテナプラットフォームで、copyコマンド(cp)の脆弱性が複数確認されてきました。それらの中で最も深刻なものはこの7月というごく最近発見・開示されたものです。驚くべきことに、CVEの説明内容があいまいだったこと、公開されたエクスプロイトがなかったことなどの理由から、本脆弱性は公開直後にはほとんど注意を引きませんでした。 しかしながら、CVE-2019-14271が攻撃者に悪用された場合、Dockerの実装するcpコマンドは、完全なコンテナブレイクアウトにつながりうるセキュリティ上の問題を引き起こします。この脆弱性は、2月に発見されたrunC脆弱性以降で初めての完全なコンテナブレイクアウトです。 この脆弱性が悪用されるに
表題のような問題があり，その調査したという記録です．なお，結論を一言で言うと--initを使え，ということになります． そもそもDockerコンテナを起動すると，CMDあるいはENTRYPOINTに指定されたコマンドがコンテナ内でPID 1として起動します．これが何を意味するかと言うと，「CMDあるいはENTRYPOINTに指定されたコマンド」はそのコマンド自体の責務をまっとうするのと同時に，initプロセスとしての振る舞いも行わなければならないということになります (id:hayajo_77さんにこの辺を詳しく教えてもらいました，ありがとうございます)． つまりPID 1で動いているプロセスは「SIGCHLDをトラップすることで孤児プロセスを適切に回収し，waitpidをかける」という処理も適切に行う必要があります． さて，puppeteerを使ってChromeブラウザを起動するとどうな
コンテナ型仮想化の技術や実装はDockerが登場する以前から存在していたとはいえ、IT業界で本格的にコンテナの活用が始まったと言えるのは、やはり2013年3月に当時のdotCloudからDockerが登場したことがきっかけでしょう。 そうして始まったコンテナ時代の第一章は今年2017年、コンテナの標準仕様がOpen Container Initiativeによって策定完了し、コンテナオーケストレーションの事実上の標準がKubernetesに決まったことで基盤技術の基本要素がおおむね固まり、一つの区切りがついたように見えます。 そして今後は、この基盤技術を用いたコンテナによる分散アプリケーションのための様々なサービスや開発、テスト、デプロイ、本番環境に対応したツールやサービス実行環境などのソリューションが登場し、競う段階へ入っていくのではないでしょうか。 この記事では、Docker登場から現
大手ＩＴ各社は、仮想化技術を用いた「ドッカー」と呼ばれる、軽量で移行性に優れたコンテナ式アプリケーション（応用ソフト）実行基盤の普及拡大に乗り出す。日本ＩＢＭは自社クラウドに依存せず、オンプレミス（自前運用）でも使えるコンテナ式の実行環境「ＩＢＭクラウドプライベート」の提供を始めた。ＮＥＣはドッカーの利便性を生かし、人工知能（ＡＩ）の利活用を促進するサービスを立ち上げた。ＩＴの新潮流であるコンテナ型の仮想化技術が日本でもいよいよ本番稼働に入る。 ドッカーはアプリやミドルウエアなどを抽象化して、コンテナ方式でコンパクトにまとめ上げる技術。大がかりなシステムが不要な上、場所を問わずに多様なクラウドやオンプレミスなどを実行できる。 この技術はオープンソースとして複数提供されているが、中でもドッカーは米アマゾン・ウェブ・サービス（ＡＷＳ）や米マイクロソフト（ＭＳ）がクラウドサービスに採用し、ここ数
Dockerコンテナ内からホストマシンのルートを取る具体的な方法（あるいは/var/run/docker.sockを晒すことへの注意喚起） 2015/11/04 dockerの -v オプションを使ってホストマシンのディレクトリをマウントするときは、マウントする範囲に注意が必要（特に/var/run/docker.sockをマウントしてはならない）という話を書きます。 元ネタは@lvhが書いてるDon't expose the Docker socket (not even to a container)という記事で、1ヶ月前くらいにHacker Newsで話題になってて知りました。 この元記事で紹介されているいくつかの危険なマウントのパターンに関する情報が、最近dockerを使い始めた自分に有用な情報だったので、自戒も込めて要点を書いておきます。 TL;DR /var/run/docke
注意 本件記事ですが、私の不適切な行動（拾ったスクリプトを検証なく走らせる）が原因です。「dockerは（特に何もしなくとも）危険」との誤解を皆様に与えた点、ご迷惑をおかけいたしました。申し訳ございません。 拡散されている記事を削除するのはさらなる誤解を招きかねないと思いましたので、冒頭に注意を付記しております。以下の記事は、「自分が何してるかをきちんと検証できないとセキュリティホールを生み出す」という意味で参考にして頂ければ幸いです。 追記 Twitterやはてブで言及いただきました皆様、ありがとうございます。 本件はpullしてきたイメージが悪意ある開発者によるものかどうかにかぎらず、不適切な設定をしていると起こり得ます。 ※コメント欄に質問への回答という形で、私がそのときに走らせていたイメージの一覧を挙げておりますが、どのイメージも評判あるものだと思います。 皆様におかれましては「あ
この記事ははてなエンジニアアドベントカレンダー2015の1日目です。今回は、既存の運用フローに乗せやすいDockerイメージへのchrootによるデプロイの考え方と自作のコンセプトツール droot を紹介します。 github.com 背景 Docker 本番導入の課題 Docker 導入の目的 Docker + chroot のアイデア droot: Dockerイメージにchrootするコンテナツール droot の使い方 droot push: Dockerイメージをtar ball化しS3にpushする droot pull: S3にpushしたイメージをダウンロードし展開する droot run: 展開先のディレクトリにchrootする droot の実装 droot push/pull の実装 droot run の実装 あわせて読みたい あとがき 背景 Dockerがリリー
Minecraftクライアントからdockerの管理ができるminecraftサーバー: Dockercraft
docker/dockercraft 公式の未改変Minecraftクライアントから接続してDockerの管理ができるMinecraft互換サーバー、Dockercraftが公開されている。 Dockercraft Dockercraftの実行方法 1. Minecraftのインストール: Minecraft Minecraftクライアントは改変していないので、公式リリースをそのまま使える。 2. Dockercraftイメージをpullするかビルドする。 docker pull dockercraft もしくは、 git clone git@github.com:docker/dockercraft.git docker build -t dockercraft dockercraft 3. Dockercraftコンテナーを実行する docker run -t -i -d -p 255
うちには 2013 年末ごろからずっと docker コンテナを運用し続けていた物理ホストがあったのだけど、最近 $ docker ps とかしても結果が戻ってくるのに 20 秒ぐらいかかるし、コンテナの起動とかにも同じくらい時間がかかる $ /etc/init.d/docker restart などとしようもんならコンテナが使用可能になるまで 3 時間ぐらいかかってた。とはいえそう頻繁にコンテナを手動で起動したり終了したりするホストではないし、 docker のデーモン自体を再起動するとかは本当に稀なのでずっと放置してたんだけど、さすがに放置できなくなってきた。 $ docker ps --all | wc -l とすると 103781 とかなってて、ゴミコンテナやイメージが大量にありすぎるのが諸悪の根源なのではないかという予想を立てた。 そこでこのようなスクリプトでコンテナを掃除してみ
クックパッド 広告事業部の大野晋一です。責任範囲は広告事業の純広告およびネットワーク広告の商品開発担当で、事業部にはそれぞれの売上でコミットしています。 この記事では、動画変換の仕組みにおけるDockerの活用について紹介します。 クックパッドは8月8日、iOS/Androidのブラウザにおいて動画クリエイティブを掲出する広告商品を公開しました。広告商品としての詳細はプレスリリースやスライドを見ていただくのがわかりやすいのですが、本稿に関係する特徴としてスマートフォンのブラウザで自動的に再生が開始されるというものがあります。 スマートフォンのブラウザにおいては、現在のところ、動画を自動再生させることは出来ません。これはAppleやGoogleといったブラウザベンダが課している制約です。そこで、クックパッドでは、janiというライブラリを使い、特定の規則に基づいて作られた画像を、JavaSc
Built on Docker Swarm, Shipyard gives you the ability to manage Docker resources including containers, images, private registries and more. Shipyard differs from other management applications in that it promotes composability and is 100% compatible with the Docker Remote API. Shipyard manages containers, images, nodes, private registries cluster-wide as well as providing authentication and role ba
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
