More powerful permissions drift detection and correction

[toadjaune]

Company Name

No response

Use Cases or Problem Statement

Hi,

While the recent addition of the strict_privilege_management flag is a very nice improvement, I do think our ability to declaratively manage permissions in an authoritative way is still quite limited.

Basically, this new flag allows us to control authoritatively the set of permissions for a given (role, resource) couple. It will detect and correct missing or extraneous permissions for this specific pair, but nothing more.

Example options that may be useful, depending on the context :

1. for a given (resource, permission), authoritative control over the roles having it
2. for a given resource, authoritative control over the entire set of permissions (all roles, all permissions)
3. for a given role, authoritative control over its entire set of permissions (all resource, all permissions)

Then, some harder stuff could be nice too, although it would certainly make for a more challenging configuration DSL :

4. 1,2,3 but for a set of resources of a given type (including the specific case of the set being "ALL")
5. full authoritative policy on a given account and/or database, etc

A very good example of different levels of permission management, in my opinion, is the GCP IAM, which offers 4 different resources to manage the same IAM permissions, but covering different scopes. Quoting their documentation :

• google_project_iam_policy: Authoritative. Sets the IAM policy for the project and replaces any existing policy already attached.
• google_project_iam_binding: Authoritative for a given role. Updates the IAM policy to grant a role to a list of members. Other roles within the IAM policy for the project are preserved.
• google_project_iam_member: Non-authoritative. Updates the IAM policy to grant a role to a new member. Other members for the role for the project are preserved.
• google_project_iam_audit_config: Authoritative for a given service. Updates the IAM policy to enable audit logging for the given service.

Of course, I do understand that beyond the discussions about terraform resource organization and permissions specification DSL ; there are limitations coming from what the Snowflake API permits to do in an efficient manner or not, and I have no expectation for this topic to be a quick win.
There's a massive amount of design to do here, probably along with some API and back-end evolutions.

Category

category:grants

Object type(s)

resource:grant_privileges_to_account_role

Proposal

No response

Additional Information

This is a follow-up of #3973

Would you like to implement a fix?

• Yeah, I'll take it 😎

[sfc-gh-jcieslak]

Hey @toadjaune 👋
Thank you for your feedback! Most of the information regarding our analysis and implementation of strict_privilege_management should already be described in https://registry.terraform.io/providers/snowflakedb/snowflake/latest/docs/guides/strict_privilege_management, but some insights may be missing.

During the initial analysis, we considered other angles of restricting grants as you suggested (again, thank you for linking those sources and giving more insight into the topic; It was really helpful), but because we wanted to utilize existing stable resources, we were limited in the changes we could introduce. The strict_privilege_management flag was a step toward better grant management within the provider, and we already have plans to expand this experience, but we also have other topics to push. We update our roadmap regularly, so I recommend following it.

If you want to raise the priority of this request and you are an enterprise customer, you can also work with your Snowflake account manager to file a feature gap.

[toadjaune]

Hi,

I've seen this document, and agree that the introduction of strict_privilege_management was a nice improvement, going in the right direction.
I also understand that implementing efficiently any of the proposals here would likely require API updates, so, we're way out of quickwin territory ^^

I thought it made sense to open this feature request, though, so that the topic can at least be considered, and/or to expand the API discussions whenever you start working again on the general permission management topic :)