Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Failed to grant privileges to COMPUTE POOL using 'snowflake_grant_privileges_to_account_role' resource #2717

Closed
scizorman opened this issue Apr 16, 2024 · 7 comments
Assignees
Labels
bug Used to mark issues with provider's incorrect behavior category:grants resource:grant_privileges_to_account_role Issue connected to the snowflake_grant_privileges_to_account_role resource

Comments

@scizorman
Copy link

scizorman commented Apr 16, 2024

Terraform CLI and Provider Versions

  • Terraform: 1.8.0
  • Snowflake Provider: 0.88.0

Terraform Configuration

resource "snowflake_role" "dev_zucks_dashboard_pool_usage_access_role" {
  provider = snowflake.useradmin

  name = "DEV_ZUCKS_MANAGEMENT_POOL_USAGE"
}

resource "snowflake_grant_privileges_to_account_role" "grant_usage_privilege_to_this_usage_role" {
  provider = snowflake.securityadmin

  account_role_name = snowflake_role.dev_zucks_dashboard_pool_usage_access_role.name
  privileges        = ["USAGE"]

  on_account_object {
    object_type = "COMPUTE POOL"
    object_name = "DEV_ZUCKS_MANAGEMENT_POOL"
  }
}

Expected Behavior

The following SQL is executed and the grant of USAGE privileges to COMPUTE POOL succeeds.

GRANT USAGE ON COMPUTE POOL DEV_ZUCKS_MANAGEMENT_POOL TO ROLE DEV_ZUCKS_MANAGEMENT_POOL_USAGE;

Actual Behavior

It appears that before executing the GRANT statement, an attempt is being made to check the existing GRANTS by running SHOW GRANTS ON .... However, the statement SHOW GRANTS ON COMPUTE POOL <object_name> does not exist in Snowflake.

As a result, the query that actually gets executed is SHOW GRANTS ON, which leads to a syntax error, causing the terraform apply to fail.

The console log is below.

...
Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with the following symbols:
  + create

Terraform will perform the following actions:

  # snowflake_grant_privileges_to_account_role.grant_usage_privilege_to_this_usage_role will be created
  + resource "snowflake_grant_privileges_to_account_role" "grant_usage_privilege_to_this_usage_role" {
      + account_role_name = "DEV_ZUCKS_MANAGEMENT_POOL_USAGE"
      + all_privileges    = false
      + always_apply      = false
      + id                = (known after apply)
      + on_account        = false
      + privileges        = [
          + "USAGE",
        ]
      + with_grant_option = false

      + on_account_object {
          + object_name = "DEV_ZUCKS_MANAGEMENT_POOL"
          + object_type = "COMPUTE POOL"
        }
    }

  # snowflake_role.dev_zucks_dashboard_pool_usage_access_role will be created
  + resource "snowflake_role" "dev_zucks_dashboard_pool_usage_access_role" {
      + id   = (known after apply)
      + name = "DEV_ZUCKS_MANAGEMENT_POOL_USAGE"
    }

Plan: 2 to add, 0 to change, 0 to destroy.

Do you want to perform these actions?
  Terraform will perform the actions described above.
  Only 'yes' will be accepted to approve.

  Enter a value: yes

snowflake_role.dev_zucks_dashboard_pool_usage_access_role: Creating...
snowflake_role.dev_zucks_dashboard_pool_usage_access_role: Creation complete after 0s [id=DEV_ZUCKS_MANAGEMENT_POOL_USAGE]
snowflake_grant_privileges_to_account_role.grant_usage_privilege_to_this_usage_role: Creating...

│ Error: Failed to retrieve grants

