Provider incorrectly marks snowflake_user.name as sensitive

[qbatten]

Terraform CLI and Provider Versions

❯ terraform version
Terraform v1.6.6
on darwin_arm64

• provider registry.terraform.io/airbytehq/airbyte v0.4.1
• provider registry.terraform.io/snowflake-labs/snowflake v0.87.2

Your version of Terraform is out of date! The latest version
is 1.7.5. You can update by downloading from https://www.terraform.io/downloads.html

Terraform Configuration

terraform {
  required_version = "1.6.6"
  required_providers {

    snowflake = {
      source  = "Snowflake-Labs/snowflake"
      version = "0.87.2"
    }
  }
}

provider "snowflake" {
  account  = local.snowflake_creds.account_id
  role     = "USERADMIN"
  alias    = "useradmin"
}


resource "snowflake_user" "user" {
  name              = "USER"
  login_name        = "[email protected]"
  provider          = snowflake.useradmin
}

locals {
  some_users = toset([
    snowflake_user.user.name,
  ])
}

resource "snowflake_grant_account_role" "grant_role_to_users" {
  for_each = local.some_users
  provider   = snowflake.useradmin
  role_name  = "THE_ROLE"
  user_name  = each.key
}

Expected Behavior

I expect this to work. The list of user's names should not be marked sensitive, and the role should be granted. User names are not sensitive data, Snowflake says as such here ("Usernames are not sensitive data and are returned by other commands and functions"). I don't believe I've encountered any other providers that mark usernames as sensitive. But it seems that snowflake_user.name is indeed considered sensitive for this provider? (I don't know much Go, so hopefully I'm linking to the right line.)

I'm wondering if this PR actually meant to un-sensitive-ize name instead of login_name and a mistake was made? According to Snowflake, login_name is more sensitive than name. And name is the internal identifier for a user, not login_name, so by making name sensitive, it makes it impossible to do simple references to users (like I'm trying to do here), while login_name being marked sensitive wouldn't have that kind of impact.

Actual Behavior

Instead, the plan is failing due to the below error, because user.name is marked as sensitive. I saw & commented on this older issue, which the conversation made seem like it was resolved... but it doesn't seem to have been correctly resolved. It looks like login_name got changed to not-sensitive, but name is still sensitive?

╷
│ Error: Invalid for_each argument
│ 
│   on snowflake.tf line 162, in resource "snowflake_grant_account_role" "grant_analyze_to_analyzers":
│  162:   for_each = local.some_users
│     ├────────────────
│     │ local.some_users has a sensitive value
│ 
│ Sensitive values, or values derived from sensitive values, cannot be used
│ as for_each arguments. If used, the sensitive value could be exposed as a
│ resource instance key.

Steps to Reproduce

1. terraform apply

How much impact is this issue causing?

Medium

Logs

No response

Additional Information

Thanks for you help!

[sfc-gh-asawicki]

Hey @qbatten. Thanks for reaching out to us.

We will address it during the resources redesign: https://github.com/Snowflake-Labs/terraform-provider-snowflake/blob/main/ROADMAP.md#supporting-all-snowflake-ga-features.

[sfc-gh-asawicki]

Hey @qbatten, the fix was included in #3013 and will be released in v0.95.0 today or tomorrow (we have to wrap up a few other PRs before making a release). Please check the migration guide and report any problems.

[sfc-gh-asawicki]

Hey @qbatten.
We have just released v0.95.0 of the provider. It contains a reworked snowflake_user resource. Please consult the migration guide.

[sfc-gh-asawicki]

Closing the issue due to inactivity. Please create a new one if the issue persists in the newest version of the provider.