Add walkthrough for using PSRule as a quality gate within an Azure DevOps release pipeline.

Description of the issue

Incorrect deserialization of nested arrays with non-objects. This is related to issue #109.

To Reproduce

Steps to reproduce the issue:

{
    "Properties": {
        "n": [
            "1",
            "2",
            "3"
        ]
    }
}

Rule 'countN' {
    ($TargetObject.properties.n | Measure-Object).Count -ge 3
}

Expected behaviour

The rule should pass, returns an exception Read json failed instead.

Module in use and version:

• Module: PSRule
• Version: 0.4.0-B190313

Captured output from $PSVersionTable:

Name                           Value
----                           -----
PSVersion                      5.1.17763.316
PSEdition                      Desktop
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
BuildVersion                   10.0.17763.316
CLRVersion                     4.0.30319.42000
WSManStackVersion              3.0
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1

Additional context

The issue also affects PSRule v0.3.0.

When an object is passed from the pipeline, PSRule assigns the object a TargetName. TargetName is used in output results to identify one object from another.

Currently direct properties of the pipeline object can be bound, or a custom script block can be used to perform binding.

Using a custom script block is highly flexible but has performance impacts. For simple cases like nested properties, it would be better to provide this feature natively.

A similar feature was added in #60 for Exists, Within and Match keywords.

For example:

# Use the metadata.name property as TargetName
binding:
  targetName:
  - 'metadata.name'

An example Kubernetes namespace object:

---
# Namespace: dev
apiVersion: v1
kind: Namespace
metadata:
  name: dev

Using metadata.name to bind TargetName should return dev.

Currently rules can be dynamically filtered at runtime by using a preconditions to select rules that apply to a certain objects. Preconditions are defined as PowerShell script blocks using the -If parameter on a Rule definition.

In many cases preconditions filter based on the type of object.

Providing an option to dynamically filter rules based on a bound type would reduce some complexity and improve performance because binding can be done up front for all rules.

Example rule:

Rule 'typeFiltedRule' -Type 'Microsoft.Storage/storageAccounts' {
    # Rule body
}

Example binding option:

# Bind to the ResourceType property of the object to determine TargetType
binding:
  targetType:
  - ResourceType

Instead of:

Rule 'typeFiltedRule' -If { $TargetObject.ResourceType -eq 'Microsoft.Storage/storageAccounts' } {
    # Rule body
}

Several modern CLI tools provide the option to export objects/ results in a serialized format for down stream processing.

