Menú
Secret 管理 4 方式（Vault dynamic / Vault static via ESO / Vault Transit / SealedSecret）の健全性を一括チェック — Vault seal 状態、ESO 同期、SealedSecret 復号、関連 cert をまとめて診断
Instalar con Codex o Claude Copia este prompt, pégalo en Codex, Claude u otro asistente, y deja que revise la página de la skill y la instale por ti.
Basado en la clasificación ocupacional SOC
Longhorn の健全性チェック — volume robustness（degraded 検出）、node 容量、R2 バックアップの鮮度、recurring job の動作状況を一括診断
Scaffold a new infrastructure component, choosing the right layout (Helm multi-source / raw YAML / ApplicationSet) for its category
Create a new Sealed Secret — generates raw secret, seals it with kubeseal, and places it in the correct resources/ directory
Troubleshoot a specific infrastructure component — resolve namespace, check pods, events, logs, and Argo CD sync status
全 Helm Application の chart バージョン鮮度を一括チェック — 各 app.yaml の targetRevision を upstream 最新と突き合わせ、更新候補を優先度付きでレポート（/helm-upgrade の前段）
OpenAI Codex に作業を委譲する。コードレビュー、セカンドオピニオン、別解の生成、調査・分析を Codex にやらせたいとき（「Codex にレビューさせて」「Codex に聞いて」「Codex の意見も欲しい」等）に使う。
| name | secret-health |
| description | Secret 管理 4 方式（Vault dynamic / Vault static via ESO / Vault Transit / SealedSecret）の健全性を一括チェック — Vault seal 状態、ESO 同期、SealedSecret 復号、関連 cert をまとめて診断 |
| argument-hint | null |
4 方式が併用されているため（SoT: docs/secret-management/index.md）、障害時の切り分けに必要な状態を 1 回で横断確認する。
Vault 本体:
kubectl get pods -n vault -o wide
kubectl exec -n vault vault-0 -- vault status
Sealed: false を確認。sealed なら以降の ESO / dynamic creds は全滅するので最優先で報告vault status の HA Mode: active の pod が現リーダーvault-aws-kms-credentials（SealedSecret、vault ns）— これが壊れると再起動時に unseal できないClusterSecretStore（ESO ↔ Vault の接続）:
kubectl get clustersecretstore -o wide
vault-backend が Valid / Ready であること。ここが死んでいると全 ExternalSecret が巻き添えExternalSecret 同期状態（Vault static 方式）:
kubectl get externalsecret -A -o custom-columns='NAMESPACE:.metadata.namespace,NAME:.metadata.name,STORE:.spec.secretStoreRef.name,REFRESH:.spec.refreshInterval,STATUS:.status.conditions[0].reason,READY:.status.conditions[0].status'
SecretSynced / True 以外を列挙。SecretSyncedError は Vault path の存在・token 権限を疑うSTORE が <none> の行は異常ではなく generator 参照（dataFrom.sourceRef.generatorRef、下記 step 4）の ExternalSecretconditions[0] は配列順序依存。判定が怪しい場合は素の kubectl get externalsecret -A（READY/STATUS 列）と突き合わせるDynamic creds（ESO generator 方式、DB credential 系）:
# このクラスタは VSO ではなく ESO generator (generators.external-secrets.io) を採用
kubectl get vaultdynamicsecret.generators.external-secrets.io -A
kubectl get externalsecret -A -o custom-columns='NS:.metadata.namespace,NAME:.metadata.name,GEN:.spec.dataFrom[0].sourceRef.generatorRef.name' | grep -v '<none>'
must be owner of table 42501）。これは secret 配布ではなく Vault DB role 定義側の問題として切り分けるSealedSecret 復号状態:
kubectl get sealedsecret -A
# controller は kube-system に居る（sealed-secrets ns ではない）
kubectl logs -n kube-system -l app.kubernetes.io/name=sealed-secrets --tail=50 | grep -iE "error|unable" || echo "no decryption errors"
|| echo が誤って正常表示する。先に kubectl get pods -A -l app.kubernetes.io/name=sealed-secrets でヒットを確認すること/sealed-secret で再封緘を提案Secret 消費側の整合:
kubectl get pods -A --field-selector=status.phase=Pending -o wide 2>/dev/null
kubectl get events -A --field-selector reason=FailedMount,type=Warning 2>/dev/null | head -20
CreateContainerConfigError / FailedMount を検出spec.target.name は ES 名と異なることがある（例: ES postgres-polaris → Secret postgres-polaris-cred）。Secret 不在の判定は target 名で行うReloader の生存確認（rotation の最終工程）:
kubectl get pods -n reloader
Summary:
/troubleshoot <component> への導線を示す/cert-check を案内（本 skill では深追いしない）