@raishin/vanguard-frontier-agentic 1.2.0 → 1.4.0

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,46 @@
+---
+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.
+allowed-tools: Read Grep Glob
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+  updated: "2026-05-05"
+  category: security
+---
+
+# 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.

package/skills/kyverno/kyverno-policy-review/references/workflow-and-output.md

@@ -0,0 +1,106 @@
+# Workflow and Output Contract
+
+## Workflow
+
+### Step 1 — Identify the policy and its scope
+
+1. Confirm the policy kind: `ValidatingPolicy`, `MutatingPolicy`, `GeneratingPolicy`, `DeletingPolicy`, `ImageValidatingPolicy` (stable `policies.kyverno.io/v1`), or legacy `ClusterPolicy` / `Policy`.
+2. Confirm the match scope: namespace-scoped (`Policy`) vs cluster-scoped (`ClusterPolicy` / new v1 kinds).
+3. Confirm the API version. The stable `policies.kyverno.io/v1` API is the recommended target — see the [Kyverno policy types overview](https://kyverno.io/docs/policy-types/overview/).
+4. Confirm match conditions in `spec.match` — kinds, names, namespaces, labels, annotations. Any `kinds: ['*']` with no further filter is high-blast-radius.
+
+### Step 2 — Identify the failure mode
+
+1. Locate `spec.rules[].validate.failureAction` (newer API) or `spec.validationFailureAction` (legacy).
+2. Two values exist: `Enforce` (admission denied on violation) and `Audit` (admission allowed, violation recorded in PolicyReport).
+3. **Critical finding**: any production-relevant policy with `failureAction: Audit` and no plan to migrate to `Enforce`. The policy is a logging shim, not a control.
+4. Also confirm `spec.background` — when `false`, the policy only evaluates at admission time; existing resources are not scanned.
+5. Reference: [Validate rules — failureAction semantics](https://kyverno.io/docs/policy-types/cluster-policy/validate/).
+
+### Step 3 — Challenge dangerous policy patterns
+
+Flag the following as high-severity findings:
+
+- **`failureAction: Audit` in production** — silent allow path; PolicyReports accumulate without enforcement.
+- **`background: false` + match scope that does not match admission requests** — policy never runs; effectively dead code.
+- **`match` with `kinds: ['*']` and no namespace selector** — cluster-wide blast radius; one mis-written CEL expression breaks every admission.
+- **`exclude` clause that exempts entire `kube-system` or operator namespaces** — operators bypass policy that should still apply (e.g., image signing).
+- **`failurePolicy: Ignore` on the underlying ValidatingWebhookConfiguration** — Kyverno controller failures silently allow. See the [Kubernetes admission webhook reference](https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/).
+- **CEL expressions referencing `request.userInfo` without a deny default** — easy to bypass with a service account named in an exception.
+
+### Step 4 — Audit every PolicyException
+
+A PolicyException is a documented bypass. Treat every one as audit evidence requiring four facts:
+
+1. **Owner**: who created it and is on call for the exempted resources?
+2. **Reason**: why does this resource not meet the policy?
+3. **Expiry**: is there a date or condition under which this exception is removed? Kyverno does not enforce expiry — this must be a documented commitment.
+4. **Scope**: which resources, namespaces, and rules are exempted?
+
+Reference: [Kyverno PolicyExceptions](https://kyverno.io/docs/exceptions/).
+
+Stress-test exceptions:
+
+- An exception with `match.any.resources.kinds: ['*']` exempts everything — almost always too broad.
+- An exception that exempts the `default` ServiceAccount — effectively exempts every workload that hasn't bound an SA.
+- An exception that exempts a `ClusterPolicy` with `failureAction: Enforce` quietly demotes the policy to `Audit` for the matched scope.
+
+### Step 5 — Audit ImageValidatingPolicy specifically
+
+For `ImageValidatingPolicy` (and legacy `verifyImages` rules), confirm:
+
+1. **Public key or KMS key reference** is present and points to a real attestation root (Sigstore / Cosign / Notary / KMS-backed).
+2. **`mutateDigest: true`** — replaces the mutable image tag with the immutable digest at admission. Without this, the verified image can be replaced after admission.
+3. **`verifyDigest: true`** — re-checks the digest against the verified attestation chain.
+4. **`required: true`** on the verification rule — without this, missing signatures pass.
+5. **`match` covers all production registries**, not just public Docker Hub.
+6. **No `imageReferences: ['*']` with `skip: true`** — total signature bypass.
+
+Reference: [Kyverno verify-images / ImageValidatingPolicy](https://kyverno.io/docs/policy-types/cluster-policy/verify-images/).
+
+### Step 6 — Evaluate Kyverno vs native ValidatingAdmissionPolicy (CEL)
+
+Native `ValidatingAdmissionPolicy` (CEL) shipped stable in Kubernetes 1.30 ([reference](https://kubernetes.io/docs/reference/access-authn-authz/validating-admission-policy/)). Kyverno can compile its own policies into native VAP — see [Kyverno docs on VAP generation](https://kyverno.io/docs/policy-types/cluster-policy/validate/).
+
+Choose **native VAP** when:
+
+- The policy is pure validation (no mutation, no generation, no image verification, no cleanup).
+- The CEL expression alone is sufficient — no JMESPath, no API lookup, no `context.apiCall`, no foreach.
+- You want fewer moving parts in the admission path (no Kyverno controller).
+
+Stay with **Kyverno** when:
+
+- You need mutation, generation, cleanup, or image verification.
+- You need cross-resource lookups (`context.apiCall`).
+- You need PolicyReports for compliance evidence.
+- You need PolicyExceptions managed declaratively.
+
+Recommend a path explicitly. "Could be native VAP" without a recommendation is incomplete review.
+
+### Step 7 — Stress-test operational hygiene
+
+- Prefer policies authored with `policies.kyverno.io/v1` over legacy `kyverno.io/v1` — the new API is the long-term path.
+- Prefer explicit `match.any.resources.kinds` lists over wildcards.
+- Prefer policies with `background: true` so existing resources are scanned (catches drift).
+- Prefer policies that emit clear `message` text — admission rejections show this string to the user, and a vague rejection message wastes engineer time.
+- Reports Server should be installed when policy reports are needed at scale — etcd-backed PolicyReports do not scale beyond a few thousand violations. See [Kyverno installation](https://kyverno.io/docs/installation/).
+
+## Output
+
+Return:
+
+- **target**: policy kind, name, match scope, and API version,
+- **evidence level**: `live evidence` / `documentation-based` / `sanitized user evidence` / `inference`,
+- **failure mode**: `Enforce` vs `Audit`, with judgment on whether this matches production posture,
+- **risk findings** (with severity: high / medium / low) — including PolicyException audit, image verification posture, wildcard match, and admission webhook failurePolicy,
+- **architectural recommendation**: stay with Kyverno, migrate to native VAP, or hybrid — with reason,
+- **safest next actions** with sample manifest changes,
+- **rollback plan**: how to remove or revert the policy without breaking running workloads,
+- **assumptions and missing facts**.
+
+## Security notes
+
+- Never recommend `failureAction: Audit` for a production-tier policy unless there is a written rollout plan to `Enforce` with a date.
+- Never recommend exempting `cluster-admin`, the controller's own ServiceAccount, or wildcards in PolicyExceptions.
+- Never recommend disabling image signature verification "temporarily" without a tracked re-enable date.
+- Do not print Cosign private keys, Rekor signature blobs, or registry credentials. Reference key names only.

package/skills/oci/README.md

@@ -0,0 +1,63 @@
+# 🟥 OCI Skills
+
+<p align="center">
+  <img src="../../assets/logos/cloud/oci/oracle-cloud-infrastructure.png" alt="Oracle Cloud Infrastructure logo" width="140" />
+</p>
+
+This folder contains OCI-focused skills curated for this marketplace.
+
+## Local marketplace portfolio
+
+This folder contains **37** local OCI skills:
+
+- `oci-autonomous-database-architect`
+- `oci-cloud-guard-responder`
+- `oci-compute-instance-agent-operator`
+- `oci-compute-platform-operator`
+- `oci-cost-finops-analyst`
+- `oci-database-platform-dba`
+- `oci-dbtools-sql-analyst`
+- `oci-devops-container-platform-engineer`
+- `oci-exadata-database-architect`
+- `oci-exadata-platform-architect`
+- `oci-fusion-apps-environment-operator`
+- `oci-goldengate-replication-operator`
+- `oci-identity-access-governor`
+- `oci-iot-digital-twin-engineer`
+- `oci-limits-capacity-planner`
+- `oci-live-autonomous-db-lifecycle-guard`
+- `oci-live-cost-budget-runaway-guard`
+- `oci-live-iam-policy-compartment-guard`
+- `oci-live-network-security-rule-guard`
+- `oci-live-oke-rollout-guard`
+- `oci-live-resource-manager-stack-guard`
+- `oci-live-vault-key-destruction-guard`
+- `oci-load-balancer-traffic-engineer`
+- `oci-maestro`
+- `oci-migration-cutover-architect`
+- `oci-multi-cloud-architect`
+- `oci-mysql-heatwave-ai-specialist`
+- `oci-network-architect`
+- `oci-observability-incident-responder`
+- `oci-recovery-service-operator`
+- `oci-registry-artifact-governor`
+- `oci-resource-search-inventory-analyst`
+- `oci-security-compliance-reviewer`
+- `oci-solution-architect`
+- `oci-storage-backup-steward`
+- `oci-support-incident-coordinator`
+- `oracle-oci-mcp-grounded-advisor`
+
+## Portfolio posture
+
+Role-based OCI skills for evidence-backed architecture, database operations, security, networking, FinOps, identity governance, and guarded live-environment operations.
+
+These skills are intentionally conservative:
+
+- prefer `oracle-oci-mcp-grounded-advisor` via OCI MCP server when available for live OCI state grounding
+- prefer read-only discovery before mutation
+- require explicit OCID, compartment, tenancy confirmation, approval, rollback posture, and verification for guarded live actions
+- challenge overly broad IAM policies, missing compartment isolation, public exposure, and unclear resource ownership
+- use official OCI documentation and live CLI evidence when service behavior matters
+
+Run `npm run validate` after changing cataloged OCI skills.

package/skills/oci/oci-autonomous-database-architect/SKILL.md

@@ -1,9 +1,12 @@
 ---
 name: oci-autonomous-database-architect
 description: OCI Architect and operate Autonomous Database and Autonomous AI Database across serverless, dedicated Exadata, Cloud@Customer, Oracle Database@Azure, Oracle Database@Google Cloud, and Oracle Database@AWS contexts. Use for ADB design, compatibility, deployment-option selection, networking, security, DR, backup, migration, performance, and multicloud destination reviews.
+allowed-tools: Read Grep Glob
 metadata:
   author: github: Raishin
   version: 0.1.0
+  updated: "2026-05-05"
+  category: data
 ---
 
 # OCI Autonomous Database Architect

package/skills/oci/oci-certificates-issuer-review/SKILL.md

@@ -0,0 +1,40 @@
+---
+name: oci-certificates-issuer-review
+description: Use this skill when reviewing OCI Certificates Service issuer configurations for cert-manager on OKE. Trigger on any request to audit OCI CA hierarchy, issuance rules, OKE Workload Identity vs Instance Principal auth, IAM policy scope, OCSP reachability, or certificate version management.
+allowed-tools: Read Grep Glob
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+  updated: "2026-05-05"
+  category: security
+---
+
+# OCI Certificates Issuer Review
+
+## Purpose
+
+Review Oracle Cloud Infrastructure (OCI) Certificates Service configurations used as cert-manager issuers on OKE (Oracle Kubernetes Engine). Identify CA hierarchy misconfigurations (root vs subordinate), missing issuance rules, overly broad IAM policies, Instance Principal authentication scope risks, OCSP reachability gaps, and certificate version accumulation. Output severity-labeled findings with evidence and remediation steps.
+
+## Lean operating rules
+
+- Flag any OCI issuer that references a ROOT CA directly as CRITICAL — only a SUBORDINATE CA should be used for cert-manager issuance. The ROOT CA must be offline (disabled after subordinate creation) or kept entirely out of the Certificates Service.
+- Check whether OCI issuance rules are configured on the subordinate CA: flag missing validity caps (>90d) and missing key algorithm restrictions (RSA <2048 or EC <P-256) as MEDIUM.
+- Identify the authentication method used by cert-manager to call OCI APIs: flag Instance Principal auth as HIGH — any pod on the OKE node can call the OCI Certificates API via instance metadata. Correct method is OKE Workload Identity (SA-bound, pod-level).
+- Review the OCI IAM policy for cert-manager: flag `manage certificate-authorities` (grants delete/update CA) as HIGH. Minimum required: `use certificate-authorities` with `request.permission='CREATE_CERTIFICATE_REQUEST'`.
+- Check OCSP reachability from OKE worker nodes to `ocsp.pki.oraclecloud.com`. Flag unreachable OCSP endpoint as MEDIUM (soft-fail revocation = revoked certs accepted by most TLS stacks).
+- Review certificate version count; flag high version accumulation (> 10 versions per cert) as LOW (storage cost and management overhead).
+- Label all findings as live evidence, documentation-based, or inference.
+
+## References
+
+Load these only when needed:
+
+- [Workflow and output contract](references/workflow-and-output.md)
+
+## Response minimum
+
+- Severity-labeled findings list (CRITICAL / HIGH / MEDIUM / LOW)
+- Evidence source for each finding
+- Specific resource name, CA OCID, or IAM policy statement that caused the finding
+- Recommended remediation with example OCI CLI command or IAM policy snippet
+- Overall OCI PKI trust posture verdict

package/skills/oci/oci-certificates-issuer-review/metadata.json

@@ -0,0 +1,20 @@
+{
+  "id": "oci-certificates-issuer-review",
+  "name": "OCI Certificates Issuer Review",
+  "type": "skill",
+  "provider": "oci",
+  "harnesses": ["codex", "claude-code", "cursor", "gemini", "kiro", "other"],
+  "summary": "Review OCI Certificates Service issuer configurations for cert-manager on OKE, covering CA hierarchy safety, issuance rule enforcement, OKE Workload Identity vs Instance Principal authentication, IAM policy scope minimization, OCSP reachability, and certificate version lifecycle management.",
+  "source_type": "original",
+  "official_docs": [
+    "https://docs.oracle.com/en-us/iaas/Content/certificates/home.htm",
+    "https://docs.oracle.com/en-us/iaas/Content/certificates/managing-certificate-authority.htm",
+    "https://docs.oracle.com/en-us/iaas/Content/ContEng/Tasks/contengusingworkloadidentity.htm",
+    "https://github.com/oracle/oci-native-ingress-controller"
+  ],
+  "security_notes": "Instance Principal auth for cert-manager on OKE means ANY pod on the node can call the OCI Certificates API using the instance metadata endpoint — not just cert-manager. Use OKE Workload Identity to scope cert-issuance permissions to the cert-manager ServiceAccount only. IAM policy with 'manage certificate-authorities' grants delete and update CA permissions, which is excessive for cert-manager.",
+  "last_verified": "2026-05-02",
+  "path": "skills/oci/oci-certificates-issuer-review",
+  "author": "github: Raishin",
+  "version": "0.1.0"
+}