@raishin/vanguard-frontier-agentic 1.2.0 → 1.3.0

package/skills/argocd/argocd-gitops-review/SKILL.md

@@ -0,0 +1,43 @@
+---
+name: argocd-gitops-review
+description: Use this skill for Argo CD GitOps review across Application, AppProject, ApplicationSet, sync windows, RBAC, sync impersonation, and Argo CD Agent multi-cluster topologies. Trigger when the user asks whether an Argo CD configuration is safe for production, whether automated sync should be enabled, whether prune+selfHeal is appropriate, whether AppProject scope is too wide, or how to enforce least-privilege sync identity.
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+---
+
+# Argo CD GitOps Review
+
+## Purpose
+
+Review Argo CD `Application`, `AppProject`, `ApplicationSet`, sync windows, RBAC, and the central `argocd-cm` / `argocd-rbac-cm` configuration against blast radius, drift handling, and least-privilege sync identity. Argo CD's controller defaults to cluster-admin permissions on every destination cluster — the security posture lives in `AppProject` boundaries, sync impersonation, and explicit RBAC, not in the controller defaults.
+
+## Lean operating rules
+
+- Prefer live cluster evidence (`kubectl get applications,appprojects,applicationsets -n argocd -o yaml` plus the `argocd-cm` and `argocd-rbac-cm` ConfigMaps) when the active client exposes it; otherwise fall back to official Argo CD documentation and sanitized YAML from the user.
+- Separate confirmed facts from inference. If sync history, current health, or RBAC binding state was not queried, say so.
+- Treat `application.sync.impersonation.enabled: false` (default) in production as a critical finding — every sync runs as the controller's cluster-admin ServiceAccount.
+- Treat `AppProject` with `sourceRepos: ['*']` and `destinations: ['*']` as a wide-blast-radius finding — any commit in any repo can deploy anywhere.
+- Treat `automated.prune: true` + `automated.selfHeal: true` on production Applications as critical without an explicit allowlist of authorized Git refs and a tested rollback runbook — Git divergence becomes irreversible deletion.
+- Challenge `ApplicationSet` generators that include unbounded clusters (`clusters: {}`) or label selectors with no exclusion — one mis-labeled cluster joins the rollout.
+- Challenge `syncOptions: ['Replace=true']` and `syncOptions: ['ServerSideApply=false']` on stateful resources — Replace deletes-then-creates, breaking PVC bindings.
+- 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 Argo CD install state and version, or switching to documentation mode.
+- [Workflow and output contract](references/workflow-and-output.md) — use when executing the full review, applying stress checks on Application / AppProject / ApplicationSet, or formatting the final answer.
+- [Official sources](references/official-sources.md) — use when you need the detailed Argo CD documentation list, RBAC syntax, and grounded insights from the project.
+
+## Response minimum
+
+Return, at minimum:
+
+- the scoped target (`Application`, `AppProject`, `ApplicationSet`, or `argocd-rbac-cm` policy) and evidence level,
+- the sync identity (controller default cluster-admin, impersonated ServiceAccount, or `destinationServiceAccount`),
+- the blast radius assessment (`sourceRepos`, `destinations`, `clusterResourceWhitelist`, `namespaceResourceBlacklist`),
+- the drift handling posture (`automated`, `prune`, `selfHeal`, `syncWindows`),
+- the safest next actions and rollback plan,
+- the assumptions or blockers that prevent stronger conclusions.

package/skills/argocd/argocd-gitops-review/metadata.json

@@ -0,0 +1,30 @@
+{
+  "id": "argocd-gitops-review",
+  "name": "Argo CD GitOps Review",
+  "type": "skill",
+  "provider": "argocd",
+  "harnesses": [
+    "codex",
+    "claude-code",
+    "cursor",
+    "gemini",
+    "kiro",
+    "other"
+  ],
+  "summary": "Review Argo CD Application, AppProject, ApplicationSet, sync windows, RBAC, sync impersonation, and Argo CD Agent multi-cluster topologies for blast radius, drift handling, and least-privilege sync identity.",
+  "source_type": "original",
+  "official_docs": [
+    "https://argo-cd.readthedocs.io/en/stable/",
+    "https://argo-cd.readthedocs.io/en/stable/operator-manual/declarative-setup/",
+    "https://argo-cd.readthedocs.io/en/stable/user-guide/auto_sync/",
+    "https://argo-cd.readthedocs.io/en/stable/operator-manual/applicationset/",
+    "https://argo-cd.readthedocs.io/en/stable/operator-manual/rbac/",
+    "https://argo-cd.readthedocs.io/en/stable/proposals/decouple-application-sync-user-using-impersonation/",
+    "https://argo-cd.readthedocs.io/en/stable/operator-manual/argocd-cm-yaml/"
+  ],
+  "security_notes": "Sync impersonation is disabled by default — controller runs as cluster-admin on every destination. AppProject sourceRepos and destinations wildcards remove blast-radius bounds. Automated prune+selfHeal on Git divergence is irreversible. ApplicationSet unbounded cluster generators auto-onboard misconfigured clusters.",
+  "last_verified": "2026-05-01",
+  "path": "skills/argocd/argocd-gitops-review",
+  "author": "github: Raishin",
+  "version": "0.1.0"
+}

