AWS_ROLE credentials are not allowed for this account - snowflake-cloud-data-platform

I am getting the below message:
AWS_ROLE credentials are not allowed for this account.
I am trying to execute the below command to create a stage and the execute a book from my files in S3 to a table into my data warehouse.
use schema mydb.[myschema];
create stage mystage
url='s3://my-bucket'
credentials = (aws_role = 'arn:aws:iam::[]:role/myrole')
encryption=(type='AWS_SSE_KMS' kms_key_id = 'aws/key');

Based on the information in the comments I would recommend these changes that by good practice can be done from the suggest:
GRANT CREATE STATE ON WAREHOUSE <your_warehouse> TO ROLE aws_test;
This is based on the IAM role setup here
Let me know if that helps?

The option 2 is not allowed when the snowflake root account is created in Azure. This answer came to me through the Snowflake support. I then requested them to update the documentation and for me I am using the user and secret key for a while. https://docs.snowflake.net/manuals/user-guide/data-load-s3-config.html

Related

Automate AWS RDS User Management

Most of you would have encountered the problem of creating db users for developers across multiple database (using common user is not allowed). We have around 90 DB's on AWS and 200-250 dev's. Everyday someone needs access to a database and this is manual and repetitive task.
I am looking for a solution to automate end-to-end lifecycle of user management, scripting or creating a terraform module are solutions which I already have in my mind, but how does other organization manage DB users at scale ?
I did look at AWS IAM authentication but I am not sure how can we grant fine grain access using IAM roles.
Cheers,
Fun Learn
The way I've done this is (high level);
Create your RDS Terraform Config / Module(s)
Create a sql file with the user & grant creations needed
Create a wrapper script that deploys terraform then connects to it to deploy your SQL file with user creation
Your wrapper script will need to use Terraform Outputs to get your newly created RDS Endpoint to connect to | Say you created an output called rds_endpoint in your terraform plan / config... This is how you grab it in bash terraform output rds_endpoint
Assuming your new RDS DB is not publicly accessible, your wrapper script will need to tunnel in through a bastion or some other instance that is publicly accessible with access to the DB. Example: ssh -oStrictHostKeyChecking=no -p 22 -i ~/.ssh/bastion-host-key.pem -C -N ec2-user#$bastion_ip -L 3306:$rds_endpoint:3306 &
Your wrapper script will need to use the RDS user & password you created with terraform as well to run the SQL File
In fact IAM authentication could be the key to do that.
What you can do is in fact create all you databases with terraform.
do not forget to enable iam authentication via your terraform module.
Once all you databases are created via teraform, you have to create local role(s) in all of theses databases (either via terraform using SQL script or still via terraform using modules that allow you to create user/roles, for postgresql you can use this module ) and you have to grant them the pre-created, existing, database role for iam (for example with postgresql its named "rds_iam")
The thing that is interresting with iam authentication is that all of your developper can connect using their account to aws and request a token that will be used as a password (the username will be the role you created before) and by doing this you create only one role, but each authentication is made by each developpers account.
If your company really needs you to create roles for each devs (even if the roles are exactly the same, It makes no sense since by definition, we ASSUME a role, so anyone can assume ONE role, this is not awful) you can then create a local database users (instead of a role) for all of your developpers in all of your database by using an SQL script that your terraform will execute.
Of course do not forget to grant the rds_iam existing role to either the unique role that will be used by all the developpers (in case you choose this solution) or to all the db users you created before.
You will have to manage IAM policy for all of theses users to be accurate regarding to the security (or use * in the policy to let all your developpers connect to all you db users lol)
and then your developpers will be able to use aws rds command to generate an auth token and connect to their local db user that will have to correct rights.
There is a hole bunch of informations and precisions here:
https://aws.amazon.com/premiumsupport/knowledge-center/users-connect-rds-iam
have a nice journey on aws

Issue creating master key for Azure SQL Pool - Permission error

I'm trying to follow this tutorial but I'm having issues with granting CONTROL permission.
This is on a Dedicated SQL pool (formerly SQL DW) within Azure by following this tutorial.
I initially try CREATE MASTER KEY ENCRYPTION BY PASSWORD = '23987hxJ#KL95234nl0zBe'; which returns
User does not have permission to perform this action.
So I try to apply CONTROL permission to the user account:
GRANT CONTROL ON DATABASE::master TO useradmin
But this returns
Principal doesn't exist or doesn't have sufficient privileges.
I have search the web for a solution but I cant find one that has yet worked so any help or advice would be much appreciated!
To create MASTER key in azure SQL, follow below statement in Azure SQL data base.
CREATE MASTER KEY
GO
For more details refer this SO Thread by Alberto Morillo and also refer this Microsoft official document.
Updated:
I reproduced same thing in my environment its working fine .
sample code:
CREATE MASTER KEY ENCRYPTION BY PASSWORD='xxxx'
GO
CREATE DATABASE SCOPED CREDENTIAL [cred-name] WITH IDENTITY = 'User_name' , SECRET = 'xxxx'
GO

How to get the user who created table in snowflake

