Skip to content
Report library
Purpose / Data analysis

Azure Kubernetes Skill Security Audit

What the author says it does (original text)

Plan, create, and configure production-ready Azure Kubernetes Service (AKS) clusters. Covers Day-0 checklist, SKU selection (Automatic vs Standard), networking options (private API server, Azure CNI Overlay, egress configuration), security, and operations (autoscaling, upgrade strategy, cost analysis). WHEN: create AKS environment, provision AKS, enable AKS observability, design AKS networking, ch

Independent security check

Do not install or run it yet

Files checked
53
Risks found
9
Could it run dangerous commands?Looks for programs run straight after downloading, remote control of your computer, and hidden commands.Risks found: 6
High risk

Gateway API resources are installed directly from a mutable latest URL

Source references: 1
What we found

When Gateway API CRDs are missing, the workflow tells `kubectl` to apply remote YAML from GitHub's `releases/latest` path. It pins neither a release, commit, nor content digest and does not require review of the downloaded document.

Why this matters

If upstream content changes or its distribution chain is compromised, an identity with sufficient cluster privileges would install unreviewed resources. CRDs are cluster-scoped configuration and can affect multiple namespaces and future resource handling.

This is an active deployment instruction: when the CRDs are missing, content from GitHub's mutable “latest” URL is passed directly to kubectl apply. No release version or digest is pinned, so the same workflow may install different cluster resources later. Users can require a reviewed, version-pinned release and digest, with download inspection and server-side dry-run before application.

azure-kubernetes-app-deploy/phases/quick-deploy.md:159In the instructionsOpen original file
### Verify Gateway API CRDs (only if Istio Gateway API detected)```bashkubectl get crd gateways.gateway.networking.k8s.io httproutes.gateway.networking.k8s.io 2>/dev/null```If missing: `kubectl apply -f https://github.com/kubernetes-sigs/gateway-api/releases/latest/download/standard-install.yaml`
High risk

Mutable GitHub Action tags execute in a job with Azure OIDC access

Source references: 3
What we found

The CI template uses mutable major-version tags such as `azure/login@v2` and `azure/aks-set-context@v4`. The job has `id-token: write`, then logs into Azure and acquires AKS context. A major tag can point to new code without a workflow-file change.

Why this matters

If an upstream Action or its release tag is compromised, or a future release becomes malicious, that code could execute in the CI identity's context and potentially use its OIDC token and Azure permissions against the registry or cluster.

The job has id-token: write, then uses azure/login to acquire Azure identity and sets an AKS context. These third-party Actions are pinned only to movable major tags (@v2/@v4), not commit hashes. If an upstream tag changes or its publisher is compromised, new code could run inside a cloud-authorized job. Users can require every Action to be pinned to a reviewed full commit SHA and give the OIDC identity minimal Azure permissions.

azure-kubernetes-app-deploy/templates/github-actions/deploy.yml:32In the instructionsOpen original file
# OIDC federation requires these permissions so GitHub can issue# an ID token that Microsoft Entra ID will accept.permissions:  id-token: write   # Required for requesting the JWT  contents: read     # Required for actions/checkout
Show 2 other places
azure-kubernetes-app-deploy/templates/github-actions/deploy.yml:124In the instructionsOpen original file
      # -----------------------------------------------------------      - name: Azure Login (OIDC)        uses: azure/login@v2        with:          client-id: ${{ secrets.AZURE_CLIENT_ID }}          tenant-id: ${{ secrets.AZURE_TENANT_ID }}          subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}
azure-kubernetes-app-deploy/templates/github-actions/deploy.yml:145In the instructionsOpen original file
      - name: Set AKS context        uses: azure/aks-set-context@v4        with:          resource-group: ${{ env.RESOURCE_GROUP }}          cluster-name: ${{ env.AKS_CLUSTER }}
Medium risk

Every main-branch code push changes the cluster without an environment approval gate

Source references: 3
What we found

The template triggers on pushes to main, then directly builds an image, creates or applies a namespace, and applies all manifests under `k8s/`. The visible configuration has no GitHub Environment, required approval, or pre-deployment server-side dry run.

Why this matters

A mistaken or compromised change merged to main can immediately reach the authorized AKS cluster. Manifest changes affecting permissions, replacement behavior, or resource sizing could cause outages or expand workload access.

The template triggers on application-code pushes to main, remotely builds and pushes an image, then creates/applies the namespace and manifests and waits for rollout. No environment approval gate is visible, so once enabled, merging to main can directly change the target cluster; impact grows if the OIDC identity is broad. Users can require a protected GitHub Environment, manual approval, server-side dry-run, and stricter production triggers such as reviewed release tags.

