Most of the online guides give advice how to alter the password of the default cassandra user and create another admin for better security. Is there any reason to keep cassandra role if another superuser is created and used for all purposes?
I created a new admin user:
CREATE ROLE priam WITH PASSWORD = 'somepass' AND LOGIN = true AND SUPERUSER = true;
and deleted the default one:
drop role cassandra;
Seems that everything still works :) or not?
The biggest problem with built-in cassandra user is that the QUORUM consistency level is used when accessing its data. This means, if you lose several nodes, you have a big chance not be able to login with this user if you want to perform some action.
You can leave the cassandra user, but you must change its password, and because it's still exist, it's an additional security risk.
So it's better to use a new super user and drop cassandra.
Here they say that you can also drop the account after you create another with superuser rights.
https://docs.datastax.com/en/dse/6.0/dse-admin/datastax_enterprise/security/Auth/secCreateRootAccount.html
also here:
https://www.allcode.com/remove-the-user-cassandra-from-datastaxapache-cassandra-installations/
Related
We are going to change cassandra setting from authenticator: AllowAllAuthentication to authenticator: PasswordAuthenticator
to enable role-based authentication. There will be two roles:
admin which is a superuser
read-only which is only allowed to read.
I would like to provide backward compatibility for users of the cassandra cluster. More specifically,
many users use
shell script that uses cqlsh
python cassandra package
php cassandra package
to only read data from cassandra. Currently they don't specify any username or password. Therefore
I would like to make read-only role some sort of a "default" role, i.e. if no username and password provided,
then the role is automatically set to read-only so the users can read data and thus clients don't need to change their code.
Is there a way to do this? I'm currently having trouble in the following two parts:
the default user is cassandra if there is no role / user specified in cqlsh. I did not find a way to set default user / role.
and for the default user cassandra, I still have to set a password for it.
Any suggestions would be appreciated! Thanks in advance.
I come from an oracle background, were I've done "sqlplus "/as sysdba"" for years. I like it because the O/S authenticates me. Now, there is something similar in Cassandra, but it isn't secure. Basically in your home directory there is a subdirectory called ".cassandra" (hidden). In that directory there is a file (if there isn't, create one) called "cqlshrc" (so ~/.cassandra/cqlshrc). That file you can add authentication information that will allow someone to log in by simply typing "cqlsh" without anything else (unless you're doing remote where you need "host" and "port"). The cqlshrc file has, among other things an authentication section that looks like this:
[authentication]
username = <your_user_name>
password = <your_password>
So you could simply put your desired username and password in that file and you're essentially able to connect without supplying your username and password (You could also run "cqlsh -u your_user_name" and it will find your password in your cqlshrc file as well).
You can see a few obvious issues here:
1) The password is in clear text
2) If you change the password you need to change the password in the cqlshrc file
I do not recommend you use the "cassandra" user for ANYTHING. In fact, I'd drop it. The reason is because the cassandra user does everything with CL=quorum. We found this out when investigating huge I/O requests coming from OpsCenter and our backup tool (as you can see, we use DSE). They were all using cassandra and pounding on the node(s) that had the cassandra authentication information. It's baked into the code apparently to have CL=quorum - kinda dumb. Anyway, the above is one way to have users log in with a specific user and not provide credentials making it pretty easy to switch.
Hope that helps
-Jim
In my XPages application, web users can perform a self-registration. In the registration process, a user document for the web user is created in the address book and the user is added to a group that has Editor access for the database. After executing show nlcache reset on the Domino server, the user can login to and access the application.
In ~98% of all registrations this works perfectly fine. However, sometimes new users cannot enter the application after the login because, according to the Domino server, they "are not authorized to access" the database. The login must have worked because the user id is correct. The exact same user id can also be found in the Members field of the group that has Editor access to the database. To additionally verify the user's access level, I executed NotesDatabase.queryAccess() with the user's id. It returned 0, which is the ACL default and means "No Access". Yet, there are dozens of users in the same ACL group which have absolutely no problem with accessing the database.
At the moment, we "circumvent" this problem by manually removing the user's document from the address book as well as remove him/her from the Members of the ACL group. Afterwards we ask the user the re-do the self-registration with the exact same information as before. Up to now, this second registration has always worked and the user can access the application. Yet, this is not a real solution, which is why I have to ask if anyone knows what could be the problem?
Don't create entries in the address book directly. Use the adminp process for registration. To minimize perceived delay send a validation/confirmation message the user has to click.
Comment of 12/02/2015 seems to be the correct Answer:
Check if the self-registrated user has TWO consecutives spaces in his name, (could be because trailling space too)
In group domino do a FullTrim. So we have
John<space><space>Smith
that is not in group XXX because in the members it's:
John<space>Smith.
This may have something to do with the frequency at which the views index are refreshed in the names.nsf
Since the access control is done groups in the ACL, the server will "know" which user belongs to which group only after the views index have been updated.
In a normal setting, this can take a couple of minutes.
You can test this hypothesis by forcing an index refresh, either with CTRL-MAJ-F9 from your Notes client (warning, can take very long depending on network and number of entries in the names.nsf) or with the command
load updall -v names.nsf
... or by having the users wait a little while and try again 5min later.
Ok, first a question. If you let the user wait a couple of minutes will the access then work? I.e. is it a refresh/caching problem - or an inconsistency in the way you add the user to the group?
I assume that the format of the user name is correct as it works in most cases (i.e. fully hierarchical name)... Is there anything "special" about the names that do not work?
I do a similar thing (and has done several times) - although with some differences :-)
I typically use Directory Assistance to include my database with a "($Users)" view. When I update anything in this view I do a view.refresh() on the view (using Java). I typically do not use groups in these type of applications (either not applicable - or I use OU's or roles for specific users). I am not sure how the group membership is calculated - but I guess you could try to locate the relevant view (though none of them seemed obvious when I looked) - and do a refresh on it.
/John
I'm currently building an application that has to conform with SOX auditing requirements. One of these, is that all inserts, updates and deletes (but delete you can ignore), need to leave a trail that is difficult, if not impossible for a standard user (or non-DBA) to change.
This means, I need to enforce the auditing at the database level via triggers on insert, update and delete.
My problem is; this is a webapp... The typical design pattern is to store users as "logical", for example; in a "users" table. What I need, is for the application to actually run as the logged in user after the initial login.
My thinking (which is likely not the best) is to do the following:
Load the login page via a standard username (webapp)
Check a table called "stored_users" for their logical username/password.
If they enter the correct user/pass; retrieve the db username, generate a session password (stored in KVSession on redis), update the user on the postgres DB and login with it.
After a defined time of inactivity, destroy the password session, reset the db password for the user and log them out.
Does this sound like a safe way to ensure the following?
My users are always using postgres users; so I can enforce the triggers via CURRENT_USER etc..
Security by always regenerating the postgres user password with a random, temporary password
I'd really like to hear what others have to say on this matter; as I really can't find this on Google (or I'm not searching the right terms). It seems the prevailing mindset for user logins is to store them as logical records and have a global connection user.
To achieve your goal
all inserts, updates and deletes, need to leave a trail that is
difficult, if not impossible for a standard user to change.
you can create:
1) Two schemas: one for common tables, one for security stuff like login/pass(hash) table, user session log, change log table, etc.
2) Two users: one common user, that can only use dml on common schema (no ddl), one superuser.
3) Login function that will check provided user/pass against login/pass table and log successful/failed attempts into user session log (you need SECURITY DEFINER function)
4) Set of audit triggers on common schema tables that will check the user privileges and log any changes, made by the user (SECURITY DEFINER functions here too).
We are more than 1 user working on SQLyog (webyog), we all use root to login, recently it has been brought to my attention that some confidential data has been leaked from 1 of the tables that I work on. I have been instructed to have a look into this. Can I protect this table with a new user account from root?
Change the root password immediately.
Your employer is liable for a couple incidents given your scenario.
If confidential info of any kind is being stored on that server, only the people with proper training and classification should have access to said information.
You should create a new user for EACH employee (or for each employee type [e.g: 'root', 'accounting', 'library', 'developer']) and give permissions accordingly.
The only user with global access should be root, and possibly whatever developer account you may create.
Everyone else should have access only to the tables they need and only have access to basic CRUD (Create, Update, Delete) functions. Your accountant may know basic SELECTing statements, but he shouldn't be DROPping tables.
I have a website that I'm working on, and its hosted on a shared hosting site that gives me 1 database connection.
Of course, that login has full access to read and write (as it is the connection I use to build my tables, etc).
However, I want to allow users to be able to write ad-hoc SQL queries, but I want to limit them severely... as an example, not being able to write to any tables.
So my question is - is there ANY way to limit ANY functionality at all at runtime... perhaps as a setting passed in the connection string?
Or is there something I can do in C#? (example: I can start a transaction and roll it back)?
Is there a reason you can't create new user accounts for each user? Then use the built in server security to limit what each user can do.
You could, for example, set up role groups for the new limited users, and then use table security to limit access.
grant select on my_table to limited_user_group
deny insert, update, delete on my_table to limited_user_group
You can use the EXECUTE AS t-sql statement to switch the execution context for the session to another user. You can use WITH COOKIE to lock the execution context down until you supply the cookie value with your REVERT statement.
So it appears that you cannot limit access to the very same user that you are... so what I'm doing as a workaround is I've created another database (a blank one) and I'm going to wrap all of the user queries in a transaction that I will force to rollback.
It's a yucky solution, but as Factor Mystic said in his comment - "get better hosting" is probably the best solution (meaning - the problem here lies with the hosting company).