package/skills/argocd/argocd-gitops-review/references/mcp-and-evidence.md

@@ -0,0 +1,53 @@
+# Evidence Path and Tooling
+
+## Evidence path
+
+1. Prefer live cluster evidence when a Kubernetes MCP server, `kubectl`, or the `argocd` CLI is available against the Argo CD control-plane cluster.
+2. Fall back to official Argo CD documentation (argo-cd.readthedocs.io) and the upstream argo-cd GitHub repository when live inspection is unavailable.
+3. Ask only for sanitized `Application` / `AppProject` / `ApplicationSet` YAML, the redacted `argocd-cm` and `argocd-rbac-cm` ConfigMaps, and `argocd app history` 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 Applications, AppProjects, and ApplicationSets in the argocd namespace
+kubectl -n argocd get applications,appprojects,applicationsets -o yaml
+
+# Detailed Application status (sync, health, lastSyncRevision)
+kubectl -n argocd get application <app-name> -o yaml
+argocd app get <app-name>
+argocd app history <app-name>
+
+# Argo CD configuration (the global config knobs)
+kubectl -n argocd get configmap argocd-cm -o yaml
+kubectl -n argocd get configmap argocd-rbac-cm -o yaml
+kubectl -n argocd get configmap argocd-cmd-params-cm -o yaml
+
+# RBAC effective policy
+argocd account list
+argocd account get-user-info <user>
+
+# Cluster registrations (every destination cluster has its own Secret)
+kubectl -n argocd get secrets -l argocd.argoproj.io/secret-type=cluster -o yaml
+
+# Sync windows on an AppProject
+kubectl -n argocd get appproject <project> -o jsonpath='{.spec.syncWindows}'
+
+# Argo CD Agent (hub-and-spoke deployments)
+kubectl -n argocd get agents -o yaml
+```
+
+## Argo CD install state to confirm before review
+
+- Argo CD version (`kubectl -n argocd get deploy argocd-server -o jsonpath='{.spec.template.spec.containers[0].image}'`) — sync impersonation, RBAC granular actions, and ApplicationSet RollingSync arrived in different versions.
+- `application.sync.impersonation.enabled` in `argocd-cm` — `false` (default) means every sync runs as the controller's ServiceAccount on every destination.
+- `application.sync.requireOverridePrivilegeForRevisionSync` in `argocd-cm` — `true` requires explicit override permission for ad-hoc revision syncs.
+- `webhook.maxPayloadSizeMB` in `argocd-cm` — large Helm value files may exceed the default.
+- Whether Argo CD Agent (argocd-agent) is in use for hub-and-spoke multi-cluster — different security model.
+- Whether Argo CD Autopilot manages Argo CD itself via GitOps — change review must include the Autopilot repo.
+
+## Sanitization rules
+
+- Never request kubeconfig contents, cluster Secret contents, repository SSH keys, or webhook signing secrets in chat.
+- Replace identifiable cluster URLs and namespaces with placeholders unless the user provides them and confirms it is safe to use them.
+- Do not print Git repository tokens, OCI registry tokens, or Helm OCI credentials.

package/skills/argocd/argocd-gitops-review/references/official-sources.md

@@ -0,0 +1,32 @@
+# Official Sources
+
+Load these only when needed:
+
+- [Argo CD documentation home](https://argo-cd.readthedocs.io/en/stable/) — use as the entry point for any Argo CD authoring, install, or operator-side question.
+- [Declarative setup](https://argo-cd.readthedocs.io/en/stable/operator-manual/declarative-setup/) — use for `Application`, `AppProject`, cluster Secret, repository Secret, and ConfigMap structure.
+- [argocd-cm reference](https://argo-cd.readthedocs.io/en/stable/operator-manual/argocd-cm-yaml/) — use for global controller knobs including `application.sync.impersonation.enabled`, `application.sync.requireOverridePrivilegeForRevisionSync`, and `webhook.maxPayloadSizeMB`.
+- [Auto-sync](https://argo-cd.readthedocs.io/en/stable/user-guide/auto_sync/) — use for `automated`, `prune`, `selfHeal` semantics and operational guidance.
+- [Sync Options](https://argo-cd.readthedocs.io/en/stable/user-guide/sync-options/) — use for `Replace`, `Force`, `ServerSideApply`, `PruneLast`, `CreateNamespace`, `Validate=false`, `RespectIgnoreDifferences`.
+- [Sync Windows](https://argo-cd.readthedocs.io/en/stable/user-guide/sync_windows/) — use for deploy-freeze enforcement at the AppProject level.
+- [ApplicationSet Generators](https://argo-cd.readthedocs.io/en/stable/operator-manual/applicationset/Generators/) — use for `list`, `cluster`, `git`, `matrix`, `merge`, `pullRequest`, `scmProvider` generator semantics.
+- [ApplicationSet Progressive Syncs (RollingSync)](https://argo-cd.readthedocs.io/en/stable/operator-manual/applicationset/Progressive-Syncs/) — use for staged ApplicationSet rollouts.
+- [Argo CD RBAC](https://argo-cd.readthedocs.io/en/stable/operator-manual/rbac/) — use for `policy.csv` syntax, default role, group bindings, and granular action permissions.
+- [Sync impersonation proposal](https://argo-cd.readthedocs.io/en/stable/proposals/decouple-application-sync-user-using-impersonation/) — use for the AppProject `destinationServiceAccounts` field and the least-privilege sync identity model.
+- [Argo CD upgrading guide](https://argo-cd.readthedocs.io/en/stable/operator-manual/upgrading/) — use when version-specific RBAC actions or API fields matter.
+- [Argo CD User Management](https://argo-cd.readthedocs.io/en/stable/operator-manual/user-management/) — use for SSO via OIDC / SAML / Dex and group claims.
+- [Argo CD Webhook](https://argo-cd.readthedocs.io/en/stable/operator-manual/webhook/) — use for repository webhook setup and signature verification.
+- [Argo CD Agent](https://github.com/argoproj-labs/argocd-agent) — use for hub-and-spoke multi-cluster topologies replacing direct cluster registrations.
+- [Argo CD Autopilot](https://github.com/argoproj-labs/argocd-autopilot) — use when Argo CD itself is managed via GitOps.
+
+## Grounded insights worth carrying into the skill
+
+- The Argo CD controller defaults to running as cluster-admin on every destination cluster. The `application.sync.impersonation.enabled` flag in `argocd-cm` is the switch that activates per-Application ServiceAccount impersonation via `destinationServiceAccounts` on the AppProject.
+- `AppProject` boundaries are the only enforced isolation between teams sharing one Argo CD instance. Wildcards in `sourceRepos`, `destinations`, `clusterResourceWhitelist`, or empty `namespaceResourceBlacklist` collapse the boundary.
+- `automated.selfHeal: true` combined with `automated.prune: true` means a Git revert (or Git outage that exposes a stale ref) deletes prod resources. There is no built-in confirmation step.
+- ApplicationSet's `cluster` generator with an empty selector auto-onboards every newly registered cluster. This is the most-cited blast-radius mode in Argo CD post-incident reviews.
+- ApplicationSet RollingSync intentionally forces auto-sync **disabled** on generated Applications (the controller logs warnings if any have auto-sync enabled). RollingSync drives sync via OutOfSync detection, not auto-sync.
+- The `Replace=true` sync option is destructive on `StatefulSet`, `Service`, `PersistentVolumeClaim`, and any resource with finalizers. Argo CD's default three-way merge (or server-side apply on newer versions) is safer.
+- Argo CD RBAC granular actions (e.g., `action/apps/Deployment/restart`, `action/argoproj.io/Rollout/abort`) shipped in v2.8+. Older policies that don't list these still work but won't grant the action — operators may discover gaps after upgrade.
+- The `requireOverridePrivilegeForRevisionSync: true` flag in `argocd-cm` requires explicit `override` permission to sync to a non-tracked revision (e.g., a branch instead of HEAD of the configured target). This blocks easy ad-hoc syncs that bypass Git review.
+- Argo CD Autopilot's bootstrap repo manages Argo CD itself — changes to that repo can disable RBAC, weaken AppProject scopes, or rotate the admin password. Treat the Autopilot repo as a tier-0 control surface.
+- The Argo CD Agent (argocd-agent) introduces a hub-and-spoke topology where the central Argo CD installation does not hold cluster credentials for spoke clusters; agents connect outbound. Different threat model from the classic direct-cluster registration.

package/skills/argocd/argocd-gitops-review/references/workflow-and-output.md

@@ -0,0 +1,120 @@
+# Workflow and Output Contract
+
+## Workflow
+
+### Step 1 — Identify the target and the surrounding AppProject
+
+1. Confirm the kind: `Application`, `AppProject`, `ApplicationSet`, or a global ConfigMap (`argocd-cm`, `argocd-rbac-cm`).
+2. For an `Application`, locate the `spec.project` reference and review the `AppProject` first — the AppProject defines the boundary the Application operates within.
+3. For an `AppProject`, list every `Application` referencing it (`kubectl -n argocd get applications -o jsonpath='{range .items[?(@.spec.project=="<project>")]}{.metadata.name}{"\n"}{end}'`).
+4. For an `ApplicationSet`, identify the generator type (`list`, `cluster`, `git`, `matrix`, `merge`, `pullRequest`, `scmProvider`) and the `spec.template`.
+
+### Step 2 — Audit the AppProject blast radius
+
+The AppProject defines four boundary surfaces. Each is a potential blast-radius finding:
+
+1. **`sourceRepos`** — the Git or Helm repos this project may pull from. `['*']` means any repo. Recommended: explicit list.
+2. **`destinations`** — the (cluster, namespace) tuples this project may deploy to. `[{server: '*', namespace: '*'}]` means anywhere. Recommended: explicit cluster URLs and namespace allowlist (or `namespace: 'team-*'` for multi-tenant patterns).
+3. **`clusterResourceWhitelist`** — cluster-scoped resources this project may manage. Empty or `['*/*']` means any cluster-scoped resource (including ClusterRoleBindings, Namespaces). Recommended: empty for application projects; explicit list for platform projects.
+4. **`namespaceResourceBlacklist`** — namespace-scoped resources this project may NOT manage. Recommended: include `[{group: 'rbac.authorization.k8s.io', kind: '*'}]` for application projects to prevent applications from binding their own RBAC.
+
+Reference: [AppProject in declarative setup](https://argo-cd.readthedocs.io/en/stable/operator-manual/declarative-setup/).
+
+### Step 3 — Audit sync identity (the most under-reviewed control)
+
+Three sync identity modes exist; pick one and verify:
+
+1. **Controller default** — Argo CD controller's ServiceAccount on the destination cluster. Default is broad (cluster-admin in many installs). **Critical finding** if production Applications use this without an audit trail of what the controller can do.
+2. **Sync impersonation** (preferred for least privilege) — `application.sync.impersonation.enabled: true` in `argocd-cm` plus `destinationServiceAccounts` on the AppProject. Each Application syncs as a per-namespace ServiceAccount with scoped RBAC. See the [sync impersonation proposal](https://argo-cd.readthedocs.io/en/stable/proposals/decouple-application-sync-user-using-impersonation/).
+3. **Cluster credentials** (legacy multi-cluster) — Argo CD has its own bearer token for each registered cluster. Rotate regularly.
+
+Stress-tests:
+
+- An Application with `spec.destination.namespace: kube-system` plus controller-default identity = sync runs as cluster-admin in kube-system.
+- An AppProject with `destinationServiceAccounts` listing `defaultServiceAccount: 'default'` = effectively no impersonation; the default SA is always present.
+
+### Step 4 — Audit the drift-handling posture
+
+`spec.syncPolicy.automated` controls whether Argo CD reconciles drift. Three flags govern blast radius:
+
+1. **`automated: {}` (auto-sync)** — every Git commit triggers a sync. Production-safe only with `syncWindows` and a tested CI gate.
+2. **`automated.prune: true`** — resources removed from Git are deleted from the cluster. **Critical** without a rollback runbook: a misconfigured commit deletes prod resources.
+3. **`automated.selfHeal: true`** — manual cluster changes are reverted on the next sync. Combined with `prune`, divergence becomes a hard reset to Git state.
+
+Stress-tests:
+
+- `automated.prune: true` on a `StatefulSet` Application = deletion cascades to PVCs (if `persistentVolumeClaimRetentionPolicy.whenDeleted: Delete`). Data loss path.
+- `automated.selfHeal: true` on an Application managing CRDs from a third-party operator = the operator's runtime status updates may be reverted as drift.
+- `automated` with no `syncWindow` covering deploy-freeze periods = a freeze window can be bypassed by a Git commit.
+
+Reference: [Auto-Sync](https://argo-cd.readthedocs.io/en/stable/user-guide/auto_sync/) and [Sync Windows](https://argo-cd.readthedocs.io/en/stable/user-guide/sync_windows/).
+
+### Step 5 — Audit `syncOptions` for stateful or sensitive resources
+
+`spec.syncPolicy.syncOptions` overrides default sync behavior. Flag these as findings:
+
+- **`Replace=true`** — Argo CD deletes the resource and recreates it instead of patching. For `StatefulSet`, `PersistentVolume`, `PersistentVolumeClaim`, `Service` (ClusterIP rotation), `ConfigMap` consumed by hot-reload — this is data loss or downtime.
+- **`Force=true`** — passes `--force` to `kubectl apply`. Disables conflict detection.
+- **`ServerSideApply=false`** when Argo CD's default is server-side apply on newer versions — falls back to client-side three-way merge, which can re-introduce drift loops.
+- **`PruneLast=true`** missing on Applications that delete resources — pruning happens before resource creation, briefly leaving the namespace in an unhealthy state.
+- **`CreateNamespace=true`** with no namespace finalizer or RBAC scope — creates namespaces outside AppProject `destinations`.
+
+### Step 6 — Audit `ApplicationSet` generators
+
+ApplicationSet generators expand into multiple Applications. Risk surface depends on generator type:
+
+- **`list` generator** — explicit list of clusters/parameters. Lowest risk.
+- **`cluster` generator** — generates an Application for every registered cluster matching a label selector. **Critical** when the selector is empty (`{}`) or matches all clusters — a new cluster automatically receives the workload before review.
+- **`git` generator** — generates an Application for every directory or file pattern in a Git repo. Risk: a malicious or accidental commit adds a new directory and triggers a new Application.
+- **`matrix` and `merge` generators** — combine other generators. Risk multiplies.
+- **`pullRequest` generator** — generates Applications for open PRs. Risk: any PR can trigger an ephemeral deployment with the PR's manifests.
+- **`scmProvider` generator** — generates Applications for every repo in an org. Risk: org-wide auto-onboarding.
+
+Reference: [ApplicationSet Generators](https://argo-cd.readthedocs.io/en/stable/operator-manual/applicationset/Generators/) and [Progressive Syncs (RollingSync)](https://argo-cd.readthedocs.io/en/stable/operator-manual/applicationset/Progressive-Syncs/).
+
+Stress-tests:
+
+- ApplicationSet with `cluster` generator + no selector + auto-sync = every cluster auto-onboarded in seconds.
+- ApplicationSet with `pullRequest` generator + no namespace isolation = PRs deploy to shared namespaces.
+- ApplicationSet with `goTemplate: true` and unsanitized template inputs = template injection if PR titles are templated into manifests.
+
+### Step 7 — Audit `argocd-rbac-cm` policy
+
+The Argo CD RBAC ConfigMap (`argocd-rbac-cm`) defines who can do what in the Argo CD UI/CLI/API. Check:
+
+1. The default role (`policy.default`) — `role:readonly` is safe; `role:admin` is wrong.
+2. Specific actions on resources — newer Argo CD versions ship granular actions like `action/apps/Deployment/restart` or `action/argoproj.io/Rollout/abort`. Each granted action should map to a real on-call runbook.
+3. RBAC subject scopes — `g, <group>, role:admin` on broad SSO groups is a finding.
+
+Reference: [Argo CD RBAC](https://argo-cd.readthedocs.io/en/stable/operator-manual/rbac/).
+
+### Step 8 — Multi-cluster (Argo CD Agent) topology
+
+If Argo CD Agent is in use:
+
+- The control plane stores `Application` specs; each spoke runs an agent that pulls assigned Applications.
+- Each agent has its own credentials and authentication path — verify rotation cadence.
+- Network path from spoke to hub must be authenticated and encrypted.
+
+Reference: [argocd-agent](https://github.com/argoproj-labs/argocd-agent).
+
+## Output
+
+Return:
+
+- **target**: `Application`, `AppProject`, `ApplicationSet`, or RBAC ConfigMap, with the project boundary,
+- **evidence level**: `live evidence` / `documentation-based` / `sanitized user evidence` / `inference`,
+- **sync identity**: controller default vs impersonated SA vs cluster credential, with judgment on least privilege,
+- **blast radius**: `sourceRepos`, `destinations`, `clusterResourceWhitelist`, `namespaceResourceBlacklist` audit,
+- **drift posture**: `automated.prune`, `automated.selfHeal`, sync windows, syncOptions concerns,
+- **risk findings** (with severity: high / medium / low) — covering sync identity, blast radius, drift, ApplicationSet generators, RBAC,
+- **safest next actions** with sample manifest changes,
+- **rollback plan**: how to revert auto-sync, disable selfHeal, narrow AppProject scope without breaking running Applications,
+- **assumptions and missing facts**.
+
+## Security notes
+
+- Never recommend `automated.prune: true` + `automated.selfHeal: true` on production Applications without a tested rollback runbook.
+- Never recommend `AppProject` with `sourceRepos: ['*']` and `destinations: ['*']` for application projects. Platform projects may need this; document the justification.
+- Never recommend disabling sync impersonation as a default in production after it has been enabled.
+- Never request or print Argo CD admin tokens, repo SSH keys, or destination cluster bearer tokens.

package/skills/aws/README.md

@@ -1,6 +1,8 @@
 # AWS Skills
 
-<img src="../../assets/logos/cloud/aws/aws-cdnlogo.png" alt="AWS logo" width="140" />
+<p align="center">
+  <img src="../../assets/logos/cloud/aws/aws-cdnlogo.png" alt="AWS logo" width="140" />
+</p>
 
 
 This folder contains AWS-focused skills curated for this marketplace.

package/skills/aws/aws-maestro/references/workflow-and-output.md

@@ -10,6 +10,7 @@ Use this reference when classifying a task or selecting the right specialist(s).
 | `compute` | EC2, ECS, Fargate, EKS, Lambda, serverless, container, pod, fleet, autoscaling, AMI, launch template, capacity reservation, spot, deployment rollout, hotfix |
 | `data` | RDS, Aurora, DynamoDB, S3, database, query performance, data modeling, index, backup, data perimeter, bucket policy, data protection, restore |
 | `security-iam` | IAM, policy, role, permission, SCP, KMS, key rotation, secrets, Secrets Manager, posture, GuardDuty, SecurityHub, compliance, evidence, Bedrock security |
+| `pki` | ACM PCA, AWS Private CA, aws-privateca-issuer, AWSPCAIssuer, AWSPCAClusterIssuer, certificate template ARN, CRL distribution, CRL S3, IRSA cert-manager, cross-account PCA, RAM-shared CA, SubordinateCACertificate, private certificate authority |
 | `cost` | cost, spend, billing, anomaly, savings plan, reserved instance, rightsizing, waste, budget |
 | `devops-cicd` | pipeline, CI/CD, CodePipeline, CodeBuild, GitHub Actions, IaC, CloudFormation, Terraform, CDK, patch, release engineer, deploy, rollback |
 | `operations` | observability, CloudWatch, X-Ray, incident, alert, runbook, triage, ticket, escalation, change impact, briefing, daily ops, non-destructive automation |
@@ -61,6 +62,7 @@ Use this reference when classifying a task or selecting the right specialist(s).
 | `aws-kms-secrets-lifecycle-steward-agent` | security-iam | Managing KMS key lifecycle, rotation policies, or Secrets Manager secret health |
 | `aws-security-posture-hardening-agent` | security-iam | Hardening AWS account posture: GuardDuty, SecurityHub, Config rules, and remediation |
 | `aws-compliance-evidence-mapper-agent` | security-iam | Mapping AWS controls to compliance frameworks (SOC 2, PCI, HIPAA, NIST) and gathering evidence |
+| `aws-private-ca-issuer-review-agent` | pki | Reviewing AWS ACM Private CA issuer config for cert-manager: CA hierarchy, template ARN scope, IRSA permissions, CRL reachability, and cross-account RAM-shared CA |
 
 ### Cost
 

package/skills/aws/aws-private-ca-issuer-review/SKILL.md

@@ -0,0 +1,39 @@
+---
+name: aws-private-ca-issuer-review
+description: Use this skill when reviewing AWS ACM Private CA (Private Certificate Authority) issuer configurations for cert-manager. Trigger on any request to audit AWSPCAIssuer, AWSPCAClusterIssuer, IRSA policy for cert-manager, certificate template ARNs, CRL configuration, or cross-account PCA usage.
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+---
+
+# AWS Private CA Issuer Review
+
+## Purpose
+
+Review AWS ACM Private Certificate Authority configurations used by the cert-manager `aws-privateca-issuer` plugin. Identify CA hierarchy misconfigurations, overly permissive certificate templates, excessive IRSA permissions, unsafe validity periods, CRL reachability gaps, and cross-account PCA setup risks.
+
+## Lean operating rules
+
+- Flag any `AWSPCAIssuer` referencing a ROOT CA ARN directly as CRITICAL — only a SUBORDINATE CA should be active for cert-manager issuance.
+- Check `spec.template.arn`: flag any SubordinateCACertificate template as CRITICAL (allows cert-manager to mint sub-CAs). Correct template is `EndEntityCertificate/V1`.
+- Review IRSA role policy: required actions are `acm-pca:IssueCertificate`, `acm-pca:GetCertificate`, `acm-pca:DescribeCertificateAuthority`. Flag `acm-pca:DeleteCertificateAuthority` or `acm-pca:CreateCertificateAuthority` as HIGH.
+- Review `spec.duration` in Certificate resources; flag durations > 365d for workload certs as MEDIUM; best practice is <= 90d.
+- Check CRL S3 bucket reachability from within the VPC; flag unreachable CRL distribution points as HIGH (revocation disabled).
+- For cross-account PCA (RAM-shared CA): verify minimum issuance-only permissions in the security account.
+- Label all claims as live evidence, documentation-based, or inference.
+
+## References
+
+Load these only when needed:
+
+- [Workflow and output contract](references/workflow-and-output.md)
+- [Safety checklist](references/safety-checklist.md)
+- [Official sources](references/official-sources.md)
+
+## Response minimum
+
+- Severity-labeled findings list (CRITICAL / HIGH / MEDIUM / LOW)
+- Evidence source for each finding
+- Specific resource name or field path
+- Recommended remediation with example policy or YAML snippet
+- Overall PKI trust posture verdict

package/skills/aws/aws-private-ca-issuer-review/metadata.json

@@ -0,0 +1,21 @@
+{
+  "id": "aws-private-ca-issuer-review",
+  "name": "AWS Private CA Issuer Review",
+  "type": "skill",
+  "provider": "aws",
+  "harnesses": ["codex", "claude-code", "cursor", "gemini", "kiro", "other"],
+  "summary": "Review AWS ACM Private Certificate Authority issuer configurations for cert-manager, covering CA hierarchy safety, certificate template ARN scope, IRSA permissions minimization, validity period alignment, CRL reachability, and cross-account PCA usage patterns.",
+  "source_type": "original",
+  "official_docs": [
+    "https://docs.aws.amazon.com/privateca/latest/userguide/PcaWelcome.html",
+    "https://github.com/cert-manager/aws-privateca-issuer",
+    "https://docs.aws.amazon.com/privateca/latest/userguide/UsingTemplates.html",
+    "https://docs.aws.amazon.com/privateca/latest/userguide/crl-planning.html",
+    "https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts.html"
+  ],
+  "security_notes": "Using a Root CA ARN in AWSPCAIssuer exposes the root of trust directly to cert-manager. A SubordinateCACertificate template allows cert-manager to issue intermediate CAs, enabling an attacker with cert-manager IRSA access to create a shadow CA trusted by the entire corporate PKI. IRSA role must exclude acm-pca:DeleteCertificateAuthority and acm-pca:CreateCertificateAuthority.",
+  "last_verified": "2026-05-02",
+  "path": "skills/aws/aws-private-ca-issuer-review",
+  "author": "github: Raishin",
+  "version": "0.1.0"
+}

package/skills/aws/aws-private-ca-issuer-review/references/official-sources.md

@@ -0,0 +1,22 @@
+# Official sources
+
+Use this reference only when you need source grounding for AWS Private CA behavior or the detailed source list.
+
+## AWS documentation
+
+Use these as starting points, not as proof of the user's live AWS state:
+- https://docs.aws.amazon.com/privateca/latest/userguide/
+- https://docs.aws.amazon.com/privateca/latest/userguide/CT-CreateCertificate.html
+- https://docs.aws.amazon.com/privateca/latest/userguide/PcaIssueCert.html
+- https://docs.aws.amazon.com/privateca/latest/userguide/CT-IssueCertificate.html
+- https://docs.aws.amazon.com/privateca/latest/userguide/crl-planning.html
+- https://github.com/cert-manager/aws-privateca-issuer
+
+## cert-manager AWS PCA issuer plugin
+
+- https://cert-manager.io/docs/configuration/issuers/
+- https://github.com/cert-manager/aws-privateca-issuer/blob/main/pkg/api/v1beta1/types.go
+
+## Grounding rule
+
+Official documentation explains AWS service behavior. It does not prove the user's current PCA hierarchy, IRSA trust policy, CRL reachability, RAM share scope, or live cert-manager configuration. Prefer live AWS MCP/CLI evidence or sanitized user-provided YAML for current-state claims.

package/skills/aws/aws-private-ca-issuer-review/references/safety-checklist.md

@@ -0,0 +1,30 @@
+# Safety checklist
+
+Use this reference before any recommendations on cert-manager PKI configuration, IRSA policy changes, CA hierarchy decisions, or CRL distribution point design.
+
+## Non-negotiables
+
+- Never ask users to paste secrets, access keys, private keys, CA passwords, or PKCS#12 bundles into chat.
+- Prefer official AWS MCP tools or sanitized `kubectl get` / `aws acm-pca` CLI output for current-state evidence. Label the evidence level.
+- Do not invent CA ARNs, certificate template ARNs, IRSA role ARNs, or RAM resource share IDs.
+- Require explicit platform-team sign-off before any change that modifies a CA hierarchy, revokes a CA, or deletes a PCA CRL S3 bucket.
+- Keep IRSA permissions scoped to the minimum: `acm-pca:IssueCertificate`, `acm-pca:GetCertificate`, `acm-pca:DescribeCertificateAuthority`.
+
+## PKI attack vector: required awareness
+
+cert-manager with an `AWSPCAClusterIssuer` that has `acm-pca:IssueCertificate` via IRSA can issue certificates for any DNS name trusted by your internal PKI. A compromised cert-manager pod is equivalent to a compromised subordinate CA. Always review:
+- Which namespaces can request from this ClusterIssuer (CertificateRequestPolicy coverage)
+- Whether the CA certificate template allows sub-CA issuance (SubordinateCACertificate templates are CRITICAL)
+- Whether the certificate SAN validation enforces DNS name scope
+
+## Stress checks
+
+- Which workloads trust this CA chain — blast radius of CA compromise?
+- Can cert-manager request certificates for arbitrary SANs without CertificateRequestPolicy guard?
+- Is the CA ROOT or SUBORDINATE? (ROOT issuance is CRITICAL)
+- Is the CRL S3 bucket reachable from all pods that verify TLS using this CA?
+- Is cross-account RAM share scoped to specific organizational units?
+
+## Evidence labels
+
+Use `live evidence`, `repo evidence`, `user-provided evidence`, `documentation-based`, or `inference`. Documentation alone never proves the user's live AWS state.

package/skills/aws/aws-private-ca-issuer-review/references/workflow-and-output.md

@@ -0,0 +1,214 @@
+# Workflow and Output Contract
+
+## Review Workflow
+
+### Step 1 — Identify the issuer resource type
+
+Determine whether the configuration uses `AWSPCAIssuer` (namespace-scoped) or `AWSPCAClusterIssuer` (cluster-scoped):
+
+```bash
+kubectl get awspcaissuer -A
+kubectl get awspcaclusterissuer
+```
+
+Retrieve the issuer spec:
+
+```bash
+kubectl get awspcaissuer <name> -n <namespace> -o yaml
+kubectl get awspcaclusterissuer <name> -o yaml
+```
+
+Key fields to extract:
+- `spec.arn` — the CA ARN (must be a SUBORDINATE CA, not ROOT)
+- `spec.region` — AWS region of the CA
+- `spec.signingAlgorithm` — signing algorithm
+- `spec.template.arn` — certificate template ARN (controls what types of certs can be issued)
+
+### Step 2 — Validate CA ARN type
+
+Use the AWS CLI to confirm the CA type:
+
+```bash
+aws acm-pca describe-certificate-authority \
+  --certificate-authority-arn <arn> \
+  --query 'CertificateAuthority.Type' \
+  --output text
+```
+
+Expected output: `SUBORDINATE`
+
+If output is `ROOT` — this is a CRITICAL finding. cert-manager is directly wired to the root of trust.
+
+Also check CA status:
+```bash
+aws acm-pca describe-certificate-authority \
+  --certificate-authority-arn <arn> \
+  --query 'CertificateAuthority.Status' \
+  --output text
+```
+
+Expected: `ACTIVE`. If `DISABLED` or `DELETED`, the issuer will fail silently until the CA is restored.
+
+### Step 3 — Validate certificate template ARN
+
+The template ARN controls what type of certificate ACM PCA will issue. Common template ARNs:
+
+| Template ARN Suffix | Purpose | Risk |
+|---------------------|---------|------|
+| `EndEntityCertificate/V1` | Standard workload cert | Safe — correct choice |
+| `EndEntityClientAuthCertificate/V1` | Client auth cert | Safe for mTLS |
+| `SubordinateCACertificate_PathLen0/V1` | Subordinate CA cert | CRITICAL — allows sub-CA issuance |
+| `SubordinateCACertificate_PathLen1/V1` | Subordinate CA with chain | CRITICAL |
+| `RootCACertificate/V1` | Root CA cert | CRITICAL |
+
+Full ARN format:
+```
+arn:aws:acm-pca:::template/EndEntityCertificate/V1
+```
+
+If no template is specified in the issuer, PCA defaults to `EndEntityCertificate/V1` — verify this assumption against the actual ACM PCA issuance policy.
+
+### Step 4 — Review IRSA IAM role policy
+
+Retrieve the IAM role attached to the cert-manager ServiceAccount:
+
+```bash
+kubectl get serviceaccount cert-manager -n cert-manager -o jsonpath='{.metadata.annotations.eks\.amazonaws\.com/role-arn}'
+```
+
+Retrieve and review the role policy:
+
+```bash
+aws iam list-role-policies --role-name <role-name>
+aws iam get-role-policy --role-name <role-name> --policy-name <policy-name>
+```
+
+Minimum required IAM policy:
+
+```json
+{
+  "Version": "2012-10-17",
+  "Statement": [
+    {
+      "Effect": "Allow",
+      "Action": [
+        "acm-pca:IssueCertificate",
+        "acm-pca:GetCertificate",
+        "acm-pca:DescribeCertificateAuthority"
+      ],
+      "Resource": "arn:aws:acm-pca:<region>:<account>:certificate-authority/<ca-id>"
+    }
+  ]
+}
+```
+
+**Flag as HIGH if the policy includes any of:**
+- `acm-pca:DeleteCertificateAuthority`
+- `acm-pca:CreateCertificateAuthority`
+- `acm-pca:UpdateCertificateAuthority`
+- `acm-pca:RestoreCertificateAuthority`
+- `acm-pca:*` (wildcard)
+- Resource set to `*` instead of scoped CA ARN
+
+### Step 5 — Review Certificate validity periods
+
+List all cert-manager Certificate resources and their durations:
+
+```bash
+kubectl get certificate -A -o custom-columns=\
+NAMESPACE:.metadata.namespace,\
+NAME:.metadata.name,\
+DURATION:.spec.duration,\
+RENEW_BEFORE:.spec.renewBefore,\
+ISSUER:.spec.issuerRef.name
+```
+
+Validity guidelines:
+- Workload certs: <= 90d (best practice), <= 365d (acceptable)
+- Internal service mesh mTLS: <= 24h (optimal)
+- Long-lived infrastructure certs: <= 2y (acceptable with documented justification)
+
+Note: ACM PCA silently caps certificate validity at the CA's own remaining validity. A cert with `duration: 87600h` (10 years) issued by a CA expiring in 2 years will be capped at 2 years without error. Always verify the CA's own expiration date:
+
+```bash
+aws acm-pca describe-certificate-authority \
+  --certificate-authority-arn <arn> \
+  --query 'CertificateAuthority.NotAfter' \
+  --output text
+```
+
+### Step 6 — Review CRL configuration and reachability
+
+Check the CRL configuration on the CA:
+
+```bash
+aws acm-pca describe-certificate-authority \
+  --certificate-authority-arn <arn> \
+  --query 'CertificateAuthority.RevocationConfiguration'
+```
+
+Verify the CRL S3 bucket name from the output. Then check reachability from within the VPC:
+
+- Does the VPC have an S3 Gateway VPC endpoint for the CRL bucket's region?
+- Is the CRL S3 bucket policy allowing access from the VPC?
+- Is the CRL distribution point URL embedded in issued certs accessible?
+
+```bash
+# Check for S3 gateway VPC endpoint
+aws ec2 describe-vpc-endpoints \
+  --filters "Name=service-name,Values=com.amazonaws.<region>.s3" \
+             "Name=vpc-id,Values=<vpc-id>"
+```
+
+If the CRL S3 bucket requires a VPC endpoint and none exists, revocation checking is effectively disabled (most TLS clients soft-fail on CRL/OCSP unreachability).
+
+### Step 7 — Cross-account PCA review (if applicable)
+
+Identify if the CA ARN belongs to a different AWS account than the EKS cluster:
+
+```bash
+# Extract account ID from CA ARN
+echo "arn:aws:acm-pca:<region>:<account-id>:certificate-authority/<id>"
+# Compare with current account
+aws sts get-caller-identity --query Account --output text
+```
+
+For cross-account configurations:
+
+1. Verify the RAM share exists in the security account:
+```bash
+aws ram list-resources --resource-owner SELF --resource-type acm-pca:CertificateAuthority
+```
+
+2. Verify the workload-account IRSA role trust policy references the correct EKS OIDC provider.
+
+3. Confirm the cross-account IAM permissions follow least-privilege (issuance only, not management).
+
+---
+
+## Output Format
+
+### Finding: `<short title>`
+
+| Field | Value |
+|-------|-------|
+| Severity | CRITICAL / HIGH / MEDIUM / LOW |
+| Resource | AWSPCAIssuer name, CA ARN, IAM role, or cert name |
+| Evidence | documentation-based / live evidence / inference |
+| Description | What is wrong and why it matters for PKI trust |
+| Remediation | IAM policy snippet, ARN change, or configuration fix |
+
+---
+
+### Overall PKI Trust Posture
+
+| Category | Status |
+|----------|--------|
+| CA hierarchy (subordinate only) | PASS / FAIL |
+| Certificate template scope | PASS / FAIL |
+| IRSA permissions (least-privilege) | PASS / FAIL |
+| Certificate validity periods | PASS / FAIL |
+| CRL reachability | PASS / FAIL |
+| Cross-account configuration | PASS / N/A / FAIL |
+
+**Verdict:** TRUSTED / UNTRUSTED / CONDITIONAL (list conditions)