> ## Documentation Index > Fetch the complete documentation index at: https://docs.plerion.com/llms.txt > Use this file to discover all available pages before exploring further. # Azure workload coverage > Which Azure workload types Plerion scans for vulnerabilities, how each one is scanned, and what is not covered Plerion scans the Azure workload types below when the matching option is enabled in the subscription's workload scanning settings, except AKS and Azure Red Hat OpenShift, which are scanned by the Kubernetes integration. Each scan produces vulnerability, sensitive data and SBOM results on the workload's asset, and a publicly exposed workload with high or critical vulnerabilities also produces an attack path finding (`PLERION-AZURE-446`). ## Scanned workload types | Workload type | Asset type | Scanned from | Attack path | | - | - | - | - | | Virtual Machines | `Azure::VirtualMachine::Instance` | OS disk snapshot, then each data disk | Yes | | Virtual Machine Scale Sets | `Azure::VirtualMachine::ScaleSet` | One member per distinct image | Yes | | Functions | `Azure::FunctionApp::Function` | Deployed code, through the publishing profile | Yes | | App Service Web Apps | `Azure::AppServices::WebApp` | Deployed code, or the container image | Yes | | Container Apps | `Azure::Container::App` | Every container image of the current template | Yes | | Container Instances | `Azure::Container::Instance` | Every container image of the group | Yes | | AKS | `Azure::Container::Cluster` | Kubernetes integration | Not yet | | Azure Red Hat OpenShift | `Azure::RedHatOpenShift::Cluster` | Kubernetes integration | Not yet | | Service Fabric | `Azure::ServiceFabric::ManagedCluster`, `Azure::ServiceFabric::Cluster` | Node type scale sets | Through the scale set | | Batch | `Azure::Batch::Pool`, `Azure::Batch::Account` | Pool image, and application packages | Not yet | ## How each type is scanned ### Virtual Machines A snapshot of the OS disk is attached to an appliance and scanned, then each managed data disk the same way, one at a time. A VM with many or large data disks takes longer to scan. A data disk that cannot be copied, for example one encrypted with a customer-managed key, is reported as a warning and the scan continues. Unmanaged disks are not scanned. ### Virtual Machine Scale Sets Members are grouped by the image they run and one member per distinct image is scanned, a running member ahead of a stopped one, the same way Plerion samples AWS Auto Scaling groups. A Flexible-orchestration member is scanned through a snapshot of its OS disk. Uniform-orchestration members, and Flexible members with ephemeral OS disks, have no disk to snapshot, so a disk is created from their image, scanned and deleted. Results are attributed to the scale set, and each scan names the image and, where one was used, the member it sampled. An image published from another subscription, such as the Microsoft-managed images AKS node pools run, cannot be read by the appliance identity; the set is reported as not scanned with that reason. A set with no member and no resolvable image is reported as not scanned. A scan whose disk cannot be prepared is reported as failed with the Azure error. ### Functions The function app's deployed code is downloaded through its publishing profile and scanned. This needs basic authentication on the SCM endpoint. ### App Service Web Apps The deployed code is downloaded through the publishing profile (FTPS, or the Kudu zip API) and scanned, which needs basic authentication on the SCM endpoint. A web app that runs a custom container (`DOCKER|image` runtime stack) has its image pulled and scanned instead, as for Container Apps. ### Container Apps and Container Instances Every container image of the app's current template, or of the container group, is pulled by the appliance and scanned. Images in your Azure Container Registries are pulled with the appliance identity; public images are pulled anonymously. An image the appliance cannot pull is reported per image with the reason. ### AKS and Azure Red Hat OpenShift Both are scanned by the [Kubernetes integration](/guides/integrations/kubernetes/overview): install the Plerion collector in the cluster and it scans the images its pods run from inside the cluster. A cluster without the collector is collected as an asset but not scanned, and the node operating system is not scanned. On OpenShift (verified on 4.18), collector chart v1.2.9 or later runs under the restricted security context; earlier versions need the `anyuid` security context constraint on the collector's service account. The platform's own images on `quay.io/openshift-release-dev` scan when the chart is given the cluster pull secret (`collector.registry.pullSecrets: [openshift-config/pull-secret]`); the collector then pulls through the cluster's image mirror sets. Without it those images are reported as failed scans and your own images scan normally. [Learn more →](/guides/integrations/kubernetes/collector-manager/permissions/allow-access-to-managed-registries) ### Service Fabric Every node type is a Virtual Machine Scale Set in your subscription, so the scale set scan above covers the node image; the cluster itself is collected as an Azure asset. Application packages deployed to the cluster live in its image store behind the cluster certificate and are not scanned. ### Batch The image a pool boots its nodes from is scanned: a disk is created from it, scanned and deleted, as for Uniform scale sets. Pools in user-subscription allocation mode are also scale sets in your subscription. An image published from another subscription is reported as not scanned with that reason. The account's active application packages are downloaded from its linked storage account, unpacked and scanned as filesystems. This needs `Storage Blob Data Reader` on that storage account for the appliance identity; the install script grants it for the Batch accounts that exist when it runs. Task resource files are not scanned. ## Not scanned | Workload type | Why | | - | - | | Spring Apps | Microsoft closed the service to new customers on 17 March 2025 and retires it on 31 March 2028, and its API offers nothing to download for a deployment (an upload URL for the JAR and a log URL; Enterprise-tier builds land in a service-owned registry). Its migration targets, Container Apps and AKS, are covered above. | ## Permissions The permissions each workload type needs are granted by the CWPP install script. See [Azure CWPP architecture](/guides/integrations/azure/azure-cwpp-architecture#steps-to-onboard-an-azure-subscription) for the full list. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.