@raishin/vanguard-frontier-agentic 1.2.0 → 1.4.0

package/skills/kubernetes/kubernetes-pod-spec-review/references/workflow-and-output.md

@@ -0,0 +1,229 @@
+# Workflow and Output Contract
+
+## Review Workflow
+
+### Step 1 — Identify the workload type
+
+Determine whether the input is a Pod, Deployment, StatefulSet, DaemonSet, Job, or CronJob spec. The review scope differs:
+
+- **Pod / Deployment** — full probe, resource, securityContext, topology spread review
+- **StatefulSet** — same as Deployment plus PVC template review, ordered startup considerations
+- **DaemonSet** — probe review less critical; focus on host namespace usage, privileged mode, resource limits
+- **Job / CronJob** — no readiness probe required; focus on `activeDeadlineSeconds`, `backoffLimit`, resource limits
+
+### Step 2 — Probe review
+
+```yaml
+# Minimum production-ready probe configuration
+livenessProbe:
+  httpGet:
+    path: /healthz
+    port: 8080
+  initialDelaySeconds: 15
+  periodSeconds: 20
+  failureThreshold: 3       # >=3 to tolerate GC pauses
+  timeoutSeconds: 5
+
+readinessProbe:
+  httpGet:
+    path: /ready
+    port: 8080
+  initialDelaySeconds: 10
+  periodSeconds: 10
+  failureThreshold: 3
+  timeoutSeconds: 3
+
+startupProbe:               # required if startup > 30s
+  httpGet:
+    path: /healthz
+    port: 8080
+  failureThreshold: 30      # 30 * periodSeconds(10) = 300s max startup
+  periodSeconds: 10
+```
+
+**Flags:**
+- Missing `livenessProbe` on a long-running container — HIGH
+- Missing `readinessProbe` on a Deployment that receives traffic — HIGH
+- `livenessProbe.failureThreshold: 1` or `2` — HIGH (kills pod during GC pause)
+- `readinessProbe.initialDelaySeconds` < known startup time — HIGH (probe fails before app ready)
+- Missing `startupProbe` when app startup > 30s — MEDIUM
+
+### Step 3 — Resource QoS review
+
+```yaml
+resources:
+  requests:
+    cpu: "250m"
+    memory: "256Mi"
+  limits:
+    cpu: "500m"    # CPU limits cause throttling; consider removing if not required
+    memory: "512Mi"
+```
+
+**QoS tier resolution:**
+
+| Condition | QoS Class | Risk |
+|-----------|-----------|------|
+| `requests == limits` for all containers | Guaranteed | Lowest eviction priority |
+| `requests` set, `limits` not equal | Burstable | Evicted under node pressure |
+| No `requests`, no `limits` | BestEffort | First evicted under any pressure |
+
+**Flags:**
+- No `resources.requests` — MEDIUM (BestEffort QoS, evicted first)
+- `limits.memory` without `requests.memory` — MEDIUM (Burstable, OOM killed under node pressure)
+- `limits.cpu` set to a value significantly lower than typical usage — MEDIUM (CPU throttle)
+- Critical workload without Guaranteed QoS (`requests != limits`) — MEDIUM
+
+### Step 4 — securityContext review
+
+```yaml
+# Pod-level
+spec:
+  securityContext:
+    runAsNonRoot: true
+    runAsUser: 1000
+    seccompProfile:
+      type: RuntimeDefault   # K8s 1.22+
+
+# Container-level
+containers:
+  - name: app
+    securityContext:
+      allowPrivilegeEscalation: false
+      readOnlyRootFilesystem: true
+      capabilities:
+        drop:
+          - ALL
+        add: []              # only add specific caps if truly required
+```
+
+**Flags:**
+- Missing `runAsNonRoot: true` — HIGH (runs as root by default)
+- `allowPrivilegeEscalation: true` or missing — HIGH
+- Missing `readOnlyRootFilesystem: true` — MEDIUM (writable filesystem enables malware persistence)
+- Missing `capabilities.drop: [ALL]` — MEDIUM
+- `privileged: true` — CRITICAL (host-level access)
+- Missing `seccompProfile` — LOW (defaults to unconfined syscall access)
+
+### Step 5 — Image pull policy and tag review
+
+```yaml
+# Correct for digest-pinned images
+image: myregistry/myapp@sha256:abc123...
+imagePullPolicy: IfNotPresent
+
+# Correct for latest or mutable tags
+image: myregistry/myapp:latest
+imagePullPolicy: Always
+```
+
+**Flags:**
+- `latest` tag with `imagePullPolicy: IfNotPresent` — HIGH (stale image after first pull)
+- `latest` tag at all — MEDIUM (non-deterministic deployments)
+- No image digest pinning for critical workloads — LOW
+
+### Step 6 — Secret and ConfigMap consumption review
+
+```yaml
+# PREFERRED: Volume mount (secret not in env, not in describe output)
+volumes:
+  - name: db-creds
+    secret:
+      secretName: db-credentials
+containers:
+  - volumeMounts:
+      - name: db-creds
+        mountPath: /etc/secrets
+        readOnly: true
+
+# ACCEPTABLE: Specific env var from secret key
+env:
+  - name: DB_PASSWORD
+    valueFrom:
+      secretKeyRef:
+        name: db-credentials
+        key: password
+
+# AVOID: Bulk-mount exposes ALL secret keys including unused ones
+envFrom:
+  - secretRef:
+      name: db-credentials
+```
+
+**Flags:**
+- `envFrom.secretRef` bulk-mount — MEDIUM (all keys exposed to process env and kubectl describe)
+- `env.valueFrom.secretKeyRef` — ACCEPTABLE (only named key exposed)
+- Secret as environment variable (either method) — NOTE (appears in /proc/self/environ)
+
+### Step 7 — Topology spread and affinity review
+
+```yaml
+# Preferred: topology spread (K8s 1.19+)
+topologySpreadConstraints:
+  - maxSkew: 1
+    topologyKey: topology.kubernetes.io/zone
+    whenUnsatisfiable: DoNotSchedule
+    labelSelector:
+      matchLabels:
+        app: myapp
+
+# Also check podAntiAffinity for legacy configs
+affinity:
+  podAntiAffinity:
+    preferredDuringSchedulingIgnoredDuringExecution:
+      - weight: 100
+        podAffinityTerm:
+          topologyKey: kubernetes.io/hostname
+          labelSelector:
+            matchLabels:
+              app: myapp
+```
+
+**Flags:**
+- Multi-replica Deployment (>1 replica) with no `topologySpreadConstraints` and no `podAntiAffinity` — MEDIUM
+- `topologySpreadConstraints` present but `topologyKey: kubernetes.io/hostname` only (no zone spread) — LOW
+- `whenUnsatisfiable: ScheduleAnyway` on a critical workload — LOW (spread not enforced)
+
+### Step 8 — Termination grace period review
+
+```yaml
+spec:
+  terminationGracePeriodSeconds: 60  # increase for gRPC, database draining
+```
+
+**Flags:**
+- Default 30s for gRPC servers with long-lived streams — MEDIUM
+- Default 30s for database pods (PostgreSQL, MySQL) that need checkpoint time — MEDIUM
+- `terminationGracePeriodSeconds: 0` — HIGH (immediate SIGKILL, no graceful shutdown)
+
+---
+
+## Output Format
+
+Return findings in this structure:
+
+### Finding: `<short title>`
+
+| Field | Value |
+|-------|-------|
+| Severity | CRITICAL / HIGH / MEDIUM / LOW |
+| Field path | `spec.containers[0].livenessProbe` |
+| Evidence | documentation-based / live evidence / inference |
+| Description | What is wrong and why it matters |
+| Remediation | YAML snippet or command |
+
+---
+
+### Overall Verdict
+
+| Category | Status |
+|----------|--------|
+| Probes | PASS / FAIL |
+| Resource QoS | PASS / FAIL |
+| Security context | PASS / FAIL |
+| Image hygiene | PASS / FAIL |
+| Secret consumption | PASS / FAIL |
+| Topology spread | PASS / FAIL |
+| Termination grace | PASS / FAIL |
+
+**Production-ready:** YES / NO / CONDITIONAL (list conditions)