azure-kubernetes-app-deploy/templates/github-actions/deploy.yml:18In the instructionsOpen original file
on:  # Trigger on push to main branch (app code changes only)  push:    branches:      - main    paths-ignore:      - 'docs/**'      - '*.md'      - '.github/**'      - '.vscode/**'  # Allow manual trigger from the Actions tab  workflow_dispatch:
Show 2 other places
azure-kubernetes-app-deploy/templates/github-actions/deploy.yml:171In the instructionsOpen original file
      - name: Deploy to AKS        id: deploy        run: |          # Ensure the namespace exists before applying manifests          kubectl create namespace ${{ env.NAMESPACE }} --dry-run=client -o yaml \            | kubectl apply -f -          kubectl apply -f k8s/ --namespace ${{ env.NAMESPACE }}          kubectl rollout status deployment/${{ env.APP_NAME }} \            --namespace ${{ env.NAMESPACE }} \            --timeout=300s
azure-kubernetes-app-deploy/templates/github-actions/deploy.yml:138In the instructionsOpen original file
      # -----------------------------------------------------------      - name: Build and push image to ACR        run: |          az acr build \            --registry ${{ env.ACR_NAME }} \            --image ${{ env.APP_NAME }}:${{ github.sha }} \            .
Medium risk

Base-image policy intentionally uses mutable tags, preventing reproducible builds

Source references: 4
What we found

The base-image rules explicitly prohibit minor/patch pinning and retain floating major or major.minor tags. Dockerfiles then build directly from those tags without a digest. Identical source can therefore retrieve different files and executables at different times.

Why this matters

Routine upstream changes may enter production images without application-specific testing. If a registry or tag is compromised, later builds could also execute or package malicious content. A major tag alone cannot prove which exact base image was deployed.

The policy intentionally forbids minor/patch pins and requires floating major or major.minor tags; the Dockerfile templates consume those tags without digests. When a registry publisher rebuilds or moves a tag, identical source can receive different base layers, reducing reproducibility and admitting changes not reviewed in this repository. Automatic security patching is the stated benefit, but does not remove supply-chain risk. Users can require production builds to pin digests and refresh them through a controlled update process.

azure-kubernetes-app-deploy/references/base-images.md:7In the instructionsOpen original file
## Rules1. **Never pin minor/patch.** Use a floating **major** (or major.minor) tag.   Floating tags receive security patches automatically — a frozen patch tag   does not.2. **Resolve `<LATEST_STABLE_*>` at generation time.** When generating a   Dockerfile, replace each placeholder with the current stable major the   project targets (see "Resolution" below), then keep that major tag in the   output. A major tag is concrete, so it satisfies Deployment Safeguard DS009   (no `:latest`).3. **Prefer the Microsoft/Azure Linux image when one exists and the project
Show 3 other places
azure-kubernetes-app-deploy/templates/dockerfiles/node.Dockerfile:21In the instructionsOpen original file
# ---------------------------------------------------------------------------# Base: current Node LTS, Alpine variant. See references/base-images.md.FROM node:<LATEST_STABLE_NODE>-alpine AS build
azure-kubernetes-app-deploy/templates/dockerfiles/node.Dockerfile:46In the instructionsOpen original file
# ---------------------------------------------------------------------------FROM node:<LATEST_STABLE_NODE>-alpine# Security: install dumb-init so Node runs as PID > 1 and signals propagate# correctly — avoids zombie processes inside the container.RUN apk add --no-cache dumb-init
azure-kubernetes-app-deploy/references/base-images.md:9In the instructionsOpen original file
1. **Never pin minor/patch.** Use a floating **major** (or major.minor) tag.   Floating tags receive security patches automatically — a frozen patch tag   does not.2. **Resolve `<LATEST_STABLE_*>` at generation time.** When generating a   Dockerfile, replace each placeholder with the current stable major the   project targets (see "Resolution" below), then keep that major tag in the   output. A major tag is concrete, so it satisfies Deployment Safeguard DS009   (no `:latest`).3. **Prefer the Microsoft/Azure Linux image when one exists and the project
Medium risk

A guessed /health probe is deployed when no health endpoint is detected

Source references: 4
What we found

The detection flow defaults to `/health` when no endpoint is found. The generated Deployment uses that path for HTTP liveness/readiness probes and is later applied without requiring proof that the application serves the route.

Why this matters

If `/health` does not exist or requires authentication, readiness removes the pods from service and liveness repeatedly restarts otherwise functional containers, making the deployment unavailable.

The detection rule explicitly defaults to /health when no endpoint is found. The generated template uses the selected paths for liveness and readiness probes, and the deployment stage applies all manifests. If the application does not serve that route, probes can keep failing, leaving pods unready or repeatedly restarting them. Users can require endpoint verification before deployment, confirm or implement the correct route, and test with server-side dry-run and a staging namespace.

azure-kubernetes-app-deploy/phases/quick-deploy.md:13In the instructionsOpen original file
### Port and Health Endpoint DetectionFollow the port and health endpoint detection tables in `references/detection.md` (first match wins). If none found, use `/health` as default in probes.
Show 3 other places
azure-kubernetes-app-deploy/templates/k8s/deployment.yaml:64In the instructionsOpen original file
          # DS002: Liveness probe          livenessProbe:            httpGet:              path: <health-path>              port: <port>            initialDelaySeconds: 10            periodSeconds: 15            timeoutSeconds: 3            failureThreshold: 3          # DS003: Readiness probe          readinessProbe:            httpGet:              path: <ready-path>              port: <port>            initialDelaySeconds: 5            periodSeconds: 10            timeoutSeconds: 3            failureThreshold: 3
