@raishin/vanguard-frontier-agentic 1.2.0 → 1.3.0

package/skills/azure/README.md

@@ -1,6 +1,8 @@
 # Azure skills
 
-![Azure logo](../../assets/logos/cloud/azure/azure.png)
+<p align="center">
+  <img src="../../assets/logos/cloud/azure/azure.png" alt="Azure logo" width="140" />
+</p>
 
 This folder contains Azure-focused skills curated for this marketplace.
 

package/skills/azure/azure-keyvault-certificate-issuer-review/SKILL.md

@@ -0,0 +1,37 @@
+---
+name: azure-keyvault-certificate-issuer-review
+description: Use this skill when reviewing Azure Key Vault certificate issuer configurations for cert-manager on AKS. Trigger on any request to audit Key Vault certificate policies, Managed Identity role assignments, exportability settings, private endpoint connectivity, integrated CA credentials, or rotation policy alignment.
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+---
+
+# Azure Key Vault Certificate Issuer Review
+
+## Purpose
+
+Review Azure Key Vault configurations used as certificate issuers for cert-manager on AKS. Identify Managed Identity role assignment gaps (data plane vs management plane confusion), certificate policy misalignment, exportability risks, network connectivity issues, integrated CA credential over-scoping, and rotation race conditions between cert-manager and Key Vault auto-rotation. Output severity-labeled findings with evidence and remediation steps.
+
+## Lean operating rules
+
+- Check the Managed Identity (or Service Principal) role assignment on the Key Vault: the correct role is `Key Vault Certificate Officer` (data plane). Flag `Key Vault Contributor` as HIGH — it grants management plane access including vault deletion. Flag `Key Vault Administrator` as HIGH (full data plane + management).
+- Verify whether Key Vault RBAC mode is enabled (`enableRbacAuthorization: true`). If legacy access policies are used instead of RBAC, flag as MEDIUM (harder to audit, no Azure AD Conditional Access integration).
+- Review `exportable` in the Key Vault certificate policy. Flag `exportable: true` on certs used for cluster-internal mTLS as MEDIUM (private key unnecessarily extractable from Key Vault).
+- Check Key Vault network access configuration: if `publicNetworkAccess: Disabled`, verify the AKS cluster has private endpoint access to the Key Vault and DNS resolution via private DNS zone. Flag missing private endpoint as MEDIUM.
+- For integrated CAs (DigiCert, GlobalSign): verify the Key Vault has the CA integration configured and the credential secret is scoped to a minimum (single certificate profile, not account-wide).
+- Review cert-manager `renewBefore` against the Key Vault certificate's auto-rotation policy to detect overlapping rotation windows. Flag simultaneous rotation triggers as MEDIUM.
+- 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 or field that caused the finding
+- Recommended remediation with example Azure CLI command or policy snippet
+- Overall Key Vault certificate issuer posture verdict

package/skills/azure/azure-keyvault-certificate-issuer-review/metadata.json

@@ -0,0 +1,20 @@
+{
+  "id": "azure-keyvault-certificate-issuer-review",
+  "name": "Azure Key Vault Certificate Issuer Review",
+  "type": "skill",
+  "provider": "azure",
+  "harnesses": ["codex", "claude-code", "cursor", "gemini", "kiro", "other"],
+  "summary": "Review Azure Key Vault certificate issuer configurations for cert-manager, covering certificate policy alignment, Managed Identity authorization scope, exportability posture, private endpoint connectivity, integrated CA credential scoping, and cert-manager vs Key Vault auto-rotation race conditions.",
+  "source_type": "original",
+  "official_docs": [
+    "https://learn.microsoft.com/en-us/azure/key-vault/certificates/about-certificates",
+    "https://learn.microsoft.com/en-us/azure/key-vault/certificates/certificate-scenarios",
+    "https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles/security",
+    "https://learn.microsoft.com/en-us/azure/key-vault/general/network-security"
+  ],
+  "security_notes": "Key Vault Contributor role assigned to cert-manager allows deletion of the Key Vault, management policy changes, and purge of soft-deleted certs — a full management plane compromise. Use Key Vault Certificate Officer (data plane RBAC) instead. Exportable certificates allow private key extraction from Key Vault; use non-exportable certs for cluster-internal mTLS.",
+  "last_verified": "2026-05-02",
+  "path": "skills/azure/azure-keyvault-certificate-issuer-review",
+  "author": "github: Raishin",
+  "version": "0.1.0"
+}