PSRule should be able to processing these objects on the fly for common format such as YAML and JSON (#75).

However output from these commands may be an object type wrapping a collection of objects.

For example:

kubectl get services -o yaml | Out-String

Returns:

apiVersion: v1
items:
- apiVersion: v1
  kind: Service
  metadata: { }
  spec: { }
- apiVersion: v1
  kind: Service
  metadata: { }
  spec: { }
kind: List
metadata:
  resourceVersion: ""
  selfLink: ""

In order to process the items with PSRule, the property items must be used instead of the de-serialized object.

When executing rules the results will be outputted on the command line as individual result objects, per object per rule.

For reporting, a per rule summary of number of objects processed, number of pass/ fail/ error objects would be helpful.

Output should be able to be serialised and should have a default view created.

Currently PSRule supports Windows using PowerShell 5.1 and above.

This is great for Windows administrators however not great for everyone else. When enabling validation within a CI/CD pipeline, the agent platform might not be Windows.

Containers provide portability and consistency which is very applicable for PSRule.

PowerShell is already available in a published Docker container.

docker pull mcr.microsoft.com/powershell

i.e.

docker run -it --rm mcr.microsoft.com/powershell

Currently PSRule uses -f on path parameter for providing a working path discovery of .Rule.ps1 files.

In a number of open source tools -f is used to provide a list of data files to be used as input, instead of scripts to execute.

Adding support to import data from file will be introduced in PSRule and it makes sense from a consistency point of view to utilise -f which is currently used.

With this in mind, the -f alias should be removed from Invoke-PSRule, Get-PSRule and Test-PSRuleTarget.

Description of the issue
When using -As Summary with Invoke-PSRule output includes all summary results instead of only pass/ fail/ error results.

Additionally when using outcome filtering instead of the default filter. All results are returned.

To Reproduce
Steps to reproduce the behaviour:

@{ Name = 'test' } | Invoke-PSRule -As Summary -Outcome Fail;

Expected behaviour
Only results with the worst outcome of failed should be returned.

Module in use and version

• Module: PSRule
• Version: 0.1.0-B181235

Currently PSRule returns an record object (Invoke-PSRule) or boolean (Test-PSRuleTarget) to indicate pass or fail of evaluated rules.

In a CI pipeline where the output objects are less important (just the overall pass or failure) it would be helpful understand which object failed against what rule by means of an error or warning so that failures can be corrected.

• Add an option to treat fail/ pass as error or warnings.

For example:

logging:
  ruleFail: Error
  rulePass: Information

Documentation on PSRule features is included across separate documents for integration with PowerShell help.

It would be clearer and easier to understand if features were directly called out with examples.

PSRule can validate objects with custom PowerShell rules.

In some circumstances structural rules are already defined in an alternative format, like a Azure policy condition. PSRule should be able to leverage this format instead of recreating the rules in PowerShell.

Currently PSRule de-serializes YAML and JSON objects from string when the -Format parameter is used with Invoke-PSRule and Test-PSRuleTarget.

To read a YAML file from disk, Get-Content -Raw -Path path_to_file | Out-String needs to be used.

For example:

Invoke-PSRule -InputObject (Get-Content -Raw -Path path_to_file | Out-String) -Format Yaml;

Instead -InputObject should automatically read and deserialize the file contents of FileInfo objects when the -Format is used.

For example:

Invoke-PSRule -InputObject (Get-ChildItem -Path path_to_file) -Format Yaml;

Currently Exists, Within, Match and TypeOf keywords operate on the currently pipeline object $TargetObject.

When evaluating sub-objects of it would be useful to reuse these keywords.

Consider:

# Description: Deployments should use pods that deny privilege escalation
Rule 'kubernetes.Deployments.PrivilegeEscalation' -Type Deployment {
    foreach ($container in $TargetObject.spec.template.spec.containers) {
        $container | Exists 'securityContext.allowPrivilegeEscalation'
        $container.securityContext.allowPrivilegeEscalation -eq $False
    }
}

CI process currently provides a method to publish pre-releases, but full releases also need to be handled.

Exists, Within and Match keywords evaluate a field of the target object. The field name must be a direct property of the object.

PSRule should support the ability navigate the object graph to evaluate properties of properties so that child objects can also be evaluated. i.e. Value.Value1.

For example:

# Check if the Value property of the target object has a property called Value1
Exists 'Value.Value1`

In this case:

• if Value is not a property of the target object, Exists should return false.
• if Value1 is not a property of the object assigned to Value, Exists should return false.
• if both Value and Value1 exist then Exists should return true.

Description of the issue

When an empty object is passed to -InputObject when using the YAML input format (-Format Yaml) an exception is generated.

Consider:

---
metadata:
  name: anObject
---
# Commented out object
# metadata:
#   name: anObject2
---

To Reproduce

Steps to reproduce the issue:

Invoke-PSRule -InputObject (Get-Content -Path .\anObject.yaml -Raw | Out-String) -Format Yaml;

Expected behaviour

Empty objects should be ignored.

Error output

(Line: 10, Col: 4, Idx: 161) - (Line: 8, Col: 4, Idx: 161): Expected 'DocumentEnd', got 'Scalar' (at Line: 8, Col: 4, Idx: 161).

Module in use and version:

• Module: PSRule
• Version: 0.3.0-B190224

Captured output from $PSVersionTable:

Name                           Value
----                           -----
PSVersion                      5.1.17763.316
PSEdition                      Desktop
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
BuildVersion                   10.0.17763.316
CLRVersion                     4.0.30319.42000
WSManStackVersion              3.0
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1

We should plan for adding localisation support into rule definitions.

Rules may also want to provide localised output such as recommendations.

In certain circumstances it may be necessary to exclude or suppress rules from processing objects that are in a known failed state.

Consider:

suppression:
  storageAccounts.UseHttps:
    targetName:
      - storage

suppression:
  storageAccounts.UseHttps: storage

Description of the issues

When using Invoke-PSRule with -Verbose, additional logging is generated. PSRule should keep track of the object number that is currently being processed on the same pipeline to distinguish between different objects.

However the object counter stays at 0.

To Reproduce

Steps to reproduce the issue:

$testObject = @(
    [PSCustomObject]@{ PhoneNumber = '0400 000 000' }
    [PSCustomObject]@{ PhoneNumber = '000' }
    @{ PhoneNumber = '000' }
)

$testObject | Invoke-PSRule -Verbose;

Expected behaviour

The counter should increase from 0 for each object processed. i.e. The first object is 0, the second is 1, and so on.

Error output

VERBOSE: [PSRule][R][0][FromFile.Rule.ps1/MatchTest] ::
VERBOSE: [PSRule][R][0][FromFile.Rule.ps1/MatchTest][Match]::BEGIN
VERBOSE: [PSRule][R][0][FromFile.Rule.ps1/MatchTest][Match]::END
VERBOSE: [PSRule][R][0][FromFile.Rule.ps1/MatchTest] -- [1/1] [Pass]
VERBOSE: [PSRule][R][0][FromFile.Rule.ps1/MatchTest] ::
VERBOSE: [PSRule][R][0][FromFile.Rule.ps1/MatchTest][Match]::BEGIN
VERBOSE: [PSRule][R][0][FromFile.Rule.ps1/MatchTest][Match]::END
VERBOSE: [PSRule][R][0][FromFile.Rule.ps1/MatchTest] -- [1/1] [Pass]
VERBOSE: [PSRule][R][0][FromFile.Rule.ps1/MatchTest] ::
VERBOSE: [PSRule][R][0][FromFile.Rule.ps1/MatchTest][Match]::BEGIN
VERBOSE: [PSRule][R][0][FromFile.Rule.ps1/MatchTest][Match]::END
VERBOSE: [PSRule][R][0][FromFile.Rule.ps1/MatchTest] -- [0/1] [Fail]

Module in use and version:

• Module: PSRule
• Version: 0.1.0-B181235

Description of the issue

Invoke-PSRule and Test-PSRule return a LocalizedData.PathNotFound warning when no .rule.ps1 scripts exist in path, but not the actual warning.

To Reproduce

Steps to reproduce the issue:

@{ name = 'fruit' } | Invoke-PSRule -Verbose;
@{ name = 'fruit' } | Test-PSRule -Verbose;

Expected behaviour

Invoke-PSRule and Test-PSRule should return a localized warning message.

Error output

Capture any error messages and or verbose messages with -Verbose.

VERBOSE: [Test-PSRule] BEGIN::
VERBOSE: Attempting to read: .\psrule.yml
VERBOSE: [PSRule][D] -- Scanning for source files: C:\dev\Workspace\PSRule\src\Docker
WARNING: LocalizedData.PathNotFound

Module in use and version:

• Module: PSRule
• Version: 0.1.0 and 0.2.0-B190105

PSRule uses YAML for storage of configuration options.

Defining a schema for option will make editing configuration easier in tools such as Visual Studio Code.

PowerShell supports localisation of modules using .psd1 files.

Support for localisation of PSRule has been added however messages haven't been localised and needs to be done.

• Localize script module
• Localize binary module
• Localize output format

Currently objects can be passed from the pipeline as serialised objects using YAML or JSON.

In many cases these serieralised objects reside on disk or are available on via HTTP.

To read these files from disk Get-Content -Raw can be used, however we can do better.

Consider:

Invoke-PSRule -InputPath .\data\*.yaml -Format Yaml;

Invoke-PSRule -InputPath 'https://github.com/BernieWhite/PSRule/blob/master/docs/scenarios/kubernetes-resources/kubernetes-resources.md' -Format Yaml;

Ideally:

• PSRule should be able to auto-detect format by extension.
• Wildcard and multiple files should be supported.
• Files available on a HTTP/HTTPS endpoint are natively supported.

Several modern CLI tools provide the option to export objects/ results in a serialized format for down stream processing.

PSRule should be able to processing these objects on the fly for common format such as YAML and JSON.

For example:

# Validate service objects
Invoke-PSRule -InputObject (kubectl get services -o yaml | Out-String) -Format Yaml;

Added support for:

• YAML
• JSON

When rules are created, they then need to be distributed.

Packaging rules together in a module promotes reuse and provides a convenient distribution mechanism that already exists and is already used by IT pros.

Currently rules from a module can be used by adding the module path to the path parameter of Invoke-PSRule or Get-PSRule, but we can do better.

PSRule allows an informational message to be returned in rule results. The intent of this message to provide information about why the rule passed or failed.

An optional rule description may also be set and it's content generally aligns to the condition under which the rule passes or fails.

When a rule does not supply a custom message we should use the description to provide feedback that is easier to interpret.

Description of the issue

When calling Invoke-PSRule -As Summary -OutputFormat Yaml, two issues exist:

• Output is generated that has not been serialized
• YAML is not correctly serialized.

This issue is not specific to YAML, the same behaviour occurs with -OutputFormat Json.

To Reproduce

Steps to reproduce the issue:

 Get-Content docs/scenarios/kubernetes-resources/resources.yaml -Raw | Invoke-PSRule -Path docs/scenarios/kubernetes-resources -Format Yaml -Option docs/scenarios/kubernetes-resources/PSRule.yaml -Outcome Fail -OutputFormat Yaml -as Summary

RuleName                            Pass  Fail  Outcome
--------                            ----  ----  -------
metadata.Name                       3     1     Fail
metadata.Version                    2     2     Fail
metadata.Component                  3     1     Fail
deployment.HasMinimumReplicas       1     1     Fail
deployment.NotLatestImage           1     1     Fail
deployment.ResourcesSet             1     1     Fail
[]

Expected behaviour

When -As Summary is used with an output format, a serialized output should be generated instead of returning PowerShell objects.

Module in use and version:

• Module: PSRule
• Version: 0.4.0-B190320

Captured output from $PSVersionTable:

Name                           Value
----                           -----
PSVersion                      5.1.17763.316
PSEdition                      Desktop
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
BuildVersion                   10.0.17763.316
CLRVersion                     4.0.30319.42000
WSManStackVersion              3.0
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1

Currently PSRule validates objects passed to it against a set of rules. Matching rules produce result data for reporting based on pass or failure.

PSRule can be further extended to transform/ mutate objects that don't pass rule conditions with the intent of making the object compliant.

i.e. An object doesn't have a property that should be set, when the value the property should be set to is known, then set the property.

For example:

# Description: Use HTTPS only
Rule 'appServiceApp.UseHTTPS' -If { ResourceType 'Microsoft.Web/sites' } {
    Hint 'Disable HTTP when not required'

    $TargetObject.Properties.httpsOnly -eq $True

    Recommend -Update {
        $TargetObject.Properties.httpsOnly = $True
    }
}

Update-PSRuleTarget

Field names provide a way to navigate an object by using a dotted field notation.

For example, 'Name' or 'Metadata.Labels.Name'.

Currently the following are not supported:

• Indexing into an array. i.e. Value[0].
• Quoted field names. i.e. Value.'app.kubernetes.io/version'.

Currently PSRule automatically detects the name of the object TargetName which is used in output results.

Binding of TargetName looks for a property either TargetName or Name on the object. The TargetName property takes precedence over Name. This allows Add-Member to be used to customise the result.

If neither TargetName or Name properties are found then results will report a null TargetName.

How TargetName is bound should be configurable.

• Allow configuration of binding properties
• Add a pipeline hook to customise name binding
• Provide method to name objects with null name

We need to improve reporting of the following cases:

• An object is returns an inconclusive results
• The object is not processed by any rule

Both of these cases may be unintended so we should provide warnings to allow identification of either rule or object issues.

Description of the issue

Test-PSRule was introduced in pre-release 0.2.0-B190105. PowerShell cmdlets are named with a standard naming convention using verb-noun.

Test-PSRule should be renamed to Test-PSRuleTarget. While Test-PSRule is shorter, it doesn't accurately reflect the noun or subject of the test. The subject of the test is the target object not the rule.

Module in use and version:

• Module: PSRule
• Version: 0.2.0-B190105

Description of the issue

Originally the Hint keyword could be used to name target objects and set TargetName for pipeline objects that did not implement a TargetName or Name property that was useful for identification.

Using this approach:

• Hint is called every time a rule is executed and target name for the same object may flip-flop when rules call Hint differently.
• Objects can't be named if no rules are evaluated.

PSRule v0.2.0 introduced binding options to allow customisation of TargetName up-front, which is not only more efficient but less prone to error.

Since Hint -TargetName is no longer required, we should deprecate and remove support for the -TargetName parameter of the Hint keyword.

Currently PSRule supports Windows however the goal is to make this project cross platform by providing support for MacOS and Linux.

This is great for Windows administrators however not great for everyone else. When enabling validation within a CI/CD pipeline, the agent platform might not be Windows.

• Support for MacOS
• Support for Linux

Currently PSRule exports stub keyword function for discovery by editor services within PowerShell authoring tools like Visaul Studio Code.

Additionally variables can also be exported to further improve discovery.

• Add variable stubs and type information to improve editing experience.

Description of the issue

Informational messages are not reported to host under the following conditions:

• Verbose, information, warning and error messages within rule definition blocks
• General verbose, information and warning messages within .Rule.ps1 scripts outside of rule definitions

To Reproduce

Steps to reproduce the issue:

# Logging in main script
Write-Information -MessageData 'Script information message';
Write-Verbose -Message 'Script verbose message';
Write-Warning -Message 'Script warning message';

Rule 'WithError' {
    Write-Error -Message 'Rule error message';
    $True;
}

Rule 'WithWarning' {
    Write-Warning -Message 'Rule warning message';
    $True;
}

Rule 'WithVerbose' {
    Write-Verbose -Message 'Rule verbose message';
    $True;
}

Rule 'WithInformation' {
    Write-Information -MessageData 'Rule information message';
    $True;
}

Invoke-PSRule -Verbose -InformationAction Continue;

Expected behaviour

Verbose, information, warning and error messages should be returned to the host PowerShell runspace where they can interpreted or saved.

Module in use and version:

• Module: PSRule
• Version: 0.1.0

Add a function like Test-PSRule to test a pipeline object against rules an return just a true or false.

• The worst case of any rule evaluated for the object should be reported.
• Inconclusive is reported as $False or fail, but also write a warning.
• If no rules match report as $True or pass, but also write a warning.

Description of the issue

Incorrect deserialization of nested arrays.

To Reproduce

Steps to reproduce the issue:

{
    "Properties": {
        "n": [
            {
                "id": "1"
            },
            {
                "id": "2"
            },
            {
                "id": "3"
            }
        ]
    }
}

Rule 'countN' {
    ($TargetObject.properties.n.id | Measure-Object).Count -ge 2
}

Expected behaviour

The rule should pass, but fails when the JSON is passed in with the -InputPath parameter. The rule passes correctly when using the same content with ConvertFrom-Json and pipelining in the object to Invoke-PSRule.

Module in use and version:

• Module: PSRule
• Version: 0.4.0-B190313

Captured output from $PSVersionTable:

Name                           Value
----                           -----
PSVersion                      5.1.17763.316
PSEdition                      Desktop
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
BuildVersion                   10.0.17763.316
CLRVersion                     4.0.30319.42000
WSManStackVersion              3.0
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1

Additional context

The issue also affects PSRule v0.3.0.

Description of the issues

When the target object is a hashtable or any IDictionary, keys should be treated as fields instead of the properties of the IDictionary.

To Reproduce

Steps to reproduce the issue:

$testObject = @(
    [PSCustomObject]@{ PhoneNumber = '0400 000 000' }
    [PSCustomObject]@{ PhoneNumber = '000' }
    @{ PhoneNumber = '000' }
)

$testObject | Invoke-PSRule -Verbose;

Expected behaviour

The object @{ PhoneNumber = '000' } should pass, the same as [PSCustomObject]@{ PhoneNumber = '000' }. This is because the properties of the hashtable such as Count are being evaluated instead.

Error output

VERBOSE: [PSRule][R][0][FromFile.Rule.ps1/MatchTest] ::
VERBOSE: [PSRule][R][0][FromFile.Rule.ps1/MatchTest][Match]::BEGIN
VERBOSE: [PSRule][R][0][FromFile.Rule.ps1/MatchTest][Match]::END
VERBOSE: [PSRule][R][0][FromFile.Rule.ps1/MatchTest] -- [1/1] [Pass]
VERBOSE: [PSRule][R][1][FromFile.Rule.ps1/MatchTest] ::
VERBOSE: [PSRule][R][1][FromFile.Rule.ps1/MatchTest][Match]::BEGIN
VERBOSE: [PSRule][R][1][FromFile.Rule.ps1/MatchTest][Match]::END
VERBOSE: [PSRule][R][1][FromFile.Rule.ps1/MatchTest] -- [1/1] [Pass]
VERBOSE: [PSRule][R][2][FromFile.Rule.ps1/MatchTest] ::
VERBOSE: [PSRule][R][2][FromFile.Rule.ps1/MatchTest][Match]::BEGIN
VERBOSE: [PSRule][R][2][FromFile.Rule.ps1/MatchTest][Match]::END
VERBOSE: [PSRule][R][2][FromFile.Rule.ps1/MatchTest] -- [0/1] [Fail]

Module in use and version:

• Module: PSRule
• Version: 0.1.0-B181235

Currently it is easy to define rules with hard coded conditions. A better approach would be to allow conditions to pull in configuration as required.

Adding a common configuration model for rules will make creating configurable baselines much easier.

Rule configuration must be able to support default values, only non default values should need to be set in configuration.

Consider:

rules:
  configuration:
    rule1_config: value1

Rule 'rule1' {
  $option = Configure @{ 'rule1_config' = 'defaultValue' }
  $option.rule1_config -eq 'value1'
}

Instead of returning objects, return detailed or summary results as JSON/ YAML.

Serialised results will make down stream processing easier.

• Support for JSON
• Support for YAML

When editing .Rule.ps1 files in Visual Studio Code, keywords are imported into session to allow command completion to provide usage information.

Additionally VS Code can read help information and link out to online help with Get Help for Command. Quickly getting access to online help will improve the authoring experience for defining rules.

For this to work for PSRule keywords, comment-based help needs to provide a online link.

For example:

<#
.LINK
https://berniewhite.github.io/PSRule/keywords/PSRule/en-US/about_PSRule_Keywords.html#rule
#>

Description of the issue

Results for Invoke-PSRule with -OutputFormat Yaml should produce results formatted with lower camel case property names.

To Reproduce

Steps to reproduce the issue:

Get-Content docs/scenarios/kubernetes-resources/resources.yaml -Raw | Invoke-PSRule -Path docs/scenarios/kubernetes-resources -Format Yaml -Option docs/scenarios/kubernetes-resources/PSRule.yaml -Outcome Fail -OutputFormat Yaml

- RuleId: kubernetes.Rule.ps1/deployment.HasMinimumReplicas
  RuleName: deployment.HasMinimumReplicas
- RuleId: kubernetes.Rule.ps1/deployment.NotLatestImage
  RuleName: deployment.NotLatestImage
- RuleId: kubernetes.Rule.ps1/deployment.ResourcesSet
  RuleName: deployment.ResourcesSet
- RuleId: kubernetes.Rule.ps1/metadata.Name
  RuleName: metadata.Name
- RuleId: kubernetes.Rule.ps1/metadata.Version
  RuleName: metadata.Version
- RuleId: kubernetes.Rule.ps1/metadata.Component
  RuleName: metadata.Component
- RuleId: kubernetes.Rule.ps1/metadata.Version
  RuleName: metadata.Version

Expected behaviour

Serialized YAML results should use lower camel casing for property names.

Module in use and version:

• Module: PSRule
• Version: 0.4.0-B190320

Captured output from $PSVersionTable:

Name                           Value
----                           -----
PSVersion                      5.1.17763.316
PSEdition                      Desktop
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
BuildVersion                   10.0.17763.316
CLRVersion                     4.0.30319.42000
WSManStackVersion              3.0
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1

Rules currently support tags for selection when using Invoke-PSRule and Get-PSRule.

Tags should flow down to results to allow reporting and sorting.

An example is a category or severity tag that can then be used for generating reports.

Provide an detailed walkthrough for validating tags on Azure resources.

• Check if tag exists
• Include case sensitivity

PSRule can validate objects with custom PowerShell rules.

In some circumstances structural rules are already defined in an alternative format, like a JSON schema. PSRule should be able to leverage this format instead of recreating the rules in PowerShell.

Description of the issue

Get-PSRule does not gracefully handle the case where no .rule.ps1 files exist in the path and raises exceptions.

To Reproduce

Steps to reproduce the issue:

# With no .rule.ps1 files in current and child directories
Get-PSRule -Verbose;

Expected behaviour

Get-PSRule should return no results and no exceptions.

Error output

VERBOSE: [Get-PSRule]::BEGIN
VERBOSE: Attempting to read: .\psrule.yml
VERBOSE: [PSRule][D] -- Scanning for source files: C:\dev\Workspace\PSRule\dummy
The property 'Length' cannot be found on this object. Verify that the property exists.
At C:\Users\nnn\Documents\WindowsPowerShell\Modules\PSRule\0.2.0\PSRule.psm1:265 char:57
+ ... Verbose -Message "[Get-PSRule] -- Found $($sourceFiles.Length) script ...
+                                               ~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [], PropertyNotFoundException
    + FullyQualifiedErrorId : PropertyNotFoundStrict

VERBOSE: [Get-PSRule] -- Found  script(s)
Exception calling "Join" with "2" argument(s): "Value cannot be null.
Parameter name: values"
At C:\Users\nnn\Documents\WindowsPowerShell\Modules\PSRule\0.2.0\PSRule.psm1:266 char:64
+ ... [Get-PSRule] -- Found scripts: $([String]::Join(' ', $sourceFiles))";
+                                      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [], MethodInvocationException
    + FullyQualifiedErrorId : ArgumentNullException

Object reference not set to an instance of an object.
At C:\Users\nnn\Documents\WindowsPowerShell\Modules\PSRule\0.2.0\PSRule.psm1:286 char:13
+             $pipeline.Process();
+             ~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : OperationStopped: (:) [], NullReferenceException
    + FullyQualifiedErrorId : System.NullReferenceException```

**Module in use and version:**

- Module: PSRule
- Version: 0.1.0 and 0.2.0-B190105

Description of the issue

Results for Invoke-PSRule with -OutputFormat Yaml are missing properties that would normally be available.

To Reproduce

Steps to reproduce the issue:

Get-Content docs/scenarios/kubernetes-resources/resources.yaml -Raw | Invoke-PSRule -Path docs/scenarios/kubernetes-resources -Format Yaml -Option docs/scenarios/kubernetes-resources/PSRule.yaml -Outcome Fail -OutputFormat Yaml

- RuleId: kubernetes.Rule.ps1/deployment.HasMinimumReplicas
  RuleName: deployment.HasMinimumReplicas
- RuleId: kubernetes.Rule.ps1/deployment.NotLatestImage
  RuleName: deployment.NotLatestImage
- RuleId: kubernetes.Rule.ps1/deployment.ResourcesSet
  RuleName: deployment.ResourcesSet
- RuleId: kubernetes.Rule.ps1/metadata.Name
  RuleName: metadata.Name
- RuleId: kubernetes.Rule.ps1/metadata.Version
  RuleName: metadata.Version
- RuleId: kubernetes.Rule.ps1/metadata.Component
  RuleName: metadata.Component
- RuleId: kubernetes.Rule.ps1/metadata.Version
  RuleName: metadata.Version

Expected behaviour

Serialized YAML results should also include the following properties:

• outcome
• outcomeReason
• message
• targetName
• targetType
• tag

Module in use and version:

• Module: PSRule
• Version: 0.4.0-B190320

Captured output from $PSVersionTable:

Name                           Value
----                           -----
PSVersion                      5.1.17763.316
PSEdition                      Desktop
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
BuildVersion                   10.0.17763.316
CLRVersion                     4.0.30319.42000
WSManStackVersion              3.0
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1

PSRule offers a number of options for binding key properties during pipeline processing. Currently property binding is done ignoring case, which mirrors PowerShell behaviour when accessing properties using . notation.

In some languages and object types, case sensitivity is more important, particularly when the object is a dictionary.

Add support to turn on case sensitive property binding.