@raishin/vanguard-frontier-agentic 1.2.0 → 1.3.0

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,43 @@
+---
+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.
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+---
+
+# 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.

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

@@ -0,0 +1,166 @@
+# Workflow and Output Contract
+
+## Workflow
+
+### Step 1 — Identify the workload identity flavor
+
+Three production flavors plus the underlying primitive:
+
+1. **AWS IRSA (IAM Roles for Service Accounts)** — ServiceAccount annotated with `eks.amazonaws.com/role-arn: arn:aws:iam::<account>:role/<role>`. Pod identity webhook injects `AWS_WEB_IDENTITY_TOKEN_FILE` and `AWS_ROLE_ARN`. AWS SDK calls `sts:AssumeRoleWithWebIdentity`.
+2. **Azure Workload Identity** — ServiceAccount labeled `azure.workload.identity/use: "true"` and annotated with `azure.workload.identity/client-id: <client-id>`. Pod labeled `azure.workload.identity/use: "true"`. Webhook injects projected token at `/var/run/secrets/azure/tokens/azure-identity-token`. Azure SDK exchanges via federated identity credential.
+3. **GCP Workload Identity Federation (GKE)** — ServiceAccount annotated `iam.gke.io/gcp-service-account: <gsa>@<project>.iam.gserviceaccount.com`. GKE metadata server proxies SDK calls; ServiceAccount → GSA mapping via IAM policy binding (`roles/iam.workloadIdentityUser`).
+4. **Generic projected token + OIDC** — Kubernetes-native primitive. ServiceAccount projected token volume with explicit `audience` and `expirationSeconds`. Trust-policy verification at the cloud / external service.
+
+Reference: [Configure ServiceAccounts for Pods](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/) and [ServiceAccount admin](https://kubernetes.io/docs/reference/access-authn-authz/service-accounts-admin/).
+
+### Step 2 — Audit the OIDC trust policy scope
+
+This is the most under-reviewed control in workload identity migrations.
+
+**AWS IRSA** trust policy structure:
+
+```json
+{
+  "Effect": "Allow",
+  "Principal": {
+    "Federated": "arn:aws:iam::<account>:oidc-provider/oidc.eks.<region>.amazonaws.com/id/<id>"
+  },
+  "Action": "sts:AssumeRoleWithWebIdentity",
+  "Condition": {
+    "StringEquals": {
+      "oidc.eks.<region>.amazonaws.com/id/<id>:aud": "sts.amazonaws.com",
+      "oidc.eks.<region>.amazonaws.com/id/<id>:sub": "system:serviceaccount:<namespace>:<sa-name>"
+    }
+  }
+}
+```
+
+Critical findings:
+
+- `StringLike` on `:sub` with a wildcard (`system:serviceaccount:*:*` or `system:serviceaccount:<ns>:*`) — any ServiceAccount in scope can assume the role.
+- `:aud` not constrained to `sts.amazonaws.com` — token reusable for non-AWS audiences.
+- Multiple OIDC providers trusted from one role — broader trust surface than necessary.
+
+**Azure Workload Identity** uses federated identity credentials on a user-assigned managed identity:
+
+```text
+issuer: https://<region>.oic.prod-aks.azure.com/<tenant>/<id>/
+subject: system:serviceaccount:<namespace>:<sa-name>
+audience: api://AzureADTokenExchange
+```
+
+Critical findings:
+
+- `subject` with wildcards — Azure rejects most wildcards but pre-validation is required; mistakes get caught only at first token exchange.
+- Multiple federated identity credentials on one managed identity, each from different clusters — each is a separate cluster trust; rotate / remove unused ones.
+
+**GCP Workload Identity** uses IAM policy on the GSA:
+
+```text
+role: roles/iam.workloadIdentityUser
+member: serviceAccount:<project>.svc.id.goog[<namespace>/<ksa-name>]
+```
+
+Critical findings:
+
+- Members listing `[*/*]` — any ServiceAccount in any namespace can act as the GSA.
+- Member with wildcards `[<ns>/*]` — any ServiceAccount in the namespace.
+
+Reference: [AWS IRSA technical overview](https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts-technical-overview.html), [Azure Workload Identity overview](https://learn.microsoft.com/en-us/azure/aks/workload-identity-overview), [GKE Workload Identity](https://cloud.google.com/kubernetes-engine/docs/concepts/workload-identity).
+
+### Step 3 — Confirm the pod is actually using the federated token
+
+Workload identity migrations frequently leave a static credential alongside the new federated path. Cloud SDKs use a credential chain — if a static credential is found earlier in the chain, the federated token is never used.
+
+Stress-tests:
+
+- AWS SDK credential chain: env (`AWS_ACCESS_KEY_ID`) → shared credentials file → IRSA web identity → instance profile. A leftover env var defeats IRSA.
+- Azure SDK chain: env → managed identity → workload identity → CLI. A leftover client secret in env defeats workload identity.
+- GCP SDK chain: `GOOGLE_APPLICATION_CREDENTIALS` env → metadata server. A mounted SA key file in `GOOGLE_APPLICATION_CREDENTIALS` defeats GKE Workload Identity.
+
+Verify with:
+
+```shell
+# AWS — confirm sts:AssumeRoleWithWebIdentity is the auth path
+kubectl exec -it <pod> -n <ns> -- aws sts get-caller-identity
+# Should show "AssumedRole" not "User"
+
+# Azure — confirm token exchange
+kubectl exec -it <pod> -n <ns> -- env | grep AZURE_FEDERATED_TOKEN_FILE
+
+# GCP — confirm metadata server is reachable and used
+kubectl exec -it <pod> -n <ns> -- curl -s -H "Metadata-Flavor: Google" \
+  http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/email
+```
+
+> **Diagnostic only — do not embed in automation.** The instance metadata server is the same primitive that has been weaponized in cloud breaches (notably Capital One 2019). On AWS and Azure clusters the metadata IP is `169.254.169.254`; on GCP it resolves through `metadata.google.internal`. Any pod that can reach the metadata endpoint can request short-lived credentials for the node's identity. Block the metadata service at the network policy layer for workloads that should not read it — see [`cilium-network-policy-review`](../../../cilium/cilium-network-policy-review/SKILL.md) for the egress rule pattern that excludes `169.254.169.254/32`.
+
+### Step 4 — Audit the projected token configuration
+
+For provider webhooks, projection is automatic. For the generic projected-token primitive, the Pod spec includes:
+
+```yaml
+spec:
+  serviceAccountName: <sa-name>
+  volumes:
+    - name: token
+      projected:
+        sources:
+          - serviceAccountToken:
+              path: token
+              audience: <audience>
+              expirationSeconds: 3600     # max recommended; tokens are auto-rotated
+```
+
+Critical findings:
+
+- `expirationSeconds` longer than 1 hour — projected tokens should be short-lived.
+- `audience` empty — defaults to the API server, which means the token is interchangeable with any ServiceAccount token (no narrowing).
+- Multiple audiences for the same volume — the token can be replayed across audiences.
+
+Reference: [Bound Service Account Tokens](https://kubernetes.io/docs/reference/access-authn-authz/service-accounts-admin/#bound-service-account-tokens) and [Token volume projection](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/#serviceaccount-token-volume-projection).
+
+### Step 5 — Audit `automountServiceAccountToken`
+
+Default is `true`. Every pod gets a token mounted at `/var/run/secrets/kubernetes.io/serviceaccount/token` whether or not the workload uses the Kubernetes API. Findings:
+
+- Pod that does not call the K8s API but has `automountServiceAccountToken: true` — token is exfiltratable on container compromise.
+- ServiceAccount with `automountServiceAccountToken: false` but Pod spec overrides with `true` — Pod spec wins; the SA-level safer default is bypassed.
+
+Recommended baseline: `automountServiceAccountToken: false` on the ServiceAccount, override only when the workload actually calls the K8s API.
+
+### Step 6 — Audit cross-cluster / cross-account reuse
+
+A single IAM role (AWS) or managed identity (Azure) or GSA (GCP) can be trusted from multiple clusters. Findings:
+
+- An IAM role trusted from cluster A's OIDC provider AND cluster B's OIDC provider — compromise of cluster B grants the role's permissions.
+- Federated identity credentials on a managed identity from clusters that no longer exist — stale trust; remove.
+
+### Step 7 — Stress-test operational hygiene
+
+- Prefer dedicated IAM identities per ServiceAccount, not shared roles across multiple SAs.
+- Prefer narrow IAM policies (`Resource: arn:aws:s3:::specific-bucket/*`) over broad (`Resource: '*'`).
+- Prefer `automountServiceAccountToken: false` as the default and override per workload.
+- Prefer `audience` claims that match the cloud target's expected audience.
+- Test token rotation by killing the projected token file and confirming the SDK refreshes.
+
+## Output
+
+Return:
+
+- **target**: the workload identity flavor and the ServiceAccount → cloud identity binding,
+- **evidence level**: `live evidence` / `documentation-based` / `sanitized user evidence` / `inference`,
+- **OIDC trust policy scope**: `aud`, `sub`, `iss`, with judgment on narrowness,
+- **fallback assessment**: are static credentials still present? Is the SDK actually using the federated path?,
+- **token projection assessment**: audience, expiration, automountServiceAccountToken posture,
+- **risk findings** (with severity: high / medium / low),
+- **safest next actions** with sample manifest and trust-policy changes,
+- **rollback plan**: how to revert without locking the workload out of the cloud,
+- **assumptions and missing facts**.
+
+## Security notes
+
+- Never recommend keeping a long-lived credential Secret "just in case" alongside workload identity.
+- Never recommend wildcards in OIDC trust policy `sub` claim.
+- Never recommend `audience` defaults that allow the projected token to be replayed against the K8s API.
+- Do not print IAM access keys, client secrets, GCP service account JSON, or projected token JWT bodies.

package/skills/kyverno/README.md

@@ -0,0 +1,30 @@
+# 🛡️ Kyverno Skills
+
+<p align="center">
+  <!-- 🖼️ Add a Kyverno logo to assets/logos/cnative/kyverno/ and update this path -->
+  <span style="font-size:3.5em">🛡️</span>
+</p>
+
+This folder contains Kyverno-focused skills curated for this marketplace.
+
+## Local marketplace portfolio
+
+This folder contains **1** local Kyverno skill:
+
+- `kyverno-policy-review`
+
+## Portfolio posture
+
+Kyverno skills for evidence-backed admission policy review across `ValidatingPolicy`, `MutatingPolicy`, `GeneratingPolicy`, `DeletingPolicy`, and `ImageValidatingPolicy` — the stable `policies.kyverno.io/v1` API surface.
+
+These skills are intentionally conservative:
+
+- prefer `kubectl get policies.kyverno.io -A -o yaml` for live policy state grounding before any review
+- treat `failureAction: Audit` in production as a critical finding — policy violations become silent
+- treat `PolicyException` resources as audit-required escalation paths — every exception is a documented bypass
+- challenge any policy with `background: false` and no admission match — the policy never runs
+- prefer policies that compile to native `ValidatingAdmissionPolicy` (CEL) when complexity allows — fewer moving parts than the Kyverno controller
+- challenge `ImageValidatingPolicy` with `verifyImages` skipped on CVE-only images — supply-chain attestation must remain
+- use official Kyverno documentation (kyverno.io) for policy syntax, CEL expressions, and ValidatingAdmissionPolicy generation
+
+Run `npm run validate` after changing cataloged Kyverno skills.

package/skills/kyverno/kyverno-policy-review/SKILL.md

@@ -0,0 +1,43 @@
+---
+name: kyverno-policy-review
+description: Use this skill for Kyverno policy review across the stable policies.kyverno.io/v1 API surface — ValidatingPolicy, MutatingPolicy, GeneratingPolicy, DeletingPolicy, and ImageValidatingPolicy. Trigger when the user asks whether an admission policy is safe, whether a PolicyException is justified, whether a policy should be enforced or audited, whether a Kyverno policy should be replaced by a native ValidatingAdmissionPolicy (CEL), or whether image signature verification is correctly configured.
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+---
+
+# Kyverno Policy Review
+
+## Purpose
+
+Review Kyverno policies and PolicyExceptions against admission correctness, supply chain integrity, blast radius, failure mode, and the Kyverno-vs-native-CEL architectural decision. Kyverno is the most widely deployed Kubernetes policy engine — every misconfigured policy is either a silent allow (security gap) or a silent deny (production outage).
+
+## Lean operating rules
+
+- Prefer live cluster evidence (`kubectl get policies.kyverno.io,clusterpolicies,policies,validatingpolicies,mutatingpolicies,imagevalidatingpolicies,policyexceptions -A -o yaml`) when the active client exposes it; otherwise fall back to official Kyverno documentation (kyverno.io) and sanitized YAML from the user.
+- Separate confirmed facts from inference. If the cluster's Kyverno install state, admission webhook configuration, or PolicyReport status was not queried, say so.
+- Treat `failureAction: Audit` (or legacy `validationFailureAction: audit`) on a production-relevant policy as a critical finding — admission violations become silent log lines.
+- Treat any `PolicyException` as an audit-required artifact — every exception is a documented bypass with a name, reason, and reviewer.
+- Challenge `background: false` paired with no `match` admission scope — the policy will never run.
+- Challenge `ImageValidatingPolicy` with `verifyImages: skip` patterns, missing public keys, or `mutateDigest: false` — supply-chain attestations stop being enforced or stop being immutable.
+- Challenge any policy that could compile to a native `ValidatingAdmissionPolicy` (CEL) — fewer moving parts, no Kyverno controller in the admission path.
+- 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 Kyverno install state, or switching to documentation mode.
+- [Workflow and output contract](references/workflow-and-output.md) — use when executing the full review, applying stress checks, evaluating Kyverno-vs-native-CEL, or formatting the final answer.
+- [Official sources](references/official-sources.md) — use when you need the detailed Kyverno documentation list, CEL expression references, or grounded insights from the Kyverno project.
+
+## Response minimum
+
+Return, at minimum:
+
+- the scoped target (policy kind, name, match scope) and evidence level,
+- the failure mode (`Audit` vs `Enforce`) and whether it matches the production posture,
+- the main risks or control gaps (PolicyException, wildcard match, missing image signatures, weak CEL expressions),
+- whether the policy could be replaced by a native ValidatingAdmissionPolicy (CEL) and the tradeoff,
+- the safest next actions and rollback plan,
+- the assumptions or blockers that prevent stronger conclusions.

package/skills/kyverno/kyverno-policy-review/metadata.json

@@ -0,0 +1,30 @@
+{
+  "id": "kyverno-policy-review",
+  "name": "Kyverno Policy Review",
+  "type": "skill",
+  "provider": "kyverno",
+  "harnesses": [
+    "codex",
+    "claude-code",
+    "cursor",
+    "gemini",
+    "kiro",
+    "other"
+  ],
+  "summary": "Review Kyverno ValidatingPolicy, MutatingPolicy, GeneratingPolicy, DeletingPolicy, ImageValidatingPolicy, and PolicyException resources for admission correctness, failure mode, supply-chain integrity, and the Kyverno-vs-native-CEL architectural decision.",
+  "source_type": "original",
+  "official_docs": [
+    "https://kyverno.io/docs/",
+    "https://kyverno.io/docs/policy-types/overview/",
+    "https://kyverno.io/docs/policy-types/cluster-policy/validate/",
+    "https://kyverno.io/docs/policy-types/cluster-policy/verify-images/",
+    "https://kyverno.io/docs/exceptions/",
+    "https://kyverno.io/docs/installation/",
+    "https://kubernetes.io/docs/reference/access-authn-authz/validating-admission-policy/"
+  ],
+  "security_notes": "Treat failureAction Audit on production policies as a critical finding. Every PolicyException is a documented bypass requiring an owner, reason, and expiry. ImageValidatingPolicy must verify signatures with mutateDigest true. Prefer native ValidatingAdmissionPolicy when CEL alone is sufficient.",
+  "last_verified": "2026-05-01",
+  "path": "skills/kyverno/kyverno-policy-review",
+  "author": "github: Raishin",
+  "version": "0.1.0"
+}

package/skills/kyverno/kyverno-policy-review/references/mcp-and-evidence.md

@@ -0,0 +1,49 @@
+# Evidence Path and Tooling
+
+## Evidence path
+
+1. Prefer live cluster evidence when a Kubernetes MCP server, `kubectl`, or `kyverno` CLI is available.
+2. Fall back to official Kyverno documentation (kyverno.io) and the Kubernetes admission control reference when live inspection is unavailable.
+3. Ask only for sanitized policy YAML, PolicyReport snippets, or `kyverno apply` output when current-state proof matters. Never request kubeconfig contents, admission webhook bearer tokens, image-signing private keys, or secrets.
+4. Label conclusions as `live evidence`, `documentation-based`, `sanitized user evidence`, or `inference`.
+
+## Useful live-evidence commands
+
+```shell
+# List all Kyverno policy kinds across the cluster (stable v1 API)
+kubectl get validatingpolicies,mutatingpolicies,generatingpolicies,deletingpolicies,imagevalidatingpolicies -A -o yaml
+
+# Legacy kinds (still in use on many clusters)
+kubectl get clusterpolicies,policies -A -o yaml
+
+# List all PolicyExceptions — every one is a documented bypass
+kubectl get policyexceptions -A -o yaml
+
+# View Kyverno controller deployment and webhook config
+kubectl -n kyverno get deploy,svc,validatingwebhookconfiguration,mutatingwebhookconfiguration -o yaml
+
+# View Kyverno admission reports — does the policy actually run?
+kubectl get policyreport,clusterpolicyreport -A
+
+# Test a policy locally without applying
+kyverno apply policy.yaml --resource resource.yaml
+
+# Test against the live cluster
+kyverno apply policy.yaml --cluster
+
+# Generate a native ValidatingAdmissionPolicy from a Kyverno policy (preview)
+kyverno migrate-policy policy.yaml --output validatingadmissionpolicy.yaml
+```
+
+## Kyverno install state to confirm before review
+
+- Kyverno controller version (`kubectl -n kyverno get deploy kyverno -o jsonpath='{.spec.template.spec.containers[0].image}'`) — newer versions support more CEL expressions and the stable `policies.kyverno.io/v1` API.
+- Reports Server enabled (`kubectl -n kyverno get deploy reports-server`) — controls whether PolicyReports are stored externally or in etcd.
+- Cleanup controller enabled — required for `DeletingPolicy` resources.
+- Admission controller webhook timeout — Kyverno's default is 10s; aggressive policies can stall pod creation.
+
+## Platform-agnostic execution
+
+- Keep examples neutral with placeholders (`<policy-name>`, `<namespace>`, `<image-ref>`) until the user's cluster context and policy state are known.
+- Do not request kubeconfig files, image signing keys, Sigstore Rekor entries, or registry credentials in chat.
+- If a Kubernetes MCP server, `kubectl`, or `kyverno` CLI is unavailable, say so and fall back to reviewing sanitized YAML and the official Kyverno documentation.

package/skills/kyverno/kyverno-policy-review/references/official-sources.md

@@ -0,0 +1,31 @@
+# Official Sources
+
+Load these only when needed:
+
+- [Kyverno documentation home](https://kyverno.io/docs/) — use as the entry point for any policy authoring, install, or operator-side question.
+- [Kyverno policy types overview](https://kyverno.io/docs/policy-types/overview/) — use for the stable `policies.kyverno.io/v1` API surface (`ValidatingPolicy`, `MutatingPolicy`, `GeneratingPolicy`, `DeletingPolicy`, `ImageValidatingPolicy`).
+- [Kyverno validate rules](https://kyverno.io/docs/policy-types/cluster-policy/validate/) — use for `failureAction`, `failurePolicy`, CEL validation expressions, `denyConditions`, and the Kyverno-to-ValidatingAdmissionPolicy compilation path.
+- [Kyverno mutate rules](https://kyverno.io/docs/policy-types/cluster-policy/mutate/) — use for `patchStrategicMerge`, `patchesJson6902`, `foreach` mutations, and conditional mutation guards.
+- [Kyverno generate rules](https://kyverno.io/docs/policy-types/cluster-policy/generate/) — use for `synchronize: true` (rule keeps generated resources in sync) and the security implications of generated RoleBindings or NetworkPolicies.
+- [Kyverno verify-images / ImageValidatingPolicy](https://kyverno.io/docs/policy-types/cluster-policy/verify-images/) — use for Cosign keyless and key-based verification, attestation chains, `mutateDigest`, `verifyDigest`, and Sigstore Rekor / Notary configuration.
+- [Kyverno PolicyExceptions](https://kyverno.io/docs/exceptions/) — use for `PolicyException` syntax, the audit posture exceptions create, and `match` / `exclude` semantics.
+- [Kyverno cleanup policies](https://kyverno.io/docs/policy-types/cluster-policy/cleanup/) — use for `DeletingPolicy` cron-driven resource deletion patterns.
+- [Kyverno installation](https://kyverno.io/docs/installation/) — use for Helm install, Reports Server enablement, and admission webhook timing.
+- [Kyverno CLI (`kyverno apply`, `kyverno test`, `kyverno migrate-policy`)](https://kyverno.io/docs/kyverno-cli/) — use for offline policy testing and Kyverno-to-VAP migration.
+- [Kyverno PolicyReport / ClusterPolicyReport](https://kyverno.io/docs/policy-reports/) — use for the OpenReports-format violation records the Reports Server stores.
+- [Kubernetes ValidatingAdmissionPolicy (CEL)](https://kubernetes.io/docs/reference/access-authn-authz/validating-admission-policy/) — use for the native VAP CEL syntax that Kyverno compiles to.
+- [Kubernetes admission webhook reference](https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/) — use for `failurePolicy: Fail` vs `Ignore`, webhook timeout, and the admission chain.
+- [Sigstore Cosign documentation](https://docs.sigstore.dev/cosign/overview/) — use for signing flow that ImageValidatingPolicy verifies.
+
+## Grounded insights worth carrying into the skill
+
+- The stable Kyverno API is `policies.kyverno.io/v1` with five kinds: `ValidatingPolicy`, `MutatingPolicy`, `GeneratingPolicy`, `DeletingPolicy`, `ImageValidatingPolicy`. The legacy `kyverno.io/v1` `ClusterPolicy` and `Policy` kinds are still supported but deprecated.
+- Kyverno can compile a `ClusterPolicy` (validate-only, CEL-only) into a native `ValidatingAdmissionPolicy` so admission is enforced by the Kubernetes API server without the Kyverno controller in the request path. This is the leanest deployment when the policy fits VAP's capabilities.
+- `failureAction: Audit` (newer API) and `validationFailureAction: audit` (legacy) silently allow violations. Many security incidents have been traced back to a policy that was set to `Audit` "temporarily" and never promoted to `Enforce`.
+- `PolicyException` resources exempt resources from policy. Every exception is a bypass with no built-in expiry, owner, or revoke trigger — the documentation discipline must come from process.
+- `ImageValidatingPolicy` without `mutateDigest: true` allows a verified tag to be re-pointed to a different image after admission. This is a known image-replacement attack path.
+- Reports Server is a separate component that decouples PolicyReport storage from etcd. Without it, PolicyReports at Fortune 50 scale (millions of resources × dozens of policies) overwhelm etcd.
+- Kyverno's default admission webhook timeout is 10 seconds. Policies that perform `context.apiCall` lookups can hit this timeout and fall back to `failurePolicy` — if `failurePolicy` is `Ignore` (default), violations silently pass.
+- The cleanup controller (which powers `DeletingPolicy`) is a separate deployment and must be installed explicitly via Helm value `cleanupController.enabled=true`.
+- `background: false` disables the periodic scan of existing resources. The policy only runs at admission, so resources created before the policy existed are never evaluated — useful for migrations, dangerous as a default.
+- Aggregated CRDs (Kyverno does not ship these, but operators may) can match Kyverno policies in unexpected ways — confirm `match.any.resources.kinds` does not pick up CRDs from third-party operators.