How do you write custom checks for blocks like lifecycle

[mijdavis2]

I am trying to write a custom check to ensure that lifecycle has ignore_changes and contains something like users. Example:

resource "okta_app_saml" "this" {
  [...]
  
  lifecycle {
    ignore_changes = [
      users,
    ]
  }
}

I've tried many configurations of matchSpec but none seem to work. Example: this passes all resources regardless of ignore_changes contents:

checks:
- code: okta-app-must-ignore-groups-users
  description: Ensure groups and users are ignored on okta apps.
  impact: >-
    Maintaining groups and users in okta_app_* such as okta_app_saml is deprecated;
    can cause race conditions and side effects.
  resolution: Ignore groups and instead use okta_app_group_assignments
  requiredTypes:
  - resource
  requiredLabels:
  - 'okta_app'
  - 'okta_app_oauth'
  - 'okta_app_saml'
  - 'okta_app_swa'
  severity: CRITICAL
  matchSpec:
    name: lifecycle
    action: isPresent
    predicateMatchSpec:
      action: and
      subMatch:
        name: ignore_changes
        action: contains
        value:
        - users
        - groups
  errorMessage: Groups/users not ignored in okta app

What am I missing?

---

Secondly, I can't get other block checks to work either. And what about multiple instances of blocks? Example:

resource "okta_app_group_assignments" "this" {
  [...]

  group {
    priority = 0
    id = "some_id"
  }
}

resource "okta_app_group_assignments" "another_this" {
  [...]

  group {
    priority = 0
    id = "some_id"
  }

  group {
    id = "some__other_id"
  }
}

I want a failure if priority is present in a group block. The following doesn't work and fails on all resources regardless of group contents:

checks:
- code: okta-app-group-assignments-priority
  description: Ensure priority is not set for group assignments
  impact: >-
    Maintaining priority can cause race conditions and unnecessary diffs.
  resolution: Remove priority from group blocks in okta_app_group_assignments
  requiredTypes:
  - resource
  requiredLabels:
  - 'okta_app_group_assignments'
  severity: CRITICAL
  matchSpec:
  - name: group
    action: notContains
    value: priority

[owenrumney]

Hi

Your check needs to know what its resource type it is checking by specifying requiredLabels

I'll give your example a go and see if I can work out if there are any issues with the matchSpec

---
checks:
  - code: CUS001
    description: Custom check to ensure the CostCentre tag is applied to EC2 instances
    requiredTypes:
      - resource
    requiredLabels:
      - aws_instance
    severity: HIGH
    matchSpec:
      name: tags
      action: contains
      value: CostCentre
    errorMessage: The required CostCentre tag was missing
    relatedLinks:
      - http://internal.acmecorp.com/standards/aws/tagging.html

[mijdavis2]

My apologies, I didn't include that for brevity. I will update the question with the full yaml.

[owenrumney]

Soooooo, for the first one - good news and bad news -

This check does what you want of sorts - but for some reason it requires users, groups to be strings

checks:
  - code: okta-app-must-ignore-groups-users
    description: Ensure groups and users are ignored on okta apps.
    impact: |
      Maintaining groups and users in okta_app_* such as okta_app_saml is deprecated;
      can cause race conditions and side effects.
    resolution: Ignore groups and instead use okta_app_group_assignments
    requiredTypes:
      - resource
    requiredLabels:
      - "okta_app"
      - "okta_app_oauth"
      - "okta_app_saml"
      - "okta_app_swa"
    severity: CRITICAL
    matchSpec:
      name: lifecycle
      action: isPresent
      subMatch:
        action: and
        predicateMatchSpec:
          - name: ignore_changes
            action: contains
            value: users
          - name: ignore_changes
            action: contains
            value: groups
    errorMessage: Groups/users not ignored in okta app

works with

resource "okta_app_saml" "this" {
  
  lifecycle {
    ignore_changes = [
      "users", "groups"
    ]
  }
}

I consider this to be a bug, so I need to dig into it

---

For the second one, this was easier. You need to check that there is a group block which if true allows the submatch to run where you require that priority is not present

checks:
  - code: okta-app-group-assignments-priority
    description: Ensure priority is not set for group assignments
    impact: |
      Maintaining priority can cause race conditions and unnecessary diffs.
    resolution: Remove priority from group blocks in okta_app_group_assignments
    requiredTypes:
      - resource
    requiredLabels:
      - "okta_app_group_assignments"
    severity: CRITICAL
    matchSpec:
      name: group
      action: isPresent
      subMatch:
        name: priority
        action: notPresent

[mijdavis2]

Excellent. Thank you so much.

[owenrumney]

Sorry I haven't fixed both. If you could raise an issue for the first one, I'll look at it asap