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

vault_aws_auth_backend_role always detects a drift #853

Closed
ghost opened this issue Aug 26, 2020 · 5 comments · Fixed by #857
Closed

vault_aws_auth_backend_role always detects a drift #853

ghost opened this issue Aug 26, 2020 · 5 comments · Fixed by #857

Comments

@ghost
Copy link

ghost commented Aug 26, 2020

Hi there,

As many time i run TF following script it will detect change

HCL

resource "vault_auth_backend" "aws_auth_backend" {
  type = "aws"
  path = "aws"
}


resource "vault_aws_auth_backend_role" "aws_ec2_auth_role" {
  for_each   = var.aws_ec2_auth_role

  backend                          = vault_auth_backend.aws_auth_backend.path
  auth_type                        = "ec2"

  role                             = test-role

  resolve_aws_unique_ids           = false

  bound_ami_ids                    = ["ami-0bcc094591f354be2"]
  bound_account_ids                = []
  bound_regions                    = ["us-east-1"]
  bound_vpc_ids                    = ["vpc-d903a9a8"]
  bound_subnet_ids                 = ["subnet-b42f1a77"]
  bound_iam_role_arns              = ["arn:aws:iam::123456789012:role/vault-client-role"]
  bound_iam_instance_profile_arns  = ["arn:aws:iam::123456789012:instance-profile/vault-client-role"]
 
  token_ttl                        = 60
  token_max_ttl                    = 120
  token_policies                   = ["default"]
}

output

Terraform v0.12.23
Configuring remote state backend...
Initializing Terraform configuration...
2020/08/26 19:35:31 [DEBUG] Using modified User-Agent: Terraform/0.12.23 TFE/v202003-1



-/+ resource "vault_aws_auth_backend_role" "aws_ec2_auth_role" {
        allow_instance_migration        = false
        auth_type                       = "ec2"
        backend                         = "aws"
      - bound_account_ids               = [] -> null
        bound_ami_ids                   = [
            "ami-0bcc094591f354be2",
        ]
      - bound_ec2_instance_ids          = [] -> null
        bound_iam_instance_profile_arns = [
            "arn:aws:iam::123456789012:instance-profile/vault-client-role",
        ]
      - bound_iam_principal_arns        = [] -> null
        bound_iam_role_arns             = [
            "arn:aws:iam::123456789012:role/vault-client-role",
        ]
        bound_regions                   = [
            "us-east-1",
        ]
        bound_subnet_ids                = [
            "subnet-b42f1a77",
        ]
        bound_vpc_ids                   = [
            "vpc-d903a9a8",
        ]
        disallow_reauthentication       = false
      ~ id                              = "auth/aws/role/test-role" -> (known after apply)
      ~ resolve_aws_unique_ids          = true -> false # forces replacement
        role                            = "test-role"
      - token_bound_cidrs               = [] -> null
      - token_explicit_max_ttl          = 0 -> null
        token_max_ttl                   = 120
      - token_no_default_policy         = false -> null
      - token_num_uses                  = 0 -> null
      - token_period                    = 0 -> null
        token_policies                  = [
            "default",
        ]
        token_ttl                       = 60
        token_type                      = "default"
    }

if you keep plan and applying this will detect change every time
@catsby
Copy link
Contributor

catsby commented Aug 27, 2020

Hello - I believe this stems from the use of resolve_aws_unique_ids with auth type ec2; it seems we only expect that attribute to be set or used if the auth type is iam:

Unfortunately it's not clear to me from the documentation if that assumption is correct or not. On the surface (reading our documentation and Vault's documentation), it seems correct that resolve_aws_unique_ids would only apply to iam type authentication, but I admit I don't know for sure. Is there any information you have that supports it's use with auth type ec2?

@ghost
Copy link
Author

ghost commented Aug 27, 2020

I was implementing IAM and EC2 vault auth options and i had resolve_aws_unique_ids=false for IAM auth as it was giving error that its not able resolve IAM to aws ID as instance where terraform is running dose not have access to other aws accounts to do resolution.
For EC2 i left this parameter same but after commenting out resolve_aws_unique_ids for EC2 auth method it dose not detect any state drift

I guess if resolve_aws_unique_ids is not supported for auth_type=ec2 must be just ignored ?

@ghost ghost removed the waiting-response label Aug 27, 2020
@catsby
Copy link
Contributor

catsby commented Aug 28, 2020

It is my understanding that resolve_aws_unique_ids should be ignored when using EC2 as the auth_type; The auth code in Vault only appears to reference it when using the IAM auth type:

The above code snippet is dense, especially if you are not familiar with Vault's codebase, but searching around that file shows that the references to resolve_aws_unique_ids (which gets mapped to ResolveAWSUniqueIDs) is only used when we're dealing with IAM auth types.

@ghost
Copy link
Author

ghost commented Aug 28, 2020

so far everything is stable but it will be nice to see same warnings from terraform when using parameters that are not compatible toughener

@ghost ghost removed the waiting-response label Aug 28, 2020
@catsby
Copy link
Contributor

catsby commented Aug 31, 2020

Hey @papovyr - unfortunately I'm not sure Terraform currently supports detecting and warning based on the values of another attribute of the resource. There exists a GitHub issue for the feature, but it's not clear if/when it could be available (hashicorp/terraform-plugin-sdk#233),

For now, I've opened up #857 to add documentation to clarify usage. I hope that suffices.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant