@raishin/vanguard-frontier-agentic 1.2.0 → 1.3.0

package/skills/backstage/backstage-scaffolder-template-review/references/workflow-and-output.md

@@ -0,0 +1,179 @@
+# Workflow and output contract
+
+Use this reference only when performing a full Backstage Scaffolder template review, producing implementation guidance, triaging a scaffolder security incident, or completing a production-readiness pass.
+
+## Review domains
+
+Check these areas before giving a verdict:
+
+- Template `metadata.name`, `spec.owner`, and namespace scoping
+- Each `steps:` entry: action type, input parameters, and provisioning blast radius
+- Input `parameters:` schema: type enforcement, `maxLength`, `pattern`, `enum`, and data-flow into step inputs
+- RBAC permission gate: presence and scope of `@backstage/plugin-permission-backend` policies for this template
+- Integration secret scope: GitHub PAT, Azure DevOps token, or other credential used by `publish:*` actions
+- `catalog:register` usage: whether registered YAML is user-supplied or template-controlled
+- `output:` stanza: whether plaintext secrets or credentials are surfaced in the Backstage UI
+
+## Safe workflow
+
+1. **Frame scope**
+   - Template name and `spec.owner`:
+   - Target environment (dev / staging / production):
+   - Backstage version and active plugins:
+   - Whether `@backstage/plugin-permission-backend` is installed:
+   - Required outcome of this review:
+   - Explicit non-goals:
+
+2. **Collect evidence**
+   - Prefer user-provided sanitized Template YAML as primary evidence.
+   - Confirm Backstage version and installed plugins from `app-config.yaml` or Backstage `package.json`.
+   - Label each finding as `user-provided evidence`, `documentation-based`, or `inference`.
+
+3. **Map action blast radius**
+   For each `steps[].action`, ask:
+   ```
+   - What external system does this action write to?
+   - What credential does it use and what is that credential's scope?
+   - Is there an RBAC permission policy gating this template for that action?
+   - Can a user-controlled input reach this action unsanitized?
+   ```
+   Example: `publish:github` with `repoUrl: ${{ parameters.repoName }}` where `repoName` has no `pattern`
+   validation — a value like `../../../sensitive-repo` could traverse the expected org boundary.
+
+4. **Validate input parameter schema**
+   Check each parameter field:
+   ```yaml
+   parameters:
+     - title: Repository Name
+       properties:
+         repoName:
+           type: string
+           # REQUIRED: maxLength to prevent oversized inputs
+           maxLength: 63
+           # REQUIRED: pattern to block path traversal and injection
+           pattern: '^[a-z0-9][a-z0-9-]{0,61}[a-z0-9]$'
+   ```
+   Missing `maxLength` or `pattern` on fields that flow into `publish:github.repoUrl`,
+   `roadiehq:utils:fs:write`, or shell-exec actions is a HIGH finding.
+
+5. **Check RBAC permission gate**
+   A permission policy protecting a Terraform-provisioning template looks like:
+   ```typescript
+   // packages/backend/src/plugins/permission.ts
+   if (
+     isPermission(request.permission, scaffolderTemplateRules.instantiateTemplate)
+   ) {
+     if (request.credentials.principal.type === 'user') {
+       const groups = await catalogClient.getEntities({
+         filter: { kind: 'Group', 'spec.members': request.credentials.principal.userEntityRef }
+       });
+       const isPlatformEngineer = groups.items.some(g => g.metadata.name === 'platform-engineers');
+       return { result: isPlatformEngineer ? AuthorizeResult.ALLOW : AuthorizeResult.DENY };
+     }
+   }
+   ```
+   If no policy like this exists for infrastructure-provisioning templates, flag as CRITICAL.
+
+6. **Assess integration secret scope**
+   Examine the Backstage `integrations:` config that the template's `publish:*` action uses:
+   ```yaml
+   # app-config.yaml
+   integrations:
+     github:
+       - host: github.com
+         token: ${GITHUB_TOKEN}  # scope: repo (read/write all repos in org)
+   ```
+   A token with `repo` scope on all org repos means any template using `publish:github`
+   can write to any repo in the org. Prefer a scoped GitHub App with per-repo installation.
+
+7. **Review catalog:register usage**
+   ```yaml
+   steps:
+     - id: register
+       action: catalog:register
+       input:
+         repoContentsUrl: ${{ steps['publish'].output.repoContentsUrl }}
+         catalogInfoPath: '/catalog-info.yaml'
+   ```
+   If `catalogInfoPath` or the registered YAML content is user-controlled (not template-generated),
+   it can inject arbitrary `spec.owner`, `spec.lifecycle`, or `metadata.annotations` values
+   into the catalog — overwriting existing entities' ownership metadata. Flag as MEDIUM.
+
+8. **Inspect output stanza**
+   ```yaml
+   output:
+     links:
+       - title: Repository
+         url: ${{ steps['publish'].output.remoteUrl }}
+     # HIGH: do not surface generated credentials here
+     # - title: Database password
+     #   url: ${{ steps['create-db'].output.password }}
+   ```
+   Any `output:` value that contains a generated password, API key, connection string,
+   or bearer token is a HIGH finding — it persists in the Backstage task log in plaintext.
+
+9. **Recommend the smallest safe action**
+   - Prefer narrowing input validation before adding RBAC, as validation is deploy-free.
+   - For RBAC gaps, provide the minimum permission policy snippet.
+   - If the safest action is to quarantine the template (mark it `spec.lifecycle: deprecated`
+     and alert the platform team), say that plainly.
+
+## Validation commands
+
+```bash
+# List all templates in the catalog
+kubectl get templates -n backstage --all-namespaces
+
+# Inspect a specific template
+kubectl get template <name> -n backstage -o yaml
+
+# Check whether permission backend plugin is present
+grep -r 'plugin-permission-backend' packages/backend/package.json
+
+# List Backstage integrations config (sanitize before sharing)
+grep -A5 'integrations:' app-config.yaml
+
+# Enumerate templates with no permission policy annotation
+kubectl get templates -A -o json | jq '.items[] | select(.metadata.annotations["backstage.io/permission-policy"] == null) | .metadata.name'
+```
+
+## Output contract
+
+Return this structure:
+
+```markdown
+# Backstage Scaffolder Template Review: <template-name>
+
+## Executive verdict
+- Status: SAFE / SAFE WITH RISKS / NOT SAFE / NEEDS EVIDENCE
+- Biggest risk:
+- Evidence level:
+
+## Scope and assumptions
+- Template name and owner:
+- Backstage version:
+- Permission backend installed:
+- Confirmed:
+- Unknown:
+- Out of scope:
+
+## Findings
+
+| Severity | Field / Step | Finding | Evidence | Why it matters | Minimum safe action |
+|---|---|---|---|---|---|
+
+## Action blast radius summary
+
+| Step ID | Action | Blast radius | RBAC gated? |
+|---|---|---|---|
+
+## Recommended actions
+1. <action> — owner: <owner>, validation: <check>, rollback: <rollback>
+
+## Validation
+- Commands or checks:
+- Expected result:
+
+## Residual risk
+- <risk or explicit none>
+```

package/skills/cert-manager/cert-manager-issuer-trust-review/SKILL.md

@@ -0,0 +1,40 @@
+---
+name: cert-manager-issuer-trust-review
+description: Use this skill when reviewing cert-manager PKI configuration for Kubernetes clusters. Trigger when the user asks about Issuer or ClusterIssuer scope, CertificateRequestPolicy coverage, certificate SAN or duration risks, trust-manager bundle distribution, SPIFFE mesh CA integration, cert-manager webhook health, or cloud CA authentication method.
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+---
+
+# cert-manager Issuer Trust Review
+
+## Purpose
+
+Review cert-manager Issuer and ClusterIssuer scope, CertificateRequestPolicy (approver-policy) authorization coverage, certificate SAN wildcard and duration risks, trust-manager CA bundle distribution blast radius, SPIFFE/service-mesh CA integration, and cloud-backed CA authentication method. cert-manager's security posture depends on whether namespace-scoped request authorization exists — without CertificateRequestPolicy, any namespace can issue a certificate for any DNS name from a shared ClusterIssuer.
+
+## Lean operating rules
+
+- Prefer live evidence (`kubectl get clusterissuer,issuer -A -o yaml`, `kubectl get certificaterequestpolicy -o yaml`, `kubectl get certificate -A -o yaml`) when the active client exposes it; otherwise fall back to official cert-manager documentation and sanitized YAML from the user.
+- Separate confirmed facts from inference. If CertificateRequestPolicy deployment, certificate health, or trust-manager bundle scope was not directly queried, say so.
+- Treat no CertificateRequestPolicy deployed cluster-wide as a critical finding — any cert request in any namespace is auto-approved against any ClusterIssuer.
+- Treat a ClusterIssuer backed by a corporate private CA with no namespace restriction via CertificateRequestPolicy as a high finding — any namespace can request corp-trusted certs.
+- Treat Certificate `spec.dnsNames` containing wildcards like `*.internal.company.com` for a single microservice as a high finding — overly broad trust grants.
+- Treat `spec.duration` exceeding 90 days for workload certs as a high finding; certs with `duration: 87600h` (10 years) are critical.
+- Treat cert-manager-webhook in a degraded or failing state as a high finding — no new cert renewals can complete.
+- Treat a trust-manager Bundle with no namespace selector distributing CA bundles to all namespaces as a medium finding unless intentionally cluster-wide.
+- Keep the answer scoped, evidence-labeled, and explicit about what was not queried.
+
+## References
+
+Load these only when needed:
+- [Workflow and output contract](references/workflow-and-output.md)
+
+## Response minimum
+
+Return, at minimum:
+- the scoped target (ClusterIssuer, Issuer, Certificate, CertificateRequestPolicy, or trust-manager Bundle) and evidence level,
+- the issuer type and backing CA (self-signed, ACME, AWS PCA, Azure Key Vault, Vault, etc.) and whether it is namespace-scoped or cluster-scoped,
+- CertificateRequestPolicy presence and subject/issuer constraint coverage,
+- certificate SAN scope and duration for any reviewed Certificate resources,
+- trust-manager Bundle distribution scope,
+- the safest next actions and any assumptions or blockers.

