
ブログ
HOME Developer Square ブログ 【SCSK技術者によるブログ】生成AIでSysdigエージェントのアップグレードを効率化 〜Helm values.yamlの移行作業を自動化〜
【SCSK技術者によるブログ】生成AIでSysdigエージェントのアップグレードを効率化 〜Helm values.yamlの移行作業を自動化〜
みなさん、こんにちは! SCSK技術者によるSysdigブログ、第30回は鳥飼が担当します。今回は、Sysdigエージェントのアップグレード時に手間のかかるvalues.yamlの更新作業を、生成AIに任せるアプローチを検証してみました。
生成AIに関する過去の記事もぜひご覧ください
【SCSk技術者によるブログ】システムコール分析における生成AIの活用
https://www.scsk.jp/sp/sysdig/blog/scsk/sysdigai.html
【SCSk技術者によるブログ】生成AIで過検知対策を効率化!Sysdig Sageの実力検証
https://www.scsk.jp/sp/sysdig/blog/scsk/scskaisysdig_sage.html
※本記事における注意事項
- 本記事の検証結果は、お客様の環境によって異なる場合があります。
- AIによる分析結果はあくまで参考情報としてご活用いただき、最終的な判断は必ずご担当者様にて実施してください。
背景: Sysdig AgentのアップグレードとHelm
Kubernetes環境へSysdig Agentをインストールする際には、アプリケーションのデプロイ管理に広く使われているHelmを利用します。HelmはKubernetesのパッケージマネージャーであり、アプリケーションのデプロイ、バージョン管理、構成管理を容易にするツールです。いくつかのコマンドで簡単に操作でき、GitOpsパイプラインにも統合できる点が大きな特徴です。
Sysdigでは、Helmチャートを通じて、コマンドラインでパラメータを渡す、またはvalues.yamlという設定ファイルにパラメータを記述することで、機能の有効化や構成のカスタマイズを行います。
アップグレード時の課題
Sysdig Agentのアップグレードも、インストール時と同様にHelm経由で行います。 ここで課題となるのが、Helmチャートのバージョンアップに伴うvalues.yamlの変更作業です。
Sysdigでは頻繁に機能改善や新機能のリリースが行われ、それに伴いvalues.yamlで利用できるパラメータも追加・変更・削除されます。そのため、アップグレード時には、現在利用しているvalues.yamlと新バージョンのvalues.yamlの差分を確認し、既存のカスタム設定を維持しつつ、新しい形式に書き換えるという作業が発生します。
この作業を手作業で行うとかなりの工数がかかるだけでなく、設定の記述ミスや、変更点の見落としといったヒューマンエラーが発生するリスクも高まります。
解決策: 生成AIによるvalues.yamlの移行
この課題を解決するため、一連の移行作業を生成AIに任せる方法を試しました。 Sysdigをご利用のお客様の多くは、バージョン管理の観点からvalues.yamlファイルで設定を管理されています。そこで今回は、このvalues.yamlファイルを更新するケースを対象に検証を行いました。
検証の準備
今回の検証で用意したものは以下の通りです。
- 旧バージョンのデフォルトvalues.yaml (本検証では sysdig/shield v1.0.0 を利用)
- 新バージョンのデフォルトvalues.yaml (本検証では sysdig/shield v1.15.2 を利用)
- 現在利用しているカスタムvalues.yaml (v1.0.0ベースでカスタマイズしたもの)
- 生成AIモデル (AWS BedrockやAzure OpenAI Serviceなど複数のモデルで比較検証し、今回は最も期待する結果を得られた Gemini 1.5 Flash を選定しました)
※values.yamlの元ファイルは、以下のSysdig公式GitHubリポジトリから取得できます。
https://github.com/sysdiglabs/charts/blob/main/charts/shield/values.yaml
検証: プロンプトの設計と実行
具体的な手順は、後述するプロンプトを用意し、生成AIに実行を依頼するだけです。 今回は、sysdig/shieldチャートのv1.0.0からv1.15.2へのアップグレードを想定して、以下のプロンプトを使用しました。
生成AIに投入したプロンプト:
役割
あなたはSysdigとKubernetesのHelmチャートに精通したSRE(Site Reliability Engineer)です。Helmチャートのバージョンアップに伴うvalues.yamlの移行作業を専門としています。
背景
私たちはSysdig Shieldを運用しており、現在Helmチャートのバージョン v1.0.0 を使用しています。この度、v1.15.2 へとバージョンアップを計画しています。 私たちは、自社環境に合わせてvalues.yamlをカスタマイズして運用しているため、このカスタム設定を維持したまま、新しいバージョンのvalues.yamlに移行する必要があります。
指示
以下の3つの情報に基づいて、v1.15.2に対応した、私たちのカスタム設定が反映された新しいvalues.yamlを生成してください。 可視性を高めるため、feature以外でデフォルトの値を利用しているパラメータは削除してください。 また、移行に伴う注意点や推奨事項があれば、合わせて報告してください。
入力情報
1.旧バージョン (v1.0.0) の values.yaml
yaml # (v1.0.0のvalues.yaml全文をここに貼り付け) cluster_config: ...
2.新バージョン (v1.15.2) の values.yaml
yaml # (v1.15.2のvalues.yaml全文をここに貼り付け) cluster_config: ...
3.私たちのカスタム values.yaml (v1.0.0 ベース)
yaml # (カスタマイズしたv1.0.0のvalues.yaml全文をここに貼り付け) cluster_config: name: trk-test-cluster-20250806 ...
生成AIからの回答
上記プロンプトを実行した結果、以下の回答が得られました。カスタマイズした設定が新しいvalues.yamlに正しく反映されているだけでなく、移行に伴う注意点まで詳細にレポートしてくれました。
生成AIによる回答結果:
SREとして、Sysdig Shield Helmチャートの`v1.0.0`から`v1.15.2`への`values.yaml`移行を支援します。 お客様のカスタマイズを維持しつつ、新しいバージョンのデフォルト値を適切に反映し、かつ可視性を高めるために不要なデフォルト値を削除した`values.yaml`を生成します。
新しい `values.yaml` (v1.15.2 対応)
生成された`values.yaml`は以下の通りです。
yaml cluster_config: # The name of the cluster name: trk-test-cluster-20250806 sysdig_endpoint: # The region where the Sysdig Secure instance is located region: us1 # The access key for the Sysdig Secure instance access_key: xxxx # Features features: admission_control: # Enable the admission control feature enabled: true # The policy to apply when a request is denied failure_policy: Fail # Enable the dry run mode dry_run: false container_vulnerability_management: # Enable the container vulnerability management feature on the admission control enabled: true posture: # Enable the posture feature on the admission control (New in v1.15.2) enabled: true kubernetes_metadata: # Enable the Kubernetes Metadata feature on cluster shield enabled: true posture: host_posture: enabled: true cluster_posture: # Enable the posture feature on cluster shield enabled: true vulnerability_management: host_vulnerability_management: enabled: true container_vulnerability_management: # Enable the container vulnerability management feature on cluster shield enabled: true # Define if the platform services are enabled platform_services_enabled: true in_use: # Allows to retrieve the list of running packages. enabled: true # Allows to store the list of running packages to Sysdig backend. integration_enabled: true detections: drift_control: enabled: true malware_control: enabled: true ml_policies: enabled: true kubernetes_audit: # Enable the Kubernetes Audit feature on cluster shield enabled: true investigations: activity_audit: enabled: true live_logs: enabled: true network_security: # Enable the network security feature enabled: true audit_tap: enabled: false captures: enabled: true event_forwarder: enabled: false respond: rapid_response: enabled: false password: response_actions: enabled: false monitor: app_checks: enabled: false java_management_extensions: enabled: false prometheus: enabled: true statsd: enabled: false kube_state_metrics: # Enable the Kubernetes State Metrics feature (New in v1.15.2) enabled: false kubernetes_events: # Enable the Kubernetes Events feature (New in v1.15.2) enabled: false host: # The driver to use for the host agent (Accepted Values: kmod, legacy_ebpf, universal_ebpf) driver: legacy_ebpf image: # The tag for the host shield images tag: 14.1.1 # Default tag for v1.15.2 resources: kmodule: limits: # The CPU limit for the kmodule cpu: 2000m # The memory limit for the kmodule memory: 2Gi requests: # The CPU request for the kmodule cpu: 500m # The memory request for the kmodule memory: 748Mi shield: limits: # The CPU limit for the host shield cpu: 2000m # The memory limit for the host shield memory: 2Gi requests: # The CPU request for the host shield cpu: 500m # The memory request for the host shield memory: 748Mi # The tolerations for the host shield tolerations: [] # Preserved custom empty list # The affinity for the host shield affinity: {} # Preserved custom empty map cluster: image: # The tag for the cluster shield image tag: 1.14.0 # Default tag for v1.15.2 resources: requests: # The CPU request for the cluster shield cpu: 1000m # The memory request for the cluster shield memory: 1024Mi limits: # The CPU limit for the cluster shield cpu: 3000m # The memory limit for the cluster shield memory: 3072Mi # Defines the PodDisruptionBudget for the cluster shield (New in v1.15.2) pod_disruption_budget: # Create the PodDisruptionBudget for the cluster shield create: true # The minimum number of available pods for the cluster shield min_available: 1 # The tolerations for the cluster shield tolerations: [] # Preserved custom empty list # The affinity for the cluster shield affinity: {} # Preserved custom empty map ssl: ca: certs: [] # Default empty list, kept for visibility proxy: # HTTP proxy to use for all HTTP requests http_proxy: example.com:9876 # HTTPS proxy to use for all HTTPS requests https_proxy: example.com:9876 # No proxy hosts and ips no_proxy: 172.16.0.0/20 # The tolerations for the all the workloads tolerations: [] # Preserved custom empty list # The affinity for the all the workloads affinity: {} # Preserved custom empty map
移行に伴う注意点と推奨事項
1. Helmチャートのバージョンアップの重要性
Sysdig Shield Helmチャートの`v1.0.0`から`v1.15.2`への大幅なバージョンアップは、多くの改善、新機能、バグ修正、およびセキュリティ強化が含まれています。常に最新に近いバージョンを維持することは、安定した運用とセキュリティの観点から非常に重要です。
2. `values.yaml`の変更点サマリ
自動適用された変更:
- `host.image.tag`: `13.8.1`から`14.1.1`へ更新されました。
- `cluster.image.tag`: `1.9.1`から`1.14.0`へ更新されました。
- これらの変更は、新しいバージョンのSysdigエージェントとクラスターシールドの推奨イメージバージョンに準拠するためのものです。
新しく追加された機能 (`features`配下):
- `features.admission_control.posture`: アドミッションコントロールでポスチャー機能が有効になりました。デフォルト値は`true`です。
- `features.respond.rapid_response.password`: `rapid_response`機能のパスワード設定が追加されました。
- `features.respond.response_actions`: レスポンスアクション機能が追加されました。デフォルトは`enabled: false`です。
- `features.monitor.kube_state_metrics`: Kubernetes State Metricsの監視機能が追加されました。デフォルトは`enabled: false`です。
- `features.monitor.kubernetes_events`: Kubernetes Eventsの監視機能が追加されました。デフォルトは`enabled: false`です。 これらの新機能は、`values.yaml`に明示的に記載されており、必要に応じて設定を調整できます。
新しく追加された設定 (`features`以外):
- `cluster.pod_disruption_budget`: クラスターシールドのPod Disruption Budget設定が追加されました。これにより、計画的なメンテナンス時にPodの可用性を維持するための設定が可能です。デフォルトは`create: true`、`min_available: 1`です。
- 重要: この設定により、Sysdig ShieldのPodにPDBが自動的に作成されます。クラスタの可用性設計に影響を与える可能性があるため、既存のPDBポリシーや運用ルールと競合しないか確認してください。
削除されたデフォルト値:
- 「feature以外でデフォルトの値を利用しているパラメータは削除」という指示に基づき、お客様がカスタマイズしていない、かつ`v1.15.2`のデフォルト値と同じであった多くのパラメータ(例: `cluster_config`の`cluster_domain`、`host`の`privileged`など)は、生成された`values.yaml`から削除されています。これにより、カスタマイズされた設定のみが強調され、可視性が向上します。
- host_windows`セクション全体は、お客様の既存設定になく、かつデフォルト値のみで構成されているため、削除されました。
3. 移行時の推奨事項
1.Helm Chartのリポジトリ更新:
まず、Sysdig Helmチャートのリポジトリを最新に更新してください。
bash helm repo add sysdig https://charts.sysdig.com helm repo update
2.ドライランの実行
実際にHelmを適用する前に、必ずドライランを実行して、どのようなKubernetesリソースが変更されるかを確認してください。
bash helm upgrade YOUR_RELEASE_NAME sysdig/shield -f new_values.yaml --namespace YOUR_NAMESPACE --dry-run --debug
これにより、予期せぬ変更やエラーがないかを確認できます。
3.既存のリソースとの競合確認:
`pod_disruption_budget`など、新しいバージョンで追加されたリソースが既存のKubernetes環境と競合しないか確認してください。
4.セキュリティコンテキストの確認:
Sysdig Agentの`privileged`モードについて、`v1.15.2`の`host.privileged`パラメータのコメントには、「Universal eBPFドライバーを使用しない場合、特権モードを無効にするとPostureおよびVulnerability Management機能が無効になる」旨の注意書きが追加されています。お客様の旧設定には`host.privileged`は明示的に記述されていませんでしたが、旧バージョン・新バージョンともにデフォルトは`true`であり、今回の生成された`values.yaml`からは削除されています。これは、デフォルト値は削除するという方針によるものですが、もし特権モードの無効化を検討する際は、この点に留意してください。
現在の設定では`host.driver: legacy_ebpf`が指定されているため、`privileged: true`のままであることが推奨されます。
5.新しい機能の確認:
生成された`values.yaml`には、新バージョンで追加されたいくつかの機能がデフォルト値で含まれています。これらの新機能がお客様の要件に合致するか、または追加の設定が必要ないかを確認することをお勧めします。特に、`admission_control.posture`や`monitor`配下の新しい機能などです。
6.ロールバック計画:
万が一の問題に備え、バージョンアップ後に問題が発生した場合に、迅速に旧バージョンに戻せるよう、現在の環境のスナップショット取得やHelmリリース履歴の保持など、ロールバック計画を準備しておくことを強く推奨します。
この新しい`values.yaml`が、お客様のSysdig Shieldの円滑なバージョンアップに役立つことを願っています。ご不明な点がありましたら、お気軽にお尋ねください。
生成されたvalues.yamlを用いて、バージョンアップできるか確認しましょう。
# Helmリポジトリを更新 $ helm repo update # 生成されたvalues.yamlを使ってアップグレードを実行 $ helm upgrade sysdig-agent -n sysdig-agent -f values.yaml sysdig/shield # Podのステータスを確認 $ oc get po -n sysdig-agent NAME READY STATUS RESTARTS AGE sysdig-agent-shield-cluster-6c5df47689-4qwds 1/1 Running 0 4m45s sysdig-agent-shield-cluster-6c5df47689-8pqm8 1/1 Running 0 5m sysdig-agent-shield-host-6lgbb 1/1 Running 0 5m ...(以下略)... # DaemonSetのコンテナイメージバージョンを確認 $ oc get ds -n sysdig-agent sysdig-agent-shield-host -o yaml | grep image image: quay.io/sysdig/agent-slim:14.1.1 imagePullPolicy: IfNotPresent image: quay.io/sysdig/agent-kmodule:14.1.1 imagePullPolicy: IfNotPresent # Deploymentのコンテナイメージバージョンを確認 $ oc get deploy -n sysdig-agent sysdig-agent-shield-cluster -o yaml | grep image image: quay.io/sysdig/cluster-shield:1.14.0 imagePullPolicy: IfNotPresent
無事にPodが起動し、各コンポーネントのイメージが新しいバージョンに更新されていることが確認できました。念のためConfigMapの中身なども確認しましたが、こちらも問題なく設定が反映されていました。
まとめ
今回の検証から、生成AIはvalues.yamlのような複雑な設定ファイルのバージョンアップ作業を高い精度で支援できることがわかりました。 ただし、利用するモデルやプロンプトの内容によっては、ハルシネーション(もっともらしい嘘の情報を生成する現象)が発生する可能性もゼロではありません。本番環境へ適用する前には、ステージング環境での十分なテストと、生成された内容のレビューが不可欠です。
この記事が、みなさまのSysdig運用、そして日々の定型業務の効率化に貢献できれば幸いです。
おまけ: 効果的なプロンプトを作成するポイント
今回、期待通りの結果を得るためにプロンプトの作成に最も時間を費やしました。以下に工夫したポイントをまとめます。
- 役割・背景・指示を明確に分ける: AIにSREという役割を与え、何をしてほしいのかを具体的に指示することで、回答の精度が向上しました。
- 注意点や変更点のレポートを要求する: 単にファイルを生成させるだけでなく、変更点のサマリや注意点を報告させることで、人間がレビューしやすくなります。
- 比較対象の情報をすべて与える: 「旧版」「新版」「カスタム版」の3つのvalues.yaml全文を情報として与えることで、AIは差分を正確に分析できました。(当初、差分だけを与えようとしましたが、うまくいきませんでした)
- 出力形式を細かく指定する: 「featuresセクションはすべて記述し、それ以外はカスタム値のみ記述する」といった指示で、可読性の高いvalues.yamlを生成させることができました。
担当者紹介

- 担当者名
- 鳥飼
- コメント
- Sysdigを中心にコンテナ、Kubernetes、クラウド領域の業務に従事しています。
- 保有資格
- Certified Kubernetes Administrator
SCSK技術者ブログ

【SCSK技術者によるブログ】生成AIでSysdigエージェントのアップグレードを効率化 〜Helm values.yamlの移行作業を自動化〜

【SCSK技術者によるブログ】Sysdigの「Search」機能を体験!生成AIでクエリの学習コスト無しに脆弱性調査

【SCSK技術者によるブログ】ゼロトラスト文脈でのクラウドセキュリティ、そしてSysdig

【SCSK技術者によるブログ】Sysdigと組み合わせて効果的なソリューションのご紹介 ~ネットワークポリシー編~

【SCSK技術者によるブログ】生成AIで過検知対策を効率化!Sysdig Sageの実力検証

【SCSK技術者によるブログ】なぜ今、Sysdigが選ばれるのか?動画で解説!クラウドネイティブセキュリティの最前線 - SCSKの日本語伴走サポートで安心導入

【SCSK技術者によるブログ】Serverless AgentがAzure Container Appsに対応しました

【SCSK技術者によるブログ】システムコール分析における生成AIの活用

【SCSK技術者によるブログ】Sysdig情報アップデート~AWS連携にS3オプションが追加されました~

【SCSK技術者によるブログ】Falco初学者講座 - Exceptions編

【SCSK技術者によるブログ】Falco初学者講座 - List/Macro編

【SCSK技術者によるブログ】コンテナの電力消費をSysdig Monitorで監視してみよう

【SCSK技術者によるブログ】Sysdigの脅威検知はFalcoだけじゃない ~Contianer Drift編~

【SCSK技術者によるブログ】~Falco初学者に送る~ Sysdig SageでFalcoを勉強してみよう②

【SCSK技術者によるブログ】~Falco初学者に送る~ Sysdig SageでFalcoを勉強してみよう①

【 SCSK技術者によるブログ】Sysdigの設定をTerraformで管理してみた(Monitor編)

【SCSK技術者によるブログ】Falco初学者講座 - condition編

【SCSK技術者によるブログ】Sysdig Sageを使ってみた

【SCSK技術者によるブログ】Sysdigと組み合わせて効果的なソリューションのご紹介 ~ポリシーエンジン編②~

【SCSK技術者によるブログ】Sysdigをセキュアに使おう~IP Allowlist編~

【SCSK技術者によるブログ】Node ExporterをSysdig Monitorに連携してみた

【SCSK技術者によるブログ】Sysdigの設定をTerraformで管理してみた

【SCSK技術者によるブログ】CNAPPの理解とSysdigのカバレッジ

【SCSK技術者によるブログ】Sysdigの脅威検知はFalcoだけじゃない ~マルウェア検知編~

【SCSK技術者によるブログ】Sysdigのライセンス体系

【SCSK技術者によるブログ】Sysdig とMicrosoft Entra ID間でSAML認証設定を試してみた

【SCSK技術者によるブログ】Sysdigと組み合わせて効果的なソリューションのご紹介 ~ポリシーエンジン編~

【SCSK技術者によるブログ】Sysdigの脅威検知はFalcoだけじゃない ~AWSサインインなりすまし検知編~

【SCSK技術者によるブログ】Sysdig SecureのRisks機能を試してみた
