docker.io/Bitnami の削除

• Bitnami チームは、docker.io/bitnami 公開カタログの削除時期を 9月29日 に延期した
• 削除前にユーザーの移行を支援するため、複数回の ブラウンアウト（一部イメージの一時遮断） を実施する予定
• 今後、Bitnami の コンテナイメージと Helm チャート は、強力なセキュリティ機能を備えた Bitnami Secure Images(BSI) または Bitnami Legacy Registry に移行される
• BSI イメージは開発・テスト用途では無料で提供されるが、全イメージと長期サポートが必要な場合は 有料サブスクリプション が必要
• オープンソースのサプライチェーンセキュリティおよび規制変更への対応のため、従来方式からの移行が必要になっている

---

Bitnami docker.io 公開カタログ削除のスケジュールと対応案内

更新

• Bitnami チームは、コミュニティの意見と影響評価 を踏まえ、docker.io/bitnami 公開カタログの削除時期を 2024年9月29日 に延期した
• レジストリ削除に先立ち、ユーザーが変更を認識できるよう ブラウンアウト（一部コンテナイメージを24時間一時遮断） を 3 回実施する予定
  • 8月28日 08:00 UTC ～ 8月29日 08:00 UTC
  • 9月2日 08:00 UTC ～ 9月3日 08:00 UTC
  • 9月17日 08:00 UTC ～ 9月18日 08:00 UTC
• 各ブラウンアウトで影響を受けるイメージは当日に告知予定
• 8月28日以降、Bitnami のコンテナイメージおよび Helm chart は Docker Hub に新形式（OCI）ではこれ以上配布されない
• コンテナおよび Helm chart のソースコードは GitHub で Apache 2.0 ライセンスのもと継続して提供される

変更内容

• 8月28日から Bitnami は既存の OCI レジストリ（chart と image） を Bitnami Legacy に移し、その後はセキュリティを強化した新しいイメージへ移行する

• 現在のイメージを利用している場合、自動化パイプライン・内部ミラー・Kubernetes クラスターの イメージ Pull パス を新しい場所へ変更する必要がある

• ユーザーが選択できるオプション

  1. Bitnami Secure Images(BSI) へ移行
  2. Bitnami Legacy Registry へ移行（一時的）

• システムの継続性と機能維持のため、Bitnami Secure Images(BSI) への移行を推奨 している

• BSI を利用すると、強化されたイメージ によってセキュリティおよびコンプライアンス対応力が向上する利点がある

Bitnami Secure Images(BSI) への移行

• 一部の BSI イメージは開発およびテスト用途では無料で提供されるが、全カタログ・安定タグ・長期サポート版などは 有料サブスクリプションで利用可能
• BSI サブスクライバーは今後も Bitnami の Debian ベース全イメージカタログ と更新を受け取れる
• さらに強化された Photon Linux ベースのイメージ へのアップグレードと移行が推奨されている
  • 既存の Debian イメージと互換性があり、Helm chart も同様に利用可能
• Photon ベースイメージの主な利点
  • CVE 件数を大幅削減（100件超→0件の事例もあり）
  • VEX 診断対応、KEV/EPSS スコア連携 により脆弱性管理が容易
  • 強力なレポートおよびメタデータ機能を備えた セルフサービス UI/API
  • 攻撃対象領域を 83% 削減した distroless chart など高度な Helm chart をサポート
  • SLSA 3 準拠（サプライチェーンセキュリティ標準）のソフトウェアファクトリーでビルドイメージのカスタマイズが可能
  • 顧客専用のプライベートセキュア OCI レジストリ を提供（Docker Hub と異なり Public/Rate limit の影響なし）
  • 90種類以上の OVA 形式 VM イメージ を利用可能
  • パッケージングおよびインストール関連のエンタープライズサポート

Bitnami Legacy Registry への移行

• 暫定策として既存の Bitnami ユーザー向けに Bitnami Legacy Registry を提供する
  • サポート対象外のアーカイブ形式イメージである（セキュリティパッチなどは適用されない）
  • 長期提供の予定はなく、早期に 脆弱性の蓄積と老朽化 が懸念される
  • 一時的に利用する場合は、必要なイメージを別途 自前のレジストリへコピー することを推奨
  • 根本的には新しいセキュリティ強化システム（BSI）への迅速な移行が必要

