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
Related
Trying to access Snowflake's marketplace (Trying to access Snowsight gives the same error message). when I log onto the legacy browser UI and click on "Data Marketplace", it takes me to the log in screen again. When I put in my credentials it gives me an error that says: User's configured default role '<username>' does not exist or not authorized. Contact your local system administrator, or attempt to login using a CLI client with a connect string selecting another role, e.g. PUBLIC.
My role has accountadmin level privileges so I'm not sure why this is appearing. To be thorough I granted myself IMPORT SHARE privileges directly to my role, but that didn't seem to have any effect.
Run DESC USER <username>; and see what the default_role is set to. Most likely it's a mismatch on role that isn't assigned to that user. You can change the default role to something else by using the command:
ALTER USER <usernmae> SET DEFAULT_ROLE = <rolename>;
Snowsight will allow a user to log in with their DEFAULT_ROLE. You will receive this error when a user’s DEFAULT_ROLE is not granted to a user or the role was dropped or deleted.
To log in successfully, you should request an administrator to grant you the required role or you will have to set a different default_role for your user that you have access to, and then you will be able to log in.
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
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)
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/
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.