package/skills/azure/azure-keyvault-certificate-issuer-review/references/workflow-and-output.md

@@ -0,0 +1,190 @@
+# Workflow and Output Contract
+
+## Review Workflow
+
+### Step 1 — Identify the cert-manager issuer configuration
+
+Locate the cert-manager issuer resource that references Azure Key Vault:
+
+```bash
+kubectl get issuer -A -o yaml | grep -A10 "azureKeyVault\|keyVault"
+kubectl get clusterissuer -o yaml | grep -A10 "azureKeyVault\|keyVault"
+```
+
+Extract the Key Vault name and vault URI from the issuer spec. The exact fields depend on the cert-manager Azure issuer plugin in use (e.g., `cert-manager-webhook-azure` or CAPZ-style issuers).
+
+### Step 2 — Check Managed Identity role assignment
+
+Identify the Managed Identity or Service Principal used by cert-manager on AKS:
+
+```bash
+# Get the cert-manager pod's managed identity annotation
+kubectl get pod -n cert-manager -l app=cert-manager -o jsonpath='{.items[0].metadata.annotations}'
+
+# Or check the ServiceAccount for workload identity annotation
+kubectl get serviceaccount cert-manager -n cert-manager -o jsonpath='{.metadata.annotations}'
+```
+
+Retrieve role assignments on the Key Vault:
+
+```bash
+KV_ID=$(az keyvault show --name <vault-name> --query id -o tsv)
+az role assignment list --scope "$KV_ID" --output table
+```
+
+**Correct role:** `Key Vault Certificate Officer` (data plane only)
+
+Role comparison:
+
+| Role | Plane | Grants | Risk |
+|------|-------|--------|------|
+| `Key Vault Certificate Officer` | Data | Create, update, import, delete certificates | Correct |
+| `Key Vault Certificates Officer` | Data | Same as above (alias) | Correct |
+| `Key Vault Contributor` | Management | Manage vault config, delete vault, change policies | HIGH — management plane access |
+| `Key Vault Administrator` | Data + Management | Full control including purge | HIGH |
+| `Owner` / `Contributor` at subscription | All | Everything | CRITICAL |
+
+### Step 3 — Check RBAC mode vs legacy access policies
+
+```bash
+az keyvault show --name <vault-name> --query properties.enableRbacAuthorization
+```
+
+- `true` — RBAC mode (preferred, auditable via Azure RBAC)
+- `false` or `null` — legacy access policies (harder to audit)
+
+If legacy access policies are in use, check the policy:
+
+```bash
+az keyvault show --name <vault-name> --query properties.accessPolicies
+```
+
+The cert-manager identity should only have `certificates: ["get", "create", "import", "update", "list"]` — not `all` and not management operations.
+
+### Step 4 — Review certificate policy and exportability
+
+```bash
+az keyvault certificate get-default-policy
+az keyvault certificate show --vault-name <vault-name> --name <cert-name>
+```
+
+Key fields in the certificate policy:
+
+```json
+{
+  "x509CertificateProperties": {
+    "subject": "CN=myapp.internal",
+    "validityInMonths": 3,
+    "keyUsage": ["digitalSignature", "keyEncipherment"]
+  },
+  "keyProperties": {
+    "exportable": false,
+    "keyType": "RSA",
+    "keySize": 2048,
+    "reuseKey": false
+  },
+  "issuerParameters": {
+    "name": "Self"
+  }
+}
+```
+
+**Flags:**
+- `exportable: true` on a cert used for cluster-internal mTLS — MEDIUM (private key extractable)
+- `keySize < 2048` for RSA or `keySize < 256` for EC — HIGH (weak key)
+- `validityInMonths > 12` for workload certs — MEDIUM (excessive validity)
+
+Note: Non-exportable certs require the application to use Key Vault SDK or CSI driver for key operations, not just cert retrieval. Confirm application capability before enforcing non-exportable.
+
+### Step 5 — Review Key Vault network access
+
+```bash
+az keyvault show --name <vault-name> --query properties.networkAcls
+az keyvault show --name <vault-name> --query properties.publicNetworkAccess
+```
+
+If `publicNetworkAccess: Disabled`:
+
+```bash
+# Check for private endpoint
+az network private-endpoint list \
+  --query "[?privateLinkServiceConnections[?groupIds[0]=='vault']].{name:name,subnet:subnet.id}" \
+  --output table
+
+# Check for private DNS zone
+az network private-dns zone list --query "[?contains(name,'vaultcore')]" --output table
+```
+
+For AKS access to Key Vault:
+- AKS cluster VNet must be peered with or the same as the VNet hosting the private endpoint
+- Private DNS zone `privatelink.vaultcore.azure.net` must be linked to the AKS cluster VNet
+- Outbound traffic from cert-manager pod must route through the private endpoint
+
+**Flags:**
+- Key Vault with public access from internet and no firewall restrictions — MEDIUM
+- Key Vault with `publicNetworkAccess: Disabled` but missing private endpoint — HIGH (cert issuance will fail)
+- No private DNS zone link to AKS VNet (DNS resolution fails for private endpoint) — HIGH
+
+### Step 6 — Review integrated CA configuration (if applicable)
+
+For DigiCert or GlobalSign integrated CAs:
+
+```bash
+az keyvault certificate issuer show --vault-name <vault-name> --issuer-name DigiCert
+```
+
+Check that the issuer credential secret is stored in Key Vault and scoped to a minimum profile:
+
+```bash
+az keyvault secret show --vault-name <vault-name> --name DigiCert-issuer-creds
+```
+
+**Flags:**
+- Integrated CA credentials that have account-wide issuance scope (not single profile) — MEDIUM
+- Integrated CA credentials stored outside Key Vault (e.g., in a Kubernetes Secret) — MEDIUM
+
+### Step 7 — Review rotation race condition
+
+cert-manager rotation schedule:
+```bash
+kubectl get certificate <name> -n <namespace> -o jsonpath='{.spec.duration} {.spec.renewBefore}'
+```
+
+Key Vault auto-rotation policy:
+```bash
+az keyvault certificate get-default-policy | jq '.lifetimeActions'
+```
+
+A `lifetimeAction` of type `AutoRenew` triggers Key Vault to request a new cert from the issuer. If cert-manager's `renewBefore` window overlaps with the Key Vault auto-renewal trigger (both fire within the same rotation window), both may attempt to renew simultaneously, causing a temporary version mismatch.
+
+**Mitigation:** Disable Key Vault auto-rotation for certs managed by cert-manager, or ensure the Key Vault auto-renewal threshold is set beyond the cert-manager `renewBefore` window.
+
+---
+
+## Output Format
+
+### Finding: `<short title>`
+
+| Field | Value |
+|-------|-------|
+| Severity | CRITICAL / HIGH / MEDIUM / LOW |
+| Resource | Key Vault name, role assignment, cert name, or policy field |
+| Evidence | documentation-based / live evidence / inference |
+| Description | What is wrong and its impact |
+| Remediation | Azure CLI command, policy JSON, or configuration change |
+
+---
+
+### Overall Posture
+
+| Category | Status |
+|----------|--------|
+| Managed Identity role (data plane only) | PASS / FAIL |
+| RBAC mode (not legacy policies) | PASS / FAIL |
+| Certificate exportability | PASS / FAIL |
+| Key Vault network access | PASS / FAIL |
+| Certificate validity periods | PASS / FAIL |
+| Integrated CA credential scope | PASS / N/A / FAIL |
+| Rotation policy alignment | PASS / FAIL |
+
+**Verdict:** TRUSTED / UNTRUSTED / CONDITIONAL (list conditions)

