Data Driven Tests/Rules

[paulmccrady]

Pester supports a feature called Data Driven Tests. Can I use something similar with PSRule?

Use case: Ideally I don't want hardcoded values in rules due to configuration differences between environments. e.g. I want to assert that a virtual network address space has been configured correctly. The CIDR value may well be different between say PreProd and Prod environments. What is the best/recommended way to setup/configure rules in such a case?

[BernieWhite]

Hi @paulmccrady, PSRule supports configuration.

You would set a configuration value which can be done in a number of ways but via ps-rule.yaml is the easiest. i.e.

configuration:
  VNET_CIDR: 10.1.1.0/24

https://microsoft.github.io/PSRule/v2/concepts/PSRule/en-US/about_PSRule_Options/#configuration

Then you would use this configuration in the rule using the $Configuration variable:

For example: $Configuration.VNET_CIDR.

PowerShell rules:

• https://microsoft.github.io/PSRule/v2/concepts/PSRule/en-US/about_PSRule_Variables/#configuration

YAML rules:

• https://microsoft.github.io/PSRule/v2/expressions/functions/#using-functions

---

If you have an example maybe I can provide an alternative suggestion.

[paulmccrady]

OK, so given Azure.VNET.Rule.ps1 and this rule:

Synopsis: VNETs should have at least two DNS servers assigned.

Rule 'Azure.VNET.SingleDNS' -Ref 'AZR-000264' -Type 'Microsoft.Network/virtualNetworks' -Tag @{ release = 'GA'; ruleSet = '2020_06'; 'Azure.WAF/pillar' = 'Reliability'; } {
# If DNS servers are customized, at least two IP addresses should be defined
if ($Assert.NullOrEmpty($TargetObject, 'properties.dhcpOptions.dnsServers').Result) {
$Assert.Pass()
}
else {
$Assert.GreaterOrEqual($TargetObject, 'properties.dhcpOptions.dnsServers', 2);
}
}

Rather than have dnsServers check hardcoded to '2', could it be configurable or passed in, therefore potentially catering for differences in RTL environments. It may be a bad example, but I hope it illustrates the point.

[BernieWhite]

@paulmccrady Ok great.

The rule author defines what options can be exposed for configuration. For rules you write you can choose how to configure them based on my above example.

---

In this case Azure.VNET.SingleDNS is defined in PSRule for Azure by Microsoft and does not currently offer a configuration option.

If you feel the rule does not work for your use cases then I'm happy to take feedback and see if it makes sense to offer a configuration option or alternative solution.

However, the rule is intended to pick up cases when one DNS server is defined instead of a minimum of two.

Alternatively, you could do one of the following:

• Disable the rule - If you use a single ps-rule.yaml configuration file then this would disable it entirely, which is not ideal if you are deploy to different environments and want the rule enable for some but disabled for others.
• Suppress the rule - You can suppress the rule for a specific instance or using a suppression group. In this case, the rule runs normally unless it is suppressed for the exception cases. Using a suppression group, you can do this more programmatically let me give you can example, but there is also an example in the docs.

https://azure.github.io/PSRule.Rules.Azure/concepts/suppression/

---
# Synopsis: Ignore minimum DNS requirement for VNETs tagged for the dev environment.
apiVersion: github.com/microsoft/PSRule/v1
kind: SuppressionGroup
metadata:
  name: Local.IgnoreNonProdVNETDNS
spec:
  rule:
  - PSRule.Rules.Azure\Azure.VNET.SingleDNS
  if:
    allOf:
    - type: .
      equals: Microsoft.Network/virtualNetworks
    - field: tags.env
      equals: dev

[paulmccrady]

Also, in your suggestion above, can you have a ps_rule.yaml for say preprod and another for prod? we work with mono repos sometimes where the config for all environments is contained in the same repo and during a pipeline execution, a user would select the target environment (preprod or prod for example). the appropriate config is then loaded by the pipeline itself.

[BernieWhite]

@paulmccrady By default PSRule tooling in GitHub/ Azure DevOps/ VSCode will find ps-rule.yaml in the root of the repository.

You can define other ps-rule.yaml configurations with a different name or with the same name within a different path.

Today it's not possible to customise the ps-rule.yaml path for VSCode however this can be set by the option: parameter for GitHub Actions and Azure Pipelines. Using this parameter/ input you can point PSRule to an alternative file path that contains an environment specific PSRule options file.

• https://github.com/microsoft/ps-rule
• https://github.com/microsoft/PSRule-pipelines/blob/main/docs/tasks.md#ps-rule-assert

---

So you would ideally want the ps-rule.yaml to default to the settings you would like generally be applied for any environments and local testing by developers.

Then set an alternative configuration file for exception cases.

We are looking at advanced cases for how customers are using options files for different environments to help inform future development. If you have a specific case you want captured reply and we'll add this to our research. No promises on when or if we'll deliver this.

[paulmccrady]

@BernieWhite so if i had:
{root}/ps-rule.yaml
{root}/dev/ps-rule.yaml
{root}/prod/ps-rule.yaml

Would PSRule amalgate/join content from root yaml and one of the dev or prod yamls ? So i could put all common config in the root yaml and then specific overrides in the dev or prod yamls ?

Or would the dev and prod yamls also have to contain all of the information in the root yaml ?

[BernieWhite]

@paulmccrady you would need to include all the configuration in each file.

We are considering merging options files for PSRule v3. Which is a future release.