オープンソースのサプライチェーンセキュリティとコンプライアンス移行の必要性

• 最近のオープンソース環境の変化と 悪意あるパッケージの急増（2019～2023年の Sonatype 基準で 245,000 件以上）が主な背景
  • これはそれ以前の全期間の 2 倍水準
• AI/モデル生態系の成長とともにオープンソース活用が大きく増えており、攻撃対象領域とリスクも拡大 している
• Cyber Resilience Act(EU) のような規制により、オープンソースソフトウェアの出所と完全性に対する 立証責任 が生じつつある
• Bitnami Secure Images の導入により、組織は サプライチェーンセキュリティとコンプライアンス を容易に確保できる環境を得られる
  • 低い TCO（総保有コスト）で セキュリティ・規制対応コストの負担を軽減
  • 複雑化したオープンソースソフトウェア環境を堅牢に管理できる基盤を整備

Bitnami の変更に対する競合他社の主張

• 一部の競合他社は、Bitnami が「無料の公開イメージと Helm チャートをなくす」という誤解を招いている
  • 実際には Helm chart は引き続き Apache 2 ライセンス で GitHub 上に公開 される
  • 変更の核心は OCI アーティファクト（ビルド済みイメージ）にある
  • 大規模なビルド・配布パイプライン、レジストリ運用コストは非常に大きく、低コスト供給は不可能
  • Helm chart ソース（Debian イメージを含む）は誰でも無料でアクセス可能
• 企業が OCI ビルド済みイメージを直接必要とする場合は、BSI サブスクリプション を通じてサポートを受ける必要があり、これは セキュリティ向上と戦略的 OSS 活用 を確保する手段である

8月28日以降の具体的な移行方式

• 8月28日から Bitnami repo は イメージの段階的整理 を開始し、すべての移行作業が一括で発生するわけではない
• 数週間にわたって段階的にイメージ削除・移行を進め、ユーザーの混乱を最小化する方針
  • 84TB に及ぶ大規模 OCI コンテンツの処理のため、どのイメージがいつ削除されるかは具体的に不確実
  • 8月28日以降、基幹業務機能に必要なイメージについては 代替レジストリの準備が必要
• 新しい Bitnami レジストリには、強化された Photon イメージが以前の Debian イメージと 同じ名前 でアップロードされる予定
• 既存ユーザーおよび新規ユーザーは、セキュリティ強化イメージによって最新のオープンソース環境要件に対応できる
• Bitnami FAQ で移行に関する詳細情報を確認できる

[jic5760]

コミュニティ内で Bitnami を継続するため、昨日 Bitmoa を作りました。
目標は、最小限の変更（ENV 程度）で bitnami イメージを置き換えることです。

https://github.com/bitmoa/containers （GH Actions でイメージをビルド）
https://github.com/bitmoa/charts

[GN⁺]

Hacker Newsのコメント

• 公開ソフトウェアを「パッケージ化」しているだけで貢献はせず、Oracle流に商用化へ転換しようとしているのは少し驚きではあるが、彼らの仕事を貶める意図はない、実際に著作権を主張できる部分がどれほどあるのかは疑問で、大半のパッケージは数行の組み立て手順にすぎず、実質的には make build のようなコマンドラインに著作権をかけようとしているようにも見える、そして生成されたバイナリの配布もオープンソースライセンスであるなら、ユーザーはソースコード、ビルド方法、再配布の権利をすべて持てるべきだ
  • Bitnamiが作ったMakefileなどはかなりの労力が入った部分であり、さまざまなソフトウェアを環境変数だけで使えるようにする作業は決して簡単ではない、サンプルリンク は参考になる、現時点では一部のユーザー層にとって商用ライセンスは十分価値がある
  • 実際にはより重要な価値はHelm chartsにある可能性が高い、ただし公式イメージがすでに代替として出ているため、あえてBitnamiのNodeやPostgresイメージを使う理由は特になく、大半の人が実際にどれだけBitnamiのHelm chartsを使っていたのかは疑問だ
