minio_iam_service_account resource is updated on every run in 2.0.0

[sdejong629]

Prerequisites

• Be sure that theres no open issue already.

Description

When using a minio_iam_service_account resource, a plan and apply always updates the resource, even when no changes have been made to terraform code.

terraform config

resource "minio_iam_user" "minio_user" {
  name = "minio-user"
}

resource "minio_iam_policy" "minio_user" {
  name   = "minio-user-policy"
  policy = <<EOF
{
  "Version":"2012-10-17",
  "Statement": [
    {
      "Sid":"ReadAllBuckets",
      "Effect": "Allow",
      "Action": ["s3:GetObject","s3:GetBucketLocation","s3:ListBucket","s3:ListenBucketNotification"],
      "Principal":"*",
      "Resource": "arn:aws:s3:::*/*"
    }
  ]
}
EOF
}

resource "minio_iam_user_policy_attachment" "minio_user" {
  user_name   = minio_iam_user.minio_user.id
  policy_name = minio_iam_policy.minio_user.id
}

resource "minio_iam_service_account" "minio_user" {
  target_user   = minio_iam_user.minio_user.name
}

Terraform plan output:

~ resource "minio_iam_service_account" "minio_user" {
        id            = "sevice_account_id"
      - policy        = jsonencode(
            {
              - Statement = [
                  - {
                      - Action   = [
                          - "s3:ListBucket",
                          - "s3:ListenBucketNotification",
                          - "s3:GetBucketLocation",
                          - "s3:GetObject",
                        ]
                      - Effect   = "Allow"
                      - Resource = [
                          - "arn:aws:s3:::*/*",
                        ]
                      - Sid      = "ReadAllBuckets"
                    },
                ]
              - Version   = "2012-10-17"
            }
        ) -> null
        # (6 unchanged attributes hidden)
    }

Steps to Reproduce

1. Add minio_iam_service_account resource for a minio user.
2. Run a terraform plan & apply
3. Run another terraform plan and apply
4. It wil show changes like stated above

Expected behavior:
No changes should occur after the initial creation

Actual behavior:
The policy is updated/removed every run, eventhough no changes have been made

Reproduces how often: [What percentage of the time does it reproduce?]
100%

Versions

2.0.0

Additional Information

[acolombier]

We are also impacted by this - looking at the plan, the reason seems to be than target_user is set using LDAP username, but somehow when the resource is read, the name become the LDAP DN.

To give an example, you would need to set the target_user to minio-user from a user with DN CN=minio-user,DC=example,DC=org, but upon next execution, TF would force replacement because of CN=minio-user,DC=example,DC=org != minio-user

[pjsier]

It looks like these two may be separate issues. I'm not sure about the policy, but looks like the target_user issue probably came from #525. I should be able to put in a quick PR to address that

[pjsier]

@acolombier just opened #547, would you be able to give that a try? I'm not sure the best way to test locally, so if you have a minimal example of testing with an LDAP user I can also try that. Ideally we would get that incorporated into our test pipeline as well

[acolombier]

Unfortunately, the IaC suffering from this issue is in an automated production pipeline, so I won't be able to test in there till we have a proper release. I did comment your PR tho, hopefully this is adding some more context to cover the issue.

[sdejong629]

Ran this on version 2.0.1 and it still has the same issue. Hope you guys get this fixed soon, so I can move to the new version

[Nabsku]

Also running into this issue. anything I can do to help with debugging?

[pjsier]

Sorry for the delay on this @Nabsku if you're still interested in helping to debug, you should be able to use the git branch in #547 as the provider source rather than the central registry.

[arusa]

Hi @pjsier, I'm having the same issue as the original poster, but I'm not using LDAP and #547 seems to have something to do with LDAP?

My problem is just that the policy in the service_accounts gets updated on every run.

[pjsier]

@arusa thanks for the report! Could you share the output of your plan and what you were trying to change?

[arusa]

It's exactly what the original author of this issue reported.

I ran terraform apply and everything finished successfully.

Then I immediately ran terraform plan again and it showed changes for all minio_iam_service_account resources, although nothing was changed in the configuration:

Terraform used the selected providers to generate the following execution
plan. Resource actions are indicated with the following symbols:
  ~ update in-place
Terraform will perform the following actions:
  # xxx.minio_iam_service_account.this will be updated in-place
  ~ resource "minio_iam_service_account" "this" {
        id            = "XXXX"
      - policy        = jsonencode(
            {
              - Statement = [
                  - {
                      - Action   = [
                          - "s3:*",
                        ]
                      - Effect   = "Allow"
                      - Resource = [
                          - "arn:aws:s3:::mybucket/*",
                        ]
                    },
                ]
              - Version   = "2012-10-17"
            }
        ) -> null
        # (6 unchanged attributes hidden)
    }
  # xxx2.minio_iam_service_account.this will be updated in-place
  ~ resource "minio_iam_service_account" "this" {
        id            = "XXX2"
      - policy        = jsonencode(
            {
              - Statement = [
                  - {
                      - Action   = [
                          - "s3:*",
                        ]
                      - Effect   = "Allow"
                      - Resource = [
                          - "arn:aws:s3:::mybucket2/*",
                        ]
                    },
                ]
              - Version   = "2012-10-17"
            }
        ) -> null
        # (6 unchanged attributes hidden)
    }
Plan: 0 to add, 2 to change, 0 to destroy.

[arusa]

@pjsier any news on that? I just ran terraform again and it once again wants to replace a minio_iam_service_account, that I haven't touched.

[acolombier]

While the PR is being reviewed, this is the workaround I have been using to prevent the cycling of SA:

resource "minio_iam_service_account" "this" {
  // ...
  lifecycle {
    ignore_changes = [
      target_user # FIXME Workaround till https://github.com/aminueza/terraform-provider-minio/pull/547 gets merged
    ]
  }
}

If you expect the SA to be recreated due to a genuine target_user user change, you will have to terraform taint the resource.

[dmaes]

People seem to be confusing the policy change and the target_user change here. Original issue seems to be about the policy change. This issue is the same as #517 (fixed in #518), which seems to have re-surfaced since v2.0.0. When using mc admin user svcacct info <alias> <service-account>, the response clearly states Implied for Policy. I would suspect the go lib this terraform provider uses would do the same, and I think the terraform code should thus not make any changes when policy is not set and Minio servers says SA's policy is implied.

mcli admin user svcacct info local/ COYEK48Y9JMEM3FH2U6P
AccessKey: COYEK48Y9JMEM3FH2U6P
ParentUser: terraform
Status: on
Name:
Description:
Policy: implied
Expiration: no-expiry

[YannickTeKulve]

Hi

I'm running in the same issue (the policy change issue that is). I did some digging in the provider and after changing the minio version in the docker-copose file to the most recent version the TestServiceAccount_Policy unit test failed. After some trial and error I determined that minio release 2023-10-25T06-33-25Z still works but 2023-11-01T01-57-10Z release is breaking.

I will try to look in it further next week. But if somebody want's to fix it be my guest.