Ivan on the Server Side¶

チェック¶

[ ] 本文を確認した
[ ] 概要を確認した
[ ] タグを確認した
[ ] inbox/ 直下へ移行した

概要¶

iximiuz Labs のニュースレター。中心は Docker roadmap の第2モジュール完了で、container image build を学ぶ重要性が語られている。後半では、iximiuz Labs の Daily Practice、labctl ide、HTTP/HTTPS port scanning、コミュニティ教材、Kubernetes hands-on challenge、Docker/OCI、microVM、Agent Sandbox、CI/CD supply chain 攻撃、dependency cooldown などの技術リンクが紹介される。単発記事というより、コンテナ、Kubernetes、セキュリティ、学習教材の月次まとめとして保存する。

本文¶

ニュースレターの冒頭では、Linux、Docker、Kubernetes、networking の実践課題を 100 以上作ってきた筆者が、もっとも関心を集めにくいテーマは container image build だと述べている。しかし、関心が薄いからこそ、多くの image が肥大化し、CVE を含んだままになる。

開発者は、本番で image が大きく脆弱であることの痛みを直接感じにくい。一方、SRE や DevOps 側は、Node.js、Python、Go などの application stack に深く踏み込みづらく、Dockerfile の改善提案に自信を持てないことがある。

ここに機会がある。開発者が Linux と Docker を少し学べば、image build の相談先になれる。 SRE/DevOps が application stack に踏み込めば、release pipeline が詰まる前、本番で問題になる前に Dockerfile で直せる。

Docker roadmap の第2モジュール¶

iximiuz Labs の hands-on Docker roadmap の第2モジュールが完成した。このモジュールは container image build に焦点を当てている。

構成は次の通り。

28 hands-on challenges
6 tutorials
2 skill paths

学習は、既存 Dockerfile から image を build するところから始まる。その後、Node.js、Go、Python の簡単な Dockerfile を書き、system dependency と application dependency を入れ、docker build 中に app を compile し、multi-stage build で image を最適化する。さらに foreign CPU architecture への対応や production-ready image の作り方まで進む。

roadmap は手を動かすことに強く寄っているが、OCI Image Spec や container image を支える Linux の基礎にも触れる。単なる Dockerfile 書き方集ではなく、image の内部構造を理解するための教材として位置づけられている。

Daily Practice¶

iximiuz Labs の dashboard に Daily Practice が追加された。 Linux、Networking、Docker、Kubernetes の主要カテゴリから、それぞれ最大1つずつ daily challenge を提案する。合計で最大4つ。

目的は、次に何を解くか選ぶ摩擦を減らすこと。また、challenge を解くと daily usage time が増える仕組みや、最初の10 challenge で Premium access が得られる仕組みも紹介されている。

labctl ide¶

labctl ssh-proxy --ide のような workaround の代わりに、新しい labctl ide command が紹介されている。

Go development sandbox を起動し、repository を clone し、local VS Code をその repo に向けて開く例。

PLAY_ID=$(labctl playground start golang)
labctl ide code "$PLAY_ID" --repo https://github.com/iximiuz/kexp

クラウド上の playground とローカル IDE をつなぐことで、browser だけでなく普段の editor から実験環境を扱える。

HTTP/HTTPS port scanning¶

VM resident agent に HTTP/HTTPS port scanning が入った。 playground 内で開いている HTTP/HTTPS port を検出し、Expose Port UI で候補として表示する。

CLI からは labctl expose port --scanned により、検出された port をまとめて expose できる。 Web app や debug UI を立ち上げたとき、どの port を公開すべきか探す手間が減る。

コミュニティ教材¶

コミュニティ教材として、Uncloud で Django web app を複数 VM に deploy する tutorial が紹介されている。単一 host Docker Compose では足りないが、Kubernetes は過剰という場合に、Uncloud は軽量な中間案になる。

また、Tailscale と Cilium を使い、複数の iximiuz Labs playground を overlay network でつなぎ、その上に Kubernetes cluster を作る実験も紹介されている。複数 VM、overlay network、Kubernetes、microservice traffic visualization を組み合わせた学習例として扱われている。

Log Parser Playground は、Nginx access log や syslog のような現実的な log format を使い、Linux command-line で parsing 練習をする playground。