│   with snowflake_grant_privileges_to_account_role.grant_usage_privilege_to_this_usage_role,
│   on compute_pool.tf line 7, in resource "snowflake_grant_privileges_to_account_role" "grant_usage_privilege_to_this_usage_role":
│    7: resource "snowflake_grant_privileges_to_account_role" "grant_usage_privilege_to_this_usage_role" {

│ Id: "DEV_ZUCKS_MANAGEMENT_POOL_USAGE"|false|false|USAGE|OnAccountObject||
│ Error: 001003 (42000): SQL compilation error:
│ syntax error line 1 at position 14 unexpected '<EOF>'.

Steps to Reproduce

  1. terraform apply: The error described in Actual behaviors occurs.
  2. terraform plan: The error described below occurs. And the Terraform state is broken.
...
Planning failed. Terraform encountered an error while generating this plan.


│ Error: Failed to retrieve grants

│   with snowflake_grant_privileges_to_account_role.grant_usage_privilege_to_this_usage_role,
│   on compute_pool.tf line 7, in resource "snowflake_grant_privileges_to_account_role" "grant_usage_privilege_to_this_usage_role":
│    7: resource "snowflake_grant_privileges_to_account_role" "grant_usage_privilege_to_this_usage_role" {

│ Id: "DEV_ZUCKS_MANAGEMENT_POOL_USAGE"|false|false|USAGE|OnAccountObject||
│ Error: 001003 (42000): SQL compilation error:
│ syntax error line 1 at position 14 unexpected '<EOF>'.

How much impact is this issue causing?

Medium

Logs

No response

Additional Information

No response

@scizorman scizorman added the bug Used to mark issues with provider's incorrect behavior label Apr 16, 2024
@sfc-gh-asawicki
Copy link
Collaborator

Hey @scizorman. Thanks for reporting the issue.

This looks like a bug/missing feature in Snowflake.

From the provider side, we have to be able to run read (SHOW GRANTS ON) to be able to calculate the difference and plan the terraform actions accordingly. We will check if the COMPUTE POOL grants are visible in any other SHOW GRANTS commands. If so, we will consider introducing a workaround. We will also raise this issue on Snowflake side but it would help if you could file this as a bug too (i.e. not being able to run SHOW GRANTS ON COMPUTE POOL <object>).

@sfc-gh-asawicki
Copy link
Collaborator

cc: @sfc-gh-jcieslak

@sfc-gh-asawicki sfc-gh-asawicki self-assigned this Apr 17, 2024
@scizorman
Copy link
Author

scizorman commented Apr 17, 2024

@sfc-gh-asawicki
Thanks for your reply.

We will also raise this issue on Snowflake side but it would help if you could file this as a bug too (i.e. not being able to run SHOW GRANTS ON COMPUTE POOL <object>).

I submitted a request to the Snowflake support case, asking them to enable the execution of SHOW GRANTS ON COMPUTE POOL <object_name>. I have also informed them about this GitHub issue.

@sfc-gh-jcieslak sfc-gh-jcieslak added resource:grant_privileges_to_account_role Issue connected to the snowflake_grant_privileges_to_account_role resource category:grants labels May 20, 2024
@awilliamsOM1
Copy link

awilliamsOM1 commented Nov 5, 2024

I think this is a problem with the resource id stored in the terraform provider. I think the compute pool name is not getting added properly to the terraform resource id. In the above example's error message the id of the snowflake_grant_privileges_to_account_role is

│ Id: "DEV_ZUCKS_MANAGEMENT_POOL_USAGE"|false|false|USAGE|OnAccountObject||

The compute pool name seems to be missing from the id. I would expect the snowflake_grant_privileges_to_account_role id to be "DEV_ZUCKS_MANAGEMENT_POOL_USAGE"|false|false|USAGE|OnAccountObject|DEV_ZUCKS_MANAGEMENT_POOL|

I think the provider is failing to create a valid terraform id in state for the ``snowflake_grant_privileges_to_account_rolewhen the account object type isCOMPUTE POOL`.

This looks to be a provider issue to me instead of a snowflake issue.

SHOW GRANTS ON COMPUTE POOL <object> is a valid snowflake command that I have confirmed.

sfc-gh-asawicki added a commit that referenced this issue Nov 7, 2024
sfc-gh-asawicki added a commit that referenced this issue Nov 8, 2024
Apply various fixes:
- Fix handling compute pool privileges (#2717)
- Fail to reproduce the problem with password policy user attachment
(#3005)
- Adapt user to BCR Bundle 2024_08 (#3125)
- Loosen identifier validations - parentheses (#3127) - check below
- Prove MANAGE SHARE TARGET works correctly (#3153)

On the identifier validation topic:
ParseIdentifierString should generally allow parentheses. It should
validate them for the identifiers for functions, procedures, etc.
Because of that:
- this validation was removed
- method usages were analyzed to check what consequences it has
throughout the provider
  - DecodeSnowflakeAccountIdentifier - OK, account level identifier
  - DecodeSnowflakeParameterID
- buildOptsForGrantsOn (grants datasource) - NOK, had to fix the logic
- ContainsIdentifierIgnoringQuotes - OK, transitively used only in
network policies
    - TestDecodeSnowflakeParameterID - OK
    - IsValidIdentifier - OK, used for other identifier types
- pkg/resource - OK, used in streams, table constraints and tag masking
policy associations
  - suppressIdentifierQuoting
- used in non-grant resources with non-argument identifier types - OK
- used in grant resources - OK, the validation will be relaxed for now,
diff suppression won't work correctly for the identifiers with
arguments, will be addressed with functions/procedures rework
(multi-field validation could be handled for such cases, issue added;
references:
hashicorp/terraform-plugin-sdk#354,
hashicorp/terraform-plugin-sdk#233)
- suppressIdentifierQuotingPartiallyQualifiedName - as above; currently
used only for streams
- parseIdentifier - used by other identifier types (type constraints
added)
- ParseObjectIdentifierString - OK, used for other identifier types
(ParseSchemaObjectIdentifierWithArguments is dedicated for identifier
with arguments)
- ParseSchemaObjectIdentifierWithArguments - OK, we split the input
string on first opening paren (so there are no other opening parens
there)
- Test_ParseIdentifierString - tests adjusted for the removed validation

Others:
- Remove unused privileges.go file
- Fix preview resources list for V1

References:
-
#2717
-
#3005
-
#3125
-
#3127
-
#3153
sfc-gh-jmichalak pushed a commit that referenced this issue Nov 8, 2024
##
[0.98.0](v0.97.0...v0.98.0)
(2024-11-08)

Feature scope readiness for V1:
[link](/~https://github.com/Snowflake-Labs/terraform-provider-snowflake/blob/main/v1-preparations/ESSENTIAL_GA_OBJECTS.MD)
([Roadmap
reference](/~https://github.com/Snowflake-Labs/terraform-provider-snowflake/blob/main/ROADMAP.md#wrap-up-the-functional-scope)).
:exclamation: Migration guide: [v0.97.0 ->
v0.98.0](/~https://github.com/Snowflake-Labs/terraform-provider-snowflake/blob/main/MIGRATION_GUIDE.md#v0970--v0980)

### 🎉 What's new
- New resources:
- authentication_policy
([#3098](#3098)),
references
[#2880](#2880)
- external_volume
([#3106](#3106)),
partially references
[#2980](#2980)
- stream_on_directory_table
([#3129](#3129))
- stream_on_view
([#3150](#3150))
- primary_connection, secondary_connection
([#3162](#3162))
- secret_with_basic_authentication, secret_with_generic_string,
secret_with_oauth_authorization_code_grant,
secret_with_oauth_client_credentials
([#3110](#3110)),
([#3141](#3141))
- New data sources:
- connections
([#3155](#3155)),
([#3173](#3173))
- secrets
([#3131](#3131))
- Reworked:
- provider configuration hierarchy
([#3166](#3166)),
references
[#1881](#1881),
[#2145](#2145),
[#2925](#2925),
[#2983](#2983),
[#3104](#3104)
- provider configuration fields
([#3152](#3152))
streams data source
([#3151](#3151))
- SDK upgrades:
- Upgrade tag SDK
([#3126](#3126))
- Recreate streams when they are stale
([#3129](#3129))
### 🔧  Misc
- Add object renaming research summary
([#3172](#3172))
- Test support for object renaming
([#3130](#3130)),
([#3147](#3147)),
([#3154](#3154))
- Add tests to issue
[#3117](#3117)
([#3133](#3133))
- New roadmap entry
([#3158](#3158))
- Test more authentication methods
([#3178](#3178))
- Minor fixes
([#3174](#3174))
### 🐛  Bug fixes
- Apply various fixes
([#3176](#3176)),
this addresses BCR 2024_08, references
[#2717](#2717),
[#3005](#3005),
[#3125](#3125),
[#3127](#3127),
[#3153](#3153)
- Connection and secret data sources tests
([#3177](#3177))
- Fix grant import docs
([#3183](#3183)),
resolves
[#3179](/~https://github.com/Snowflake-Labs/terraform-provider-snowflake/discussions/3179)
- Fix user resource import
([#3181](#3181))
- Handle external type changes in stream resources
([#3164](#3164))
- Do not use OR REPLACE on initial creation in resources with
copy_grants
([#3129](#3129))
- Address issue
[#2201](#2201)
by introducing new stream resources

Co-authored-by: snowflake-release-please[bot] <105954990+snowflake-release-please[bot]@users.noreply.github.com>
@sfc-gh-asawicki
Copy link
Collaborator

Hey @awilliamsOM1 @scizorman. We've released a new v0.98.0 version (release, migration guide) containing the fix for the COMPUTE POOL grants. Please check if this solves the problem for you.

@scizorman
Copy link
Author

@sfc-gh-asawicki
Thank you for the heads-up on v0.98.0. I've tested it, and I can confirm that the snowflake_grant_privileges_to_account_role operation is now working successfully with COMPUTE POOL grants. The fix is working as expected.

terraform {
  required_version = "1.9.8"

  required_providers {
    snowflake = {
      source  = "Snowflake-Labs/snowflake"
      version = "0.98.0"
    }
  }
}

provider "snowflake" {}

provider "snowflake" {
  alias = "accountadmin"

  role = "ACCOUNTADMIN"
}

provider "snowflake" {
  alias = "securityadmin"

  role = "SECURITYADMIN"
}

provider "snowflake" {
  alias = "useradmin"

  role = "USERADMIN"
}

resource "snowflake_unsafe_execute" "test_compute_pool" {
  provider = snowflake.accountadmin

  execute = <<SQL
CREATE COMPUTE POOL TEST_POOL
  INSTANCE_FAMILY = CPU_X64_XS
  MIN_NODES = 1
  MAX_NODES = 1
  INITIALLY_SUSPENDED = TRUE
  AUTO_SUSPEND_SECS = 3600
SQL
  revert  = "DROP COMPUTE POOL TEST_POOL"
}

resource "snowflake_account_role" "test_compute_pool_usage_access_role" {
  provider = snowflake.useradmin

  name    = "TEST_POOL_USAGE"
  comment = "Access role that has USAGE privilege on the compute pool TEST_POOL"
}

resource "snowflake_grant_privileges_to_account_role" "grant_usage_privilege_to_test_compute_pool_usage_access_role" {
  depends_on = [snowflake_unsafe_execute.test_compute_pool]
  provider   = snowflake.securityadmin

  account_role_name = snowflake_account_role.test_compute_pool_usage_access_role.name
  privileges        = ["USAGE"]

  on_account_object {
    object_type = "COMPUTE POOL"
    object_name = "TEST_POOL"
  }
}
...

Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with the following symbols:
  + create

Terraform will perform the following actions:

  # snowflake_account_role.test_compute_pool_usage_access_role will be created
  + resource "snowflake_account_role" "test_compute_pool_usage_access_role" {
      + comment              = "Access role that has USAGE privilege on the compute pool TEST_POOL"
      + fully_qualified_name = (known after apply)
      + id                   = (known after apply)
      + name                 = "TEST_POOL_USAGE"
      + show_output          = (known after apply)
    }

  # snowflake_grant_privileges_to_account_role.grant_usage_privilege_to_test_compute_pool_usage_access_role will be created
  + resource "snowflake_grant_privileges_to_account_role" "grant_usage_privilege_to_test_compute_pool_usage_access_role" {
      + account_role_name = "TEST_POOL_USAGE"
      + all_privileges    = false
      + always_apply      = false
      + id                = (known after apply)
      + on_account        = false
      + privileges        = [
          + "USAGE",
        ]
      + with_grant_option = false

      + on_account_object {
          + object_name = "TEST_POOL"
          + object_type = "COMPUTE POOL"
        }
    }

  # snowflake_unsafe_execute.test_compute_pool will be created
  + resource "snowflake_unsafe_execute" "test_compute_pool" {
      + execute       = <<-EOT
            CREATE COMPUTE POOL TEST_POOL
              INSTANCE_FAMILY = CPU_X64_XS
              MIN_NODES = 1
              MAX_NODES = 1
              INITIALLY_SUSPENDED = TRUE
              AUTO_SUSPEND_SECS = 3600
        EOT
      + id            = (known after apply)
      + query_results = (known after apply)
      + revert        = "DROP COMPUTE POOL TEST_POOL"
    }

Plan: 3 to add, 0 to change, 0 to destroy.

Do you want to perform these actions?
  Terraform will perform the actions described above.
  Only 'yes' will be accepted to approve.

  Enter a value: yes

snowflake_account_role.test_compute_pool_usage_access_role: Creating...
snowflake_account_role.test_compute_pool_usage_access_role: Creation complete after 0s [id=TEST_POOL_USAGE]
snowflake_unsafe_execute.test_compute_pool: Creating...
snowflake_unsafe_execute.test_compute_pool: Creation complete after 0s [id=5707da03-5296-3ce8-7c79-6c6292b0f719]
snowflake_grant_privileges_to_account_role.grant_usage_privilege_to_test_compute_pool_usage_access_role: Creating...
snowflake_grant_privileges_to_account_role.grant_usage_privilege_to_test_compute_pool_usage_access_role: Creation complete after 0s [id="TEST_POOL_USAGE"|false|false|USAGE|OnAccountObject|COMPUTE POOL|"TEST_POOL"]

Apply complete! Resources: 3 added, 0 changed, 0 destroyed.

@sfc-gh-asawicki
Copy link
Collaborator

Glad to hear that @scizorman! I will close the issue then.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Used to mark issues with provider's incorrect behavior category:grants resource:grant_privileges_to_account_role Issue connected to the snowflake_grant_privileges_to_account_role resource
Projects
None yet
Development

No branches or pull requests

4 participants