Terraform resolving loop-CodePudding

I want AWS instance that is allowed to read its own tags, but not of any other resources? Normally, idea of instance being allowed to do something is expressed by iam_role and aws_profile_instance, but when writing policy for the role, I can't refer to ARN of instance, since it creates loop.

It makes sense: normally, Terraform creates resources in order, and once created it never revisits them. What I want requires creating instance without iam role, and attach role to instance after instance is created.

Is it possible with Terraform?

EDIT: (minimal example):

 ; cat problem.tf
resource "aws_instance" "problem" {
  instance_type        = "t2.medium"
  ami                  = "ami-08d489468314a58df"
  iam_instance_profile = aws_iam_instance_profile.problem.name
}

resource "aws_iam_policy" "problem" {
  name = "problem"
  policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      { Effect   = "Allow"
        Action   = ["ssm:GetParameters"]
        Resource = [aws_instance.problem.arn]
      }
    ]
  })
}

resource "aws_iam_role" "problem" {
  name                = "problem"
  managed_policy_arns = [aws_iam_policy.problem.id]
  # Copy-pasted from aws provider documentation. AWS is overcomplicated.
  assume_role_policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Action = "sts:AssumeRole"
        Effect = "Allow"
        Principal = {
          Service = "ec2.amazonaws.com"
        }
      },
    ]
  })
}

resource "aws_iam_instance_profile" "problem" {
  name = "problem"
  role = aws_iam_role.problem.name
}
 ; terraform apply -refresh=false
Acquiring state lock. This may take a few moments...
Releasing state lock. This may take a few moments...
╷
│ Error: Cycle: aws_iam_instance_profile.problem, aws_instance.problem, aws_iam_policy.problem, aws_iam_role.problem
│
│
╵

CodePudding user response：

The problem here arises because you've used the managed_policy_arns shorthand to attach the policy to the role in the same resource that declares the role. That shorthand can be convenient in simple cases, but it can also create cycle problems as you've seen here because it causes the role to refer to the policy, rather than the policy to refer to the role.

The good news is that you can avoid a cycle here by declaring that relationship in the opposite direction, either by using the separate

The policy won't be connected to the role until both the role and the instance are both created, so it's important to consider here that the software running in the instance might start up before the role's policy is assigned, and so it should be prepared to encounter access violation errors for some time after boot and keep trying periodically until it succeeds, rather than aborting at the first error.

If this is part of a shared module that's using the functionality of the EC2 instance as part of the abstraction it's creating, it can help the caller of the module to be explicit about that hidden dependency on the aws_iam_role_policy by including it in any output values that refer to behavior of the EC2 instance that won't work until the role policy is ready. For example, if the EC2 instance is providing an HTTPS service on port 443 that won't work until the policy is active:

output "service_url" {
  value = "https://${aws_instance.example.private_ip}/"

  # Anything which refers to this output value
  # should also wait until the role policy is
  # created before taking any of its actions,
  # even though Terraform can't "see" that
  # dependency automatically.
  depends_on = [aws_iam_role_policy.example]
}