azure-kubernetes-app-deploy/phases/quick-deploy.md:183In the instructionsOpen original file
# 2. Apply remaining manifestskubectl apply -f k8s/ --recursive# 3. Wait for rolloutkubectl rollout status deployment/<app-name> -n <namespace> --timeout=300s```
azure-kubernetes-app-deploy/phases/quick-deploy.md:176In the instructionsOpen original file
### Deploy to cluster```bash# 1. Create namespace (must succeed before proceeding)kubectl apply -f k8s/namespace.yamlkubectl get namespace <namespace> -o name   # verify# 2. Apply remaining manifestskubectl apply -f k8s/ --recursive# 3. Wait for rolloutkubectl rollout status deployment/<app-name> -n <namespace> --timeout=300s```
Medium risk

The CI “rollback on failure” condition is usually false when rollout fails

Source references: 2
What we found

The workflow applies manifests and waits for rollout, but writes `deployed=true` only after rollout succeeds. The rollback step requires both job failure and that output. A rollout timeout or failure therefore exits before the flag is set, skipping rollback exactly when it is needed.

Why this matters

The failed revision remains in the cluster, potentially with unavailable pods, partially updated resources, or an outage, despite the template creating an expectation of automatic rollback.

The deploy step applies manifests, waits for rollout, and writes deployed=true only after the wait succeeds. If apply has changed the cluster but rollout times out or fails, the shell exits before setting the output. The rollback condition also requires that output, so rollback is normally skipped in exactly that failure path, leaving a failed or partial release. Users can require the flag immediately after successful apply, or independently detect applied revisions, and test the failure path.

azure-kubernetes-app-deploy/templates/github-actions/deploy.yml:171In the instructionsOpen original file
      - name: Deploy to AKS        id: deploy        run: |          # Ensure the namespace exists before applying manifests          kubectl create namespace ${{ env.NAMESPACE }} --dry-run=client -o yaml \            | kubectl apply -f -          kubectl apply -f k8s/ --namespace ${{ env.NAMESPACE }}          kubectl rollout status deployment/${{ env.APP_NAME }} \            --namespace ${{ env.NAMESPACE }} \            --timeout=300s          # Signal that the deployment was applied — used to gate rollback          echo "deployed=true" >> "$GITHUB_OUTPUT"
Show 1 other places
azure-kubernetes-app-deploy/templates/github-actions/deploy.yml:186In the instructionsOpen original file
      - name: Rollback on failure        if: failure() && steps.deploy.outputs.deployed == 'true'        run: |          kubectl rollout undo deployment/${{ env.APP_NAME }} \            --namespace ${{ env.NAMESPACE }}          kubectl rollout status deployment/${{ env.APP_NAME }} \            --namespace ${{ env.NAMESPACE }} \            --timeout=120s          echo "⚠️ Rolled back to previous revision"
Could it expose your files or keys?Looks for uploads of files containing passwords or keys, and keys written directly in the code.No risks found
Could it delete files or keep running?Looks for broad file deletion, disk overwrites, and programs set to start automatically.Risks found: 2
High risk

Failure rollback can delete pre-existing resources and an entire namespace

Source references: 3
What we found

The deployment workflow can generate a namespace manifest under `k8s/`, while its failure recovery runs `kubectl delete -f k8s/` over the whole directory. Deletion is based on names declared in the files and does not distinguish objects created by this run from objects that already existed.

Why this matters

If the directory describes an existing or shared namespace and resources, rollback can remove them. Namespace deletion also cascades to unrelated workloads, configuration, and Secrets in that namespace, causing serious disruption or data loss.

The workflow can generate a Namespace manifest and can also modify pre-existing manifests in place; its failure guide then deletes the entire k8s/ set. kubectl deletes by declared object identity and cannot distinguish objects created by this run from older ones. If a Namespace is included, deletion can cascade to unrelated workloads inside it. Users should require rollback by a recorded object set or deployment label, preview exact targets, and exclude pre-existing namespaces from automatic deletion.

azure-kubernetes-app-deploy/phases/quick-deploy.md:104In the instructionsOpen original file
| Manifest | Template | Notes ||----------|----------|-------|| `k8s/namespace.yaml` | `templates/k8s/namespace.yaml` | || `k8s/serviceaccount.yaml` | `templates/k8s/serviceaccount.yaml` | Workload Identity || `k8s/deployment.yaml` | `templates/k8s/deployment.yaml` | image tag set after `az acr build`, not at generation time || `k8s/service.yaml` | `templates/k8s/service.yaml` | |
Show 2 other places
azure-kubernetes-app-deploy/references/rollback.md:22In the instructionsOpen original file
## kubectl apply Failed (Section 4 — Deploy to Cluster)```bash# Remove the partially applied resources:kubectl delete -f k8s/
azure-kubernetes-app-deploy/phases/quick-deploy.md:100In the instructionsOpen original file
**If existing manifests found** (in `k8s/`, `manifests/`, or `deploy/`): Validate against AKS Deployment Safeguards (Section 3) and apply targeted fixes. Do not regenerate — improve in place.**If no manifests found:** Generate from `templates/k8s/` templates. Replace `<angle-bracket>` placeholders with detected values.
Medium risk

