minio_iam_service_account resource is updated on every run in 2.0.0 about terraform-provider-minio HOT 13 OPEN

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

from terraform-provider-minio.

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

from terraform-provider-minio.

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

from terraform-provider-minio.

@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

from terraform-provider-minio.

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.

from terraform-provider-minio.

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

from terraform-provider-minio.

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

from terraform-provider-minio.

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.

from terraform-provider-minio.

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.

from terraform-provider-minio.

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

from terraform-provider-minio.

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.

from terraform-provider-minio.

@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.

from terraform-provider-minio.

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.

from terraform-provider-minio.