package/skills/kubernetes/kubernetes-rbac-review/SKILL.md

@@ -0,0 +1,41 @@
+---
+name: kubernetes-rbac-review
+description: Use this skill for Kubernetes RBAC, Role, ClusterRole, RoleBinding, ClusterRoleBinding, ServiceAccount, workload identity, or least-privilege review tasks. Trigger when the user asks whether cluster access is too broad, how to grant workload permissions safely, or how to audit RBAC state.
+allowed-tools: Read Grep Glob
+metadata:
+  author: github: Raishin
+  version: 0.1.0
+  updated: "2026-05-05"
+  category: security
+---
+
+# Kubernetes RBAC Review
+
+## Purpose
+
+Review Kubernetes RBAC objects — Roles, ClusterRoles, RoleBindings, ClusterRoleBindings, and ServiceAccounts — against least privilege, namespace scope minimization, and operational safety.
+
+## Lean operating rules
+
+- Prefer live cluster evidence (`kubectl auth can-i`, `kubectl get rolebinding`, audit logs) when the active client exposes it; otherwise fall back to official Kubernetes documentation and sanitized user evidence.
+- Separate confirmed facts from inference. If state was not queried or shown, say so.
+- Challenge cluster-scoped access granted to workloads that only need namespace-scoped access.
+- Challenge wildcard verbs (`*`), wildcard resources (`*`), and wildcard API groups (`*`) unless explicitly justified.
+- Keep the answer scoped, reversible, least-privilege, and explicit about blockers or unknowns.
+
+## References
+
+Load these only when needed:
+
+- [Evidence path and tooling](references/mcp-and-evidence.md) — use when choosing live cluster evidence, confirming MCP capability, or switching to documentation mode.
+- [Workflow and output contract](references/workflow-and-output.md) — use when executing the full review, applying stress checks, or formatting the final answer.
+- [Official sources](references/official-sources.md) — use when you need the detailed Kubernetes documentation list or source notes.
+
+## Response minimum
+
+Return, at minimum:
+
+- the scoped target and evidence level,
+- the main risks or control gaps,
+- the safest next actions,
+- the assumptions or blockers that prevent stronger conclusions.

