‫ディストロレス・イメージについてどう思われますか？
‫サイズとセキュリティのトレードオフが良いのか？
‫ディストロレス・イメージができればということですが､
‫その意味は､ 言葉は流動的なものです｡
‫ディストロの画像は複雑な気がします｡
‫スクラッチ画像と言った方が分かりやすいような気もしますが｡
‫しかし､ ベースとなるパッケージシステムが存在しないという意味で､
‫ディストロ・レス・イメージと呼ぶのが正しいでしょう｡
‫aptはありません｡ Yumがないんです｡
‫公式のイメージを使えば､ コンテナの中に入っていると思われるような､
‫さまざまなコマンドがあるわけではありません｡
‫ディストロレスイメージがあまり一般的でないのは､
‫2つの理由があるからなのです｡
‫1つは､ ほとんどのプログラムが動作するために､
‫それらのすべてが必要であるということです｡
‫これらは､ aptパッケージの依存関係を必要とします｡
‫独自のオープンSSLライブラリが必要なのです｡
‫彼らは､
‫そこにあるプログラムに加えて､ いろいろなものを必要としているんですね｡
‫それが今のほとんどのアプリケーションです｡
‫GolangやC､ その他の言語では､ 基本的にカーネル以外の実行に必要なものをすべて備えた単一のバイナリを構築することができます｡
‫そういうものは､
‫技術的には下のものをすべて取り除くことができるのです｡
‫すべてのレイヤーとあなたのイメージが消えてしまうかもしれません｡
‫私は､ GoogleやNetflixのような超プロフェッショナルな巨大チームと一緒に仕事をしているわけではないので､
‫まだあまり目にしたことはありません｡
‫その理由は2つあります｡ 1つは､ それをサポートする言語が必要なこと､
‫もう1つは､ それらを適切に構築する方法を理解するチームが必要なことです｡
‫それから､ トラブルシューティングやネームスペースのコンテナがどのように機能するかについても､
‫本当によく理解しておかなければなりません｡
‫なぜなら､ そのディストロ・イメージがコンテナで動作して問題が発生した途端､
‫シェルで突っ込むことすらできなくなるからです｡
‫殻がないんです｡ 入りきらない｡
‫見ちゃダメなんです｡ そのため､ 使用できる工具が限られており､
‫工具をコンテナに接続する他の方法を検討しなければなりません｡
‫それが存在する｡ それをやってくれるものもありますが､
‫名前空間をどう扱うかは､ あなたのスキルセットに大きく依存します｡
‫Dockerを使わずに､ コマンドラインからその名前空間の実行中のコンテナにサイドカーとして飛び込むにはどうしたらいいでしょうか｡
‫トラブルシューティングやシステムの監視・保守を行う際に､
‫ディストロ・イメージがあると､ そういった問題が忍び寄るのです｡
‫私が一緒に仕事をする中で､ コンテナを使い始めたばかりの人たちや､
‫コンテナでの最初の2､ 3回のプロジェクトでは､
‫このようなことには触れません｡
‫サーバーのディスク容量はいつでも増やせますからね｡
‫サーバーのディスク容量を減らすために､
‫チーム全員に新しいツールなどを習得させる必要はないのです｡
‫個人的には､ 大きさは気にしません｡
‫セキュリティは机上の空論です｡
‫理論的には､ コンテナ・イメージからこれらのものが取り除かれることで､
‫より安全性が高まるかもしれません｡
‫野良での話をしましょうか｡
‫アプリの外でコンテナ内の他のツールをいじる機会がどれだけあるでしょうか？
‫例えば､
‫cURLに脆弱性があるとして､ あなたのアプリはcURLを使っていないとします｡
‫たまたま画像に写っているだけです｡
‫どうやってアクセスするつもりなんだろう？
‫アプリを突破されるぞ｡
‫だから､ あなたのアプリにはエクスプロイトが必要なのです｡
‫そうすると､ 理論上はコンテナ内でcURLコマンドを実行することができるんですね｡
‫つまり､
‫このディストロ・レスというのは､ 他のアプリケーションを入れないことによる理論的なセキュリティのボーナスということなんです｡
‫しかし実際には､ 静的バイナリをビルドすると､
‫オープンSSL（SSLセキュリティでアプリケーションを接続する一般的な方法）のような脆弱性のあるライブラリがすでに多く含まれているんですね｡
‫まあ､ それが脆弱性を持っていて､ それを静的にアプリに組み込んだとしても､
‫そのままなんですけどね｡
‫ただ､ コンテナ上に別ファイルがあるわけではありません｡
‫バイナリ1つでアプリの中に入っています｡
‫実際､ セキュリティ・スキャンが難しくなっています｡
‫なぜなら､ 私が知る限り､ どのスキャナも､ SSLバイナリが組み込まれていると､
‫それを捕捉できないからです｡
‫つまり､ この多くは理論的なものなのです｡
‫私は､ 理論的なセキュリティ機能をチームに押し付けることはあまりしません｡
‫私は､
‫自然の中で何が起こっているのか､ もっと見ています｡
‫Dockerのデーモンが公開されている｡
‫Kubernetesはちゃんとした認証がないので､
‫バレてしまうんです｡ 私が見た本当の問題は､ 人々がハッキングされていることをニュースで聞き続けていることです｡
‫画像からファイルを削除する際の理論的な安全性を備えたこの種のもの｡
‫それはあくまでも理論的な領域での話です｡
‫やらない理由にはならない｡
‫このリストと同じように､ このリストにあることはすべて､
‫その難しい道に進む前にまずやっておくことです｡
‫ディストロのイメージは比較的ハードに考えています｡
‫あなたがすでにGoプログラマーで､ チーム全体が名前空間やDockerコマンドなどに精通しているのであれば話は別ですが｡
‫普通のDockerコマンドのことではありません｡
‫例えば､ シェルを入れていないコンテナのトラブルシューティングに役立つような複雑なものという意味です｡
‫だから､ いい質問ですね｡
‫よく出てくるんですよ｡
‫セキュリティの話をするときは､ 人気のあるテーマなのでみんな聞いてきますね｡
‫でも､
‫私のベストテンにも入っていないんですよ｡
‫お役に立てれば幸いです｡