Is there any way to check the user name who created the table in snowflake database.
To previous questions in stack over flow some one suggested below query.
How to find the user who created a table in Snowflake
but I am unable to run the query, showing below error
Error: SQL compilation error: Shared database is no longer available for use. It will need to be re-created if and when the publisher makes it available again.
After gone through some documentation in snowflake I understood it need share access
Please let us know if this share access can be granted to every end user to find the user name who created table ? is it recommended to grant to users.
if so how to grant access to user
or is there any alternative way to get this information.
Regards,
Srinivas
Run the following command to find your current role:
select current_role();
Then ask your account admin to grant access to the SNOWFLAKE database:
grant IMPORTED PRIVILEGES on database snowflake to role your_role_name;
You can try information Schema. If you have access to that database then you should be good.
select user_name,query_text,*
from table(information_schema.query_history())
where contains(lower(query_text),'<your table name>')
and query_type = 'CREATE_TABLE'
order by start_time;

Troubleshoot permissions on a database I am trying to share across two snowflake accounts for same region

I have two Snowflake account and need to clone or copy the databases and tables on the same region.
Solutions that I am trying to replicate:
Data Sharing Intro Reference
I read that:
"Snowflake supports using grants to provide granular access control to
selected objects (schemas, tables, secure views, and secure UDFs) in
the database (i.e., you grant access privileges for one or more
specific objects within the database)."
It sounds like I could share a UDF with the database I want to share with the account, but read only features. This is confirmed:
" ...but cannot perform any of the DML tasks that are allowed in a
full account (data loading, insert, update, etc.)."
Setting up one account as a provider:
USE ROLE ACCOUNTADMIN;
CREATE MANAGED ACCOUNT reader_acct1
ADMIN_NAME = user1 , ADMIN_PASSWORD = 'Sdfed43da!44' ,
TYPE = READER;
//create share
CREATE SHARE Articlelibary_share;
GRANT USAGE ON DATABASE Snapshots TO SHARE Articlelibary_share;
GRANT USAGE ON SCHEMA Snapshots.public TO SHARE Articlelibary_share;
GRANT SELECT ON TABLE Snapshots.public.Articlelibary_TEST TO SHARE Articlelibary_share;
However the error I am getting the error in my worksheet that says:
SQL compilation error: Database 'SNAPSHOTS' does not exist or not
authorized.
What I have found is that when I am in the ACCOUNTADMIN role I can see the snapshot table, however, in the SYSADMIN I cannot see the the Snapshots table.
So, how can I fix the Database/Table permissions so that I can add it to the share?
The activities of creating a share and allowing access to other accounts has to be performed only by the ACCOUNTADMIN and that is the reason for the error that you are seeing.
From Documentation it is very clear :
https://docs.snowflake.net/manuals/user-guide/data-sharing-gs.html#getting-started-with-secure-data-sharing
To perform the tasks described in this topic, you must use the ACCOUNTADMIN role.

What are good practices for granting database permissions to a web service connection?

I have been searching for articles and SQL script examples that would demonstrate how to securely and conveniently solve one of the most common scenarios - connecting from a .Net Core Entity Framework based web application to an SQL database.
But somehow I could not find any coherent step-by-step guide from a reputable source.
Let's assume the following:
I cannot use integrated Windows auth in the connection string and must use username and password based auth (because hosting on a Linux server and the DB is on a different Windows server)
the web service will need your usual minimum set of permissions - connect to the database, read data, write data, delete data, execute stored procedures
While reading many tutorials, I find there are multiple ways to manage the connection permissions. To avoid this question being too broad, I'll list my current choices as I understand them (please correct me if I'm missing something).
Users and logins:
create a login and a user for the database
create a database-only user without a login (not sure if this is applicable to a web app and connection string, but still it's a feature that I've seen being used)
Assigning permissions:
assign the user to some fixed SQL role (db_datareader, db_datawriter AND also will have to grant EXECUTE permission)
grant all fixed permissions
create a custom role (let's say, db_web_apps) with required permissions
Which choices are better (more secure and easier to manage in general) and recommended by SQL DBAs?
I think every database administrator should have a template script handy for quickly adding a new user with minimum required permissions every time when developers ask for a new connection for their shiny new web app.
If you know a good, reliable tutorial or GitHub / Gist example that explains what and why is being done that way or a script that you yourself have used for years without any issues in production environments, I'll really appreciate if you could share it.
Create a role in the database and assign the required privileges to the role. Don't use the fixed database roles. Instead grant permissions directly to objects, schemas, or the entire database if necessary. Like this:
create role trusted_app_role
grant select, insert, update, delete, execute
on schema::dbo to trusted_app_role
That will grant the role full DML permissions on all the objects in the default dbo schema. So if you have any tables or procedures you don't want the app to have access to, just create them in a different schema, say, admin. This way you never have to fiddle with permissions as you add objects. The fixed database roles predate schema-based permissions, and aren't really needed any more.
For your application's identity, add Active Directory or Azure Active Directory (Azure SQL) identities to this role, or, if you can't, add SQL Users to the role.
If you are on Azure SQL, you should normally use a database user without a login. On SQL Server you can only add "contained database users" if you enable Partial Database Containment. Which you can do, but is incompatible with Change Tracking and Change Data Capture, so it's a tradeoff.
So normally for SQL Server you still create a login and map the user to the login. EG:
create login web_service_user with password = '5X+jeuAB6kmhw85R/AxAg'
create user web_service_user for login web_service_user
And then add that user to your role
alter role trusted_app_role add member web_service_user

Resources