package/skills/cert-manager/cert-manager-issuer-trust-review/metadata.json

@@ -0,0 +1,22 @@
+{
+  "id": "cert-manager-issuer-trust-review",
+  "name": "cert-manager Issuer Trust Review",
+  "type": "skill",
+  "provider": "cert-manager",
+  "harnesses": ["codex", "claude-code", "cursor", "gemini", "kiro", "other"],
+  "summary": "Review cert-manager Issuer and ClusterIssuer scope, CertificateRequestPolicy (approver-policy) coverage, certificate SAN and duration risks, trust-manager bundle distribution, and cloud CA integration authentication for Kubernetes PKI posture.",
+  "source_type": "original",
+  "official_docs": [
+    "https://cert-manager.io/docs/",
+    "https://cert-manager.io/docs/concepts/certificate/",
+    "https://cert-manager.io/docs/concepts/issuer/",
+    "https://cert-manager.io/docs/projects/approver-policy/",
+    "https://cert-manager.io/docs/projects/trust-manager/",
+    "https://cert-manager.io/docs/configuration/"
+  ],
+  "security_notes": "A ClusterIssuer backed by a corporate Private CA with no CertificateRequestPolicy means any namespace can issue certs for any DNS name trusted by the corporate CA, enabling MITM against internal mTLS services.",
+  "last_verified": "2026-05-02",
+  "path": "skills/cert-manager/cert-manager-issuer-trust-review",
+  "author": "github: Raishin",
+  "version": "0.1.0"
+}

package/skills/cert-manager/cert-manager-issuer-trust-review/references/workflow-and-output.md

