Linux on Azure at Microsoft Ignite 2025: What’s New, What to Attend, and Where to Find Us
Microsoft Ignite 2025 is almost here, and we’re heading back to San Francisco from November 17-21 with a full digital experience for those joining online. Every year, Ignite brings together IT pros, developers, security teams, and technology leaders from around the world to explore the future of cloud, AI, and infrastructure. This year, Linux takes center stage in a big way. From new security innovations in Azure Linux to deeper AKS modernization capabilities and hands-on learning opportunities, Ignite 2025 is packed with content for anyone building, running, or securing Linux-based workloads in Azure. Below is your quick guide to the biggest Linux announcements and the must-see sessions. Major Linux Announcements at Ignite 2025 Public Preview: Built-in CIS Benchmarks for Azure Endorsed Linux Distributions CIS Benchmarks are now integrated directly into Azure Machine Configuration, giving you automated and customizable compliance monitoring across Azure, hybrid, and on-prem environments. This makes it easier to continuously govern your Linux estate at scale with no external tooling required. Public Preview: Azure Linux OS Guard Azure Linux OS Guard introduces a hardened, immutable Linux container host for AKS with FIPS mode enforced by default, a reduced attack surface, and tight AKS integration. It is ideal for highly regulated or sensitive workloads and brings stronger default security with less operational complexity. General Availability: Pod Sandboxing for AKS (Kata Containers) Pod Sandboxing with fully managed Kata Containers is now GA, delivering VM-level isolation for AKS workloads. This provides stronger separation of CPU, memory, and networking and is well-suited for multi-tenant applications or organizations with strict compliance boundaries. Linux Sessions at Ignite Whether you are optimizing performance, modernizing with containers, or exploring new security scenarios, there is something for every Linux practitioner. Breakout Sessions Session Code Session Name Date and Time (PST) BRK143 Optimizing performance, deployments, and security for Linux on Azure Thu Nov 20, 1:00 PM to 1:45 PM BRK144 Build, modernize, and secure AKS workloads with Azure Linux Wed Nov 19, 1:30 PM to 2:15 PM BRK104 From VMs and containers to AI apps with Azure Red Hat OpenShift Thu Nov 20, 8:30 AM to 9:15 AM BRK137 Nasdaq Boardvantage: AI-driven governance on PostgreSQL and AI Foundry Wed Nov 19, 11:30 AM to 12:15 PM Theatre Sessions Session Code Session Name Date and Time (PST) THR712 Hybrid workload compliance from policy to practice on Azure Tue Nov 18, 3:15 PM to 3:45 PM THR701 From Container to Node: Building Minimal-CVE Solutions with Azure Linux Wed Nov 19, 3:30 PM to 4:00 PM Hands-on Lab Lab 505: Fast track your Linux and PostgreSQL migration with Azure Migrate Tue Nov 18, 4:30 PM to 5:45 PM Wed Nov 19, 3:45 PM to 5:00 PM Thu Nov 20, 9:00 AM to 10:15 AM This interactive lab helps you assess, plan, and execute Linux and PostgreSQL migrations at scale using Azure Migrate’s end-to-end tooling. Meet the Linux on Azure Team at Ignite If you are attending in person, come say hello. Visit the Linux on Azure Expert Meetup stations inside the Microsoft Hub. You can ask questions directly to Microsoft’s Linux engineering and product experts, explore demos across Azure Linux, compliance, and migration, and get recommendations tailored to your workloads. We always love meeting customers and partners.Dalec: Declarative Package and Container Builds
Build once, deploy everywhere. From a single YAML specification, Dalec produces native Linux packages (RPM, DEB) and container images - no Dockerfiles, no complex RPM spec or control files, just declarative configuration. Dalec, a Cloud Native Computing Foundation (CNCF) Sandbox project, is a Docker BuildKit frontend that enables users to build system packages and container images from declarative YAML specifications. As a BuildKit frontend, Dalec integrates directly into the Docker build process, requiring no additional tools beyond Docker itself.Introducing Image Customizer for Azure Linux
We are excited to release Image Customizer, an open-source tool, built and maintained by the Azure Linux team. Image Customizer lets you customize well-tested existing Azure Linux images for any scenario in just minutes. Already trusted by first party teams like LinkedIn, Azure Frontdoor, and Azure Nexus in production, this tool is designed to make image customization simple, reliable, and fast. With full dm-verity support for enhanced security, it also supports customization of Azure Linux with OS Guard images. Unlike VM-based image customization, Image Customizer directly modifies the image without booting a VM using a chroot-based approach, making customization faster, more reliable, and easier to integrate into existing workflows. ✨ Get Image Customizer here ✨ Explore our documentation here. Why Choose Image Customizer? Direct, Reliable Customization Build on top of bootable, tested, and supported base images. Lower overhead and fewer side effects by avoiding VM boot. No need to rely on the Azure Linux Toolkit. Previously, building from scratch meant your image may fail to boot sometimes. Image Customizer reduces that risk. Clean and Lightweight Minimal dependencies for a streamlined setup (for example, no SSH required). You only need to invoke one command to run Image Customizer. It is available as a container with all its dependencies bundled for easy integration into CI/CD pipelines. Versatile and Powerful Supported input formats: vhd, vhdx, qcow2, PXE bootable artifacts, raw and iso created by Image Customizer. Supported output formats: vhd, vhd-fixed, vhdx, qcow2, raw, iso, and cosi. Perform a wide range of operations: add/remove/update packages, add files and directories, create/update users, enable/disable services, customize partitions, image history, dm-verity and more. Full list of supported operations can be found here. Cross-Platform Compatibility Tested and verified to work on Ubuntu 22.04, Azure Linux 3.0 and WSL2 (Windows Subsystem for Linux). While officially tested on these platforms, Image Customizer will likely work on other Linux distributions as well. Consistent and Predictable Builds Use --package-snapshot-time or snapshotTime to filter packages by publication timestamp, ensuring only packages available at that point in time are considered. This prevents unexpected changes from newer package versions when reusing configuration files across time. Getting Started with Image Customizer To use Image Customizer, you’ll need a configuration file that describes the changes you want to make, using the Declarative API provided by Image Customizer. Next, select a base Azure Linux image as your foundation. With these two pieces in hand, you’re ready to run Image Customizer. The easiest way is to use the Image Customizer container, which comes pre-packaged with all necessary dependencies and is recommended for most users. Alternatively, you can use the standalone executable binary if that better fits your workflow. In just a few minutes, Image Customizer will generate a modified Azure Linux image tailored to your needs. This process is designed to be repeatable and user-friendly, making it easy to add packages, files, users, make partition changes, and much more. To help you get started, we have a Quick Start guide that walks you through your first customization step by step. For those who want to explore further, comprehensive API documentation is available, covering both Command-line usage and Configuration options. Upcoming Community Call Join our upcoming community call to learn more about using Image Customizer and see a live demo. We’ll cover best practices, advanced scenarios, and answer any questions you may have. Date & Time: September 25 th , 2025 at 8:00AM PST Teams Link: Azure Linux - External Community Call | Meeting-Join | Microsoft Teams Community Call Schedule: https://learn.microsoft.com/en-us/azure/azure-linux/support-help#stay-connected-with-azure-linux Help and Feedback If you’d like to report bugs, request features, or contribute to the tool, you can do so directly through our azure-linux-image-tools GitHub repo. We welcome feedback and contributions from the community! Acknowledgements A huge thank you (in no order) to our Image Customizer team ─ Adit Jha, Brian Telfer, Chris Gunn, Deepu Thomas, Elaine Zhao, George Mileka, Himaja Kesari, Jim Perrin, Jiri Appl, Lanze Liu, Roaa Sakr, Kavya Nagalakunta and Vince Perri.
Red Hat Enterprise Linux Billing Meter ID Updates on Azure
Background Following Red Hat's transition to a scalable vCPU-based pricing model in early 2024, Microsoft Azure implemented corresponding pricing updates for RHEL services. As part of ensuring our billing infrastructure fully supports this new pricing structure, we are updating the billing meter IDs for Red Hat Enterprise Linux services to provide better alignment with the current pricing model. What's Changing As part of optimizing our billing infrastructure to fully support Red Hat's updated pricing model, Microsoft Azure is updating the billing meter IDs for Red Hat Enterprise Linux (RHEL) services. These changes ensure our billing system properly accommodates the vCPU-based pricing structure and Reserved Instance functionality. Effective Date: The meter ID migration will begin rolling out on October 2-8, 2025. Impact on Customers Pay-As-You-Go (PAYG) Customers Billing Continuity: Your RHEL instances will continue to operate without any service interruption Meter ID Changes: New meter IDs will appear in your usage reports and cost management statements starting Oct 2-8, 2025 Usage Tracking: Historical usage data remains accessible through existing billing reports Important: No Pricing Impact This meter ID migration has no impact on pricing. Azure already implemented the RHEL pricing changes in early 2024. This meter ID update is purely a technical billing system change and does not affect your costs in any way. For pricing information, see the Pricing - Red Hat Virtual Machines | Microsoft Azure page. Action Required: Update Your Billing Tools To ensure uninterrupted monitoring and reporting, we recommend reviewing and updating the following: Billing Reports and Dashboards Cost Management Reports: Update any custom reports that filter by specific RHEL meter IDs Power BI Dashboards: Refresh data connections and update meter ID filters Third-party Tools: Verify that cost management tools recognize the new meter IDs Budget Alerts and Monitoring Budget Configurations: Review budgets that target specific RHEL services and update meter ID filters Cost Alerts: Ensure automated cost alerts include both old and new meter IDs during the transition period Spending Thresholds: Update any spending controls that rely on meter ID identification Automated Tools and Scripts Cost Analysis APIs: Update API calls that reference specific RHEL meter IDs Automation Scripts: Modify any scripts that process billing data using meter ID filters Integration Tools: Update third-party integrations that rely on meter ID mapping Transition Period Support During the migration period, you may see both old and new meter IDs in your statements. This is expected behavior as the transition occurs gradually across different regions and services. Timeline: October 2-8, 2025: New meter IDs begin appearing for RHEL Pay as you go meters Transition Period: Both old and new meter IDs may appear in billing during migration Completion: Migration will be completed across all regions and services Affected RHEL Meters The following RHEL meter names will be updated with new meter IDs as part of this migration: 1 vCPU VM License 1 vCPU VM License - Free 2 vCPU VM License 4 vCPU VM License 6 vCPU VM License 8 vCPU VM License 12 vCPU VM License 16 vCPU VM License 20 vCPU VM License 24 vCPU VM License 32 vCPU VM License 40 vCPU VM License 44 vCPU VM License 48 vCPU VM License 52-vCPU VM License 60 vCPU VM License 64 vCPU VM License 72 vCPU VM License 80 vCPU VM License 96 vCPU VM License 120 vCPU VM License 128 vCPU VM License 144-vCPU VM License 192 vCPU VM License 192-vCPU VM License 208 vCPU VM License 416 vCPU VM License 420-vCPU VM License These meter changes are tied to the vCPU count, not the VM family - meaning any VM with the same vCPU count (whether D family, E family, etc.) uses the same RHEL license meter. For example, all 2 vCPU VMs use the "2 vCPU VM License" meter regardless of the VM family. If your billing reports, budgets, or automated tools currently filter or reference any of these specific meter names, you'll need to update them to include the new meter IDs once the migration begins. Support and Resources Need Help? Azure Support: Contact Azure Support for technical assistance with billing or meter ID questions Account Team: Reach out to your Microsoft account team for guidance on updating enterprise billing processes Additional Resources: RHEL pricing update details: Red Hat Enterprise Linux Pricing update Azure cost optimization resources can be found here Frequently Asked Questions Q: Will this affect my RHEL instances or their performance? A: No, this is purely a billing system update. Your RHEL instances will continue to operate normally with no performance impact. Q: How can I identify the new meter IDs in my billing? A: New meter IDs will appear in your Cost Management portal and usage reports and cost management statements starting October 2-8, 2025. Watch for updated RHEL service descriptions in your billing details. Q: What if my automated tools stop working? A: Contact Azure Support for assistance. We recommend updating your tools proactively using the meter ID mapping reference provided. We're committed to making this transition as smooth as possible. If you have questions or need assistance, please reach out to Azure Support or your Microsoft account team.
Azure Linux Now Supports AKS Long-Term Support (LTS) Starting with Kubernetes v1.28+
What’s New Managing Kubernetes upgrades can be a challenge for many organizations. The fast-paced release cycle requires frequent cluster updates, which can be time-consuming, carry operational risks, and require repeated validation of workloads and infrastructure. To address this, in April of this year, Azure Kubernetes Service (AKS) introduced Long-Term Support (LTS) on every AKS version — beginning with Kubernetes version 1.28. With AKS LTS, every community-released version of Kubernetes receives an extended support window of an additional year, giving customers more time to test, validate, and adopt new versions at a pace that suits their business needs. The Azure Linux team is excited to announce that Azure Linux now also supports AKS LTS starting with Kubernetes version 1.28 and above. This means you can now pair a stable, enterprise-grade node operating system with the extended lifecycle benefits of AKS LTS — providing a consistent, secure, and well-maintained platform for your container workloads. Benefits of Azure Linux with your AKS LTS Clusters Secure by Design: Azure Linux is built from source using Microsoft’s trusted pipelines, with a minimal package set that reduces the attack surface. It is FIPS-compliant and meets CIS Level 1 benchmarks. Operational Stability: With AKS LTS, each version is supported for two years, reducing upgrade frequency and providing a predictable, stable platform for mission-critical workloads. Reliable Updates: Every package update is validated by both the Azure Linux and AKS teams, running through a full suite of tests to prevent regressions and minimize disruptions. Broad Compatibility: Azure Linux supports AKS extensions, add-ons, and open-source projects. It works seamlessly with existing Linux based containers and includes the upstream containerd runtime. Advanced Isolation: It is the only OS on AKS that supports pod sandboxing, enabling compute isolation between pods for enhanced security. Seamless Migration: Customers can migrate from other distributions to Azure Linux nodepools in-place without recreating clusters, simplifying the process. Getting Started Getting started with Azure Linux on AKS LTS is simple and can be done with a single command. See full documentation on getting started with AKS Long-term Support here. Please note that when enabling LTS on a new Azure Linux cluster you will need to specify --os-sku AzureLinux. Considerations LTS is available on the Premium tier. Refer to the Premium tier pricing for more information. Some add-ons and features might not support Kubernetes versions outside upstream community support windows. View unsupported add-ons and features here. Please note Azure Linux 2.0 is the default node OS for AKS versions v1.27 to v1.31 during both Standard and Long-Term Support. However, Azure Linux 2.0 will reach End of Life during the LTS period of AKS v1.28–v1.31. To maintain support and security updates, customers running Azure Linux 2.0 on AKS v1.28–v1.31 LTS are requested to migrate to Azure Linux 3.0 by November 2025. Azure Linux 3.0 has been validated to support AKS Kubernetes v1.28–v1.31. Before Azure Linux 2.0 goes EoL, AKS will offer a feature to facilitate an in-place migration from Azure Linux 2.0 to 3.0 via a node pool update command. For feature availability and updates, see GitHub issue. After November 2025 Azure Linux 2.0 will no longer receive updates, security patches, or support, which may put your systems at risk. AKS version Azure Linux version during AKS Standard Support Azure Linux version during AKS Long-Term Support 1.27 Azure Linux 2.0 Azure Linux 2.0 1.28 - 1.31 Azure Linux 2.0 Azure Linux 2.0 (migrate to 3.0 by Nov 2025) 1.32+ Azure Linux 3.0 Azure Linux 3.0 For more information on the Azure Linux Container Host support lifecycle see here. How to Keep in Touch with the Azure Linux Team: For updates, feedback, and feature requests related to Azure Linux, there are a few ways to stay connected to the team: We have a public community call every other month for Azure Linux users to come together to ask questions, share learnings, and get updates. Join the next community call on July 24 th at 8AM PST: here Partners with support questions can reach out to AzureLinuxISV@microsoft.comBoost your network performance on Linux VMs on Azure
Imagine running a marathon while wearing ankle weights—that’s what it feels like when your Linux VM struggles with network performance issues. Slow data transfers and bottlenecks can keep your systems from reaching their full potential. But here’s the good news: you don’t need to settle for suboptimal speeds anymore. Power of collaboration Just like a relay race requires teamwork to achieve the best result, optimizing your Linux VM's network performance on Azure works best when you combine tools, techniques, and community insights. By pooling knowledge from system administrators, developers, and Azure experts, you can explore a range of solutions designed to tackle common network challenges. Consider experimenting with adjustments to network buffer settings, congestion control algorithms, and queue disciplines to enhance data throughput and resource efficiency. These suggestions provide a foundation to transform the way your systems handle data traffic, offering opportunities to boost performance. And the best part? Everything is open for customization to suit your needs. Why It Matters In today’s fast-paced world, every second counts. Delays in network performance can mean missed opportunities and wasted resources. By implementing optimizations, you’ll have the chance to achieve: Faster data transfers: Move large files between regions without the headache of constant delays. Improved resource utilization: Handle data traffic more efficiently, reducing wasted bandwidth. Scalability: Make your systems ready to grow with your business needs. Take Action Today Don’t let your systems run with ankle weights any longer. Dive into the technical details and explore the solutions by visiting this link. Whether you’re a seasoned system administrator or a business leader looking for better results, this is your opportunity to collaborate, innovate, and maximize performance. To learn more, read the documentation.
From Kafka to Ray: Deploying AI and Stateful Workloads on AKS with Confidence
Building on our initial announcement for Deploying Open Source Software on Azure, the AKS and the Customer Experience team are excited to announce our expanded library of technical best practice deployment guides for stateful and AI workloads on AKS. These guides are designed to help you accelerate the integration of some of the most critical and heavily adopted open source projects onto Azure, utilizing best practices and optimizations for AKS. For your convenience, you can jump to our collection of Stateful and AI guides at the bottom. To receive updates and read about the other improvements and updates please follow us at the AKS Engineering Blog. In the AKS Engineering Blog, we discuss our updated Postgres guidance with additional storage considerations for data resiliency, performance, or costs using Azure Container Storage. We also highlight our Terraform additions for the Mongo DB and Valkey guides, and the newly developed Azure Verified Module for deploying a production-grade AKS Cluster. Introducing New Guidance Below is a brief overview of each new guide available today. In addition to basic installation steps, the guides detail best practice recommendations on networking, monitoring, and security. The guidance includes initial setup to advanced AKS cluster and node configurations, ensuring applications are successfully deployed with best practices enabled. Deploy Kafka on AKS with Strimzi for Distributed Streaming Apache Kafka is an open source distributed event streaming platform designed to handle high-volume, high-throughput, and real-time streaming data. It is widely used by thousands of companies for mission-critical applications but managing and scaling Kafka clusters on Kubernetes can be challenging. Strimzi simplifies the deployment and management of Kafka on Kubernetes by providing a set of Kubernetes Operators and container images that automate complex Kafka operational tasks. The Kafka on Azure Kubernetes Service (AKS) guide covers essential storage and compute considerations, ensuring you Kafka deployment meets your needs. Additionally, we provide guidance for tuning the Java Virtual Machine (JVM), which is critical for optimal Kafka broker and controller performance. Deploy Airflow on AKS for Workflow Orchestration Apache Airflow is a widely adopted open source workflow orchestrator often used for ETL processes, data pipeline management, and task automation. Despite its interoperability and importance, deploying Airflow on Kubernetes is very complex. As best practice, we recommend installing Airflow using the community-maintained Helm Chart. Deploying Apache Airflow on Azure Kubernetes Service (AKS), provides step-by-step instructions for installing the Helm Chart, configuring the Azure Container Registry and setting up user-assigned managed identities. Additionally, we provide recommendations on adjusting default configurations to optimize Airflow on AKS. Deploy Ray on AKS for Distributed Computing Ray is an open source framework for distributed computing, allowing both Python applications and common machine learning workloads to be parallelized and distributed efficiently. The Ray on Azure Kubernetes Service (AKS) guide details how to configure the underlying infrastructure and deploy KubeRay, the Ray Kubernetes Operator. KubeRay is the best way to deploy and managed Ray on AKS as it provides a Kubernetes-native way to manage Ray clusters. Additionally, this guide includes two illustrative samples: one for distributed training and another for fine-tuning. The distributed training example demonstrates a PyTorch model trained on Fashion MNIST using Ray Train on AKS. The fine-tuning example showcases how to tune the GPT-2 large model using KubeRay in combination with Azure Blob Storage and BlobFuse. Deploy open source technologies on Azure Apache Airflow - Create the infrastructure for deploying Apache Airflow on Azure Kubernetes Service (AKS) Apache Kafka - Prepare the infrastructure for deploying Kafka on Azure Kubernetes Service (AKS) Ray - Deploy a Ray cluster on Azure Kubernetes Service (AKS) Valkey - Create the infrastructure for running a Valkey cluster on Azure Kubernetes Service (AKS) Mongo DB - Create the infrastructure for running a MongoDB cluster on Azure Kubernetes Service (AKS) Postgres - Create infrastructure for deploying a highly available PostgreSQL database on AKS Kubernetes AI Toolchain Operator (KAITO) - Deploy KAITO on AKS using TerraformHow Pulp powers Microsoft's Linux Software Repositories
PMC, the backbone of Microsoft’s Linux Software Delivery Microsoft's mission is "to empower every person and organization on the planet to achieve more" - across all platforms. To support this, Microsoft provides PMC (packages.microsoft.com), a key service for distributing Microsoft software products for Linux; and a critical service for Microsoft's Linux Distributions and secure software. PMC is a critical part of Azure Core’s Linux infrastructure. It handles the ingestion and distribution of Linux packages from Microsoft, serving both internal Microsoft teams and external customers. For example, PMC hosts packages from Microsoft that support Azure Linux, Azure Security Pack, .NET, VSCode, and Edge Browser, to name a few. PMC delivers packages via standard Linux package managers, apt (Debian/Ubuntu), dnf/yum (RHEL, Fedora, CentOS), and zypper (SUSE), along with necessary config files and keys. PMC’s Evolution with Pulp The PMC team is responsible for operating and maintaining the infrastructure which replicates and serves published packages, manages repositories, and controls publishing access. At the heart of PMC’s infrastructure is Pulp, an enterprise-grade, open-source platform for managing software repositories. Before adopting Pulp, PMC relied on a custom-built, in-house application deployed across virtual machines (VM’s) in multiple regions. Due to the entirely custom and aging nature of the infrastructure it was becoming increasingly difficult to maintain and prone to outages. Transitioning to Pulp enabled PMC to also modernize its architecture by leveraging best-in-class Azure Services: Azure Blob Storage for scalable package and metadata storage, Azure Kubernetes Service for improved application scalability and availability, and Azure Front Door (AFD) for global content delivery. This shift has significantly enhanced service reliability and operational efficiency. Pulp was initially developed by Red Hat to manage RPM packages - handling tasks like fetching, uploading, organizing, and distributing them. Over time, it evolved into a plugin-based system that now supports additional package types, including Debian packages. By integrating Pulp with Azure’s capabilities, PMC achieved greater service stability, reduced dependency on legacy tooling, minimized rate-limiting issues, and gained a more scalable, maintainable solution. Its flexibility and robustness made Pulp the clear choice, allowing the team to focus on delivering packages to users in hundreds of countries, rather than maintaining a bespoke system. Better Together: How PMC and Pulp Serve Microsoft Customers Pulp manages uploaded artifacts, repositories of content, and metadata for the apt/dnf clients. PMC is best thought of as two tightly integrated components working with a shared database and blob store. Content Ingress: API which handles CRUD operations of repos and packages Content Egress: Delivering packages and associated metadata to customers The PMC API manages user authentication and security enforcement in front of the Pulp backend while AFD caches and serves content stored by Pulp in blob storage. Everything in between is handled by Pulp. Together, these components form a secure, scalable, and globally accessible platform for distributing Debian and RPM packages to both internal Microsoft teams and external users. Figure 1: Content Ingress Architectural Diagram Figure 2: Content Egress Architectural Diagram (Click to enlarge) Package Quality Assurance at Scale Before any package is published, PMC performs a signature check. PMC also provides publishers with a package quality container to scan their packages. This scanning check is currently being integrated directly into PMC to streamline quality assurance. While Pulp handles core metadata curation and repository management, PMC extends this with additional quality gates and validations tailored to Microsoft’s ecosystem. High Availability Pulp, as the origin, provides a container-based solution that we run on Azure Kubernetes Service (AKS). PMC then leverages AFD to replicate content across a global mirror fleet, ensuring fast, reliable access to packages regardless of customer location. Monitoring and Observability Pulp provides a tasking system that PMC monitors for failures. PMC also supplements this tasking system by monitoring our own logs and synthetics to ensure service reliability. We monitor the edge as it reflects the customer experience whereas origin monitoring focuses on the internal health of PMC components. As a result, PMC has comprehensive monitoring, both at the edge and internally, to gain deeper insights into the overall health and performance of its service. Secure and Reliable Package Delivery PMC ensures that packages are delivered with integrity. If a package fails to download or has a checksum mismatch, PMC helps diagnose and resolve the issue. Using the Pulp feature, Checkpoints, PMC enables snapshotting for limited distros, allowing customers to lock into known-good states for safe deployments. Partnering with the Pulp Community In addition to leveraging Pulp, the PMC team actively contributes to and engages with the broader Pulp community. We regularly contribute to upstream Pulp by submitting bug fixes, reporting issues to Pulp's GitHub issue tracker, and developing new features to benefit both PMC and the entire Pulp ecosystem. Below are a few features and smaller improvements the PMC team has contributed back to Pulp: Checkpoint support: Checkpoints allow you to manage and access historical versions of repositories, enhancing your content management capabilities. Checkpoint Support - A Journey Towards Predictable and Consistent Deployments - Pulp Project Pulp-deb apt-by-hash support: Implemented apt-by-hash (also known as Acquire-By-Hash) support in pulp-deb, eliminating errors where clients retrieve inconsistent Debian metadata during repository updates (AptByHash - Ubuntu Wiki). Source Package Support for Debian Plug-in: Collaborated with community contributors to add source package support to the pulp_deb plugin, expanding its capabilities for Debian-based workflows (add source package support to pulp_deb). Redis Caching Improvements: Enhanced Redis caching mechanisms in Pulp to improve performance and reduce latency (Ensure the Redis cache is actually respecting the TTL). Signing Service Enhancements: Delivered improvements to Pulp’s signing service, including better key management and signing workflows (Pass correlation id to signing script through ENV variable). You can learn more about the PMC service (packages.microsoft.com), file issues, pull requests, or report a security vulnerability on the affiliated GitHub repo: Microsoft Linux Package Repositories. Access the most recent packages on https://packages.microsoft.com.Ubuntu Pro FIPS 22.04 LTS on Azure: Secure, compliant, and optimized for regulated industries
Organizations across government (including local and federal agencies and their contractors), finance, healthcare, and other regulated industries running workloads on Microsoft Azure now have a streamlined path to meet rigorous FIPS 140-3 compliance requirements. Canonical is pleased to announce the availability of Ubuntu Pro FIPS 22.04 LTS on the Azure Marketplace, featuring newly certified cryptographic modules. This offering extends the stability and comprehensive security features of Ubuntu Pro, tailored for state agencies, federal contractors, and industries requiring a FIPS-validated foundation on Azure. It provides the enterprise-grade Ubuntu experience, optimized for performance on Azure in collaboration with Microsoft, and enhanced with critical compliance capabilities. For instance, if you are building a Software as a Service (SaaS) application on Azure that requires FedRAMP authorization, utilizing Ubuntu Pro FIPS 22.04 LTS can help you meet specific controls like SC-13 (Cryptographic Protection), as FIPS 140-3 validated modules are a foundational requirement. This significantly streamlines your path to achieving FedRAMP compliance. What is FIPS 140-3 and why does it matter? FIPS 140-3 is the latest iteration of the benchmark U.S. government standard for validating cryptographic module implementations, superseding FIPS 140-2. Managed by NIST, it's essential for federal agencies and contractors and is a recognized best practice in many regulated industries like finance and healthcare. Using FIPS-validated components helps ensure cryptography is implemented correctly, protecting sensitive data in transit and at rest. Ubuntu Pro FIPS 22.04 LTS includes FIPS 140-3 certified versions of the Linux kernel and key cryptographic libraries (like OpenSSL, Libgcrypt, GnuTLS) pre-enabled, which are drop-in replacements for the standard packages, greatly simplifying deployment for compliance needs. The importance of security updates (fips-updates) A FIPS certificate applies to a specific module version at its validation time. Over time, new vulnerabilities (CVEs) are discovered in these certified modules. Running code with known vulnerabilities poses a significant security risk. This creates a tension between strict certification adherence and maintaining real-world security. Recognizing this, Canonical provides security fixes for the FIPS modules via the fips-updates stream, available through Ubuntu Pro. We ensure these security patches do not alter the validated cryptographic functions. This approach aligns with modern security thinking, including recent FedRAMP guidance, which acknowledges the greater risk posed by unpatched vulnerabilities compared to solely relying on the original certified binaries. Canonical strongly recommends all users enable the fips-updates repository to ensure their systems are both compliant and secure against the latest threats. FIPS 140-3 vs 140-2 The new FIPS 140-3 standard includes modern ciphers such as TLS v1.3, as well as deprecating older algorithms like MD5. If you are upgrading systems and workloads to FIPS 140-3, it will be necessary to perform rigorous testing to ensure that applications continue to work correctly. Compliance tooling Included Ubuntu Pro FIPS also includes access to Canonical's Ubuntu Security Guide (USG) tooling, which assists with automated hardening and compliance checks against benchmarks like CIS and DISA-STIG, a key requirement for FedRAMP deployments. How to get Ubuntu Pro FIPS on Azure You can leverage Ubuntu Pro FIPS 22.04 LTS on Azure in two main ways: Deploy the Marketplace Image: Launch a new VM directly from the dedicated Ubuntu Pro FIPS 22.04 LTS listing on the Azure Marketplace. This image comes with the FIPS modules pre-enabled for immediate use. Enable on an Existing Ubuntu Pro VM: If you already have an Ubuntu Pro 22.04 LTS VM running on Azure, you can enable the FIPS modules using the Ubuntu Pro Client (pro enable fips-updates). Upgrading standard Ubuntu: If you have a standard Ubuntu 22.04 LTS VM on Azure, you first need to attach Ubuntu Pro to it. This is a straightforward process detailed in the Azure documentation for getting Ubuntu Pro. Once Pro is attached, you can enable FIPS as described above. Learn More Ubuntu Pro FIPS provides a robust, maintained, and compliant foundation for your sensitive workloads on Azure. Watch Joel Sisko from Microsoft speak with Ubuntu experts in this webinar Explore all features of Ubuntu Pro on Azure Read details on the FIPS 140-3 certification for Ubuntu 22.04 LTS Official NIST certification link
