[Bug]: network policy doesn't seem to be applied correctly to snowflake_user in the first time

[Mattioli]

Terraform CLI Version

1.7.4

Terraform Provider Version

1.0.0

Company Name

No response

Terraform Configuration

BEFORE
resource "snowflake_network_policy_attachment" "allow_gcp_ingress" {
  network_policy_name = snowflake_network_policy.allow_gcp_ingress.name
  users = [
    snowflake_user.airbyte.name
  ]
}

AFTER
resource "snowflake_user" "airbyte" {
  name           = "AIRBYTE_USER"
  password       = var.airbyte_user_password
  default_role   = snowflake_account_role.airbyte.name
  network_policy = snowflake_network_policy.allow_gcp_ingress.name
}

PRESENT BOTH BEFORE AND AFTER
resource "snowflake_network_policy_attachment" "allow_vpn_ingress" {
  network_policy_name = snowflake_network_policy.allow_vpn_ingress.name
  set_for_account     = true
}

Category

category:resource

Object type(s)

No response

Expected Behavior

I expected the snowflake_user network policy to be correctly migrated from 0.94 to 0.95.

Actual Behavior

I migrated directly from 0.94 to 1.0.0 and found a issue that I believe might be related from changes from 0.94 to 0.95.

Before, I had a snowflake_network_policy_attachment tying a user and a network_policy (GCP in this case). At the same time, I had a VPN policy set for the account. When I migrated from 0.94 to 1.0.0, I added the network_policy field to the snowflake_user resource and removed the snowflake_network_policy_attachment resource. At the same time, I kept the VPN policy that is set for the account.

When I ran the plan, there was no diff related to the user's network policy. However, after applying, if I run a plan with the exact same code, the diff shows that the network policy tied to the user is the VPN one (the account one) instead of the GCP one. I believe this happened because the account one took precedence over the user one but the Snowflake docs says it should be the other way.

I had to run the apply again to fix things. While this is fine in staging, this might be troublesome to our production environment, so I'd like to know if there's anything I can do for the first apply to work correctly when doing it in production. Thank you.

Steps to Reproduce

1. Go to the provider in version 0.94
2. Copy the "BEFORE" and the "PRESENT IN BOTH" configuration
3. Apply
4. Upgrade to 0.95
5. Remove the "BEFORE" configuration and add the "AFTER" configuration
6. Apply
7. Notice that plan still shows changes

How much impact is this issue causing?

Medium

Logs

No response

Additional Information

No response

Would you like to implement a fix?

• Yeah, I'll take it 😎

[sfc-gh-jmichalak]

Hi @Mattioli 👋

This happens because in one step Terraform tries to

• remove the attachment because of removing snowflake_network_policy_attachment
• this does not get detected in snowflake_user initially because, in the state, there's still the attached policy. Terraform still thinks that it's attached, but this gets fixed during another refresh after removing the attachment - that's why we can see the diff during later terraform plan

To perform the migration without detaching the policy, we recommend splitting it into the following steps (following our migration guide):

1. Add network_policy = snowflake_network_policy.allow_gcp_ingress.name to your user configuration.
2. Remove the attachment from the config and from the state with the state rm command.
3. Run terraform plan; this should result in an empty plan.

In the mentioned migration guide, there are links to similar issues and discussions.

Please let us know if this helps, or if you still have this problem.

[Mattioli]

@sfc-gh-jmichalak thank you for the answer, that makes sense.

Just another follow-up question, please: in our production changes we will actually not remove the related snowflake_network_policy_attachment resource, but rather remove the related snowflake_user name id from the users field (we are not removing the attachment because there are other entries not managed by TF on users).

Do I need to do something special in this case? In other words, I will simply skip step 2 (using state rm) and run steps 1 and 3, right?

[sfc-gh-jmichalak]

In this scenario, I think it's best to:

1. Add network_policy = snowflake_network_policy.allow_gcp_ingress.name to your user configuration.
2. Adjust the snowflake_network_policy_attachment resource (remove the user from users field).
3. Remove the attachment ONLY FROM the state with the state rm command.
4. Run terraform import for this resource.
5. Run terraform plan; this should result in an empty plan.

If you would just skip step 2, and remove the user from the list instead, I think it would still get unassigned.

[Mattioli]

Run terraform import for this resource.

Which resource should be imported here? And curious why this import step isn't needed in the first case (where the attachment is actually removed from the config)...

[sfc-gh-jmichalak]

snowflake_network_policy_attachment should be reimported, because if you just remove the user from the list, the policy will get unassigned. You can also modify state manually, but that's not recommended by Terraform (read docs).

It's not needed in the first scenario, because snowflake_network_policy_attachment is removed from the state and the config anyway. It's needed in this one, because there are still some attachments managed by this resource.

[Mattioli]

Got it. Thanks for all the help @sfc-gh-jmichalak!