package/skills/kubernetes/kubernetes-rbac-review/metadata.json

@@ -0,0 +1,27 @@
+{
+  "id": "kubernetes-rbac-review",
+  "name": "Kubernetes RBAC Review",
+  "type": "skill",
+  "provider": "kubernetes",
+  "harnesses": [
+    "codex",
+    "claude-code",
+    "cursor",
+    "gemini",
+    "kiro",
+    "other"
+  ],
+  "summary": "Review Kubernetes Roles, ClusterRoles, RoleBindings, ClusterRoleBindings, and ServiceAccounts for least-privilege, namespace-scope, and workload identity safety.",
+  "source_type": "original",
+  "official_docs": [
+    "https://kubernetes.io/docs/reference/access-authn-authz/rbac/",
+    "https://kubernetes.io/docs/concepts/security/rbac-good-practices/",
+    "https://kubernetes.io/docs/reference/access-authn-authz/authorization/",
+    "https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/"
+  ],
+  "security_notes": "Do not recommend ClusterAdmin or wildcard bindings unless explicitly justified. Prefer namespace-scoped Roles over ClusterRoles for workloads that do not need cluster-wide access. Do not auto-mount service account tokens unless the workload requires API server access.",
+  "last_verified": "2026-05-01",
+  "path": "skills/kubernetes/kubernetes-rbac-review",
+  "author": "github: Raishin",
+  "version": "0.1.0"
+}

package/skills/kubernetes/kubernetes-rbac-review/references/mcp-and-evidence.md

