#コンテナ

Docker を日常的に使っている人でも、実際にその中身がどう動いているかまで意識する機会は多くありません。今回の元記事は、著者が自作の container runtime を作り始めたところで、Docker の正体が思った以上に変わった仕組みの集まりだと気づいた、という話です。単なる雑談ではなく、普段「当たり前」に見えるツールが、どれだけ Linux の素の機能や妙な工夫の上に乗っているかを、かなり素朴な言葉でほどいています。読み終えると、コンテナが便利な理由だけでなく、なぜ扱いが難しいのかも少し見えてきます。 元記事の著者は、遊び半分で自分の container runtime を作り始めたところ、Docker について「変だ」と感じる発見がいくつもあったと書いています。まず強調するのは、コンテナは VM のような“本当に独立した箱”ではない、という点です。コンテナの中で動くのは結局ただの process で、kernel はその process を普通に動かしています。見ようと思えば `/proc` の中からその process を見つけることもできる。隔離されているように見えて

Linuxでプログラムを隔離したい場面は多いのに、実際には「隔離のための準備」が重くて使わなくなることがある。今回紹介する Drop は、その面倒をできるだけ減らしながら、coding agent や第三者が配布するパッケージを安全に試せる rootless sandbox をうたうツールだ。元の作業環境をなるべくそのまま残しつつ、危ないものだけを閉じ込める発想が中心にある。Docker や Podman とは少し違う立ち位置で、日々の開発作業に入り込ませることを狙っているのが面白い。 Drop のサイトは、まず「Linux sandboxing that doesn’t get in your way」という言い方で始まる。つまり、隔離はしたいが、普段使っている環境から離れたくはない、という開発者向けの問題意識が前提にある。説明によると、Drop は rootless の Linux sandbox で、開発者向けに作られている。隔離したい対象は大きく二つで、ひとつは coding agents、もうひとつは PyPI や npm などから入れる第三者のプログラムだ。 coding

Baseten を inference の提供元として使おうとしていたセキュリティ企業 Strix が、公開されていた Docker/Harbor 系のイメージを自動調査したところ、古い GitHub personal access token を見つけた、というのがこの話の骨子だ。しかもそのトークンは生きていて、Baseten の内部 GitHub リポジトリに対して admin 権限を持っていたとされる。外部サービスを業務に組み込む前に、相手側の足元を自分で点検する。その重要性をかなり生々しく示した事例だと思う。 Strix は自社の自律型ハッキングエージェントを使い、`*.baseten.co` を対象にクレデンシャルなし、ソースコードなしで調査を走らせた。Baseten は推論基盤を提供する企業で、Strix は自分たちのデータやモデル、コードを預ける前に、まず相手のセキュリティを確認したかったという。調査を始めて約25分後、Strix は Baseten の GitHub personal access token を見つけたと主張している。 最初の入口は Harbor とい

オープンソースのWebソフトを、自分で持って動かす。昔は当たり前だったこの感覚が、今はかなり難しくなっています。Cloud in a Bottle は、その壁を下げようとする新しい個人向けクラウド基盤です。単なるホスティングではなく、ログインやアプリ間連携まで含めて「スマホのように使える自分専用クラウド」を目指しているのが特徴です。サービスの仕組みそのものが、いまのソフトウェア環境の偏りをどう変えられるかまで踏み込んでいるので、かなり野心のある発表だと感じました。 このブログ投稿は、Cloud in a Bottle というオープンソースの個人向けクラウド基盤の公開告知だ。書き手の Zack Polizzi 氏は、現代のソフトウェアが広告、追跡、データ販売に寄りすぎていることに強い不満を持っていると述べ、その背景には「ソフトウェアがクラウドに移ったこと」があると見る。クラウド上で動くサービスは、インストール不要で、どの端末からでも使え、共有も簡単だ。その一方で、誰かがサーバー代を払って運用しなければならず、結局は企業が提供するサービスが中心になる。オープンソース作者が無料で世界中にサー

`Copy Fail`（CVE-2026-31431）は、ローカルの未特権ユーザーがroot権限を奪える脆弱性として公開された Podmanのrootless containerでも、この脆弱性でコンテナ内のrootシェルは取れてしまう ただし、Podmanのrootless構成では、ホスト全体への被害はかなり抑えられるのが重要なポイント 理由は、Podmanがuser namespaceとLinux capabilitiesを使って、コンテナのrootをホストrootと切り離しているから とはいえ、`read-only`化、capability削減、使えるコマンドの制限、firewallなど、防御を重ねる設計はやはり大事 コンテナの脆弱性の話は、どうしても「結局、全部危ないの？」で終わりがちです。 でも、Gabriel Garrido氏の記事はそこをもう一段深く掘っていて、Podmanのrootless containerは何が強くて、何が弱いのかをかなり実感しやすい形で説明していました。個人的には、こういう「理屈だけじゃなくて、実際に