policy assignment arm template

Navigation Menu

Search code, repositories, users, issues, pull requests..., provide feedback.

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly.

To see all available qualifiers, see our documentation .

• Notifications

Sample ARM and Bicep templates for Azure policy and policy initiative definitions

andrewmatveychuk/azure.policy

Folders and files, repository files navigation, azure.policy.

Sample ARM and Bicep (!) templates for Azure policy and policy initiative definitions.

Before starting to work with these templates, read the information in the following blog posts according to your points of interest:

• Audit and Enable Azure Hybrid Benefit using Azure Policy
• How to deploy Azure Policy with Bicep
• How to deploy Azure Policies with ARM templates
• Using ARM templates to deploy Azure Policy initiatives
• How to enforce naming convention for Azure resources
• Automatic tagging for Azure resources
• How to validate Azure tags
• How to ensure proper configuration for your Azure resources

Build status

Getting Started

To start working with this project, clone the repository to your local machine and look for the artifacts in the specific folders:

• linked templates - contains sample ARM templates for policy and initiative definitions plus their assignments grouped by logical area
• main-template - contains master ARM template to perform deployments of all policies and initiatives to a subscription

Build and Test

To create definitions and assignments for policies and initiatives in the target subscription or resource group, use the following build order:

Deploy policy definitions

Deploy policy initiatives

(Optionally) Create a resource group to be used as a target for assignments during testing policy effects

Create policy and initiative assignments

Things to remember

Pay attention to the format of parameters as there are cases when they should be provided as an object type. Look into existing policies and initiatives for examples.

When using deployment scripts in the build/release pipelines, define the script variables in the pipeline ones.

• Bicep 100.0%

A blog about Microsoft Azure

How to – azure policy via arm template.

If you’ve worked with Azure for a while, you would know that one of the most efficient methods of deployment is ARM templates and one of the most powerful services is Azure Policy. What you might not know, is that you can combine the two for efficient, iterative and defined deployments.

A great point I saw recently on Twitter was that a lot of technical posts highlight features and how to use them but rarely go into why you should use them. Conscious of that, here are a couple of points on why I think you should make use of Policy via Template (PvT):

• Quick deployment time – hilariously quick.
• Repeatable defined structures – the exact policy definition, applied to the exact scope, with no possibility of user error.
• Confident flexibility – Templates are idempotent; need to update the definition? Update the template, deploy the update, job done.

So if the “why” makes sense to you, let’s move onto the “how”. If it doesn’t, let me know! I’d love to hear your horror stories/use cases…

Templates can be deployed in several ways, for the sake of simplicity, I’m going to use two tools here. Visual Studio Code and Powershell. Currently you can only deploy subscription scope resources via Powershell or CLI.

There are some other differences to note. The schema for the template must be:

When deploying the template, it must be deployed to a location and given a name (the name of the template will be used if none is specified), that combination is then immutable for that location. So if you need to change location, you need to use a new name etc.

Now, let’s create our template. For this post, I am going to use an existing Template Definition and scope it to my Subscription. While you can pass the Template Parameters via Powershell Variable, for this post I am going to define them as a Template Variable. This is tricky piece of logic as they must be defined as a nested, object array. I also define the policyID via Variable. For existing definitions, you can get this via the Portal, or Powershell command

Now are Policy deployment is defined and ready for use, we deploy using Powershell:

You should receive a succeeded message within your shell and you can verify via the Portal. As it was a subscription level deployment, head to your Subscription blade and check the Deployments tab. You should see the Template listed as the same name as you ran for the deployment.

You can then confirm your settings via heading to Azure Policy and the Assignments blade. You will see your Policy Definition assigned at the scope you set, using the Parameters you set.

Just to go back to an early point on why you’d use this option. Look at the duration of the deployment in the above screengrab – 1 second. You simply cannot beat that!

