As development teams embrace cloud-based tools to accelerate their workflows, managing resources securely and efficiently across different projects has become a top priority for IT pros and developers alike. Microsoft Dev Box is designed to streamline project-based development, providing developers with tailored cloud development environments optimized for productivity and collaboration. Today, we’re excited to announce a new feature, now available for preview for Microsoft Dev Box: project policies.

Project policies bring a powerful new way for platform engineers to set guardrails around resources enabled on a per-project basis, allowing teams to balance flexibility with governance as they work on diverse projects. Let’s dive into understanding the basics of project policies, what problems they solve, how to create them, and how you can leverage them for enhanced resource management.

What Are Project Policies?

In Microsoft Dev Box, the Dev Center is the main hub for platform engineers. Within the Dev Center, platform engineers can set up multiple projects, each tailored to specific workflows, team configurations, and goals, and mapped to different development teams working on various apps or products. Project policies provide a mechanism to restrict access to certain resources—specifically, SKUs, Images, and Network Connections—to designated projects. This helps ensure that each project has controlled access to the resources it needs while keeping everything secure, isolated, and streamlined.

With project policies, platform engineers gain more granular control over resources, which can lead to better performance, cost efficiency, and compliance. This feature is particularly beneficial for large organizations managing multiple development teams or projects with varied requirements, as it allows for individualized guardrails without sacrificing flexibility.

Enabling Project Policies

Creating a default project policy

With project policies, platform engineers have the option to configure a default project policy. Think of this default policy as a foundational layer applied across all projects in your Dev Center. This default policy helps establish baseline rules and ensures consistency in how sub-resources are managed. While a default policy is helpful to scale project policies across your entire Dev Box deployment, they are not required before setting up custom policies.

To create your default project policy:

1. Within your Dev Center resource, navigate to Settings > Project policy and select the option to create a new Project Policy.
2. Select “All current and future projects”. This option will automatically set the name for the project policy to “default”
3. Configure the default settings for SKUs, Images, and Network Connections that will apply universally across projects.
4. Save the policy, which will now act as the default set of resources available for any new or existing projects until additional custom policies are applied.

While a default project policy is not required, setting one up ensures all projects adhere to a standard set of guidelines from the start. This can be especially helpful if your organization has overarching security or compliance requirements that every project must meet.

Creating custom project policies for targeted control

After the default project policy is in place, you can create additional policies to address specific needs or restrictions for individual projects. Custom policies allow admins to set guardrails that are unique to the project’s requirements, whether that means offering high-powered SKUs for certain projects or restricting network access based on security considerations.

Key points to know:

• Resource-specific controls: Each Project Policy can set rules for SKUs, Images, and Network Connections. This granularity lets you define, for instance, which types of virtual machines or configurations are allowed per project.
• Flexible application: Because the relationship between projects and policies is many-to-many, you can apply multiple policies to any number of projects. This flexibility allows projects to share common resource configurations or establish unique policies where necessary.
• Joined policies: When multiple policies apply to a single project, sub-resource access is cumulative. This means that if one policy grants access to a specific SKU and another policy grants access to a particular network, the project can access both resources.

Enforcing your project policies

Creating a policy does not mean it has automatically been enforced on the selected projects. Once you’ve configured your policies, you can control enforcement by using the resource type checkboxes located at the top of the page.

Here’s how enforcement works:

• For each resource type (SKUs, Images, Network Connections), select the checkbox to enforce policies for that specific resource.
• Existing policies control what resources are available to each project based on the types you’ve selected.
• When a resource type is selected, all resources of that type will be unavailable for all projects unless specified by a project policy.
• Projects without a custom policy will fall back on the resources outlined in the default project policy.

When policies are enforced, Microsoft Dev Box evaluates the health of existing resource pools against the new policy settings:

• Pool Health Check: Each resource pool is evaluated to determine compliance with the enforced policies.
• Unhealthy Pools: If a pool fails to meet the enforced requirements, it may be marked as unhealthy. This prevents any new Dev Boxes from being created within that pool.
• Existing Dev Boxes Remain Active: Dev Boxes already created within an unhealthy pool will continue to function normally, so your teams can keep working without disruption.

This enforcement mechanism ensures projects access only the resources they’re approved for, maintaining a secure-by-default environment with efficient operations across all projects in the Dev Center.

Examples of Project Policies in Action

To illustrate how project policies can streamline resource management, here are a few common scenarios:

• Securely Configuring Network Access for Sensitive Projects: For projects handling sensitive data, you might want to restrict network access to ensure that only specific, approved connections are available. Using a custom Project Policy, you can define which network connections are accessible, helping to enhance security while allowing project teams to focus on their work.
• Optimizing Resources for High/Low-Power Development Needs: Certain projects may require more (or less) powerful machines with specific configurations. Through project policies, you can enable access to specific SKUs only for the projects that need them, optimizing resource use and reducing costs for projects that don’t require those configurations.
• Managing Images for Different Project Needs: Images can include various software setups or tools needed for a project. With project policies, you can limit the images available to each project, ensuring that each team has access to exactly what they need. These teams can then utilize team customizations to further support their specific needs.

Get Started with Project Policies Today

Project policies are part of our ongoing effort to make Microsoft Dev Box a versatile, secure, and scalable solution for developers and platform engineers alike. And this is just the beginning for project policies. We’re actively working on expanding the feature set and incorporating your feedback.

We’d love to hear about your experience with project policies and how we can make it even better for your development teams.

• Learn about what’s new in Dev Box: https://aka.ms/devbox/ignite24blog
• Share your feedback by visiting https://aka.ms/DevBox/Feedback!
• To get started with Microsoft Dev Box, please visit https://aka.ms/devbox/getstarted!