Add bastion session recording configuration and identity properties

[Matthew Lee (mwlee29)]

ARM (Control Plane) API Specification Update Pull Request

Tip

Overwhelmed by all this guidance? See the Getting help section at the bottom of this PR description.

PR review workflow diagram

Please understand this diagram before proceeding. It explains how to get your PR approved & merged.

Purpose of this PR

What's the purpose of this PR? Check the specific option that applies. This is mandatory!

• New resource provider.
• New API version for an existing resource provider. (If API spec is not defined in TypeSpec, the PR should have been created in adherence to OpenAPI specs PR creation guidance).
• Update existing version for a new feature. (This is applicable only when you are revising a private preview API version.)
• Update existing version to fix OpenAPI spec quality issues in S360.
• Convert existing OpenAPI spec to TypeSpec spec (do not combine this with implementing changes for a new API version).
• Other, please clarify:
  • edit this with your clarification

Due diligence checklist

To merge this PR, you must go through the following checklist and confirm you understood
and followed the instructions by checking all the boxes:

• I confirm this PR is modifying Azure Resource Manager (ARM) related specifications, and not data plane related specifications.
• I have reviewed following Resource Provider guidelines, including
  ARM resource provider contract and
  REST guidelines (estimated time: 4 hours).
  I understand this is required before I can proceed to the diagram Step 2, "ARM API changes review", for this PR.
• A release plan has been created. If not, please create one as it will help guide you through the REST API and SDK creation process.

Additional information

Viewing API changes

For convenient view of the API changes made by this PR, refer to the URLs provided in the table
in the Generated ApiView comment added to this PR. You can use ApiView to show API versions diff.

Suppressing failures

If one or multiple validation error/warning suppression(s) is detected in your PR, please follow the
suppressions guide to get approval.

Getting help

• First, please carefully read through this PR description, from top to bottom. Please fill out the Purpose of this PR and Due diligence checklist.
• If you don't have permissions to remove or add labels to the PR, request write access per aka.ms/azsdk/access#request-access-to-rest-api-or-sdk-repositories
• To understand what you must do next to merge this PR, see the Next Steps to Merge comment. It will appear within few minutes of submitting this PR and will continue to be up-to-date with current PR state.
• For guidance on fixing this PR CI check failures, see the hyperlinks provided in given failure
  and https://aka.ms/ci-fix.
• For help with ARM review (PR workflow diagram Step 2), see https://aka.ms/azsdk/pr-arm-review.
• If the PR CI checks appear to be stuck in queued state, please add a comment with contents /azp run.
  This should result in a new comment denoting a PR validation pipeline has started and the checks should be updated after few minutes.
• If the help provided by the previous points is not enough, post to https://aka.ms/azsdk/support/specreview-channel and link to this PR.
• For guidance on SDK breaking change review, refer to https://aka.ms/ci-fix.

[azure-pipelines]

Azure Pipelines:
Successfully started running 9 pipeline(s).
3 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

[github-actions]

Next Steps to Merge

✅ All automated merging requirements have been met! To get your PR merged, see aka.ms/azsdk/specreview/merge.

Comment generated by summarize-checks workflow run.

[github-actions]

API Change Check

APIView identified API level changes in this PR and created the following API reviews

Language	API Review for Package
TypeSpec	Microsoft.Network
Go	sdk/resourcemanager/network/armnetwork
JavaScript	@azure/arm-network
Java	com.azure.resourcemanager:azure-resourcemanager-network
Python	azure-mgmt-network

---

Comment generated by After APIView workflow run.

[github-actions]

TypeSpec suppressions requiring review (testing, non-blocking)

Status: ❌ Approval required (currently under testing, review NOT enforced) — 6 suppressions

⚠️ This check is currently in testing mode and is non-blocking — it will not prevent this PR from merging. This PR adds or updates the TypeSpec suppressions listed below. Suppressions are strongly discouraged — they bypass linter rules that protect API quality and consistency. Authors should avoid adding new suppressions and prefer fixing the underlying issue; reviewers should approve only when there is a clear, compelling justification and no reasonable alternative. Review each linked rule and source location, then apply Approved-TypeSpecSuppression only if every justification is acceptable. The Status column shows ✅ once the label is applied and ❌ while approval is pending.

New suppressions (2)

