PLERION-AZURE-446).
Scanned workload types
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: 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 theanyuid 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 →
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 needsStorage 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.