[❄️ Snowflake Official ] Grant Issues Update

[sfc-gh-swinkler]

We, the Snowflake Terraform Provider team, are aware of the many grant resource issues which negatively impact users. Grant resources are a critical piece of infrastructure required by everyone, and even small issues can become major blockers. This is extremely frustrating, and we apologize for any inconvenience you have experienced when using these resources.

The existing 26 grant resources (which comprise about 1/3 of all resource types) are difficult to maintain and there are insufficient tests. Even small changes, seemingly innocuous, have lead to breaking changes for users. The evidence suggests that we cannot safely apply changes to or maintain these current grant resources.

We present here our solution. As originally outlined in Grant Resource Refactoring Discussion we plan to deprecate all 26 of the existing grant resources and replace them with three new resources:

grant_privileges_to_role, grant_privileges_to_database_role, and grant_ownership_to_role.

These resources more closely match the API, and have been written into our new SDK framework. This means it is well tested (unit + integration tests) and is thus a lot easier to maintain. The existing grant resources will be removed from the provider in a later 1.0 release. We do not plan to further patch or maintain these old grant resources going forward given the high risk.

We understand that this will mean considerable rewrite for many users. If it was not so urgent to fix grants, and relieve the stress users have been experiencing over this problematic resource, we would wait until version 2.0 to release this kind of change. We thank you in advance for your patience and understanding.
##Examples
Note: the complete schema will be available in the documentation when this resource is available.

Global Privileges

resource "snowflake_grant_privileges_to_role" "g" {
  privileges = ["MANAGE GRANTS", "MONITOR USAGE"]
  role_name  = snowflake_role.r.name
  on_account = true
}

Account Object Privileges

resource "snowflake_grant_privileges_to_role" "g1" {
  privileges = ["MONITOR", "CREATE SCHEMA"]
  role_name = snowflake_role.r.name
  on_account_object {
    object_type = "DATABASE"
    object_name = snowflake_database.d.name
  }
}

Schema Privileges

resource "snowflake_grant_privileges_to_role" "g2" {
  depends_on = [ snowflake_schema.s , snowflake_table.t]
  role_name = snowflake_role.r.name
  privileges = ["SELECT", "INSERT"]
  on_schema_object {
    all {
      object_type_plural = "TABLES"
      in_schema = "\"test_db\".\"test_schema\""
    }
  }
}

Schema Object Privileges

resource "snowflake_grant_privileges_to_role" "g2" {
  depends_on = [ snowflake_schema.s , snowflake_table.t]
  role_name = snowflake_role.r.name
  privileges = ["SELECT"]
  on_schema_object {
    future {
      object_type_plural = "TABLES"
      in_database = snowflake_database.d.name
    }
  }
}

Q: What does this mean for me?
A: We highly recommend migrating to the new grant resources at your earliest convenience. The easiest thing to do will be to destroy all your existing grants and re-create them. Since this may not be possible for all users, it’s also possible to import the grants.

Q: Can you patch one particular issue for me?
A: We have seen repeated issues while attempting to patch the existing grant resources. Unintended side effects have been myriad. The lack of tests means we cannot reliably screen for those side effects. Given the risk this imposes to customers, we cannot continue patching that code.

[bjornburrell-8451]

Has anyone on the Snowflake Terraform Provider team created a state importer tool for the provider. That would certainly help ease this migration.

If not, I'll get working on one.

[bjornburrell-8451]

Also - thanks the the team for all the hard work on the provider

[Pete-rePete]

I hacked together an importer (parser here, script here) for the core resources about a year and a half ago (back on chanzuckerberg). It's out-of-date, but I'll probably rewrite large chunks of it for this migration.

Or if you build one first, I might use that 😄

[toni-moreno]

Instead of import , I would prefer a step by step guide on how migrate my current grant resources.

1. snowflake_stage_grant
2. snowflake_account_grant
3. snowflake_warehouse_grant
4. snowflake_database_grant
5. snowflake_schema_grant