@@ -0,0 +1,34 @@
+# Evidence Path and Tooling
+
+## Evidence path
+
+1. Prefer live cluster evidence when the active client exposes relevant Kubernetes MCP capabilities or a working `kubectl` context.
+2. Fall back to official Kubernetes documentation when live inspection is unavailable, incomplete, or unsafe.
+3. Ask only for sanitized RBAC YAML or `kubectl` output when current-state proof matters.
+4. Label conclusions as `live evidence`, `documentation-based`, `sanitized user evidence`, or `inference`.
+
+## Useful live-evidence commands
+
+```shell
+# List all RoleBindings in a namespace
+kubectl get rolebindings -n <namespace> -o yaml
+
+# List all ClusterRoleBindings
+kubectl get clusterrolebindings -o yaml
+
+# Check effective permissions for a ServiceAccount
+kubectl auth can-i --list --as=system:serviceaccount:<namespace>:<sa-name>
+
+# Check a specific verb/resource
+kubectl auth can-i <verb> <resource> --as=system:serviceaccount:<namespace>:<sa-name> -n <namespace>
+
+# Describe a Role or ClusterRole
+kubectl describe role <name> -n <namespace>
+kubectl describe clusterrole <name>
+```
+
+## Platform-agnostic execution
+
+- Keep examples neutral with placeholders until the user's cluster context and toolchain are known.
+- Do not request kubeconfig files, bearer tokens, service account JWT tokens, or cloud-provider credentials in chat.
+- If a Kubernetes MCP server or kubectl is unavailable, say so and fall back to reviewing sanitized YAML provided by the user.

package/skills/kubernetes/kubernetes-rbac-review/references/official-sources.md