• Bitnamiが提供していた hardened images は goodwill のしるしであり、本当に必要な場所で最初の一歩を踏み出させる役割を果たしていた、しかし市場のより良い選択肢とは競争できなかった、この「サブスクリプション」への転換は解決策ではなく、まるで押し売りのようだ、Terraform Cloudがやったのと同じで、あちらも最近の状況はよくないと思う、Bitnamiの貢献は実質的にconfigオプションを少し入れる程度にすぎず、OperatorFramework capability で見ればせいぜい level 2 ないし 1 程度だ 参考リンク
  • Bitnamiが無料で提供していたものを今やめるだけで、ユーザーが代替を探さなければならない状況を「押し売り」と表現するのは行き過ぎだと思う、無料でやってくれていたこと自体、感謝に値する
  • 無料で配っていたものをやめるからといって押し売りだというのは極端な表現だ、今後は自分でやることが増えて残念だという感情が残るだけだ
  • Broadcomがどういう会社か混同があるようだ、Broadcomは「長期的な健全性」に関心のある企業ではない、製品を買収すると従業員の90%を解雇し、ライセンスとサポート費用を2〜100倍に引き上げる、Fortune 500企業が簡単には外せない性質を利用して5年程度の契約で継続的に金を吸い上げる、市場の反発も気にせず、法的に争われても結果として値上げの効果が残ればよいという戦略だ
  • 2025年には、インフラ企業としてまず開発者の間で人気を築いてから売上につなげる戦略は通用しない、最初から売上を作らなければならず、結局はエンタープライズ市場だけがターゲットになる、皆がその狭い市場を取り合って競争している構図だ
  • 彼らが追加した価値はごく小さいが、それですら今や代替しづらくて苦労しているユーザーがいるなら、それが何を意味するのか考えるべきだ
• 結局はCSR（企業の社会的責任）のためでもあり、CSRによって可能になる転換でもある、EU Cyber Residence Act規制によってオープンソース生態系が大きく変わる可能性がある、今後は商用でオープンソースベースの商品を提供する会社はセキュリティと文書化の規定を厳格に守らなければならず、純粋なオープンソースプロジェクト自体は対象外でも、有償で配布すれば法的負担が生じる、結局はコンプライアンスフレームワークをサービスとして売ることが新しい機会に見える
  • CSRのために必ず有料のセキュアなイメージだけを供給しなければならないわけではない、その気になれば無料で提供してもよいし、商用向けだけ有料にしてもよい
  • 商用としてオープンソース＋サービスを売るなら、CSRに合わせたコンプライアンス作業は必須だ、結局オープンでも商用でも同じ努力が必要になる
• 代替が必要なら、TwistlockチームがMinimusをローンチしている、ソースから直接ビルドし、ほとんど脆弱性のないイメージを継続的に供給している、Bitnamiと同じく drop-in replacement も提供している、使い方・ツール・顧客事例など気になる点があればいつでも質問歓迎、比較と案内の投稿 を参照
  • Minimusの登録フォーム は「個人」と「組織」を区別しているのに会社名の入力が必須なのはおかしい、マーケティング目的にしか見えない
  • ブログでのMinimusとBitnami Secure Imagesの比較事例をもう少し分かりやすく整理すると、Bitnami Secure ImagesはPhotonベースでビルドされ、脆弱性や新バージョンのリリースがあれば自動でビルド・テスト・配布され、ユーザーは最新版だけを使えばよいので、CVE監視の心配や手動パッチの必要がない
  • 価格が最大の論点だ、ChainguardやDocker secure imagesも価格を聞いて興味を失った、Minimusの価格情報はWebサイトのどこにもなく、おそらく多くの人には使えないほど高いのではないかという疑念が湧く
  • MinimusがOSなのか気になる、Bitnamiは依然としてオープンソースプロジェクトとして、ソースから直接イメージをビルドできる
  • Minimus側で docker-credential helper を直接実装し、Chainguardの docker-credential-cgr を参考にして提供してくれるとよい、ただ「dockerはcredential storeをサポートしているので各自で対応してほしい」という案内だけで終わらせないでほしい リファレンス