@@ -0,0 +1,222 @@
+# Workflow and Output Contract
+
+## Workflow
+
+### Step 1 — Identify scope and collect raw evidence
+
+1. Confirm the review target: a ClusterIssuer, a namespace-scoped Issuer, a Certificate resource, a CertificateRequestPolicy, or a trust-manager Bundle.
+2. List all issuers and their types:
+   ```bash
+   kubectl get clusterissuer -o yaml
+   kubectl get issuer -A -o yaml
+   ```
+   For each issuer, note the `spec` type: `acme`, `ca`, `selfSigned`, `vault`, `venafi`, `acmepca` (AWS), `azureKeyVault`.
+3. List all CertificateRequestPolicy resources (approver-policy CRD):
+   ```bash
+   kubectl get certificaterequestpolicy -o yaml
+   ```
+   If the CRD does not exist, approver-policy is not installed — all cert requests are auto-approved. Record this as a critical gap.
+4. List certificates with their issuers and SAN content:
+   ```bash
+   kubectl get certificate -A -o custom-columns=\
+   "NS:.metadata.namespace,NAME:.metadata.name,ISSUER:.spec.issuerRef.name,\
+   KIND:.spec.issuerRef.kind,DURATION:.spec.duration,DNS:.spec.dnsNames"
+   ```
+
+### Step 2 — Audit ClusterIssuer vs Issuer scope
+
+1. For every ClusterIssuer, determine what namespaces can reference it:
+   - A `ClusterIssuer` has no namespace — any Certificate in any namespace can reference it.
+   - An `Issuer` is namespace-scoped — only Certificates in the same namespace can reference it.
+2. For cloud-backed ClusterIssuers (AWS PCA, Azure Key Vault, Vault), check the authentication method:
+   ```bash
+   # AWS PCA ClusterIssuer — check for IRSA annotation
+   kubectl get clusterissuer <name> -o jsonpath='{.spec.acmepca}' 2>/dev/null
+   kubectl get serviceaccount -n cert-manager cert-manager -o jsonpath='{.metadata.annotations}'
+   ```
+   Flag as **HIGH** if the ClusterIssuer authenticates to a cloud CA using static credentials (AWS access key, Azure client secret) instead of workload identity (IRSA, Azure Workload Identity).
+3. Example of a safely scoped setup vs a risky setup:
+   ```yaml
+   # SAFE: Namespace-scoped Issuer, only one namespace can use it
+   apiVersion: cert-manager.io/v1
+   kind: Issuer
+   metadata:
+     name: internal-ca
+     namespace: payments
+   spec:
+     ca:
+       secretName: payments-ca-secret
+
+   # RISKY: ClusterIssuer for corporate CA with no request policy
+   apiVersion: cert-manager.io/v1
+   kind: ClusterIssuer
+   metadata:
+     name: corp-private-ca
+   spec:
+     acmepca:
+       arn: arn:aws:acm-pca:us-east-1:123456789:certificate-authority/abc
+   ```
+
+### Step 3 — Audit CertificateRequestPolicy coverage
+
+CertificateRequestPolicy is the RBAC layer for PKI. Without it, any Certificate resource is auto-approved.
+
+1. Verify approver-policy is installed:
+   ```bash
+   kubectl get crd certificaterequestpolicies.policy.cert-manager.io
+   ```
+   If not found, record as **CRITICAL**: all certificate requests are auto-approved.
+2. For each CertificateRequestPolicy, inspect the subject constraints:
+   ```bash
+   kubectl get certificaterequestpolicy <name> -o yaml
+   ```
+   Check:
+   - `spec.allowed.dnsNames.values` — which DNS names the policy permits
+   - `spec.allowed.dnsNames.validations` — regex constraints on allowed names
+   - `spec.allowed.subject` — allowed subject distinguished names
+   - `spec.selector.issuerRef` — which issuers this policy covers
+   - `spec.selector.namespace` — which namespaces this policy governs
+3. Example of a correctly constrained CertificateRequestPolicy:
+   ```yaml
+   apiVersion: policy.cert-manager.io/v1alpha1
+   kind: CertificateRequestPolicy
+   metadata:
+     name: payments-internal-certs
+   spec:
+     allowed:
+       dnsNames:
+         values:
+           - "*.payments.svc.cluster.local"
+         validations:
+           - rule: self.endsWith('.payments.svc.cluster.local')
+             message: "DNS name must be in payments namespace service domain"
+       subject:
+         organizations:
+           values: ["payments-team"]
+       usages:
+         - "digital signature"
+         - "key encipherment"
+         - "server auth"
+         - "client auth"
+     selector:
+       issuerRef:
+         name: corp-private-ca
+         kind: ClusterIssuer
+         group: cert-manager.io
+       namespace:
+         matchLabels:
+           team: payments
+   ```
+4. Flag as **CRITICAL** if no CertificateRequestPolicy restricts a ClusterIssuer backed by a corporate or cloud CA.
+5. Flag as **HIGH** if a CertificateRequestPolicy allows `dnsNames` with a wildcard that covers high-value internal FQDNs (e.g., `*.internal.company.com`).
+
+### Step 4 — Audit Certificate SAN and duration
+
+1. For each Certificate, review `spec.dnsNames` for excessive scope:
+   ```bash
+   kubectl get certificate -A -o yaml | grep -A 5 "dnsNames"
+   ```
+2. Flag as **HIGH** any Certificate where a single microservice's cert includes:
+   - `*.internal.company.com` (covers all internal services)
+   - `*.svc.cluster.local` (covers all cluster services)
+3. Review certificate duration and renewal:
+   ```bash
+   kubectl get certificate -A -o custom-columns=\
+   "NAME:.metadata.name,DURATION:.spec.duration,RENEW:.spec.renewBefore,READY:.status.conditions[0].status"
+   ```
+   - Flag as **HIGH** if `duration` exceeds `8760h` (1 year) for workload certs.
+   - Flag as **CRITICAL** if `duration` is `87600h` (10 years) or similar for workload certs.
+   - Flag as **MEDIUM** if `renewBefore` is not set or is less than 1/3 of `duration`.
+4. Verify certificate readiness:
+   ```bash
+   kubectl get certificate -A | grep -v "True"
+   ```
+   Any certificate not in `Ready=True` state that is approaching expiry is a **HIGH** finding.
+
+### Step 5 — Audit cert-manager webhook health
+
+A failing cert-manager webhook blocks all new certificate issuance and renewals.
+
+1. Check webhook pod health:
+   ```bash
+   kubectl get pods -n cert-manager
+   kubectl describe deployment cert-manager-webhook -n cert-manager
+   ```
+2. Check webhook configuration:
+   ```bash
+   kubectl get validatingwebhookconfiguration cert-manager-webhook -o yaml | grep -A 5 "failurePolicy"
+   ```
+   `failurePolicy: Fail` means a webhook outage blocks all cert operations. `failurePolicy: Ignore` means webhook failures are skipped — cert validation is bypassed.
+3. Check for recent CertificateRequest failures:
+   ```bash
+   kubectl get certificaterequest -A | grep -v "True"
+   kubectl describe certificaterequest -A | grep -A 5 "Reason:"
+   ```
+4. Flag as **HIGH** if the cert-manager-webhook deployment has unavailable replicas and any certificates are approaching expiry within 30 days.
+
+### Step 6 — Audit trust-manager Bundle distribution
+
+1. List trust-manager Bundles:
+   ```bash
+   kubectl get bundle -o yaml
+   kubectl get configmapbundle -o yaml 2>/dev/null
+   ```
+2. For each Bundle, check the target namespace selector:
+   ```yaml
+   # RISKY: no namespaceSelector distributes to all namespaces
+   spec:
+     target:
+       configMap:
+         key: "bundle.pem"
+       namespaceSelector: {}   # matches all namespaces
+
+   # SAFE: explicit namespace label selector
+   spec:
+     target:
+       configMap:
+         key: "bundle.pem"
+       namespaceSelector:
+         matchLabels:
+           cert-manager.io/trust-bundle: "enabled"
+   ```
+3. Flag as **MEDIUM** if a Bundle distributes a corporate or cloud CA bundle to all namespaces without a restrictive namespace selector — untrusted workloads receive the CA and can potentially use it for internal service impersonation if combined with a cert issuance gap.
+
+### Step 7 — Audit SPIFFE / service mesh CA integration
+
+1. Check if cert-manager is serving as the Istio CA via istio-csr:
+   ```bash
+   kubectl get pods -n istio-system | grep cert-manager
+   kubectl get cm istio -n istio-system -o yaml | grep caAddress
+   ```
+2. If cert-manager feeds the mesh trust domain, the ClusterIssuer it references is the root of trust for all SPIFFE SVIDs in the mesh.
+   - A compromised ClusterIssuer in this scenario allows forging any SPIFFE SVID for any mesh workload.
+   - Flag as **HIGH** if the mesh CA ClusterIssuer uses a shared corporate private CA without CertificateRequestPolicy constraints on the istio-csr service account.
+3. For Linkerd:
+   ```bash
+   kubectl get secret linkerd-identity-issuer -n linkerd -o yaml | grep -v "^  tls"
+   ```
+   Verify the issuer cert expiry is managed by cert-manager and has a `renewBefore` set.
+
+## Output
+
+Return:
+
+- **target**: ClusterIssuer/Issuer names, Certificate references, or CertificateRequestPolicy names, with evidence source,
+- **evidence level**: `live evidence` / `documentation-based` / `sanitized user evidence` / `inference`,
+- **issuer scope**: namespace-scoped Issuer or cluster-wide ClusterIssuer, backing CA type, authentication method (workload identity vs static credentials),
+- **CertificateRequestPolicy coverage**: present/absent, constrained issuers, allowed DNS names scope, namespace selector,
+- **certificate SAN and duration audit**: wildcard SAN findings, duration exceeding recommended thresholds, renewBefore settings,
+- **webhook health**: cert-manager-webhook pod state, failurePolicy, any CertificateRequest failures,
+- **trust-manager posture**: Bundle distribution scope, namespace selector presence,
+- **mesh integration**: whether cert-manager feeds a mesh CA and the blast radius of that issuer,
+- **risk findings** (with severity: critical / high / medium / low),
+- **safest next actions** with sample YAML,
+- **assumptions and missing facts**.
+
+## Security notes
+
+- Never recommend removing CertificateRequestPolicy to unblock a blocked cert request — the correct path is to add an appropriate policy.
+- Never request or print CA private key contents, PKCS#12 bundles, Vault tokens, or AWS credentials.
+- A ClusterIssuer backed by a corporate Private CA with no CertificateRequestPolicy is equivalent to an open PKI endpoint — any namespace can issue trusted certs for any FQDN.
+- Always confirm approver-policy CRD presence before concluding that cert requests are constrained.
+- cert-manager `failurePolicy: Ignore` on the webhook means the webhook can be bypassed — verify this is not used in production cert issuance paths for sensitive CAs.

