feat: Add ebs_csi_restrict_tagging_to_create to allow EBS CSI tag modification on existing volumes - #651

this default would automatically remove permissions which makes it a breaking change - must be true for backwards compatibility and users will have to opt into disabling

Thanks for reviewing, and for merging master in.

I want to make sure I'm not talking past you, so I rendered the actual policy document three ways against this branch (attach_ebs_csi_policy = true, terraform plan → terraform show -json → the aws_iam_policy body). The variable's polarity is the opposite of what the name suggests at a glance:

1. master vs this PR at the default (ebs_csi_volume_tagging = false) — byte-identical, zero diff:

$ diff <(jq -S . master-policy.json) <(jq -S . pr-default-false-policy.json)
$ echo $?
0

The dynamic "condition" block uses for_each = var.ebs_csi_volume_tagging ? [] : [1], so at the default it still emits the same ec2:CreateAction condition master emits unconditionally:

{
  "Action": "ec2:CreateTags",
  "Condition": { "StringEquals": { "ec2:CreateAction": ["CreateVolume", "CreateSnapshot"] } },
  "Effect": "Allow",
  "Resource": ["arn:aws:ec2:*:*:volume/*", "arn:aws:ec2:*:*:snapshot/*"]
}

2. master vs this PR with ebs_csi_volume_tagging = true — the condition is what gets removed:

-      "Condition": {
-        "StringEquals": {
-          "ec2:CreateAction": [
-            "CreateVolume",
-            "CreateSnapshot"
-          ]
-        }
-      },

So false is the existing, narrower behavior and true is the opt-in that broadens ec2:CreateTags to already-existing volumes/snapshots (which is what VolumeAttributesClass tag modification needs). Defaulting to true would relax the policy for every current user on upgrade rather than preserve it — I think that's the inverse of what you were guarding against.

That said, your underlying requirement — the default must be the backwards-compatible value, and any change must be opt-in — is exactly right, and it's satisfied today. If the concern is that a false default reads like it's taking something away, I'm happy to flip the variable's sense so the default is literally true:

variable "ebs_csi_restrict_tagging_to_create" {
  description = "Determines whether `ec2:CreateTags` is restricted to resource-creation via the `ec2:CreateAction` condition. Set to `false` to allow the EBS CSI driver to tag existing volumes/snapshots, which `VolumeAttributesClass` tag modifications require"
  type        = bool
  default     = true
}

Same rendered policy at the default, same opt-in semantics, and the default is true for backwards compatibility. Just say which you'd prefer and I'll push it — happy to go either way.

Renamed it to ebs_csi_restrict_tagging_to_create with default = true, so the default renders exactly the same policy as master and nothing changes for existing users. If you need the driver to tag existing volumes (e.g. for VolumeAttributesClass), you opt out by setting it to false. Merged master in too, so it should be ready for another look.