Status	Rule	Source	Justification
❌	@azure-tools/typespec-azure-resource-manager/lro-location-header A 202 response should include a Location response header.	BastionHost.tsp#L77	Rename of previous updateTags operation which uses a legacy async polling pattern
❌	@azure-tools/typespec-azure-resource-manager/lro-location-header A 202 response should include a Location response header.	BastionHost.tsp#L77	Rename of previous updateTags operation which uses a legacy async polling pattern

Changed suppressions (4)

Status	Rule	Source	Previous justification	New justification
❌	@azure-tools/typespec-azure-resource-manager/secret-prop RPC-v1-13: Check that property with names indicating sensitive information(e.g. contains auth, password, token, secret, etc.) are marked with Madara (@secret) decorator.	models.tsp#L11425	FIXME: Update justification, follow aka.ms/tsp/conversion-fix for details	Pre-existing GA property; changing its schema (e.g. adding format: password / x-ms-secret) would be a breaking change. Whether GET/LIST returns this authorization key unmasked or masked is enforced at runtime by the backend based on the caller's privileges, not by the API schema, so Madara (@secret) is intentionally not applied. The dedicated listKeys POST action returns the unmasked key via the Madara (@secret) ExpressRouteAuthorizationKey response model.
❌	@azure-tools/typespec-azure-resource-manager/secret-prop RPC-v1-13: Check that property with names indicating sensitive information(e.g. contains auth, password, token, secret, etc.) are marked with Madara (@secret) decorator.	models.tsp#L12892	FIXME: Update justification, follow aka.ms/tsp/conversion-fix for details	Pre-existing GA property; changing its schema (e.g. adding format: password / x-ms-secret) would be a breaking change. Whether GET/LIST returns this authorization key unmasked or masked is enforced at runtime by the backend based on the caller's privileges, not by the API schema, so Madara (@secret) is intentionally not applied. The dedicated listKeys POST action returns the unmasked key via the Madara (@secret) ExpressRouteAuthorizationKey response model.
❌	@azure-tools/typespec-azure-resource-manager/secret-prop RPC-v1-13: Check that property with names indicating sensitive information(e.g. contains auth, password, token, secret, etc.) are marked with Madara (@secret) decorator.	models.tsp#L11425	FIXME: Update justification, follow aka.ms/tsp/conversion-fix for details	Pre-existing GA property; changing its schema (e.g. adding format: password / x-ms-secret) would be a breaking change. Whether GET/LIST returns this authorization key unmasked or masked is enforced at runtime by the backend based on the caller's privileges, not by the API schema, so Madara (@secret) is intentionally not applied. The dedicated listKeys POST action returns the unmasked key via the Madara (@secret) ExpressRouteAuthorizationKey response model.
❌	@azure-tools/typespec-azure-resource-manager/secret-prop RPC-v1-13: Check that property with names indicating sensitive information(e.g. contains auth, password, token, secret, etc.) are marked with Madara (@secret) decorator.	models.tsp#L12892	FIXME: Update justification, follow aka.ms/tsp/conversion-fix for details	Pre-existing GA property; changing its schema (e.g. adding format: password / x-ms-secret) would be a breaking change. Whether GET/LIST returns this authorization key unmasked or masked is enforced at runtime by the backend based on the caller's privileges, not by the API schema, so Madara (@secret) is intentionally not applied. The dedicated listKeys POST action returns the unmasked key via the Madara (@secret) ExpressRouteAuthorizationKey response model.

For an overview of TypeSpec linting rules click here.
For a mapping from ARM lintdiff rules to corresponding TypeSpec linting rules click here.

💬 Have feedback on the TypeSpec suppression flow? Let us know.

[Sandip Shahane (sandipsh)]

ARM API Review

Posting findings from the ARM API Reviewer agent (critic-verified, 2 iteration(s), converged) against commit 295dcf8. See inline comments for findings 1-5.

Approval labels observed: none.

[Matthew Lee (mwlee29)]

This PR needs the Approved-Avocado tag to suppress the Swagger Avocado violation as the default tag intentionally includes vmssNetwork.json from 2018-10-01 for backward compatibility. Please find the reference PR where the suppression was provided: #41904

[github-actions]

ARM API Review Summary

Reviewed PR #45630 at head SHA 4acc7b4007ced06372c884db1e59410a6d88d75f | Triggered by: manual/scheduled ARM review run