package/skills/cilium/README.md

@@ -0,0 +1,30 @@
+# 🐝 Cilium Skills
+
+<p align="center">
+  <!-- 🖼️ Add a Cilium logo to assets/logos/cnative/cilium/ and update this path -->
+  <span style="font-size:3.5em">🐝</span>
+</p>
+
+This folder contains Cilium-focused skills curated for this marketplace.
+
+## Local marketplace portfolio
+
+This folder contains **1** local Cilium skill:
+
+- `cilium-network-policy-review`
+
+## Portfolio posture
+
+Cilium skills for evidence-backed eBPF networking review covering the three policy formats (`NetworkPolicy`, `CiliumNetworkPolicy`, `CiliumClusterwideNetworkPolicy`), L7 policy via embedded Envoy, ClusterMesh cross-cluster semantics, Hubble flow observability, and `CiliumEgressGatewayPolicy` for SNAT egress.
+
+These skills are intentionally conservative:
+
+- prefer `kubectl get networkpolicies,ciliumnetworkpolicies,ciliumclusterwidenetworkpolicies,ciliumegressgatewaypolicies -A -o yaml` for live policy state grounding before any review
+- treat **removal of a default-deny `NetworkPolicy`** as a critical finding — pods become reachable from any source/destination
+- challenge `CiliumNetworkPolicy` egress with `toCIDRSet: [0.0.0.0/0]` — unrestricted egress = data exfiltration path
+- challenge `policy-default-local-cluster` flag changes in ClusterMesh — cross-cluster policy semantics change globally for every existing policy
+- challenge `CiliumEgressGatewayPolicy` IP collisions — two policies SNATing to the same IP cause silent connection breakage
+- prefer `cilium clustermesh inspect-policy-default-local-cluster` before any flag flip — it lists every policy that would change behavior
+- use official Cilium documentation (docs.cilium.io) for policy syntax, CRD versions, ClusterMesh setup, and L7 policy semantics
+
+Run `npm run validate` after changing cataloged Cilium skills.

