@raishin/vanguard-frontier-agentic 1.1.0 → 1.3.0

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)

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-aks-rollout-guard/SKILL.md

@@ -0,0 +1,49 @@
+---
+name: azure-live-aks-rollout-guard
+description: Guard live AKS deployment rollouts with PDB audit, maxUnavailable/surge validation, rollout pause/undo gates, and post-rollout health verification.
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+---
+
+# Azure Live AKS Rollout Guard
+
+## Purpose
+
+Act as the guarded live Azure operator for azure-live-aks-rollout-guard work. Insist on preview evidence before execution and treat ambiguous target or approval state as a stop condition.
+
+## When to use
+
+Use this skill when:
+
+- a Kubernetes deployment rollout must proceed against a live AKS cluster
+- a rollout is paused mid-flight and an operator must decide to resume or undo
+- PDB violations or replica health issues are blocking a rollout and resolution is needed
+
+## Lean operating rules
+
+- Prefer Azure CLI (`az`) official documentation when available; fall back to Microsoft Learn docs and sanitized user evidence.
+- Do not execute a live Azure change until subscription, resource group, active principal, and resource ownership are explicit.
+- Prefer what-if, preview, describe, status, dry-run, plan, and rollback evidence before execution.
+- If the request skips preview or rollback design, push back.
+- Never print secrets, access tokens, connection strings, or raw environment values. Summarize sanitized evidence only.
+- Load references only when needed.
+
+## References
+
+Load these only when needed:
+
+- [Preflight commands](references/preflight-commands.md) — CLI commands to run before any mutation.
+- [Rollback playbook](references/rollback-playbook.md) — concrete rollback steps for this service.
+- [Permission model](references/permission-model.md) — RBAC role definitions and PIM guidance.
+- [Official sources](references/official-sources.md) — authoritative Azure documentation links.
+
+## Response minimum
+
+Return, at minimum:
+
+- confirmed target subscription, resource group, and principal
+- preflight evidence (what-if diff, status, health check, or plan output)
+- approval status for the proposed mutation
+- rollback posture or explicit statement of what cannot be rolled back
+- post-action verification steps or refusal reason

package/skills/azure/azure-live-aks-rollout-guard/metadata.json

@@ -0,0 +1,27 @@
+{
+  "id": "azure-live-aks-rollout-guard",
+  "name": "Azure Live AKS Rollout Guard",
+  "type": "skill",
+  "provider": "azure",
+  "harnesses": [
+    "codex",
+    "claude-code",
+    "cursor",
+    "gemini",
+    "kiro",
+    "other"
+  ],
+  "summary": "Guard live AKS deployment rollouts with PDB audit, maxUnavailable/surge validation, rollout pause/undo gates, and post-rollout health verification.",
+  "source_type": "original",
+  "official_docs": [
+    "https://learn.microsoft.com/en-us/azure/aks/operator-best-practices-cluster-security",
+    "https://learn.microsoft.com/en-us/azure/aks/concepts-clusters-workloads",
+    "https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#rolling-update-deployment",
+    "https://kubernetes.io/docs/tasks/run-application/configure-pdb/"
+  ],
+  "security_notes": "Never advance an AKS rollout without PDB audit and replica health check. kubectl rollout undo is safe but must be confirmed before execution to avoid double-rollback churn.",
+  "last_verified": "2026-04-30",
+  "path": "skills/azure/azure-live-aks-rollout-guard",
+  "author": "github: Raishin",
+  "version": "0.1.0"
+}

package/skills/azure/azure-live-aks-rollout-guard/references/official-sources.md

@@ -0,0 +1,19 @@
+# Official Sources: Azure Live AKS Rollout Guard
+
+## Azure AKS
+
+- https://learn.microsoft.com/en-us/azure/aks/operator-best-practices-cluster-security
+- https://learn.microsoft.com/en-us/azure/aks/concepts-clusters-workloads
+- https://learn.microsoft.com/en-us/azure/aks/manage-azure-rbac
+- https://learn.microsoft.com/en-us/azure/aks/use-azure-ad
+
+## Kubernetes rolling updates and rollback
+
+- https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#rolling-update-deployment
+- https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#rolling-back-a-deployment
+- https://kubernetes.io/docs/tasks/run-application/configure-pdb/
+
+## Source-grounding rule
+
+Use official Microsoft Learn and Kubernetes.io documentation as source of truth.
+Do not override official guidance with secondary examples or training data assumptions.

