Bernie White
GitHub
Родитель
f4ac6c4418
Коммит
f147ba266b
|
|
@ -6,7 +6,7 @@ A suite of rules to validate Azure resources and infrastructure as code (IaC) us
|
|||
|
||||
Features of PSRule for Azure include:
|
||||
|
||||
- [Ready to go](https://azure.github.io/PSRule.Rules.Azure/features/#readytogo) - Leverage over 230 pre-built rules to validate Azure resources.
|
||||
- [Ready to go](https://azure.github.io/PSRule.Rules.Azure/features/#readytogo) - Leverage over 250 pre-built rules to validate Azure resources.
|
||||
- [DevOps](https://azure.github.io/PSRule.Rules.Azure/features/#devops) - Validate resources and infrastructure code pre or post-deployment.
|
||||
- [Cross-platform](https://azure.github.io/PSRule.Rules.Azure/features/#cross-platform) - Run on MacOS, Linux, and Windows.
|
||||
|
||||
|
|
|
|||
|
|
@ -0,0 +1,180 @@
|
|||
---
|
||||
author: BernieWhite
|
||||
---
|
||||
|
||||
# Expanding source files
|
||||
|
||||
PSRule for Azure supports analyzing resources contained within Azure Infrastructure as Code.
|
||||
|
||||
!!! Abstract
|
||||
This topic covers what source expansion is and how to use it within PSRule for Azure.
|
||||
|
||||
## Source expansion
|
||||
|
||||
PSRule for Azure goes beyond linting Azure Bicep and template files for syntax.
|
||||
Source expansion performs context specific static analysis on Azure resources.
|
||||
Azure resources are analyzed before deployment as if they are deployed.
|
||||
|
||||
This provides some unique benefits such as:
|
||||
|
||||
- **Improve success** — Azure resources are resolved before deployment,
|
||||
increasing success by finding errors earlier such as within a PR.
|
||||
- Detect common templates issues such as missing parameters and JSON structure.
|
||||
- Identify deployment issues such as invalid resource names and incorrect resource identifiers.
|
||||
- **As deployed** — Analysis of Azure resources against Azure WAF as if they are deployed.
|
||||
- Parameters, conditional resources, functions (built-in and user defined), variables,
|
||||
and copy loops are resolved.
|
||||
- Azure resource names are shown in passing and failing results.
|
||||
Resolving issues with resource configurations can be targeted by resource.
|
||||
- Resource file locations for template and parameter files are included in results.
|
||||
- **Suppression by resource name** — Azure resource names can be used to apply exceptions.
|
||||
- Suppression allows for individual resources to be excluded from rules by name.
|
||||
- **Offline support** — Static analysis is performed against source files instead of deployed resources.
|
||||
- Some functions that may be included in templates dynamically query Azure for current state.
|
||||
For these functions standard placeholder values are used by default.
|
||||
Functions that use placeholders include `reference`, `list*`.
|
||||
|
||||
### Feature support
|
||||
|
||||
Source expansion is supported with:
|
||||
|
||||
- **Azure template and parameter files** — Azure templates are expanded from parameter files.
|
||||
Link parameter files to templates by metadata or naming convention.
|
||||
See [Using templates](using-templates.md) for a detailed explaination of how to do this.
|
||||
- **Azure Bicep deployments** — Files with the `.bicep` extension are detected and expanded.
|
||||
See [Using Bicep source](using-bicep.md) for a detailed explaination of how to do this.
|
||||
- **Azure Bicep modules with tests** — Reusable Bicep modules can be expanded with tests.
|
||||
See [Using Bicep source](using-bicep.md) for a detailed explaination of how to do this.
|
||||
|
||||
### Limitations
|
||||
|
||||
Currently the following limitations apply:
|
||||
|
||||
- Required parameters in must be provided in parameter files or Bicep deployments.
|
||||
- Nested templates are expanded, external templates are not.
|
||||
- Deployment resources that link to an external template are returned as a resource.
|
||||
- Sub-resources such as diagnostic logs or configurations are automatically nested.
|
||||
Automatic nesting a sub-resource requires:
|
||||
- The parent resource is defined in the same template.
|
||||
- The sub-resource depends on the parent resource.
|
||||
- The `environment()` template function always returns values for Azure public cloud.
|
||||
- References to Key Vault secrets are not expanded.
|
||||
A placeholder value is used instead.
|
||||
- Multi-line strings are not supported.
|
||||
- Template expressions up to a maximum of 100,000 characters are supported.
|
||||
|
||||
In addition, currently the following limitation apply to using Bicep source files:
|
||||
|
||||
- The Bicep CLI must be installed.
|
||||
When using GitHub Actions or Azure Pipelines the Bicep CLI is pre-installed.
|
||||
- Location of issues in Bicep source files is not supported.
|
||||
- Expansion of Bicep source files times out after 5 seconds.
|
||||
|
||||
[1]: using-templates.md#featuresupport
|
||||
[2]: setup/configuring-expansion.md#excludingfiles
|
||||
|
||||
## Strong type
|
||||
|
||||
String parameters are commonly used to pass values such as a resource Id or location.
|
||||
PSRule for Azure provides additional support to allow parameters to be strongly typed.
|
||||
When a parameter is strongly typed, the value is checked against the type during expansion.
|
||||
|
||||
To configure a strong type for a parameter set the `strongType` metadata property on the parameter.
|
||||
The strong type will be set to the resource type that the parameter will accept, such as `Microsoft.OperationalInsights/workspaces`.
|
||||
|
||||
=== "Template"
|
||||
|
||||
```json
|
||||
{
|
||||
"$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
|
||||
"contentVersion": "1.0.0.0",
|
||||
"parameters": {
|
||||
"workspaceId": {
|
||||
"type": "string",
|
||||
"metadata": {
|
||||
"description": "The resource identifer for a Log Analytics workspace.",
|
||||
"strongType": "Microsoft.OperationalInsights/workspaces"
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
=== "Bicep"
|
||||
|
||||
```bicep
|
||||
@metadata({
|
||||
strongType: 'Microsoft.OperationalInsights/workspaces'
|
||||
})
|
||||
@description('The resource identifer for a Log Analytics workspace.')
|
||||
param workspaceId string
|
||||
```
|
||||
|
||||
Strong type also supports the following non-resource type values:
|
||||
|
||||
- `location` - Specifies the parameter must contain any valid Azure location.
|
||||
|
||||
## Scope functions
|
||||
|
||||
Azure deployments support a number of [scope functions][3] can be used within Infrastructure as Code.
|
||||
When using PSRule for Azure, these functions have a default meaning that can be configured.
|
||||
|
||||
When configuring scope functions, only the properties you want to override has to be specified.
|
||||
Unspecified properties will inherit from the defaults.
|
||||
|
||||
[3]: https://docs.microsoft.com/azure/azure-resource-manager/templates/template-functions-scope
|
||||
|
||||
### Subscription
|
||||
|
||||
The `subscription()` function will return the following unless overridden:
|
||||
|
||||
```yaml
|
||||
subscriptionId: 'ffffffff-ffff-ffff-ffff-ffffffffffff'
|
||||
displayName: 'PSRule Test Subscription'
|
||||
state: 'NotDefined'
|
||||
```
|
||||
|
||||
To override, configure [`AZURE_SUBSCRIPTION`](setup/configuring-expansion.md#deploymentsubscription).
|
||||
|
||||
### Resource Group
|
||||
|
||||
The `resourceGroup()` function will return the following unless overridden:
|
||||
|
||||
```yaml
|
||||
name: 'ps-rule-test-rg'
|
||||
location: 'eastus'
|
||||
tags: { }
|
||||
properties:
|
||||
provisioningState: 'Succeeded'
|
||||
```
|
||||
|
||||
To override, configure [`AZURE_RESOURCE_GROUP`](setup/configuring-expansion.md#deploymentresourcegroup).
|
||||
|
||||
### Tenant
|
||||
|
||||
The `tenant()` function will return the following unless overridden:
|
||||
|
||||
```yaml
|
||||
countryCode: 'US'
|
||||
tenantId: 'ffffffff-ffff-ffff-ffff-ffffffffffff'
|
||||
displayName: 'PSRule'
|
||||
```
|
||||
|
||||
To override, configure [`AZURE_TENANT`](setup/configuring-expansion.md#deploymenttenant).
|
||||
|
||||
### Management Group
|
||||
|
||||
The `managementGroup()` function will return the following unless overridden:
|
||||
|
||||
```yaml
|
||||
name: 'psrule-test'
|
||||
properties:
|
||||
displyName: 'PSRule Test Management Group'
|
||||
```
|
||||
|
||||
To override, configure [`AZURE_MANAGEMENT_GROUP`](setup/configuring-expansion.md#deploymentmanagementgroup).
|
||||
|
||||
*[WAF]: Well-Architected Framework
|
||||
*[ARM]: Azure Resource Manager
|
||||
*[PR]: Pull Request
|
||||
*[JSON]: JavaScript Object Notation
|
||||
|
|
@ -77,7 +77,8 @@ If we didn't tell you, you might not even know that PowerShell runs under the co
|
|||
To perform local validation, some PowerShell setup is required but we step you through that.
|
||||
See [installation][7] and [validating locally][8] for details.
|
||||
|
||||
To start writing your own custom rules, some PowerShell experience is required.
|
||||
To start writing your own custom rules you can use YAML, JSON, or PowerShell
|
||||
PowerShell experience is required for some scenarios.
|
||||
We have a walk through scenario [Enforcing custom tags][9] to get you started.
|
||||
|
||||
[7]: install-instructions.md
|
||||
|
|
|
|||
|
|
@ -25,7 +25,7 @@ This allows you to explore and learn the context of each WAF principle.
|
|||
|
||||
## Ready to go
|
||||
|
||||
PSRule for Azure includes over 230 rules for validating resources against configuration recommendations.
|
||||
PSRule for Azure includes over 250 rules for validating resources against configuration recommendations.
|
||||
Rules automatically detect and analyze resources from Azure IaC artifacts.
|
||||
This allows you to quickly light up unit testing of Azure resources from templates and Bicep deployments.
|
||||
|
||||
|
|
@ -40,7 +40,7 @@ As new built-in rules are added and improved, download the latest version to sta
|
|||
|
||||
- [Enforcing custom tags][3].
|
||||
|
||||
[3]: customization/enforce-custom-tags/index.md
|
||||
[3]: customization/enforce-custom-tags.md
|
||||
|
||||
## DevOps integrated
|
||||
|
||||
|
|
@ -53,11 +53,6 @@ Pre-flight validation can be integrated into a continuous integration (CI) pipel
|
|||
- **Quality gates** — Implement quality gates between environments such as development, test, and production.
|
||||
- **Monitor continuously** — Perform ongoing checks for configuration optimization opportunities.
|
||||
|
||||
<!-- PSRule for Azure provides the following cmdlets that extract data for analysis:
|
||||
|
||||
- [Export-AzRuleTemplateData](commands/Export-AzRuleTemplateData.md) - Used for pre-flight analysis of one or more ARM templates.
|
||||
- [Export-AzRuleData](commands/Export-AzRuleData.md) - Used for in-flight analysis of resources deployed to one or more Azure subscriptions. -->
|
||||
|
||||
## Cross-platform
|
||||
|
||||
PSRule for Azure uses modern PowerShell libraries at its core,
|
||||
|
|
|
|||
|
|
@ -21,13 +21,16 @@ Here are some examples:
|
|||
|
||||
```yaml
|
||||
requires:
|
||||
# Require a minimum of PSRule for Azure v1.4.1
|
||||
PSRule.Rules.Azure: '>=1.4.1'
|
||||
# Require a minimum of PSRule for Azure v1.10.2
|
||||
PSRule.Rules.Azure: '>=1.10.2'
|
||||
|
||||
configuration:
|
||||
# Enable parameter file expansion
|
||||
# Enable expansion of Azure Template files.
|
||||
AZURE_PARAMETER_FILE_EXPANSION: true
|
||||
|
||||
# Enable expansion of Azure Bicep files.
|
||||
AZURE_BICEP_FILE_EXPANSION: true
|
||||
|
||||
rule:
|
||||
# Enable custom rules that don't exist in the baseline
|
||||
includeLocal: true
|
||||
|
|
|
|||
|
|
@ -4,7 +4,13 @@ author: BernieWhite
|
|||
|
||||
# Using Bicep source
|
||||
|
||||
PSRule for Azure also supports analyzing Azure resources contained within Bicep source files.
|
||||
PSRule for Azure discovers and analyzes Azure resources contained within Bicep files.
|
||||
To enable this feature, you need to:
|
||||
|
||||
- Enable expansion.
|
||||
- For modules (if used):
|
||||
- Define a deployment.
|
||||
- Configure path exclusions.
|
||||
|
||||
!!! Experimental
|
||||
Support for Bicep source files is currently an experimental feature.
|
||||
|
|
@ -12,38 +18,111 @@ PSRule for Azure also supports analyzing Azure resources contained within Bicep
|
|||
Please give us [feedback] on this feature and report any [issues] you encounter.
|
||||
|
||||
!!! Abstract
|
||||
This topic covers how to use use PSRule for Azure to validate Azure resources within Bicep source.
|
||||
This topic covers how you can validate Azure resources within `.bicep` files.
|
||||
To learn more about why this is important see [Expanding source files](expanding-source-files.md).
|
||||
|
||||
## Source file expansion
|
||||
## Enabling expansion
|
||||
|
||||
Bicep source files provide an additional option to define Azure resources.
|
||||
Bicep provides a abstraction layer on top of Azure Resource Manager (ARM) that is more human readable.
|
||||
When Azure resources are built from Bicep source files, an ARM template is generated.
|
||||
PSRule for Azure automates this in memory to allow analysis of Azure resources from `.bicep` files.
|
||||
To expand Bicep deployments configure `ps-rule.yaml` with the `AZURE_BICEP_FILE_EXPANSION` option.
|
||||
|
||||
### Feature support
|
||||
|
||||
Expansion of Azure resources contained within Bicep source files is supported.
|
||||
For details on how this works and limitations see [Using templates][1].
|
||||
|
||||
In addition, currently the following limitation apply to using Bicep source files:
|
||||
|
||||
- The Bicep CLI must be installed.
|
||||
- PSRule for Azure will only expand Bicep source files without mandatory parameters.
|
||||
To modules with mandatory parameters you can [exclude files by path spec][2].
|
||||
Expand from a `main.bicep` that is intended to be deployed directly to Azure.
|
||||
- Location of issues in Bicep source files is not supported.
|
||||
- Expansion of Bicep source files times out after 5 seconds.
|
||||
|
||||
[1]: using-templates.md#featuresupport
|
||||
[2]: setup/configuring-expansion.md#excludingfiles
|
||||
```yaml
|
||||
# YAML: Enable expansion for Bicep source files.
|
||||
configuration:
|
||||
AZURE_BICEP_FILE_EXPANSION: true
|
||||
```
|
||||
|
||||
### Setup Bicep
|
||||
|
||||
To expand Azure resources for analysis from Bicep source files the Bicep CLI is required.
|
||||
For details on how to configure Bicep for PSRule for Azure see [Setup Bicep][3].
|
||||
The Bicep CLI is already installed on hosted runners and agents used by GitHub Actions and Azure Pipelines.
|
||||
For details on how to configure Bicep for PSRule for Azure see [Setup Bicep][1].
|
||||
|
||||
[3]: setup/setup-bicep.md
|
||||
[1]: setup/setup-bicep.md
|
||||
|
||||
### Building files
|
||||
|
||||
It's not nessecary to build `.bicep` files with `bicep build` or `az bicep build`.
|
||||
PSRule will automatically detect and build `.bicep` files.
|
||||
You may choose to pre-build `.bicep` files if the Bicep CLI is not available when PSRule is run.
|
||||
|
||||
!!! Important
|
||||
If using this method, follow [Using templates](using-templates.md) instead.
|
||||
Using `bicep build` transpiles Bicep code into an Azure template `.json`.
|
||||
|
||||
## Testing Bicep modules
|
||||
|
||||
Bicep allows you to separate out complex details into separate files called [modules][2].
|
||||
To expand resources, any parameters must be resolved.
|
||||
|
||||
Two types of parameters exist, _required_ (also called mandatory) and _optional_.
|
||||
An optional parameter is any parameter with a default value.
|
||||
Required parameters do not have a default value and must be specified.
|
||||
|
||||
!!! Example "Example `modules/storage/main.bicep`"
|
||||
|
||||
```bicep
|
||||
// Required parameter
|
||||
param name string
|
||||
|
||||
// Optional parameters
|
||||
param location string = resourceGroup().location
|
||||
param sku string = 'Standard_LRS'
|
||||
```
|
||||
|
||||
To specify required parameters for a module, create a deployment or test that references the module.
|
||||
|
||||
!!! Example "Example `deploy.bicep`"
|
||||
|
||||
```bicep
|
||||
// Deploy storage account to production subscription
|
||||
module storageAccount './modules/storage/main.bicep' = {
|
||||
name: 'deploy-storage'
|
||||
params: {
|
||||
name: 'stpsrulebicep001'
|
||||
sku: 'Standard_GRS'
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
!!! Example "Example `modules/storage/.tests/main.tests.bicep`"
|
||||
|
||||
```bicep
|
||||
// Test with only required parameters
|
||||
module test_required_params '../main.bicep' = {
|
||||
name: 'test_required_params'
|
||||
params: {
|
||||
name: 'sttest001'
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
[2]: https://docs.microsoft.com/azure/azure-resource-manager/bicep/modules
|
||||
|
||||
### Configuring path exclusions
|
||||
|
||||
Unless configured, PSRule will discover all `.bicep` files when expansion is enabled.
|
||||
Bicep module files with required parameters will not be able be expanded and should be excluded.
|
||||
Instead expand resources from deployments or tests.
|
||||
|
||||
To do this configure `ps-rule.yaml` with the `input.pathIgnore` option.
|
||||
|
||||
!!! Example "Example `ps-rule.yaml`"
|
||||
|
||||
```yaml
|
||||
configuration:
|
||||
# Enable expansion for Bicep source files.
|
||||
AZURE_BICEP_FILE_EXPANSION: true
|
||||
|
||||
input:
|
||||
pathIgnore:
|
||||
# Exclude module files
|
||||
- 'modules/**/*.bicep'
|
||||
# Include test files from modules
|
||||
- '!modules/**/*.tests.bicep'
|
||||
```
|
||||
|
||||
!!! Note
|
||||
In this examplem, Bicep files such as `deploy.bicep` in other directories will be expanded.
|
||||
|
||||
*[WAF]: Well-Architected Framework
|
||||
*[ARM]: Azure Resource Manager
|
||||
|
|
|
|||
|
|
@ -4,101 +4,29 @@ author: BernieWhite
|
|||
|
||||
# Using templates
|
||||
|
||||
PSRule for Azure detects Azure template and parameter files in your repository based on their schemas.
|
||||
This provides template and parameter file linting for structure and general usage.
|
||||
PSRule for Azure discovers and analyzes Azure resources contained within template and parameter files.
|
||||
To enable this feature, you need to:
|
||||
|
||||
- Enable expansion.
|
||||
- Link parameter files to templates.
|
||||
|
||||
!!! Abstract
|
||||
This topic covers how to use Azure templates and metadata to improve the success of Azure deployments.
|
||||
This topic covers how you can validate Azure resources within template `.json` files.
|
||||
To learn more about why this is important see [Expanding source files](expanding-source-files.md).
|
||||
|
||||
## Parameter file expansion
|
||||
## Enabling expansion
|
||||
|
||||
In additional to template and parameter file linting,
|
||||
PSRule for Azure can automatically resolve template and parameter file context at runtime.
|
||||
Resolved context provides some unique benefits such as:
|
||||
|
||||
- **Improve success** — Templates are resolved before deployment.
|
||||
- Detect issues with invalid resource names, missing parameters, and JSON structure.
|
||||
- Increases success of deployments by finding errors earlier such as within a PR.
|
||||
- **As deployed** — Analysis of Azure resources against Azure WAF as if they are deployed.
|
||||
- Parameters, conditional resources, functions (built-in and user defined), variables,
|
||||
and copy loops are resolved.
|
||||
- Azure resource names are shown in passing and failing results.
|
||||
Resolving issues with resource configurations can be targeted by resource.
|
||||
- Resource file locations for template and parameter files are included in results.
|
||||
- **Suppression by resource name** — Azure resource names can be used to apply exceptions.
|
||||
- Suppression allows for individual resources to be excluded from rules by name.
|
||||
|
||||
To get these benefits, Azure parameter files must be associated to templates.
|
||||
PSRule for Azure uses links to achieve this.
|
||||
|
||||
!!! Note
|
||||
Azure parameter file expansion needs to be enabled.
|
||||
It is not enabled by default to preserve the default behavior prior to PSRule for Azure v1.4.0.
|
||||
[Creating your pipeline][1] covers how to enable this in a CI pipeline.
|
||||
|
||||
[1]: creating-your-pipeline.md#expandtemplateparameterfiles
|
||||
|
||||
### Feature support
|
||||
|
||||
Expansion of Azure template parameter files works with Azure Resource Manager (ARM) features.
|
||||
By default this is an offline process, requiring no connectivity to Azure.
|
||||
Some functions that may be included in templates dynamically query Azure for current state.
|
||||
For these functions standard placeholder values are used by default.
|
||||
Functions that use placeholders include `reference`, `list*`.
|
||||
|
||||
The `subscription()` function will return the following unless overridden with `AZURE_SUBSCRIPTION`:
|
||||
To expand parameter files configure `ps-rule.yaml` with the `AZURE_PARAMETER_FILE_EXPANSION` option.
|
||||
|
||||
```yaml
|
||||
subscriptionId: 'ffffffff-ffff-ffff-ffff-ffffffffffff'
|
||||
displayName: 'PSRule Test Subscription'
|
||||
state: 'NotDefined'
|
||||
# YAML: Enable expansion for template expansion.
|
||||
configuration:
|
||||
AZURE_PARAMETER_FILE_EXPANSION: true
|
||||
```
|
||||
|
||||
The `resourceGroup()` function will return the following unless overridden with `AZURE_RESOURCE_GROUP`:
|
||||
## Linking templates
|
||||
|
||||
```yaml
|
||||
name: 'ps-rule-test-rg'
|
||||
location: 'eastus'
|
||||
tags: { }
|
||||
properties:
|
||||
provisioningState: 'Succeeded'
|
||||
```
|
||||
|
||||
The `tenant()` function will return the following unless overridden with `AZURE_TENANT`:
|
||||
|
||||
```yaml
|
||||
countryCode: 'US'
|
||||
tenantId: 'ffffffff-ffff-ffff-ffff-ffffffffffff'
|
||||
displayName: 'PSRule'
|
||||
```
|
||||
|
||||
The `managementGroup()` function will return the following unless overridden with `AZURE_MANAGEMENT_GROUP`:
|
||||
|
||||
```yaml
|
||||
name: 'psrule-test'
|
||||
properties:
|
||||
displyName: 'PSRule Test Management Group'
|
||||
```
|
||||
|
||||
To override, see [Configuring expansion](setup/configuring-expansion.md).
|
||||
|
||||
Currently the following limitations apply:
|
||||
|
||||
- Nested templates are expanded, external templates are not.
|
||||
- Deployment resources that link to an external template are returned as a resource.
|
||||
- Sub-resources such as diagnostic logs or configurations are automatically nested.
|
||||
Automatic nesting a sub-resource requires:
|
||||
- The parent resource is defined in the same template.
|
||||
- The sub-resource depends on the parent resource.
|
||||
- The `environment` template function always returns values for Azure public cloud.
|
||||
- References to Key Vault secrets are not expanded.
|
||||
A placeholder value is used instead.
|
||||
- Multi-line strings are not supported.
|
||||
- Template expressions up to a maximum of 100,000 characters are supported.
|
||||
|
||||
## Template links
|
||||
|
||||
PSRule for Azure automatically detects parameter files and uses the following logic to associate templates.
|
||||
PSRule for Azure automatically detects parameter files and uses the following logic to link templates.
|
||||
|
||||
- **By metadata** — Check parameter file for a metadata link identifying the associated template.
|
||||
- **By naming convention** — Check for matching template files using file naming convention.
|
||||
|
|
@ -107,7 +35,7 @@ PSRule for Azure automatically detects parameter files and uses the following lo
|
|||
Metadata links take priority over naming convention.
|
||||
For details on both options continue reading.
|
||||
|
||||
### Metadata links
|
||||
### By metadata
|
||||
|
||||
A parameter file can be linked to an associated template by setting metadata.
|
||||
To link a template within a parameter file, set the `metadata.template` property to the path of the template.
|
||||
|
|
@ -172,7 +100,7 @@ Additional benefits you get by using metadata links include:
|
|||
|
||||
[2]: setup/configuring-expansion.md#requiretemplatemetadatalink
|
||||
|
||||
### Naming convention
|
||||
### By naming convention
|
||||
|
||||
When metadata links are not set, PSRule for Azure will use a naming convention to link to template files.
|
||||
PSRule for Azure uses the parameter file prefix `<templateName>.parameters.json` to link to a template.
|
||||
|
|
@ -181,47 +109,6 @@ When linking using naming convention, the template and the parameter file must b
|
|||
!!! Example
|
||||
A parameter file named `azuredeploy.parameters.json` links to the template file named `azuredeploy.json`.
|
||||
|
||||
## Strong type
|
||||
|
||||
String parameters are commonly used to pass values such as a resource Id or location.
|
||||
PSRule for Azure provides additional support to allow parameters to be strongly typed.
|
||||
When a parameter is strongly typed, the value is checked against the type during expansion.
|
||||
|
||||
To configure a strong type for a parameter set the `strongType` metadata property within the template.
|
||||
The strong type will be set to the resource type that the parameter will accept, such as `Microsoft.OperationalInsights/workspaces`.
|
||||
|
||||
=== "Azure template"
|
||||
|
||||
```json
|
||||
{
|
||||
"$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
|
||||
"contentVersion": "1.0.0.0",
|
||||
"parameters": {
|
||||
"workspaceId": {
|
||||
"type": "string",
|
||||
"metadata": {
|
||||
"description": "The resource identifer for a Log Analytics workspace.",
|
||||
"strongType": "Microsoft.OperationalInsights/workspaces"
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
=== "Azure Bicep"
|
||||
|
||||
```bicep
|
||||
@metadata({
|
||||
description: 'The resource identifer for a Log Analytics workspace.'
|
||||
strongType: 'Microsoft.OperationalInsights/workspaces'
|
||||
})
|
||||
param workspaceId string
|
||||
```
|
||||
|
||||
Strong type also supports the following non-resource type values:
|
||||
|
||||
- `location` - Specifies the parameter must contain any valid Azure location.
|
||||
|
||||
*[WAF]: Well-Architected Framework
|
||||
*[ARM]: Azure Resource Manager
|
||||
*[CI]: continuous integration
|
||||
|
|
|
|||
|
|
@ -25,7 +25,7 @@ The Visual Studio Code extension includes a built-in `PSRule: Run analysis` task
|
|||
<img src="https://raw.githubusercontent.com/microsoft/PSRule-vscode/main/docs/images/tasks-provider.png" alt="Built-in tasks shown in task list" />
|
||||
</p>
|
||||
|
||||
To learn about tasks in Visual Studio Code see [Integrate with External Tools via Tasks][3].
|
||||
To learn about tasks in Visual Studio Code see [Integrate with External Tools via Tasks][4].
|
||||
|
||||
To use PSRule for Azure with the built-in `PSRule: Run analysis` task, insert the following into `.vscode/tasks.json`.
|
||||
|
||||
|
|
|
|||
|
|
@ -43,11 +43,13 @@ nav:
|
|||
- Features: features.md
|
||||
- FAQ: faq.md
|
||||
- Installation: install-instructions.md
|
||||
- Using templates: using-templates.md
|
||||
- Using Bicep source: using-bicep.md
|
||||
- Testing infrastructure code:
|
||||
- Expanding source files: expanding-source-files.md
|
||||
- Using templates: using-templates.md
|
||||
- Using Bicep source: using-bicep.md
|
||||
- Working with baselines: working-with-baselines.md
|
||||
- Creating your pipeline: creating-your-pipeline.md
|
||||
- Validating locally: validating-locally.md
|
||||
- Working with baselines: working-with-baselines.md
|
||||
- Customization:
|
||||
- Storing custom rules: customization/storing-custom-rules.md
|
||||
- Enforcing custom tags: customization/enforce-custom-tags.md
|
||||
|
|
|
|||
|
|
@ -316,7 +316,7 @@
|
|||
<div>
|
||||
{% include ".icons/octicons/rocket-24.svg" %}
|
||||
<h3 class="h4 text-brand font-weight-600 mb-3">Ready to go</h3>
|
||||
<p>Leverage over 230 pre-built rules to test Azure resources.</p>
|
||||
<p>Leverage over 250 pre-built rules to test Azure resources.</p>
|
||||
</div>
|
||||
</a>
|
||||
<a class="tile" href="{{ page.next_page.url | url }}#devops" target="_self" rel="noopener">
|
||||
|
|
|
|||
Загрузка…
Ссылка в новой задаче