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.
Related
Big question: How to rotate passwords in an Oracle database in a zero downtime (ZDT) way?
My current thought is to rotate the users. Originally, I had MY_USER that had all the tables and such. Now, I have:
CREATE USER MY_USER NO AUTHENTICATION;
GRANT CREATE SESSION TO MY_USER;
CREATE USER MY_USER_PROXY_1 IDENTIFIED BY "abc123";
GRANT CREATE SESSION TO MY_USER_PROXY_1;
ALTER USER MY_USER GRANT CONNECT THROUGH MY_USER_PROXY_1;
When I want to rotate the password, I simply create MY_USER_PROXY_2 and give the 'connect through' grant to MY_USER. This way, the app can continue to create new connections until I deploy it using the new user. Because of the 'connect through', the new user is essentially the same as the old user so everything should continue to work without much fanfare. Afterwards, I can decommission MY_USER_PROXY_1 or let the password normally expire
This seems like a reasonable approach if there is 1 'physical' user (MY_USER)
However, I am already using proxy users for multi-tenancy. Same as before, but instead of 1 user, there could be hundreds of users going through the same proxy user:
CREATE USER TENANT_PROXY_1 IDENTIFIED BY "abc123";
GRANT CREATE SESSION TO TENANT_PROXY_1;
-- During tenant onboard
CREATE USER TENANT_1234 NO AUTHENTICATION;
GRANT CREATE SESSION TO TENANT_1234;
ALTER USER TENANT_1234 GRANT CONNECT THROUGH TENANT_PROXY_1;
The issue with creating TENANT_PROXY_2 is recreating all the connect through grants. I could iterate through all the users like 'TENANT_%' and apply the grant that way but will always be a window of opportunity after TENANT_PROXY_2 is created and updated with the grants BUT BEFORE the app is restarted to use the new proxy user. So it would add the grant to TENANT_PROXY_1 and thus fail when the proxy user is rotated to TENANT_PROXY_2
I tried using roles (both as the connector and the connectee) but looks like only users are supported:
ALTER USER TENANT_1234 GRANT CONNECT THROUGH TENANT_PROXY_ROLE;
GRANT ROLE TENANT_PROXY_ROLE TO TENANT_PROXY_1;
-- or
ALTER ROLE TENANT_PROXY_ROLE GRANT CONNECT THROUGH TENANT_PROXY_1;
GRANT ROLE TENANT_PROXY_ROLE TO TENANT_1234;
My only thought is to pre-create TENANT_PROXY_1 through TENANT_PROXY_N and apply the grant to all N proxy users during onboarding and manually round-robin through the N users. Not quite as graceful, but still seems reasonable
Any thoughts on either solution? Databases have been around for decades, is there any official solution or pattern to ZDT password rotation problem?
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 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
I am using Azure SQL database with sharding (single tenant approach). So, when the application connects to DB it goes into Shard and creates a proper connection to the tenant's DB (tenant is identified by login name).
However, we've been using a server admin credentials for that on a development stage.
Now, I'd like to create a separate application user with much more limited permissions compared to server admin.
In a very general case, what I want is to have a user that can connect to the Shard Map and figure out a connection string to any of the Shards, but have different permissions for each of the shards. For example, some application user may need to be able to connect to DB_1 with full read-write permissions, to DB_2 with read-only permissions and no permissions to connect to DB_3.
In a simpler case I just need a user that doesn't have any update permissions to ShardMap and other internal databases, but has a normal read/write/execute access to all tenant databases(shards).
I was googling around and din't find any good recipe how to do that, what are the best practices, etc.
I'd appreciate if someone could answer me or point to a docs.
Thank yuo!
In each database create a role for the Application Users, and grant the minimal permissions needed for the application to run. Granting permissions on the Schema level is a good choice here, as you don't have to manage object-level permissions.
create role ApplicationUsers;
grant select, insert, update, delete, execute on schema::dbo to ApplicationUsers;
Then if you want a single identity to access all the databases, create a login with a password. Then in each Tenant database create a user mapped to that login.
--create a server-level Login
create login AppUser with Password ='asdfAds01980(*)(*)(#&$)##';
--add a user mapped to that login in each database
create user AppUser for login AppUser;
alter role ApplicationUsres add member AppUser;
Or create a user in each database with a different password or a database user mapped to an Azure Active Directory identity.
create user AppUser with Password ='asdfAds01980(*)(*)(#&$)##';
alter role ApplicationUsers add member AppUser;
or
create user [tenant123user#mydomain.onmicrosoft.com] from external provider;
alter role ApplicationUsers add member [tenant123user#mydomain.onmicrosoft.com];
I spent a long time yesterday to configure for my CouchDB instance in order to create a little app and letting CouchDB manage authentication and authorizations for me.
So I ended up with something like that :
On top of everything I've got a server admin, who basically is god on my CouchBD instance.
Then I created a database named "mydatabase" (for example) and added the role "mydatabase_dba" as admin and also the role "mydatabase_user" as reader.
I also created a database named "_users" which contains all the database admins and users with their roles and also a design document named "_auth" which manages authorizations.
Only the server admin is admin of this database, and I added users with role "mydatabase_dba" as readers. Then, for those of you who knows about it, I modified the "validate_doc_update" field o the "_auth" document so that users with role "mydatabase_dba" can only deals with users with role "mydatabase_user".
So, to summarize at this point :
server admin is still god
users with role "mydatabase_user" can connect to "mydatabase" but they are just readers
users with role "mydatabase_dba" are admins of "mydatabase"
users with role "mydatabase_dba" can connect to database "_users" where they are readers
users with role "mydatabase_dba" can only manage users of role "mydatabase_user" in "_users"
Hope this is clear :D
What I can do now is create an application that will not manage users itself, but let users connect to CouchDB directly (transparently).
The problem come when it deals with users creation/update/deletion.
Because only users with role "mydatabase_dba" can access to the "_users" database and work on users with roles "mydatabase_user", I need at some point to connect to CouchDB as this db admin.
I have two solutions :
Create a user interface into my app that will let the admin connect and do what he has to do
or
Make some more code and let the app do it automatically, this is the solution I prefer, but the problem is : I have to store the admin credentials...
Sorry for the long introduction but I had to describe the landscape first :)
I created a post yesterday about how I could secure the connection between my app and the CouchDB instance : here
The solution I was given is to use HTTP over SSL (/TLS) to secure the communication. I'm okay with that, but now I have another concern, maybe I'm paranoid, but because my app will need to connect as "mydatabase_dba", I have to store its credential somewhere.
But how to store them securely ? As said in my previous post, even if I store the hashed password instead of the plain text password, if an attacker access my app source code, he'll have my admin credentials...
An application should never have an administrative rights. It should only be given the bare minim rights it needs to function. If the application needs some administrative rights, make sure it has as few as possible. Other than that, most of the time these credentials are stored in plain text in some file that only your application can access.
Never commit this text file into your source code manager (Subversion, Git, etc.)! Placing the file into a running system must be a step in the installation procedure.