awscc_verifiedpermissions_policy changes disallowed by api

[ryancausey]

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or other comments that do not add relevant new information or questions, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment
• The resources and data sources in this provider are generated from the CloudFormation schema, so they can only support the actions that the underlying schema supports. For this reason submitted bugs should be limited to defects in the generation and runtime code of the provider. Customizing behavior of the resource, or noting a gap in behavior are not valid bugs and should be submitted as enhancements to AWS via the CloudFormation Open Coverage Roadmap.

Terraform CLI and Terraform AWS Cloud Control Provider Version

Terraform v1.5.7
on linux_amd64
+ provider registry.terraform.io/hashicorp/aws v5.42.0
+ provider registry.terraform.io/hashicorp/awscc v0.72.0
+ provider registry.terraform.io/hashicorp/random v3.6.0
+ provider registry.terraform.io/hashicorp/time v0.11.1

Affected Resource(s)

• awscc_verifiedpermissions_policy

Terraform Configuration Files

Please include all Terraform configurations required to reproduce the bug. Bug reports without a functional reproduction may be closed without investigation.

resource "awscc_verifiedpermissions_policy_store" "notifications_api_policy_store" {
  description = "The policy store for the notifications api project."

  validation_settings = {
    mode = "STRICT"
  }

  schema = {
    cedar_json = file("verified_permissions_schema.json")
  }
}

resource "awscc_verifiedpermissions_policy" "view_notification" {
  policy_store_id = awscc_verifiedpermissions_policy_store.notifications_api_policy_store.policy_store_id

  definition = {
    static = {
      description = "Allow all users to view Jurisdiction information."
      statement   = <<EOF
permit(
  principal in NotificationsApi::AllUsers::"User",
  action in NotificationsApi::Action::"viewNotification",
  resource in NotificationsApi::AllNotifications::"Notification"
);
EOF
    }
  }
}

{
    "NotificationsApi": {
        "entityTypes": {
            "AllRoles": {
                "memberOfTypes": [],
                "shape": {
                    "type": "Record",
                    "attributes": {}
                }
            },
            "Role": {
                "memberOfTypes": [
                    "AllRoles"
                ],
                "shape": {
                    "type": "Record",
                    "attributes": {}
                }
            },
            "AllUsers": {
                "memberOfTypes": [],
                "shape": {
                    "type": "Record",
                    "attributes": {}
                }
            },
            "User": {
                "memberOfTypes": [
                    "AllUsers",
                    "Role"
                ],
                "shape": {
                    "type": "Record",
                    "attributes": {
                        "org_id": {
                            "type": "String",
                            "required": true
                        }
                    }
                }
            },
            "AllNotifications": {
                "memberOfTypes": [],
                "shape": {
                    "attributes": {},
                    "type": "Record"
                }
            },
            "Notification": {
                "memberOfTypes": [
                    "AllNotifications"
                ],
                "shape": {
                    "type": "Record",
                    "attributes": {
                        "id": {
                            "type": "String",
                            "required": true
                        }
                    }
                }
            }
        },
        "actions": {
            "viewNotification": {
                "appliesTo": {
                    "principalTypes": [
                        "User"
                    ],
                    "resourceTypes": [
                        "Notification"
                    ]
                },
                "memberOf": []
            }
        }
    }
}

Debug Output

╷
│ Error: AWS SDK Go Service Operation Incomplete
│ 
│   with awscc_verifiedpermissions_policy.view_notification,
│   on verified_permissions.tf line 13, in resource "awscc_verifiedpermissions_policy" "view_notification":
│   13: resource "awscc_verifiedpermissions_policy" "view_notification" {
│ 
│ Waiting for Cloud Control API service UpdateResource operation completion
│ returned: waiter state transitioned to FAILED. StatusMessage: Invalid input
│ (Service: VerifiedPermissions, Status Code: 400, Request ID:
│ 189de938-52ff-4b0b-9a16-15abc964ef26). At /definition/static/statement: You
│ can't change the principal referenced in the scope of an existing policy.
│ At /definition/static/statement: You can't change the resource referenced
│ in the scope of an existing policy.. ErrorCode: InvalidRequest
╵

Panic Output

N/A

Expected Behavior

The resource should have been destroyed and recreated.

Actual Behavior

The resource was updated in place, which is disallowed for changes to the principal or a resource for a static policy.

Steps to Reproduce

1. create the policy store and one static policy in AVP as per the above using terraform.
2. make changes to the policy's principal statement, resource statement, or both.
3. run terraform plan
4. observe that the resource will be updated in place
5. run terraform apply using the previous plan

Important Factoids

N/A

References

• https://docs.aws.amazon.com/verifiedpermissions/latest/apireference/API_UpdatePolicy.html

[kadrach]

The underlying Cedar policy is treated as an object in the CloudFormation schema (which the awscc provider is generated from). To distinguish between update-able and not-updateable properties the schema would need to model Cedar policies in more detail. This is probably not feasible or pragmatic at this time.

As an example, adding an editNotification action to your schema, you can indeed modify the policy resource by changing the action, so the ability to "update" the resource is in itself valid.

[wellsiau-aws]

@ryancausey , thanks for opening this issue.

According to this documentatopn:

You can't change these elements of a static policy: Changing a policy from a static policy to a template-linked policy. Changing the effect of a static policy from permit or forbid. The principal referenced by a static policy. The resource referenced by a static policy.

As such, I believe that the returned error message are accurate / as expected.

The CloudFormation schema for StaticPolicyDefinition is marked as Update requires no interruption, meaning that changes to this policy wont trigger replacement.

If the intent to allow granular changes to the StaticPolicyDefinition attributes (i.e. actions) while triggering replacement for other attributes (principal or resources) , this this should be a feature request to the CloudFormation / VerifiedPermissions team directly.

[ryancausey]

@wellsiau-aws the problem is that this doesn't follow the semantics one expects from a Terraform resource. If I make changes to the resource, in this case a awscc_verifiedpermissions_policy, I shouldn't have to go manually delete the policy to get the terraform plan + apply to work. The correct semantics would be for the resource to recognize that the changes require it to be destroyed and re-created, preventing the apply time error altogether.

I'm not sure if that's a bug in their cloud control API spec, or a bug in how this provider translates the cloud control API functionality into a Terraform resource.

[wellsiau-aws]

@ryancausey , agreed that this didnt follow the expected semantics.

Since AWSCC provider is build based of CloudFormation schema registry, the required changes must be implemented at the CloudFormation schema level, which then Cloud Control API and AWSCC will use. I will go ahead and open feature request on behalf of you. Feel free to also contact your AWS rep / account team. Thank you.