Terraform Module Error: Unsupported attribute

Terraform
1

We modularized to manage some AWS permission sets.

in modules>permission_set/module /main.tf

data "aws_ssoadmin_instances" "this" {}

# Create Permission Set
resource "aws_ssoadmin_permission_set" "this" {
  name             = var.name
  description      = var.description
  instance_arn     = tolist(data.aws_ssoadmin_instances.this.arns)[0]
  session_duration = var.session_duration
}

# Attach AWS Managed Policy
resource "aws_ssoadmin_managed_policy_attachment" "this" {
  count              = length(var.managed_policy_arn)
  instance_arn       = aws_ssoadmin_permission_set.this.instance_arn
  managed_policy_arn = var.managed_policy_arn[count.index]
  permission_set_arn = aws_ssoadmin_permission_set.this.arn
}

# Create Permission Set
data "aws_iam_policy_document" "this" {
  count = var.inline_policy == null ? 0 : 1
  dynamic "statement" {
    for_each = var.inline_policy.statement
    content {
      sid       = statement.value.sid == null ? "1" : statement.value.sid
      effect    = statement.value.effect == null ? "Allow" : statement.value.effect
      actions   = statement.value.actions
      resources = statement.value.resources
    }
  }
}

resource "aws_ssoadmin_permission_set_inline_policy" "this" {
  count              = var.inline_policy == null ? 0 : 1
  inline_policy      = data.aws_iam_policy_document.this[0].json
  instance_arn       = aws_ssoadmin_permission_set.this.instance_arn
  permission_set_arn = aws_ssoadmin_permission_set.this.arn
}

in modules/permission_set/ps_admin.tf

module "admin" {
  source = "./module"

  name               = "admin"
  managed_policy_arn = [
    "arn:aws:iam::aws:policy/AdministratorAccess"
  ]
  inline_policy = {
    statement = concat(
      local.default_inline_policy,
      [
        # Quicksight Policy
        {
          effect  = "Deny"
          actions = [
            "quicksight:CreateAdmin",
            "quicksight:CreateUser",
          ]
          resources = [
            "*"
          ]
        }
      ]
    )
  }

}

So before adding sid and effect lines to the dynamic “statement”, it has been worked well. But, I wanna use effect variable not to use the default effect “allow” But I got this below error. How can I fix this?
Since I didn’t define all the effect and sid for all the other inline policies I want to make sid=1, effect=allow as a default (if effect and sid are not defined in modules/permission_set/ps_*.tf

│ Error: Unsupported attribute
│
│ on modules/permission_set/module/main.tf line 26, in data “aws_iam_policy_document” “this”:
│ 26: effect = statement.value.effect == null ? “Allow” : statement.value.effect
│ ├────────────────
│ │ statement.value is object with 2 attributes
│
│ This object does not have an attribute named “effect”.
╵
╷
│ Error: Unsupported attribute
│
│ on modules/permission_set/module/main.tf line 26, in data “aws_iam_policy_document” “this”:
│ 26: effect = statement.value.effect == null ? “Allow” : statement.value.effect
│ ├────────────────
│ │ statement.value is object with 2 attributes
│
│ This object does not have an attribute named “effect”.
╵
╷
│ Error: Unsupported attribute
│
│ on modules/permission_set/module/main.tf line 26, in data “aws_iam_policy_document” “this”:
│ 26: effect = statement.value.effect == null ? “Allow” : statement.value.effect
│ ├────────────────
│ │ statement.value is object with 2 attributes
│
│ This object does not have an attribute named “effect”.

cc. Terraform Registry

2

I solved this error by changing [1] to [2] in modules>permission_set/module /main.tf.
But I still don’t get why [1] doesn’t work. It seems like null issue.

#[1]
sid       = statement.value.sid == null ? "1" : statement.value.sid
effect    = statement.value.effect == null ? "Allow" : statement.value.effect

# [2]
sid       = try(statement.value.sid, "")
effect    = try(statement.value.effect, "Allow")
3

Hi @100sun,

It’s hard to determine exactly what the problem may be without the variable type declaration, but I’m guessing there is no defined type for statements, in which case it could be various shapes of objects or maps depending on the values passed in. If this is the case, then the try function would need to be used when you cannot tell what attributes the objects will have.

You may want to consider refining the variable type to be more explicit, so that it’s easier to work with complex types like this without the need for dynamic lookups and the greater possibility of errors. If optional attributes and defaults are a problem for the type declaration, the next v1.3 release will contain a new optional attributes system for modules which you can see discussion about here: Request for Feedback: Optional object type attributes with defaults in v1.3 alpha

Thanks!