[Feature]: Support snowflake_user TYPE property #2951

mogren · 2024-07-19T18:33:12Z

Use Cases or Problem Statement

The existing snowflake_user resource does not have the TYPE property. This is a big limitation for us, since it prevents us from creating SERVICE users, which is a great security feature.

We are currently getting a number of Critical security warnings in Trust Center because of this issue.

Object type(s)

resource:user

Proposal

Add a type property that accepts PERSON | SERVICE | LEGACY_SERVICE | NULL

How much impact is this issue causing?

Medium

Additional Information

Commented on a related PR here:

#2947 (comment)

Would you like to implement a fix?

Yeah, I'll take it 😎

The text was updated successfully, but these errors were encountered:

sfc-gh-asawicki · 2024-07-22T09:42:46Z

Hey, we will handle this as a part of user redesign (that is currently happening).

Most probably, we will split the resource into three different ones (snowflake_user for people; snowflake_service_user and snowflake_legacy_service_user for the two others).

Redesigned snowflake_user may be ready for the next release but snowflake_service_user and snowflake_legacy_service_user will most probably have to wait a version.

mogren · 2024-07-24T13:14:02Z

Awesome, thanks for the update @sfc-gh-asawicki !

mogren · 2024-09-18T20:49:14Z

@sfc-gh-asawicki Hi Artur, any update on this?

sfc-gh-jcieslak · 2024-09-19T07:43:57Z

Hey @mogren 👋
What exactly would you like to know? If you're asking about the user rework, it was released as part of v0.95.0. The rest of the user resources (service and legacy_service) have to still wait a little (after today's release, a version or two). Artur is on vacation right now, but I'm guessing that will be one of his priorities after he comes back next week.

MrStemo · 2024-09-19T12:23:25Z

Hi,

Following the Snowflake security update email we received yesterday we now have a deadline to update users to 'service users' by 30th September.

Is there any chance this is available in the TF by then?

Thanks

sfc-gh-jcieslak · 2024-09-19T14:08:15Z

Hey 👋
As far as I know, starting in October, the only thing that will be enforced is multi-factor authentication (MFA), not service users. Nevertheless, the timeline of missing user types will be discussed on Monday. I'll let you know the outcome of those discussions.

mogren · 2024-09-19T14:09:58Z

Thanks @sfc-gh-jcieslak, yes, I was mainly wonderinga bout the service and legacy_service users. I'll continue to keep an eye on this ticket.

simonepm · 2024-09-23T09:02:13Z

@sfc-gh-jcieslak I noticed an unexpected behavior with 0.96.0 and user_type.

snowflake_user gets created by default as NULL (PERSON), if we set it afterward to SERVICE, on next deploy the user is forced to be replaced:

user_type = "SERVICE" # forces replacement -> (known after apply) # forces replacement

On the other side, if we try to directly pass SERVICE at snowflake_user creation we receive:

Can't configure a value for "user_type": its value will be decided automatically based on the result of applying this configuration.

So we have an egg-chicken problem, I think as soon as the new users types are not ready in Terraform provider the user_type property should be editable.

Is there a way to make snowflake_user create user with type SERVICE directly in this particular phase?

At the moment I am doing:

lifecycle {{ ignore_changes = [user_type] }}

sfc-gh-jcieslak · 2024-09-23T09:46:01Z

Hey @simonepm
As @sfc-gh-asawicki mentioned above, additional user types will be separate resources. snowflake_user represents the regular (PERSON) user type. Additional resources that will give you ability to manage other user types will be added in next versions of the provider (right now only PERSON is available). The user_type field in the snowflake_user resource is a computed value, meaning it is only settable by the provider (it gets its value from Snowflake). Currently, this field will apply ForceNew logic (drop and create) whenever user_type is equal to anything else than PERSON. If you changed the user type to SERVICE or LEGACY_SERVICE in the worksheet and want to manage this user with snowflake_user, it may work, but we don't guarantee it will because different types of users may act differently in some cases. Setting lifecycle {{ ignore_changes = [user_type] }} is only a workaround to manage "non-person" users with snowflake_user.

jwilson232 · 2024-09-24T10:12:38Z

Hey 👋 As far as I know, starting in October, the only thing that will be enforced is multi-factor authentication (MFA), not service users. Nevertheless, the timeline of missing user types will be discussed on Monday. I'll let you know the outcome of those discussions.

Hey any update on this?

sfc-gh-asawicki · 2024-09-24T15:44:48Z

Hey all.

I will focus on service and legacy service users this week, so they should be ready for next week's release.

csp33 · 2024-10-03T10:53:32Z

hi @sfc-gh-asawicki

Any news regarding this issue?
Thanks! 😃

sfc-gh-asawicki · 2024-10-03T11:51:52Z

Hey @csp33, I was on sick leave, just got back to work, and this is my current priority. I expect to have it early next week.