Deployment unconditionally overwrites an existing kubeconfig entry

Source references: 1
What we found

The deployment command uses `az aks get-credentials ... --overwrite-existing`. This replaces same-named cluster/user information in the local kubeconfig and may change the current context instead of isolating credentials for this deployment.

Why this matters

Existing authentication configuration or context selection may be lost. Later manual or automated `kubectl` commands could target an unintended cluster, risking reads or changes in the wrong environment.

The deployment flow explicitly runs get-credentials with --overwrite-existing and does not use an isolated kubeconfig or require confirmation at that step. For matching entries, it replaces local credential/connection data, and the command normally changes the current context, affecting later kubectl decisions—especially in multi-cluster environments. Users can require a temporary KUBECONFIG, save and restore the prior context, or display and confirm the exact target before overwrite.

azure-kubernetes-app-deploy/phases/quick-deploy.md:151In the instructionsOpen original file
## Section 4: Deploy### Ensure kubectl context```bashaz aks get-credentials -g <resource_group> -n <aks_cluster_name> --overwrite-existing```
Could it bypass safety checks?Looks for skipped website security checks, excessive file access, or actions that skip your approval.Risks found: 1
High risk

Read-only assessment requests permission to obtain cluster user credentials

Source references: 4
What we found

Although the readiness assessment calls itself read-only, its required permissions include `listClusterUserCredential/action`, and its troubleshooting reference recommends granting the AKS Cluster User Role when access is missing. That action can retrieve cluster user credentials rather than merely read configuration.

Why this matters

The assigned principal may gain Kubernetes API access; its actual capabilities depend on the cluster's Kubernetes/Azure RBAC configuration. Compromise or misuse of that identity could therefore extend beyond compatibility assessment.

The assessment declares itself read-only but requires the action permission used to obtain AKS cluster-user credentials, and its troubleshooting reference shows how to grant the corresponding role. If followed, the principal can request user credentials rather than merely read cluster configuration. This may support live workload assessment, but it expands credential and cluster access. Users can ask why MCP/offline assessment needs this permission and restrict any grant to the target cluster and a temporary principal.

azure-kubernetes-automatic-readiness/SKILL.md:97In the instructionsOpen original file
**Required permissions:**- `Microsoft.ContainerService/managedClusters/read`- `Microsoft.ContainerService/managedClusters/listClusterUserCredential/action`
Show 3 other places
azure-kubernetes-automatic-readiness/references/mcp-integration.md:55In the instructionsOpen original file
# Minimum permissions required:# - Microsoft.ContainerService/managedClusters/read# - Microsoft.ContainerService/managedClusters/listClusterUserCredential/action# Assign if missing (requires Owner or User Access Administrator)az role assignment create \  --assignee <principal-id> \  --role "Azure Kubernetes Service Cluster User Role" \  --scope /subscriptions/<subscription-id>/resourceGroups/<rg>/providers/Microsoft.ContainerService/managedClusters/<cluster>```
azure-kubernetes-automatic-readiness/SKILL.md:49In the instructionsOpen original file
1. **Read-only**: NEVER modify cluster state. Assessment is read-only. Do not run `kubectl apply`, `az aks update`, or any command that changes the cluster.2. **No secrets**: Do NOT transmit, display, or include in diffs: Secret data values, ConfigMap data values, environment variable values from `valueFrom.secretKeyRef`, service account tokens, or connection strings.
azure-kubernetes-automatic-readiness/references/mcp-integration.md:59In the instructionsOpen original file
# Assign if missing (requires Owner or User Access Administrator)az role assignment create \  --assignee <principal-id> \  --role "Azure Kubernetes Service Cluster User Role" \  --scope /subscriptions/<subscription-id>/resourceGroups/<rg>/providers/Microsoft.ContainerService/managedClusters/<cluster>```
Could it mislead the AI or hide text?Checks the skill instructions for requests to ignore you, influence the report, or hide text in invisible characters.No risks found
Could it change links or payment recipients without asking?Looks for forced referral or payment changes combined with instructions to hide the change.No risks found

Inside this skill

8 instruction sections

The main skill plans and configures AKS. It first discovers available AKS operations through Azure MCP, then falls back to Azure CLI when necessary. It covers networking, security, observability, upgrades, node pools, and cost settings.

View source
SKILL.md:42In the instructionsOpen original file
## Rules1. Start with the user's requirements for provisioning compute, networking, security, and other settings.2. Use the `azure` MCP server and select `mcp_azure_mcp_aks` first to discover the exact AKS-specific MCP tools surfaced by the client. Choose the smallest discovered AKS tool that fits the task, and fall back to Azure CLI (`az aks`) only when the needed functionality is not exposed through the AKS MCP surface.3. Determine if AKS Automatic or Standard SKU is more appropriate based on the user's need for control vs convenience. Default to AKS Automatic unless specific customizations are required.4. Document decisions and rationale for cluster configuration choices, especially for Day-0 decisions that are hard to change later (networking, API server access).