This can obviously be used for much more complex deployments, for example, defining your own policy inline and deploying via template. The possibilities are endless with one current exception; Subscription is highest scope you can currently use, hopefully Management Groups are on the roadmap and therefore the scaling capability is excellent.

As always, if there are any questions or suggestions, please get in touch!

Share this:

One thought on “ how to – azure policy via arm template ”.

• Pingback: Azure Weekly: October 7, 2019 | Build Azure

Leave a comment Cancel reply

• Already have a WordPress.com account? Log in now.
• Subscribe Subscribed
• Copy shortlink
• Report this content
• View post in Reader
• Manage subscriptions
• Collapse this bar

How to deploy Azure Policy with Bicep

It has been a while since I wrote about Azure Policy last time, plus recently there was a lot of hype around Bicep , so I decided to give it a try and shed some light on creating and deploying custom Azure policies with that new language.

Prerequisites

I assume that you are already familiar with what Azure Policy is and how it works. If you are new to that really helpful and often underrated technology, I suggest checking out my Azure Policy Starter Guide .

Also, I recommend that you read through official Bicep documentation to get some notion about this new domain-specific language, which Microsoft promotes as an abstraction over ARM templates and Azure Resource Manager.

Bicep basics for Azure Policy

Like JSON-based ARM templates, Bicep is a declarative language that allows you to define desired Azure resource configuration and let Azure Resource Manager do its job of provisioning it. Initially, you had to compile a Bicep file into a regular ARM template to deploy your configuration. However, it is not the case anymore as both Azure CLI and Azure PowerShell now support deploying Bicep definitions . Note that input parameters for Bicep definitions are still come in the same format as for old-school ARM templates .

Apart from that, as we work with the same Azure service, you should expect that all Azure Policy specifics are applicable regardless of the language you use to define your configurations. So, all the tips and tricks you learned about creating, deploying and evaluating Azure Policy are still relevant.

Speaking of Bicep, you can define a single policy as well as a policy initiative, aka policy set, along with their assignment to a specific scope using the Bicep resource primitive . For example, to create a custom Azure Policy, you can define the following resource in your Bicep file:

As you might notice from that sample, in order for some policy-specific syntax to be valid, you should use backslash as an escape character for single quotation marks. Also, you shouldn’t use an additional forward square bracket in the expressions as it will be automatically added to the JSON during the Bicep build.

In the same manner, you can define your custom policy initiative:

As policy initiatives don’t define any rules, they use the ‘ policyDefinitions’ keyword to reference existing policy definitions.

Policy and policy initiative assignments are also pretty straightforward and defined as yet another resource:

For complete definitions, look into bicep samples in my Azure Policy repository on GitHub . Besides, the Bicep product team and the community regularly update and create new sample Bicep definitions for various Azure services, including Azure Policy, so I suggest checking them for additional cases.

Advanced technics

Now, when the basics are clear, let’s look into more advanced topics.

First of all, remember that you can deploy your custom Azure policy definitions at the subscription and management group levels only . At the same time, Azure Policy assignments can be created at the management group, subscription, and resource group levels. Also, keep in mind that the deployment scope of a policy, in turn, effectively limits its assignment scope .

The Bicep VS Code extension will warn you about the resources that cannot be deployed to the target scope, and the Bicep compiler will produce the compilation error.

In terms of Bicep definitions, you can scope your deployments by using the ‘ targetScope ’ keyword. Depending on that scope, a bicep file will be compiled into an ARM template using the corresponding deployment schema.

Using different deployment scopes will also impact the way you reference other resources in your configuration. If it is a new resource defined in the same Bicep file, then using standard syntax like ‘ resourceSymbolicName.Id ’ should be enough. However, when you need to reference an existing resource , e.g., a policy definition in policy initiative, first you should correctly define that resource in your Bicep file, and second, you should use the correct reference function:

• for Azure Policy definitions deployed at the subscription level use the ‘ subscriptionResourceId ’ function;
• for Azure Policy definitions deployed at the management group level use the ‘ extensionResourceId ’ function as custom policy definitions are implemented as resource extensions .

If you want to assign your policy at the tenant level, you should use the Tenant Root Group for that.

For example, to reference your existing policy definition deployed at the subscription level in a policy initiative, you can define it as the following:

Same referencing but at the management group level can be accomplished with the following syntax:

I don’t cover the Azure Policy exemptions feature here as it’s currently in preview and might change in the future.

Current drawbacks

Unfortunately, authoring Azure Policies with Bicep is still far from ideal. So, here are a few things that are not specifically related to Azure Policy, but rather Bicep language-generic features or their absence that annoyed me.

As I already mentioned, referencing policies from policy initiatives is a bit complicated and non-intuitive as you must be explicit about your reference scopes and always keep that nuance in mind. On a larger scale, when you have dozens of definitions that are defined in separate files and need to be deployed and assigned at different scopes, the new authoring experience is quite painful.

The next thing, which adds up to the negative authoring and debugging experience, is the lack of IntelliSense support for Azure Policy internal logic defined in Bicep files . What is more, the syntax highlighting for Bicep-defined Azure Policy rules in VS Code is also very limited. Apart from that, I was also unpleasantly surprised that, in contrast to the ARM template authoring experience, Bicep will not warn you about unused parameters or variables you have in your files.

Lastly, the way you currently define human-readable names and descriptions for policy parameters using the Bicep parameter decorators looks a bit awkward for me:

Why not provide the same simplified syntax for the ‘name’ metadata tag for the ‘description’ ?

Fortunately, the Bicep product team makes good progress in implementing new Bicep features and providing the community with simpler and better options for defining Azure infrastructure as code, and I’m impatiently looking forward to new Bicep releases .

If you were writing lots of ARM templates and haven’t tried Bicep yet, I certainly recommend you check it out and post your impressions in the comments below!

Written by:

Andrew Matveychuk

Member discussion:.

Azure RBAC: role assignments and ARM templates

This post is about Azure's role assignments and ARM templates. Role assignments can be thought of as "permissions for Azure".

If you're deploying to Azure, there's a good chance you're using ARM templates to do so. Once you've got past "Hello World", you'll probably find yourself in a situation when you're deploying multiple types of resource to make your solution. For instance, you may be deploying an App Service alongside Key Vault and Storage .

One of the hardest things when it comes to deploying software and having it work, is permissions. Without adequate permissions configured, the most beautiful code can do nothing . Incidentally, this is a good thing. We're deploying to the web; many people are there, not all good. As a different kind of web-head once said:

Azure has great power and suggests you use it wisely .

Access management for cloud resources is critical for any organization that uses the cloud. Azure role-based access control (Azure RBAC) helps you manage who has access to Azure resources, what they can do with those resources, and what areas they have access to. Designating groups or individual roles responsible for specific functions in Azure helps avoid confusion that can lead to human and automation errors that create security risks. Restricting access based on the need to know and least privilege security principles is imperative for organizations that want to enforce security policies for data access.

This is good advice. With that in mind, how can we ensure that the different resources we're deploying to Azure can talk to one another?

Role (up for your) assignments ​

The answer is roles. There's a number of roles that exist in Azure that can be assigned to users, groups, service principals and managed identities. In our own case we're using managed identity for our resources. What we can do is use "role assignments" to give our managed identity access to given resources. Arturo Lucatero gives a great short explanation of this:

Whilst this explanation is delightfully simple, the actual implementation when it comes to ARM templates is a little more involved. Because now it's time to talk "magic" GUIDs. Consider the following truncated ARM template, which gives our managed identity (and hence our App Service which uses this identity) access to Key Vault and Storage:

Let's take a look at these three variables:

The three variables above contain the subscription resource ids for the roles Storage Blob Data Contributor , Key Vault Secrets Officer and Key Vault Crypto Officer . The first question on your mind is likely: "what is ba92f5b4-2d11-453d-a403-e96b0029c9fe and where does it come from?" Great question! Well, each of these GUIDs represents a built-in role in Azure RBAC. The ba92f5b4-2d11-453d-a403-e96b0029c9fe represents the Storage Blob Data Contributor role.

How can I look these up? Well, there's two ways; there's an article which documents them here or you could crack open the Cloud Shell and look up a role by GUID like so:

Or by name like so:

As you can see, the Actions section of the output above (and in even more detail on the linked article ) provides information about what the different roles can do. So if you're looking to enable one Azure resource to talk to another, you should be able to refer to these to identify a role that you might want to use.

Creating a role assignment ​

So now we understand how you identify the roles in question, let's take the final leap and look at assigning those roles to our managed identity. For each role assignment, you'll need a roleAssignments resource defined that looks like this:

Let's go through the above, significant property by significant property (it's also worth checking the official reference here ):

• type - the type of role assignment we want to create, for a key vault it's "Microsoft.KeyVault/vaults/providers/roleAssignments" , for storage it's "Microsoft.Storage/storageAccounts/providers/roleAssignments" . The pattern is that it's the resource type, followed by "/providers/roleAssignments" .
• dependsOn - before we can create a role assignment, we need the service principal we desire to permission (in our case a managed identity) to exist
• properties.roleDefinitionId - the role that we're assigning, provided as an id. So for this example it's the keyVaultCryptoOfficer variable, which was earlier defined as [subscriptionResourceId('Microsoft.Authorization/roleDefinitions', 'ba92f5b4-2d11-453d-a403-e96b0029c9fe')] . (Note the use of the GUID)
• properties.principalId - the id of the principal we're adding permissions for. In our case this is a managed identity (a type of service principal).
• properties.scope - we're modifying another resource; our key vault isn't defined in this ARM template and we want to specify the resource we're granting permissions to.
• properties.principalType - the type of principal that we're creating an assignment for; in our this is "ServicePrincipal" - our managed identity.

There is an alternate approach that you can use where the type is "Microsoft.Authorization/roleAssignments" . Whilst this also works, it displayed errors in the Azure tooling for VS Code . As such, we've opted not to use that approach in our ARM templates.

Many thanks to the awesome John McCormick who wrangled permissions with me until we bent Azure RBAC to our will.

• Role (up for your) assignments
• Creating a role assignment

This browser is no longer supported.

Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.

Microsoft.PolicyInsights remediations

• 1 contributor
• 2018-07-01-preview

Bicep resource definition

The remediations resource type is an extension resource , which means you can apply it to another resource.

Use the scope property on this resource to set the scope for this resource. See Set scope on extension resources in Bicep .

Valid deployment scopes for the remediations resource are:

• Resource groups - See resource group deployment commands
• Subscriptions - See subscription deployment commands
• Management groups - See management group deployment commands

For a list of changed properties in each API version, see change log .

Resource format

To create a Microsoft.PolicyInsights/remediations resource, add the following Bicep to your template.

Property values

Remediations, remediationproperties, remediationpropertiesfailurethreshold, remediationfilters, arm template resource definition.

Use the scope property on this resource to set the scope for this resource. See Set scope on extension resources in ARM templates .

To create a Microsoft.PolicyInsights/remediations resource, add the following JSON to your template.

Terraform (AzAPI provider) resource definition

Use the parent_id property on this resource to set the scope for this resource.

• Resource groups
• Subscriptions
• Management groups

To create a Microsoft.PolicyInsights/remediations resource, add the following Terraform to your template.

Was this page helpful?

Coming soon: Throughout 2024 we will be phasing out GitHub Issues as the feedback mechanism for content and replacing it with a new feedback system. For more information see: https://aka.ms/ContentUserFeedback .

Submit and view feedback for

Additional resources

• Preparing search index...
• The search index is not available
• Public/Protected
• PolicyAssignments

Class PolicyAssignments

Package version

Class representing a PolicyAssignments.

Constructors

Constructor, create byid, delete byid, delete method, list for resource, list for resource group, list for resource group next, list for resource next.

• new Policy Assignments ( client : PolicyClientContext ) : PolicyAssignments

Create a PolicyAssignments.

client: PolicyClientContext

Reference to the service client.

Returns PolicyAssignments

• create ( scope : string , policyAssignmentName : string , parameters : PolicyAssignment , options ?: msRest.RequestOptionsBase ) : Promise < Models.PolicyAssignmentsCreateResponse >
• create ( scope : string , policyAssignmentName : string , parameters : PolicyAssignment , callback : msRest.ServiceCallback < PolicyAssignment > ) : void
• create ( scope : string , policyAssignmentName : string , parameters : PolicyAssignment , options : msRest.RequestOptionsBase , callback : msRest.ServiceCallback < PolicyAssignment > ) : void

This operation creates or updates a policy assignment with the given scope and name. Policy assignments apply to all resources contained within their scope. For example, when you assign a policy at resource group scope, that policy applies to all resources in the group.

Creates or updates a policy assignment.

scope: string

The scope of the policy assignment. Valid scopes are: management group (format: '/providers/Microsoft.Management/managementGroups/{managementGroup}'), subscription (format: '/subscriptions/{subscriptionId}'), resource group (format: '/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}', or resource (format: '/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/{resourceProviderNamespace}/[{parentResourcePath}/]{resourceType}/{resourceName}'

policyAssignmentName: string

The name of the policy assignment.

parameters: PolicyAssignment

Parameters for the policy assignment.

Optional options: msRest.RequestOptionsBase

Returns promise < models.policyassignmentscreateresponse >.

Promise<Models.PolicyAssignmentsCreateResponse>

callback: msRest.ServiceCallback < PolicyAssignment >

The callback

Returns void

Options: msrest.requestoptionsbase.

The optional parameters

• create ById ( policyAssignmentId : string , parameters : PolicyAssignment , options ?: msRest.RequestOptionsBase ) : Promise < Models.PolicyAssignmentsCreateByIdResponse >
• create ById ( policyAssignmentId : string , parameters : PolicyAssignment , callback : msRest.ServiceCallback < PolicyAssignment > ) : void
• create ById ( policyAssignmentId : string , parameters : PolicyAssignment , options : msRest.RequestOptionsBase , callback : msRest.ServiceCallback < PolicyAssignment > ) : void

This operation creates or updates the policy assignment with the given ID. Policy assignments made on a scope apply to all resources contained in that scope. For example, when you assign a policy to a resource group that policy applies to all resources in the group. Policy assignment IDs have this format: '{scope}/providers/Microsoft.Authorization/policyAssignments/{policyAssignmentName}'. Valid scopes are: management group (format: '/providers/Microsoft.Management/managementGroups/{managementGroup}'), subscription (format: '/subscriptions/{subscriptionId}'), resource group (format: '/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}', or resource (format: '/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/{resourceProviderNamespace}/[{parentResourcePath}/]{resourceType}/{resourceName}'.

policyAssignmentId: string

The ID of the policy assignment to create. Use the format '{scope}/providers/Microsoft.Authorization/policyAssignments/{policyAssignmentName}'.

Parameters for policy assignment.

Returns Promise < Models.PolicyAssignmentsCreateByIdResponse >

Promise<Models.PolicyAssignmentsCreateByIdResponse>

• delete ById ( policyAssignmentId : string , options ?: msRest.RequestOptionsBase ) : Promise < Models.PolicyAssignmentsDeleteByIdResponse >
• delete ById ( policyAssignmentId : string , callback : msRest.ServiceCallback < PolicyAssignment > ) : void
• delete ById ( policyAssignmentId : string , options : msRest.RequestOptionsBase , callback : msRest.ServiceCallback < PolicyAssignment > ) : void

This operation deletes the policy with the given ID. Policy assignment IDs have this format: '{scope}/providers/Microsoft.Authorization/policyAssignments/{policyAssignmentName}'. Valid formats for {scope} are: '/providers/Microsoft.Management/managementGroups/{managementGroup}' (management group), '/subscriptions/{subscriptionId}' (subscription), '/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}' (resource group), or '/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/{resourceProviderNamespace}/[{parentResourcePath}/]{resourceType}/{resourceName}' (resource).

Deletes a policy assignment.

The ID of the policy assignment to delete. Use the format '{scope}/providers/Microsoft.Authorization/policyAssignments/{policyAssignmentName}'.

Returns Promise < Models.PolicyAssignmentsDeleteByIdResponse >

Promise<Models.PolicyAssignmentsDeleteByIdResponse>

• delete Method ( scope : string , policyAssignmentName : string , options ?: msRest.RequestOptionsBase ) : Promise < Models.PolicyAssignmentsDeleteMethodResponse >
• delete Method ( scope : string , policyAssignmentName : string , callback : msRest.ServiceCallback < PolicyAssignment > ) : void
• delete Method ( scope : string , policyAssignmentName : string , options : msRest.RequestOptionsBase , callback : msRest.ServiceCallback < PolicyAssignment > ) : void

This operation deletes a policy assignment, given its name and the scope it was created in. The scope of a policy assignment is the part of its ID preceding '/providers/Microsoft.Authorization/policyAssignments/{policyAssignmentName}'.

The name of the policy assignment to delete.

Returns Promise < Models.PolicyAssignmentsDeleteMethodResponse >

Promise<Models.PolicyAssignmentsDeleteMethodResponse>

• get ( scope : string , policyAssignmentName : string , options ?: msRest.RequestOptionsBase ) : Promise < Models.PolicyAssignmentsGetResponse >
• get ( scope : string , policyAssignmentName : string , callback : msRest.ServiceCallback < PolicyAssignment > ) : void
• get ( scope : string , policyAssignmentName : string , options : msRest.RequestOptionsBase , callback : msRest.ServiceCallback < PolicyAssignment > ) : void

This operation retrieves a single policy assignment, given its name and the scope it was created at.

Retrieves a policy assignment.

The name of the policy assignment to get.

Returns Promise < Models.PolicyAssignmentsGetResponse >

Promise<Models.PolicyAssignmentsGetResponse>

• get ById ( policyAssignmentId : string , options ?: msRest.RequestOptionsBase ) : Promise < Models.PolicyAssignmentsGetByIdResponse >
• get ById ( policyAssignmentId : string , callback : msRest.ServiceCallback < PolicyAssignment > ) : void
• get ById ( policyAssignmentId : string , options : msRest.RequestOptionsBase , callback : msRest.ServiceCallback < PolicyAssignment > ) : void

The operation retrieves the policy assignment with the given ID. Policy assignment IDs have this format: '{scope}/providers/Microsoft.Authorization/policyAssignments/{policyAssignmentName}'. Valid scopes are: management group (format: '/providers/Microsoft.Management/managementGroups/{managementGroup}'), subscription (format: '/subscriptions/{subscriptionId}'), resource group (format: '/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}', or resource (format: '/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/{resourceProviderNamespace}/[{parentResourcePath}/]{resourceType}/{resourceName}'.

Retrieves the policy assignment with the given ID.

The ID of the policy assignment to get. Use the format '{scope}/providers/Microsoft.Authorization/policyAssignments/{policyAssignmentName}'.

Returns Promise < Models.PolicyAssignmentsGetByIdResponse >

Promise<Models.PolicyAssignmentsGetByIdResponse>

• list ( options ?: Models.PolicyAssignmentsListOptionalParams ) : Promise < Models.PolicyAssignmentsListResponse >
• list ( callback : msRest.ServiceCallback < PolicyAssignmentListResult > ) : void
• list ( options : PolicyAssignmentsListOptionalParams , callback : msRest.ServiceCallback < PolicyAssignmentListResult > ) : void

This operation retrieves the list of all policy assignments associated with the given subscription that match the optional given $filter. Valid values for $filter are: 'atScope()' or 'policyDefinitionId eq '{value}''. If $filter is not provided, the unfiltered list includes all policy assignments associated with the subscription, including those that apply directly or from management groups that contain the given subscription, as well as any applied to objects contained within the subscription. If $filter=atScope() is provided, the returned list includes all policy assignments that apply to the subscription, which is everything in the unfiltered list except those applied to objects contained within the subscription. If $filter=policyDefinitionId eq '{value}' is provided, the returned list includes all policy assignments of the policy definition whose id is {value}.

Retrieves all policy assignments that apply to a subscription.

Optional options: Models.PolicyAssignmentsListOptionalParams

Returns promise < models.policyassignmentslistresponse >.

Promise<Models.PolicyAssignmentsListResponse>

callback: msRest.ServiceCallback < PolicyAssignmentListResult >

Options: policyassignmentslistoptionalparams.

• list For Resource ( resourceGroupName : string , resourceProviderNamespace : string , parentResourcePath : string , resourceType : string , resourceName : string , options ?: Models.PolicyAssignmentsListForResourceOptionalParams ) : Promise < Models.PolicyAssignmentsListForResourceResponse >
• list For Resource ( resourceGroupName : string , resourceProviderNamespace : string , parentResourcePath : string , resourceType : string , resourceName : string , callback : msRest.ServiceCallback < PolicyAssignmentListResult > ) : void
• list For Resource ( resourceGroupName : string , resourceProviderNamespace : string , parentResourcePath : string , resourceType : string , resourceName : string , options : PolicyAssignmentsListForResourceOptionalParams , callback : msRest.ServiceCallback < PolicyAssignmentListResult > ) : void

This operation retrieves the list of all policy assignments associated with the specified resource in the given resource group and subscription that match the optional given $filter. Valid values for $filter are: 'atScope()' or 'policyDefinitionId eq '{value}''. If $filter is not provided, the unfiltered list includes all policy assignments associated with the resource, including those that apply directly or from all containing scopes, as well as any applied to resources contained within the resource. If $filter=atScope() is provided, the returned list includes all policy assignments that apply to the resource, which is everything in the unfiltered list except those applied to resources contained within the resource. If $filter=policyDefinitionId eq '{value}' is provided, the returned list includes all policy assignments of the policy definition whose id is {value} that apply to the resource. Three parameters plus the resource name are used to identify a specific resource. If the resource is not part of a parent resource (the more common case), the parent resource path should not be provided (or provided as ''). For example a web app could be specified as ({resourceProviderNamespace} == 'Microsoft.Web', {parentResourcePath} == '', {resourceType} == 'sites', {resourceName} == 'MyWebApp'). If the resource is part of a parent resource, then all parameters should be provided. For example a virtual machine DNS name could be specified as ({resourceProviderNamespace} == 'Microsoft.Compute', {parentResourcePath} == 'virtualMachines/MyVirtualMachine', {resourceType} == 'domainNames', {resourceName} == 'MyComputerName'). A convenient alternative to providing the namespace and type name separately is to provide both in the {resourceType} parameter, format: ({resourceProviderNamespace} == '', {parentResourcePath} == '', {resourceType} == 'Microsoft.Web/sites', {resourceName} == 'MyWebApp').

Retrieves all policy assignments that apply to a resource.

resourceGroupName: string

The name of the resource group containing the resource.

resourceProviderNamespace: string

The namespace of the resource provider. For example, the namespace of a virtual machine is Microsoft.Compute (from Microsoft.Compute/virtualMachines)

parentResourcePath: string

The parent resource path. Use empty string if there is none.

resourceType: string

The resource type name. For example the type name of a web app is 'sites' (from Microsoft.Web/sites).

resourceName: string

The name of the resource.

Optional options: Models.PolicyAssignmentsListForResourceOptionalParams

Returns promise < models.policyassignmentslistforresourceresponse >.

Promise<Models.PolicyAssignmentsListForResourceResponse>

options: PolicyAssignmentsListForResourceOptionalParams

• list For Resource Group ( resourceGroupName : string , options ?: Models.PolicyAssignmentsListForResourceGroupOptionalParams ) : Promise < Models.PolicyAssignmentsListForResourceGroupResponse >
• list For Resource Group ( resourceGroupName : string , callback : msRest.ServiceCallback < PolicyAssignmentListResult > ) : void
• list For Resource Group ( resourceGroupName : string , options : PolicyAssignmentsListForResourceGroupOptionalParams , callback : msRest.ServiceCallback < PolicyAssignmentListResult > ) : void

This operation retrieves the list of all policy assignments associated with the given resource group in the given subscription that match the optional given $filter. Valid values for $filter are: 'atScope()' or 'policyDefinitionId eq '{value}''. If $filter is not provided, the unfiltered list includes all policy assignments associated with the resource group, including those that apply directly or apply from containing scopes, as well as any applied to resources contained within the resource group. If $filter=atScope() is provided, the returned list includes all policy assignments that apply to the resource group, which is everything in the unfiltered list except those applied to resources contained within the resource group. If $filter=policyDefinitionId eq '{value}' is provided, the returned list includes all policy assignments of the policy definition whose id is {value} that apply to the resource group.

Retrieves all policy assignments that apply to a resource group.

The name of the resource group that contains policy assignments.

Optional options: Models.PolicyAssignmentsListForResourceGroupOptionalParams

Returns promise < models.policyassignmentslistforresourcegroupresponse >.

Promise<Models.PolicyAssignmentsListForResourceGroupResponse>

options: PolicyAssignmentsListForResourceGroupOptionalParams

• list For Resource Group Next ( nextPageLink : string , options ?: msRest.RequestOptionsBase ) : Promise < Models.PolicyAssignmentsListForResourceGroupNextResponse >
• list For Resource Group Next ( nextPageLink : string , callback : msRest.ServiceCallback < PolicyAssignmentListResult > ) : void
• list For Resource Group Next ( nextPageLink : string , options : msRest.RequestOptionsBase , callback : msRest.ServiceCallback < PolicyAssignmentListResult > ) : void

nextPageLink: string

The NextLink from the previous successful call to List operation.

Returns Promise < Models.PolicyAssignmentsListForResourceGroupNextResponse >

Promise<Models.PolicyAssignmentsListForResourceGroupNextResponse>

• list For Resource Next ( nextPageLink : string , options ?: msRest.RequestOptionsBase ) : Promise < Models.PolicyAssignmentsListForResourceNextResponse >
• list For Resource Next ( nextPageLink : string , callback : msRest.ServiceCallback < PolicyAssignmentListResult > ) : void
• list For Resource Next ( nextPageLink : string , options : msRest.RequestOptionsBase , callback : msRest.ServiceCallback < PolicyAssignmentListResult > ) : void

Returns Promise < Models.PolicyAssignmentsListForResourceNextResponse >

Promise<Models.PolicyAssignmentsListForResourceNextResponse>

• list Next ( nextPageLink : string , options ?: msRest.RequestOptionsBase ) : Promise < Models.PolicyAssignmentsListNextResponse >
• list Next ( nextPageLink : string , callback : msRest.ServiceCallback < PolicyAssignmentListResult > ) : void
• list Next ( nextPageLink : string , options : msRest.RequestOptionsBase , callback : msRest.ServiceCallback < PolicyAssignmentListResult > ) : void

Returns Promise < Models.PolicyAssignmentsListNextResponse >

Promise<Models.PolicyAssignmentsListNextResponse>

Generated using TypeDoc