Introduce `snowflake_service_user` and `snowflake_legacy_service_user` resources: - Add new resources (almost the same schema and the same limitations as `snowflake_user` resource - read below) - Adjust datasource and add `type` to the `describe_output` - Adjust SDK: handling types - Add SDK integration tests to validate and document the Snowflake behavior of handling user types (create, alter set, alter unset, and parameters) - Fix `TestAcc_User_issue2970` test - Add migration guide - Generate models and assertions for the new resources - Fix sweepers References: #2951 ##### Implementation considerations Users of different types differ in Snowflake just slightly - a few fields are restricted from SERVICE and LEGACY_SERVICE type users. We decided to split Snowflake resources into multiple resources on our route to V1, to simplify the logic and usage (in this case, not to handle the type changes which are followed by attributes being hidden/revealed). That led to three choices for the implementation, to reuse the existing resource: - copy-paste `snowflake_user` resource - parameterized handling methods of `snowflake_user` resource with the user type - enrich the helper methods with the knowledge of the schema (i.e. to change the logic of setting a field to always check first if the attribute exists in the given schema) Ultimately, the second option was picked for the current implementation. More details of pros and cons of each solution are presented in points below. ###### copy-paste Pros: - Fastest implementation - We plan to ultimately generate the resources, so at the end the implementation would be close to duplicated resources Cons: - Need to alter the logic in three different places - Separate implementation of resources would require separate complete set of tests ###### parameterized handling methods Pros: - user object handled in "one" place - implementation reused, so only smoke acceptance tests are justified Cons: - more complex logic in user resource, spread over multiple handling methods ###### enrich the helper methods Pros: - user resource implementation could stay the same in helper methods (because the checks would be delegated to helper methods) - solution that can be reused in more resources - only smoke tests would be justified Cons: - SDKv2 does not allow to fetch the schema in context of helper methods without exposing unexported fields - "unsafe" solution potentially used in the majority of resources (because helper methods should be reused more and more)

sfc-gh-asawicki · 2024-10-11T12:20:06Z

Hey, we have just released v0.97.0 version of the provider (release notes, migration guide) containing the new user types in new separate resources snowflake_service_user and snowflake_legacy_service_user.

simonepm · 2024-10-11T13:29:59Z

Thanks, I tested and 0.97.0 new users resources suffers of this bug as well the old snowflake_user resource:

#3125

sfc-gh-asawicki · 2024-10-11T15:30:35Z

Hey @simonepm, this is expected.

nidal123 · 2024-10-16T16:28:26Z

I think the new snowflake_service_user resource is not setting the user type.
For example here's my code:
resource "snowflake_service_user" "nidal_testing_service_user" {
provider = snowflake.useradmin
name = "nidal_testing_service_user"
}

And here's the resulting created user:

Shouldn't the user have type="SERVICE"? Sorry if I am missing something obvious here.

sfc-gh-asawicki · 2024-10-16T19:20:54Z

Hey @nidal123.

What role do you use to run the SHOW command you have pasted? According to the Snowflake docs you need to have OWNERSHIP on the given user or the MANAGE GRANTS privilege on the account. Without them, it's possible you don't see the type.
Please run your config with TF_LOG=DEBUG environment variable; you should see a statement similar to CREATE USER "nidal_testing_service_user" TYPE = SERVICE (this is the output I get running a similar config now) which should confirm that the service user with proper type is being created.

sfc-gh-asawicki · 2024-10-30T02:30:24Z

Closing as completed. Please create a new issue if you encounter problems with the new user resources.

mogren added the feature-request Used to mark issues with provider's missing functionalities label Jul 19, 2024

sfc-gh-asawicki mentioned this issue Oct 8, 2024

feat: Add service user and legacy service user resources #3119

Merged

sfc-gh-asawicki closed this as completed Oct 30, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[Feature]: Support snowflake_user TYPE property #2951

[Feature]: Support snowflake_user TYPE property #2951

mogren commented Jul 19, 2024

sfc-gh-asawicki commented Jul 22, 2024

mogren commented Jul 24, 2024

mogren commented Sep 18, 2024

sfc-gh-jcieslak commented Sep 19, 2024

MrStemo commented Sep 19, 2024

sfc-gh-jcieslak commented Sep 19, 2024

mogren commented Sep 19, 2024

simonepm commented Sep 23, 2024 •

edited

Loading

sfc-gh-jcieslak commented Sep 23, 2024 •

edited

Loading

jwilson232 commented Sep 24, 2024

sfc-gh-asawicki commented Sep 24, 2024

csp33 commented Oct 3, 2024

sfc-gh-asawicki commented Oct 3, 2024

sfc-gh-asawicki commented Oct 11, 2024

simonepm commented Oct 11, 2024 •

edited

Loading

sfc-gh-asawicki commented Oct 11, 2024

nidal123 commented Oct 16, 2024

sfc-gh-asawicki commented Oct 16, 2024

sfc-gh-asawicki commented Oct 30, 2024

[Feature]: Support snowflake_user TYPE property #2951

[Feature]: Support snowflake_user TYPE property #2951

Comments

mogren commented Jul 19, 2024

Use Cases or Problem Statement

Category

Object type(s)

Proposal

How much impact is this issue causing?

Additional Information

Would you like to implement a fix?

sfc-gh-asawicki commented Jul 22, 2024

mogren commented Jul 24, 2024

mogren commented Sep 18, 2024

sfc-gh-jcieslak commented Sep 19, 2024

MrStemo commented Sep 19, 2024

sfc-gh-jcieslak commented Sep 19, 2024

mogren commented Sep 19, 2024

simonepm commented Sep 23, 2024 • edited Loading

sfc-gh-jcieslak commented Sep 23, 2024 • edited Loading

jwilson232 commented Sep 24, 2024

sfc-gh-asawicki commented Sep 24, 2024

csp33 commented Oct 3, 2024

sfc-gh-asawicki commented Oct 3, 2024

sfc-gh-asawicki commented Oct 11, 2024

simonepm commented Oct 11, 2024 • edited Loading

sfc-gh-asawicki commented Oct 11, 2024

nidal123 commented Oct 16, 2024

sfc-gh-asawicki commented Oct 16, 2024

sfc-gh-asawicki commented Oct 30, 2024

simonepm commented Sep 23, 2024 •

edited

Loading

sfc-gh-jcieslak commented Sep 23, 2024 •

edited

Loading

simonepm commented Oct 11, 2024 •

edited

Loading