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

Schema roles are created with Database Onwer ruleset #178

Closed
kokorin opened this issue Feb 5, 2025 · 2 comments
Closed

Schema roles are created with Database Onwer ruleset #178

kokorin opened this issue Feb 5, 2025 · 2 comments

Comments

@kokorin
Copy link

kokorin commented Feb 5, 2025

Describe the bug
We have DEV DB where every developer may create personal schemas to work on DBT-based project. Schema names start with developer name. So we used Database Owner ruleset for it with is_sandbox: true flag for that Database.

The same database contains schemas and tables created by DEV CI runs, some of those tables (not all) should be granted to specific business roles. So, we added schema and tables in it to SnowDDL-based project (otherwise Tech role validation fails). Additionally granted Tech role privileges on mentioned tables and schema.

Despite Database Owner ruleset, SnowDDL creates schema-specific owner/read/write roles (like ...__READ__S_ROLE).

Expected behavior
Only database read/write/owner roles are created without creating schema roles.

Attach log
N/A

Attach YAML config (if applicable)
N/A

@littleK0i
Copy link
Owner

littleK0i commented Feb 5, 2025

It is by design. Currently it is the only way to make such schemas work with schema_read and schema_write parameters.

It is even more interesting internally. Since future grants on schema level override future grants on database level, such schemas require two sets of future grants: one set for schema-level and another set for database-level.

Naturally, "unknown" schemas are managed on database-level only and cannot be granted via schema_read / schema_write.

In general, it should not cause any issues or noticeable overhead.

@kokorin
Copy link
Author

kokorin commented Feb 5, 2025

I think it can be converted to discussion then, thank you!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants