What IT teams need to know about Linux Secure Boot certificates expiring in 2026
If your organization does not use UEFI Secure Boot on Linux systems, this transition does not affect your boot path. You can stop reading now. If you do use Secure Boot, here is what you need to know. The Microsoft Corporation UEFI CA (Certificate Authority) 2011 expires on June 27, 2026 (June 26 local time in some time zones). Expiration alone does not stop anything from booting and does not render a system insecure. Existing 2011-signed shims keep working on systems that still trust the 2011 CA. The real risk is narrower: once an operating system vendor ships a shim signed only by the Microsoft UEFI CA 2023, any system whose firmware does not already trust the 2023 CA will fail to boot. The work for you is to confirm, before that update reaches your systems, that your systems trust the 2023 CA. If you want the history of why a Microsoft certificate sits in the Linux Secure Boot path at all, skip to the end. Terms used in this post You may see three Microsoft Secure Boot certificate authorities discussed in 2026 guidance. This post focuses on the Microsoft UEFI CA 2011, which is the CA used for third-party UEFI boot applications such as the Linux shim. The other expiring Microsoft Secure Boot certificates are the Microsoft Corporation KEK CA 2011, which is used to authorize updates to Secure Boot databases, and the Microsoft Windows Production PCA 2011, which is used for Windows boot components. Windows systems have a separate update path for those certificates; this post covers only the Linux boot chain. The 2023 update also separates two uses that were both covered by the Microsoft UEFI CA 2011. The Microsoft UEFI CA 2023 is for third-party UEFI boot applications, including the Linux shim. The Microsoft Option ROM UEFI CA 2023 is for third-party option ROMs, such as firmware on some add-in cards. This post is about the Linux bootloader path, but physical systems that rely on signed option ROMs may need to check that path too. Microsoft began returning 2023-signed Linux shim binaries to operating system vendors in October 2025, and since then a submitted shim comes back signed by both the 2011 CA and the 2023 CA. Once the 2011 CA expires, Microsoft can only sign with the 2023 CA. In UEFI Secure Boot terminology, db is the allowed signature database, dbx is the forbidden or revoked signature database, and KEK contains keys that can authorize updates to db and dbx . SBAT is a shim ecosystem mechanism for revoking boot components by generation. SBAT is related to Secure Boot revocation, but it is separate from the CA expiration itself. For brevity, the rest of this post uses operating system vendor to include Linux distributions and other vendors that ship and support Linux boot components. Microsoft returns signed shims to that submitting operating system vendor. It does not push shim updates to end users or IT departments. Those reach systems through the normal operating system, package, image, or platform update channels. What is not happening Expiration is not revocation, and it does not cause an immediate boot failure. The 2011 CA expiring does not make existing 2011-signed shims stop booting on June 27, 2026. UEFI Secure Boot validates a signature against the trust database and revocation state, not against the certificate's validity period. The image-validation process in the UEFI specification bases the decision on whether the image's hash or signing certificate is present in the authorized database ( db ) and absent from the forbidden database ( dbx ). It does not check whether the certificate has expired. Firmware bugs are always possible, but expiration by itself should not invalidate an already-signed shim. There is also no current plan to revoke the Microsoft UEFI CA 2011. Expiration means Microsoft can no longer sign new binaries with that certificate. Revocation would mean telling systems not to trust binaries signed with it. Revocation is not the plan. For the same reason, do not remove the 2011 CA from a system's Secure Boot db . Removing it strips that trust path. Removal is not required for this transition, and existing boot components may still depend on the 2011 CA. No operating system vendor has to move to a 2023-signed shim on the expiration date. An operating system vendor may keep shipping a 2011-signed shim (if one is available), ship a 2023-only shim, or ship one carrying both signatures. That decision belongs to the operating system vendor. What can break The failure case is a mismatch between the shim signature and the firmware trust database. The moment to worry about is not the expiration date. It is when a system first receives a 2023-only shim. That leaves a remediation window: the time between the expiration date and the first 2023-only shim reaching a given system. How long it lasts depends on your operating system vendor's packaging decisions, any security fix that forces a new shim release, and how easily you can update firmware or VM Secure Boot state on the affected platforms. The transition comes down to one table: Firmware trust database 2011-only shim 2023-only shim Dual-signed shim 2011 CA only Boots, but depends on continued 2011 trust Does not boot Should boot 2023 CA only Does not boot Boots Should boot Both 2011 and 2023 CAs Boots Boots Boots The table is deliberately simple. Real systems also have dbx revocations, SBAT policy, firmware bugs, operating system vendor packaging choices, and platform-specific update paths. But this is the core compatibility problem. Dual-signed shims help bridge the transition, because the same shim can validate through either CA. However, they are not a guarantee. Some firmware mishandles multiple signatures and evaluates only one of them, revocation and vendor support still apply, and the operating system vendor decides whether to ship and support a dual-signed shim at all. This kind of failure happens early, before the operating system loads. Recovery means restoring a trusted boot path or following your operating system, hardware, or platform vendor's recovery guidance. It is not a package rollback inside a running system. Who should pay closest attention This transition matters most where the operating system, firmware, and update path may not move together. If you run a maintained operating system on maintained hardware or a maintained virtualization platform, the normal vendor update path may handle most of it. Closer attention is worthwhile where that path is missing, delayed, customized, or hard to validate. Older hardware is the first case. Some systems need a firmware update before they can trust the 2023 CA, and support can vary by model even within one hardware vendor's portfolio. Check each model you operate rather than assuming one answer covers the fleet. Long-lived virtual machines are the second. VM firmware is still firmware. A VM's Secure Boot state depends on when it was created, which platform firmware it uses, and which UEFI variables have changed since. Firmware is not just another package update, so a long-lived VM may never have received the relevant firmware or database updates unless the administrator or platform applied them. Your cloud or virtualization provider should be able to say how the 2023 CA is handled for new VMs, existing VMs, and imported or custom images. For Azure Trusted Launch and Confidential VMs specifically, Microsoft has published guidance on identifying and updating affected instances. Older operating system releases need more careful validation. Some lack current Secure Boot tooling, current fwupd daemon behavior, or a supported path for updating UEFI trust databases. A command that works on one release may not be supported on another. Custom fleets are their own category: systems built from custom images, frozen package mirrors, pinned bootloader versions, or local Secure Boot policy changes. The more an environment differs from the vendor's default update path, the more you need to verify the actual firmware trust database and installed shim directly. Smaller operating system vendors and long-tail distributions are worth checking too, especially if they submit shim updates infrequently or have not finished their 2023 signing transition. No single authoritative public list tells you which releases have completed this work. Who is responsible for what There is no single Linux Secure Boot owner who can make every system safe for the transition. The operating system vendor controls which shim and boot components it ships. It also controls whether its update process checks the firmware trust database before installing a 2023-only shim. The Linux community runs a community-driven shim-review process for shim submissions. That process is the primary review gate before an operating system vendor requests a Microsoft signature. It is not a support channel for individual systems or fleets. The hardware vendor, firmware vendor, or virtual machine platform controls which trust anchors are present by default and how firmware updates are delivered. In a physical machine, that may mean a BIOS or firmware update. In a VM, it may mean platform firmware defaults, guest-visible UEFI variables, or a provider-specific remediation process. Microsoft controls the Microsoft UEFI signing service and the Microsoft UEFI CAs. After shim-review approval, Microsoft verifies the submitter's relationship to the operating system vendor, runs some additional checks, signs submitted shims, and returns the signed artifacts to the submitting operating system vendor. Microsoft does not choose when each operating system vendor ships a new shim to its customers. Your organization controls the systems it administers. In practice, that means checking whether Secure Boot is enabled, checking which certificates are trusted, following guidance from the relevant operating system vendor, and following guidance from the hardware vendor or VM provider. This is why the right answer for any specific system depends on its operating system vendor, hardware vendor, and platform. This post explains the model. Only those vendors can tell you what is supported for your systems. What to check The exact commands vary by operating system vendor, package set, and platform. Treat the examples below as illustrations, not guaranteed instructions for every Linux system. IT departments should validate commands against vendor documentation before using them in production automation. At fleet scale, the useful starting point is an inventory rather than a one-time manual check. Useful fields include whether Secure Boot is enabled, which Microsoft UEFI CAs are present in the firmware trust database, which CA signed the installed shim, the operating system release, the hardware model or VM platform, the update channel, and whether the system comes from a custom image or vendor image. Set up representative canary systems before any broad rollout. A canary set should cover the differences that matter in your fleet: hardware model, VM platform, operating system release, image lineage, and update channel. The aim is to avoid discovering a firmware or shim mismatch for the first time during a broad production update, not to build a new certification program. First, check whether Secure Boot is enabled: sudo mokutil --sb-state If Secure Boot is disabled, this certificate transition does not affect that system's current boot path. Next, check which Microsoft UEFI CAs are in the firmware trust database: sudo mokutil --db Look for entries such as: Microsoft Corporation UEFI CA 2011 Microsoft UEFI CA 2023 If both are present, the system is prepared for a future 2023-signed shim. If only the 2011 CA is present, check guidance from the relevant operating system vendor and platform provider before accepting a 2023-only shim update. On physical systems, also check whether the platform relies on signed third-party option ROMs. Those may require the Microsoft Option ROM UEFI CA 2023 in addition to the Microsoft UEFI CA 2023 used for boot applications. This is another reason hardware guidance can vary by model. Administrators can also inspect the signature on the shim currently installed on a system. On Enterprise Linux and related distributions, pesign is often used: sudo dnf install pesign sudo pesign -S -i /boot/efi/EFI/<vendor-or-distribution>/shimx64.efi On Debian, Ubuntu, and related distributions, sbverify from sbsigntools is often used: sudo apt install sbsigntools sudo sbverify --list /boot/efi/EFI/<vendor-or-distribution>/shimx64.efi The path to shim may differ. Some systems use a different EFI path, a different architecture suffix, or a different bootloader arrangement. Vendor documentation is the right source for exact commands. How updates may be delivered Many operating system vendors use the Linux Vendor Firmware Service (LVFS) and fwupd for firmware-related updates, including some UEFI Secure Boot database updates. Not every vendor enables the same tooling, and not every platform supports the same update mechanism. Common examples include: sudo fwupdmgr update sudo fwupdmgr security sudo fwupdmgr get-devices Some systems may require a firmware update from the hardware vendor. Some may support a standalone UEFI database update. Some may not support a safe standalone update at all. Some hardware and firmware vendors block standalone database updates because earlier failures showed that the update could break systems. Updating the Secure Boot allowed signature database ( db ) also depends on authorization from keys in KEK . That is one reason these updates often require cooperation from the firmware, hardware, or VM platform vendor. Administrators should not assume that possession of a certificate file is enough to update a system safely. Do not force a Secure Boot database update just because a command exists. Follow the guidance for the specific hardware, VM platform, or operating system vendor. Forcing an update can force a physical reboot of a machine or destroy the system. After the first inventory pass, keep watching the operating system vendor's security advisories and bootloader package updates. Questions for your vendors The right questions depend on the system, but these are the kinds of answers IT departments should look for from operating system vendors, hardware vendors, and VM providers: Does this operating system release currently ship a 2011-signed, 2023-signed, or dual-signed shim? If the vendor plans to ship a 2023-only shim, will the update process check whether the system trusts the 2023 CA before installing it? How is the Microsoft UEFI CA 2023 delivered for this hardware model, VM platform, or image? Is a standalone Secure Boot database update supported, or must the update arrive through a firmware update? Does support vary by hardware model, firmware version, VM generation, image type, or operating system release? What should administrators monitor for shim, GRUB, SBAT, db , KEK , or dbx updates related to this transition? What is the recommended validation path before broad deployment? What is the supported recovery path if a system receives an incompatible shim or firmware update and fails to boot? What to do now If an IT department administers Linux systems that use Secure Boot, the useful work is straightforward: Use the checks above to inventory Secure Boot state, trusted CAs, and installed shim signatures across representative systems. Identify the parts of the fleet most likely to diverge from default vendor paths, including older hardware, long-lived VMs, older operating system releases, custom images, and pinned bootloader packages. Read operating system, hardware, and VM provider guidance before accepting 2023-only shim updates or applying firmware and Secure Boot database updates. Test representative canary systems before rolling out shim or firmware changes broadly. Monitor operating system vendor advisories for shim and bootloader updates related to the transition. Avoid forcing low-level firmware or UEFI variable updates unless vendor guidance says to do so. How Linux got here UEFI Secure Boot was introduced to let firmware verify boot components before executing them. The firmware contains a trust database. If a bootloader is signed by a trusted certificate and is not blocked by revocation policy, the firmware can execute it. In the PC ecosystem, Microsoft has long operated the signing infrastructure used by Windows and by many third-party UEFI boot components. Linux operating system vendors do not have Microsoft sign the Linux kernel directly. Instead, they use a small first-stage bootloader called shim. The Linux shim is signed by Microsoft so firmware will start it. The shim then validates the next boot component, usually GRUB or another vendor-controlled bootloader, using keys controlled by the operating system vendor, not Microsoft. That structure lets Linux operating system vendors participate in the UEFI Secure Boot ecosystem while keeping control over their own boot chains. The shim code is developed publicly, and shim signing uses the community-run shim-review process before the Microsoft signing step. That split is important. The Linux community reviews shim submissions, and Microsoft operates the signing service that applies a signature firmware will trust. The certificate rotation affects this first handoff. Firmware must trust the CA that signed shim. If a future shim is signed only by the 2023 CA, the firmware needs the 2023 CA in its trust database. A system that keeps booting with a 2011-signed shim is not automatically broken or insecure on the expiration date. A system that moves to a 2023-signed shim needs to trust the 2023 CA; plan for that transition.Four open source projects to explore at Microsoft Build
Open source is where developers experiment, collaborate, and turn new ideas into tools that others can build on. At Microsoft Build, we’re creating a dedicated space for that energy: the Open Source Zone. This year, the Open Source Zone will bring together maintainers, contributors, and developers working on some of the most interesting open source projects in AI. Whether you’re building agents, experimenting with local models, exploring prompt workflows, or looking for practical ways to bring AI into your development process, this is a place to meet the people behind the projects and see what they’re building. The Open Source Zone is inspired by similar community spaces we’ve hosted at GitHub Universe: hands-on, conversation-driven, and centered on the people and projects moving open source forward. Meet the projects OpenClaw OpenClaw, originally Clawbot, formerly Clawdbot and briefly Moltbot,before landing on its current name (because naming is hard), is a personal AI assistant project built for developers who want more control over how AI agents run across tools, devices, and workflows. Its repository describes it as “your own personal AI assistant” across operating systems and platforms, with support for agent workspaces, skills, and device nodes. It has also become one of the fastest-growing open source projects on GitHub, with over 370,000 stars to date. At the Open Source Zone, attendees can learn how OpenClaw approaches personal agents, extensibility, and local-first experimentation. AutoGPT AutoGPT is one of the best-known open source projects in the autonomous agent space. The project’s mission is to make AI accessible for everyone to use and build on, with tools for building, testing, and delegating work to agents. Visit AutoGPT in the Open Source Zone to learn how the project is evolving agent development, benchmarking, frontend experiences, and practical workflows for building agent-powered applications. Come for the autonomous agents; stay for the very human maintainers. AutoGPT is also a member of GitHub’s Secure Open Source Fund, with a goal of enhancing AI security across the open source ecosystem. Open WebUI Open WebUI is a self-hosted, extensible AI platform for working with large language models. The project supports Ollama and OpenAI-compatible APIs and includes built-in RAG capabilities, making it a strong option for developers and organizations exploring local, private, or provider-flexible AI experiences. At Build, the Open WebUI team will show how developers can run, customize, and extend AI interfaces for their own environments. prompts.chat prompts.chat, formerly Awesome ChatGPT Prompts, is a curated collection of prompt examples for AI chat models. The project is designed to help people discover, share, and build better prompts for modern AI assistants. Created by Fatih Kadir Akın, a GitHub Star from Istanbul, prompts.chat reflects his work at the intersection of open source, developer education, and AI-assisted development. Fatih leads Developer Relations at Teknasyon, has authored books on JavaScript and prompt engineering, and is active in the community as a speaker, organizer, and contributor. Stop by to explore prompt libraries, prompt engineering resources, self-hosting options, and ways the community is making prompting more reusable and collaborative. Register for Microsoft Build Microsoft Build takes place June 2–3, 2026, in San Francisco and online. In-person passes are available, and online registration is free for livestreamed keynote and select session access. Register for Microsoft Build and come visit the Open Source Zone to meet the teams behind OpenClaw, AutoGPT, Open WebUI, and prompts.chat. We’ll see you there. <3Azure Image Testing for Linux (AITL)
As cloud and AI evolve at an unprecedented pace, the need to deliver high-quality, secure, and reliable Linux VM images has never been more essential. Azure Image Testing for Linux (AITL) is a self-service validation tool designed to help developers, ISVs, and Linux distribution partners ensure their images meet Azure’s standards before deployment. With AITL, partners can streamline testing, reduce engineering overhead, and ensure compliance with Azure’s best practices, all in a scalable and automated manner. Let’s explore how AITL is redefining image validation and why it’s proving to be a valuable asset for both developers and enterprises. Before AITL, image validation was largely a manual and repetitive process, engineers were often required to perform frequent checks, resulting in several key challenges: Time-Consuming: Manual validation processes delayed image releases. Inconsistent Validation: Each distro had different methods for testing, leading to varying quality levels. Limited Scalability: Resource constraints restricted the ability to validate a broad set of images. AITL addresses these challenges by enabling partners to seamlessly integrate image validation into their existing pipelines through APIs. By executing tests within their own Azure subscriptions prior to publishing, partners can ensure that only fully validated, high-quality Linux images are promoted to production in the Azure environment. How AITL Works? AITL is powered by LISA, which is a test framework and a comprehensive opensource tool contains 400+ test cases. AITL provides a simple, yet powerful workflow run LISA test cases: Registration: Partners register their images in AITL’s validation framework. Automated Testing: AITL runs a suite of predefined validation tests using LISA. Detailed Reporting: Developers receive comprehensive results highlighting compliance, performance, and security areas. All test logs are available to access. Self-Service Fixes: Any detected issues can be addressed by the partner before submission, eliminating delays and back-and-forth communication. Final Sign-Off: Once tests pass, partners can confidently publish their images, knowing they meet Azure’s quality standards. Benefits of AITL AITL is a transformative tool that delivers significant benefits across the Linux and cloud ecosystem: Self-Service Capability: Enables developers and ISVs to independently validate their images without requiring direct support from Microsoft. Scalable by Design: Supports concurrent testing of multiple images, driving greater operational efficiency. Consistent and Standardized Testing: Offers a unified validation framework to ensure quality and consistency across all endorsed Linux distributions. Proactive Issue Detection: Identifies potential issues early in the development cycle, helping prevent costly post-deployment fixes. Seamless Pipeline Integration: Easily integrates with existing CI/CD workflows to enable fully automated image validation. Use Cases for AITL AITL designed to support a diverse set of users across the Linux ecosystem: Linux Distribution Partners: Organizations such as Canonical, Red Hat, and SUSE can validate their images prior to publishing on the Azure Marketplace, ensuring they meet Azure’s quality and compliance standards. Independent Software Vendors (ISVs): Companies providing custom Linux Images can verify that their custom Linux-based solutions are optimized for performance and reliability on Azure. Enterprise IT Teams: Businesses managing their own Linux images on Azure can use AITL to validate updates proactively, reducing risk and ensuring smooth production deployments. Current Status and Future Roadmap AITL is currently in private preview, with five major Linux distros and select ISVs actively integrating it into their validation workflows. Microsoft plans to expand AITL’s capabilities by adding: Support for Private Test Cases: Allowing partners to run custom tests within AITL securely. Kernel CI Integration: Enhancing low-level kernel validation for more robust testing and results for community. DPDK and Specialized Validation: Ensuring network and hardware performance for specialized SKU (CVM, HPC) and workloads How to Get Started? For developers and partners interested in AITL, following the steps to onboard. Register for Private Preview AITL is currently hidden behind a preview feature flag. You must first register the AITL preview feature with your subscription so that you can then access the AITL Resource Provider (RP). These are one-time steps done for each subscription. Run the “az feature register” command to register the feature: az feature register --namespace Microsoft.AzureImageTestingForLinux --name JobandJobTemplateCrud Sign Up for Private Preview – Contact Microsoft’s Linux Systems Group to request access. Private Preview Sign Up To confirm that your subscription is registered, run the above command and check that properties.state = “Registered” Register the Resource Provider Once the feature registration has been approved, the AITL Resource Provider can be registered by running the “az provider register” command: az provider register --namespace Microsoft.AzureImageTestingForLinux *If your subscription is not registered to Microsoft.Compute/Network/Storage, please do so. These are also prerequisites to using the service. This can be done for each namespace (Microsoft.Compute, Microsoft.Network, Microsoft.Storage) through this command: az provider register --namespace Microsoft.Compute Setup Permissions The AITL RP requires a permission set to create test resources, such as the VM and storage account. The permissions are provided through a custom role that is assigned to the AITL Service Principal named AzureImageTestingForLinux. We provide a script setup_aitl.py to make it simple. It will create a role and grant to the service principal. Make sure the active subscription is expected and download the script to run in a python environment. https://raw.githubusercontent.com/microsoft/lisa/main/microsoft/utils/setup_aitl.py You can run the below command: python setup_aitl.py -s "/subscriptions/xxxx" Before running this script, you should check if you have the permission to create role definition in your subscription. *Note, it may take up to 20 minutes for the permission to be propagated. Assign an AITL jobs access role If you want to use a service principle or registration application to call AITL APIs. The service principle or App should be assigned a role to access AITL jobs. This role should include the following permissions: az role definition create --role-definition '{ "Name": "AITL Jobs Access Role", "Description": "Delegation role is to read and write AITL jobs and job templates", "Actions": [ "Microsoft.AzureImageTestingForLinux/jobTemplates/read", "Microsoft.AzureImageTestingForLinux/jobTemplates/write", "Microsoft.AzureImageTestingForLinux/jobTemplates/delete", "Microsoft.AzureImageTestingForLinux/jobs/read", "Microsoft.AzureImageTestingForLinux/jobs/write", "Microsoft.AzureImageTestingForLinux/jobs/delete", "Microsoft.AzureImageTestingForLinux/operations/read", "Microsoft.Resources/subscriptions/read", "Microsoft.Resources/subscriptions/operationresults/read", "Microsoft.Resources/subscriptions/resourcegroups/write", "Microsoft.Resources/subscriptions/resourcegroups/read", "Microsoft.Resources/subscriptions/resourcegroups/delete" ], "IsCustom": true, "AssignableScopes": [ "/subscriptions/01d22e3d-ec1d-41a4-930a-f40cd90eaeb2" ] }' You can create a custom role using the above command in the cloud shell, and assign this role to the service principle or the App. All set! Please go through a quick start to try AITL APIs. Download AITL wrapper AITL is served by Azure management API. You can use any REST API tool to access it. We provide a Python wrapper for better experience. The AITL wrapper is composed of a python script and input files. It calls “az login” and “az rest” to provide similar experience like the az CLI. The input files are used for creating test jobs. Make sure az CLI and python 3 are installed. Clone LISA code, or only download files in the folder. lisa/microsoft/utils/aitl at main · microsoft/lisa (github.com). Use the command below to check the help text. python -m aitl job –-help python -m aitl job create --help Create a job Job creation consists of two entities: A job template and an image. The quickest way to get started with the AITL service is to create a Job instance with your job template properties in the request body. Replace placeholders with the real subscription id, resource group, job name to start a test job. This example runs 1 test case with a marketplace image using the tier0.json template. You can create a new json file to customize the test job. The name is optional. If it’s not provided, AITL wrapper will generate one. python -m aitl job create -s {subscription_id} -r {resource_group} -n {job_name} -b ‘@./tier0.json’ The default request body is: { "location": "westus3", "properties": { "jobTemplateInstance": { "selections": [ { "casePriority": [ 0 ] } ] } } } This example runs the P0 test cases with the default image. You can choose to add fields to the request, such as image to test. All possible fields are described in the API Specification – Jobs section. The “location” property is a required field that represents the location where the test job should be created, it doesn’t affect the location of VMs. AITL supports “westus”, “westus2”, or “westus3”. The image object in the request body json is where the image type to be used for testing is detailed, as well as the CPU architecture and VHD Generation. If the image object is not included, LISA will pick a Linux marketplace image that meets the requirements for running the specified tests. When an image type is specified, additional information will be required based on the image type. Supported image types are VHD, Azure Marketplace image, and Shared Image Gallery. - VHD requires the SAS URL. - Marketplace image requires the publisher, offer, SKU, and version. - Shared Image Gallery requires the gallery name, image definition, and version. Example of how to include the image object for shared image gallery. (<> denotes placeholder): { "location": "westus3", “properties: { <...other properties from default request body here>, "image": { "type": "shared_gallery", "architecture": "x64", "vhdGeneration": 2, "gallery": "<Example: myAzureComputeGallery>", "definition": "<Example: myImage1>", "version": "<Example: 1.0.1>" } } } Check Job Status & Test Results A job is an asynchronous operation that is updated throughout the job’s lifecycle with its operation and ongoing tests status. A job has 6 provisioning states – 4 are non-terminal states and 2 are terminal states. Non-terminal states represent ongoing operation stages and terminal states represent the status at completion. The job’s current state is reflected in the `properties.provisioningState` property located in the response body. The states are described below: Operation States State Type Description Accepted Non-Terminal state Initial ARM state describing the resource creation is being initialized. Queued Non-Terminal state The job has been queued by AITL to run LISA using the provided job template parameters. Scheduling Non-Terminal state The job has been taken off the queue and AITL is preparing to launch LISA. Provisioning Non-Terminal state LISA is creating your VM within your subscription using the default or provided image. Running Non-Terminal state LISA is running the specified tests on your image and VM configuration. Succeeded Terminal state LISA completed the job run and has uploaded the final test results to the job. There may be failed test cases. Failed Terminal state There was a failure during the job’s execution. Test results may be present and reflect the latest status for each listed test. Test results are updated in near real-time and can be seen in the ‘properties.results’ property in the response body. Results will begin to get updated during the “Running” state and the final set of result updates will happen prior to reaching a terminal state (“Completed” or “Failed”). For a complete list of possible test result properties, go to the API Specification – Test Results section. Run below command to get detailed test results. python -m aitl job get -s {subscription_id} -r {resource_group} -n {job_name} The query argument can format or filter results by JMESquery. Please refer to help text for more information. For example, List test results and error messages. python -m aitl job get -s {subscription_id} -r {resource_group} -n {job_name} -o table -q 'properties.results[].{name:testName,status:status,message:message}' Summarize test results. python -m aitl job get -s {subscription_id} -r {resource_group} -n {job_name} -q 'properties.results[].status|{TOTAL:length(@),PASSED:length([?@==`"PASSED"`]),FAILED:length([?@==`"FAILED"`]),SKIPPED:length([?@==`"SKIPPED"`]),ATTEMPTED:length([?@==`"ATTEMPTED"`]),RUNNING:length([?@==`"RUNNING"`]),ASSIGNED:length([?@==`"ASSIGNED"`]),QUEUED:length([?@==`"QUEUED"`])}' Access Job Logs To access logs and read from Azure Storage, the AITL user must have “Storage Blob Data Owner” role. You should check if you have the permission to create role definition in your subscription, likely with your administrator. For information on this role and instructions on how to add this permission, see this Azure documentation. To access job logs, send a GET request with the job name and use the logUrl in the response body to retrieve the logs, which are stored in Azure storage container. For more details on interpreting logs, refer to the LISA documentation on troubleshooting test failures. To quickly view logs online (note that file size limitations may apply), select a .log Blob file and click "edit" in the top toolbar of the Blob menu. To download the log, click the download button in the toolbar. Conclusion AITL represents a forward-looking approach to Linux image validation bringing automation, scalability, and consistency to the forefront. By shifting validation earlier in the development cycle, AITL helps reduce risk, accelerate time to market, and ensure a reliable, high-quality Linux experience on Azure. Whether you're a developer, a Linux distribution partner, or an enterprise managing Linux workloads on Azure, AITL offers a powerful way to modernize and streamline your validation workflows. To learn more or get started with AITL or more details and access to AITL, reach out to Microsoft Linux Systems GroupFrom Compliance to Auto-Remediation: Azure's Latest Linux Security Innovations
We are pleased to announce that the Azure security baseline through Azure Policy and Machine Configuration for Linux has moved to public preview, and we are expanding the capabilities with built-in auto-remediation feature (limited public preview). Customers face increasing pressure to comply with requirements set by governments, regulatory bodies, or specific industries. As their environments become more complex and hybrid, achieving and maintaining compliance on a large scale remains challenging and problematic. Failing to meet compliance goals can result in substantial business harm, including financial penalties and the potential loss of customers. Introducing enhanced audit and the new auto-remediation experience: Recognizing the above-mentioned challenges, Microsoft has developed a solution to help customers navigate these complexities at ease. The Azure security baseline for Linux offers compliance and built-in auto-remediation (limited public preview) features via Azure Policy’s Machine Configuration and Microsoft’s open-source Azure-OSconfig engine. The combination of these capabilities will ensure that security is embedded by design and compliance requirements are upheld, whether workloads operate in the cloud, on-premises, or in another CSP environment, through the Azure Arc platform. Thanks to the new approach we provide detailed information about the state of compliance and more accurate results with detailed descriptions with direct reference to the CIS rule definitions. Furthermore, the new architecture has enabled us to implement and provide automatic remediation capabilities against the security baseline providing a Linux-native experience for our customers when it comes to hardening. Microsoft has implemented a streamlined version of Linux security best practices, primarily based on the latest CIS (Center for Internet Security) Distribution Independent Linux benchmark. All the audit and remediation results are available and can be queried within the Azure Resource Graph Explorer for reporting and monitoring purposes. As security is Microsoft’s top priority, we will provide these capabilities at no additional cost to our customers, with charges only applying to the Azure Arc managed workloads hosted on-premises or other CSP environments. What’s next: At Microsoft we strive to continuously improve customer satisfaction - understanding that a one-size-fits-all approach is not feasible for hardening and security, we are committed to working with our customers throughout the preview process to improve the end-to-end experience. In addition to that, Microsoft is committed to evolve and further develop and deliver new security baseline contents to be fully aligned with the latest CIS standards across various Linux distributions and will collaborate with the relevant standard bodies to contribute to the standards, benefiting both the broader community and the wider industry. Stay tuned in this space for more information - exciting news to come in the upcoming months! What happens with the existing Azure security baseline for Linux capability: Every VM customer which has the “Linux machines should meet requirements for the Azure compute security baseline” policy definition assigned will be auto migrated by the Azure team in the upcoming months to the new policy definition. (audit only) We are going to do a gradual rollout of this enhanced capability. For the time being approximately 3-6 months post announcement, the existing policy will still be available and then it will be deprecated and removed from the Azure portal. Learn more: Sign-up form for the auto-remediation capability Read more about Azure Arc Check out the Azure osconfig’s GitHub repo Comparison between old and new baseline is attached to the blog List of supported operating systems (check the Linux distros in the table)How Microsoft Ensures the Quality of Linux VM Images and Platform Experiences on Azure?
In the continuously evolving landscape of cloud computing and AI, the quality and reliability of virtual machines (VMs) plays vital role for businesses running mission-critical workloads. With over 65% of Azure workloads running Linux our commitment to delivering high-quality Linux VM images and platforms remains unwavering. This involves overcoming unique challenges and implementing rigorous validation processes to ensure that every Linux VM image offered on Azure meets the high standards of quality and reliability. Ensuring the quality of Linux images and the overall platform experience on Azure involves addressing the challenges posed by a unique platform stack and the complexity of managing and validating multiple independent release cycles. High-quality Linux VMs are essential for ensuring consistent performance, minimizing downtime and regressions, and enhancing security by addressing vulnerabilities with timely updates. Figure 1: Complexity of Linux VMs in Azure VM Image Updates: Azure's Marketplace offers a diverse array of Linux distributions, each maintained by its respective publishers. These distributions release updates on their own schedules, independent of Azure's infrastructure updates. Package Updates: Within each Linux distribution, numerous packages are maintained and updated separately, adding another layer of complexity to the update and validation process. Extension and Agent Updates: Azure provides over 75+ guest VM extensions to enhance operating system capabilities, security, recovery etc. These extensions are updated independently, requiring careful validation to ensure compatibility and stability. Azure Infrastructure Updates: Azure regularly updates its underlying infrastructure, including components like Azure Boost, to improve reliability, performance, and security. VM SKUs and Sizes: Azure provides thousands of VM sizes with various combinations of CPU, memory, disk, and network configurations to meet diverse customer needs. Managing concurrent updates across all VMs poses significant QA challenges. To address this, Azure uses rigorous testing, gating and validation processes to ensure all components function reliably and meet customer expectations. Azure’s Approach to Overcoming Challenges To address these challenges, we have implemented a comprehensive validation strategy that involves testing at every stage of the image and kernel lifecycle. By adopting a shift-left approach, we execute Linux VM-specific test cases as early as possible. This strategy helps us catch failures close to the source of changes before they are deployed to Azure fleet. Our validation gates integrate with various entry points and provide coverage for a wide variety of scenarios on Azure. Upstream Kernel Validation: As a founding member of Kernel CI, Microsoft validates commits from Linux next and stable trees using Linux VMs in Azure and shares results with the community via Kernel CI DB. This enables us to detect regressions at early stages. Azure-Tuned Kernel Validation: Azure-Tuned Kernels provided by our endorsed distribution partners are thoroughly validated and signed off by Microsoft before it is released to the Azure fleet. Linux Guest Image Validation: The quality team works with endorsed distribution partners for major releases to conduct thorough validation. Each refreshed image, including those from third-party publishers, is validated and certified before being added to the marketplace. Automated pipelines are in place to validate the images once they are available in the Marketplace. Package Validation: Unattended Update: We conduct validation of packages updates with target distro to prevent regression and ensure that only tested snapshots are utilized for updating Linux VM in Azure. Guest Extension Validation: Every Azure-provided extensions undergoes Basic Validation Testing (BVT) across all images and kernel versions to ensure compatibility and functionality amidst any changes. Additionally, comprehensive release testing is conducted for major releases to maintain reliability and compatibility. New VM SKU Validation: Any new VM SKU undergoes validation to confirm it supports Linux before its release to the Azure fleet. This process includes functionality, performance and stress testing across various Linux distributions, and compatibility tests with existing Linux images in the fleet. Azure HostOS & Host Agent Validation: Updates to the Azure Host OS & Agents are thoroughly tested from the Linux guest OS perspective to confirm that changes in the Azure host environment do not result in regressions in compatibility, performance, or stability for Linux VMs. At any stage where regressions or bugs are identified, we block those releases to ensure they never reach customers. All issues are resolved and rigorously retested before images, kernels, or extension updates are made available. Through these robust validation processes, Azure ensures that Linux VMs consistently deliver to customer expectations, delivering a reliable, secure, and high-performance environment for mission-critical workloads. Validation Tools for VM Guest Images and Kernel To ensure the quality and reliability of Linux VM images and kernels on Azure, we leverage open-source kernel testing frameworks like LTP, kselftest, and fstest, along with extensive Azure-specific test cases available in LISA, to comprehensively validate all aspects of the platforms. LISA (Linux Integration Services Automation): Microsoft is committed to open source and that is no different with our testing framework LISA. LISA is an open-source core testing framework designed to meet all Linux validation needs. It includes over 400 tests covering performance, features and security, ensuring comprehensive validation of Linux images on Azure. By automating diverse test scenarios, LISA enables early detection and resolution of issues, enhancing the stability and performance of Linux VMs. Conclusion At Azure, Linux quality is a fundamental aspect of our commitment to delivering reliable VM images and platforms. Through comprehensive testing and strong collaboration with Linux distribution partners, we ensure quality and reliability of VMs while proactively identifying and resolving potential issues. This approach allows us to continually refine our processes and maintain the quality that customers expect from Azure. Quality is a core focus, and we remain dedicated to continuous improvement, delivering world-class Linux environments to businesses and customers. For us, quality is not just a priority—it’s our standard. Your feedback is invaluable, and we would greatly appreciate your insights.