package/skills/azure/azure-live-aks-rollout-guard/references/permission-model.md

@@ -0,0 +1,54 @@
+# Permission Model: Azure Live AKS Rollout Guard
+
+## Azure RBAC (control plane — cluster credential access)
+
+```json
+{
+  "Name": "AKS Rollout Guard",
+  "IsCustom": true,
+  "Description": "Read AKS cluster state and fetch user-level kubeconfig. No cluster admin rights.",
+  "Actions": [
+    "Microsoft.ContainerService/managedClusters/read",
+    "Microsoft.ContainerService/managedClusters/listClusterUserCredential/action"
+  ],
+  "NotActions": [
+    "Microsoft.ContainerService/managedClusters/delete",
+    "Microsoft.ContainerService/managedClusters/agentPools/write"
+  ],
+  "AssignableScopes": [
+    "/subscriptions/<SUBSCRIPTION_ID>/resourceGroups/<TARGET_RG>/providers/Microsoft.ContainerService/managedClusters/<CLUSTER_NAME>"
+  ]
+}
+```
+
+`listClusterUserCredential` grants a user-level kubeconfig. What the user can do inside
+the cluster is governed by AKS-integrated Entra ID RBAC, not this control-plane role.
+
+## Kubernetes RBAC (data plane — in-cluster namespace scope)
+
+Bind the operator's Entra ID identity to a namespace-scoped Role (never ClusterRole):
+
+```yaml
+apiVersion: rbac.authorization.k8s.io/v1
+kind: Role
+metadata:
+  name: rollout-guard
+  namespace: <TARGET_NAMESPACE>
+rules:
+- apiGroups: ["apps"]
+  resources: ["deployments", "replicasets"]
+  verbs: ["get", "list", "watch", "patch", "update"]
+- apiGroups: [""]
+  resources: ["pods", "pods/log"]
+  verbs: ["get", "list", "watch"]
+- apiGroups: ["policy"]
+  resources: ["poddisruptionbudgets"]
+  verbs: ["get", "list"]
+```
+
+## Do not assign
+
+- `Azure Kubernetes Service Cluster Admin Role` — full cluster admin kubeconfig
+- `cluster-admin` ClusterRoleBinding in Kubernetes
+- `Microsoft.ContainerService/managedClusters/agentPools/delete`
+- Subscription-level Contributor for routine rollout operations

package/skills/azure/azure-live-aks-rollout-guard/references/preflight-commands.md

@@ -0,0 +1,55 @@
+# Preflight Commands: Azure Live AKS Rollout Guard
+
+Run these commands before any AKS rollout mutation. Paste sanitized output as evidence.
+
+## 1. Confirm identity and cluster target
+
+```bash
+az account show --query "{subscription:id, name:name, user:user.name}"
+az aks show -g <RESOURCE_GROUP> -n <CLUSTER_NAME> \
+  --query "{provisioningState:provisioningState, kubernetesVersion:kubernetesVersion, fqdn:fqdn}"
+```
+
+## 2. Fetch user-level kubeconfig
+
+```bash
+az aks get-credentials -g <RESOURCE_GROUP> -n <CLUSTER_NAME> --overwrite-existing
+kubectl config current-context
+```
+
+## 3. Audit PodDisruptionBudgets in target namespace
+
+```bash
+kubectl get pdb -n <NAMESPACE> -o wide
+# minAvailable or maxUnavailable must leave at least one pod available during rollout
+```
+
+## 4. Check current deployment rollout status
+
+```bash
+kubectl rollout status deployment/<DEPLOYMENT_NAME> -n <NAMESPACE>
+kubectl get deployment <DEPLOYMENT_NAME> -n <NAMESPACE> -o jsonpath='{.spec.strategy}'
+```
+
+## 5. Verify node readiness and resource headroom
+
+```bash
+kubectl get nodes -o wide
+kubectl top nodes
+kubectl get pods -n <NAMESPACE> -o wide
+```
+
+## 6. Confirm maxSurge / maxUnavailable strategy
+
+```bash
+kubectl get deployment <DEPLOYMENT_NAME> -n <NAMESPACE> \
+  -o jsonpath='{.spec.strategy.rollingUpdate}'
+# maxUnavailable=0 is safest for production; maxSurge=1 is a conservative default
+```
+
+## 7. Check HorizontalPodAutoscaler (if present)
+
+```bash
+kubectl get hpa -n <NAMESPACE>
+# HPA minReplicas must exceed PDB minAvailable or the rollout will deadlock
+```