package/skills/azure/azure-live-entra-role-assignment-guard/SKILL.md

@@ -0,0 +1,56 @@
+---
+name: azure-live-entra-role-assignment-guard
+description: Guard live permanent Microsoft Entra ID and Azure RBAC role assignments with scope audit, principal-type risk classification, dangerous-role detection, and explicit approval gates before write. Use only when a direct (non-PIM) role assignment is intentionally requested against a confirmed target.
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+---
+
+# Azure Live Entra Role Assignment Guard
+
+## Purpose
+
+Act as the guarded live Azure operator for azure-live-entra-role-assignment-guard work. Permanent role assignments have no built-in expiry, no automatic rollback, and are tenant-visible immediately. Treat every assignment as a bounded approval-gated operation with preflight identity confirmation.
+
+## When to use
+
+Use this skill when:
+
+- a direct (non-PIM) Entra ID or Azure RBAC role assignment must be created against a confirmed principal and scope
+- an existing assignment must be removed and the downstream access impact must be assessed before deletion
+- a role assignment audit finds over-broad, stale, or guest assignments that must be remediated with least-privilege alternatives
+
+## Lean operating rules
+
+- Prefer Azure CLI (`az`) and Microsoft Learn docs when available; fall back to sanitized user evidence.
+- Do not create or delete any role assignment until subscription or tenant, active principal, target scope, role, and assignee identity are all explicit.
+- Prefer read-only inspection (`az role assignment list`, `az ad user show`) before any write.
+- Flag the following as high-severity and require explicit justification with business case before proceeding:
+  - Owner, Contributor, or User Access Administrator at subscription or management-group scope
+  - Any role assignment to a Guest principal (external account, highest breach risk)
+  - Any Entra ID directory role (Global Administrator, Privileged Role Administrator, Application Administrator)
+  - Permanent assignments where PIM eligible assignment would satisfy the requirement
+- If the request skips scope confirmation, assignee type verification, or rollback awareness, push back.
+- Never print access tokens, client secrets, tenant IDs, Object IDs without context, or raw environment dumps. Summarize sanitized evidence only.
+- Load references only when needed.
+
+## References
+
+Load these only when needed:
+
+- [Preflight commands](references/preflight-commands.md) — Azure CLI commands to inspect current assignments, identity, and scope before any write.
+- [Rollback playbook](references/rollback-playbook.md) — how to remove an assignment and verify access is revoked.
+- [Permission model](references/permission-model.md) — least-privilege role alternatives, dangerous role IDs, and PIM vs permanent guidance.
+- [Official sources](references/official-sources.md) — authoritative Microsoft documentation links.
+
+## Response minimum
+
+Return, at minimum:
+
+- confirmed tenant, subscription (if applicable), target scope, and active caller identity
+- preflight evidence: existing assignments on the target scope and current assignee roles
+- principal-type risk classification (member user / guest / service principal / managed identity / group)
+- role risk classification (Owner / Contributor / UAA / custom / narrow built-in)
+- approval status and explicit justification for the assignment
+- rollback posture: the exact `az role assignment delete` command to undo
+- post-assignment verification steps or refusal reason