package/skills/cilium/cilium-network-policy-review/SKILL.md

@@ -0,0 +1,43 @@
+---
+name: cilium-network-policy-review
+description: Use this skill for Cilium network policy review across the three policy formats (Kubernetes NetworkPolicy, CiliumNetworkPolicy, CiliumClusterwideNetworkPolicy), L7 policy via embedded Envoy, ClusterMesh cross-cluster semantics, Hubble flow observability, and CiliumEgressGatewayPolicy. Trigger when the user asks whether a network policy is too broad, whether default-deny is in place, whether L7 rules will actually be enforced, whether ClusterMesh policy semantics are correct, or whether an egress gateway IP collision is possible.
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+---
+
+# Cilium Network Policy Review
+
+## Purpose
+
+Review Cilium policy resources against zero-trust correctness, blast radius, and the operational traps unique to eBPF-backed networking. Cilium's policy surface is broader than native Kubernetes NetworkPolicy — `CiliumNetworkPolicy` adds L7 rules, FQDN matching, ICMP control, and identity-based selectors; `CiliumClusterwideNetworkPolicy` applies cluster-wide; `CiliumEgressGatewayPolicy` controls SNAT egress IPs; and `policy-default-local-cluster` changes how policy evaluates across ClusterMesh.
+
+## Lean operating rules
+
+- Prefer live cluster evidence (`kubectl get networkpolicies,ciliumnetworkpolicies,ciliumclusterwidenetworkpolicies,ciliumegressgatewaypolicies -A -o yaml`, `cilium policy get`, `cilium clustermesh inspect-policy-default-local-cluster`, and Hubble flow observation) when the active client exposes it; otherwise fall back to official Cilium documentation (docs.cilium.io) and sanitized YAML.
+- Separate confirmed facts from inference. If Cilium agent state, ClusterMesh peer status, or Hubble flow data was not queried, say so.
+- Treat **removal of a default-deny `NetworkPolicy`** in a namespace as a critical finding — pods become reachable from any source/destination unless another policy provides isolation.
+- Treat `CiliumNetworkPolicy` egress with `toCIDRSet: [{cidr: 0.0.0.0/0}]` (no `except` for sensitive CIDRs) as a critical finding — unrestricted egress is a documented data exfiltration path.
+- Treat any change to `policy-default-local-cluster` in a ClusterMesh deployment as critical-blast-radius — every existing policy's cross-cluster semantics flip simultaneously.
+- Challenge `CiliumEgressGatewayPolicy` with the same `egressIP` used in two policies — silent connection breakage when both match.
+- Challenge L7 rules in `CiliumNetworkPolicy` for namespaces where Envoy proxy is not enabled — L7 fields require the proxy.
+- 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 Cilium version and ClusterMesh state, or switching to documentation mode.
+- [Workflow and output contract](references/workflow-and-output.md) — use when executing the full review, applying stress checks across the three policy formats and ClusterMesh, or formatting the final answer.
+- [Official sources](references/official-sources.md) — use when you need the detailed Cilium documentation list, CRD schema, and grounded insights.
+
+## Response minimum
+
+Return, at minimum:
+
+- the scoped target (namespace `NetworkPolicy`, namespace `CiliumNetworkPolicy`, cluster-wide `CiliumClusterwideNetworkPolicy`, `CiliumEgressGatewayPolicy`) and evidence level,
+- the default-deny posture in the affected namespace(s),
+- the L7 enforcement assessment (Envoy proxy enabled / required) and whether L7 rules will actually run,
+- the ClusterMesh assessment when applicable (`policy-default-local-cluster` semantics),
+- the safest next actions and rollback plan,
+- the assumptions or blockers that prevent stronger conclusions.

package/skills/cilium/cilium-network-policy-review/metadata.json