• ライセンス費用を見ると年間 $50,000 以上なので、自分のターゲット市場ではない
  • 公式説明には「BSIがオープンソースのセキュリティとコンプライアンスを民主化する」と書かれているが、$50,000 でも決して「民主化」と言える水準ではないと思う
  • 用語はやや混乱を招くが、実際には無料で提供していたさまざまなイメージを有料へ移行している、Dockerファイルは依然として入手でき、Docker Hubのイメージも使えはする、ただし無料提供分は「開発用」（production目的では制限あり）で、本当の「secure」イメージはPhoton OSでビルドされ、セキュリティプロセスも通る、提供サービス以外を禁止しているわけではない
  • 既存ユーザーベースをアップデートなしで放置したまま収益化する最も簡単な戦略だ、少し滑稽でもある
• ほぼ2年前、エンタープライズ環境でBitnamiから移行するよう勧めたおかげで、ちょうど今ごろそのプロジェクトが終わる時期になっており、見立てが当たったという満足感が大きい
• VMwareのライセンス変更と合わせて、BroadcomがOracleのポジションを狙っているのは明らかに見える、最近競争が激しくなっているのは残念だ
  • BroadcomがSpring生態系をどう収益化するのか楽しみ（？）にしている、実際ほとんどの大企業がSpringを使っているので、そのうち必然的に起きることだと思う
  • Broadcomは実際にはAvago Technologiesが2015〜2016年に名前だけを取得して使っているもので、本来のBroadcomの事業領域とIPはすでに大半が売却されている
  • Broadcomが実際にどれほど「えげつない」かを知れば、この件自体は大したことではないように感じるかもしれない、それでも当面はユーザーにとって利益になる可能性もある
  • Bitnamiのエンジニアのかなりの部分は、こうした決定に全面的に賛成しているわけではないと思う
  • Microsoftが存在する限り、BroadcomやOracleなどは「悪のランキング」2位を争っているようなものだ
• ソフトウェアプロジェクトは、(1) 自分で管理するか金を払って保守するコード、(2) いつか互換性のないバージョンに置き換えなければならない雑多なコード、のどちらかで構成される、雑多なコードをつなぎ合わせるのも十分に賢い賭けではあるが、依存関係のソースが他社のものなら、彼らが半永久的に保守してくれると期待してはいけない、そのプロジェクトのライフサイクルは依存関係より短いと見込んでこそ本当のリスク管理になる
• Broadcomがモバイル向けのパディングすらまともにできないのは残念だ、ともあれ docker.io/bsi を別に作り、/bitnami は旧バージョンのまま残しておけば壊れるものはないので、ユーザーも自分で移行できる、アップグレードできない理由も自然に案内できる
  • Bitnamiが無料のセキュリティアップデートをやめる意思を示すなら、ユーザーが自分でリスク受容に同意できるようにすべきだった、十分な事前告知のうえで /bitnami を /bitnamilegacy に移す程度でもよい方法だった
  • 「bitnami」という名前自体にブランド価値があるので、新サービスを売る際にもこの命名を使い続けるのはビジネスとして理にかなっている
  • Broadcomのパディング問題は、RallyのUIデザインが古すぎることと同じ文脈に感じる
• Bitnamiのイメージやパッケージの慣習がどうにも理解できない、実際に使ってみると複雑すぎて、カスタムルールが煩雑で好みではなかった、普通のベースによるシンプルなパッケージではなく妙な構造になっていて、何かを変えようとするとまさに混沌そのものだ
  • 彼ら独自のルールを大量に持ち込み、複雑なスクリプトを載せていて、どのイメージも個別のドキュメントを読まないと使えない、標準の公式ドキュメントとも一致しないのでつらかった
  • 以前はrootlessで動くベースイメージを簡単に手に入れるためにBitnamiイメージを使っていた、昔は公式リポジトリでpostgresなどをrootless設定にするのが難しかったためだ、ただBitnamiイメージごとにuidやconfigパスなどが違い、毎回Dockerfileを逐一読まなければならなかった
  • BitnamiはもともとWindowsでWordpressを動かす用途で人気があった、Windows Serverですぐ使えるようにしてくれたので当時は有用だった、今そのやり方で仕事をしていたら解雇ものかもしれないが、当時はLinuxの普及が遅れていたので必要なサービスだった
  • こうしたパッケージング慣習の参考になるリソースがあるのか気になる、多くの場合はプロジェクト公式イメージをベースに各自でカスタムして自前のイメージを作るのが慣行のように感じる