PSRule.Rules.Azure/setup/configuring-options/

[giscus[bot]]

PSRule.Rules.Azure/setup/configuring-options/

Ready to go validation and governance controls for Azure Infrastructure as Code (IaC).

https://azure.github.io/PSRule.Rules.Azure/setup/configuring-options/

[Omaraqlan]

i have a question, is it possible to change one rule from fail to pass or i have to add this as a new rule ?

for example: 'Azure.Storage.UseReplication' is failing, what im trying to do is to make it as recommended.

is it possible to have like
rule:
changes:
- Azure.Storage.UseReplication
- recommended

[Omaraqlan]

sorry there is missing spaces but i should have added markdown.

[BernieWhite]

@Omaraqlan I'm not sure I fully understand the question. Let me try to explain.

If an Azure resource:

• Meets the recommendation it returns Pass.
• Does not meet the recommendation it returns Fail.

To make the rule Pass update your Azure resource to follow the recommendation.

It is not possible to make the rule Pass without updating the Azure resource, but you can suppress or ignore the rule. You might do this if the recommendation is invalid for your use-case or requirement. Suppressing or ignoring skips the rule.

These basic options are covered here: https://microsoft.github.io/PSRule/v2/faq/#how-do-i-ignore-a-rule

---

If you believe a rule is incorrect and returns a fail when it should be passing then you can log a bug.

---

I hope this answers the question. If not, are you able to provide a little more detail.

[Omaraqlan]

sorry for my bad explanation , what im trying to do is for example we have :
Azure.Storage.UseReplication it holds standard_grs , and when im passing standard_lrs it will fail.

currently im suppress this and using a custom rule with -Level information to enable LRS as a recommendation for cost efficiency.

---

i was thinking if instead of supressing it, we change the -level from the ps-rule.yaml
so it can show this "Storage Accounts not using geo-replicated storage (GRS) may be at risk" as failed but not error.

---

BTW im in love with this ps-rules, need to learn how to handle type in custom rules

[BernieWhite]

@Omaraqlan Currently overriding the rule level is not supported. We have it in the backlog over here microsoft/PSRule#1180.

[maxricketts]

Hi there. We are at a stage where we need to have PSRule run and return back the information but not stop the pipeline. We are using the modules that are created by MS, but they are behind on the standards PSRule are showing, so we need to be able to deploy still and then update configs later.

Is there a switch we can use for it to analyse but not stop the pipeline on errors/warnings etc?

KR, Max

[Omaraqlan]

You can use invoke ps rule but not the assert at this stage https://microsoft.github.io/PSRule/v2/commands/PSRule/en-US/Invoke-PSRule/

[BernieWhite]

@maxricketts Great question. @Omaraqlan is correct you could do this.

Alternatively you could also use the built-in options within GitHub Actions and Azure Pipelines to continue on error. It's something we should add to the documentation so good call out.

For GitHub Actions use the continue-on-error property. For example:

- name: Run PSRule analysis
  uses: microsoft/[email protected]
  continue-on-error: true
  with:
    modules: PSRule.Rules.Azure

For Azure Pipelines use the continueOnError property. For example:

- task: ps-rule-assert@2
  displayName: Run PSRule analysis
  continueOnError: true
  inputs:
    modules: PSRule.Rules.Azure

---

Let us know what you think.

[mpr555]

@BernieWhite sounds good!

[kamfaima]

Which file takes precedence when the same option is specified in ps-rule.yaml and the yaml file used for Azure Pipelines or GitHub Actions?

Also can you please expand on usage when ps-rule.yaml is in the current working directory vs when it's in the root of the repo? Can it be present in both and if so are the settings a union of the two with the ones in the current working directory superseding those in the root if the same option is in both files?

[BernieWhite]

Thanks for the question @kamfaima, and we'll look at expanding these in the docs in a future update. Options passed from the pipeline YAML override a value set in ps-rule.yaml allowing you to runs separate tasks/ steps with a different configuration.

Two exceptions to call out:

• The modules: parameter is merged with the include.module option from ps-rule.yaml so that modules specified in either location will be imported for a PSRule run.
• The conventions parameter is merged with the convention.include option from ps-rule.yaml so that conventions specified in either location will be executing during a PSRule run.

---

In terms of usage of the ps-rule.yaml, PSRule only finds one instance of ps-rule.yaml. By default, which is in the root of the repository which is also the working path because that is the default for GitHub Actions, Azure Pipelines, and Visual Studio Code integration.

You can override this behaviour using one of two methods for GitHub Actions and Azure Pipelines.

1. Set the option: parameter, to give the pipeline task an alternative options file. i.e. you could provide it an option file in a nested path such as environments/dev/ps-rule.yaml or use a different naming scheme such as ps-rule-dev.yaml.
2. Change the base/ working path specified by the path: parameter. PSRule will then look for the ps-rule.yaml under this path instead. And will also assume all other operations are occurring within this specified path too.

---

We have had a small number of customers interested in the idea of a union of multiple options files together. If you have some specifics you would like to share, then we'd like to hear them in a feature request here: https://github.com/microsoft/PSRule/issues/new?assignees=&labels=enhancement&projects=&template=feature_request.md

[userwizz]

Is that possible to provide AZURE_PARAMETER_DEFAULTS values dynamically? E.g. from command line or using environment variable?

E.g how to set location parameter dynamically if it is now defined like this:

AZURE_PARAMETER_DEFAULTS:
location: foobar

[BernieWhite]

@userwizz Yes. You could set this via command line. This option wouldn't work currently via environment variable.

i.e.

$option = New-PSRuleOption -Configuration @{ AZURE_PARAMETER_DEFAULTS = @{ location = 'foorbar' } };
Assert-PSRule -Option $option -Format File -InputPath .

---

For ARM/ Bicep code the recommended practise is to set the location parameter to either resourceGroup().location (for RG deployments) or deployment().location (for deployments at other scopes).

That way the location just inherits the location of the deployment and it is still optional for cases when it needs to be overridden.

Example here: https://github.com/Azure/PSRule.Rules.Azure-quickstart/blob/d9edfdafe638e6bb1916137f1b7976e28cfdf41a/bicep/modules/keyvault/v1/main.bicep#L15-L16