Design Principles and Guardrails¶
Platform philosophy explains how the product is built. This page is about the rules for using the platform: the guardrails that workload teams and the platform team follow. They are a recommended set. Your organisation decides which ones apply and who enforces them.
Policy, standard, best practice¶
Say for every rule how binding it is.
| Level | Meaning | Example |
|---|---|---|
| Policy | Must be followed. Preferably enforced by technology. | Storage accounts are not reachable from the public internet |
| Standard | Must be followed unless a deviation is motivated | A default language or tool, unless a required library is not available |
| Best practice | Recommended, not required | Run tests against shared data models |
Guardrails for workload teams¶
| # | Guardrail | Why |
|---|---|---|
| 1 | No manual changes in production. Use a deployment pipeline. | Manual changes have no history (what changed, who, why) and are error-prone |
| 2 | Automate as much as possible: infrastructure as code, pipelines, scripts | Manual tasks are not reproducible and cause mistakes |
| 3 | Four-eyes principle for every change in production, for example a reviewed pull request | An independent check catches errors |
| 4 | Reuse before buy before build | Reuse and buy are usually cheaper in the long run |
| 5 | Prefer cloud-native over third-party, and SaaS over PaaS over IaaS | Easier to integrate into the rest of the landscape |
| 6 | You build it, you run it, you own it | Design for operations, because you will operate it |
| 7 | Observability must not require access to the data | Operators can verify health without seeing sensitive content |
| 8 | Isolate development: one team's work must not break another team's | Deploy to production often instead of big-bang releases |
| 9 | Test the crucial parts | Not 100% coverage, but tests that protect refactoring and continuous deployment |
| 10 | Sign in with Entra ID with MFA. Grant access to groups, never to individuals. | One identity, one control point |
Best practices that go with them: lint and security-test in the pipeline, prefer best-of-breed small tools over one tool that does everything, keep the number of connections between resources low, standardise APIs, and follow the best practices of the services you use.
Guardrails for infrastructure¶
| # | Guardrail | Why |
|---|---|---|
| 1 | Public access to a workload goes through the central entry points: HTTP(S) through the Application Gateway, other protocols through the Azure Firewall | One place to inspect and control inbound traffic |
| 2 | No public IP addresses on workload resources | Follows from the previous guardrail |
| 3 | Use private connectivity. Public access to resources is blocked by default; private endpoints are the preferred way. If that is not possible, allow only specific subnets or IP addresses. | Keeps data traffic off the internet |
| 4 | Use the latest TLS version a service offers | Security |
| 5 | Environments are fully isolated: each has its own resources, configuration and dependencies | Prevents issues in one stage from cascading to another, and supports parallel development and testing |
In the platform these are implemented by the central firewall, the private DNS and policies that deny public endpoints. A way to give an external party inbound access to one resource is Inbound SFTP to a storage account. See Limits and Policy and exemptions.
Guardrails for pipelines and repositories¶
The platform runs on pipelines, so the pipeline platform is part of the security model. A baseline in short:
- Organisation. A non-personal account owns the organisation. Access is only with Entra ID identities, through groups. Privileged roles only through PIM. Alternate authentication credentials and third-party OAuth access are off.
- History is evidence. Nobody deletes builds, releases, repositories or team projects.
- Production deployments need an approval on the production stage, and run only from specific production branches.
- Pipelines are YAML, classic pipelines are off, and variables that can be set at queue time are limited.
- Secrets live in a vault, not in pipeline variables. They are never logged, and they are audited and rotated. Prefer service connections scoped to what they need, and service principals over personal access tokens.
- Branches have policies without bypass: at least two reviewers, the person who pushed last cannot approve, comments are resolved, a build succeeds and a work item is linked. Forking is off.
- Production secrets are in a separate vault, with access on a need-to-know basis. Test and production credentials are not mixed.
- Agents. Few accounts have permissions, the firewall is as restrictive as the agents allow, pools are updated regularly, and production artifacts use a separate pool (Build agent access).
The full list for Azure DevOps, with the settings, is in Azure DevOps: setup and guiding principles.
How these relate to the MCP pipelines
The MCP configuration repository has its own protections: approval modes for prod runs and branch protection on the configuration repository. See Pipelines and workflows. The guardrails on this page are for the pipelines your workload teams build.
Freedom within a framework¶
Guardrails do not mean central control of everything. A good platform gives teams autonomy where it is safe: the team owns its pipelines, its resources inside its spoke and, in some designs, its own DNS zones (DNS subdomain delegation). The platform sets the framework with policy, naming and the network, and checks it automatically.