Add a source expression property

[BernieWhite]

Currently the expression properties field, name, or type can be used. In PowerShell the source file for the object can be referenced using $PSRule.Source.

For example:

# Synopsis: Policy exemptions must be stored under designated paths for review.
Rule 'Org.Azure.Policy.Path' -Type 'Microsoft.Authorization/policyExemptions' {
    $Assert.WithinPath($PSRule.Source['Parameter'], '.', @(
        'deployments/policy/'
    ));
}

Currently $PSRule.Source is not available within expressions, neither is an equivalent of $Assert.WithinPath.

It would be helpful to provide both options to allow suppression groups to exclude objects based on their origin path.

For example:

---
apiVersion: github.com/microsoft/PSRule/v1
kind: SuppressionGroup
metadata:
  name: Local.IgnoreACRTests
spec:
  if:
    source: 'file'
    withinPath: 'modules/**/*.tests.bicep'

[ArmaanMcleod]

@BernieWhite Similar to WithinPath assertion, should this also support giving an array of paths?

---
apiVersion: github.com/microsoft/PSRule/v1
kind: SuppressionGroup
metadata:
  name: Local.IgnoreACRTests
spec:
  if:
    source: 'file'
    withinPath: 
      - 'modules/**/*.tests.bicep'
      - '/some/other/path'

Could probably also support notWithinPath.

[BernieWhite]

@ArmaanMcleod Yep. Sounds good. Not sure on how notWithinPath would be used, but it would be easy to add.

[ArmaanMcleod]

@BernieWhite Should we include warnings for this, similar to what we do for rules?

Maybe something like Object {0} with source {1} was suppressed by suppression group {2}?

[BernieWhite]

@ArmaanMcleod I don't think the implementation for souce and withinpath needs to be suppression group specific, it should also work for rules or selectors. As such the message probably doesn't need to be specific. I.e. if the condition matches then the object is suppressed.

[ArmaanMcleod]

@BernieWhite Yeah don't think it should be suppression group specific as well, Selectors like below should work as well:

apiVersion: github.com/microsoft/PSRule/v1
kind: Selector
metadata:
  name: YamlSourceWithinPath
spec:
  if:
    source: 'Template'
    withinPath:
      - "deployments/path/"

I can probably just keep the warning message like Object {0} with source {1} was suppressed.

I've implemented this so far for withinPath:

internal static bool WithinPath(ExpressionContext context, ExpressionInfo info, object[] args, object o) 
{
    var properties = GetProperties(args);
    if (TrySource(properties, out var sourceValue) &&
        TryPropertyStringArray(properties, WITHINPATH, out var path) &&
        GetCaseSensitive(properties, out var caseSensitive))
    {
        var source = context.GetContext()?.TargetObject?.Source[sourceValue];

        if (source == null)
            return Invalid(context, sourceValue);

        var sourcePath = ExpressionHelpers.GetObjectOriginPath(source);

        for (var i = 0; path != null && i < path.Length; i++) {
            if (ExpressionHelpers.WithinPath(sourcePath, path[i], caseSensitive))
                return Pass();
        }

        return Fail(
            context,
            ReasonStrings.WithinPath,
            ExpressionHelpers.NormalizePath(PSRuleOption.GetWorkingPath(), sourcePath),
            StringJoinNormalizedPath(path)
        );
    }

    return Invalid(context, WITHINPATH);
}

Which seems to work fine for source and withinPath, but thinking this should also have the ability to support other properties like field, which is what the equivalent assertion supports. What do you think?

apiVersion: github.com/microsoft/PSRule/v1
kind: Selector
metadata:
  name: YamlFieldWithinPath
spec:
  if:
    field: 'resourceId' # Some field that has a path we want to check, can be anything
    withinPath:
      - "deployments/path/"

[BernieWhite]

@ArmaanMcleod Agreed. Maybe have a look at the Operand methods. It should be able to be easily extended to include source.

[ArmaanMcleod]

@BernieWhite Ah I see. I think I was initially confused with TryOperand, since it has a name argument for the specific expression type.

I can probably do this and extend Operand to include source:

private static bool TryOperand(ExpressionContext context, string name, object o, LanguageExpression.PropertyBag properties, out IOperand operand)
{
    return TryField(context, properties, o, out operand) ||
        TryType(context, properties, out operand) ||
        TryName(context, properties, out operand) ||
        TrySource(context, properties, out operand) || // Add source here
        Invalid(context, name);
}

[BernieWhite]

@ArmaanMcleod Yep. That should work nicely.