Has anyone implemented a process whereby a user can submit a request for a role and that role will, after approval, be granted to that user?
So something like user fills out request form, once submitted an email is sent for approval, once approved a process is kicked off to run the grant statement and email the user that they have been granted a role.
In addition I would want that transaction logged for auditing purposes.
You could have your list of users/roles/grants on a version controlled file - and use commits to that file as a trigger to change Snowflake's configuration.
That's basically what tools like Terraform and Permifrost do.
See this discussion from dbt users:
https://discourse.getdbt.com/t/how-do-you-manage-snowflake-privileges/1397/4
This is a guide for Terraform on Snowflake:
https://guides.snowflake.com/guide/terraforming_snowflake/index.html
Meanwhile Permifrost:
Usage: permifrost run [OPTIONS] SPEC
Grant the permissions provided in the provided specification file for
specific users and roles
https://gitlab.com/gitlab-data/permifrost/
Related
I just set up my snowflake instance to use google auth. I can log in with my google account, query tables, create roles, etc... Today I ran into an issue (two of them actually).
I run this script
SET ROLE ACCOUNTADMIN;
CREATE WAREHOUSE IF NOT EXISTS joe;
When I am logged in with my Google Account, I get the error message:
SQL access control error: Insufficient privileges to operate on account 'XXX99999'
When I am logging in with my Snowflake native account, it works. Both accounts have the ACCOUNTADMIN role and are using it.
This is all in the classic interface. When trying to switch over to Snowsight, my google account cannot login in. I click the [Authenticate with Google] and the screen refreshes, no error, but not now the button is disabled.
For the first error, the reason is that the user does not have any roles that has the privileges on the account where the operation is being done. To overcome that you need to assign the right set of roles to the user coming from Google IDP.
Please check the following documentation which details the levels for each of the database objects that requires privileges: https://docs.snowflake.com/en/sql-reference/sql/grant-privilege.html#syntax
For the second issue, which button is disabled "Snowsight" which is listed from Classic UI?
Please use the below scripts to create warehouse. You need to use role instead of set role.
use ROLE ACCOUNTADMIN; //To use accountadmin role
CREATE WAREHOUSE IF NOT EXISTS joe_wh; //to creare warehouse
To use SSO based login with Snowsight, Please migrate to advanced SAML as per
https://docs.snowflake.com/en/user-guide/admin-security-fed-auth-advanced.html#migrating-to-a-saml2-security-integration
I have a Snowpipe created by user A. I would then like a separate user B to check its status using the Snowflake rest API endpoint /insertReport.
User A is an ACCOUNTADMIN
User A created the Snowpipe.
User A ran the following for user B's default role:
GRANT ALL ON PIPE <my pipe> TO ROLE USER_B_ROLE;
GRANT ALL ON FUTURE PIPES IN DATABASE <my db> TO ROLE USER_B_ROLE;
GRANT MONITOR ON DATABASE <my db> TO ROLE USER_B_ROLE;
GRANT USAGE ON DATABASE <my db> TO ROLE USER_B_ROLE;
GRANT MONITOR ON SCHEMA <my schema> TO ROLE USER_B_ROLE;
GRANT USAGE ON SCHEMA <my schema> TO ROLE USER_B_ROLE;
I assumed role USER_B_ROLE (I don't have direct access to log in as User B) and can run the following commands and see output as expected:
USE ROLE USER_B_ROLE;
SELECT CURRENT_ROLE();
-- USER_B_ROLE
DESCRIBE PIPE <my pipe>;
-- created_on,name,database_name,schema_name,definition,owner,notification_channel,comment,integration,pattern,error_integration
-- 2022-01-..., ..., ...
SELECT SYSTEM$PIPE_STATUS('<my db>.<my schema>.<my pipe>');
-- {"executionState":"RUNNING","pendingFileCount":0,"notificationChannelName":"arn:aws:sqs:...","numOutstandingMessagesOnChannel":0,"lastReceivedMessageTimestamp":"..."}
When I try using user B, using GET https://{account}.snowflakecomputing.com/v1/data/pipes/{snowpipe}/insertReport I receive: {'data': None, 'code': '390403', 'message': 'Not authorized to manage the specified object. Pipe access permission denied', 'success': False, 'headers': None}
I have checked that the public key fp and private key work since I can get a proper JWT token.
I don't think I can transfer ownership of the pipe and all future pipes of this kind as a blanket statement to user B because Terraform deploys, even those without changes, will recreate the PIPE and remove all permissions from user B - which is why I want to use FUTURE.
I've also tried GRANT MONITOR EXECUTION but that doesn't work either.
What permissions am I missing?
Related documentation:
The Snowflake rest API page does not mention permissions needed: https://docs.snowflake.com/en/user-guide/data-load-snowpipe-rest-apis.html#endpoint-insertreport
Snowpipes only support MONITOR and OPERATE (and I gave them all already): https://docs.snowflake.com/en/user-guide/security-access-control-privileges.html#pipe-privileges
This answer says that OWNERSHIP must be granted, but this was 2 years ago - surely there must be a way for a non-owner to check a Snowpipe ingestion report especially when I can already check them directly via SQL: https://community.snowflake.com/s/question/0D50Z00009YAcOz/how-can-i-see-pipes-using-show-pipes-or-see-their-status-with-systempipestatus-without-having-ownership-permission-to-the-pipes-need-to-debug-issues-without-the-ability-to-change-them
This question mentions default role, but my User B is using the correct default role that I set up. Snowflake Pipe access permission denied
I have checked with a Snowflake representative - irrespective of MONITOR and OPERATE privileges, if you want to use /insertReport, you must have OWNERSHIP of the pipe.
The permissions and features found here https://docs.snowflake.com/en/release-notes/2021-03.html#snowpipe-support-for-non-pipe-owners-to-manage-pipes-preview do not mention /insertReport at all. You can let a sub-role start/pause/load/read/check (via SQL) a pipe, but there are no privileges that let non-owners use /insertReport.
It is possible to call /insertReport by user who is not the pipe owner, if the role has MONITOR privilege.
Snowpipe: Support for Non-Pipe Owners to Call the Snowpipe REST API:
With this release, calling the public Snowpipe REST endpoints to load data and retrieve load history reports is no longer restricted to a pipe owner (i.e. the role with the OWNERSHIP privilege on the pipe) or a higher role in a role hierarchy. The following pipe privileges allow calling specific REST endpoints:
Pipe Privilege
REST Endpoints
MONITOR
insertReport, loadHistoryScan
OPERATE
insertFiles
Pipe execution works fine from user role using snowsql and GUI confirming no permissions issues on the pipe from the given role.
But while calling via snowpipe rest API below error is encountered while using same role.
snowflake.ingest.error.IngestResponseError: Http Error: 403, Vender Code: 390403,
Message: Not authorized to manage the specified object. Pipe access permission denied
Any clue in this will be very appreciated.
The user that is used by Snowpipe REST API needs to have the role with specific permissions for the pipe assigned as default_role.
This is how default role is assigned:
ALTER USER <user> SET DEFAULT_ROLE=<role>;
where is the role used for Snowpipe operations.
This is basically related to how RBAC works:
Every active user session has a “current role,” also referred to as a primary role. When a session is initiated (e.g. a user connects via JDBC/ODBC or logs in to the Snowflake web interface), the current role is determined based on the following criteria:
- If a role was specified as part of the connection and that role is a role that has already been granted to the connecting user, the specified role becomes the current role.
- If no role was specified and a default role has been set for the connecting user, that role becomes the current role.
- If no role was specified and a default role has not been set for the connecting user, the system role PUBLIC is used.
See for more details here
Specifically for Snowpipe REST API usage the following permissions are required to be granted to the role:
See more details here
We have an application which parses the Audit Logs emitted by Azure AD. More specifically we are parsing the 'Update application' log to detect when a new Role has been added to an Application (see example below).
We would like to find out more information about the "DirectAccessGrantTypes" and "ImpersonationAccessGrantTypes" fields. If someone can point us to documentation for this that would be great.
[{"EntitlementEncodingVersion":2,"EntitlementId":"654a4f1f-1b7f-4354-a6d6-fcf7346af0ec","IsDisabled":true,"Origin":0,"Name":"Data Manager","Description":"Manager for test app","Definition":null,"ClaimValue":"DataManager","ResourceScopeType":0,"IsPrivate":false,"UserConsentDisplayName":null,"UserConsentDescription":null,"DirectAccessGrantTypes":[20],"ImpersonationAccessGrantTypes":[],"EntitlementCategory":0,"DependentMicrosoftGraphPermissions":[]},{"EntitlementEncodingVersion":2,"EntitlementId":"3d03256d-cf0c-4553-b8af-98d7ebbee1f2","IsDisabled":false,"Origin":0,"Name":"Application Manager","Description":"Admin for test app","Definition":null,"ClaimValue":"ApplicationManager","ResourceScopeType":0,"IsPrivate":false,"UserConsentDisplayName":null,"UserConsentDescription":null,"DirectAccessGrantTypes":[20],"ImpersonationAccessGrantTypes":[],"EntitlementCategory":0,"DependentMicrosoftGraphPermissions":[]},{"EntitlementEncodingVersion":2,"EntitlementId":"88d0d3e3-b661-4760-aea3-f4548db1ff96","IsDisabled":false,"Origin":0,"Name":"Read","Description":"Allow users to add a admin consent","Definition":null,"ClaimValue":"Read","ResourceScopeType":0,"IsPrivate":false,"UserConsentDisplayName":null,"UserConsentDescription":null,"DirectAccessGrantTypes":[],"ImpersonationAccessGrantTypes":[{"Impersonator":29,"Impersonated":20}],"EntitlementCategory":0,"DependentMicrosoftGraphPermissions":[]}]
From article > View reports & logs in entitlement management - Azure AD | Microsoft Docs
When Azure AD receives a new request, it writes an audit record, in
which the Category is EntitlementManagement and the Activity is
typically User requests access package assignment. In the case of a
direct assignment created in the Azure portal, the Activity field of
the audit record is Administrator directly assigns user to access package, and the user performing the assignment is identified by the
ActorUserPrincipalName.
Application Impersonation is basically an administrator-managed, not user-managed permission.
Impersonate access grants logs gives information ex:count., of users given consent by the admin to access the application to impersonate user.
ImpersonationAccessGrantTypes gives count or info of access grants by admin on behalf of user whereas DirectAccessGrantTypes gives info about the users who directly access the application ,as they are already assigned by admin.
Reference:
Multiple Client applications authorisation to WebApi (microsoft.com)
At first there is no authentication in mongodb, so I created one for one database with readWrite role.
Now I want to create more users for other databases but as this user doesn't have the privileges to create other users I'm stuck.
The documentation clearly says:
With access control enabled, ensure you have a user with userAdmin or userAdminAnyDatabase role in the admin database. This user can administrate user and roles such as: create users, grant or revoke roles from users, and create or modify customs roles.
If you haven't created such user, you cannot create it now with authentication and access rights enabled. I gues you need to restart the MongoDB server without authentication enabled, create that admin user, and restart the MongoDB server again with authentication enabled.
I highly recommend you read to complete documentation how to enable authentication first to understand the complete concept, before you follow it step by step. Otherwise it might be confusing and creating such state you are currently locked in and cannot continue with all actions.