[aghassemlouei]

Description

• Switch the custom.kmsRotation custom organization policy constraint in fast/stages-aw/0-bootstrap/data/custom-constraint-policies/cloudkms.yaml to the Cloud Foundation Fabric action_type: DENY implementation (has(resource.rotationPeriod) && resource.rotationPeriod > duration('7776000s')) across both CREATE and UPDATE so keys cannot be created or updated with a rotation period exceeding 90 days while terraform destroy can clear rotationPeriod via UPDATE prior to key version destruction, fixing [Bug] Custom KMS Org policy breaks terraform destroy operations of KMS keys #9.
• Align .gemini/styleguide.md with the updated custom.kmsRotation DENY constraint definition.

Fixes #9

Type of Change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Documentation update

Deployment & Compliance Impact

• Applicable Regimes:
  • US Region Restricted (e.g., Access Policy constraint)
  • FedRAMP Moderate
  • FedRAMP High
  • DoD IL4
  • DoD IL5
  • General / All
• NIST 800-53r5 Controls: SC-12, SC-13, SC-28, CM-6

Checklist

Code Quality & Reusability

• My code adheres to the Maximize Reusability principle. I have not redefined common elements and have reused existing base configurations and modules where possible.
• I have checked that no existing module or configuration in modules/ or fast/stages-aw/ can be leveraged for this change.
• My code follows the established naming conventions outlined in docs/naming-convention.md.

Documentation

• I have updated the README.md of the modified module or blueprint.
• I have added/updated documentation for inputs (variables) and outputs.

Security

• My change adheres to GCP security best practices and the principle of least privilege.
• I have ensured compliance with the targeted regime (FedRAMP Moderate, FedRAMP High, IL4, IL5, etc.).

Testing

• I have tested my changes locally.
• I have included details of my testing in this PR.

Testing Performed

• Executed bash tools/run_tests.sh, ruff check ., ruff format --check ., and python3 tools/check_documentation.py (all Python unit tests, shell syntax checks, shell unit tests, and CodeQL AST checks pass).

[aghassemlouei]

/gemini review

[Calvin-Cheng1]

Suggest using the CFF implementation of this update adds a gap where keys could be created with duration < 90 but updated to be < 90 after the fact.

custom.cloudkmsAllowedRotationPeriod:
action_type: DENY
condition: |-
has(resource.rotationPeriod) && resource.rotationPeriod > duration("7776000s")
method_types:

• CREATE
• UPDATE
  resource_types:
• cloudkms.googleapis.com/CryptoKey

[aghassemlouei]

Thanks for catching the UPDATE bypass, @Calvin-Cheng1! Updated custom.kmsRotation in f22a660 to use the CFF action_type: DENY condition (has(resource.rotationPeriod) && resource.rotationPeriod > duration('7776000s')) across both CREATE and UPDATE while keeping the custom.kmsRotation constraint key name for compatibility with cloudkms_policy.yaml and scripts/destroy.sh.