Omakub remote desktop playground では、Apache Guacamole や RDP client で GUI 環境に接続できる。 remote Chrome と coding agent を同じ playground に置く用途にも触れられている。

Kubernetes challenge 一覧¶

CKA/CKAD/CKS の練習として、Kubernetes hands-on challenges が追加されている。扱う内容は次のようなもの。

Deployment の rolling update と rollback。
Pod を特定 Node に手動 schedule する。
static Pod の lifecycle 管理。
ResourceQuota 下で Guaranteed QoS Pod を作る。
CPU/Memory target を使った HPA 設定。
VPA recommendation を読んで OOMKilled を解決する。
Node affinity を使って PV を特定 Node に結びつける。
ResourceQuota と LimitRange による namespace resource 制御。
ConfigMap 作成失敗の debug。
immutable container の強制。
ServiceAccount token automount の無効化。
RBAC で Secret への access を制限する。
RBAC permission failure の troubleshoot。
deprecated API を kubectl-convert で修正する。

実務運用でも試験対策でも使える基礎問題が並んでいる。

Good technical reads¶

技術リンクのセクションでは、まず Docker container の10年を振り返る記事が紹介される。 Linux capabilities が Docker/OCI container を成立させたこと、非 Linux platform でどのように user experience を再現しているかを説明する technical recap として扱われている。

次に、container は sandbox ではないという記事。 Firecracker、Cloud Hypervisor、QEMU、libkrun、crosvm などの microVM ecosystem を扱い、container の isolation は強い security boundary ではないと整理する。信頼済み multi-tenancy では十分な場合もあるが、AI agent や未検証の AI-generated code のような rogue workload では microVM を検討すべき、という文脈。 container を捨てるのではなく、microVM の中で container を使うという方向が示される。

Kubernetes の Agent Sandbox も紹介されている。 agent は Pod で実行できるが、composition、scaling、identity 要件が従来の stateless service とは違う。 Sandbox CRD は、gVisor や Kata Containers による隔離、warm pooling による起動高速化、stable identity を持つ新しい deployment primitive として見られている。

AI/CI/CD supply chain security¶

Clinejection では、issue triage の AI automation workflow を prompt injection で悪用し、より重要な release workflow へ横展開した事例が紹介されている。直接重要 token を盗むのではなく、GitHub Actions cache を汚染し、後続の release workflow がそれを再利用することで、悪意ある VS Code extension が配布された。

Trivy の GitHub Actions tag compromise も紹介されている。 vulnerability scanner 自体が CI/CD secret を漏らす経路になり得るという皮肉な事例であり、software supply chain の弱さを示す。

これらの話から、未検証 code や agent をどこで実行するか、CI/CD workflow に何を許すか、sandbox をどう設計するかが重要になる。

dependency cooldown¶

Package Managers Need to Cool Down では、新しい package version が出た直後にすぐ upgrade しない考え方が紹介されている。 npm outdated などで新 version が見えても、release notes や互換性だけでなく、その release が正当なものか、account compromise ではないかを確認する。確認する時間がないなら、一定期間待ち、他者が問題を見つける時間を置く。

npm security best practices では、npm、pnpm、yarn などで cooldown period を設定するベストプラクティスも紹介される。

読み替え¶

この newsletter は、container image build、Kubernetes practice、agent sandbox、microVM、CI/CD supply chain 攻撃、dependency cooldown が一つながりで見える。特に AI agent の普及により、未検証 code をどこで実行するか、container を sandbox と誤解しないこと、CI cache や dependency update をどう守るかが重要になる。

要点¶

container image build は関心が薄いが、肥大化と CVE の原因になりやすい。
Docker roadmap 第2モジュールは、Dockerfile、multi-stage build、multi-arch、OCI image internals を hands-on で扱う。
labctl ide により、playground と local VS Code をつなげる。
HTTP/HTTPS port scanning で、playground 内の web port を expose しやすくなった。
Kubernetes challenges は CKA/CKAD/CKS 対策にも実務練習にも使える。
container は sandbox ではなく、危険な workload には microVM や Agent Sandbox のような隔離が必要になる。
AI workflow と GitHub Actions cache は supply chain attack の経路になり得る。
dependency は出た直後に飛びつかず、cooldown を置く運用が有効。

タグ¶

docker #kubernetes #linux #security #supply-chain #learning¶