How to Request¶
All requests go through your platform team's intake (for example a ticket or work item). The platform team is XMMS under a managed-service contract, or your organisation's own platform team: see Operating models and Support. Every request is a standard change: a known procedure with fixed request fields. Fill in all fields; a complete request is handled fastest.
Request or pull request?
Some platforms let workload teams prepare a change themselves, usually a firewall rule, as a pull request on the configuration repository. The platform team reviews and deploys it. Ask your platform team whether this is possible for you. If it is, read the Firewall rule guidelines and Pull request review first. The steps for the files are in Firewall rules and IP groups.
Every request¶
| Field | Required | Example |
|---|---|---|
| Rationale | yes | "New invoice portal for Finance" |
| Environment | yes | dev, tst, acc, prd, shared |
| Comments | no | Anything else we need to know |
A new spoke¶
| Field | Required | Example / notes |
|---|---|---|
| Name (workload short name) | yes | invprt. Max 6 characters, can't change later. |
| Environment(s) | yes | dev and prd. One spoke per environment. |
| Existing subscription | yes | The subscription ID, if your organization creates subscriptions first. Ask your platform team how subscriptions are created. |
| Production data yes/no | yes | Decides the management group and policies |
| Personal data (PII) yes/no | yes | Sets the pii tag |
| Exposed to the internet yes/no | yes | Decides corp or online, and whether you need the App Gateway |
| IP range size | yes | For example a /24. The platform team allocates the range. |
| Subnets | yes | Name and size per subnet, delegations (e.g. Microsoft.Web/serverFarms), service endpoints (e.g. Microsoft.Storage) |
| Team access | yes | Display name of your existing Entra ID group, and per role whether you want direct access, PIM self-approve, or PIM with approval. The group must exist before the spoke is created. |
| Tags | yes | owner, department, workload, costcentre |
| Region | no | Default is the primary region of the platform |
| Azure DevOps repository + service connection | no | Project name and repository name |
| Optional resources | no | Leave out Key Vault, storage or Log Analytics if you don't want them. Say if you won't use the private endpoint of the Key Vault or storage account. |
| Approvals | depends | The approvals your organisation requires before a workload is created, for example product owner, architecture and security. See Onboarding. |
Other requests¶
| Request | Fields |
|---|---|
| Firewall rule (new or changed) | Source (spoke/subnet), destination (FQDN, IP or service tag), port and protocol, rationale. For outbound internet, prefer FQDNs. |
| Publish an app through the Application Gateway | Workload name, backend address (IP/FQDN), listener URL, port (HTTP/HTTPS), SSL certificate (for HTTPS), redirects yes/no, health probe (path, protocol, interval). Optional: URLs of custom error pages (for example for 502 and 403). |
| Change an App Gateway configuration | Same fields, only what changes |
| Renew or replace a certificate on the Application Gateway | Listener URL and certificate name. Who orders the certificate depends on your platform: see Certificates for published apps. |
| Web application firewall exception | The blocked request (URI, argument name, rule ID from the WAF log), why it is a false positive, and the security approval. See Application Gateway. |
| Inbound SFTP from an external party to a storage account | See Inbound SFTP to a storage account |
| Managed VM (new, change, remove) | See Managed virtual machines |
| Policy exemption | Policy or initiative, scope (your subscription or resource group), category (waiver or mitigated), rationale, alternative measures, end date, security approval. See Policy and exemptions. |
| Change to your spoke | See How to change |
| Delete a spoke | Spoke name and environment, confirmation that data may be deleted, confirmation that you are the workload owner. Deleting is permanent: the spoke's resource groups, Key Vault and storage are destroyed. The subscription is not cancelled automatically. Remove the firewall rules and Application Gateway entries of the workload in the same request. See Delete a spoke. |
| Group access (PIM mode, team group) | See Access, groups and PIM |
| Budget, reservation | See Cost and reservations |
| Shared service (registry, APIM, gateway) | See Shared services |
| A new region | Region, rationale. This is a platform change and takes longer. |
Firewall rules¶
Outbound and spoke-to-spoke traffic is blocked unless a rule allows it. Request the rule before you need it.
| Field | Description |
|---|---|
| Source | The spoke or subnet (CIDR) the traffic starts from |
| Destination | IP address, CIDR, FQDN or service tag. For internet destinations, prefer FQDNs. |
| Port(s) | The port numbers of the service |
| Protocol | TCP, UDP or HTTP/HTTPS |
| Environment | One request per environment (dev, tst, acc, prd), because each has its own rules |
| Rationale | Why this traffic is needed |
- For traffic between two workloads in Azure, the owner of the receiving (destination) workload makes the request.
- The platform team (or your security officer, who approves) checks the request against the security policy and then implements it in the hub firewall configuration.
- Operators: see Firewall rules.
- Workload teams that prepare the pull request themselves: Firewall rules and IP groups.
Who requests which rule¶
A common ownership model, which keeps one clear owner per rule:
| Traffic | Who requests |
|---|---|
| Your workload to an internet destination | Your team (the source) |
| Your workload to an on-premises system | Your team (the source) |
| One Azure workload to another | The team of the destination workload |
| An external or on-premises system to an Azure workload | The team of the destination workload |
The reason for placing internal rules at the destination is that the firewall is shared. If both sides could add rules, a workload could open traffic towards another workload that never approved it. The destination owner decides who may connect to their workload.
Choosing the rule type and destination¶
- Use an application rule for HTTP, HTTPS and SQL traffic to an internet FQDN. It matches on the FQDN and the firewall can inspect it.
- Use a network rule for other protocols and for internal traffic. Application rules translate the source address (SNAT), so the destination sees the firewall instead of your workload, and source-based logging and troubleshooting get harder. Your platform may choose differently, so follow what your platform team says.
- Name the destination as precisely as you can: an FQDN first, then a single IP address, then an IP range. Don't ask
for
*, "any" or wide ranges. Name the exact ports. - Several rules often need the same addresses. The platform team then puts them in an IP group (IP groups).
What the review usually checks¶
Organisations often set rules like these. Ask yours which apply.
- Only encrypted protocols by default. Unencrypted protocols need an extra approval from security.
- No rules between production and non-production environments, so that production data doesn't flow to non-production.
- Internet rules and internal rules are kept apart.
- Internal rules between workloads need the approval of the destination owner. Rules to the internet or to a workload with another usage type usually also need a security review.
The example below shows how approvals can be divided. It is an example, not a fixed rule of the platform.
| Request | Destination owner approves | Security reviews rationale | Platform team reviews technically |
|---|---|---|---|
| Traffic between two spokes of the same workload | yes | no | yes |
| Traffic from another workload with the same usage type (prod or non-prod) | yes | yes | yes |
| Outbound traffic to the internet | yes | yes | yes |
| Traffic to or from on-premises | yes | yes | yes |
| A small change to an existing rule (only source or destination within the same spoke changes) | yes | no | yes |
| Everything else | yes | yes | yes |
Certificates for published apps¶
For an HTTPS listener on the Application Gateway, the certificate is stored in the gateway's Key Vault, which the platform team manages. Ordering and renewing the certificate is usually a responsibility on the customer side (a central team or the workload team), because the certificate authority and its account belong to your organisation. Agree with your platform team who does what when you publish the app, and put the expiry date in your calendar or monitoring. The renewal steps are in Replace a certificate on the Application Gateway. If the backend uses the same certificate (for example a reverse proxy that terminates TLS), both copies must be replaced at the same time.
What happens next¶
- The platform team checks the request and asks questions if fields are missing.
- They make the change in code, have it reviewed, test it on the canary platform where relevant, and apply it.
- You get a confirmation with what was created or changed. For a new spoke: the subscription name, VNet range, group names, and (if you use PIM) how to activate your role.