Open Standard Enterprise Java and our Secure Future Initiative
Microsoft Azure is the best place for enterprise Java workloads. Whether you are using plain Java SE, Spring Boot and its many sub-projects, or a Jakarta EE and MicroProfile runtime, our portfolio of Java support has first class, framework-native, compute offerings and detailed guidance to give you confidence in your choice of Azure for your mission critical Java workloads. This blog post covers the Jakarta EE and MicroProfile part of our Java on Azure portfolio, and specifically how our Secure Future Initiative (SFI) is supported by Jakarta EE and MicroProfile on Azure. What is Jakarta EE and MicroProfile on Azure? Our product offering for Jakarta EE and MicroProfile on Azure is partner driven and Azure native. We recognize that our partners are the experts in the Java frameworks that power many Fortune 500 companies [boss magazine 2024-10-25]. Microsoft has partnered with Oracle, IBM, and Red Hat to build a portfolio based on two pillars: 1. Azure portal deployment experiences and 2. step-by-step guidance. These Azure portal deployment experiences are Azure-native and are maintained and supported by each partner. The step-by-step guidance shows users exactly how to implement advanced use-cases using the partner’s Jakarta EE and MicroProfile products. Direct links to the portal experiences and guidance are included later in this blog post. The landing page for Jakarta EE and MicroProfile on Azure is at https://aka.ms/java/ee . What is the Secure Future Initiative (SFI) and how does it relate to Jakarta EE and MicroProfile on Azure? The Secure Future Initiative is our name for Microsoft’s comprehensive, top-to-bottom, vision-backed implementation of security for every aspect for all our products. Microsoft has been doing security at scale for half a century, but in November 2023 we launched SFI to give our users and partners a transparent look at exactly how we are delivering on our promise to be the most secure hyperscale cloud. Everything you need to learn about, and follow along with, the SFI can be found on the SFI landing page. The remainder of this section breaks down a few of the ways SFI is implemented in our Jakarta EE and MicroProfile on Azure portfolio. Jakarta EE and MicroProfile on Azure is not an Azure service. Instead of being a service, users of the portfolio are empowered to run the software in their own tenancy, or even on their own sites with their own hardware, using Azure Local. As such, it’s important to understand how SFI applies to Jakarta EE and MicroProfile on Azure. SFI is explained in terms of principles, foundations and pillars. The principles are 1. Secure by design. 2. Secure by default and 3. Secure operations. This table breaks down how we implement these principles for each of the Azure portal deployment experiences: Oracle WebLogic Server, IBM Web Sphere Application Server and Liberty, and Red Hat JBoss EAP. Partner Secure by design Secure by default Secure operations Oracle WebLogic Server For AKS the offer is tightly integrated with Oracle Container Registry, which contains the most secure and up-to-date Critical Patch Update releases. For virtual machines, Oracle maintains the base images and allows easy registration with MyOracleSupport to get Critical Patch Updates. For AKS, the deployment experience requires providing your Oracle Container Registry credentials. Users can easily choose to pull from pre-approved secure patched WebLogic Server images. For AKS, easy integration with Microsoft Defender for Cloud ensures continually updated threat monitoring. For complete details see, What is Microsoft Defender for Cloud? For Virtual Machines, the Azure Virtual Machine marketplace continually monitors all VM images and notifies vendors of vulnerabilities. Vendors, including Oracle continually update their images based on this guidance. IBM WebSphere Application Server and Liberty For AKS, the offer supports deploying fully secure WebSphere Liberty. For virtual machines, IBM maintains the VM images or a quarterly update schedule. For AKS, the deployment experience makes it easy to use the supported version. For virtual machines, in addition to IBM’s quarterly update process, the deployment action also updates the deployed VM to the latest secure patches from IBM with OWASP and CIS compliance. For AKS, easy integration with Microsoft Defender for Cloud ensures continually updated threat monitoring. For complete details see, What is Microsoft Defender for Cloud? For Virtual Machines, the Azure Virtual Machine marketplace continually monitors all VM images and notifies vendors of vulnerabilities. Vendors, including Oracle continually update their images based on this guidance. Red Hat JBoss EAP For Azure Red Hat OpenShift, security is built into the service as described in Security for Azure Red Hat OpenShift. The portal experience uses the JBoss EAP Operator. The operator is designed to deliver the most secure and supported EAP version to run on OpenShift. For Virtual Machines, Red Hat maintains all the images on a regular update schedule. For more, see Security considerations for Red Hat Enterprise Linux on Azure. For virtual machines, in addition to Red Hat’s process to continually update the base images, the VM is registered with your Red Hat account at deployment time and the latest patches are applied. For Virtual Machines, the Azure Virtual Machine marketplace continually monitors all VM images and notifies vendors of vulnerabilities. Vendors, including Oracle continually update their images based on this guidance. On top of the principles are the foundations: 1. A security first-culture, 2. The ability to integrate with security governance, 3. Continuous security improvement, 4. “Paved paths” that optimize productivity, compliance, and security. The Jakarta EE and MicroProfile on Azure team has ongoing engineering meetings with the developers at each of our partners. These meetings allow us to reinforce our security-first culture from Microsoft, and allow it to build on the existing security cultures at each of our partners. Security governance, as described in SFI, is about aligning security efforts with business priorities and technical implementations. One way this is implemented in our portal experiences is by integration with Azure Policy in the use of Tags. All of our offers support tags, for more on tags, see Manage tag governance with Azure Policy. The first two foundations enable the third. We are constantly revising and improving our portal experiences and guidance with input from the experts in Azure core. The final foundation, “paved paths” is the most visible manifestation of SFI in the Jakarta EE on Azure portfolio. For more on the paved paths and how they relate to Jakarta EE and MicroProfile on Azure, see the next section. Finally, after the principles and foundations, come the six pillars of SFI. These pillars are very clear and detailed goals and actions that Microsoft uses to secure how it runs Azure and its own mission critical business operations. Because the Jakarta EE and MicroProfile on Azure offers are not an Azure first party service, the pillars are not directly applicable. Even so, Microsoft is making the pillars transparent so you can apply them in your own operations, safe in the knowledge that our fifty years of security experience are baked into every one of them. You can read the pillars at Secure Future Initiative pillars. What are the paved paths and how do they apply to Jakarta EE and MicroProfile on Azure? In the context of SFI, paved paths are best practices that optimize productivity, compliance, and security. Because step-by-step guidance is a big part of the Jakarta EE and MicroProfile on Azure portfolio, it makes sense to think of the guidance as paved paths. In fact, we recently audited our entire portfolio for SFI compliance. We focused specifically on usage of the “Resource Owner Password Credential (ROPC)” pattern. Strictly speaking, this pattern comes from the world of OAuth 2.0. We use the term ROPC to include any usage of username and password credentials that could possibly be replaced by a usage of managed identities for Azure resources. Wherever possible, we have replaced the use of ROPC with a more SFI compliant approach that does the same thing. For more details on ROPC, see Microsoft identity platform and OAuth 2.0 Resource Owner Password Credentials. For more details on managed identities for Azure resources, see What are managed identities for Azure resources? The following tables list, for each supported Jakarta EE and MicroProfile on Azure runtime, the portal deployment experiences, corresponding paved paths and some specific notes about SFI compliance. Oracle WebLogic Server on Azure Azure compute offer Deploy it now Paved paths SFI notes AKS https://aka.ms/wlsaks Deploy WebLogic Server on Azure Kubernetes Service using the Azure portal - Azure Kubernetes Service WebLogic Server step-by-step guidance Tutorial: Migrate Oracle WebLogic Server to Azure Kubernetes Service (AKS) with geo-redundancy Use passwordless database connection with managed identities. The username/password approach is still shown in a separate embedded tab. Recommendation to use patched images. Virtual machines https://aka.ms/wls-vm-admin https://aka.ms/wls-vm-cluster https://aka.ms/wls-vm-base-images Quickstart: Deploy WebLogic Server on Azure Virtual Machines (VMs) - Azure Virtual Machines Configure Passwordless Database Connections for Java Apps on Oracle WebLogic Server Use SSH for VM login. IBM WebSphere Application Server (traditional) Azure compute offer Deploy it now Paved paths SFI notes Virtual machines https://aka.ms/twas-cluster-portal https://aka.ms/twas-single-portal https://aka.ms/twas-nd-vm-portal Deploy WebSphere Application Server Cluster on Azure VMs IBM WebSphere and Open Liberty Azure compute offer Deploy it now Paved paths SFI notes AKS https://aka.ms/liberty-aks Deploy a Java application with Open Liberty/WebSphere Liberty on an Azure Kubernetes Service (AKS) cluster - Azure Kubernetes Service Tutorial: Migrate WebSphere Liberty/Open Liberty to Azure Kubernetes Service (AKS) with high availability and disaster recovery Use managed identity for container registry access. Use Service Connector for easy passwordless database connection. Azure Red Hat OpenShift https://aka.ms/liberty-aro WebSphere Liberty and Open Liberty on Azure Red Hat OpenShift Azure Container Apps Not applicable Deploy a Java Application with Open Liberty or WebSphere Liberty on Azure Container Apps Use managed identity for container registry access. Use Service Connector for easy passwordless database connection. Red Hat JBoss EAP Azure compute offer Deploy it now Paved paths SFI notes Azure Red Hat OpenShift https://aka.ms/eap-aro-portal Quickstart: JBoss EAP on Azure Red Hat OpenShift - Azure Red Hat OpenShift Manually Deploy a Java Application with JBoss EAP on an Azure Red Hat OpenShift Cluster Workload identity not yet supported on Azure Red Hat OpenShift. Virtual machines https://aka.ms/eap-vm-vmss-portal https://aka.ms/eap-vm-single-portal https://aka.ms/eap-vm-cluster-portal https://aka.ms/eap-vm-base-images Tutorial: Install JBoss EAP on Azure Virtual Machines (VMs) manually Use passwordless database connection with managed identities. Red Hat Quarkus Azure compute offer Paved paths SFI notes AKS Deploy Quarkus on Azure Kubernetes Service - Azure Kubernetes Service Use passwordless database connection with managed identities. Use Service Connector for easy passwordless database connection. Azure Container Apps Deploy a Java Application with Quarkus on Azure Container Apps Use passwordless database connection with managed identities. Use Service Connector for easy passwordless database connection. Azure Functions Deploy serverless Java apps with Quarkus on Azure Functions Multiple compute offers Quarkus with Microsoft Entra ID Use of OIDC is SFI compliant. Summary Microsoft has partnered with the leading enterprise Java vendors to build Azure-native deployment experiences and guidance for the most popular enterprise Java products. Through SFI, Microsoft is committed to continually update this portfolio to be the most secure way to run Java at scale in the cloud.New Features in Azure Container Apps VS Code extension
👆 Install VS Code extension Summary of Major Changes New Managed Identity Support for connecting container apps to container registries. This is now the preferred method for securing these resources, provided you have sufficient privileges. New Container View: Introduced with several commands for easier editing of container images and environment variables. One-Click Deployment: Deploy to Container App... added to the top-level container app node. This supports deployments from a workspace project or container registry. To manage multiple applications in a workspace project or enable faster deployments with saved settings, use Deploy Project from Workspace. It can be accessed via the workspace view. Improved Activity Log Output: All major commands now include improved activity log outputs, making it easier to track and manage your activities. Quickstart Image for Container App Creation: The "Create container app..." command now initializes with a quickstart image, simplifying the setup process. New Commands and Enhancements Managed Identity support for new connections to container registries New command Deploy to Container App... found on the container app item. This one-click deploy command allows deploying from a workspace project or container registry while in single revision mode. New Container view under the container app item allows direct access to the container's image and environment variables. New command Edit Container Image... allows editing of container images without prompting to update environment variables. Environment Variable CRUD Commands: Multiple new commands for creating, reading, updating, and deleting environment variables. Convert Environment Variable to Secret: Quickly turn an environment variable into a container app secret with this new command. Changes and Improvements Command Create Container App... now always starts with a quickstart image. Renamed the Update Container Image... command to Edit Container.... This command is now found on the container item. When running Deploy Project from Workspace..., if remote environment variables conflict with saved settings, prompt for update. Add new envPath option useRemoteConfiguration. Deploying an image with the Docker extension now allows targeting specific revisions and containers. When deploying a new image to a container app, only show ingress prompt when more than the image tag is changed. Improved ACR selection dropdowns, providing better pick recommendations and sorting by resource group. Improved activity log outputs for major commands. Changed draft deploy prompt to be a quick pick instead of a pop-up window. We hope these new features and improvements will simplify deployments and make your Azure Container Apps experience even better. Stay tuned for more updates, and as always, we appreciate your feedback! Try out these new features today and let us know what you think! Your feedback is invaluable in helping us continue to improve and innovate. Azure Container Apps VS Code Extension Full changelog:Azure DevOps - Agent pool report and replace.
As usage of Azure DevOps organisations grow so do the number of projects, repositories, pipelines and agent pools used. With new services available such as Managed DevOps Pools it can appear a mammoth task for central IT function to manually trawl through every pipeline noting down each agentpool being used. Replacing these values potentially even more complicated after creating the new agent pools and mapping them with potential for human error.Self Hosted AI Application on AKS in a day with KAITO and CoPilot.
In this blog post I document my experience of spending a full day using KAITO and Copilot to accelerate deployment and development of a self managed AI enabled chatbot deployed in a managed cluster. The goal is to showcase how quickly using a mix of AI tooling we can go from zero to a self hosted, tuned LLM and chatbot application. At the top of this article I want to share my perspective on the future of projects such as KAITO. At the moment I believe KAITO to be somewhat ahead of its time, as most enterprises begin adopting abstracted artificial intelligence it is brilliant to see projects like KAITO being developed ready for the eventual abstraction pendulum to swing back, motivated by usual factors such as increased skills in the market, cost and governance. Enterprises will undoubtedly in the future look to take centralised control of the AI models being used by their enterprises as GPU's become cheaper, more readily available and powerful. When this shift happens open source projects like KAITO will become common place in enterprises. It is also my opinion that Kubernetes lends itself perfectly to be the AI platform of the future a position shared by the CNCF (albeit both sources here may be somewhat biased). The resiliency, scaling and existence of Kuberentes primitives such as "Jobs" mean that Kubernetes is already the de-facto platform for machine learning training and inference. These same reasons also make Kuberentes the best underlying platform for AI development. Companies including DHL, Wayve and even OpenAI all run ML or AI workloads already on Kubernetes. That does not mean that Data Scientists and engineers will suddenly be creating Dockerfiles or exploring admission controllers, Kubernetes instead, as a platform will be multiple layers of abstraction away (Full scale self service platform engineering) however the engineers responsible for running and operating the platform will hail projects like KAITO.Deploy secure App Service resources to prevent dangling DNS entries and avoid subdomain takeover
Back in May 2024, we announced the Public Preview of Secure Unique Default Hostnames on Web Apps. We are excited to announce that this feature is now in General Availability on Web Apps and is now in Public Preview for Functions! This feature works similarly for both Web Apps and Functions, so you can refer to the Public Preview announcement for more in-depth information regarding this feature. Secure unique default hostname feature is a long-term solution to protect your resources from dangling DNS entries and subdomain takeover. If you have this feature enabled for your App Service resources, then no one outside of your organization would be able to recreate resources with the same default hostname. This means that malicious actors can no longer take advantage of your dangling DNS entries and takeover your subdomains. We highly encourage everyone to enable secure unique default hostnames on their net-new App Service deployments. Addressing pre-existing resources without secure unique default hostnames enabled Since this feature can only be enabled upon resource creation, if you’d like to use this feature for your pre-existing resources, you can: Clone a pre-existing app to a new app with secure unique default hostname enabled Screenshot of cloning pre-existing app to an app that's about to be created with secure unique default hostname enabled. Use a backup of a pre-existing app to restore to a new app with secure unique default hostname enabled Screenshot of using a backup of a pre-existing app to restore to an app that's about to be created with secure unique default hostname enabled. Looking ahead We highly encourage everyone to enable secure unique default hostnames on all net-new App Service deployments. This is the time to integrate and to adopt this feature to your testing and production environments so that you can build more secure App Service resources to prevent dangling DNS entries and avoid subdomain takeover. Keep an eye out for future announcements where we will launch secure unique default hostnames in Public Preview for Logic Apps (Standard)!
