Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

destroying aws_iam_policy_attachment to a managed policy deletes everyone's attachments #94

Closed
hashibot opened this issue Jun 13, 2017 · 2 comments
Labels
bug Addresses a defect in current functionality. service/iam Issues and PRs that pertain to the iam service.

Comments

@hashibot
Copy link

This issue was originally opened by @slowbluecamera as hashicorp/terraform#5483. It was migrated here as part of the provider split. The original body of the issue is below.


If you use the "aws_iam_policy_attachment" resource to attach a role to a managed_policy, when you destroy the configuration, it will remove attachments made by other configurations, or even manually setup attachments.

In the example configurations below, configuration "plan_one.tf" sets up an attachment to the "AWSLambdaBasicExecutionRole" managed policy. The configuration "plan_two.tf" also sets up a similar attachment. If you apply both configurations, and then delete one, you'll find that both attachments have bene removed.

Also, if you have set up role attachments to the managed policy by other scripts, or manually, then you will find that those attachments have been removed (which is how we discovered it! :-( ).

Have reproduced this in terraform-0.6.12 on OSX.

(This is my first issue reported to the terraform project. I've reviewed submitting guidelines and tried to be complete, but I'd like this issue to be as useful as possible. So if there is any additional information needed or changes in style that would be helpful, please don't hesitate to let me know. Thanks!)

Workarounds:

  • don't use managed policies in terraform configurations
  • (haven't tried this) use IAM to permissions to prevent terraform from deleting attachments it hasn't set up, and then make sure your terraform configurations don't use the same managed policies.

Steps to reproduce:

  one/
     plan_one.tf
     variables.tf
  two/
     plan_two.tf
     variables.tf
  1. create two configurations as above directories (using the file contents below).
  2. set environment variables as appropriate
    export TF_VAR_access_key=AWS ACCESS KEY
    export TF_VAR_secret_key=AWS SECRET KEY
  3. "cd one; terraform apply" to create config one
  4. "cd two; terraform apply" to create config two
  5. "cd one; terraform destroy" to destroy config one
  6. "cd two; terraform plan" to see if config two is still complete

Notice that the policy attachment in plan_two.tf is no longer there.

plan_one.tf

provider "aws" {
  access_key = "${var.access_key}"
  secret_key = "${var.secret_key}"
  region = "${var.region}"
}

# Configure security settings for Lambda
resource "aws_iam_role" "lambda_exec_role" {
  name = "PlanOneLambdaExecRole"
  assume_role_policy = <<POLICY
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "lambda.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}
POLICY
}

# Attach role to Managed Policy
resource "aws_iam_policy_attachment" "test_attach" {
  name = "PlanOneLambdaExecPolicy"
  roles = ["${aws_iam_role.lambda_exec_role.id}"]
  policy_arn = "arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole"
}

two/plan_two.tf

provider "aws" {
  access_key = "${var.access_key}"
  secret_key = "${var.secret_key}"
  region = "${var.region}"
}

# Configure security settings for Lambda
resource "aws_iam_role" "lambda_exec_role" {
  name = "PlanTwoLambdaExecRole"
  assume_role_policy = <<POLICY
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "lambda.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}
POLICY
}

# Attach role to Managed Policy
resource "aws_iam_policy_attachment" "test_attach" {
  name = "PlanTwoLambdaExecPolicy"
  roles = ["${aws_iam_role.lambda_exec_role.id}"]
  policy_arn = "arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole"
}

variables.tf (identical in both configurations)

# to set aws key env variables
variable "access_key" {}
variable "secret_key" {}

variable "region" {
  default = "us-east-1"
}
@bflad
Copy link
Contributor

bflad commented May 3, 2018

For those finding this old issue which I'm going to close out now, we updated the aws_iam_policy_attachment resource documentation to very obviously display a big red warning message at the top. https://www.terraform.io/docs/providers/aws/r/iam_policy_attachment.html

WARNING: The aws_iam_policy_attachment resource creates exclusive attachments of IAM policies. Across the entire AWS account, all of the users/roles/groups to which a single policy is attached must be declared by a single aws_iam_policy_attachment resource. This means that even any users/roles/groups that have the attached policy via some mechanism other than Terraform will have that attached policy revoked by Terraform. Consider aws_iam_role_policy_attachment, aws_iam_user_policy_attachment, or aws_iam_group_policy_attachment instead. These resources do not enforce exclusive attachment of an IAM policy.

In almost all cases we tend to highly recommend using the separate aws_iam_group_policy_attachment, aws_iam_role_policy_attachment, and aws_iam_user_policy_attachment resources.

@bflad bflad closed this as completed May 3, 2018
@ghost
Copy link

ghost commented Apr 6, 2020

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.

If you feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. Thanks!

@ghost ghost locked and limited conversation to collaborators Apr 6, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
bug Addresses a defect in current functionality. service/iam Issues and PRs that pertain to the iam service.
Projects
None yet
Development

No branches or pull requests

3 participants