by Contributed | Sep 14, 2023 | Technology
This article is contributed. See the original author and article here.
Our Microsoft Learn community, along with the rest of the world, has experienced a time of great change over the last few years—the pandemic, a sudden shift to remote work, economic volatility, and huge leaps in the capabilities and implementation of AI, to name just a few. Times of change like these cause us all to reevaluate our priorities, how we operate, and what’s most important across all areas of our lives. Careers are no small part of that equation. We must continuously adapt to these new realities, whether we’re employees, employers, job seekers, educators, or leaders of organizations. Because of that impact, Microsoft Learn remains committed to leading the way with resources to help equip our learners and customers with technical skills to not only meet but thrive through the challenges of that ever-changing landscape.
What does ‘skills-first’ mean and why are we talking about it?
We’re always on the lookout for emerging trends so that we can bring you insights to help you succeed. The latest and most significant of these trends is a direct response to the massive global shifts we alluded to above, what the World Economic Forum refers to as “an accelerated shift towards a skills-based operating model for talent.” Simply put: whether you’re focused on your own career or on finding the right talent, a skills-centric mentality is becoming more essential.
How does this impact you? There are all sorts of reasons to engage with skilling content—you might have one or more of the following goals (featuring some great Microsoft Learn blogs on the subject!):
Whatever your objective, knowing how to find and feature the right skills is a game-changer, and we want to be part of your journey.
What to expect from Microsoft Learn through the end of October
Our ‘Skill-it-forward’ content throughout September and October will be focused on understanding the skills-first trend and why it’s important. We’ll also be highlighting the tools and resources you need to build your technical skills and expertise. You can expect the inside scoop about what’s new with Microsoft Learn (hint: we might have a few announcements to make…). We’ll offer resources across Microsoft Learn and beyond to help you not only navigate this skills-centric shift but use it to achieve your goals. And of course, we can’t leave out Tips & Tricks – we always have a few up our sleeve!
Make sure you’re following us on Twitter and LinkedIn, and are subscribed to “The Spark,” our recently enhanced LinkedIn newsletter so you don’t miss any of the exciting stuff we have planned!
by Contributed | Sep 13, 2023 | Technology
This article is contributed. See the original author and article here.
In a previous blog, we introduced Continuous Access Evaluation (CAE) – a product that brings Zero Trust principles to session management. Today we would like to discuss securing cross-tenant access with a focus on preventing data exfiltration.
It’s impossible to imagine a successful modern organization that doesn’t collaborate with partners across organizational boundaries. While cross-company collaboration empowers employees and enables partnerships, it also lowers barriers for both accidental and malicious data exfiltration. Microsoft Cross-Tenant Access Settings is designed to address security of cross-company exchange.
Outbound and Inbound Cross-Tenant Access Settings offer fine grain security controls for cross-company collaboration using user’s home identity, while Tenant Restriction v2 (TRv2) can be used to prevent data exfiltration using foreign identity.
Some of the hardest-to-prevent data leaks happen when users inside your organization use foreign identities to connect to external tenants. Let’s consider one such attack. A malicious insider creates a Microsoft Entra tenant. Then they authenticate to their malicious tenant from your organization’s device. Now the attacker can leak your files via email using the Exchange Online account of the malicious tenant. These types of attacks can be described as creating a “USB dongle in a cloud.” Regular security methods do not work against such attacks. Your tenant’s policies do not apply to external identities that attackers use. Blocking Microsoft Entra ID or Exchange Online URIs in the firewall would block your legitimate users along with the attacker. These types of attack need special defenses that TRv2 provides.
TRv2 works by sending special signals to Entra ID, Microsoft Account and other Microsoft resources. These signals point to Cross-Tenant Access Settings’ TRv2 policy that you created. Microsoft resources evaluate the policy and block unsanctioned access. We have two major flavors of TRv2.
Auth Plane TRv2 can block logins with external identities based on policy. To configure it you need to deploy a network proxy in your organization and configure that proxy to set TRv2 signals on all traffic to Entra ID and Microsoft Account. In the above example of a malicious insider leaking data over external email, the attacker will not be able to login to their malicious tenant and therefore will not be able to send email. Auth Plane TRv2 is now generally available.
Universal TRv2 as part of Microsoft Entra Global Secure Access goes one step further to protect against more sophisticated attacks where an attacker bypasses authentication by allowing anonymous access to the malicious tenant’s apps, such as anonymous meeting join in Teams. Or the attacker can import to your organizational device an access token lifted from a device in the malicious tenant. All these attack vectors bypass login to Entra ID. Since Universal TRv2 sends TRv2 signals on authentication plane (Entra ID and Microsoft Account) and data plane (Microsoft cloud applications), these attacks will be prevented. Universal TRv2 is currently in public preview.
We have another flavor of TRv2 in public preview – TRv2 on Windows. It’s a partial solution that protects the authentication and data planes but only for some scenarios. It only works on managed Windows devices and does not protect .NET stack, Chrome, or Firefox. We have heard from customers that it is difficult to deploy and does not provide adequate security. The Windows solution was meant to provide temporary protection until Universal TRv2 is released and we’re planning to retire it after Universal TRv2 is generally available.
Anna Barhudarian
Principal Product Manager, Identity Division
Learn more about Microsoft Entra:
by Contributed | Sep 13, 2023 | Azure, Business, Gartner Magic Quadrant, Hybrid Work, Microsoft 365, Technology
This article is contributed. See the original author and article here.
Microsoft recognized as a Leader in the Gartner DaaS Magic Quadrant with a global presence, the largest partner ecosystem, and unparalleled integration.
The post Microsoft recognized as a Leader in 2023 Gartner® Magic Quadrant™ for Desktop as a Service appeared first on Microsoft 365 Blog.
Brought to you by Dr. Ware, Microsoft Office 365 Silver Partner, Charleston SC.
by Contributed | Sep 12, 2023 | Technology
This article is contributed. See the original author and article here.
Today, we are announcing the general availability of the latest generations of Azure Burstable virtual machine (VM) series – the new Bsv2, Basv2, and Bpsv2 VMs based on the Intel® Xeon® Platinum 8370C, AMD EPYC™ 7763v, and Ampere® Altra® Arm-based processors respectively.
The new generation of Azure burstable B-series v2 VMs are the lowest priced amongst general purpose VMs in Azure and now include native support for Arm-based workloads with the Bpsv2 series. B-series v2 VMs offer up to 15% better price-performance, up to 5x higher network bandwidth, and 10x higher remote storage throughput compared to the previous generation B-series VMs.
Azure customers today can select from a diverse range of Azure virtual machines that are tailored to meet the high CPU performance and utilization needs of their workloads. However, certain categories of workload do not require high levels of CPU utilization and performance on a continuous basis and can be run more cost-effectively on VMs optimized for burstable performance. With B-series v2 VMs, you can balance high CPU utilization and cost savings that automatically meets your workload’s real-time requirements. Burstable virtual machines provide high CPU utilization when applications need it and run at a baseline CPU utilization to save cost when high CPU utilization and performance are not required.
B-series v2 VMs are ideal for workloads that experience unpredictable spikes in demand and require occasional bursts of high CPU utilization. This capability makes burstable VMs ideal candidates for a variety of workloads such as web applications, small and medium databases, micro services, code repositories, CI/CD pipelines for development and test environments, and servers for proof-of-concept development that don’t require full CPU performance all the time, but occasionally need to burst to complete tasks quickly.
With the new Arm-based Bpsv2 VMs now available alongside x86-based Bsv2 and new AMD-based Basv2 burstable VMs, customers can now tailor their infrastructure for specific performance and price-performance requirements across CPU architectures. Arm-Based Bpsv2 VMs, with one physical core per vCPU, are ideal for many workloads like microservices, web apps, containers, and small to medium databases. While Bsv2 and Bav2 VMs can run these workloads, they also offer capabilities and infrastructure for monolithic, vectorized workloads, and others that don’t have affinity to Arm-based VMs.
You can choose from multiple memory ratios for a given vCPU size, giving you the flexibility to select the configuration and architecture that is ideal for your workload. Bsv2-series and Basv2-series offer up to 32 vCPUs and 128 GiB of RAM, and the Bpsv2-series offers up to 16 vCPUs with 64 GiB of RAM. All sizes support accelerated networking and network bandwidth up to 6.25 Gbps. To learn more about the pricing of Arm64-based and x86-based VMs, please visit the Azure Virtual Machines pricing pages.
The new Azure B-series v2 VMs support various Linux OS distributions including Canonical Ubuntu, Red Hat Enterprise Linux, CentOS, Debian, SUSE Enterprise Linux and more. Windows Server and Windows Client are supported on x86-based B-series VMs. Client application developers can take advantage of Azure’s highly available, scalable, and secure platform to run cloud-based software, build and test workflows. To help developers increase their agility and support their work, we’ve made Insider Preview releases of Windows 11 Pro and Enterprise available on Arm-based Azure B-series VMs. Access the full list of images in the Azure Marketplace.
The new virtual machines support all remote disk types such as Standard SSD, Standard HDD, Premium SSD and Ultra Disk storage. To learn more about various disk types and their regional availability, please refer to Azure managed disk type. Disk storage is billed separately from virtual machines and to learn more on disk pricing please see pricing for disks.
Learn more about these new B-series v2 VMs by visiting the Bsv2, Basv2, and Bpsv2 documentation, reading about the regional availability at Azure product availability page, and following this simple migration guide.
You can also take advantage of Spot Virtual Machines, Reserved Instances and Saving Plan that are available for all new B-series VM families to potentially save even more. You can significantly reduce costs and improve your budget forecasting with Reserved VM Instances through upfront one-year or three-year commitments. With the Azure Savings Plan, you have the flexibility to save across multiple Azure Services, including this one. For workloads that can tolerate interruptions and have flexible execution time, using Spot Virtual Machines can significantly reduce the cost of running in Azure and further optimize your cloud spend. Eligible new Azure customers can sign up for an Azure free account and receive $200 Azure credit.
Start running your applications on Azure B-series v2 VMs today. We can’t wait to hear about the amazing workloads you will build with these new VMs.
Learn what our partners have to say about Azure’s latest burstable VMs:
Azure-Ampere-Bpsv2-Burstable-Virtual-Machines
Demonstrating new Arm-based Azure Burstable VMs – Infrastructure Solutions blog – Arm Community blogs – Arm Community
Have questions? Please reach us at Azure Support Options | Microsoft Azure and our experts will be there to help you with your Azure journey.
by Contributed | Sep 11, 2023 | Technology
This article is contributed. See the original author and article here.
Welcome! This post is going to cover the end-to-end process of configuring and using Workload identity federation in Azure DevOps for your Terraform deployments. We’ll cover:
- Why use Workload identity federation
- What is Workload identity federation and how does it work
- How can your organisation join the Workload identity federation preview
- How to configure Workload identity federation using the Azure DevOps Terraform provider
- How to use Workload identity federation in an Azure DevOps Pipeline with the Terraform task
Why use Workload identity federation
Up until now the only way to avoid storing service principal secrets for Azure DevOps pipelines was to use a self-hosted Azure DevOps agents with managed identities. Now with Workload identity federation we remove that limitation and enable you to use short-lived tokens for authenticating to Azure. This significantly improves your security posture and removes the need to figure out how to share and rotate secrets. Workload identity federation works with many Azure DevOps tasks, not just the Terraform ones we are focussing on in this article, so you can use it for deploying code and other configuration tasks. I encourage you to learn more about the supported tasks here.
What is Workload identity federation and how does it work
Workload identity federation is an OpenID Connect implementation for Azure DevOps that allow you to use short-lived credential free authentication to Azure without the need to provision self-hosted agents with managed identity. You configure a trust between your Azure DevOps organisation and an Azure service principal. Azure DevOps then provides a token that can be used to authenticate to the Azure API.
You can read more about how Workload identity federation works here.
In the first iteration Workload identity federation for Azure DevOps works within the scope of a Service Connection. A new type of Azure Resource Manager Service Connection is available that enables this:
Any task that supports a Service Connection and has been updated to use Workload identity federation can then use your configured trust to interact with Azure resources.
On the Azure side we need to configure Federated Credentials on an App Registration or User Assigned Managed Identity service principal. There are a few settings needed for this, which you can find in the Azure DevOps Service Connection or you can figure out up front:
Issuer URL: This is the a URL in the format https://vstoken.dev.azure.com/ where organisation-id is the GUID of your Azure DevOps organisation. For example https://vstoken.dev.azure.com/f66a4bc2-08ad-4ec0-a25e-e769dab3b294.
Subject identifier: This is the mapping to your service connection in the format sc://// where organisation-name is your Azure DevOps organisation name, project-name is your Azure DevOps project name and service-connection-name is the name of your service connection. For example sc://my-organisation/my-project/my-service-connection.
Audience: This is always api://AzureADTokenExchange.
Here is what it looks like in the Azure Portal:
Once we have the service connection and federated credentials configured, we can use the service connection to authenticate to Azure. You’ll just need to grant your service principal some permissions in the subscription.
How can your organisation join the Workload identity federation preview
The preview is open to anyone, you can input the name of your Azure DevOps organisation into this form to sign up. Once signed up, you’ll have access to the feature flag and you’ll find it under the organisation ‘Preview Features’ menu. Turn it on and you’ll see the new Azure Resource Manager Service Connection types. You can find lots more information here.
How to configure Workload identity federation using the Azure DevOps Terraform provider
The Azure DevOps Terraform provider has been updated to support the creation of Workload identity federation Service Connections. The documentation can be found here.
The following example shows how to setup a Service Connection and User Assigned Managed Identity with Federated Credentials:
terraform {
required_providers {
azurerm = {
source = "hashicorp/azurerm"
version = ">=3.0.0"
}
azuredevops = {
source = "microsoft/azuredevops"
version = ">= 0.9.0"
}
}
}
provider "azurerm" {
features {}
}
resource "azuredevops_project" "example" {
name = "Example Project"
visibility = "private"
version_control = "Git"
work_item_template = "Agile"
description = "Managed by Terraform"
}
resource "azurerm_resource_group" "identity" {
name = "identity"
location = "UK South"
}
resource "azurerm_user_assigned_identity" "example" {
location = azurerm_resource_group.identity.location
name = "example-identity"
resource_group_name = azurerm_resource_group.identity.name
}
resource "azuredevops_serviceendpoint_azurerm" "example" {
project_id = azuredevops_project.example.id
service_endpoint_name = "example-federated-sc"
description = "Managed by Terraform"
service_endpoint_authentication_scheme = "WorkloadIdentityFederation"
credentials {
serviceprincipalid = azurerm_user_assigned_identity.example.client_id
}
azurerm_spn_tenantid = "00000000-0000-0000-0000-000000000000"
azurerm_subscription_id = "00000000-0000-0000-0000-000000000000"
azurerm_subscription_name = "Example Subscription Name"
}
resource "azurerm_federated_identity_credential" "example" {
name = "example-federated-credential"
resource_group_name = azurerm_resource_group.identity.name
parent_id = azurerm_user_assigned_identity.example.id
audience = ["api://AzureADTokenExchange"]
issuer = azuredevops_serviceendpoint_azurerm.example.workload_identity_federation_issuer
subject = azuredevops_serviceendpoint_azurerm.example.workload_identity_federation_subject
}
The items of note are:
- We have to supply the client id of our service principal in the
credentials block service connection, so it knows which service principal is configured with federation.
- We supply the string
WorkloadIdentityFederation in the service_endpoint_authentication_scheme attribute to tell it the type of service connection we want to create.
- We use the
workload_identity_federation_issuer and workload_identity_federation_subject outputs of our service connection to populate the federated credentials. This is a shortcut for getting this information, which you of course get from elsewhere if you prefer.
Once you run this Terraform and create these resources you’ll be ready to use the Service Connection in your Azure DevOps Pipeline.
How to use Workload identity federation in an Azure DevOps Pipeline with the Terraform task
We have updated the two most popular Terraform Tasks to support Workload identity federation, these are:
The following example shows how to use the Microsoft DevLabs task in an Azure DevOps Pipeline:
jobs:
- deployment: deploy
displayName: Deploy with Terraform
pool:
vmImage: ubuntu-latest
environment: dev
strategy:
runOnce:
deploy:
steps:
- checkout: self
displayName: Checkout Terraform Module
- task: TerraformInstaller@0
displayName: Install Terraform
inputs:
terraformVersion: 'latest'
- task: TerraformTaskV4@4
displayName: Terraform Init
inputs:
provider: 'azurerm'
command: 'init'
workingDirectory: '$(workingDirectory)'
backendServiceArm: '${{ variables.serviceConnection }}'
backendAzureRmResourceGroupName: '$(BACKEND_AZURE_RESOURCE_GROUP_NAME)'
backendAzureRmStorageAccountName: '$(BACKEND_AZURE_STORAGE_ACCOUNT_NAME)'
backendAzureRmContainerName: '$(BACKEND_AZURE_STORAGE_ACCOUNT_CONTAINER_NAME)'
backendAzureRmKey: 'terraform.tfstate'
env:
ARM_USE_AZUREAD: true # This environment variable tells the backend to use AzureAD auth rather than trying a create a key. It means we can limit the permissions applied to the storage account and container to least priviledge: https://developer.hashicorp.com/terraform/language/settings/backends/azurerm#use_azuread_auth
- task: TerraformTaskV4@4
displayName: Terraform Apply
inputs:
provider: 'azurerm'
command: 'apply'
workingDirectory: '$(workingDirectory)'
commandOptions: '-auto-approve -var="resource_group_name=$(AZURE_RESOURCE_GROUP_NAME)"'
environmentServiceNameAzureRM: '${{ variables.serviceConnection }}'
env:
ARM_USE_AZUREAD: true
Right now you are probably thinking “how is this any different to what I do now?” and you’d be right to think that because there is no difference. The Workload identity federation implementation is abstracted away into the choice of Service Connection type. The task knows based on the type of Service Connection how to authenticate to Azure and set the relevant environment variables for you.
If you want to know how you can do it yourself outside of the terraform task, you can see an example of using the Azure CLI task here and here.
Conclusion
We’ve shown you how to configure and use Workload identity federation for Azure DevOps, we want you to SIGN UP FOR THE PREVIEW and start using it right away.
If you want a more in depth example, you can refer to this sample repository.
Thanks for reading, feel free to ask questions.
Recent Comments