To the new one:

1. grant_privileges_to_role,
2. grant_privileges_to_database_role
3. grant_ownership_to_role

And If possible if there is any way to do it without removing the old resource and recreating the new one , this could impact on the service ( maybe something like to do a terraform mv but from two different types of resource , obviously not with the terraform tool maybe with another tool created just to help us in this resource type migration, even being different resource type they both would have the same snowsql behavior in the snowflake platform, so maybe wouldn't be needed to revoke and grant again the same privileges).

Any idea, on this direction would be greatly appreciated

[emoyer0928]

I understand that the recommendation is to migrate to the new grant resources at our earliest convenience. Are the new grant resources ready for use?

[bennylu2]

When are the new grant resources going to be available?

[Pete-rePete]

When will this be released? Prior to the release, could you please publish the import syntax so we can prepare?

[bennylu2]

It seems like the current outstanding issue with grants is the enable multiple grants bug that was introduced recently. Can you help me understand why that change can't be reverted? It would allow us to continue our work without breaking all existing grants and avoid rewriting all our code immediately. And then the Snowflake team can work on the new resources that we can migrate to when we're ready

[skwon615]

Totally agreed here - especially for teams managing tons and tons of custom grants, to say that rewriting (+ testing) all grant resources will be "considerable" is an understatement. And that scope will only expand should there be any non-trivial bugs in 1.0 (which, given the sweeping changes involved, wouldn't be unexpected).

If the main goals are to fix the existing grant issues (tied to enabling multiple grants) and to relieve stress for users, I'd also be curious why reverting the 1-2 relevant PRs won't be sufficient to unblock us. At face value, forcing teams to either upgrade to 1.0 or be stuck in a much lower provider version (cf. #1868) doesn't sound ideal, though we'd love to hear if there are additional factors preventing the revert option.

[ndavies-om1]

I have pushed a PR to revert that PR #1898
It would be great if we could get that merged so at least grants can start working again

[ndavies-om1]

This is vastly improved because the ID of the grant resource is the principal getting the grant.
How are grants to roles for users going to be affected?

[sfc-gh-swinkler]

role grants to users will be unaffected

[rjoelnorgren]

I think it is also worth pointing out that the opt out period for bundle 2023_03, which broke provider versions <= 0.64, is scheduled to end 2023-07-10. Disabling the bundle and staying on versions <= 0.64 right now is by far the easiest way to avoid the very recently created issue introduced by the change to enable_multiple_grants.

Once the opt out period ends, we need to have a solution ready that allows us to upgrade to a version > 0.64. Forcing us to migrate to a currently unreleased API before 2023-07-10 seems like an unrealistic window to pull this off safely.

[lra]

If this is the plan, you should stop working on 0.X and focus on 1.0 because most of us can't upgrade past 0.64 and thus are unable to use any new release due to this issue.

[bastgau]

Ready to test a first version.
I have created a script to create with the current provider version 12 000 resources (i currently use 70% of resource grant types) ... and I could test that on the new provider version ...

[sfc-gh-swinkler]

The grant resource is now available in 0.68 release: https://registry.terraform.io/providers/Snowflake-Labs/snowflake/latest/docs/resources/grant_privileges_to_role

[kimLalilo]

is there a deadline by which the old version will be deprecated?

[toni-moreno]

@sfc-gh-swinkler , First of all I would like to thank the whole team for the hard work at this provider.

And I would like to notify you that documentation seems to be wrong here.

Valid object_type_plural here:

Could you update/fix resource documentation please?

[joshtree41]

These resources are so much more intuitive, thank you so much team!

[ivica-k]

For anyone in the same situation, here's the issue #1952 and the PR #1967 aims to solve it.

---

Does anyone have an idea on how to migrate from snowflake_external_table_grant to snowflake_grant_privileges_to_role including future external tables? Example resource:

resource "snowflake_external_table_grant" "select" {
  database_name = var.db_name

  privilege = "SELECT"
  roles = [
    "ROLE_1",
    "ROLE_2",
  ]

  on_future         = true
  with_grant_option = false
  provider          = snowflake.securityadmin
}

I don't see any mention of the word "external" in the docs for snowflake_grant_privilege_to_role.

I tried doing it with this

resource "snowflake_grant_privileges_to_role" "future_external_tables" {
  privileges = ["SELECT", "REFERENCES"]

  role_name  = "ROLE_1"

  on_schema_object {
    future {
      object_type_plural = "TABLES"
      in_database        = var.db_name
    }
  }
}

which does show the SELECT - FUTURE TABLE as one of the permissions, but not SELECT - FUTURE EXTERNAL TABLE.

[danu165]

I opened an issue about this here. Last I heard, the snowflake team is working on this: #1952

[mparuscio]

With the old resource snowflake_schema_grantit was possible to define the attribute revert_ownership_to_role_name but I do not see how to replicate the same behavior with the new resources.

Without this attribute if I use these new resources to grant the ownership of a schema to a specific role it works fine during the apply phase, but when I try to destroy it fails because I cannot destroy the snowflake_grant_privileges_to_role because my schema needs to have an owner.

Can someone explain it this behavior is expected or not? And, if not, will it be fixed?

[ndearaujo]

^^Bump

[sfc-gh-asawicki]

Hey. There is a new resource dedicated to handling granting ownership: https://registry.terraform.io/providers/Snowflake-Labs/snowflake/latest/docs/resources/grant_ownership. Please try using it, it should be enough to cover this use case. cc: @sfc-gh-jcieslak

[ndearaujo]

in the new resource you've linked above this attribute isn't available. The workaround here don't really seem to address the resource conflicts issues stated above.

[sfc-gh-asawicki]

The new resource handles the destroy with regranting ownership to the current role, so the error mentioned above should not happen at all.
So, with the new resource, you can achieve the desired result with destroy + new grant, or it should even work with just changing the role in the resource, because of the ForceNew on the account_role_name attribute.

[NaveenAutomate]

Hi,

I have tried to use the new resources, may be this might be an existing issue.
When a role is granted a privilege using on_schema_object { all { object_type_plural = "TABLES" in_schema = var.schema_name //qualified name } } }
the role has access to tables created as of now

but later if there are more tables created and to provide access to those tables there is no way apart from deleting the role and re creating
using future will grant access to future tables but to the one that are already created

And I was in assumption that all{} grants access to all objects for already created and future grants but is not the case, in that case can we have that explicitly mentioned in the documentation as both all and future cannot be used in single resource

it would be great if we can atleast use both all {} future {} blocks in a single resources which will save some time for already created schemas/tables or which are not tracked via terraform.

[NaveenAutomate]

If anyone has found an easy way to create a kind of read-role for a schema/database/account( select on all object types) it would be great to post here

[acheraime]

Thanks to the whole team for all the improvements. grant_privilege_to_role is a great resource that covers most of my use cases. Do you plan to add a flag/parameter to can mimic "REVOKE CURRENT GRANTS" feature?
Also any idea when the grant_ownership_to_role resource will be available?

[wcamarao]

Would appreciate an ETA as well 🙏

[sfc-gh-jcieslak]

I'll be working on an implementation of ownership-granting resource this week (it should have REVOKE CURRENT GRANTS unless there will be some complications with it)

[wcamarao]

You're a legend @sfc-gh-jcieslak! Thanks for the update 🙏

[vbruzga-tc]

will ownership-granting resources include granting ownership (on schemas, objects) to database role?

[sfc-gh-jcieslak]

Everything present in the Snowflake documentation page about GRANT OWNERSHIP should be possible in the new resource; tldr yes.

[mengjunOS]

is there any timeline on grant_privileges_to_database_role?

[argemiront]

Hey, great work there! I have a question: how grants to share will be handled? In the current snowflake_table_grant we can grant to shares but I didn't find any reference on how that will work with the new resource types.

[sfc-gh-swinkler]

Hi @argemiront ! @sfc-gh-jcieslak has a PR to add grant privilege to shares #2447. This would allow you to table access to a share.

[argemiront]

Hey, folks! Getting back to this, is there a way to have database imported privileges controlled by the new resources?

[sfc-gh-jcieslak]

@argemiront IMPORTED PRIVILEGES privilege is a special case we have to handle internally. I should pick it up this or next week.

[argemiront]

Thank you very much! I appreciate the efforts on rebuilding the grants!

[monti-python]

Thanks for the ongoing improvements, consolidating grants makes a lot of sense!

Just a simple suggestion: would it be possible to provide the schema's fully qualified name as an attribute of snowflake_schema?

Using your example above, it is straightforward to refer to a database name by using its snowflake_database.d.name attribute. This would also create a relation within terraform's dependency graph so the resources will be deployed in the right order.

resource "snowflake_grant_privileges_to_role" "g1" {
  privileges = ["MONITOR", "CREATE SCHEMA"]
  role_name = snowflake_role.r.name
  on_account_object {
    object_type = "DATABASE"
    object_name = snowflake_database.d.name
  }
}

However, referring to a schema requires its fully qualified name which is not directly available as an attribute of snowflake_schema. Forming this attribute is rather cumbersome and cannot be consolidated as a local variable, so it has to be repeated for every grant involving the schema.

resource "snowflake_grant_privileges_to_role" "g2" {
  depends_on = [ snowflake_schema.s , snowflake_table.t]
  role_name = snowflake_role.r.name
  privileges = ["SELECT", "INSERT"]
  on_schema_object {
    all {
      object_type_plural = "TABLES"
      # When referring a `snowflake_schema` resource, the syntax becomes rather ugly:
      in_schema = "\"${snowflake_schema.s.database}\".\"${snowflake_schema.s.name}\""
    }
  }
}

If the fully qualified name was available as an attribute, the syntax would be much simpler:

resource "snowflake_grant_privileges_to_role" "g2" {
  depends_on = [ snowflake_schema.s , snowflake_table.t]
  role_name = snowflake_role.r.name
  privileges = ["SELECT", "INSERT"]
  on_schema_object {
    all {
      object_type_plural = "TABLES"
      in_schema = snowflake_schema.s.fqn
    }
  }
}

[sfc-gh-asawicki]

Hey @monti-python. That's a valid suggestion. There is already an open issue, #2035, and a few comments on other issues (like #2165). We have identifiers rework on our roadmap (https://github.com/Snowflake-Labs/terraform-provider-snowflake/blob/main/ROADMAP.md#our-roadmap), we will consider it then.

[bjornburrell-8451]

Echoing the same sentiment as @monti-python. Having the fully qualified name available as an attribute for resources would be super helpful.

Thanks for considering this, really appreciate all of the hard work y'all are putting into the provider!

[ndnchapathi69]

Will snowflake_grant_account_role be deprecated as well? I noticed that there isn't an option/example of using snowflake_grant_privileges_to_account_role to grant role privileges to another role. What is the recommended approach for role to role access mapping via terraform?

[toni-moreno]

@sfc-gh-swinkler regarding these notes:
which of these resources should be the replacement for the snowflake_role_grants resource ? There is no deprecation message when deploying this old grant resource and neither examples on how to replace it in the existing documentation.

[sfc-gh-jcieslak]

Yeah, snowflake_role_grants is missing a deprecation message (we should add one), but it should be replaced by snowflake_grant_account_role. snowflake_role_grants can be used to grant multiple roles, but snowflake_grant_account_role can be used with for_each which will have the same effect.

[sfc-gh-swinkler]

@sfc-gh-jcieslak did a great job designing the new grant resources. It does create some confusion because there are now multiple resources serving the same purpose, but in general, I would say use the latest resources, and you should be fine. Jan spent months of work on these resources, and understands the idiosyncracies of grants better than anyone else at this point.

[ndnchapathi69]

@sfc-gh-swinkler , @sfc-gh-jcieslak - Thanks so much for the response and suggestions. I have one more question as we start to implement our initial RBAC system in which we use terraform to create roles and grant them various access to a schema. I've gotten your book "terraform in action" and I'm starting to think about how we want design our terraform. Everytime we create a schema access role, we need multiple grant statements to get that role access to a schema. This is the same grant resource about 4 times (usage on db, usage on schema, select on schema , future in schema) , as I start to think of scaling, this would become cumbersome to manage in a grants.tf file. I was thinking maybe it makes sense to define schema roles in a yaml or somewhere and then dynamically generate appropriate grant resource statements from this yaml config.

I know this is subjective, but was wondering if you had guidance/suggestions/best practices for the community. Also are their plans to upgrade the snowflake-roleout tool with these new grant resources

Cheers!

[sfc-gh-swinkler]

Thanks for buying my book, i think chapter 4 is the best one. Some of the content in later chapters is a bit outdated, but still worthwhile to skim through as I put a lot of different and interesting design patterns in there.

For your grant problem, I would recommend using a module for this purpose. The inputs for this module can then be stored as either a tf variable or as YAML config. I actually do this myself for use cases where I want to expose a clean interface to users who need self-service. Telling someone to make a PR to edit a TF variable or YAML file is much less daunting than asking them to edit TF config, in many cases.

Theres a lot of crazy things you can do with for-expressions and local values, but as long as that is contained in the module, users don't need to care.

[wesleyhillyext]

While I generally agree with cleaning up the approach to grants, I think the new terraform resources make it basically impossible to handle an important use-case for us.

For background, my team uses terraform to manage all our Snowflake infrastructure across several Snowflake accounts, and we just went through the process of upgrading to the snowflake_grant_privileges_to_account_role approach in around 15K lines of terraform code. We haven't moved to other resources like snowflake_grant_account_role yet but they appear to have the same problem.

The use case these new resources appear to miss is the ability to assert that a certain privilege is granted to a set of grantees and only those grantees. For example, if we grant USAGE on a database to roles A and B in the terraform, but in Snowflake that privilege has also been granted to role C somehow, then applying the terraform should have the property that it will revoke that privilege from role C.

With this property, auditing our Snowflake accounts to ensure that they have only the intended grants which have been reviewed and approved in the terraform code is as simple as running terraform plan on all the accounts and confirming that there are no changes to be made.

Without this property, the terraform becomes basically useless in performing such an audit of grants. Managing audits for things like SOX and SOC2 etc. are unfortunately burdensome enough as it is; I'd hate to see the Snowflake terraform provider evolve in a way which makes them even harder.

Unintentional grants do crop up over time, including through someone manually granting privileges outside of the terraform, or just in the course of performing refactoring to the terraform and moving around state as a result. We can't always rely on terraform state knowing that there was once a grant which now needs to be removed.

This is related to the messy history of the enable_multiple_grants in the older snowflake_role_grants resource, which was working or broken on and off in different provider versions. But it was intended that enable_multiple_grants = false would have this essential property of ensuring that only the listed roles had the grant.

Were the maintainers of this provider unaware of the desirability of this property? Or have you considered it at length and chosen not to address it? Is it considered too late to modify the new resources to enable this behavior?

Or could we address this use case by introducing more resource variants like snowflake_grant_accout_role_exclusive? I wish it were as simple as adding a boolean option to the new resources, but they would need to take a set of grantees instead of a just a single grantee in order for that to work.

[sfc-gh-asawicki]

Hey @wesleyhillyext. We will publish the design decisions around the grants topic soon (probably next week).

A short explanation before that would be: consider different objects, e.g. a database. If you set up database A and database B with terraform, you don't expect that it will drop database C, even if it was added manually. We want grant resources to behave the same way by default.

However, we are aware that grants are different (in many ways) and may require a bit of a different treatment. We want to add an authoritative flag (the name has not been decided yet) that will allow the grant resources to be set in this strict mode that you mentioned. It is not trivial to implement it correctly, though, e.g. because of ALL PRIVILEGES (old resources do not handle this very well). It is on our radar, but it's rather a matter of months rather than weeks.

cc: @sfc-gh-jcieslak

[wesleyhillyext]

Thanks for your informative reply @sfc-gh-asawicki . I was looking for the design document since I saw it mentioned earlier; I'll certainly keep an eye out for its publication.

Agreed; if you take the view that an individual grant to one grantee is one resource, then it would be the natural way for terraform to ignore such "resources"/(grants) created outside the current terraform stack. I'm aware that many people would prefer to treat grants in this matter (witness the introduction of enable_multiple_grants in the first place), so I'm not suggesting that exclusive/authoritative mode should be required, or even the default.

But as you say, it is useful to be able to treat grants in an authoritative mode though for those who choose to. So I'm glad to hear you are considering an authoritative flag; that sounds like it would address this use case. It also sounds similar to what I was thinking we'd have to do if this feature wasn't added, which would be to write a separate tool which parses the terraform state to collect the intended grants and compare that to what's in Snowflake.

ALL PRIVILEGES does sound like a complicating factor, as WITH GRANT OPTION has also been. If it's of any help, we don't use either. We don't use ALL PRIVILEGES because I find it's better to be explicit, especially as new privileges are added over time. It might even be fair to state that an authoritative option doesn't support the use of ALL PRIVILEGES, but you would have a better idea of other customers' use cases.

The other complicating factor are those privileges which don't appear in the terraform at all. E.g., if the terraform grants CREATE VIEW on a certain schema but never grants CREATE FUNCTION on that schema to anything, then does that mean the CREATE FUNCTION grants are managed outside of terraform, or that an authoritative mode should check that CREATE FUNCTION is granted to nothing? (The latter would be what I'm after).

Similar for grantee types which don't appear in terraform. Is the absence of any grants to database roles / users / shares for an object an indication that it should expect there to be no such grants? (Again, if we're being strict, then probably so).

We do have occasional cases where a role is created in one terraform stack but its grants are delegated to a different stack; so we might need to be able to opt-out certain roles from the authoritative treatment.

(E.g. if you have separate stacks for Dev and Prod environments, but both stacks need the ability to grant an account-level privilege like EXECUTE TASK to things in their own environment, then the workaround is to have an account-level stack create DEV_EXECUTE_TASK and PROD_EXECUTE_TASK roles and grant EXECUTE TASK just to them, then have the Prod environment stack manage the grants of the PROD_EXECUTE_TASK role, and similarly for Dev.)

[sfc-gh-asawicki]

Thanks for the elaborate answer, @wesleyhillyext. I have added it to our internal considerations regarding authoritative flag support. We did not think about the opt-out roles earlier, but we will consider them.

As you write, there are many challenges and questions to support the "strict"/"authoritative" approach correctly. At the same time, it has to be usable. We also prefer the explicit approach and not using ALL PRIVILEGES, but unfortunately, many of our users requested it.

The authoritative flag, in addition to the existing resources, is not written in stone. We are also considering an entirely new strict resource that aligns more with the use case you described. I am not ruling out having the workshops or at least wider consultations. We'll make sure to keep you posted.

[sfc-gh-jcieslak]

Hey, with the latest release (v0.88.0), we concluded the redesign of grants. Thank you all for your patience!

Grants have received much of our attention in the past few months, and they're in a much better state now. We will move now to other essential topics before the V1. You can check the summary of introduced changes and future challenges in grants_redesign_design_decisions.md.

Thank you all for the feedback and issue reports; they helped us steer the grants in the right direction. Now that all the new grants are available, we would love to hear your thoughts on using them in practice, so please share any usability concerns or missing parts.

[georgie-walker]

Hi team, thanks for all your great work on this. I have a number of questions before my org plans the work to complete the migration:

1. My org has a heavy reliance on resources that will need to be migrated to snowflake_grant_privileges_to_account_role. We are on v.0.87.2 and I noticed that this resource is still in preview. In which version is snowflake_grant_privileges_to_account_role planned be fully released, i.e. out of preview? And approximately how far is that release away?
2. snowflake_grant_account_role does not have a preview notice, is it safe to use in its current state?
3. In which version are existing grant resources planned to be fully deprecated, i.e. where they are no longer supported? And approximately how far is that release away?

Please let me know if there is a better place to post these questions.

cc @sfc-gh-asawicki @sfc-gh-jcieslak @sfc-gh-swinkler @sfc-gh-bculberson @sfc-gh-ckite

[sfc-gh-jcieslak]

Hey hey 👋
GitHub Discussion is a good place to put such questions :)

1. The preview note was added when the resources were introduced. We wanted to emphasize at the time that they're new and in case of any issues to create a GitHub issue to make the resource more stable. Right now, I think the resources were available for long enough (except snowflake_grant_ownership) to say they're pretty stable and I'm pretty sure they're covering more edge cases than the deprecated ones. That being said, despite the new grant resources being noted as "preview" we recommend using them instead of deprecated ones because they're more complete.
2. It's safe to use.
3. Deprecated resources are already not supported. We won't fix any existing or incoming issues related to the deprecated resources. That's why we always recommend using the latest resources (even despite being a "preview" resource), because you'll use the most complete resource and you'll get help through GitHub Issues in case of any errors. Soon, we're planning to post a discussion on what we're planning to do with deprecated grant resources, so stay tuned.

[georgie-walker]

Thanks for your speedy reply! Apologies, point 3 was supposed to ask when those resources would be removed, i.e. when they will no longer work. Looking forward to the discussion on those.

[sfc-gh-jcieslak]

That also will be answered by the previously mentioned discussion post we're planning to create soon.

[nybejonn]

My team is moving to these new grant resources, but I cannot for the life of me figure out how grants for procedures and functions with input arguments should work. The deprecated resource: snowflake_procedure_grant has the attribute argument_data_types that allows you to define the datatypes of the inputs as an array. Is there anything similar in the new resources?

[nybejonn]

@sfc-gh-asawicki thanks for the quick response! Seems to work for functions with actual inputs, but when I tried with a procedure that has no input arguments I got the error: Error: error granting privileges to account role: 090208 (42601): Argument types of function 'FUNCTION_WITH_NO_INPUTS' must be specified.

[sfc-gh-asawicki]

Hey @nybejonn. Did you use the empty parentheses? Can you check what statement is being run (by enabling TF_LOG=DEBUG environment variable).

[nybejonn]

So in the logs I can see that Terraform is doing the call like so: GRANT ALL PRIVILEGES ON PROCEDURE "MY_DB"."MY_SCHEMA"."MY_FUNCTION_NAME" TO ROLE "FUNCTION_USER_ROLE"
so without the parentheses.

But my reference object does have the parentheses defined like this:
on_schema_object {
object_type = "PROCEDURE"
object_name = "\"${var.MY_DB}\".\"MY_SCHEMA\".${snowflake_procedure.my_function.name}()"
}

Also, this worked just fine:
on_schema_object {
object_type = "PROCEDURE"
object_name = "\"${var.MY_DB}\".\"MY_SCHEMA\".${snowflake_procedure.my_other_function.name}(VARCHAR)"
}

[sfc-gh-asawicki]

Hey, the problem is with the identifier parsing function, I don't see any clever workaround currently, so it's best to wait for the rework mentioned above.

[nybejonn]

Ok thanks for your help! We'll wait for an update.