@@ -0,0 +1,30 @@
+{
+  "id": "cilium-network-policy-review",
+  "name": "Cilium Network Policy Review",
+  "type": "skill",
+  "provider": "cilium",
+  "harnesses": [
+    "codex",
+    "claude-code",
+    "cursor",
+    "gemini",
+    "kiro",
+    "other"
+  ],
+  "summary": "Review Cilium NetworkPolicy, CiliumNetworkPolicy, CiliumClusterwideNetworkPolicy, CiliumEgressGatewayPolicy, and ClusterMesh policy-default-local-cluster behavior for zero-trust correctness, blast radius, L7 enforcement, and egress gateway IP correctness.",
+  "source_type": "original",
+  "official_docs": [
+    "https://docs.cilium.io/en/stable/",
+    "https://docs.cilium.io/en/stable/network/kubernetes/policy/",
+    "https://docs.cilium.io/en/stable/security/policy/",
+    "https://docs.cilium.io/en/stable/network/clustermesh/",
+    "https://docs.cilium.io/en/stable/network/egress-gateway/egress-gateway/",
+    "https://docs.cilium.io/en/stable/observability/hubble/",
+    "https://docs.cilium.io/en/stable/cmdref/cilium_clustermesh_inspect-policy-default-local-cluster/"
+  ],
+  "security_notes": "Removal of default-deny NetworkPolicy collapses namespace isolation. Unrestricted egress (0.0.0.0/0) is a documented exfiltration path. ClusterMesh policy-default-local-cluster flag flip changes cross-cluster semantics for every existing policy globally. CiliumEgressGatewayPolicy IP collisions cause silent connection breakage.",
+  "last_verified": "2026-05-01",
+  "path": "skills/cilium/cilium-network-policy-review",
+  "author": "github: Raishin",
+  "version": "0.1.0"
+}

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

@@ -0,0 +1,52 @@
+# Evidence Path and Tooling
+
+## Evidence path
+
+1. Prefer live cluster evidence when a Kubernetes MCP server, `kubectl`, the `cilium` CLI, and Hubble are available against the cluster.
+2. Fall back to the official Cilium documentation (docs.cilium.io) for policy syntax, CRD schema, and ClusterMesh semantics when live inspection is unavailable.
+3. Ask only for sanitized policy YAML, `cilium policy get` output, Hubble flow snippets, or ClusterMesh status output when current-state proof matters.
+4. Label conclusions as `live evidence`, `documentation-based`, `sanitized user evidence`, or `inference`.
+
+## Useful live-evidence commands
+
+```shell
+# All policy formats across the cluster
+kubectl get networkpolicies,ciliumnetworkpolicies,ciliumclusterwidenetworkpolicies -A -o yaml
+
+# Egress gateway policies
+kubectl get ciliumegressgatewaypolicies -A -o yaml
+
+# Cilium agent state and policy enforcement
+kubectl -n kube-system get pods -l k8s-app=cilium -o name
+kubectl -n kube-system exec -it <cilium-pod> -- cilium status
+kubectl -n kube-system exec -it <cilium-pod> -- cilium policy get
+kubectl -n kube-system exec -it <cilium-pod> -- cilium endpoint list
+
+# Hubble flow observation (live traffic vs policy)
+hubble observe --from-namespace <ns> --to-namespace <ns> --verdict DROPPED
+hubble observe --to-fqdn <fqdn> --verdict DROPPED --last 1000
+
+# ClusterMesh state
+cilium clustermesh status
+cilium clustermesh inspect-policy-default-local-cluster -A -o json
+
+# Policy verification — what does Cilium think this pod is allowed to do?
+kubectl -n kube-system exec -it <cilium-pod> -- \
+  cilium policy trace --src-k8s-pod <ns>/<src-pod> --dst-k8s-pod <ns>/<dst-pod>
+```
+
+## Cilium state to confirm before review
+
+- Cilium version (`kubectl -n kube-system exec <cilium-pod> -- cilium version`) — L7 policy support, ClusterMesh features, and CRD versions evolve across releases.
+- Envoy proxy enabled — required for L7 policy fields (`toPorts.rules.http`, `toPorts.rules.kafka`, `toPorts.rules.dns`).
+- ClusterMesh enabled (`cilium clustermesh status`) — multi-cluster policies are evaluated differently when ClusterMesh is up.
+- `policy-default-local-cluster` setting (per cluster, configurable via Helm) — changes whether policies match cross-cluster identities by default.
+- IPAM mode (`cluster-pool`, `kubernetes`, `eni`, `azure`, `aws-eni`) — affects the IP pool and any egress gateway IP planning.
+- Hubble enabled — required for flow observability and policy debugging.
+- Tetragon installed (separate but Cilium-affiliated) — runtime security; relevant when reviewing combined eBPF posture.
+
+## Sanitization rules
+
+- Never request kubeconfig contents, ClusterMesh peer Secrets, or Cilium agent tokens.
+- Replace identifiable cluster IDs, peer cluster URLs, public egress IPs (when sensitive), and namespace names with placeholders unless the user provides them.
+- Do not print Cilium agent service account tokens.

package/skills/cilium/cilium-network-policy-review/references/official-sources.md