package/skills/azure/azure-live-entra-role-assignment-guard/metadata.json

@@ -0,0 +1,28 @@
+{
+  "id": "azure-live-entra-role-assignment-guard",
+  "name": "Azure Live Entra Role Assignment Guard",
+  "type": "skill",
+  "provider": "azure",
+  "harnesses": [
+    "codex",
+    "claude-code",
+    "cursor",
+    "gemini",
+    "kiro",
+    "other"
+  ],
+  "summary": "Guard live permanent Microsoft Entra ID and Azure RBAC role assignments with scope audit, principal-type risk classification, dangerous-role detection, and explicit approval gates before write.",
+  "source_type": "original",
+  "official_docs": [
+    "https://learn.microsoft.com/en-us/azure/role-based-access-control/overview",
+    "https://learn.microsoft.com/en-us/azure/role-based-access-control/best-practices",
+    "https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles",
+    "https://learn.microsoft.com/en-us/azure/role-based-access-control/role-assignments-alert",
+    "https://learn.microsoft.com/en-us/entra/id-governance/privileged-identity-management/pim-configure"
+  ],
+  "security_notes": "Never create Owner, Contributor, or User Access Administrator assignments at subscription or management-group scope without explicit CISO-level justification. Always prefer PIM eligible assignment over permanent. Block any assignment to Guest principals without Director-level sign-off. Token caching means deletion may take up to 5 minutes to propagate.",
+  "last_verified": "2026-05-01",
+  "path": "skills/azure/azure-live-entra-role-assignment-guard",
+  "author": "github: Raishin",
+  "version": "0.1.0"
+}

