[] Add PVC, Secret, and ConfigMap templates; update Deployment to reference them#267
Conversation
![orange-codens[bot]](https://avatars.githubusercontent.com/in/4028936?s=60&v=4){kind=small}
There was a problem hiding this comment.
🍊 Orange Codens レビュー
レビュー総評
重大な問題が複数あります。
- データ消失リスク (blocker/high): 旧
values.yamlにあったretainOnDelete: trueが削除され、helm uninstallで Git リポジトリデータが消える。helm.sh/resource-policy: keepアノテーションの追加が必須。 - Secret の空値問題 (blocker):
secrets.*のデフォルト値がすべて空文字列のため、--setを忘れると空 Secret が作成されてアプリが認証エラーで起動失敗する。requiredパイプラインによる早期バリデーションが必要。 - 既存クラスタへの破壊的変更 (critical): 旧
-db/-minioSecret への参照が削除されたが、移行手順が未記載。helm upgradeすると新 Secret が空のまま作成され、旧 Secret は孤立する。 - accessMode のハードコード (high):
ReadWriteOnceが固定になり、マルチノード対応など柔軟な構成が不可能になった。
🔒 セキュリティ: 最も深刻な問題は values.yaml と secret.yaml で JWT シークレット・DB パスワード・MinIO パスワードのデフォルト値が空文字列であり、Helm の required ガードが存在しないため、--set 省略時に空シークレットが本番クラスターに適用されるリスクです（特に JWT が空の場合は認証バイパスに直結します）。加えて ConfigMap と Secret が同一の fullname を共有している設計は混同リスクを高めるため、Secret にはサフィックスを付与することを推奨します。これらを修正することで、Helm チャートとしてのシークレット管理の基本的な安全性が担保されます。
🛑 blocker: 1 / 🔴 critical: 3 / 🟠 high: 4 / 🟡 medium: 3 / 🔵 low: 2
その他の指摘 (8 件)
- 🟠 [high]
helm/values.yaml:25—retainOnDelete: trueに相当する設定が削除され、helm uninstallでデータ消失の恐れ (confidence: 0.92,code.helm.pvc_retain_policy_removed) - 🟠 [high]
helm/templates/secret.yaml:11— ConfigMap と Secret が同一名を使用しており、参照の混同リスクがある (confidence: 0.80,sec.sast.authz.secret_name_collision) - 🟠 [high]
helm/templates/configmap.yaml:1— ConfigMap がpersistence.enabledに関わらず常に生成される (confidence: 0.72,code.helm.configmap_always_rendered) - 🟡 [medium]
helm/templates/pvc.yaml:14—global.storageClassが values.yaml に定義されておらず、参照が不明確 (confidence: 0.82,maintainability.helm.pvc_storage_class_values_missing) - 🟡 [medium]
helm/templates/configmap.yaml:12—MINIO_ENDPOINTがminio.enabledの条件なしに ConfigMap に出力される (confidence: 0.75,code.helm.minio_endpoint_configmap_conditional_mismatch) - 🟡 [medium]
helm/templates/configmap.yaml:8— ConfigMap の値がクォート処理されているが、一部の Values が未定義の場合にテンプレートエラーで情報漏洩する可能性 (confidence: 0.70,sec.sast.injection.helm_template_injection) - 🔵 [low]
helm/templates/pvc.yaml:13— PVC サイズのデフォルト値がテンプレートと values.yaml で二重管理されている (confidence: 0.88,maintainability.helm.pvc_size_default_inconsistency) - 🔵 [low]
helm/templates/pvc.yaml:14— PVC の storageClassName が global.storageClass 未設定時にデフォルトの StorageClass を使用し、意図しないストレージバックエンドにデータが書き込まれる可能性 (confidence: 0.65,sec.sast.authz.pvc_no_namespace)
head: c726276 | Orange Codens (P1)
| data: | ||
| jwt-secret: {{ .Values.secrets.jwtSecret | b64enc | quote }} | ||
| db-password: {{ .Values.secrets.dbPassword | b64enc | quote }} | ||
| minio-root-password: {{ .Values.secrets.minioRootPassword | b64enc | quote }} |
There was a problem hiding this comment.
🛑 [blocker] Secret の値が b64enc のみで保護されており、values.yaml に平文で残る
該当箇所:
jwt-secret: {{ .Values.secrets.jwtSecret | b64enc | quote }}
db-password: {{ .Values.secrets.dbPassword | b64enc | quote }}
minio-root-password: {{ .Values.secrets.minioRootPassword | b64enc | quote }}b64enc は Kubernetes の Secret 形式に合わせたエンコードであり、暗号化ではない。しかし本質的な問題は、--set secrets.jwtSecret=xxx で渡した値が Helm リリース履歴 (helm get values) に平文で記録されることである。
推奨対策:
lookupを使って既存の Secret が存在する場合は再生成しない (helm upgradeで上書きしない) ロジックを追加する。- または
existingSecretパターン（既存のvalues.yamlにあったsecrets.existingSecretキー）を活用し、Secret 自体は Helm 管理外で作成させる設計を検討する。 - 少なくとも
helm installコマンドのドキュメントや--set-stringよりも--set-fileや外部シークレット管理 (Sealed Secrets, ESO 等) を推奨するコメントを追記する。
また values.yaml では:
secrets:
jwtSecret: ""
dbPassword: ""
minioRootPassword: ""デフォルト値が空文字列のままであり、helm install 時に --set を忘れると空の Secret が生成されてアプリが起動失敗するまで気づかない。required パイプラインを使って早期エラーにすることを強く推奨する。例: {{ required "secrets.jwtSecret is required" .Values.secrets.jwtSecret | b64enc | quote }}
@@ -16,3 +16,3 @@
- jwt-secret: {{ .Values.secrets.jwtSecret | b64enc | quote }}
- db-password: {{ .Values.secrets.dbPassword | b64enc | quote }}
- minio-root-password: {{ .Values.secrets.minioRootPassword | b64enc | quote }}
+ jwt-secret: {{ required "secrets.jwtSecret is required" .Values.secrets.jwtSecret | b64enc | quote }}
+ db-password: {{ required "secrets.dbPassword is required" .Values.secrets.dbPassword | b64enc | quote }}
+ minio-root-password: {{ required "secrets.minioRootPassword is required" .Values.secrets.minioRootPassword | b64enc | quote }}code.secret_management.plaintext_in_secret | confidence: 0.95
| existingSecret: "" | ||
| jwtSecret: "" | ||
| dbPassword: "" | ||
| minioRootPassword: "" |
There was a problem hiding this comment.
🔴 [critical] シークレット値がデフォルト空文字列として values.yaml にコミットされ、空のまま本番適用されるリスク
CWE-522: Insufficiently Protected Credentials
values.yaml にシークレットのデフォルト値として空文字列が定義されています。
secrets:
jwtSecret: ""
dbPassword: ""
minioRootPassword: ""Helmでは --set が省略された場合、空文字列のまま Secret リソースが作成されます。secret.yaml 側でも検証ガードが存在しないため（後述）、空文字列が base64 エンコードされた "" (e30K 等ではなく空文字) の Secret が Kubernetes に登録されます。特に JWT シークレットが空の場合、認証トークンの署名検証が無効化されるかアプリ側でパニックになる可能性があります。
推奨対応: required 関数でインストール時に値の指定を強制してください。
# secret.yaml で required を使用して空文字列デプロイを防ぐ
data:
jwt-secret: {{ required "secrets.jwtSecret must be set" .Values.secrets.jwtSecret | b64enc | quote }}
db-password: {{ required "secrets.dbPassword must be set" .Values.secrets.dbPassword | b64enc | quote }}
minio-root-password: {{ required "secrets.minioRootPassword must be set" .Values.secrets.minioRootPassword | b64enc | quote }}sec.sast.crypto.secret_in_values | confidence: 0.95
| data: | ||
| jwt-secret: {{ .Values.secrets.jwtSecret | b64enc | quote }} | ||
| db-password: {{ .Values.secrets.dbPassword | b64enc | quote }} | ||
| minio-root-password: {{ .Values.secrets.minioRootPassword | b64enc | quote }} |
There was a problem hiding this comment.
🔴 [critical] シークレット値が空のまま Secret リソースに書き込まれる可能性（required ガードなし）
CWE-522: Insufficiently Protected Credentials
secret.yaml はシークレット値を無条件に base64 エンコードして書き込んでいますが、値が空かどうかの検証がありません。
data:
jwt-secret: {{ .Values.secrets.jwtSecret | b64enc | quote }}
db-password: {{ .Values.secrets.dbPassword | b64enc | quote }}
minio-root-password: {{ .Values.secrets.minioRootPassword | b64enc | quote }}values.yaml のデフォルト値はすべて "" であるため、--set 省略時に空文字列が base64 エンコードされた Secret が作成されます。JWT シークレットが空文字列の場合、多くの JWT ライブラリは署名検証をスキップまたはエラーとなり、認証バイパスに直結する危険があります。
data:
jwt-secret: {{ required "secrets.jwtSecret must be set" .Values.secrets.jwtSecret | b64enc | quote }}
db-password: {{ required "secrets.dbPassword must be set" .Values.secrets.dbPassword | b64enc | quote }}
minio-root-password: {{ required "secrets.minioRootPassword must be set" .Values.secrets.minioRootPassword | b64enc | quote }}sec.sast.crypto.secret_in_values | confidence: 0.95
| apiVersion: v1 | ||
| kind: Secret | ||
| metadata: | ||
| name: {{ include "open-git.fullname" . }} |
There was a problem hiding this comment.
🔴 [critical] Secret / ConfigMap / Deployment が同一名を使用しており、名前衝突リスクがある
該当箇所 (secret.yaml):
name: {{ include "open-git.fullname" . }}configmap.yaml も同じ名前を使用している:
name: {{ include "open-git.fullname" . }}open-git.fullname が例えば open-git に解決されると、open-git という名前の Secret と ConfigMap が両方作成されるが、これ自体は Kind が異なるので問題ない。
しかし本当の問題は、以前の deployment.yaml では
name: {{ include "open-git.fullname" . }}-db
key: postgres-passwordおよび
name: {{ include "open-git.fullname" . }}-minio
key: secret-keyという別名の Secret が参照されていた。今回の変更でこれらの既存 Secret リソースへの参照がなくなったが、既存クラスタでは古い -db / -minio Secret がそのまま残り、新しい open-git.fullname Secret は helm upgrade の差分で作成される。移行手順やアップグレード時の注意が一切記載されていないため、既存デプロイメントでは helm upgrade 後に古い Secret が孤立し、かつ新 Secret の値が空（デフォルト値が ""）のため認証エラーが発生する。
code.kubernetes.secret_name_collision | confidence: 0.88
| {{- include "open-git.labels" . | nindent 4 }} | ||
| spec: | ||
| accessModes: | ||
| - ReadWriteOnce |
There was a problem hiding this comment.
🟠 [high] PVC の accessMode がハードコードされ、values.yaml から設定できなくなった
該当箇所:
accessModes:
- ReadWriteOnce変更前の values.yaml には:
persistence:
repositories:
size: 50Gi
accessMode: ReadWriteOnce
retainOnDelete: trueaccessMode が設定可能だったが、今回の変更で:
persistence:
enabled: true
reposSize: "20Gi"accessMode フィールドが削除され、テンプレートに ReadWriteOnce がハードコードされた。NFS や CephFS など ReadWriteMany が必要な環境では設定変更不可能になっている。
また retainOnDelete: true に対応する persistentVolumeReclaimPolicy や Helm helm.sh/resource-policy: keep アノテーションも削除されており、helm uninstall 時にデータが消える。
@@ -9,2 +9,2 @@
accessModes:
- - ReadWriteOnce
+ - {{ .Values.persistence.accessMode | default "ReadWriteOnce" }}code.helm.pvc_access_mode_regression | confidence: 0.95
There was a problem hiding this comment.
🍊 Orange Codens レビュー
重大な問題が複数あります。
secret.yamlでデフォルト値が空文字のまま適用されると空 Secret がクラスタに作成される（required関数による必須チェックなし）。- Secret と ConfigMap が同名になっており、既存の
-db/-minioSecret からの参照先変更が破壊的移行を引き起こす恐れがある。 persistence.repositories構造の削除・サイズ縮小（50Gi→20Gi）・retainOnDelete消失は既存ユーザーのデータ損失リスクを持つ後方互換性破壊変更であり、移行ガイドが必須。helm.sh/resource-policy: keepannotation の追加を強く推奨する。
🔒 セキュリティ: 今回の変更はシークレット管理を Kubernetes Secret に集約する方向で適切ですが、values.yaml のデフォルト値が空文字列のまま required 検証なしでテンプレートに流れ込むため、デプロイ時の設定ミスで空シークレットが本番に適用されるリスクが最も深刻です。helm/templates/secret.yaml で required 関数を使い必須入力を強制することを強く推奨します。また MINIO_ACCESS_KEY が平文 value のまま残っている点も、Secret への移行が望まれます。
🛑 blocker: 2 / 🔴 critical: 1 / 🟠 high: 1 / 🟡 medium: 3 / 🔵 low: 2
その他の指摘 (5 件)
- 🟡 [medium]
helm/values.yaml:25— 既存のpersistence.repositories構造を削除しており後方互換性が失われている (confidence: 0.92,maintainability.helm.values_breaking_change) - 🟡 [medium]
helm/templates/pvc.yaml:8— PVC にpersistentVolumeReclaimPolicy/retainOnDelete相当の設定が引き継がれていない (confidence: 0.85,maintainability.helm.pvc_no_retain_policy) - 🟡 [medium]
helm/templates/pvc.yaml:13— PVC ストレージサイズがユーザー入力値を直接使用しており入力検証がない (confidence: 0.65,sec.sast.authz.pvc_no_size_validation) - 🔵 [low]
helm/templates/deployment.yaml:79— MINIO_ACCESS_KEY が Secret ではなく平文 value として Deployment に設定されている (confidence: 0.80,sec.sast.infodisclosure.minio_access_key_plaintext) - 🔵 [low]
.github/workflows/helm.yml:31—--generate-name削除により CI での helm install 名が固定になる (confidence: 0.65,maintainability.helm.dry_run_flag_change)
前回 run からの未解決 finding: 3 件
head: b983b28 | Orange Codens (P1)
| data: | ||
| jwt-secret: {{ .Values.secrets.jwtSecret | b64enc | quote }} | ||
| db-password: {{ .Values.secrets.dbPassword | b64enc | quote }} | ||
| minio-root-password: {{ .Values.secrets.minioRootPassword | b64enc | quote }} |
There was a problem hiding this comment.
🛑 [blocker] Secret の値が values.yaml に平文で保存され、Helm リリース履歴にも残る
該当箇所:
jwt-secret: {{ .Values.secrets.jwtSecret | b64enc | quote }}
db-password: {{ .Values.secrets.dbPassword | b64enc | quote }}
minio-root-password: {{ .Values.secrets.minioRootPassword | b64enc | quote }}b64enc は base64 エンコードであり暗号化ではない。--set で渡した値は Helm リリース（Secret）として helm.sh/release-name ConfigMap/Secret に平文で保存され、helm get values で誰でも取得できる。本番運用では Helm Secrets / External Secrets Operator / Vault 等の外部シークレット管理を推奨する。少なくとも requiredEnv や Helm の required 関数で空値チェックを入れ、空のまま適用されることを防ぐべき。現状 jwtSecret: "" がデフォルトのため、空 secret が意図せずクラスタに適用される。
@@ -16,3 +16,3 @@
- jwt-secret: {{ .Values.secrets.jwtSecret | b64enc | quote }}
- db-password: {{ .Values.secrets.dbPassword | b64enc | quote }}
- minio-root-password: {{ .Values.secrets.minioRootPassword | b64enc | quote }}
+ jwt-secret: {{ required "secrets.jwtSecret is required" .Values.secrets.jwtSecret | b64enc | quote }}
+ db-password: {{ required "secrets.dbPassword is required" .Values.secrets.dbPassword | b64enc | quote }}
+ minio-root-password: {{ required "secrets.minioRootPassword is required" .Values.secrets.minioRootPassword | b64enc | quote }}code.secret_management.plaintext_in_chart | confidence: 0.95
| apiVersion: v1 | ||
| kind: Secret | ||
| metadata: | ||
| name: {{ include "open-git.fullname" . }} |
There was a problem hiding this comment.
🛑 [blocker] Secret と ConfigMap が同名で競合する
該当箇所（secret.yaml）:
name: {{ include "open-git.fullname" . }}該当箇所（configmap.yaml）:
name: {{ include "open-git.fullname" . }}Kubernetes では Kind が異なっても同一 Namespace 内で Secret と ConfigMap の名前は独立した名前空間を持つため、名前が衝突してもリソース作成自体は失敗しない。しかし deployment.yaml での参照時に意図したリソース種別を参照しているかが即座に判別できず、将来的な混乱を招く。より重大な問題として、既存 deployment で {{ include "open-git.fullname" . }}-db / {{ include "open-git.fullname" . }}-minio を参照していた Secret が本 PR でフラットな {{ include "open-git.fullname" . }} に変更されており、既存クラスタにこれらの古い Secret がある場合は deployment 側の参照変更と合わせた移行手順が必要。Secret には -secret、ConfigMap には -config などのサフィックスを推奨。
@@ -11,1 +11,1 @@
- name: {{ include "open-git.fullname" . }}
+ name: {{ include "open-git.fullname" . }}-secretcode.helm.secret_configmap_name_collision | confidence: 0.88
| key: postgres-password | ||
| name: {{ include "open-git.fullname" . }} | ||
| key: db-password | ||
| {{- else }} |
There was a problem hiding this comment.
🔴 [critical] 既存 Secret 参照を破壊的に変更しており、ローリングアップデート時に Pod 起動失敗する
該当箇所:
- name: {{ include "open-git.fullname" . }}-db
- key: postgres-password
+ name: {{ include "open-git.fullname" . }}
+ key: db-password既存クラスタには <fullname>-db という Secret が存在する可能性がある。新 Secret <fullname> は本 PR で初めて作成されるため、helm upgrade のタイミングで新旧 Pod が混在すると、旧 Secret を参照する古い Pod は継続動作するが、新テンプレートで起動しようとする Pod は旧 Secret 削除前/新 Secret 未作成状態でクラッシュする可能性がある。移行ガイドまたは helm upgrade --atomic の使用を PR に明記すべき。
code.helm.breaking_existing_secret_refs | confidence: 0.82
| storage: {{ .Values.persistence.reposSize | default "20Gi" }} | ||
| {{- with .Values.global.storageClass }} | ||
| storageClassName: {{ . | quote }} | ||
| {{- end }} |
There was a problem hiding this comment.
🟠 [high] global.storageClass を参照しているが values.yaml に定義が存在しない
該当箇所:
{{- with .Values.global.storageClass }}
storageClassName: {{ . | quote }}
{{- end }}diff 内の values.yaml の変更に global.storageClass の追加は含まれていない。Helm では未定義キーのアクセスは空文字として扱われるため with ブロックはスキップされるが、global キー自体が values.yaml に存在しない場合、helm lint --strict でエラーになることがある。また利用者が storageClass を設定したいときに値の設定場所が分からない。values.yaml に global.storageClass: "" を追加すべき。
code.helm.pvc_storage_class_undefined_key | confidence: 0.80
There was a problem hiding this comment.
🍊 Orange Codens レビュー
PR 全体の所感
重大度の高い問題が複数存在します。 最も深刻なのは以下の 2 点です。
- アップグレード時の Pod 起動失敗リスク: Deployment が旧
-db/-minioSecret から新-secretsSecret への参照に切り替わっており、ロールアウト順序によってはCreateContainerConfigErrorが発生します。マイグレーション手順の明示が必要です。 - CI の lint / template ステップで
secrets.dbPasswordが未設定:db.typeのデフォルトがpostgresの場合、required関数でパイプラインが失敗する可能性があります（dry-run ステップには含まれているため不整合）。
それ以外にも、レガシー Secret の無期限重複保持、values.yaml の reposSize デフォルト値の不一致、secrets.existingSecret の破壊的削除など、運用上の懸念点が複数あります。マージ前に少なくとも CI の dbPassword 欠落を修正し、アップグレードパスのドキュメント化が推奨されます。
🔒 セキュリティ: 本 PR は Secret / ConfigMap / PVC を Helm テンプレートとして分離する正しい方向の変更ですが、--set によるシークレット平文渡しが Helm リリース履歴に保存されるリスクが残ります。また後方互換レガシー Secret の複製が不要な攻撃対象領域を生んでいる点と、CI ワークフローでテスト値がハードコードされている点が改善ポイントです。required バリデーションや b64enc の使用は適切ですが、長期的には External Secrets Operator や helm-secrets による外部管理への移行を推奨します。
🛑 blocker: 2 / 🔴 critical: 1 / 🟠 high: 3 / 🟡 medium: 4 / 🔵 low: 4
その他の指摘 (10 件)
- 🛑 [blocker]
helm/templates/deployment.yaml:42— db-password の secretKeyRef が postgres 条件の外にある一方、Secret 側は条件付きで生成されない (confidence: 0.45,code.helm.conditional_secret_key_missing) - 🟠 [high]
helm/templates/pvc.yaml:3— storage size バリデーション regex が空文字列を通過させてしまう (confidence: 0.60,code.helm.regex_invalid_quantity) - 🟡 [medium]
helm/values.yaml:30— values.yaml のreposSizeデフォルトと pvc.yaml のフォールバック値が不一致 (confidence: 0.88,maintainability.helm.values_default_inconsistency) - 🟡 [medium]
.github/workflows/helm.yml:23— helm lint ステップでsecrets.dbPasswordが渡されていないため postgres モードの lint が検証できない (confidence: 0.82,maintainability.helm.ci_secret_missing_dbpassword_lint) - 🟡 [medium]
.github/workflows/helm.yml:29— helm template ステップでもsecrets.dbPasswordが欠落しており postgres モードのテンプレート検証が不完全 (confidence: 0.82,maintainability.helm.ci_secret_missing_dbpassword_template) - 🟡 [medium]
helm/templates/configmap.yaml:8— ConfigMap テンプレートで値を quote しているが、一部の値は信頼できない入力を受け入れる可能性がある (confidence: 0.45,sec.sast.injection.helm_template_unquoted) - 🔵 [low]
helm/values.yaml:77—secrets.existingSecretキーが削除されており、既存インストールが破壊的変更の影響を受ける (confidence: 0.88,maintainability.helm.breaking_values_schema) - 🔵 [low]
helm/templates/secret.yaml:30— 後方互換レガシー Secret（-db / -minio）が同一シークレット値を複製しており、攻撃対象領域が拡大する (confidence: 0.80,sec.sast.authz.secret_duplicate_exposure) - 🔵 [low]
helm/templates/deployment.yaml:80—MINIO_SECRET_KEY環境変数がminio-root-passwordキーを参照しており命名が混乱を招く (confidence: 0.78,maintainability.helm.naming_minio_secret_key) - 🔵 [low]
.github/workflows/helm.yml:23— CI ワークフローでシークレット値が --set で平文ハードコードされている (confidence: 0.70,sec.sast.crypto.plaintext_ci_secret)
head: 0e50cec | Orange Codens (P1)
There was a problem hiding this comment.
🍊 Orange Codens レビュー
重大な問題が2件あります。
values.yamlにjwtSecret/dbPassword等の空文字列デフォルトが書き込まれており、ユーザーが誤って実値をここに記載した場合に Git 履歴に秘密値が残るリスクがあります（blocker）。secret.yamlの legacy Secret（-minio）に書き込むaccess-keyキーと、deployment.yamlが参照するminio-access-keyキーが不一致であり、legacy モードから統合 Secret への移行ガイドに齟齬があります（critical）。
その他、persistence の新旧スキーマ重複・storageClass 参照のベストプラクティス不足・CI の --set 重複なども修正推奨です。
🔒 セキュリティ: 本 PR は Helm chart のシークレット管理を大幅に改善するものですが、CI ワークフロー内でテスト用シークレットが GitHub Actions の env ブロックにプレーンテキスト記載されており、ログ・PR diff から漏洩するリスクがあります（high）。また existingSecret を使用する場合に外部 Secret のキー存在検証がスキップされる設計上の抜けと、--set secrets.*=... が helm history に平文で残る Helm の既知問題への対処も必要です。全体的なアーキテクチャの方向性は正しいため、上記 3 点を修正すれば本番適用可能なレベルになります。
🛑 blocker: 1 / 🔴 critical: 1 / 🟠 high: 3 / 🟡 medium: 5 / 🔵 low: 2
その他の指摘 (8 件)
- 🟠 [high]
helm/templates/deployment.yaml:20—$secretNameの定義がspec.template.spec直下ではなくcontainersの外側に置かれているが、インデント的にspec直下に見える (confidence: 0.65,code.helm.secret_variable_scope) - 🟡 [medium]
.github/workflows/helm.yml:27— CI の--set secrets.*が3ステップに渡って重複しており、追加時の変更漏れリスクがある (confidence: 0.80,maintain.helm.duplicate_secret_set_in_ci) - 🟡 [medium]
helm/templates/pvc.yaml:25— PVC のstorageClassNameがglobal.storageClassのみ参照しておりpersistence.storageClassを無視している (confidence: 0.80,code.helm.pvc_storageclass_global_only) - 🟡 [medium]
helm/values.yaml:54—persistenceに新旧2系統の設定スキーマが共存しており混乱しやすい (confidence: 0.78,maintain.helm.values_duplicate_persistence_schema) - 🟡 [medium]
helm/templates/secret.yaml:13— existingSecret 指定時に jwtSecret 等の required 検証が完全にスキップされ、キー不一致のまま Pod が起動できる (confidence: 0.75,sec.sast.authz.secret_bypass_via_existingSecret) - 🟡 [medium]
helm/templates/configmap.yaml:12— ConfigMap のMINIO_ENDPOINTがminio.enabled時のみ存在するが、configMapKeyRefのoptionalフラグが設定されていない (confidence: 0.62,code.helm.configmap_minio_endpoint_conditional) - 🔵 [low]
helm/templates/secret.yaml:23— Helm values 経由で渡されたシークレットが helm history / helm get values に平文で残る (confidence: 0.90,sec.sast.crypto.weak_secret_management) - 🔵 [low]
helm/values.yaml:103—legacySecrets: trueがデフォルトのため、新規インストールでも不要な Secret が2つ作成される (confidence: 0.75,maintain.helm.legacy_secrets_default_true)
前回 run からの未解決 finding: 1 件
head: b9251b1 | Orange Codens (P1)
There was a problem hiding this comment.
🍊 Orange Codens レビュー
高優先度の問題が 2 件あります。
helm template/--dry-runではlookupが空を返すため、secrets.existingSecretを使用した場合の必須キー検証が完全にスキップされます（CI でも実 install でも初回は無効）。secret.yamlで作成されるキー名はminio-secret-key/minio-access-keyですが、タスク仕様・コメントにはminio-root-passwordと記載されており、外部 Secret を準備するユーザーへの説明と実装が乖離しています。
また values.yaml に secrets.jwtSecret 等のデフォルトキーが存在しないため helm show values での発見性が低く、新規利用者の混乱を招く可能性があります。legacySecrets フォールバック周りの設計は丁寧ですが、移行終了バージョンの明示が望まれます。
🔒 セキュリティ: 本 PR の主要なセキュリティリスクは、Helm --set secrets.* フラグおよび $GITHUB_ENV へのシークレット平文書き込みによる CWE-312 (Cleartext Storage) である。コメントで警告を記載しているものの、デフォルトの使用例が安全でないフローを示しており、開発者がそのまま踏襲するリスクがある。existingSecret の lookup 検証は helm lint/dry-run では機能しないため、設計上の意図した検証が迂回される点も要注意。シークレット管理は secrets.existingSecret + 外部シークレットマネージャーをデフォルト推奨フローとし、--set secrets.* は明示的に非推奨として扱う設計変更を推奨する。
🔴 critical: 1 / 🟠 high: 4 / 🟡 medium: 4 / 🔵 low: 3
その他の指摘 (7 件)
- 🟡 [medium]
helm/values.yaml:85— secrets.jwtSecret / dbPassword / minioRootPassword / minioAccessKey が values.yaml に存在せずスキーマ定義も不明 (confidence: 0.90,maintainability.helm.values_schema_missing) - 🟡 [medium]
helm/templates/secret.yaml:17— existingSecret が存在しない場合にキー検証がスキップされる (confidence: 0.80,sec.sast.authz.secret_lookup_bypass) - 🟡 [medium]
.github/workflows/helm.yml:35— HELM_SECRET_SET_FLAGS を引用符なしで展開するとシェルの単語分割が想定外の動作を起こす可能性 (confidence: 0.72,code.helm.ci_shell_word_splitting) - 🟡 [medium]
helm/templates/pvc.yaml:6— PVC サイズの正規表現が Kubernetes 量形式を完全にカバーしていない (confidence: 0.65,code.helm.pvc_size_regex_incomplete) - 🔵 [low]
helm/templates/pvc.yaml:2— persistence.reposSize / persistence.repositories.size の二重フォールバックが複雑で将来の混乱を招く (confidence: 0.70,maintainability.helm.pvc_fallback_complexity) - 🔵 [low]
helm/templates/configmap.yaml:12— MINIO_ENDPOINT が minio.enabled=false の場合に ConfigMap から欠落し deployment.yaml の optional: true に依存している (confidence: 0.65,maintainability.helm.configmap_minio_conditional) - 🔵 [low]
helm/templates/configmap.yaml:11— ConfigMap に Git リポジトリの保存パスが平文で記載される (confidence: 0.60,sec.sast.infodisclosure.configmap_sensitive_path)
head: b78763d | Orange Codens (P1)
| --- | ||
| apiVersion: v1 | ||
| kind: Secret | ||
| metadata: |
There was a problem hiding this comment.
🔴 [critical] secret.yaml の minio キー名が deployment.yaml の参照と不一致
該当箇所:
minio-secret-key: {{ required "secrets.minioRootPassword is required when minio.enabled — pass via --set secrets.minioRootPassword=<value>" .Values.secrets.minioRootPassword | b64enc | quote }}
minio-access-key: {{ required "secrets.minioAccessKey is required when minio.enabled — pass via --set secrets.minioAccessKey=<value>" .Values.secrets.minioAccessKey | b64enc | quote }}タスク仕様（secret.yaml のコメント行 1–8）では minio-root-password というキー名が要求されているが、実際に作成されるキーは minio-secret-key になっている。deployment.yaml 側では key: minio-secret-key で参照しているため Pod 起動自体は成功するが、タスクの Verification Checklist「secret.yaml created with three keys (jwt-secret, db-password, minio-root-password)」との乖離があり、外部ドキュメントや既存の外部 Secret を minio-root-password キー名で準備したユーザーが existingSecret を使った場合にキーが見つからない問題が起きる。
また existingSecret の検証ブロック（行 29–35）は minio-secret-key の存在をチェックしているが、コメントに書かれた minio-root-password を期待するユーザーは混乱する。仕様に合わせて統一するか、コメントを実装に合わせて修正する必要がある。
code.helm.secret_key_mismatch | confidence: 0.88
| production deployments. | ||
| */}} | ||
| {{- if .Values.secrets.existingSecret }} | ||
| {{- $existing := lookup "v1" "Secret" .Release.Namespace .Values.secrets.existingSecret }} |
There was a problem hiding this comment.
🟠 [high] helm template / --dry-run では lookup が空を返し existingSecret の検証がスキップされる
該当箇所:
{{- $existing := lookup "v1" "Secret" .Release.Namespace .Values.secrets.existingSecret }}
{{- if $existing }}helm template や helm install --dry-run では lookup は常に空マップを返す（Helm の仕様）。そのため $existing が falsy になり、if $existing ブロックが評価されず、jwt-secret / db-password / minio-access-key / minio-secret-key のキー存在チェックが完全にスキップされる。
CI の helm lint / helm template ステップ（.github/workflows/helm.yml）でも secrets.existingSecret を設定した場合、検証が機能しない。実クラスターへの helm install 時も初回は Secret が存在しないため同様にスキップされ、起動後に Pod が CreateContainerConfigError になって初めて問題が発覚する。
lookup による検証は「アップグレード時に既存 Secret の内容を確認する」用途に限定し、初回インストールの検証は required 関数を使った別の手段で補完するか、ドキュメントに明示的に警告を追記すること。
code.helm.lookup_dry_run_unavailable | confidence: 0.92
| MINIO_ACCESS="$(openssl rand -hex 16)" | ||
| { | ||
| echo "HELM_SECRET_SET_FLAGS=--set secrets.jwtSecret=${JWT} --set secrets.dbPassword=${DB} --set secrets.minioRootPassword=${MINIO_ROOT} --set secrets.minioAccessKey=${MINIO_ACCESS}" | ||
| } >> "$GITHUB_ENV" |
There was a problem hiding this comment.
🟠 [high] CI で生成したシークレット値を GITHUB_ENV に平文で書き込んでいる
CWE-312: Cleartext Storage of Sensitive Information
該当箇所:
- name: Generate ephemeral CI secrets and helm --set flags
run: |
JWT="$(openssl rand -hex 32)"
DB="$(openssl rand -hex 32)"
MINIO_ROOT="$(openssl rand -hex 32)"
MINIO_ACCESS="$(openssl rand -hex 16)"
{
echo "HELM_SECRET_SET_FLAGS=--set secrets.jwtSecret=${JWT} --set secrets.dbPassword=${DB} --set secrets.minioRootPassword=${MINIO_ROOT} --set secrets.minioAccessKey=${MINIO_ACCESS}"
} >> "$GITHUB_ENV"$GITHUB_ENV に書き込まれた値はジョブのログやデバッグモードで露出する可能性がある。また HELM_SECRET_SET_FLAGS 変数にシークレット値が直接含まれるため、後続の helm lint / helm template / helm install --dry-run のコマンドライン引数としてプロセステーブルに現れ、同ホスト上の他プロセスから ps で読み取れる。
シークレット値は $GITHUB_ENV ではなく、::add-mask:: でマスクしてから環境変数に渡すか、GitHub Actions の env: コンテキストで step スコープに留めるべき。
```yaml
- name: Generate ephemeral CI secrets and helm --set flags
run: |
JWT="$(openssl rand -hex 32)"
DB="$(openssl rand -hex 32)"
MINIO_ROOT="$(openssl rand -hex 32)"
MINIO_ACCESS="$(openssl rand -hex 16)"
echo "::add-mask::${JWT}"
echo "::add-mask::${DB}"
echo "::add-mask::${MINIO_ROOT}"
echo "::add-mask::${MINIO_ACCESS}"
# フラグをファイルに分割して渡すか、各 helm コマンドへ直接 env var として注入する
echo "CI_JWT=${JWT}" >> "$GITHUB_ENV"
echo "CI_DB=${DB}" >> "$GITHUB_ENV"
echo "CI_MINIO_ROOT=${MINIO_ROOT}" >> "$GITHUB_ENV"
echo "CI_MINIO_ACCESS=${MINIO_ACCESS}" >> "$GITHUB_ENV"その後、helm コマンドでは --set secrets.jwtSecret="${CI_JWT}" のように個別に参照してコマンドラインへの直接展開を最小化する。
<sub>`sec.sast.crypto.secret_in_env` | confidence: 0.90</sub>
| Warning: values passed via --set secrets.* are stored in Helm release metadata | ||
| (helm get values / helm history). Prefer secrets.existingSecret or --set-file for | ||
| production deployments. | ||
| */}} |
There was a problem hiding this comment.
🟠 [high] --set で渡したシークレットが Helm リリースメタデータに平文保存される
CWE-312: Cleartext Storage of Sensitive Information
コメント自体がリスクを認識しているものの、デフォルトの利用方法として --set secrets.jwtSecret=... を推奨しており、values.yaml の secrets セクションも同様に --set を例示している。helm get values / helm history を実行できる RBAC 権限を持つ人物はシークレット値を平文で読み取れる。
該当箇所:
{{/*
Secrets should be passed at install time, e.g.:
helm install open-git ./helm \
--set secrets.jwtSecret=your-jwt-secret \
--set secrets.dbPassword=your-db-password \
--set secrets.minioRootPassword=your-minio-password \
--set secrets.minioAccessKey=your-minio-access-key
...
Warning: values passed via --set secrets.* are stored in Helm release metadata
(helm get values / helm history). Prefer secrets.existingSecret or --set-file for
production deployments.
*/}}
また values.yaml にも同様の案内が記載されている:
# Example: --set secrets.jwtSecret=... --set secrets.minioAccessKey=... --set secrets.minioRootPassword=...
コメントで警告を記載しているだけでは不十分。デフォルトフローを secrets.existingSecret または --set-file に誘導すべき。CI ワークフロー (helm.yml) でも --set secrets.*= フラグをそのまま $GITHUB_ENV に書き込んでおり、ジョブログやアーティファクトからの漏洩リスクがある。
production 向けドキュメント・デフォルト値を `existingSecret` 優先に変更し、`--set secrets.*` を非推奨とする。CI ではシークレットを `$GITHUB_ENV` に展開せず GitHub Actions の `env:` コンテキストか step レベルの masked secret を使用する。sec.sast.crypto.secret_in_helm_metadata | confidence: 0.85
| - name: MINIO_ACCESS_KEY | ||
| value: {{ .Values.minio.accessKey | quote }} | ||
| valueFrom: | ||
| secretKeyRef: |
There was a problem hiding this comment.
🟠 [high] MINIO_ENDPOINT の configMapKeyRef に optional: true が付いているが ConfigMap 側はキー自体が存在しない場合がある
該当箇所:
valueFrom:
configMapKeyRef:
name: {{ include "open-git.fullname" . }}
key: MINIO_ENDPOINT
optional: trueconfigmap.yaml では MINIO_ENDPOINT は {{- if .Values.minio.enabled }} ブロックの中にのみ存在する。deployment.yaml 側も {{- if .Values.minio.enabled }} ブロック内で参照しているため、minio.enabled=false の場合に MINIO_ENDPOINT env ブロックはレンダリングされない。
しかし optional: true を付けることで「ConfigMap 自体が存在しない場合」も許容してしまう。ConfigMap は minio.enabled に関係なく常に作成されるため実害は出にくいが、デプロイ順序の問題（ConfigMap が先に作成されていない状況）でも Pod が起動してしまい、MINIO_ENDPOINT が空のまま接続エラーになるリスクがある。他の configMapKeyRef（PORT、DB_TYPE、GIT_STORAGE_PATH、REDIS_ADDR）には optional: true が付いていないので統一性もない。意図して optional にしているなら理由をコメントで明示すべき。
@@ -79,6 +79,5 @@
valueFrom:
configMapKeyRef:
name: {{ include "open-git.fullname" . }}
key: MINIO_ENDPOINT
- optional: truecode.helm.configmap_optional_key_inconsistency | confidence: 0.80
…cret flags; drop superseded ConfigMap/PVC/Deployment dups - helm/templates/secret.yaml: NEW unified -secrets Secret + optional legacy -db/-minio Secrets that the backend/worker/migration Deployments reference (nothing on main created these). No name collision with bitnami subcharts. - helm/values.yaml: add secrets.legacySecrets (true) so the referenced -db/-minio Secrets are rendered. - .github/workflows/helm.yml: generate ephemeral CI secrets and pass --set flags (required by secret.yaml's required validators). - ConfigMap, PVC, Deployment, persistence schema: superseded by main's newer design -> took main's (dropped PR duplicates).
There was a problem hiding this comment.
🍊 Orange Codens レビュー
Secret 分離と CI 向け --set secrets.* 注入の方向性は妥当ですが、Template render check だけ secrets 未指定のまま残っており、required() 付き jwt-secret により CI が高確率で失敗します。加えて PRD 指定の minio-root-password キー名との不一致と、existingSecret 未存在時の無警告スキップはデプロイ前に検知しにくい点です。
🔒 セキュリティ: Secret/ConfigMap 分離自体は Deployment 内平文 env より改善方向ですが、--set secrets.* 経路は Helm release metadata に資格情報が残るため、本番では existingSecret 必須化が必要です。CI ワークフローは短命シークレットですが、GITHUB_ENV 連結と CLI --set によりログ/プロセス引数経由の露出リスクがあります。SQL injection・SSRF・認可漏れ等のアプリケーション論理脆弱性は本 diff には含まれていません。
🔴 critical: 1 / 🟡 medium: 4 / 🔵 low: 3 / ⚪ info: 1
その他の指摘 (8 件)
- 🟡 [medium]
helm/templates/secret.yaml:44— Helm release metadata へのシークレット平文保存リスク (confidence: 0.90,sec.sast.config.helm_release_metadata) - 🟡 [medium]
helm/templates/secret.yaml:47— Task spec の Secret キー名 minio-root-password と不一致 (confidence: 0.85,code.requirements.key_name_mismatch) - 🟡 [medium]
helm/templates/secret.yaml:17— existingSecret 指定時に Secret が見つからないと無警告で Secret を生成しない (confidence: 0.80,code.logic.existing_secret_lookup_silent) - 🟡 [medium]
helm/values.yaml:76— Task spec で要求された secrets / persistence の values 定義が diff に不足 (confidence: 0.75,code.requirements.values_schema_incomplete) - 🔵 [low]
.github/workflows/helm.yml:27— CI で生成したシークレットを GITHUB_ENV に平文連結 (confidence: 0.85,sec.sast.config.cli_secret_exposure) - 🔵 [low]
.github/workflows/helm.yml:36— Helm コマンドライン引数へのシークレット埋め込み (confidence: 0.85,sec.sast.config.cli_secret_exposure) - 🔵 [low]
helm/values.yaml:86— legacySecrets デフォルト true による同一資格情報の複製 (confidence: 0.75,sec.sast.config.secret_duplication) - ⚪ [info]
helm/templates/secret.yaml:17— Secret テンプレートの条件分岐に対する chart test が diff に無い (confidence: 0.65,code.testing.missing_chart_tests)
head: e1bded7 | Orange Codens (P1)
|
|
||
| - name: Dry-run install | ||
| run: helm install gitforge helm/ --dry-run=client --set ingress.host=test.example.com | ||
| run: | |
There was a problem hiding this comment.
🔴 [critical] Template render check が secrets 未指定のまま実行される
helm lint / Validate templates / Dry-run install には ${HELM_SECRET_SET_FLAGS} が追加されていますが、Template render check ステップだけが secrets を渡さないままです。一方 secret.yaml では jwt-secret が required() 付きで定義されているため、このステップは空 values で helm template した際に失敗します。
該当箇所:
- name: Template render check
run: helm template gitforge helm/ --set ingress.host=test.example.com >/dev/null jwt-secret: {{ required "secrets.jwtSecret is required — pass via --set secrets.jwtSecret=<value>" .Values.secrets.jwtSecret | b64enc | quote }}@@ -45,2 +45,2 @@
- name: Template render check
- run: helm template gitforge helm/ --set ingress.host=test.example.com >/dev/null
+ run: helm template gitforge helm/ --set ingress.host=test.example.com ${HELM_SECRET_SET_FLAGS} >/dev/nullcode.logic.missing_required_values | confidence: 0.95
# Conflicts: # helm/templates/secret.yaml
There was a problem hiding this comment.
🍊 Orange Codens レビュー
提供 diff は Task / PR タイトルが求める PVC・ConfigMap・Deployment / values 更新を含まず、secret-workloads.yaml のみ追加しています。加えて Secret キー構成（jwt-secret 欠落、db-password / minio-root-password との不一致）が Task 指定と乖離しており、Deployment 側変更とセットでマージされない場合は Pod 起動失敗につながる可能性が高いです。テンプレート内の lookup / randAlphaNum ロジック自体は diff 上で明確な構文エラーは見当たりません。
🔒 セキュリティ: 本 diff はインライン環境変数から Kubernetes Secret への分離という改善方向ですが、Helm values から直接 Secret を生成する経路では認証情報がリリース履歴に残る典型的なリスク（CWE-522）が残ります。lookup による既存 Secret 再利用はアップグレードの冪等性に寄与しますが、namespace 内での Secret 先占めという低確率の脅威モデルも考慮余地があります。SQL injection・SSRF・暗号アルゴリズム誤用などのアプリケーション層の論理脆弱性は diff 上では検出されませんでした。
🔴 critical: 1 / 🟠 high: 2 / 🟡 medium: 4 / 🔵 low: 1 / ⚪ info: 1
その他の指摘 (6 件)
- 🟡 [medium]
helm/templates/secret-workloads.yaml:8— Secret 供給方針が Task の --set secrets 要件と矛盾 (confidence: 0.85,maintainability.design.values_wiring_divergence) - 🟡 [medium]
helm/templates/secret-workloads.yaml:24— Helm values 経由の DB パスワードがリリース履歴に残る可能性 (confidence: 0.82,sec.sast.crypto.insufficient_credential_protection) - 🟡 [medium]
helm/templates/secret-workloads.yaml:43— Helm values 経由の MinIO secret-key がリリース履歴に残る可能性 (confidence: 0.82,sec.sast.crypto.insufficient_credential_protection) - 🟡 [medium]
helm/templates/secret-workloads.yaml:1— helm lint / テスト実行の証跡が diff にない (confidence: 0.75,maintainability.testing.missing_verification) - 🔵 [low]
helm/templates/secret-workloads.yaml:26— 既存 Secret の lookup 採用により名前空間内の先占め Secret が使われる可能性 (confidence: 0.55,sec.sast.authz.secret_squatting) - ⚪ [info]
helm/templates/secret-workloads.yaml:3— Deployment / Job 参照は diff 上未確認 (confidence: 0.40,maintainability.docs.unverified_integration_claim)
head: 0b57369 | Orange Codens (P1)
| {{- else }} | ||
| secret-key: {{ randAlphaNum 32 | b64enc | quote }} | ||
| {{- end }} | ||
| {{- end }} |
There was a problem hiding this comment.
🔴 [critical] Task 指定の jwt-secret が Secret テンプレートに存在しない
Task Step 2 および Verification Checklist では Secret に jwt-secret / db-password / minio-root-password の 3 キーが必要です。diff 上のテンプレートは postgres 用と minio 用の 2 Secret のみを条件付きで生成しており、jwt-secret を作成するブロックがありません。Deployment が JWT_SECRET を secretKeyRef で参照する変更（Task Step 4）とセットでマージされる前提なら、インストール時に Secret が存在せず Pod 起動が失敗します。
該当箇所:
{{- if eq .Values.db.type "postgres" }}
...
postgres-password: {{ .Values.db.postgres.password | b64enc | quote }}
...
{{- end }}
{{- if .Values.minio.enabled }}
...
secret-key: {{ .Values.minio.secretKey | b64enc | quote }}
...
{{- end }}code.logic.missing_secret_key | confidence: 0.90
| {{- else }} | ||
| secret-key: {{ randAlphaNum 32 | b64enc | quote }} | ||
| {{- end }} | ||
| {{- end }} |
There was a problem hiding this comment.
🟠 [high] PR スコープが Task / PR タイトルと一致しない
PR タイトルおよび Task Goal では pvc.yaml / secret.yaml / configmap.yaml の追加と deployment.yaml・values.yaml の更新が求められていますが、提供 diff には secret-workloads.yaml の新規追加のみが含まれています。Task で必須とされた PVC・ConfigMap・Deployment 参照の変更が diff 上に存在せず、縦串要件を満たしていません。
該当箇所:
{{/*
Workload Secrets referenced by the backend Deployment, worker Deployment, and
migration Job. These hold the credentials the application pods consume directly:
- <fullname>-db (key: postgres-password) — only when db.type == "postgres"
- <fullname>-minio (key: secret-key) — only when minio.enabled
...
{{- end }}maintainability.requirements.prd_mismatch | confidence: 0.95
| type: Opaque | ||
| data: | ||
| {{- if .Values.minio.secretKey }} | ||
| secret-key: {{ .Values.minio.secretKey | b64enc | quote }} |
There was a problem hiding this comment.
🟠 [high] Secret キー名が Task 指定と不一致
Task では単一 Secret 内のキー名として db-password と minio-root-password が指定されていますが、diff では別 Secret 名・別キー名を使用しています。Task Step 4 が secretKeyRef.key: db-password / minio-root-password を前提としている場合、生成される Secret と Deployment 参照が一致せず env 注入に失敗します。
該当箇所:
postgres-password: {{ .Values.db.postgres.password | b64enc | quote }}
...
secret-key: {{ .Values.minio.secretKey | b64enc | quote }}Task 指定: db-password, minio-root-password
@@ -24,1 +24,1 @@
- postgres-password: {{ .Values.db.postgres.password | b64enc | quote }}
+ db-password: {{ .Values.db.postgres.password | b64enc | quote }}
@@ -45,1 +45,1 @@
- secret-key: {{ .Values.minio.secretKey | b64enc | quote }}
+ minio-root-password: {{ .Values.minio.secretKey | b64enc | quote }}code.logic.secret_key_name_mismatch | confidence: 0.88
1 participant
Summary
Type of Change
Testing
Checklist
Task Goal
Target Repository
Corevice/open-gitAll work for this task belongs in this repository. Do the implementation inside this repository's directory in the workspace; do not search or edit other repositories unless this task explicitly requires a cross-repo change.
Context
The Helm chart currently embeds all env vars directly in the Deployment template, making secret management insecure and persistence impossible on restarts.
Steps
open-git/helm/templates/pvc.yaml— two PVCs:{{ include "forge.fullname" . }}-repos(storage:{{ .Values.persistence.reposSize | default "20Gi" }}); wrap in{{- if .Values.persistence.enabled }}conditionalopen-git/helm/templates/secret.yaml— Kind Secret, data keysjwt-secret,db-password,minio-root-passwordbase64-encoded from corresponding values; add note that values should be passed via--set secrets.X=Yat install timeopen-git/helm/templates/configmap.yaml— Kind ConfigMap, data keys forDB_TYPE,REDIS_ADDR,PORT,GIT_STORAGE_PATH,MINIO_ENDPOINTfrom valuesopen-git/helm/templates/deployment.yaml— replace inline env value entries for secrets withsecretKeyRefblocks referencing the Secret; replace config entries withconfigMapKeyRefblocks referencing the ConfigMapopen-git/helm/values.yaml— addpersistence: {enabled: true, reposSize: "20Gi"}andsecrets: {jwtSecret: "", dbPassword: "", minioRootPassword: ""}sectionsVerification Checklist
Original PRD Content
v1.0リリース 実装PRD
Features
v1.0リリース 残実装リスト（縦切り）
**注意: 抽出済み scaffold には routes / forms / components が一切検出されていません
Changes Made
Helm chart の
既存テ
ンプレートと
values
を確認し、
Secret/
ConfigMap/P
VC への分
離を実
装
します
。
既
存チャ
ートは
open -git.fullnameを使っている
ため、それ
に合わせ
て Secret
/ConfigMap/P
VC を作成
し、deployment を
更新
します
。
values.yamlからタ
スク指定
外の
repos Pathを削除します
。
Hel
m chart の
Secret
/ ConfigMap /
PVC 分離
を実
装しました。
作成
・更新
内容
**
pvc .yaml** —persistence.enabledが true のとき
- reposPVCを作成（
サイ
ズは
p ersistence.reposSize、デ
フォルト 20
Gi）
secret.yaml—jwt -secret、db-password、min io-root-passwordを base
64 エ
ンコード。
イン
ストール時は
--set secrets.X =Yで渡す旨を
コメントに
記載
**
configmap.yaml** —DB _TYPE、RED IS_ADDR、PORT、GIT_STORAGE_PATH、MINIO_ENDPOINTの5 キ
ー
deployment.yaml—上
記 Secret
/
ConfigMap を
secretKeyRef/
configMap KeyRefで参照。
JWT _SECRETとGIT_STORAGE_PATHも追加values .yaml—persistence.enabled/
reposSizeとsecrets .jwtSecret/
dbPassword/min ioRootPasswordを追加
Hel
m ヘ
ルパーは
既存の
open-git.fullnameを使用してい
ます（
forge.fullnameは未定
義のため
）。
[P
URPLE
-MODIFIED-F
ILES]
open-git
/helm/templates
/pvc.yaml
open-git/helm
/templates/secret.yaml
open-git/
helm/templates/configmap
.yaml
open-git
/helm/templates/de
ployment.yaml
open
-git/helm/
values.yaml
[/
PURPLE
-MODIFIED-F
ILES]
Task ID:
019f0d82-1e54-749b-a35a-87ed244aa3e7Generated by Purple Codens