Approval labels observed: BreakingChange-Go-Sdk-Approved, BreakingChange-JavaScript-Sdk-Approved, BreakingChange-Python-Sdk-Approved, Approved-Avocado.

Category	Count
🔴 Blocking	0
🟠 Warning	1
🔵 Suggestion	0

Reconciliation note: Five prior findings from earlier runs (anonymous PATCH body, unconstrained armResourceIdentifier on userAssignedIdentityId, two example resource-ID inconsistencies, and the BastionHosts_UpdateTags→BastionHosts_Update operationId rename) were previously resolved as fixed by commits between 2026-08-24 and 2026-08-27. Commit f03cacf ("Revert previous changes which maintained the old operation") reintroduced the operation-ID rename: stable/2026-01-01/virtualNetwork.json's PATCH operation is again BastionHosts_Update (previously restored to BastionHosts_UpdateTags in 8be842a), with its request body now BastionHostUpdate instead of TagsObject. A reply was posted on the existing resolved thread rather than a new duplicate finding, per reconciliation rules. It is scored Warning (not Blocking) because SDK-language breaking-change approvals are present, though no ARM-review-specific BreakingChange-Approved-* label was observed.

Critic availability: The arm-api-review-critic-runtime subagent reported that its required protocol/input-template files were not resolvable in this run, so it returned a failed dispatch rather than a verdict. Per protocol, this run proceeds with critic: unknown and does not treat any finding as Critic-verified. No other Blocking or Warning candidates were identified in this pass across the TypeSpec, common.json, and virtualNetwork.json changes (identity/sessionRecordingConfiguration placement, common-types ManagedServiceIdentity $ref usage, x-ms-enum/modelAsString on SessionRecordingIdentityType, and arm-id format with x-ms-arm-id-details on userAssignedIdentityId all look correct).

The operationId rename is the key open item for the author to resolve or get approved before merge.

posted-by: arm-api-reviewer-agent | rule: summary | severity: warning | classification: existing | critic: unknown | head-sha: 4acc7b4

🔍 ARM API review by ARM API Review: Automated Workflow

[github-actions]

ARM API Review

Posting findings from the ARM API Reviewer agent (Critic unavailable; reviewer self-check only, 1 iteration, reintroduced regression flagged) against commit 4acc7b4007ced06372c884db1e59410a6d88d75f. All findings are reported in the summary comment and as a reply to the existing thread; no new inline comments were queued this run.

Approval labels observed: BreakingChange-Go-Sdk-Approved, BreakingChange-JavaScript-Sdk-Approved, BreakingChange-Python-Sdk-Approved, Approved-Avocado.

🔍 ARM API review by ARM API Review: Automated Workflow

[Gary Li (gary-x-li)]

Suppression review result: not approved as currently justified. The suppression report at #45630 (comment) identifies the new lro-location-header suppression but does not approve it. This supersedes the non-blocking characterization in #45630 (comment) and #45630 (review).
In stable 2026-01-01, BastionHosts_Update is an asynchronous PATCH whose 202 response has Azure-AsyncOperation and Retry-After but no required Location header. Copying the older updateTags pattern is not a technical justification for the new GA suppression.
Please add the required Location header and remove the suppression after verifying LroLocationHeader no longer fires. If a technical constraint prevents that, document the constraint and operational impact here for ARM API peer review.
Approval context: No Approved-TypeSpecSuppression label was observed at the session SHA. Please confirm whether approval already covers this specific suppression. If it does, ensure the label is applied and resolve this conversation; otherwise add the required Location header and remove the suppression, or obtain approval for a documented technical exception.

The new update operation is effectively the same as the updateTags operation with a different body. It uses some legacy polling pattern

The missing Location header is blocking. The ARM RPC asynchronous PATCH contract requires a 202 response to include both Location and Azure-AsyncOperation headers.

The operation-ID change is acceptable. It does not affect the HTTP method, URI, or service behavior; it only influences generated SDK naming and tooling. Since 2026-01-01 is not yet published on main, no released same-version contract is being changed, and the relevant SDK compatibility checks and approvals cover the future generated surface.

[Matthew Lee (mwlee29)]

