| Virtual Machines | Azure::VirtualMachine::Instance | A snapshot of the OS disk is attached to an appliance and scanned, then each managed data disk the same way, on its own unit. | Yes | Data disks are copied, scanned and removed one at a time after the OS disk, so 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 | Azure::VirtualMachine::ScaleSet | The set’s 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 have no snapshot-able disk, so their image is scanned instead: a disk is created from the image, scanned and deleted; the same applies to Flexible members with ephemeral OS disks. Results are attributed to the scale set and each scan names the image and, where one was used, the member it sampled. | Yes | An image published from another subscription, such as the Microsoft-managed images AKS node pools run, cannot be read by the appliance identity; such a 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 | Azure::FunctionApp::Function | The function app’s deployed code is downloaded through its publishing profile and scanned. | Yes | Requires basic authentication on the SCM endpoint. |
| App Service Web Apps | Azure::AppServices::WebApp | The deployed code is downloaded through the publishing profile (FTPS, or the Kudu zip API) and scanned. A web app that runs a custom container (DOCKER|image runtime stack) has its image pulled and scanned instead, as for Container Apps. | Yes | Code scans require basic authentication on the SCM endpoint. Container images are pulled with the appliance identity from your Azure Container Registries, or anonymously from public registries. |
| Container Apps | Azure::Container::App | Every container image of the app’s current template is pulled by the appliance and scanned. Images in your Azure Container Registries are pulled with the appliance identity. | Yes | An image in a registry the appliance identity cannot pull is reported per image with the reason. |
| Container Instances | Azure::Container::Instance | Every container image of the container group is pulled and scanned. | Yes | As for Container Apps. |
| AKS | Azure::Container::Cluster | Through the Kubernetes integration: install the Plerion collector in the cluster and it scans the images its pods run from inside the cluster. | Not yet | A cluster without the collector is collected as an asset but not scanned. |
| Azure Red Hat OpenShift | Azure::RedHatOpenShift::Cluster | Through the Kubernetes integration, the same way as AKS: install the Plerion collector in the cluster and it scans the images its pods run. The cluster is collected as an Azure asset. Verified on OpenShift 4.18. | Not yet | A cluster without the collector is collected as an asset but not scanned. Collector chart versions before the one that mounts a writable working directory need the anyuid security context constraint on the collector’s service account. OpenShift’s own platform images on quay.io/openshift-release-dev scan when the collector chart is given the cluster pull secret (collector.registry.pullSecrets: [openshift-config/pull-secret], from the next collector chart release); the collector then pulls through the cluster’s image mirror sets. Without it they are reported as failed scans while your workload images scan normally. The node operating system itself is not scanned. |
| Service Fabric | Azure::ServiceFabric::ManagedCluster, Azure::ServiceFabric::Cluster | Every node type is a Virtual Machine Scale Set in your subscription, so the scale set row above scans the node image. The cluster is collected as an Azure asset. | Through the scale set | Application packages deployed to the cluster live in its image store behind the cluster certificate and are not scanned. |
| Batch | Azure::Batch::Pool, Azure::Batch::Account | 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. The account’s active application packages are downloaded from its linked storage account, unpacked and scanned as filesystems. | Not yet | An image published from another subscription is reported as not scanned with that reason. Application packages need Storage Blob Data Reader on the account’s linked 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. |