The app-deployment sub-skill inspects the project and Azure environment, generates or modifies Dockerfiles and Kubernetes manifests, then builds and pushes an image, applies manifests to an existing cluster, and waits for rollout. It can therefore change local files, the image registry, and a live cluster rather than merely provide advice.

View source
azure-kubernetes-app-deploy/phases/quick-deploy.md:70In the instructionsOpen original file
## Section 2: File GenerationWrite all files in a single response turn.### Dockerfile**If existing Dockerfile:** Validate against best practices (multi-stage build, non-root USER, base tags pinned to a stable major tag (not :latest, not a frozen patch), layer caching, .dockerignore). Apply targeted fixes for failures — do not regenerate the file.
azure-kubernetes-app-deploy/phases/quick-deploy.md:167In the instructionsOpen original file
### Build and push```bashIMAGE_TAG=$(git rev-parse --short HEAD)   # fallback: date +%Y%m%d%H%M%Saz acr build --registry <acr_name> --image <app-name>:$IMAGE_TAG --file Dockerfile .```
azure-kubernetes-app-deploy/phases/quick-deploy.md:176In the instructionsOpen original file
### Deploy to cluster```bash# 1. Create namespace (must succeed before proceeding)kubectl apply -f k8s/namespace.yamlkubectl get namespace <namespace> -o name   # verify# 2. Apply remaining manifestskubectl apply -f k8s/ --recursive# 3. Wait for rolloutkubectl rollout status deployment/<app-name> -n <namespace> --timeout=300s```

The Automatic-readiness sub-skill explicitly requires read-only cluster assessment and prior explicit approval for every file change. It supports both MCP-connected cluster assessment and offline validation of local manifests.

View source
azure-kubernetes-automatic-readiness/SKILL.md:47In the instructionsOpen original file
## Guardrails — READ FIRST1. **Read-only**: NEVER modify cluster state. Assessment is read-only. Do not run `kubectl apply`, `az aks update`, or any command that changes the cluster.2. **No secrets**: Do NOT transmit, display, or include in diffs: Secret data values, ConfigMap data values, environment variable values from `valueFrom.secretKeyRef`, service account tokens, or connection strings.3. **User approval for file changes**: Present every fix as a diff. The user must explicitly accept before you write to any file.4. **Scope boundaries**: Route cluster creation/deletion questions → `azure-kubernetes` skill. Route live troubleshooting → `azure-diagnostics` skill.
azure-kubernetes-automatic-readiness/SKILL.md:65In the instructionsOpen original file
**Option A — Cluster-connected assessment (via AKS MCP)**Use when the user has a connected cluster context (subscription + resource group + cluster name).**Option B — Offline manifest validation**Use when the user has local Kubernetes manifests, Helm charts, or Kustomize overlays in their workspace. Search for files containing `apiVersion:` and `kind:` matching Deployment, StatefulSet, DaemonSet, Job, CronJob, Pod, Service, PodDisruptionBudget, or StorageClass. For Helm charts, look for `Chart.yaml` and rendered templates under `templates/`.**Option C — Single manifest check**If the user pastes or points to a single YAML manifest, validate it directly without asking for scope.

The bundled GitHub Actions template logs into Azure through OIDC on pushes to the main branch, remotely builds an image, and applies resources from the k8s directory to AKS.

View source
azure-kubernetes-app-deploy/templates/github-actions/deploy.yml:18In the instructionsOpen original file
on:  # Trigger on push to main branch (app code changes only)  push:    branches:      - main    paths-ignore:      - 'docs/**'      - '*.md'      - '.github/**'      - '.vscode/**'  # Allow manual trigger from the Actions tab  workflow_dispatch:
azure-kubernetes-app-deploy/templates/github-actions/deploy.yml:124In the instructionsOpen original file
      # -----------------------------------------------------------      - name: Azure Login (OIDC)        uses: azure/login@v2        with:          client-id: ${{ secrets.AZURE_CLIENT_ID }}          tenant-id: ${{ secrets.AZURE_TENANT_ID }}          subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}
azure-kubernetes-app-deploy/templates/github-actions/deploy.yml:171In the instructionsOpen original file
      - name: Deploy to AKS        id: deploy        run: |          # Ensure the namespace exists before applying manifests          kubectl create namespace ${{ env.NAMESPACE }} --dry-run=client -o yaml \            | kubectl apply -f -          kubectl apply -f k8s/ --namespace ${{ env.NAMESPACE }}          kubectl rollout status deployment/${{ env.APP_NAME }} \            --namespace ${{ env.NAMESPACE }} \            --timeout=300s
Start here · InstructionsSKILL.md
azure-kubernetes
Lines connect the instruction file to its sections, not an observed execution order. Select a section to read the source.

File reference map

References: 40
Files making referencesReferenced content
Lines show actual file references, not execution order. Select a node to highlight its connections and inspect the files and source locations. Dashed lines include files that still need locating.
Files and check records53 files

Coverage and gaps