Gary Li (@gary-x-li) Currently our PATCH path doesn't return a Location header in the response and has never done so. This is a pre-existing issue that was previously suppressed and has nothing to do with my changes. The reason it's surfaced now is because I'm renaming the operation to something more appropriate (updateTags -> update). With this context, is the missing Location header still blocking?

[Gary Li (gary-x-li)]

Gary Li (Gary Li (@gary-x-li)) Currently our PATCH path doesn't return a Location header in the response and has never done so. This is a pre-existing issue that was previously suppressed and has nothing to do with my changes. The reason it's surfaced now is because I'm renaming the operation to something more appropriate (updateTags -> update). With this context, is the missing Location header still blocking?

Given this is a pre-existing issue, and likely won't break at runtime (most client tools use Location header first, then falls back to Azure-AsyncOperation header), I won't block this PR.

Can you please create a work item to track this work, and paste the link here?

[Matthew Lee (mwlee29)]

Gary Li (Gary Li (Gary Li (@gary-x-li))) Currently our PATCH path doesn't return a Location header in the response and has never done so. This is a pre-existing issue that was previously suppressed and has nothing to do with my changes. The reason it's surfaced now is because I'm renaming the operation to something more appropriate (updateTags -> update). With this context, is the missing Location header still blocking?

Given this is a pre-existing issue, and likely won't break at runtime (most client tools use Location header first, then falls back to Azure-AsyncOperation header), I won't block this PR.

Can you please create a work item to track this work, and paste the link here?

https://msazure.visualstudio.com/One/_workitems/edit/39551597

resolved

[github-actions]

ARM API Review Summary

Reviewed PR #45630 at head SHA 4acc7b4007ced06372c884db1e59410a6d88d75f | Triggered by: pull_request_target

Approval labels observed: BreakingChange-Go-Sdk-Approved, BreakingChange-JavaScript-Sdk-Approved, BreakingChange-Python-Sdk-Approved, Approved-Suppression.

Category	Count
🔴 Blocking	0
🟠 Warning	0
🔵 Suggestion	0

No new commits since the last automated review at this same head SHA (4acc7b4007ced06372c884db1e59410a6d88d75f, run 33539479667). Reconciliation against all three discussion surfaces (inline review threads, top-level comments, and reviews) found no state change: five prior findings (anonymous PATCH body, unconstrained userAssignedIdentityId, two example resource-ID/name mismatches, and a public-IP resource-ID typo) remain fixed and resolved (SKIP-COVERED), and one previously-flagged, still-open issue remains unresolved — the PATCH operationId rename from BastionHosts_UpdateTags to BastionHosts_Update on stable/2026-01-01/virtualNetwork.json (introduced via @renamedFrom(Versions.v2026_01_01, "updateTags") in BastionHost.tsp line 81), most recently reintroduced by commit f03cacf after being fixed in 8be842a1. No matching BreakingChange-Approved-* label is observed at this session SHA (only SDK-language approvals BreakingChange-Go-Sdk-Approved/BreakingChange-JavaScript-Sdk-Approved/BreakingChange-Python-Sdk-Approved are present, which do not count as ARM API-review breaking-change approval). This is already flagged on the existing inline thread (#45630 (comment)); it is not reposted here per reconciliation rules, and no new commits changed its state, so no new resolution action was taken either.

Critic availability: The arm-api-review-critic-runtime subagent reported that its required protocol/template files could not be loaded in this environment, so it returned a failed dispatch rather than a verdict. Per protocol this run proceeds with critic: unknown, no finding is treated as Critic-verified, and no Blocking finding is posted or newly escalated this run.

No new findings were identified in this run across the TypeSpec (BastionHost.tsp, models.tsp), common.json (SessionRecordingIdentityType), and virtualNetwork.json (BastionHostUpdate, BastionSessionRecordingConfiguration, SessionRecordingIdentity, top-level identity on BastionHost) changes. No label changes were made (no new Blocking finding was queued for publication this run).

posted-by: arm-api-reviewer-agent | rule: summary | severity: warning | classification: existing | critic: unknown | head-sha: 4acc7b4

🔍 ARM API review by ARM API Review: Automated Workflow

[Matthew Lee (mwlee29)]

/azp run

[azure-pipelines]

You have several pipelines (over 10) configured to build pull requests in this repository. Specify which pipelines you would like to run by using /azp run [pipelines] command. You can specify multiple pipelines using a comma separated list.