We've built a web tool (C# WebAPI) to administrate migration of SQL Azure databases with Entity Framework Code First Migrations.
By default, when we create databases we also create logins and user accounts per database.
These accounts get db_datareader and db_datawriter permissions.
We use these accounts from the web app to connect to the database to get current migrations and if there are any pending migrations, apply them.
For some reason, this operation takes about 10 seconds every time (without applying any updates).
If we use the admin account (associated when setting up the sql server in Azure) instead the time drops to less than a second.
I've come to the conclusion that there must be some kind of permission thing that gives us the decrease of performance.
I've added db_ddladmin role explained here without any success.
We use the DbMigrator class in Entity Framework Migrations to get pending migrations.
After some more investigation I found out that the solution to the problem is to create sql users in the master database also.
Before we only created logins and a corresponding user in the database.
According to this post SQL Azure doesn't support default database and therefore it defaults to the master database were I didn't have any rights.
Adding user to the master database solved the "performance" issue.
Related
I'd like to limit the privileges afforded to any given user that I create via the Google Terraform provider. By default, any user created is placed in the cloudsqlsuperuser group, and any new database created has that role/group as owner. This gives any user created via the GCP console or google_sql_user Terraform resource total control over any database that is (or was) created in a similar fashion.
So far, the best we've been able to come up with is creating and altering a user via a single-run k8s job. This seems circuitous, at best, especially given that that resource must then be manually imported later if we want to manage it via Terraform.
Is there a better way to create a user that has privileges limited to a single, application-specific database?
I was puzzled by this behaviour too. Its probably not the answer you want but if you can use GCP IAM accounts the user gets created in the PostgreSQL instance with NO roles.
There are 3 types of account you can create from "gcloud sql users create" or terraform module "google_sql_user"
"CLOUD_IAM_USER", "CLOUD_IAM_SERVICE_ACCOUNT" or "BUILT_IN"
The default is the built_in type if not specified.
CLOUD_IAM_USER and CLOUD_IAM_SERVICE_ACCOUNTS get created with NO roles.
We are using these as integration with IAM is useful in lots of ways (no managing passwords at database level is a major plus esp. when used in conjunction with SQL Auth Proxy).
BUILT_IN accounts (ie old school need a postgres username and password) for some reason are granted the "cloudsqlsuperuser" role.
In the absence of being allowed the superuser role on GCP this is about as privileged as you can get so to me (and you) seems a bizarre default.
I'm migrating an on-premise application (basically a database + a dashboard) to Azure. In my database on-premise, I had set up some access rules and RSL (Row Level Security) for different user profiles. Those were done at the level of my database which is postgres.
Now on the plateforme of Azure, I have to add an intermediare layer, Azure Analysis service between my postgres and dashboard. I want to know how to ensure my database access management & RLS with the addition of Azure Analysis service.
Do I need to replicate it in Analysis Service? Or it will still work and I do nothing with it.
Thanks
As I understand in the intial design you did not have AAS and the RLS was at the database level . Once you moved to Azure you introduced the AAS ( may be to boost performance) , to me it should work fine . We will have to think how will you refresh the data from the database to AAS and for that you may have add an user .
I have situation here, I have enabled system assigned manage identity of Azure WebApp. And created the External Provide user in Azure SQL database.
These are combination of Powershell task and Dynamic SQL in devops release pipeline
CREATE USER [<identity-name>] FROM EXTERNAL PROVIDER;
ALTER ROLE db_datareader ADD MEMBER [<identity-name>];
ALTER ROLE db_datawriter ADD MEMBER [<identity-name>];
These works fine
But, for testing purpose I have Deleted Azure Web App, but its entry in sql is still persisted
So I tried to Drop this User via powershell task in devops.
But its now allowing me to do so.
If situation is unclear please let me know I will make necessory changes in it.
Is there a way to get the server info of my VSO account and access using SQL Server?
I've tried logging in using the URL
{account}.visualstudio.com
But I got a sever not found error
No, the back-end databases are SQL Azure instances, different from the TFS on-premise databases. I cannot see MS ever giving you access to the database - maybe the data, but not the database.
You can only use the API (old and new REST) and Power BI tools to perform queries.
If you have a specific problem you are trying to solve, post it as a new question because it may be possible without database access.
We are using EF4.3 and Code First.
Our DBAs are keen to reduce the permissions developers have on the development database. But we've had many situations where we've been unable to create the database after it's been dropped when we call DropCreateDatabaseIfModelChanges
What are the minimum database permissions required for a user to be able to call both DropCreateDatabaseIfModelChanges and DropCreateDatabaseAlways?
Do these require different permissions?
Is there any documentation that I can refer our DBA's to that will help explain what is required?
Both initializers need permissions for dropping and creating database. These operations require very different permissions:
Database can be dropped by its owner - this permission is localized to the database (db_owner in SQL Server).
Database can be created only by the user with global server permission to create database - that is usually permission provided only to highly privileged users (dbcreator role in SQL Server)
You also need read access on Master database.
Btw. if this is related to development environment you should use your own local database server instead.