Content covered in each file

These are the source ranges included in this check, not a guarantee that every issue has been resolved.

  • SKILL.mdFull text included
  • references/azure-aks-autoscaler.mdFull text included
  • references/azure-aks-rightsizing.mdFull text included
  • references/azure-aks-spot.mdFull text included
  • references/azure-aks-vpa.mdFull text included
  • references/cli-reference.mdFull text included
  • azure-kubernetes-app-deploy/references/base-images.mdFull text included
  • azure-kubernetes-app-deploy/references/detection.mdFull text included
  • azure-kubernetes-app-deploy/references/rollback.mdFull text included
  • azure-kubernetes-app-deploy/references/safeguards.mdFull text included
  • azure-kubernetes-app-deploy/references/workload-identity.mdFull text included
  • azure-kubernetes-automatic-readiness/references/common-fixes.mdFull text included
  • azure-kubernetes-automatic-readiness/references/constraint-spec-v1.yamlFull text included
  • azure-kubernetes-automatic-readiness/references/mcp-integration.mdFull text included
  • azure-kubernetes-automatic-readiness/references/migration-guide-summary.mdFull text included
  • azure-kubernetes-app-deploy/SKILL.mdFull text included
  • azure-kubernetes-automatic-readiness/SKILL.mdFull text included
  • azure-kubernetes-app-deploy/knowledge-packs/frameworks/aspnet-core.mdFull text included
  • azure-kubernetes-app-deploy/knowledge-packs/frameworks/django.mdFull text included
  • azure-kubernetes-app-deploy/knowledge-packs/frameworks/express.mdFull text included
  • azure-kubernetes-app-deploy/knowledge-packs/frameworks/fastapi.mdFull text included
  • azure-kubernetes-app-deploy/knowledge-packs/frameworks/flask.mdFull text included
  • azure-kubernetes-app-deploy/knowledge-packs/frameworks/go.mdFull text included
  • azure-kubernetes-app-deploy/knowledge-packs/frameworks/nestjs.mdFull text included
  • azure-kubernetes-app-deploy/knowledge-packs/frameworks/nextjs.mdFull text included
  • azure-kubernetes-app-deploy/knowledge-packs/frameworks/spring-boot.mdFull text included
  • azure-kubernetes-app-deploy/phases/quick-deploy.mdFull text included
  • azure-kubernetes-app-deploy/templates/dockerfiles/dotnet.DockerfileFull text included
  • azure-kubernetes-app-deploy/templates/dockerfiles/dotnet.dockerignoreFull text included
  • azure-kubernetes-app-deploy/templates/dockerfiles/go.DockerfileFull text included
  • azure-kubernetes-app-deploy/templates/dockerfiles/go.dockerignoreFull text included
  • azure-kubernetes-app-deploy/templates/dockerfiles/java.DockerfileFull text included
  • azure-kubernetes-app-deploy/templates/dockerfiles/java.dockerignoreFull text included
  • azure-kubernetes-app-deploy/templates/dockerfiles/node.DockerfileFull text included
  • azure-kubernetes-app-deploy/templates/dockerfiles/node.dockerignoreFull text included
  • azure-kubernetes-app-deploy/templates/dockerfiles/python.DockerfileFull text included
  • azure-kubernetes-app-deploy/templates/dockerfiles/python.dockerignoreFull text included
  • azure-kubernetes-app-deploy/templates/dockerfiles/rust.DockerfileFull text included
  • azure-kubernetes-app-deploy/templates/dockerfiles/rust.dockerignoreFull text included
  • azure-kubernetes-app-deploy/templates/github-actions/deploy.ymlFull text included
  • azure-kubernetes-app-deploy/templates/k8s/configmap.yamlFull text included
  • azure-kubernetes-app-deploy/templates/k8s/deployment.yamlFull text included
  • azure-kubernetes-app-deploy/templates/k8s/gateway.yamlFull text included
  • azure-kubernetes-app-deploy/templates/k8s/hpa.yamlFull text included
  • azure-kubernetes-app-deploy/templates/k8s/httproute.yamlFull text included
  • azure-kubernetes-app-deploy/templates/k8s/ingress.yamlFull text included
  • azure-kubernetes-app-deploy/templates/k8s/namespace.yamlFull text included
  • azure-kubernetes-app-deploy/templates/k8s/networkpolicy.yamlFull text included
  • azure-kubernetes-app-deploy/templates/k8s/pdb.yamlFull text included
  • azure-kubernetes-app-deploy/templates/k8s/service.yamlFull text included
  • azure-kubernetes-app-deploy/templates/k8s/serviceaccount.yamlFull text included
  • azure-kubernetes-app-deploy/templates/mermaid/architecture-diagram.mdFull text included
  • azure-kubernetes-app-deploy/templates/mermaid/summary-dashboard.mdFull text included

