Skip to content
Merged
Show file tree
Hide file tree
Changes from 4 commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
14 changes: 7 additions & 7 deletions docs/rules.md
Original file line number Diff line number Diff line change
Expand Up @@ -942,12 +942,6 @@ For more detail, pls refer to https://github.com/microsoft/api-guidelines/blob/v

Please refer to [path-resource-type-name-camel-case.md](./path-resource-type-name-camel-case.md) for details.

### Post201Response

Using post for a create operation is discouraged.

Please refer to [post201-response.md](./post201-response.md) for details.

### PostOperationIdContainsUrlVerb

A POST operation's operationId should contain the verb indicated at the end of the corresponding url.
Expand All @@ -962,6 +956,12 @@ Long-running POST operations must have responses with 202 and default return cod

Please refer to [post-response-codes.md](./post-response-codes.md) for details.

### Post201Response

Using post for a create operation is discouraged.

Please refer to [post201-response.md](./post201-response.md) for details.

### PreviewVersionOverOneYear

Per [Retirement-of-Previews](https://dev.azure.com/msazure/AzureWiki/_wiki/wikis/AzureWiki.wiki/37683/Retirement-of-Previews), service, feature, API, and SKU in preview for over one year need to move to GA or retire.
Expand Down Expand Up @@ -1246,7 +1246,7 @@ Please refer to [tags-are-not-allowed-for-proxy-resources.md](./tags-are-not-all

### TenantLevelAPIsNotAllowed

Tenant level APIs are strongly discouraged and subscription or resource group level APIs are preferred instead. The reason for this guidance is that tenant level APIs have a really broad scope and blast radius. We permit APIs to be at this broad scope under rare conditions. Some ARM feature sets also do not cover tenant level APIs such as the use of AFEC. Additionally, if you intend to bypass the standard RBAC constructs and make the APIs unauthorized, you will need an approval from the PAS team before the open API spec can be merged.
This rule checks for th tenant level APIs.

Please refer to [tenant-level-apis-not-allowed.md](./tenant-level-apis-not-allowed.md) for details.

Expand Down
17 changes: 3 additions & 14 deletions docs/tenant-level-apis-not-allowed.md
Original file line number Diff line number Diff line change
Expand Up @@ -2,7 +2,7 @@

## Category

ARM Error
ARM Warning

## Applies to

Expand All @@ -14,22 +14,11 @@ ARM OpenAPI(swagger) specs

## Description

Tenant level APIs are strongly discouraged and subscription or resource group level APIs are preferred instead. The reason for this guidance is that tenant level APIs have a really broad scope and blast radius. We permit APIs to be at this broad scope under rare conditions. Some ARM feature sets also do not cover tenant level APIs such as the use of AFEC. Additionally, if you intend to bypass the standard RBAC constructs and make the APIs unauthorized, you will need an approval from the PAS team before the open API spec can be merged.
This rule checks for th tenant level APIs.

## How to fix the violation

The error can be fixed in one of the following two ways

1. Do not define tenant level APIs
2. Address both the sub sections below

1. Provide a justification as to why you need the APIs to have the broad tenant scope to the ARM API reviewer. To do this, please attend the ARM API review office hours to have a conversation with the ARM API reviewer. To book a slot, please visit aka.ms\armofficehoursinfo.

2. In addition to modeling the API at the tenant scope, if you also intend to add the API to the "allowUnauthorizedActions" list in your ARM manifest, you must present your design and get an exception from the PAS team. Once you get an approval, please share the evidence of the approval by dropping a screenshot of the written approval as a comment on the PR. Please proceed by adding a suppression for the linter error indicating that the exception has been approved by the PAS team. If you do not intend to add the API to the "allowUnauthorizedActions" list in your ARM manifest, please add a suppression indicating the same.

Please use the following guidance to add a suppression - https://github.com/Azure/autorest/blob/main/docs/generate/suppress-warnings.md#suppress-warnings

To get an approval from PAS, please book their office hours slot at https://aka.ms/azurerbacofficehours . You will have to present the scenario and explain why the API needs to be unauthorized. If the service team would like to reach out over email, they can send an email to authzeng@microsoft.com
Tenant level APIs require a review from the security RBAC team during manifest check-in. For details, refer to the Manifest security review process: https://eng.ms/docs/microsoft-security/identity/auth-authz/access-control-managed-identityacmi/policy-administration-service/pas-wiki/livesite/security/manifest

## Good Examples

Expand Down
12 changes: 12 additions & 0 deletions packages/rulesets/CHANGELOG.md
Original file line number Diff line number Diff line change
@@ -1,5 +1,17 @@
# Change Log - @microsoft.azure/openapi-validator-rulesets

## 2.1.8

### Patches

- Modified the rule TenantLevelAPIsNotAllowed RPC-Uri-V1-11 from error to warning

## 2.1.7

### Patches

- Updated autorest package.json to 2.2.4
-
## 2.1.6

### Patches
Expand Down
6 changes: 3 additions & 3 deletions packages/rulesets/generated/spectral/az-arm.js
Original file line number Diff line number Diff line change
Expand Up @@ -2978,7 +2978,7 @@ const tenantLevelAPIsNotAllowed = (pathItems, _opts, ctx) => {
for (const apiPath of apiPaths) {
if (pathItems[apiPath]["put"] && !apiPath.endsWith("/operations") && apiPath.startsWith("/providers")) {
errors.push({
message: `${apiPath} is a tenant level api. Tenant level APIs are strongly discouraged and subscription or resource group level APIs are preferred instead. If you cannot model your APIs at these levels, you will need to present your design and get an exception from PAS team.`,
message: `${apiPath} is a tenant level api. Tenant level APIs require a review from the security RBAC team during manifest check-in. For details, refer to the Manifest security review process: https://eng.ms/docs/microsoft-security/identity/auth-authz/access-control-managed-identityacmi/policy-administration-service/pas-wiki/livesite/security/manifest`,
path: [...path, apiPath],
});
break;
Expand Down Expand Up @@ -3976,9 +3976,9 @@ const ruleset = {
},
TenantLevelAPIsNotAllowed: {
rpcGuidelineCode: "RPC-Uri-V1-11",
description: "Tenant level APIs are strongly discouraged and subscription or resource group level APIs are preferred instead. Design presentation and getting an exception from the PAS team is needed if APIs cannot be modelled at subscription or resource group level.",
description: "Tenant level APIs require a review from the security RBAC team during manifest check-in. For details, refer to the Manifest security review process: https://eng.ms/docs/microsoft-security/identity/auth-authz/access-control-managed-identityacmi/policy-administration-service/pas-wiki/livesite/security/manifest",
message: "{{error}}",
severity: "error",
severity: "warn",
resolved: true,
formats: [oas2],
given: "$[paths,'x-ms-paths']",
Expand Down
2 changes: 1 addition & 1 deletion packages/rulesets/package.json
Original file line number Diff line number Diff line change
@@ -1,6 +1,6 @@
{
"name": "@microsoft.azure/openapi-validator-rulesets",
"version": "2.1.7",
"version": "2.1.8",
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a reason we are doing version bump/prod release just for this 1 update?

Copy link
Copy Markdown
Member

@mikeharder mikeharder Aug 15, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since this is a shared repo, I think we should use a process where main is always "ready to release":

  1. Release version x.y.z
  2. In next PR to repo, update version to x.y.(z+1), either in a dedicated PR, or along with the next code change. Also update changelog.
  3. After PR is merged, main is "ready to release", but it doesn't mean "must release".
  4. If you don't want to release yet, keep merging more PRs, updating changelog, etc.
  5. If you do want to release, go ahead at any time. The release will include your all changes queued in main since last release.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That said, why not be more agile, and publish and update the specs repo after each fix? It should be much easier than before:

  1. Trigger publish of azure-openapi-validator to npmjs
  2. Update package.json files in azure-rest-api-specs (manually or by triggering dependabot)

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks Mike,
Hey @AkhilaIlla, this code is ready to release so I had to update the package

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thanks @mikeharder for the details. However, I think we need to have a deeper discussion to figure out the right process for our use case.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thanks @mikeharder for the details. However, I think we need to have a deeper discussion to figure out the right process for our use case.

what is your proposed alternative strategy?

"description": "Azure OpenAPI Validator",
"main": "dist/index.js",
"scripts": {
Expand Down
4 changes: 2 additions & 2 deletions packages/rulesets/src/spectral/az-arm.ts
Original file line number Diff line number Diff line change
Expand Up @@ -950,9 +950,9 @@ const ruleset: any = {
TenantLevelAPIsNotAllowed: {
rpcGuidelineCode: "RPC-Uri-V1-11",
description:
"Tenant level APIs are strongly discouraged and subscription or resource group level APIs are preferred instead. Design presentation and getting an exception from the PAS team is needed if APIs cannot be modelled at subscription or resource group level.",
"Tenant level APIs require a review from the security RBAC team during manifest check-in. For details, refer to the Manifest security review process: https://eng.ms/docs/microsoft-security/identity/auth-authz/access-control-managed-identityacmi/policy-administration-service/pas-wiki/livesite/security/manifest",
message: "{{error}}",
severity: "error",
severity: "warn",
resolved: true,
formats: [oas2],
given: "$[paths,'x-ms-paths']",
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -17,7 +17,7 @@ export const tenantLevelAPIsNotAllowed = (pathItems: any, _opts: any, ctx: any)
for (const apiPath of apiPaths) {
if (pathItems[apiPath]["put"] && !apiPath.endsWith("/operations") && apiPath.startsWith("/providers")) {
errors.push({
message: `${apiPath} is a tenant level api. Tenant level APIs are strongly discouraged and subscription or resource group level APIs are preferred instead. If you cannot model your APIs at these levels, you will need to present your design and get an exception from PAS team.`,
message: `${apiPath} is a tenant level api. Tenant level APIs require a review from the security RBAC team during manifest check-in. For details, refer to the Manifest security review process: https://eng.ms/docs/microsoft-security/identity/auth-authz/access-control-managed-identityacmi/policy-administration-service/pas-wiki/livesite/security/manifest`,
path: [...path, apiPath],
})
break
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -2,7 +2,7 @@ import { Spectral } from "@stoplight/spectral-core"
import linterForRule from "./utils"

const ERROR_MESSAGE =
"is a tenant level api. Tenant level APIs are strongly discouraged and subscription or resource group level APIs are preferred instead. If you cannot model your APIs at these levels, you will need to present your design and get an exception from PAS team."
Comment thread
tejaswiMinnu marked this conversation as resolved.
"is a tenant level api. Tenant level APIs require a review from the security RBAC team during manifest check-in. For details, refer to the Manifest security review process: https://eng.ms/docs/microsoft-security/identity/auth-authz/access-control-managed-identityacmi/policy-administration-service/pas-wiki/livesite/security/manifest"

let linter: Spectral

Expand Down
Loading