►
From YouTube: NYC* 2013 - "NoSQL No Longer Equals No Security"
Description
Speaker: Dave Finnegan
SlideShare:
An April 2012 InformationWeek special report entitled "Why NoSQL Equals No Security" began by stating: "If it seems security is an afterthought at best in the big data ecosystem, you're right." DataStax Enterprise 3.0 overcomes this perception and is the first big data platform in the NoSQL industry to bring the type of enterprise security used in traditional RDBMS's to secure systems and important data to the big data/NoSQL market. This presentation will describe each aspect of DataStax Enterprise 3.0's security feature set. Note that all security features are optional; the administrator can decide to use none, some, or all of them depending on their specific application. Features described include Internal Authentication, External Authentication, Permission Management, Transparent Data Encryption, Data Auditing, Client to Node Encryption
A
Security
features
that
we've
added
to
both
the
patchy
Cassandra
open
source
product,
as
well
as
the
data
stacks
enterprise
platform.
It's
been
said
that
no
sequel
equals
no
security,
as
evidenced
by
the
write-up
in
information
week
magazine
and
by
and
large,
that's
been
true.
There's
been
some
amount
of
security,
but
really
not
much.
A
What
datastax
has
done
has
come
in
and
added
security
features
to
both
the
Apache
Cassandra
12
version,
as
well
as
the
data
stacks
enterprise
30
version,
which
we
believe
has
brought
security
up
to
be
production
ready,
as
well
as
enterprise
capable
and
dispelling
the
myth
about
no
security
for
no
sequel
databases.
There.
A
The
security
that
we've
added,
the
first
being
user
authentication-
this
is
a
basic
user
name,
password
type
challenge
when
getting
into
the
cassandra
database.
This
has
been
implemented
through
an
API
that
customers
can
use
to
create
their
own
authentication
paradigms.
Datastax
has
used
the
same
API
to
extend
the
authentication
paradigm
for
data
snacks,
Enterprise
30,
in
that
we've
added
Kerberos
support
for
the
whole
products.
We,
the
second
section
in
security,
is
permission
management.
A
We've
created
an
interface
where
we've
got
users
being
given
permissions
for
objects
within
a
database
as
well
as
hierarchically
through
the
system
and
we'll
talk
about
what
those
features
look
like.
The
third
is
data
encryption.
There
are
several
tiers
of
data
encryption
both
in
flight
on
the
wire
between
the
client
and
the
node
between
nodes,
as
well
as
encryption
on
disk
for
data
at
grass,
and
the
fourth
is
activity
oddity.
A
So
I'm
going
to
break
this
up
into
two
sections.
The
person
is
going
to
be
talking
about
Apache,
Cassandra
and
we'll
go
through
those
categories
of
security
features
that
we've
added.
The
second
is
going
to
be
focused
on
dense
tax
enterprise
and
the
enhanced
features
that
we've
added
to
DSC
30
within
the
same
category
group.
Much
of
it
inherits
from
Cassandra,
but
then
we've
done
a
few
things
to
add
on
to
that.
A
So
the
first
one
in
Cassandra,
sorry
Cassandra
is
user,
authentication,
its
internal
user
authentication,
the
username
and
password
is
stored
within
the
cassandra
database
in
a
key
space
and
column
family.
The
permission
management
section
for
cassandra
is
also
stored
within
the
database.
It's
based
on
the
grant
revoke
paradigm
and
provides
permission
categories.
A
A
A
It's
fairly
similar
we've
also
got
username
password
internal
authentication,
but
we've
extended
that
with
external
off
through
Kerberos,
the
permission
management
is
exactly
the
same:
grant
revoked
I'm
permission
hierarchies
as
we'll
see
data
encryption
on
disk
we've
added
that
to
the
DSC
platform
over
and
above
the
client
to
node
encryption
and
the
node
to
node
encryption
that
you
get
on
the
wire
and
finally,
the
auditing
capability
has
been
added
to
datastax
enterprise.
So
pretty
similar
you
see,
the
few
lines
in
bold
here
are
the
enhancements
that
we've
made
for
datastax
enterprise
over
and
above
Cassandra.
A
Sorry.
So,
looking
at
Cassandra
we'll
go
through
each
of
these.
In
a
little
more
detail,
this
is
managed
by
the
CT
username
password
authentication
managed
by
the
CQ
l3
protocol.
Looking
at
the
c
ql
shell
interface,
you
can
issue
create
user
drop
user
commands
users
get
created
with
the
password
again.
This
information
is
stored
right
inside
a
column
family
within
the
cassandra
database.
Users
can
be
flagged
as
super
users
for
non
super
users.
A
This
is
enabled
by
a
configuration
files
out
of
the
box.
It's
configured
to
be
allow
all.
So
it's
normal.
The
way
you
would
have
expected
Cassandra
today,
no
authentication
required,
but
if
you
change
that
authenticated
parameter
to
be
password,
authentication
users
will
then
be
challenged
for
a
username
and
a
password
when
accessing
the
database
and,
as
I've
said
it's
stored
within
a
column
family
off
in
the
key
spaces
under
users
and
credentials,
Cassandra
authentic
authentication,
sorry
moving
on
still
with
Cassandra
authentication,
so
this
is
default
user.
A
When
you
open
it
up
out
of
the
box,
it's
the
Cassandra
user
with
a
cassandra
password.
This
is
a
super
user
and
we
recommend,
once
you
get
up
and
running
with
authentication
that
you
want
to
drop,
that
user,
create
an
alternate
user
with
superuser
privileges
at
your
own
username
and
your
own
password
and
drop
back
Cassandra
user.
A
If
you're
running
a
full
cluster
would
say
you
know
it
doesn't
nodes
or
four
nodes,
or
what
have
you
you'll
want
to
increase
that
replication
factor
application
factor
one
wouldn't
be
sufficient
if
you
lost
the
one
note
that
happens
to
be
housing
that
data,
what
we
recommend
is
the
replication
factor
be
equal
to
the
number
of
nodes
that
are
running
in
your
cluster,
to
ensure
that
all
nodes
have
direct
access
to
that
authentication
information.
A
couple
of
examples
here:
the
first
one
is
a
user
logging
in
using
cql
shell,
but
not
authenticating.
A
What
they
do
is
they
run
the
cql
shell,
that
executes
it's
just
a
client
and
when
they
attempt
to
run
commands
against
commander
I'm
sorry
against
Cassandra,
they
will
see
a
bad
request
that
the
user
is
not
yet
logged
in.
So
repeating
that
command
again
exiting
the
shell
coming
back
in
and
specifying
the
username
and
password
on
the
command
line
allows
the
user
to
now
see
what
what
the
data
is
and
actually
connect
up
to
the
database.
The
password
on
the
command
line
is
an
optimal.
A
You
don't
want
people
seeing
that
as
you're
typing
in
or
having
your
being
here
p.s
table
with
cql
shell
as
a
client,
it's
possible
to
create
a
cql
shell
RC
file,
a
dot
file
and
put
username
password
in
there
and
simply
secure
that
vial
with
appropriate
permissions.
Then
you
don't
have
to
be
entering
the
password
on
the
command
line.
Similar
interface
would
exist
for
other
clients
that
you're
using
to
access
the
system.
They
would
be
gathering
the
username
and
password
in
their
own
way.
A
In
this
case,
you
have
to
exit
out
of
your
shell
log
back
in
as
a
different
user
and
then
drop
the
Cassandra
user,
so
Cassandra
permissions
based
on
the
grant
revoke
paradigm.
The
permission
categories
that
we
support
include
this
list
here
create
is
for
creating
key
spaces
and
column
families.
So,
given
that
create
permission,
a
user
would
have
the
ability
to
create
new
key
spaces
or
create
the
column.
Families
within
the
key
spaces
alter
is
for
modifying
those
key
spaces
and
column
families,
as
well
as
creating
and
dropping
indexes
select.
A
As
your
basic
read
capability
modify
is
for
editing.
The
data
insert
update,
delete,
truncate
type
commands
drop,
Bowl,
allow
you
to
drop
key
spaces
and
column
families
and
finally,
authorized
gives
you
the
ability
to
grant
permissions
to
others
and
we'll
look
at
this
in
a
little
more
detail.
You
need
either
super
user
privilege
to
grant
users
permissions
or
have
a
permission
with
the
permission
trying
to
give
to
another.
A
This
allows
you
to
actually
delegate
administration
for
whole
two
spaces,
for
example,
to
a
particular
user,
give
them
the
authorized
permission,
and
then
they
can
grant
permissions
to
others
within
that
key
space.
These
permissions
are
hierarchical,
so
there
are
actually
three
tiers.
You
can
grant
permissions
at
the
top
tier
for
all
key
spaces
and
on
down.
So
if
I
had
that
permission,
I
could
create
any
key
space
create
any
column
family
within
any
key
space.
A
Given
that
permission
hierarchy,
I
can
also
specify
permissions
on
just
a
key
space,
a
specific
key
space,
so
I
could,
for
my
very
own
key
space,
have
permissions
there
and
not
have
permissions
in
the
rest
of
the
area,
and
you
can
also
get
down
to
the
column
family
level
with
table.
These
permissions
are
also
individual.
Interestingly,
if
I
had
permissions
to
say,
read
a
column
family
within
a
key
space,
and
I
also
had
all
permissions
on
all
key
spaces.
A
A
These
are
enabled
via
the
cassandra
llamo
file.
There's
an
authorizer
keyword
again
out
of
the
box.
It's
wide
open,
so
allow
all
allow
all
authorizers
is
the
default
setting
you'll
want
to
go
in
and
set
the
Cassandra
authorizer,
and
that
will
enable
permissions
by
default.
No
users
have
any
permissions.
You'll
then
need
to
start
granting
permissions
to
users,
but
then
actually
gain
access
to
the
system.
The
cql
interface
for
doing
that
is
the
grant
and
revoke
commands,
and
you
can
grin
on
key
space
on
key
space.com
family.
A
B
A
I
want
to
give
permissions
to
other
users
to
my
key
space,
for
them
to
say,
read
on
that
a
column
family
within
their
I
would
need
to
have
that
read
permission
in
addition
to
the
authorized
permission
so
given
authorized,
plus
the
permission
I'm
trying
to
delegate
I
can
then
give
that
to
other
users
and
again
this
is
all
stored
within
column
families
inside
Cassandra,
in
off
permissions.
So
a
couple
of
examples
here:
I'm
creating
a
new
user
and
granting
some
permissions
to
the
user
created
user
Mel
with
the
password.
It's
not
a
super
user.
A
A
A
user
they
have
no
permissions,
can't
read
or
write
or
perform
any
operations
within
Cassandra.
You
would
need
to
then
grant
them
permissions
for
them
to
have
the
ability
to
do
anything
within
the
system.
So
here
I've
granted,
select
on
a
table
and
airline
routes
and
granted
modify.
Now
when
I
run
list
permissions,
that's
showing
up
at
the
bottom.
Mel
has
two
permissions
on
those
individual
column,
families,
the.
A
So
a
couple
more
examples
running
is
the
user
Mel
if
I
now
login
to
c
ql
shell,
as
this
new
user
Mel
that
I've
created
I,
can
run
a
select
command,
select
star
on
airline
routes
and
I
get
to
see
that
data.
If
I
try
something
else
say
select
star
from
Caroline
airports,
I
cannot
read
that
data
as
the
user
Mel
as
I
have
no
permissions
on
that
column,
family
and
I
wasn't
granted
permissions
on
the
key
space.
I
was
granted
permissions
down
at
the
column
family
level
also.
A
Pardon
me
so
moving
on
to
data
encryption
within
Cassandra
there's
two
forms
of
data
encryption
both
are
in
flight
on
the
wire
it
already
had
node
to
node
encryption.
This
was
the
ability
to
encrypt
information
between
the
nodes
in
the
Cassandra
cluster.
There's
now
the
ability
to
encrypt
data
from
the
client
to
the
node
as
well
and
there's
configurations
for
no
denote
encryption,
that
you
can
configure
encryption
for
communication
between
all
nodes
in
the
cluster
or
just
nodes
in
remote
data
centers.
A
C
B
A
B
A
Three
different
settings
that
you
configure
for
in-flight
encryption
capabilities.
The
first
is
the
SSL
storage
port.
This
is
set
by
default.
It's
really
not
used
until
you
enable
either
node
to
node
or
client
to
note
encryption.
That
Court
is
just
idle.
When
you
modify
the
encryption
options
section
again,
you
can
do
internode
encryption
and
set
it
to
none,
which
is
the
default
we
can
do
all
for
all.
A
Nodes
should
have
encrypted
communications
between
them
at
all
times
or
look
at
DC
or
rack
settings,
and
then
you
have
to
set
up
the
key
store
and
trust
store.
This
is
the
nodes
certificate.
Key
that
gets
stored
on
the
node,
as
well
as
the
trust
store,
is
the
nodes
that
this
node
trusts
to
communicate
with
the
same
sort
of
setups
exists
for
the
client
encryption
options
for
client
to
node
setups,
where
you
can
enable
this
and
then
provide
the
key
store
and
trust
store
for
those
settings
as
well.
A
All
cassandra,
apache
cassandra,
one
dot
to
open
source
configurations
for
security,
will
now
go
through
sort
of
that
same
list
for
dates:
tax
enterprise.
Much
of
it
is
the
same
internal
user
authentication.
This
has
been
back
ported
from
Cassandra
one
to
two
hours
with
Cassandra
that
were
within
datastax
Enterprise
30,
which
is
119
datastax
Enterprise
lags
the
Cassandra
open
source
version.
By
a
little
bit.
We
do
testing
certification
qualification
on
the
version
of
Cassandra.
A
Sometimes
we
apply
patches
to
that
version
to
get
a
an
enterprise-ready
production-ready
version
of
cassandra
and
we've
now
taken
the
one
dot
two
features
or
security
that
we've
added
to
the
apache
open
source
project
and
backported
that
to
the
119
release,
that's
inside
datastax
enterprise
30,
again,
users
can
create
their
own
paradigms
and
we've
created
an
authentication
paradigm
based
on
Kerberos
Kerberos
is
available
already
in
Hadoop,
there's
also
a
web
Kerberos
interface
for
solar
that
receipt.
So
we
leverage
that
capability
down
into
daves
tax
enterprise
and
through
that
we
have
support
for
ldap.
Look.
A
Carrboro
supports
ldap.
We
do
not
support
authentication
directly
to
ldap
as
a
primary
authentication
mechanism
within
datastax
enterprise,
but
you
can
link
with
ldap
through
Kerberos,
so
get
that
by
extension,
it's
something
we're
looking
into
in
the
future,
so
authentication
carrboro
support
that
for
the
tooling,
so
primary
crib
row
support
for
Cassandra,
of
course,
or
cql,
shell
for
our
Cassandra
client,
scoop,
thrift,
etc,
etc.
All
of
these
clients
are
able
to
be
authenticated
through
Kerberos.
A
We
also
have
Kerberos
delegate
support
down
through
Hadoop
the
CFS
pic
hi
Wow
type
setups
coming
through
that
interface
for
solar.
It
has
its
own
Kerberos
authentication
at
the
web
UI
level
and
since
it
runs
within
the
JVM,
along
with
Cassandra
in
the
datastax
enterprise
process,
there's
no
need
for
that
to
be
handled,
no
need
for
extra
off
there
for
solar
commands
and
queries,
data
ingestion
or
searching
and
finally
jmx.
The
jmx
interface
has
not
yet
been
modified
to
handle
these
new
security
features,
so
it's
still
secured
through
its
standard
jmx
methods.
A
A
At
present,
we
are
storing
the
keys
on
the
node,
which
is
something
to
be
aware
of
the
DSC
service
principles
that
will
be
one
per
node
and
the
format
is
there
either
HTTP
or
DSE,
with
fully
qualified
domain
and
realm
and
regular
users
get
username
at
realm,
and
that
full
principal
must
exist
within
the
authentication
space
inside
cassandra.
So
when
you're
authenticating
through
Kerberos,
you
need
to
also
create
the
users
within
Cassandra.
A
So
DC
permissions,
no
change
here.
This
is
exactly
the
same
as
with
Cassandra
the
same
hierarchy,
the
same
list
of
categories
or
permissions
that
we
talked
about
a
few
minutes
ago
and
datastax
encryption
again
very
similar
to
Cassandra.
We
have
client
to
node
encryption
node
to
node
and
we've
added
on
disk
encryption
that
protects
the
data
at
rest.
In
this
case,
we
are
actually
encrypting
the
data
within
the
SS
tables,
as
we
flush
from
mem
tables
to
SS
table.
We
encrypt
that
data
and
write
it
on
disk.
A
So
now
you
have
the
capability
to
encrypt
data
both
in
flight
and
at
rest
on
the
nodes.
We
are
not
at
this
point,
encrypting
the
commit
log
data
commit
logs
are
ephemeral.
So,
as
we
write
data
into
the
cassandra
database,
we
first
depend
to
a
short
commit
log.
We
write
to
mem
tables
when
those
mem
tables
flushed
to
disk
as
SS
tables.
The
commit
log
gets
erased,
so
the
elements
that
are
in
that
commit
log
go
away,
so
the
commit
log
again
as
ephemeral
data.
A
A
So
the
configurations
for
this
same
thing
as
with
Cassandra
setting
up
the
SSL
boards
and
the
encryption
keys
on
dis
data
encryption.
This
is
enabled
on
a
part
table
basis
to
were
encrypting
data
per
table.
You
can
decide
you
want
these
spaces
and
individual
cables
tables
encrypted.
The
configuration
is
with
the
altar
table
command.
A
We've
leveraged
the
compression
algorithms
that
already
exists
within
Cassandra
database,
and
we
can
now
specify
an
encrypted
and
place
of
or
in
addition
to
as
it
turns
out,
the
SS
table
compression
said
so
in
this
example
we're
just
setting
the
compression
to
be
encrypter
and
specifying
the
secret
key
length.
We
can
also
do
both
at
the
same
time.
The
second
example
here
shows
that
the
compressor
the
compression
setting
is
for
encrypting
snappy
compressor.
A
One
thing
to
note
is
this:
does
not
increase
the
existing
data,
so
if
you
upgrade
to
datastax
enterprise-
and
you
want
to
encrypt
your
data
when
you
enable
these
features,
all
new
data
that
gets
written
to
the
system
will
be
encrypted
and
written
down
to
the
disk
in
the
SS
tables.
If
you
want
to
encrypt
the
existing
data,
that's
in
SS
tables,
already
existing
on
disk
you'll
have
to
run
something
like
DSM
tool
scrub
to
rewrite
those
SS
tables
and
will
be
encrypted
so
encrypting
compression
options.
We
can
do
just
encryption
by
specifying
encrypter.
A
And
finally,
DSC
oddly
auditing
I'm,
sorry
so,
we've
enabled
DSE
auditing
via
the
log4j
config
file.
The
output
for
the
audit
can
be
written
to
a
log
file
on
disk
and
that
gets
specified
in
the
log4j
server
properties
file
or
it
can
be
written
to
a
column
family
within
the
cassandra
database.
Again,
the
formats
for
the
log
are
all
pipe
delimited
with
fields.
These
are
key
value
field,
so
you
actually
see
the
keys
within
the
output.
A
I'll
show
you
an
example
of
that,
but
these
different
fields
include
the
host,
which
is
the
DSC
node
that
has
received
the
activity
and
is
logging.
This
audit
activity,
the
source
is
the
client
address
the
node
that
initiated
the
request
to
drive
this
activity.
The
authenticated
user
is
added
with
the
audit
log
line
that
comes
out
as
well
as
the
timestamp
for
the
event
when
it
occurred.
Finally,
the
category
of
the
type
of
audit
that
you're
seeing
is
the
type
of
activity
that
you're
seeing
is
included
within
the
log
line,
output,
DML,
ddl,
etc.
A
Tcl
query:
the
type
is
the
API
level
operation
that
that's
occurring
down
within
Cassandra
and
when
we
running
cql
commands,
we
actually
show
the
operation
the
cql
command
that
was
issued
in
addition
to
the
type
the
API
level
command.
That
was,
that
was
the
activity
that
was
being
logged,
there's
also
optional,
information
on
batch
and
key
space
and
column
family
information.
So
if
you're
creating
a
user,
for
example,
the
window
key
space
or
column
family
data,
if
you
are
writing
data
to
a
key
space,
you
are
column
family.
A
This
could
be
a
comma,
comma
separated
a
comma
delimited
list
of
categories
can
be
included,
and
you
know
all
just
overrides
that
whole
list
a
lot
of
configuration
options
so
the
first
release
here
there
are
two
audit
configuration
options.
The
first
one
is
by
action,
so
you
can
audit
and
limit
the
audit
that
you
output
to
the
log
file
based
on
the
type
of
category
the
audit
category,
the
DML,
ddl,
etc.
A
You
can
limit
by
t
spaces,
so
you
can
specify
key
spaces
or
black
list
key
spaces
that
you
don't
want
to
see
auditing
information
on
and
in
future
releases
we
will
include
configurations
based
on
the
user,
the
object,
d'art,
type
and
column
information-
that's
not
yet
available
in
the
30
release,
so
configuring
this
stuff
again,
is
by
the
log4j
server
properties
file.
You
come
in
and
set
the
offender
to
be
the
the
offender
file
I'm,
sorry
to
be
specified
a
file
on
disk.
A
Where
you
want
to
write
this
data,
you
can
then
go
in
and
set
the
default
audit
level
info
is
the
default
and
probably
the
one
you
want
to
keep
with.
If
you
go
up
to
higher
levels,
say
or
lower
levels
rather
say
for
warning,
you
won't
see
any
output
you'll.
Have
the
audit
logging
enabled
you'll
see
that
modest
performance
hit
on
what
happens
when
that
code
gets
rung,
but
you
won't
get
any
outputs
because
it
requires
info
level
to
get
the
audit
logs
to
be
written
and,
finally,
the
active
categories
similar
here.
A
This
should
be
a
non-empty
list.
You
need
to
specify
the
categories
that
you
want
logged
if
it
were
empty.
There
would
be
no
categories.
Log
and
you'd
be
suffering
the
overhead
of
driving
that
code
without
actually
getting
any
helpful
from
it.
So
a
couple
of
examples:
this
is
a
cql
command
issuing
use
command
on
a
key
space.
Dsp
904
you
see,
the
first
parameter
is
the
host.
This
is
the
node
where
the
activity
occurred.
The
source
is
the
client
that
asked
for
this
activity,
the
user.
A
The
authenticated
user
is
listed
along
with
the
timestamp
of
when
this
action
occurred
and
the
category
in
this
case
DML.
The
type
is
the
API
level
command
that
gets
issued,
set
key
space,
and
since
we
are
operating
on
a
particular
key
space,
it
includes
the
key
space
parameter:
KS
DSP
904.
Finally,
with
cql
commands,
you
see
the
operation
string,
which
is
the
command
that
was
issued
from
the
cql
level,
that
drove
that
API
level
type
command
as
a
cassandra
CLI
level,
the
same
command
being
issued.
Really.
A
The
only
difference
here
is
that
you
do
not
see
the
operation
field
at
the
end
of
the
line.
It
was
just
driven
from
because
embassy
a
lie
which
is
really
an
API
level
and
no
cql.
On
top
of
that
another
example
for
cql
query
or
drop
key
space
again,
each
of
the
values
is
entered
delimited
by
pipes,
there's
a
name
colon
and
the
value,
and
pretty
straight
forward
to
read
this.
A
So
in
summary,
we've
added
four
different
kinds
of
capabilities
for
security:
we've
added
it
to
both
the
apache
Cassandra,
open
source
project
and
we've
had
it
too
datastax
enterprise.
There's
a
few
more
features
added
the
data
stacks
enterprise
around
encryption
on
disk
and
authentication
for
kerberos
a
couple
of
other
things,
but
these
are
the
main
categories
here:
user
authentication
been
added
/
mission
management
on
the
grant
and
revoke
paradigm
data
encryption
through
client
to
node,
as
well
as
note
to
note
and
on
disk
and
finally,
activity
oddity.
A
Don't
know
the
answer
to
that
question.
That's
a
good
question.
I
know
that
when
you're
doing
sort
of
describe
schema
that
has
changed
now,
you're,
not
getting
the
full
output
that
you
used
to
get
that's
based
on
permissions
and
I.
Don't
know
if
system
is
treated
as
a
regular
key
space.
I
think
it
is
slightly
special,
but
I'd
have
to
get
back.
B
A
C
A
B
A
A
So,
depending
on
the
read
I,
don't
know
what
the
read
consistency
level
is
for
authentication.
I
know
this
information
gets
cached,
there's
a
parameter
for
setting
the
cash
timeout
and
we
recommend
that
you
replicate
to
all
nodes
in
the
cluster
I.
Imagine
it
would
be
handled
the
same
way
that
normal
collisions
are
handled
within
Cassandra,
with
a
higher
consistency
level
and
resolving
to
the
newest
timestamp.
But
again,
I.
Don't
know
that
level
of
detail.
C
A
C
A
C
A
Is
performance
implications
on
that
I?
Don't
have
hard
numbers
on
that,
we're
still
working
on
all
the
benchmarking.
It
seems
to
be
sort
of
in
the
area
of
ten
percent,
but
I
can't
really
quote
hard
numbers
as
to
say
we
know
what
it
is.
We
benchmarked
it
and
studied
it.
That
analysis
is
being
done
today.
Okay,
hang.
A
C
A
A
Yeah
you
would
edit
the
animal
file
for
all
the
nodes
and
then
restart
those
nodes
and
then
bring
your
clients
in,
so
we
recommend
doing
it
all
at
one
time
now,
if
you
were
doing
say,
a
rolling
restart,
a
client
would
come
in
to
a
note
where
it
would
have
to
authenticate
and
another
node
where
it
might
not
have
to
authenticate.
So
we
certainly
don't
recommend
that
you
have
mixed
mode.
C
C
C
A
For
so
authorization
is
username
password
to
gain
access
to
the
system.
Then
permissions
again
is
configured
in
the
mo
file,
but
once
turned
on,
all
of
the
configurations
are
done
through
zql,
shell
or
cql.
Three
right,
so
you
go
into
the
system
and
then
issue
commands
to
grant
permissions
say:
give
Dave
Reed
Commission
on
the
airline
key
space
right,
that's
not
done
from
a
file,
that's
done
from
the
database
directly.
It's
just
the
enablement
of
the
permissions
or
authentication
it's
done
through
the
configuration
file,
and
then
you
restart
the
note
okay.
So
you
try.
A
Not
at
this
time,
so
what
I
had
said
was
the
by
auditing
by
categories
we
have
a
list
of
about
six
categories
that
were
driving
for
only
two
of
them
are
implemented
in
the
first
pass,
so
by
user
is
on
the
list.
We
just
didn't
get
it
for
the
first
pass,
but
that
will
be
coming
as
well
as
some
other.
So
I
could
go
back
to
show
you
what
that
list
looks
like
here.
We
go
so
by
action
by
T.
Space
is
available
in
the
first
pass
by.
A
B
A
Actually,
I
can
answer
that
question.
I,
don't
do
product
direction.
I
know
that
we're
working
on
our
product
roadmap
sort
of
revisiting
it
right
in
this
time
frame
right
now
we
periodically.
Of
course,
we
visit
our
roadmap
I'm,
not
really
sure
what
those
discussions
include
that
they'll
be
coming
out
with
a
new
roadmap
and
hopefully
I'll
get
to
see
that
I
wouldn't
imagine
kerberos
going
to
the
open
source
project,
it's
sort
of
a
fortune,
100
kind
of
thing.