This report is for the version above. We read the available code and instructions without running the skill or checking extra packages it installs. This is not a promise of safety: a different version or setup may behave differently.

  • SKILL.mdInstructions
  • azure-kubernetes-app-deploy/SKILL.mdSupporting file
  • azure-kubernetes-app-deploy/knowledge-packs/frameworks/aspnet-core.mdSupporting file
  • azure-kubernetes-app-deploy/knowledge-packs/frameworks/django.mdSupporting file
  • azure-kubernetes-app-deploy/knowledge-packs/frameworks/express.mdSupporting file
  • azure-kubernetes-app-deploy/knowledge-packs/frameworks/fastapi.mdSupporting file
  • azure-kubernetes-app-deploy/knowledge-packs/frameworks/flask.mdSupporting file
  • azure-kubernetes-app-deploy/knowledge-packs/frameworks/go.mdSupporting file
  • azure-kubernetes-app-deploy/knowledge-packs/frameworks/nestjs.mdSupporting file
  • azure-kubernetes-app-deploy/knowledge-packs/frameworks/nextjs.mdSupporting file
  • azure-kubernetes-app-deploy/knowledge-packs/frameworks/spring-boot.mdSupporting file
  • azure-kubernetes-app-deploy/phases/quick-deploy.mdSupporting file
  • azure-kubernetes-app-deploy/references/base-images.mdSupporting file
  • azure-kubernetes-app-deploy/references/detection.mdSupporting file
  • azure-kubernetes-app-deploy/references/rollback.mdSupporting file
  • azure-kubernetes-app-deploy/references/safeguards.mdSupporting file
  • azure-kubernetes-app-deploy/references/workload-identity.mdSupporting file
  • azure-kubernetes-app-deploy/templates/dockerfiles/dotnet.DockerfileSupporting file
  • azure-kubernetes-app-deploy/templates/dockerfiles/dotnet.dockerignoreSupporting file
  • azure-kubernetes-app-deploy/templates/dockerfiles/go.DockerfileSupporting file
  • azure-kubernetes-app-deploy/templates/dockerfiles/go.dockerignoreSupporting file
  • azure-kubernetes-app-deploy/templates/dockerfiles/java.DockerfileSupporting file
  • azure-kubernetes-app-deploy/templates/dockerfiles/java.dockerignoreSupporting file
  • azure-kubernetes-app-deploy/templates/dockerfiles/node.DockerfileSupporting file
  • azure-kubernetes-app-deploy/templates/dockerfiles/node.dockerignoreSupporting file
  • azure-kubernetes-app-deploy/templates/dockerfiles/python.DockerfileSupporting file
  • azure-kubernetes-app-deploy/templates/dockerfiles/python.dockerignoreSupporting file
  • azure-kubernetes-app-deploy/templates/dockerfiles/rust.DockerfileSupporting file
  • azure-kubernetes-app-deploy/templates/dockerfiles/rust.dockerignoreSupporting file
  • azure-kubernetes-app-deploy/templates/github-actions/deploy.ymlSupporting file
  • azure-kubernetes-app-deploy/templates/k8s/configmap.yamlSupporting file
  • azure-kubernetes-app-deploy/templates/k8s/deployment.yamlSupporting file
  • azure-kubernetes-app-deploy/templates/k8s/gateway.yamlSupporting file
  • azure-kubernetes-app-deploy/templates/k8s/hpa.yamlSupporting file
  • azure-kubernetes-app-deploy/templates/k8s/httproute.yamlSupporting file
  • azure-kubernetes-app-deploy/templates/k8s/ingress.yamlSupporting file
  • azure-kubernetes-app-deploy/templates/k8s/namespace.yamlSupporting file
  • azure-kubernetes-app-deploy/templates/k8s/networkpolicy.yamlSupporting file
  • azure-kubernetes-app-deploy/templates/k8s/pdb.yamlSupporting file
  • azure-kubernetes-app-deploy/templates/k8s/service.yamlSupporting file
  • azure-kubernetes-app-deploy/templates/k8s/serviceaccount.yamlSupporting file
  • azure-kubernetes-app-deploy/templates/mermaid/architecture-diagram.mdSupporting file
  • azure-kubernetes-app-deploy/templates/mermaid/summary-dashboard.mdSupporting file
  • azure-kubernetes-automatic-readiness/SKILL.mdSupporting file
  • azure-kubernetes-automatic-readiness/references/common-fixes.mdSupporting file
  • azure-kubernetes-automatic-readiness/references/constraint-spec-v1.yamlSupporting file
  • azure-kubernetes-automatic-readiness/references/mcp-integration.mdSupporting file
  • azure-kubernetes-automatic-readiness/references/migration-guide-summary.mdSupporting file
  • references/azure-aks-autoscaler.mdSupporting file
  • references/azure-aks-rightsizing.mdSupporting file
  • references/azure-aks-spot.mdSupporting file
  • references/azure-aks-vpa.mdSupporting file
  • references/cli-reference.mdSupporting file

Operations mentioned in code and instructions