package/skills/azure/azure-live-entra-role-assignment-guard/references/official-sources.md

@@ -0,0 +1,21 @@
+# Official Sources
+
+Load these only when needed:
+
+- [Azure RBAC overview](https://learn.microsoft.com/en-us/azure/role-based-access-control/overview) — use for role assignment model, scope hierarchy (management group → subscription → resource group → resource), and security principal types.
+- [Best practices for Azure RBAC](https://learn.microsoft.com/en-us/azure/role-based-access-control/best-practices) — use for least privilege, group-based assignment, PIM preference, limiting Owner and UAA, and stable role ID usage.
+- [Azure built-in roles](https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles) — use when checking whether a narrow built-in role satisfies the requirement before recommending Contributor or Owner.
+- [Alert on privileged role assignments](https://learn.microsoft.com/en-us/azure/role-based-access-control/role-assignments-alert) — use for the Kusto query pattern to detect Owner / Contributor / UAA assignment events in Activity Log.
+- [Entra ID PIM overview](https://learn.microsoft.com/en-us/entra/id-governance/privileged-identity-management/pim-configure) — use when the permanent assignment request should instead use PIM eligible assignment with JIT activation.
+- [az role assignment CLI reference](https://learn.microsoft.com/en-us/cli/azure/role/assignment) — use for exact `az role assignment create`, `list`, `delete` syntax and parameter options.
+- [Understand role assignments](https://learn.microsoft.com/en-us/azure/role-based-access-control/role-assignments) — use for role assignment object structure (name, roleDefinitionId, principalId, principalType, scope, condition).
+
+## Grounded insights worth carrying into the skill
+
+- The Azure RBAC API version for role assignments is `2022-04-01` (`Microsoft.Authorization/roleAssignments`).
+- Dangerous role definition IDs (stable — never rename): Owner `8e3af657-a8ff-443c-a75c-2fe8c4bcb635`, Contributor `b24988ac-6180-42a0-ab88-20f7382dd24c`, User Access Administrator `18d7d88d-d35e-4fb5-a5c3-7773c20a72d9`.
+- A permanent role assignment at subscription scope granted to a Guest user is one of the most common post-breach persistence techniques in Azure tenants — always block without explicit CISO-level sign-off.
+- Azure AD token caching means a deleted assignment may still be honored for up to 5 minutes after deletion; do not declare rollback complete immediately.
+- `Microsoft.Authorization/roleAssignments/write` at subscription scope is the permission that enables all downstream privilege escalation — any principal with it can assign themselves Owner.
+- Prefer `az role assignment list --include-inherited` to find assignments at parent scopes that affect the target resource.
+- Microsoft recommends group-based role assignment over direct user assignment to simplify access reviews and offboarding.

package/skills/azure/azure-live-entra-role-assignment-guard/references/permission-model.md

@@ -0,0 +1,70 @@
+# Permission Model: Azure Live Entra Role Assignment Guard
+
+## Risk classification by role
+
+| Role | Risk | Reason |
+|---|---|---|
+| Owner | Critical | Full resource control + can reassign access |
+| User Access Administrator | Critical | Can assign any role to any principal at scope |
+| Contributor | High | Full resource read/write, no access management |
+| Global Administrator | Critical | Tenant-wide Entra ID control, bypasses RBAC |
+| Privileged Role Administrator | Critical | Can assign Entra directory roles including Global Admin |
+| Application Administrator | High | Can create service principals and grant Graph API permissions |
+| Custom roles with `*/write` | High | Broad mutation rights — review assignable scopes |
+| Reader | Low | Read-only — acceptable for most principals |
+| Narrow built-in roles | Low | e.g. Storage Blob Data Reader, Key Vault Secrets User |
+
+## Risk classification by scope
+
+| Scope | Risk |
+|---|---|
+| Management group | Critical — affects all child subscriptions and resource groups |
+| Subscription | High — affects all resources in the subscription |
+| Resource group | Medium — contained to group members |
+| Individual resource | Low — minimal blast radius |
+
+## Risk classification by principal type
+
+| Principal type | Risk | Notes |
+|---|---|---|
+| Guest user (`userType: Guest`) | Critical | External identity, not governed by corporate IdP; highest breach risk |
+| Member user | Medium | Internal — verify employment status and team ownership |
+| Service principal (application) | High | Non-human identity; verify application ownership and client secret rotation policy |
+| Managed identity (system-assigned) | Low-Medium | Scoped to a resource lifecycle; verify the resource owner |
+| Managed identity (user-assigned) | Medium | Shared across resources; verify all attached resources |
+| Group | Medium | Verify group membership is actively governed; avoid open groups |
+
+## Least-privilege guidance
+
+1. **Prefer PIM eligible assignments over permanent.** If the role is needed periodically, PIM with time-bounded activation + MFA + justification is always the correct approach.
+2. **Prefer narrow built-in roles over Contributor/Owner.** Azure has 200+ built-in roles; check whether a service-specific role (e.g. `Monitoring Contributor`, `Key Vault Secrets Officer`) satisfies the requirement.
+3. **Prefer resource-group scope over subscription scope.** Subscription scope is justified only for infrastructure, platform, or governance roles.
+4. **Prefer group-based assignment over direct user assignment.** Groups enable consistent access reviews and offboarding.
+
+## Minimum caller permissions for role assignment operations
+
+```json
+{
+  "Name": "Role Assignment Operator (Guarded)",
+  "IsCustom": true,
+  "Description": "Read role assignments and create new ones at resource-group or lower scope only.",
+  "Actions": [
+    "Microsoft.Authorization/roleAssignments/read",
+    "Microsoft.Authorization/roleAssignments/write",
+    "Microsoft.Authorization/roleAssignments/delete",
+    "Microsoft.Authorization/roleDefinitions/read"
+  ],
+  "AssignableScopes": [
+    "/subscriptions/<SUBSCRIPTION_ID>"
+  ]
+}
+```
+
+Restrict `AssignableScopes` to resource-group scope for operators who should not assign at subscription level.
+
+## Dangerous combinations — always block
+
+- Owner at management-group scope assigned to a Guest principal
+- User Access Administrator at subscription scope (allows re-elevating to Owner)
+- Any Entra directory role (Global Admin, Privileged Role Admin) assigned outside of PIM
+- Service principal with Owner and no owner/contact defined in application registration

package/skills/azure/azure-live-entra-role-assignment-guard/references/preflight-commands.md

@@ -0,0 +1,69 @@
+# Preflight Commands: Azure Live Entra Role Assignment Guard
+
+Run all of these before creating or deleting any role assignment.
+
+## 1. Confirm caller identity and active subscription
+
+```bash
+az account show --query "{subscription:id, name:name, tenantId:tenantId, caller:user.name}"
+az ad signed-in-user show --query "{displayName:displayName, id:id, userPrincipalName:userPrincipalName}"
+```
+
+## 2. Inspect existing role assignments on the target scope
+
+```bash
+# Subscription scope
+az role assignment list \
+  --scope "/subscriptions/<SUBSCRIPTION_ID>" \
+  --include-inherited \
+  --query "[].{role:roleDefinitionName, principal:principalName, principalType:principalType, scope:scope}"
+
+# Management group scope
+az role assignment list \
+  --scope "/providers/Microsoft.Management/managementGroups/<MG_ID>" \
+  --include-inherited \
+  --query "[].{role:roleDefinitionName, principal:principalName, principalType:principalType, scope:scope}"
+
+# Resource group scope
+az role assignment list \
+  --resource-group <RESOURCE_GROUP> \
+  --include-inherited \
+  --query "[].{role:roleDefinitionName, principal:principalName, principalType:principalType, scope:scope}"
+```
+
+## 3. Verify the assignee identity and principal type
+
+```bash
+# For a user
+az ad user show --id <UPN_OR_OBJECT_ID> \
+  --query "{displayName:displayName, userPrincipalName:userPrincipalName, userType:userType, accountEnabled:accountEnabled}"
+
+# userType: "Guest" = external account, elevated risk. Always flag.
+
+# For a service principal
+az ad sp show --id <APP_ID_OR_OBJECT_ID> \
+  --query "{displayName:displayName, appId:appId, servicePrincipalType:servicePrincipalType}"
+
+# For a managed identity
+az identity show --name <IDENTITY_NAME> --resource-group <RG> \
+  --query "{name:name, principalId:principalId, tenantId:tenantId}"
+```
+
+## 4. Check for existing dangerous standing assignments (audit)
+
+```bash
+# Find Owner and UAA at subscription scope (Kusto alternative via activity log)
+az role assignment list \
+  --scope "/subscriptions/<SUBSCRIPTION_ID>" \
+  --query "[?roleDefinitionName=='Owner' || roleDefinitionName=='User Access Administrator'].{role:roleDefinitionName, principal:principalName, principalType:principalType}"
+```
+
+## 5. Check whether a PIM eligible assignment already exists (prefer PIM over permanent)
+
+```bash
+az role eligibility-schedule list \
+  --scope "/subscriptions/<SUBSCRIPTION_ID>" \
+  --query "[?principalId=='<PRINCIPAL_OBJECT_ID>'].{role:roleDefinitionDisplayName, endDateTime:endDateTime, status:status}"
+```
+
+If an eligible assignment already exists, the correct action is PIM activation, not a new permanent assignment.

package/skills/azure/azure-live-entra-role-assignment-guard/references/rollback-playbook.md

@@ -0,0 +1,51 @@
+# Rollback Playbook: Azure Live Entra Role Assignment Guard
+
+Permanent role assignments do not expire automatically. Rollback means explicit deletion. Always capture the assignment details before write so deletion is unambiguous.
+
+## Before any assignment write — capture the full assignment for rollback
+
+```bash
+# Save the exact object ID, role definition ID, and scope
+az role assignment list \
+  --assignee <PRINCIPAL_OBJECT_ID_OR_UPN> \
+  --scope <SCOPE> \
+  --query "[].{name:name, roleDefinitionId:roleDefinitionId, principalId:principalId, scope:scope}"
+```
+
+## Remove a role assignment by name (most precise)
+
+```bash
+az role assignment delete \
+  --ids /subscriptions/<SUBSCRIPTION_ID>/providers/Microsoft.Authorization/roleAssignments/<ASSIGNMENT_NAME>
+```
+
+## Remove by role + assignee + scope (if name not captured)
+
+```bash
+az role assignment delete \
+  --assignee <PRINCIPAL_OBJECT_ID_OR_UPN> \
+  --role "<ROLE_NAME_OR_ID>" \
+  --scope <SCOPE>
+```
+
+## Verify deletion took effect
+
+```bash
+az role assignment list \
+  --assignee <PRINCIPAL_OBJECT_ID_OR_UPN> \
+  --scope <SCOPE> \
+  --query "[].{role:roleDefinitionName, scope:scope}"
+# Should return empty or not include the deleted assignment
+```
+
+## Caveats
+
+- Token caching: deleted assignments may still appear valid for up to 5 minutes due to Azure AD token caching. Wait before declaring rollback complete.
+- Inherited assignments: if the assignment was at a parent scope (subscription or management group), removing it at the child scope is not possible — you must delete from the parent scope where it was created.
+- Guest accounts: if the principal is a guest and the assignment was their only entitlement, removal may trigger MFA re-enrollment on next access. Communicate with the affected user.
+- Audit log: the deletion will appear in Azure Activity Log under `Microsoft.Authorization/roleAssignments/delete`. Retain the activity log entry as evidence.
+
+## What cannot be rolled back automatically
+
+- Access exercised during the window the assignment was active (data accessed, operations performed) cannot be undone via role removal.
+- Any resources created or deleted by the principal during the assignment window must be remediated separately.

package/skills/backstage/backstage-scaffolder-template-review/SKILL.md

@@ -0,0 +1,39 @@
+---
+name: backstage-scaffolder-template-review
+description: Use this skill when reviewing Backstage Scaffolder software templates. Trigger when the user asks whether a template is safe for developer self-service, whether template RBAC gates are in place, whether input parameters are validated, whether a step action has excessive blast radius, or whether template outputs expose secrets.
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+---
+
+# Backstage Scaffolder Template Review
+
+## Purpose
+
+Review Backstage Scaffolder `Template` kind resources for action blast-radius, input parameter injection risk, RBAC permission gate coverage, integration secret scope, catalog entity poisoning via `catalog:register`, and plaintext secret exposure in `output:` stanzas. Backstage Scaffolder gives developers a curated UI to trigger powerful backend actions — without RBAC gates and input validation, every authenticated developer effectively has write access to whatever the Scaffolder integration credentials can reach.
+
+## Lean operating rules
+
+- Prefer user-provided sanitized Template YAML as primary evidence; official Backstage docs are the authoritative fallback.
+- Treat any `steps:` action that provisions real cloud infrastructure (Terraform, Crossplane CRD apply, CloudFormation deploy, `kubectl apply`) with no RBAC permission gate as a CRITICAL finding.
+- Treat input parameters flowing unsanitized into `publish:github.repoUrl`, file-path actions, or shell-exec actions as a HIGH finding — path traversal and injection are realistic.
+- Treat `publish:github` with `visibility: public` as the default or without an `allowedHosts` constraint as a HIGH finding.
+- Treat `output:` stanzas exposing plaintext generated credentials, connection strings, or API keys in the Backstage UI as a HIGH finding.
+- Treat the absence of `@backstage/plugin-permission-backend` policies for infrastructure-provisioning templates as a HIGH finding — any authenticated Backstage user can trigger them.
+- Treat `catalog:register` accepting arbitrary user-supplied YAML without server-side entity schema validation as a MEDIUM finding — catalog poisoning overwrites ownership and lifecycle metadata.
+- Keep the answer scoped: report what was reviewed, the evidence level, and exactly which steps or fields triggered each finding.
+
+## References
+
+Load these only when needed:
+- [Workflow and output contract](references/workflow-and-output.md)
+
+## Response minimum
+
+- Scoped target (Template `metadata.name`) and evidence level
+- Each `steps:` action type and its provisioning blast radius
+- Input parameter validation gaps (missing `maxLength`, `pattern`, `enum`)
+- RBAC permission gate verdict (present / absent / partial)
+- Integration secret scope assessment
+- `output:` stanza exposure assessment
+- Safe next actions and open questions

package/skills/backstage/backstage-scaffolder-template-review/metadata.json

@@ -0,0 +1,21 @@
+{
+  "id": "backstage-scaffolder-template-review",
+  "name": "Backstage Scaffolder Template Review",
+  "type": "skill",
+  "provider": "backstage",
+  "harnesses": ["codex", "claude-code", "cursor", "gemini", "kiro", "other"],
+  "summary": "Review Backstage Scaffolder software templates for action blast-radius, input parameter injection, RBAC gate coverage, secret scope, catalog entity poisoning, and output exposure.",
+  "source_type": "original",
+  "official_docs": [
+    "https://backstage.io/docs/features/software-templates/",
+    "https://backstage.io/docs/features/software-templates/writing-templates",
+    "https://backstage.io/docs/features/software-templates/builtin-actions",
+    "https://backstage.io/docs/permissions/overview",
+    "https://backstage.io/docs/integrations/github/github-apps"
+  ],
+  "security_notes": "Backstage Scaffolder templates without RBAC gate and without input validation allow any developer to trigger infrastructure provisioning actions. Templates that provision cloud resources via Terraform or Crossplane CRDs effectively grant cloud-write to all Backstage users.",
+  "last_verified": "2026-05-02",
+  "path": "skills/backstage/backstage-scaffolder-template-review",
+  "author": "github: Raishin",
+  "version": "0.1.0"
+}