@@ -0,0 +1,30 @@
+# Official Sources
+
+Load these only when needed:
+
+- [Cilium documentation home](https://docs.cilium.io/en/stable/) — use as the entry point for any Cilium question.
+- [Network Policy](https://docs.cilium.io/en/stable/network/kubernetes/policy/) — use for the three policy formats (`NetworkPolicy`, `CiliumNetworkPolicy`, `CiliumClusterwideNetworkPolicy`) and how Cilium distributes them.
+- [Policy language reference](https://docs.cilium.io/en/stable/security/policy/language/) — use for `endpointSelector`, `toEndpoints`, `toCIDRSet`, `toFQDNs`, `toServices`, `toEntities`, L7 HTTP/Kafka/DNS rule syntax.
+- [Policy enforcement modes](https://docs.cilium.io/en/stable/security/policy/intro/) — use for `default`, `always`, `never` enforcement modes and Cilium's identity-based model.
+- [ClusterMesh overview](https://docs.cilium.io/en/stable/network/clustermesh/) — use for multi-cluster service discovery, identity propagation, and cross-cluster policy.
+- [`cilium clustermesh inspect-policy-default-local-cluster`](https://docs.cilium.io/en/stable/cmdref/cilium_clustermesh_inspect-policy-default-local-cluster/) — use before any flag flip; lists every policy whose scope would change.
+- [Egress Gateway](https://docs.cilium.io/en/stable/network/egress-gateway/egress-gateway/) — use for `CiliumEgressGatewayPolicy` SNAT semantics, gateway node selection, and IP collision behavior.
+- [Hubble Observability](https://docs.cilium.io/en/stable/observability/hubble/) — use for flow observation, drop debugging, and policy verification.
+- [Hubble CLI reference](https://docs.cilium.io/en/stable/cmdref/hubble/) — use for `hubble observe` filters and output formats.
+- [Cilium Ingress / Gateway API](https://docs.cilium.io/en/stable/network/servicemesh/) — use when Cilium service mesh (sidecar-free) is in scope alongside policy.
+- [Cilium Service Mesh Beta / GA notes](https://docs.cilium.io/en/stable/network/servicemesh/) — use to understand when Cilium service mesh replaces Istio in the L7 enforcement path.
+- [Tetragon documentation](https://tetragon.io/docs/) — use when runtime security observability and enforcement is in scope alongside Cilium network policy.
+- [Cilium release notes](https://github.com/cilium/cilium/releases) — use for version-specific behavior changes, especially around `policy-default-local-cluster` defaults.
+
+## Grounded insights worth carrying into the skill
+
+- Cilium supports three policy formats simultaneously in one cluster: native `NetworkPolicy`, `CiliumNetworkPolicy` (CNP) for namespace-scoped L3-L7, and `CiliumClusterwideNetworkPolicy` (CCNP) for cluster-wide L3-L7.
+- `CiliumNetworkPolicy` adds capabilities native NetworkPolicy lacks: FQDN matching (`toFQDNs`), L7 HTTP/Kafka/DNS rules, identity-based selectors (Cilium endpoint identities derived from labels), `toEntities` (cluster, world, host, kube-apiserver), and ICMP rules.
+- Cilium's effective policy is the **union** of all selecting allows. There is no DENY action — restriction comes from default-deny on selected pods plus explicit allow rules that collectively define the allowed graph.
+- A pod becomes deny-by-default only when **at least one ingress policy selects it for ingress** or **at least one egress policy selects it for egress**. Pods with no selecting policy are allow-all in that direction.
+- ClusterMesh's `policy-default-local-cluster` flag changes whether identity selectors match endpoints in peer clusters. Setting it to `true` (the newer default in 1.16+) makes selectors local-only unless the policy explicitly opts into cross-cluster matching with `cluster: <name>`. Migrating an existing cluster from `false` to `true` silently breaks every policy that depended on cross-cluster matching.
+- `CiliumEgressGatewayPolicy` controls SNAT egress IPs for selected pods. The most common operational pitfall is two policies SNATing to the same `egressIP` — connection-tracking on the gateway node confuses replies, and connections drop intermittently.
+- L7 policy fields (HTTP, Kafka, DNS) require Cilium's embedded Envoy proxy. Without Envoy enabled, the L7 fields are either rejected at admission or silently dropped depending on the Cilium version. Always verify Envoy state before relying on L7.
+- `toCIDRSet: [{cidr: 0.0.0.0/0}]` with no `except` for the cloud metadata service IP (`169.254.169.254` on AWS/Azure/GCP) is the exfiltration path AWS Capital One famously suffered from. Cilium's `except` clause is the right tool to block it while still allowing general internet egress.
+- Hubble flow observation is the only reliable way to verify what Cilium's eBPF programs are actually doing — static policy review can miss conflicts between policies that share endpoint selectors but differ in port or L7 rules.
+- Tetragon (eBPF runtime security) is a separate Cilium-affiliated project, not part of Cilium itself. When a review touches runtime syscall monitoring, link to Tetragon docs explicitly rather than assuming Cilium provides it.