@@ -0,0 +1,22 @@
+# Official Sources
+
+Load these only when needed:
+
+- [Using RBAC Authorization](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) — use for Role, ClusterRole, RoleBinding, ClusterRoleBinding structure, aggregation rules, default roles, and `kubectl auth` usage.
+- [RBAC Good Practices](https://kubernetes.io/docs/concepts/security/rbac-good-practices/) — use for least privilege, wildcard cautions, privilege escalation paths, impersonation risks, and workload namespace isolation.
+- [Authorization Overview](https://kubernetes.io/docs/reference/access-authn-authz/authorization/) — use when confirming how Kubernetes evaluates requests and which authorizers are stacked.
+- [Configure Service Accounts for Pods](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/) — use for `automountServiceAccountToken`, dedicated ServiceAccount patterns, and token projection.
+- [Kubernetes Security Checklist](https://kubernetes.io/docs/concepts/security/security-checklist/) — use for a holistic posture check covering RBAC alongside admission, network policies, and pod security.
+- [Bound Service Account Tokens](https://kubernetes.io/docs/reference/access-authn-authz/service-accounts-admin/#bound-service-account-tokens) — use when reviewing projected token lifetimes, audience binding, and migration from legacy auto-mounted tokens.
+
+## Grounded insights worth carrying into the skill
+
+- Kubernetes RBAC is additive: there are no deny rules. Any binding that grants a permission cannot be overridden by another binding.
+- `pods/exec` and `pods/attach` are equivalent to remote-shell access on any pod; treat both as high-severity grants requiring explicit justification.
+- `pods/portforward` tunnels arbitrary TCP to pod ports; treat as high-severity for database and internal-service workloads.
+- `nodes/proxy` grants proxy access to the kubelet API on every node — this is effectively cluster-admin for node-level operations and is rarely justified for any non-system workload.
+- `secrets` `get`/`list` access at ClusterRole scope means reading every secret in every namespace — almost always over-privileged for a workload.
+- `escalate` on roles/clusterroles, `bind` on bindings, and `impersonate` on users/groups/serviceaccounts are Kubernetes' three dedicated privilege-escalation verbs. Any Role that grants these is high severity regardless of other verb restrictions — they allow the holder to exceed their own permission set.
+- The `system:masters` group bypasses all RBAC checks, including admission webhooks; never bind real workloads to it.
+- Aggregated ClusterRoles (`aggregationRule`) inherit rules from any ClusterRole that matches the label selector — third-party operators can silently expand them.
+- Setting `automountServiceAccountToken: false` on the ServiceAccount (or the Pod spec) is the correct default for workloads that do not call the Kubernetes API.

package/skills/kubernetes/kubernetes-rbac-review/references/workflow-and-output.md

@@ -0,0 +1,44 @@
+# Workflow and Output Contract
+
+## Workflow
+
+1. Identify the target: namespace-scoped Role/RoleBinding or cluster-scoped ClusterRole/ClusterRoleBinding.
+2. Identify the principal: ServiceAccount, user, or Group (including `system:` groups).
+3. Prefer namespace-scoped Roles before ClusterRoles when the workload only operates in one namespace.
+4. Challenge dangerous defaults:
+   - `cluster-admin` ClusterRoleBinding for any non-infrastructure workload,
+   - Wildcard verbs (`*`) or wildcard resources (`*`) in any Role or ClusterRole,
+   - Wildcard API groups (`*`) that grant cross-group access,
+   - Binding to the `default` ServiceAccount (shared blast radius),
+   - `automountServiceAccountToken: true` (default) on pods that do not need API server access,
+   - ClusterRoleBindings where a RoleBinding to a namespaced ClusterRole would suffice,
+   - Aggregated ClusterRoles with labels that may attract unexpected rules from third-party operators.
+5. **Check privilege-escalation verbs explicitly** — these three verbs bypass Kubernetes' own escalation prevention controls and must be flagged as high severity whenever present:
+   - `escalate` on `clusterroles` or `roles` — allows granting permissions the subject does not itself hold; the textbook Kubernetes privilege escalation path,
+   - `bind` on `clusterroles`, `roles`, `clusterrolebindings`, or `rolebindings` — allows creating bindings to roles the subject is not bound to,
+   - `impersonate` on `users`, `groups`, or `serviceaccounts` — allows acting as any other identity, bypassing all authentication controls.
+6. Check whether RBAC controls reach high-severity resources:
+   - `secrets` (get/list at ClusterRole scope = read every secret cluster-wide),
+   - `pods/exec` and `pods/attach` (interactive shell on any pod — same severity),
+   - `pods/portforward` (tunnel to pod ports),
+   - `nodes/proxy` (proxy to kubelet API on every node — effectively cluster-admin for node operations),
+   - `nodes`, `namespaces`, `clusterroles`, `clusterrolebindings`.
+7. Stress-test operational hygiene:
+   - prefer dedicated ServiceAccounts per workload over shared accounts,
+   - prefer explicit `resources` lists over wildcards,
+   - prefer explicit `verbs` lists (`get`, `list`, `watch`) over `*`,
+   - challenge escalation paths: can the bound account create/update Roles or RoleBindings?
+
+## Output
+
+Return:
+
+- current access summary,
+- risk findings (with severity: high / medium / low),
+- least-privilege alternative,
+- validation commands or manifest corrections,
+- assumptions and missing facts.
+
+## Security notes
+
+Do not suggest `cluster-admin` bindings or wildcard grants unless the user has explicitly justified the blast radius and there is no namespace-scoped alternative.

package/skills/kubernetes/kubernetes-workload-identity-review/SKILL.md

@@ -0,0 +1,46 @@
+---
+name: kubernetes-workload-identity-review
+description: Use this skill for Kubernetes workload identity review covering AWS IRSA (IAM Roles for Service Accounts), Azure Workload Identity, GCP Workload Identity Federation, and the underlying ServiceAccount token volume projection plus OIDC issuer trust. Trigger when the user asks how a pod should authenticate to cloud services, whether long-lived credentials in a Secret can be replaced, whether the OIDC trust policy is correctly scoped, or whether ServiceAccount token reuse is a risk.
+allowed-tools: Read Grep Glob
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+  updated: "2026-05-05"
+  category: security
+---
+
+# Kubernetes Workload Identity Review
+
+## Purpose
+
+Review how pods authenticate to cloud services. Long-lived static credentials in Secrets are the largest unmanaged credential surface in most Kubernetes deployments. Workload identity replaces them with short-lived federated tokens via the cluster's OIDC issuer. The review covers ServiceAccount token projection, OIDC issuer trust policy, the cloud-provider IAM mapping, and the runtime check that the pod is actually using the federated token rather than falling back to a static credential.
+
+## Lean operating rules
+
+- Prefer live cluster evidence (`kubectl get serviceaccount,pods -A -o yaml` plus the cluster's OIDC issuer URL and the cloud-provider IAM trust policy) when the active client exposes it; otherwise fall back to official cloud-provider and Kubernetes documentation.
+- Separate confirmed facts from inference. If the OIDC issuer URL, IAM trust policy, or pod's projected token volume was not queried, say so.
+- Treat **a Pod with both a workload-identity ServiceAccount AND a long-lived credential Secret mounted** as a critical finding — credential precedence often falls back to the static credential, defeating the migration.
+- Treat an **OIDC trust policy with `StringEquals` on `aud` but `StringLike` (wildcard) on `sub`** as a critical finding — any ServiceAccount in the cluster can assume the role.
+- Treat **`automountServiceAccountToken: true` on pods that don't use the Kubernetes API** as a high finding — token is mounted and exfiltratable, even when not used.
+- Challenge ServiceAccount tokens with no `audiences` claim — projected tokens should target a specific cloud audience (`sts.amazonaws.com`, `api://AzureADTokenExchange`, `https://iam.googleapis.com/projects/.../workloadIdentityPools/...`).
+- Challenge token expiry windows longer than 1 hour — projected tokens should be short-lived.
+- Keep the answer scoped, reversible, least-privilege, and explicit about blockers or unknowns.
+
+## References
+
+Load these only when needed:
+
+- [Evidence path and tooling](references/mcp-and-evidence.md) — use when choosing live evidence, confirming OIDC issuer and IAM trust state, or switching to documentation mode.
+- [Workflow and output contract](references/workflow-and-output.md) — use when executing the full review, applying provider-specific stress checks, or formatting the final answer.
+- [Official sources](references/official-sources.md) — use when you need the detailed AWS / Azure / GCP / Kubernetes documentation list and grounded insights.
+
+## Response minimum
+
+Return, at minimum:
+
+- the cloud provider (AWS, Azure, GCP, or generic OIDC) and evidence level,
+- the ServiceAccount → IAM identity binding (annotation, label, or trust policy claim) and whether it is correctly scoped,
+- the OIDC trust policy scope (`aud`, `sub`, `iss`) — must constrain to a specific ServiceAccount,
+- whether long-lived credentials still exist anywhere in the workload (Secret mounts, env vars, sidecars),
+- the safest next actions and rollback plan,
+- the assumptions or blockers that prevent stronger conclusions.

package/skills/kubernetes/kubernetes-workload-identity-review/metadata.json

@@ -0,0 +1,29 @@
+{
+  "id": "kubernetes-workload-identity-review",
+  "name": "Kubernetes Workload Identity Review",
+  "type": "skill",
+  "provider": "kubernetes",
+  "harnesses": [
+    "codex",
+    "claude-code",
+    "cursor",
+    "gemini",
+    "kiro",
+    "other"
+  ],
+  "summary": "Review Kubernetes workload identity bindings across AWS IRSA, Azure Workload Identity, GCP Workload Identity Federation, and the underlying ServiceAccount projected token model with OIDC issuer trust scope and short-lived federation.",
+  "source_type": "original",
+  "official_docs": [
+    "https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/",
+    "https://kubernetes.io/docs/reference/access-authn-authz/service-accounts-admin/",
+    "https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts.html",
+    "https://learn.microsoft.com/en-us/azure/aks/workload-identity-overview",
+    "https://cloud.google.com/kubernetes-engine/docs/concepts/workload-identity",
+    "https://openid.net/specs/openid-connect-core-1_0.html"
+  ],
+  "security_notes": "Workload identity OIDC trust policy with wildcard sub claim allows any ServiceAccount in the cluster to assume the role. Pods with both a workload-identity SA and a long-lived credential Secret typically fall back to the static credential. Tokens with audiences not pinned to the cloud target are reusable elsewhere.",
+  "last_verified": "2026-05-01",
+  "path": "skills/kubernetes/kubernetes-workload-identity-review",
+  "author": "github: Raishin",
+  "version": "0.1.0"
+}

package/skills/kubernetes/kubernetes-workload-identity-review/references/mcp-and-evidence.md

@@ -0,0 +1,57 @@
+# Evidence Path and Tooling
+
+## Evidence path
+
+1. Prefer live cluster evidence (`kubectl`) plus the cloud-provider's CLI (`aws`, `az`, `gcloud`) or MCP server when available.
+2. Fall back to official documentation: Kubernetes ServiceAccount admin, AWS IRSA, Azure Workload Identity, GCP Workload Identity Federation.
+3. Ask only for sanitized ServiceAccount, Pod, and trust policy YAML/JSON, plus the cluster's OIDC issuer URL.
+4. Label conclusions as `live evidence`, `documentation-based`, `sanitized user evidence`, or `inference`.
+
+## Useful live-evidence commands
+
+```shell
+# ServiceAccount with workload identity annotations
+kubectl get serviceaccount -A -o yaml | grep -A2 -E 'eks\.amazonaws\.com/role-arn|azure\.workload\.identity/client-id|iam\.gke\.io/gcp-service-account'
+
+# Pod's projected ServiceAccount token volume
+kubectl get pod <pod> -n <ns> -o yaml | grep -A20 'projected:'
+
+# Verify pod is consuming the projected token
+kubectl exec -it <pod> -n <ns> -- ls -la /var/run/secrets/tokens/
+kubectl exec -it <pod> -n <ns> -- cat /var/run/secrets/tokens/<audience-token>
+
+# Cluster OIDC issuer (each cluster has one — IAM trusts it)
+# AWS EKS:
+aws eks describe-cluster --name <cluster> --query "cluster.identity.oidc.issuer" --output text
+# Azure AKS:
+az aks show --resource-group <rg> --name <cluster> --query "oidcIssuerProfile.issuerUrl" --output tsv
+# GKE:
+gcloud container clusters describe <cluster> --location <location> --format='value(workloadIdentityConfig.workloadPool)'
+
+# Confirm there's no static credential alongside
+kubectl exec -it <pod> -n <ns> -- env | grep -E 'AWS_ACCESS_KEY_ID|AZURE_CLIENT_SECRET|GOOGLE_APPLICATION_CREDENTIALS'
+kubectl exec -it <pod> -n <ns> -- ls /var/run/secrets/
+
+# AWS — view IAM role trust policy
+aws iam get-role --role-name <role-name> --query 'Role.AssumeRolePolicyDocument'
+
+# Azure — view federated identity credentials on the user-assigned managed identity
+az identity federated-credential list --identity-name <mi> --resource-group <rg>
+
+# GCP — view IAM policy on the service account
+gcloud iam service-accounts get-iam-policy <gsa>@<project>.iam.gserviceaccount.com
+```
+
+## Cluster state to confirm before review
+
+- **OIDC issuer enabled** on the cluster (provider-specific switch).
+- **OIDC issuer URL** — IAM trust policies key off this URL.
+- **Webhook installed** for the workload identity model (AWS Pod Identity Webhook, Azure Workload Identity admission webhook, GKE built-in).
+- **Default audience** for the cluster (cloud-specific): `sts.amazonaws.com` on AWS, `api://AzureADTokenExchange` on Azure, `<workload-identity-pool-name>` on GCP.
+- **Service account → IAM mapping mechanism**: annotation, label, federated identity credential, or IAM policy binding.
+
+## Sanitization rules
+
+- Never request kubeconfig contents, IAM access keys, Azure client secrets, GCP service account JSON keys.
+- Replace identifiable cluster URLs, account IDs, tenant IDs, and project IDs with placeholders unless the user provides them.
+- Do not print projected ServiceAccount token JWTs; reference the file path and audience claim only.

package/skills/kubernetes/kubernetes-workload-identity-review/references/official-sources.md

@@ -0,0 +1,47 @@
+# Official Sources
+
+Load these only when needed:
+
+## Kubernetes core
+
+- [Configure ServiceAccounts for Pods](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/) — use for `automountServiceAccountToken`, projected token volumes, and dedicated SA patterns.
+- [ServiceAccount admin guide](https://kubernetes.io/docs/reference/access-authn-authz/service-accounts-admin/) — use for bound ServiceAccount tokens, audience binding, and migration from legacy auto-mounted tokens.
+- [TokenRequest API](https://kubernetes.io/docs/reference/kubernetes-api/authentication-resources/token-request-v1/) — use when reviewing custom code that calls `TokenRequest` for bespoke token issuance.
+- [OIDC issuer discovery](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#openid-connect-tokens) — use when the cluster's own OIDC issuer is consumed by external trust policies.
+
+## AWS IRSA
+
+- [IAM Roles for Service Accounts overview](https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts.html) — use as the entry point for IRSA.
+- [IRSA technical deep dive](https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts-technical-overview.html) — use for the OIDC trust policy structure (`Federated`, `Condition.StringEquals` on `aud` and `sub`) and the AssumeRoleWithWebIdentity flow.
+- [Configuring IRSA pod identity](https://docs.aws.amazon.com/eks/latest/userguide/pod-configuration.html) — use for the ServiceAccount annotation, env injection, and credential-chain interaction.
+- [EKS Pod Identity (the newer alternative)](https://docs.aws.amazon.com/eks/latest/userguide/pod-identities.html) — use when the cluster has migrated to EKS Pod Identity instead of IRSA; the trust model is different.
+
+## Azure Workload Identity
+
+- [Azure Workload Identity overview](https://learn.microsoft.com/en-us/azure/aks/workload-identity-overview) — use for the federated identity credential model and AKS-specific configuration.
+- [Workload Identity deploy and configure](https://learn.microsoft.com/en-us/azure/aks/workload-identity-deploy-cluster) — use for OIDC issuer enablement, webhook installation, and the ServiceAccount/Pod label/annotation set.
+- [Federated identity credentials on a user-assigned managed identity](https://learn.microsoft.com/en-us/entra/workload-id/workload-identity-federation) — use for the issuer/subject/audience trust scope.
+
+## GCP Workload Identity Federation
+
+- [GKE Workload Identity overview](https://cloud.google.com/kubernetes-engine/docs/concepts/workload-identity) — use for KSA → GSA mapping via `iam.gke.io/gcp-service-account` annotation and the `roles/iam.workloadIdentityUser` IAM binding.
+- [GKE Workload Identity setup](https://cloud.google.com/kubernetes-engine/docs/how-to/workload-identity) — use for cluster-level config and migration steps.
+- [Workload Identity Federation (non-GKE)](https://cloud.google.com/iam/docs/workload-identity-federation) — use when the workload runs outside GKE but federates to GCP IAM.
+
+## Specifications
+
+- [OpenID Connect Core 1.0](https://openid.net/specs/openid-connect-core-1_0.html) — use for the standard claims (`iss`, `sub`, `aud`, `exp`, `nbf`, `iat`) that all three providers verify.
+- [JSON Web Token (JWT) — RFC 7519](https://datatracker.ietf.org/doc/html/rfc7519) — use for token structure and validation.
+
+## Grounded insights worth carrying into the skill
+
+- Workload identity replaces long-lived static credentials with short-lived federated tokens issued by the cluster's OIDC issuer. The cloud's IAM trusts the cluster's OIDC issuer URL and the trust policy narrows on `iss`, `aud`, `sub` claims.
+- The most-cited trust-policy mistake across all three providers is a wildcard in `sub` (AWS), `subject` (Azure), or member set (GCP). Wildcards mean any ServiceAccount in scope can assume the cloud identity.
+- Cloud SDK credential chains explain why workloads frequently keep using static credentials after a workload identity migration. The SDK searches for credentials in a fixed order (env vars → file → instance metadata → web identity); whichever is found first wins. Leaving a static credential anywhere in the chain defeats the migration.
+- The Kubernetes-native primitive under all three flavors is the **projected ServiceAccount token volume** with `audience` and `expirationSeconds`. The cloud webhook (AWS Pod Identity Webhook, Azure Workload Identity admission webhook) automates the projection setup.
+- AWS IRSA injects `AWS_ROLE_ARN` and `AWS_WEB_IDENTITY_TOKEN_FILE` env vars into pods whose ServiceAccount carries the `eks.amazonaws.com/role-arn` annotation. The AWS SDK then calls `sts:AssumeRoleWithWebIdentity` to exchange the projected JWT for IAM credentials.
+- Azure Workload Identity requires both a label on the ServiceAccount AND a label on the Pod (`azure.workload.identity/use: "true"`). Forgetting the Pod label is a frequent silent failure — the SDK falls back to other auth modes.
+- GKE Workload Identity uses a metadata-server proxy on each node. SDK calls to `metadata.google.internal` are intercepted and federated to the bound GSA. There is no token file mounted into the pod.
+- Projected ServiceAccount tokens are auto-rotated by the kubelet at ~50% of `expirationSeconds`. Long-running SDK clients must read the token file dynamically, not cache it.
+- EKS Pod Identity is AWS's newer alternative to IRSA. It uses a node-level agent and a different trust model (no OIDC trust policy on the IAM role; instead a Pod Identity Association resource). Reviews must distinguish which model is in use because the controls are different.
+- Setting `automountServiceAccountToken: false` on the ServiceAccount is the correct safer default for workloads that do not call the Kubernetes API. Pod spec overrides this; the override is the failure mode.