Connect to websites
SKILL.md:69In the instructionsOpen original file
- **Azure CNI (VNet-routable)**: pod IPs directly from VNet (pod subnet or node subnet), use when pods must be directly addressable from VNet or on-prem  - Docs: https://learn.microsoft.com/azure/aks/azure-cni-overlay
azure-kubernetes-app-deploy/knowledge-packs/frameworks/aspnet-core.md:181In the instructionsOpen original file
- **Default port:** 8080 (since .NET 8; previously 80 in .NET 7 and earlier)- **Env var override:** `ASPNETCORE_URLS=http://+:8080` or `ASPNETCORE_HTTP_PORTS=8080`- **Code override:** `builder.WebHost.UseUrls("http://+:8080")` in `Program.cs`
azure-kubernetes-app-deploy/knowledge-packs/frameworks/aspnet-core.md:182In the instructionsOpen original file
- **Env var override:** `ASPNETCORE_URLS=http://+:8080` or `ASPNETCORE_HTTP_PORTS=8080`- **Code override:** `builder.WebHost.UseUrls("http://+:8080")` in `Program.cs`
Read keys or account settings
SKILL.md:87In the instructionsOpen original file
### 3. Security- Use **Microsoft Entra ID** everywhere (control plane, Workload Identity for pods, node access). Avoid static credentials.- Azure Key Vault via **Secrets Store CSI Driver** for secrets
SKILL.md:155In the instructionsOpen original file
|-----------------|--------------|-------------|| MCP tool call fails or times out | Invalid credentials, subscription, or AKS context | Verify `az login`, confirm the active subscription context with `az account show`, and check the target resource group without echoing subscription identifiers back to the user || Quota exceeded | Regional vCPU or resource limits | Request quota increase or select different region/VM SKU |
azure-kubernetes-app-deploy/knowledge-packs/frameworks/django.md:158In the instructionsOpen original file
- **CLI flag:** `--bind 0.0.0.0:8000` passed to `gunicorn`- **Env var override:** `PORT` (read via `gunicorn --bind 0.0.0.0:$PORT` or `int(os.environ.get("PORT", 8000))`)- **Workers formula:** `2 * CPU_CORES + 1` (e.g. `--workers 3` for a 1-vCPU container)
Run commands
azure-kubernetes-app-deploy/knowledge-packs/frameworks/aspnet-core.md:54In the instructionsOpen original file
```bashdotnet add package AspNetCore.HealthChecks.NpgSql
azure-kubernetes-app-deploy/knowledge-packs/frameworks/django.md:22In the instructionsOpen original file
```bashpip install django-health-check
azure-kubernetes-app-deploy/knowledge-packs/frameworks/nestjs.md:36In the instructionsOpen original file
```bashnpm install @nestjs/terminus
Read files
azure-kubernetes-app-deploy/knowledge-packs/frameworks/aspnet-core.md:127In the instructionsOpen original file
When `readOnlyRootFilesystem: true` is set, ASP.NET Core needs `/tmp` writable:
azure-kubernetes-app-deploy/knowledge-packs/frameworks/aspnet-core.md:184In the instructionsOpen original file
The port change from 80 to 8080 in .NET 8 aligns with non-root container best practices — port 80 requires elevated privileges. Set `DOTNET_EnableDiagnostics=0` to disable diagnostic pipes that require writable paths not available in read-only filesystems.
azure-kubernetes-app-deploy/knowledge-packs/frameworks/django.md:117In the instructionsOpen original file
When `readOnlyRootFilesystem: true` is set, Django apps need `/tmp` writable and optionally `/app/staticfiles`:
Install extra software packages
azure-kubernetes-app-deploy/knowledge-packs/frameworks/django.md:23In the instructionsOpen original file
```bashpip install django-health-check```
azure-kubernetes-app-deploy/knowledge-packs/frameworks/express.md:35In the instructionsOpen original file
| npm | `npm ci` | `npm ci --omit=dev` | `package-lock.json` || yarn | `yarn install --frozen-lockfile` | `yarn install --frozen-lockfile --production` | `yarn.lock` || pnpm | `pnpm install --frozen-lockfile` | `pnpm install --frozen-lockfile --prod` | `pnpm-lock.yaml` |
azure-kubernetes-app-deploy/knowledge-packs/frameworks/express.md:36In the instructionsOpen original file
| yarn | `yarn install --frozen-lockfile` | `yarn install --frozen-lockfile --production` | `yarn.lock` || pnpm | `pnpm install --frozen-lockfile` | `pnpm install --frozen-lockfile --prod` | `pnpm-lock.yaml` |
Change files
azure-kubernetes-app-deploy/knowledge-packs/frameworks/go.md:32In the instructionsOpen original file
    w.WriteHeader(http.StatusOK)    w.Write([]byte(`{"status":"ok"}`))})
azure-kubernetes-app-deploy/knowledge-packs/frameworks/go.md:37In the instructionsOpen original file
        w.WriteHeader(http.StatusServiceUnavailable)        w.Write([]byte(`{"status":"not ready"}`))        return
azure-kubernetes-app-deploy/knowledge-packs/frameworks/go.md:41In the instructionsOpen original file
    w.WriteHeader(http.StatusOK)    w.Write([]byte(`{"status":"ready"}`))})
Lines read
5,793
File checksum (to compare versions)
e5c8695ecefb3f8f53374d0a5c2dcf0cd091abaeb3055e68144c953e266551c4