Kubernetes基盤における開発者体験 とセキュリティの両⽴ 1 Kubernetes Novice Tokyo #40 ~ 共通Helmチャートで実現するPlatform Engineering ~ 

2 ⾃⼰紹介 SIer にてアプリケーションエンジニアとしてキャリアをスタート。ToBのSaaS企業 でのSRE組織の⽴ち上げを経て、2024年10⽉より株式会社ログラスに参画。 現在は共通基盤部にて、開発組織への SRE の推進およびプラットフォーム開発に取 り組んでおり、SRE を⽂化として根付かせることをテーマに活動しています。 株式会社ログラス SRE ⾒形 親久∕mekka Chikahisa Mikata∕https://x.com/melpo_mel 

3 

No content

No content

No content

Kubernetes基盤における開発者体験とセキュリティの両⽴ 7 • 課題: K8sマニフェストの複雑さと属人化 • どう作ったか : 共通Helmチャートの設計思想 • どう守っているか : SSOT + CI による品質担保 今日お話しすること 

8 開発チームが抱えていた課題 Kubernetes基盤における開発者体験とセキュリティの両⽴ 課題 影響 K8sマニフェストの学習コストが高い デプロイまでのリードタイムが長い セキュリティ設定が属人的 サービスごとに品質がばらつく YAML定義が巨大で見通しが悪い レビュー負荷が高くミスが入り込む 目指す姿: 開発者はアプリの設定だけに集中し、基盤側がセキュリティ・運用をガードレールとして提供する 

Kubernetes基盤における開発者体験とセキュリティの両⽴ 9 • ArgoCD App-of-Apps + ApplicationSet でデプロイを自動化 • テンプレートリポジトリ（基盤チーム管理）とサービスリポジトリ（開発チーム管理）の2リポジトリ構成 GitOps アーキテクチャ概要 

Kubernetes基盤における開発者体験とセキュリティの両⽴ 10 なぜ1つの巨大チャートにしないのか • 役割ごとにチャートを分割 → テンプレートの可読性・保守性が向上 • 全チャートが common ライブラリに依存 → セキュリティ・監視・スケジューリングを共通化 • サービスが必要なチャートだけを組み合わせて利用 例: Web API → base + stateless 例: バッチ処理付き → base + stateless + workflow + migration 例: イベント駆動 → base + stateless + events 共通チャートの設計 : チャート分割による関心の分離 

11 チャート構成と各チャートの役割 Kubernetes基盤における開発者体験とセキュリティの両⽴ チャート 役割 主なリソース common 全チャート共通の基盤 SecurityContext, Labels base サービスの土台 ServiceAccount, NetworkPolicy stateless 常駐アプリ（ステートレス） Deployment, Service, Ingress stateful 常駐アプリ（ステートフル） StatefulSet, Service, Ingress workflow バッチ・定期ジョブ WorkflowTemplate events イベント駆動処理 EventSource, Sensor migration DBマイグレーション Workflow, WorkflowTemplate 

12 commonライブラリ : 全チャート共通の基盤 Kubernetes基盤における開発者体験とセキュリティの両⽴ 機能 内容 SecurityContext 非root, readOnlyFS, drop ALL, seccomp Datadogアノテーション APMライブラリ自動注入（Java/Python/JS） スケジューリング TopologySpread, Affinity, Tolerations の自動設定 共通ラベル app.kubernetes.io/, platform.loglass.com/ 開発者が何も指定しなくても、全Podにセキュリティとオブザーバビリティが適用される構造 commonはライブラリチャートとして実装、named templateで共通設定を定義し各チャートから呼び出す 

13 組み込みセキュリティ : Secure by Default Kubernetes基盤における開発者体験とセキュリティの両⽴ レイヤー 仕組み 内容 Namespace Pod Security Admission restricted enforce Network NetworkPolicy 同一NS + Istio + Datadog のみ許可 Pod SecurityContext 非root, readOnlyFS, drop ALL, seccomp セキュリティ設定を「忘れる」ことが構造的に起きない 必要に応じてオーバーライドは可能（権限的に厳しい場合など） 3層のセキュリティが全Podに自動適用 

Kubernetes基盤における開発者体験とセキュリティの両⽴ 組み込みセキュリティ : Secure by Default 14 

Kubernetes基盤における開発者体験とセキュリティの両⽴ 15 statelessの最小構成のサンプル SecurityContext, NetworkPolicy, Datadog, TopologySpread ... 全て自動適用 Deployment, Service, Pdbなどの必要リソースを生成 開発者が書く YAMLはこれだけ 

Kubernetes基盤における開発者体験とセキュリティの両⽴ 16 品質担保 (1): なぜ独自のスキーマ管理を選んだのか Helmの既存プラグインの課題 • アノテーションやコメントの構造が使いにくかった • description や additionalProperties の表現力が不足している values.schemaをyamlにして管理 • JSONよりはマシ（誰かアイディアあったら教えて） • additionalProperties: false で開発者管理キーを厳密に定義 • SRE管理はtype: objectのみといった調整が出来る 

Kubernetes基盤における開発者体験とセキュリティの両⽴ 17 品質担保 (2): SSOT からの自動生成パイプライン • 開発者はこのテンプレートをコピーして値を 埋めるだけ • required / optional がコメントで明示 → 何 を書くべきか迷わない • CIで make generate + git diff --exit-code → 生成物の同期漏れを自動検出 

18 品質担保 (3): templatesリポジトリの CI Kubernetes基盤における開発者体験とセキュリティの両⽴ テストパターン 内容 Full 全機能ONでリソース数・フィールド値を検証 Minimal 最小構成でオプション機能が含まれないことを確認 Split Values 分割values と 結合values の出力一致を検証 CIパイプライン（ PR時に自動実行） 1. make generate + git diff → 生成物の同期チェック 2. Helm テスト（Full / Minimal / Split） 3. kubeconform → K8s/CRDスキーマ適合性チェック 4. Trivy → セキュリティスキャン（CRITICAL/HIGH） 5. 失敗時 → Slack 通知 チャートのテスト（ 3パターン） 

19 品質担保 (4): servicesリポジトリの CI + ローカル検証 Kubernetes基盤における開発者体験とセキュリティの両⽴ CIパイプライン（ PR時に自動実行） 1. 変更検出 → 影響するサービス×環境を自動特定 2. helm lint + template + kubeconform + trivy を並列バリデーション 3. 失敗時 → PRコメント + Slack 通知（サービスチームへ） 開発者のローカル検証 • scripts/validate.sh [component] • helm lint → template → kubeconform → trivy を一括実行 • CIと同じ検証をローカルで再現できる 

20 品質担保: 2つのリポジトリを横断する CI Kubernetes基盤における開発者体験とセキュリティの両⽴ 

21 まとめ Kubernetes基盤における開発者体験とセキュリティの両⽴ 開発者体験 セキュリティ アプリ設定だけ書けばデプロイ可能 全Pod に Secure by Default チャートを組み合わせるだけで構成完了 PSA + SecurityContext + NetworkPolicy の3層防御 ローカルで事前検証 → 安心してPR セキュリティを「忘れる」ことが構造的に不可能 共通Helmチャートで実現したこと レイヤー 仕組み スキーマ 全機能ONでリソース数・フィールド値を検証 テスト + 検証 Full / Minimal / Split テスト + kubeconform + Trivy をCI両方で実行 CI templates / services 両リポジトリで独立したパイプライン SSOT + CI による品質担保 

22 

23