> > Here is what I have pieced together. Please let me know if I am on the > right track.
You're more or less right regarding the built in authenticator/authorizer/role manager (which are usually referred to as "internal" as they store their data in Cassandra tables). One important thing to note is that using the default superuser credentials (i.e. logging in as 'cassandra') will make these reads happen at QUORUM, not LOCAL_ONE, which is one of the reasons you shouldn't use those credentials after initial setup. There are 2 settings which govern the lifetime of cached auth data. Once an item has been cached, it becomes eligible for refresh after the update interval has passed. A get from the cache will trigger this refresh, which happens in the background and while it's running, the old (maybe stale) entry is served from the cache. When the validity period expires for a cache entry, it is removed from the cache and subsequent reads trigger a blocking fetch from storage. There is further detail in the docs here: http://cassandra.apache.org/doc/latest/operating/security.html If NOT EXISTS will use SERIAL consistency This isn't actually true. Because internal storage is just one implementation of role/user management, it doesn't rely on LWT. Instead, the configured role manager is consulted before executing the statement, which is similar to how IF NOT EXISTS in schema updates work. On Tue, Mar 14, 2017 at 11:44 PM, Jai Bheemsen Rao Dhanwada < jaibheem...@gmail.com> wrote: > I have similar question. when we create users or roles what is the > consistency level used? > > I know, If NOT EXISTS will use SERIAL consistency. what consistency will > be used if just use CREATE USER ? > > On Mon, Mar 13, 2017 at 7:09 PM, Jacob Shadix <jacobsha...@gmail.com> > wrote: > >> I'm looking for a deeper understanding of how Cassandra interacts with >> the system_auth keyspace to authenticate/authorize users. >> >> Here is what I have pieced together. Please let me know if I am on the >> right track. >> >> A user attempts to connect to Cassandra. Cassandra checks against >> system_auth for that user @ LOCAL_ONE - - If the user exists, a connection >> is established. When CQL is executed, C* again checks system_auth for that >> user @ LOCAL_ONE to determine if it has the correct privileges to perform >> the CQL. If so, it executes the CQL and the permissions are stored in a >> cache. During the cache validity timeframe, future requests for ANY user >> stored in the cache do not require a lookup against system_auth. After the >> cache validity runs out, any new requests will require a lookup against >> system_auth. >> >> -- Jacob Shadix >> > >
