►
From YouTube: Webinar: Achieving Least Privilege Access in Kubernetes
Description
Aqua Security and Apolicy have partnered on an introductory webinar covering Kubernetes Permissions, Access, and Role-Based Access Control (RBAC).
We’ll be answering many commonly asked questions from professionals working with security and compliance challenges in this dynamic environment.
What is RBAC?
How access in Kubernetes works?
How to define and enforce access policies?
Can roles only be assigned the access level needed to do their job?
By the end of the webinar, you’ll have a working knowledge of how to achieve least-privilege access in Kubernetes.
Presenters:
Eran Leib, Co-Founder and VP Product Management @Apolicy
Daniel Pacak, Open Source Engineer @Aqua Security
A
All
right
we're
gonna
go
ahead
and
get
started.
I'd
like
to
thank
everyone
who
is
joining
us.
Welcome
to
today's
cncf
webinar,
achieving
this
privilege
accessing
kubernetes,
I'm
around
labe,
co-founder
and
vp
of
product
management
at
the
policy
I'll
be
moderating
and
co-presenting.
Today's
webinar,
I
would
like
to
introduce
my
co-presenter
daniel
he's
an
oss
engineer
at
aqua.
A
A
A
A
So,
let's
start
so
it's
a
pleasure
to
be
here
today.
My
name
is
iran,
as
I
just
as
you
already
know,
and
I'm
here
to
speak
about
kubernetes
arbuck
and
achieving
this
privilege
in
kubernetes
with
me
today,
daniel
who
is
going
to
with
the
help
of
the
demo
gods
to
demo
some
of
the
topics
we'll
present,
I'm
going
to
try
in
the
brief
time
that
we
have
to
educate
you
to
the
best
that
I
can
about
the
subject.
A
So,
let's
see
what's
on
our
agenda
today,
we'll
start
with
the
pla
with
explaining
how
role-based
access
control
or
our
back
is
implemented
in
kubernetes
double
clicking
on
some
of
the
common
pitfalls
you
will
encounter
when
you,
when
using
arbuck,
we'll
discuss
some
best
practices.
You
should
consider
finally
we'll
be
able
to
tile
tight
altogether
and
discuss
this
privilege.
A
So
I'll
formally
introduce
myself
I'm
one
of
the
founders
and
vp
of
product
management
at
a
policy
we're
a
kubernetes
policy,
orchestration
solution.
Before
that
I
was
a
co-founder
at
whitebox
security,
where
we
built
an
amazing
data
access
governance
solution.
Whitebox
security
was
acquired
in
2015
by
cell
phone
technologists.
A
Awesome,
let's,
let's
get
going!
Thank
you
daniel,
so
the
concept
of
role-based
access
control,
also
known
as
arbuck,
has
been
around
for
many
years
now.
Generally
speaking,
it
seems
simple
at
first,
however,
in
some
cases
the
rigidness
of
some
of
the
implementations
and
the
nuances
translates
to
a
substantial
effort.
Another
factor
of
an
often
overlooked
is
that
our
book
requirement
requires
ongoing
maintenance,
as
users
and
access
are
never
idle.
A
So
arbuck,
like
many
other
concepts,
is
a
compromise
security,
wise
we'd,
like
every
user,
human
or
machine
that
operates
in
our
system
to
have
the
access
it
needs
nothing
more.
Nothing
less.
Reality
tells
us
that
it's
not
always
a
simple
task
operations
wise
we'd
like
to
keep
management
in
a
reasonable
level,
not
requiring
a
whole
team
or
an
army
to
take
care
of
it.
A
Various
you
know
like
something
based
access
control
exists
out
there,
but
the
most
common
one
is
arbuck.
The
main
reason
is
manageability.
Arbuck
means
grouping
access
and
assigning
them
directly
or
through
groups
to
end
users.
The
balance
comes
into
play.
When
you
choose
how
many
roles
you
will
manage
more
roles
means
grander.
More
granular
access,
not
in
our
fault
mean
every
change,
is
a.
A
A
A
So
what
are
roles
made
of
they
are
made
out
of
rules.
Rules
are
the
building
blocks
of
roles.
Building
rules
is
simple.
A
rule
is
made
out
of
two
parts:
verbs
defining
the
action
like
get,
create,
delete,
impersonate
and
resources.
You
can
take
that
action
on.
So
to
summarize,
a
role
holds
a
list
of
actions
on
objects
later
to
be
granted
to
users,
and
you
can
have
multiple
rules
inside
a
single.
A
Role
so
wait
what
so?
What
are
the
resources
in
kubernetes?
So
kubernetes
is
an
api
first
platform
and,
as
such,
resources
are
basically
api
access.
There
are
three
layers
with
every
layer
filtering
down
the
resources
defined
in
the
rule.
So
if
you
see
that
the
chart
here,
we
start
from
the
top
level,
which
is
the
api
group
representing
multiple
types
of
objects.
A
For
example,
the
batch
api
group
is
a
group
containing
jobs,
cron
jobs,
etc.
The
resource
type
filters
down
the
group
to
object
type,
for
example.
If
I
would
write
in
the
api
group
batch
and
then
in
the
resource
type,
I
would
write
jobs.
It
would
mean
that
I
can
access
all
the
jobs
under
under
that
group
and,
finally,
the
name
which
is
the
most
specific
resource
selection
leaving
all
empty
basically
means
everything.
A
In
kubernetes,
we
have
objects
that
are
non-resources
basically
pointing
to
urls
and
allowing
access
aligned
kubernetes
are
back
to
actually
control
access
to
those
urls.
Slash
health
is
an
example
of
one.
If
you
decide
to
use
them
remember
they
are
cluster
level
objects,
meaning
access
to
them
must
be
granted
through
cluster
roles.
Only
and
binded,
through
cluster
role,
binding.
We'll
talk
about
those
bindings
in
in
a
few.
In
a
few
slides.
A
A
A
And
then,
if
you're,
a
user-
and
you
have
access
to
multiple
groups,
then
you'll
get
you're.
Actually
a
member
of
multiple
groups.
All
the
effective
access
for
the
from
those
group
will
be
augmented
to
your
to
your
user
and
then
to
your
subject
basically
and
then
effectively.
You
will
get
all
the
access
together.
Luckily
there
is
no.
There
are
no
deny
rules
in
kubernetes,
hence
less
complexity,
for
something
which
is
already
pretty
complex
and
we'll
see
that
we
can
get
to
pretty
complex
scenarios
with
our
back.
A
So
there
are
roughly
five
types
of
subjects
in
kubernetes,
so
let's
start
from
the
middle
one,
that's
the
most
common
one
and
that's
called
the
service
account
service
accounts
are
objects
of
kubernetes,
they're
managed
internally
per
namespace.
So
when
you,
you
cannot
create
a
service
account
for
the
cluster,
but
once
you
create
a
namespace
or
using
the
default
namespace,
don't
do
it
you
can
you
actually
can
create
a
new
service
account?
For
example,
you
just
do
control,
create
service
account
and
it
will
create
a
service
account.
A
They
are
used
to
run
workloads.
That's
the
main
purpose
for
those
for
those
service
accounts,
their
access
can
be
in
the
namespace
in
their
own
namespace,
where
they
are
defined
or
in
other
namespaces,
where
they
are
not
defined,
meaning
you
can
assign
access
to
a
service
account
defined
in
namespace,
a
in
namespace
b
through
row
bindings,
which
we'll
talk
about,
and
they
can
also
get
access
to
cluster
level
resources
or
cluster
wide
by
doing
role
binding
to
a
cluster
role.
A
Next
are
the
service
account
groups?
These
groups
are
automatically
populated.
A
group
per
namespace
exists,
so
that
name
is
system.
Column
service
accounts,
colon
and
then
the
namespace
name,
and
they
are
populated
with
all
the
service
accounts
in
the
namespace
and
a
global
one
populated
with
all
service
accounts
in
the
cluster,
so
that
one
is
called
system,
column
service
accounts
and
you
cannot
control
those
groups.
They
are
automatically
populated.
Remember
that
last
inside
the
cluster
are
the
special
groups
also
automatically
populated.
A
This
includes
groups
like
authenticated,
which
doesn't
need
explaining
too
much
or
unauthenticated,
which
requires
even
less
explaining
and
masters,
which
is
pretty
much
self-explanatory,
but,
for
example,
masters
automatically
are
assigned
to
cluster
admins.
In
the
beginning,
the
users
in
the
automated
groups
cannot
be
controlled.
They
are
automatically
populated,
so
we'll
talk
about
some
best
practices
around
these
groups.
Later
on
in
the
slides
to
the
right,
we
have
two
types
of
subjects
that
are
not
specifically
tied
up
to
the
cluster
they're
not
defined
over
there
they're
actually
authenticated
to
the
cluster.
A
The
first
are
idp
user
idp
stands
for
identity
provider.
Those
are
users
authenticated
into
the
cluster.
From
an
identity
provider
like
like
google,
like
active
directory
like
azure,
active
directory
like
aws
users,
they
can
be
authenticated
to
the
cluster
and
granted
access
like
any
other
subject,
and
they
can
get
access
in
multiple
clusters
and
that's
actually
important.
A
Last
are
the
idp
groups
that
are
populated
with
other
idp
groups
and
idp
users,
and
they
can
have
access
also
in
multiple
clusters.
So
when
you
think
about
idp
users,
they
are
get
sorry,
they
are
getting
access
from
the
idp
groups
that
they
are
associated
with
or
members
of,
and
then
including
themselves
plus
the
special
groups.
So
everything
ties
up
together.
A
So,
let's
connect
the
dots,
we
talked
about
granting
access
to
subjects
to
them.
To
do
that,
we
use
role
bindings
and
cluster
role
bindings.
The
bindings
are
almost
always
defined
in
the
same
scope
of
the
role.
So,
for
example,
if
you
want
to
tie
up
a
role
you
will
def
in
in
a
specific
name
namespace,
you
will
define
a
role
binding
in
that
namespace.
If
you
want
to
tie
up
a
cluster
role,
you
will
define
a
cluster
wall
binding
and
tie
them
up
together.
A
So
now
that
we
have
the
complete
picture,
let's
just
reiterate
quickly-
roles
are
scoped
to
a
namespace.
They
group
permission
sets
called
rules
and
assigned
through
role
bindings
to
subjects.
The
role
bindings
are
also
an
object.
Remember
it's
not
just
the
line.
It's
not
just
something
that
connects
it's
an
object
of
its
own
cluster
roles
are
scoped
to
the
whole
cluster
and
group
permission
sets
called
rules.
Cluster-Wide
assigning
them
is
through
cluster
role,
bindings
to
subjects.
A
A
A
So
kubernetes
is
no
different
than
other
systems
implementing
our
back.
It
is
still
not
clear
what
a
user
can
do
so
to
help
us
with
that.
Cubecontrol
has
a
command
called.
Can
I
so
it's
a
it's
a
normal
type
of
command
inside
queue
control.
It
allows
us
to
check
if
we
can
do
something
before
actually
trying
and
failing
or
succeeding.
A
It
also
supports
impersonation,
letting
admins
check
the
access
of
any
users.
Usually
it's
for
service
accounts,
that's
the
common
use.
It
does
have
some
shortcoming.
It
doesn't
tell
you,
how
do
you
get
the
access,
and
that's
I
mean
from
what
path
it
comes
in
and
that's
something
daniel
is
going
to
discuss.
That's
the
project
that
he's
working
on.
That's
the
plugin
for
cube
control.
A
So
now
that
we're
kubernetes
our
back
experts,
we
realize
that
understanding,
effective
access
is
not
a
small
fit.
Yet
it
is
a
required
capability
and
not
just
to
check
a
specific
permission
on
a
specific
user.
We
have
direct
versus
indirect
access.
We
have
resource
definitions.
That
is
not
so
easy
to
understand.
Right.
We
have
the
resources
and
the
filters
that
it
down
to
the
filters.
We
have
different
types
of
actions.
A
Everything
needs
to
be
augmented
together
and
then,
when
we
go
into
a
large
scale,
multiple
cluster
hybrid,
multiple
cloud
providers-
it
just
doesn't
get
any
easier
right,
so
all
of
the
above
becomes
pretty
insane
in
large
scales.
Even
medium
skills
are
not
that
easy,
so
daniel.
Why
don't
you
share
some
examples
with
everyone.
B
B
This
command
creates
a
rule
with
a
single
permission
which
grants
a
view
access
to
a
pod,
which
is
a
built-in
kubernetes
resource,
and
we
didn't
wanted
to
show
you
yaml
file,
which
can
be
pretty
obvious.
Instead,
we
are
showing
you
a
utility
which
is
a
dry
run
flag.
So,
if
you
want
to
get
hold
of
a
yaml
file,
you
could
add
a
dry
run
and
the
output
flag,
so
this
will
show
you
the
definition
overall,
as
I
don't
explain,
the
first
command
doesn't
grant
any
permission.
B
This
is
just
defines
a
set
of
rules
which
we
called
viewpods,
then
the
second
command,
actually
grants
binds
this
permission
with
a
service
account.
The
webinar,
namespace
and
the
webinar
name
says
admin.
Those
are
the
objects
that
we
took
from
the
demo
that
we
are
going
to
see.
But
again,
the
second
command
is
granting
permission.
B
If
you
want
to
see
what
a
given
role
or
a
build
in
cluster
role
has
which
rules
it
contains,
you
could
use
the
describe
command
and
the
last
one
is
a
something
that
we're
going
also
to
explain
a
little
bit
better,
that
you
could
actually
create
a
role
binding,
which
refers
to
a
cluster
role.
This
is
mainly
for
reusing
definitions
and
just
creating
a
binding
within
the
namespace.
A
Yeah
awesome,
thank
you
very
much
daniel,
and
so
let's
talk
about
some
advanced
topics.
One
of
them
is
actually
the
last
command
that
daniel
was
showing
so
just
to
remember,
remember
the
last
command
that
you
see
over
there.
That's
the
binding
cluster
role
in
using
a
normal
role,
binding.
Remember
that
it's
coming
soon.
A
A
A
A
Don't
use
it
another
advanced
topic,
and
this
is
actually
very
advanced.
Are
the
aggregated
cluster
roles?
That's
that's
a
level
300
400.
I
think,
and
the
reason
for
that
is
it's
a
special
behavior
and
it's
not
very
simple
to
to
see
that
allows
us
to
create
smaller
cluster
roles
that
automatically
rolls
up
their
x
rules
to
a
bigger
cluster
role.
A
The
actual
problem
with
using
this.
This
feature
is
that
it
makes
something
which
is
already
not
very
simple,
to
understand
even
more
complex,
because
then
you
have
permissions
that
are
or
access
levels
which
are
kind
of
transparent
to
the
to
the
to
the
naked
eye,
and
you
need
to
start
digging
in
to
actually
understand.
A
And,
of
course,
that's
the
exception
that
we
were
talking
about.
So
what
happens
when
you
use
a
role
binding
with
a
cluster
role,
so
the
answer
is
actually
pretty
simple:
it
takes
that
role,
definition
and
scoped.
It
scope
it
down
to
the
namespace
of
the
cl
of
the
of
the
role.
Binding
is
basically
a
method
for
creating
a
single
role
with
common
access
and
assigning
it
to
service
account,
while
scoping
scoping
it
down
to
their
namespace.
A
A
B
Yeah
here
again,
I
don't
want
you
to
memorize
all
the
commands.
This
is
just
to
reiterate
what
aram
was
explaining
with
the
commands,
so
the
first
command
is
creating
a
cluster
role,
because
one
another
use
case
of
cluster
rows
is
to
grant
permissions
to
the
non
res
to
the
cluster
scope
resources.
So
in
kubernetes
we
have
you
know
namespace
resources
and
cluster
scope.
Resources.
Nodes
are
cluster
scope,
so
we
must
use
cluster
roles
to
grant
perm
permissions
right.
B
Another
case
when
you
must
use
cluster
rules
is
when
you
want
to
grant
permission
to
the
api
endpoints
like
health
checks
or
readiness
checks.
There
is
a
bunch
of
endpoint
urls
exposed
by
the
kubernetes
api.
They
are
not
kubernetes
objects,
they
are
not
stored
in
cd,
but
still
you
can
control
who
has
permission
to
to
access
those
and,
and
so
the
third
and
fourth
command
is
like
creating
a
role.
A
cluster
role
and
the
cluster
rule
binding
and
and
the
last
command
is
just
a
preview.
B
A
A
So
one
of
my
favorite
subjects
is
common
pitfalls.
What's
where
can
I
fail
and
the
first
thing-
and
that's
actually
a
big
big,
big
problem
in
kubernetes,
and
it's
it's
not
like
that
in
in
arabic,
implementations,
others,
you
know
if
you,
if
you
go
to
other
hour
back
implementation,
you're,
not
going
to
see
that
the
first
one
is
validation.
It
just
doesn't
exist
so
check
and
double
check,
because
you're
not
going
to
get
a
warning.
If
your
rules
are
not
configured
correctly,
it
won't
work.
A
A
A
The
other
one
is
the
auto-populated
groups,
it's
a
great
feature
for
for
people.
You
know
who
used
other
arbuck
systems.
You
probably
know
that
feature
from
there
as
well,
but
they
also
add
to
the
complexity.
A
member
of
those
groups
cannot
be
removed,
so
hence
any
access
granted
to
these
groups
will
be
assigned
to
all
users
in
them.
A
Adding
access
is
easy,
but
what
we
see
is
that
taking
it
away
is
always
an
issue
think
well
before
adding
any
access
to
those
groups.
Just
give
you
an
example
actually
from
the
white
box
days,
if
someone
would
just
add
access
to
a
folder,
for
example,
to
a
group
of
users,
it
might
be
very
simple,
but
then
taking
it
away,
can
take
years
just
to
verify
that
no
one
is
actually
using
it
and
no
one
actually
utilized
it.
A
So
we'll
talk
about
removing
access
and
how
to
see
some
other
data
around
it
soon,
but
remember
that
anytime,
that
you
want
to
add
something
to
one
of
those
groups
think
carefully.
If
that
group
actually
needs
it
again,
it's
a
shortcut,
but
sometimes
this
shortcut
is
going
to
be,
is
going
to
take
you
to
the
wrong
way.
A
That's
why
we
also
said
you
know,
keep
a
named
account
and
not
the
default
account
that
way:
you're
not
creating
too
broad
of
of
of
access
for
for
users
versus
normal.
You
know
human
beings
where
reality
proves
we
need
to
have
some
wiggle
room
so
keep
it
close
to
this
privilege.
You
know,
don't
just
give
them
anything
they
want,
but
you
don't
have
to
keep
it
to
the
strictest
possible,
because
that
way,
your
help
desk
or
your
people
who
maintain
this
is
going
to
have
a
big
big
headache.
A
So
a
key
method
helping
us
to
is
basically
to
isolate
risky
access
and
we
want
to
isolate
those
risky
access
to
designated
roles
and
grouping
those
risky
access
bundles
as
bundles
that
need
to
work
together.
So,
for
example,
the
ability
to
create
normally
come
would
come
with
the
ability
to
modify
to
modify,
so
you
bundle
them
together
in
a
in
a
role.
A
I'm
not
I'm
not
saying
that
you
should
overlook
it,
but
you
should
pay
more
attention
to
the
risky
roles,
while
isolating
the
risky
access
is
a
good
idea.
Don't
provide
those
risky
roles
to
the
built-in
groups.
Remember
the
previous
recommendation
work
together
on
those,
so
that
takes
us
back
where
I
said.
Arbuck
is
a
compromise
between
security
and
operation.
A
We
we
have
to
have
the
compromise
here
and
eventually,
if
you
think
about
it,
the
compromise
is
the
service.
Account
should
be
kept
with
the
tightest
control,
less
privilege
and
normal
users
should
be
divided
with
isolated
roles
and
granted
on
a
need
to
do
basis
and
non-risky
is
more
of
a
relaxed
manner,
but
the
wiggle
room
and
the
compromise
is
also
the
number
of
roles
and
the
number
of
rules
inside
each
role.
A
A
It
helps
us
to
determine
if
users
are
actually
using
their
access,
it's
a
stepping
stone
to
be
used
when
you
want
to
remove
access.
It
requires
us
to
enable
the
audit
analyze
it
and
understand
which
access
is
not
been
utilized
over
time
by
our
users.
It's
not
a
simple
task.
Hence
you
can
use
solutions
that
address
these
needs
and
also
it
also
also
automates
the
analysis
to
determine
what's
used
and
what
can
be
removed.
B
Yeah
again
quickly
during
the
demo,
you
will
see
the
live,
update,
log
entries,
but
here
we
just
wanted
to
demonstrate
how
it
looks
like
from
the
server
perspective.
So,
on
the
left
hand,
side
we
have
a
request:
http
request
to
the
kubernetes
api,
which
is
trying
to
list
pods
in
the
webinar
namespace
as
an
anonymous
user,
and
it
is
detected.
B
Obviously
the
the
request
is
not
permitted
and
it
is
recorded
on
the
server
side
as
a
forbidden
status,
and
you
can
see
it
as
a
notation
like
a
forbidden
and
the
code
403
another
example.
If
we
move
on
to
the
next
slide
is
also
forbidden
access.
But
this
time
we
are
trying
to
get
the
list
of
pods
in
a
webinar
space
passing
the
token
which
is
associated
with
the
webinar
ns
admin.
However,
this
service
account
is
not
permitted
to
do
so.
B
A
Awesome
thanks
daniel
as
daniel
said,
we're
going
to
see
a
bit
more
of
that
in
the
demo
so
really
quickly
to
to
go
over
the
the
way
to
achieve
the
steps
for
achieving
this
privilege
in
service
accounts
is
basically
it's
divided
to
day
zero,
which
is
the
setup
time
and
day
one
plus,
which
is
the
ongoing
effort.
The
first
step
is
to
create
a
named
account
to
be
used
in
in
the
workload
that
way
we
can
ensure
that
only
the
required
access
is
being
granted
to
this
user.
A
Second,
isolate
the
rules
for
the
for
that
user
to
handle
just
him
now.
This
is
the
other
way
around
from
what
we
talked
about
for
normal
users,
create
a
designated
role
for
that
enroll
bindings.
For
that
service
account,
it
will
create
some
extra
roles,
but
it's
worth
it.
The
last
setup
phase
is
to
set
up
the
audit
where
we
could
track
the
usage,
but
also
to
do
some
some
tracing
day.
A
One
plus
involves
granting
access
when
our
workloads
evolves
and
needs
more
access
review,
the
other
records
to
determine
what's
used
and,
lastly,
remove
unused
access
normally
in
a
in
a
service
account
which
is
in
an
application
that
we
know
what
it's
doing
exactly.
We
won't
need
to
do
too
much
on
day,
one
plus
unless
the
application
changes.
Okay,
if
we
do
a
good
job
on
day,
zero,
we're
clear
some
some
take
away
from
you
know
daniel
experience
and
myself.
A
A
As
I
said,
fourth,
keep
your
clusters
clean:
don't
leave
loose
ends
if
you,
if
you
stop
using
a
roll,
just
delete
it.
If
you
stop
using
your
roll
binding,
just
delete
it
service
accounts
that
you
don't
need,
delete
them,
don't
keep
them
out
there
and,
lastly,
use
audit,
even
if
you're
not
going
to
analyze
it
it's
going
to
reduce
to
reduce
access,
it
will
help
you
later
on
with
operations
and
visibility.
B
Yeah,
thank
you.
So
what
I
have
is,
I
have
a
single
node,
minicube
cluster.
In
my
environment,
you
could
use
managed
cluster,
it
doesn't
really
matter,
but
then
I
also
have
a
cube
control
configured
to
connect
to
this
cluster
crew,
which
is
a
cubecontrol
plugins
manager.
I
need
that
to
install
hook
and
plugin
and
and
I'm
also
using
curl
and
openssl
for
some
of
the
scripts
that
you
are
going
to
see.
B
B
I
have
already
installed
it
before,
so
you
saw
it
and
let's
start
with
the
checking.
What
is
the
current
context
and
what
is
the
context?
So,
whenever
you
install
a
cluster,
let's
say
you
have
a
fresh
mini
cube
cluster.
It
automatically
configures
a
cubecontrol
config
regulation
file
and
it
points
to
something
which
is
called
the
current
context.
B
So
this
current
context
usually
has
a
all
the
credentials
to
connect
to
the
kubernetes
api
server
server
in
this
case,
by
default,
minique
is
using
a
tls,
so
it
is
using
a
client
certificate
and
this
certificate
is
not
stored
in
the
api.
It's
external
right,
but
this
certificate
has
a
something
which
is
called
a
you
know,
fields
such
as
organization
and
common
name,
and
this
is
what
it
matters.
So
the
only
thing
to
remember
from
this
executing
this
script
is
to
to
note
the
organization.
B
As
you
can
see,
the
current
user
in
the
current
context
is
a
member
of
the
system
masters.
I
will
show
you
why
it
is
important
later
on
right.
So
now,
as
we
said,
there
is
a
built-in
command.
I
think
we
had
a
typo
on
the
on
one
of
the
slides.
This
is
cube,
control
alf
can
I
command
and,
for
example,
we
can
use
it
to
check
whether
we
can
create
pods
in
the
current
namespace.
B
B
If
we
are
interested
in
seeing
whether
we
can
create
pods
in
any
namespace
there
is
this
dash
a
or
dash
dash
all
namespaces
flag?
However,
I
would
like
to
see
who
else
or
what
other
you
know,
bindings
or
permissions
that
allow
me
to
do
all
this
pretty
powerful
things.
So
this
is
where
who
can
plugin
comes
in?
B
If
I
ask
who
can
plugin,
who
can
create
pods
in
any
namespace,
you
will
see
that
there
is
a
subject
which
is
of
type
group,
so
there
is
a
group
called
system
masters
that
is
allowed
to
create
bots
because
of
the
cluster
admin
role
binding,
so
essentially
what
it
means.
The
default
user
created
by
the
mecube
installation
script
is
a
member
of
system
masters
group,
which
is
very
powerful.
B
This
proves
that
this
is
not
the
least
privileged.
We
are
too
powerful
and
let's
go
further.
Building
our
command
accepts
this
wildcard
and,
for
example,
we
can
check
who
can
do
anything
with
any
resource
across
the
across
the
cluster
and
again
this
system
masters
group
allows
us
to
do
that,
so
we
can
create
bots
delete
pods,
we
can
create
nodes
delete
boards.
This
is
potentially
dangerous
and
again
with
cubecontrol
who
can
plug
in.
We
have
more
information
about
the
cluster
role
bindings
or
role
bindings.
B
B
As
a
best
practice
create
a
service
account
which
is
dedicated
for
running
the
workloads
right,
so
here
we
are
creating
a
webinar,
namespace
admin
and
and
just
to
prove
that
there
is
a
default
service
account
created
as
well
right.
We
have
two
service
accounts
and
two
corresponding
secrets,
but
try
it
not
using
a
default
secret
right.
This
allows
you
to
browse
through
the
arbuck
objects
and
narrowing
down
the
permissions
yeah.
So,
as
you
can
see
now
we
have
this
webinar
namespace
service
account.
B
We
could
get
the
secret
associated
with
it
and
then
we
can
also
extract
the
code
token.
This
is
by
default
a
jwt
token
and
then
the
last
bit
to
send
a
request
to
kubernetes
api
is
to
get
the
kubernetes
api
url.
From
the
current
context,
and
with
that
we
could
try
listing
pods
in
the
webinar
namespace.
B
And
because
we
sent
an
anonymous
anonymous
request
to
the
api
server,
we
got
the
forbidden
status
right.
We
were
identified
as
system
anonymous,
so
let's
go
ahead
and
try
sending
the
same
request,
but
this
time
we
will
pass
the
barrier
token.
So
there
is
no
magic.
The
the
access
token
associated
with
the
service
account
is
sent
as
a
http
header,
and
this
time
we
were
identified
as
a
webinar
namespace
admin
service
account.
However,
we
haven't
granted
any
permissions,
so
this
is
forbidden
as
well,
so
let's
go
ahead
and
fix
it.
B
One
thing
to
fix:
it
is
to
define
a
role
with
with
the
rules
for
for
listing
parts,
but
we
can
also
reuse
a
built-in
cluster
rows.
Whether
it's
a
good
idea
or
bad
depends
on
your
use
case.
For
the
sake
of
simplicity,
I'm
going
to
reuse
a
built-in
view,
cluster
role,
just
to
demonstrate
that
we
can
do
that.
So
if
you
describe
this
role
and
prep
it
for
permissions
for
pods,
you
see
that
it
has.
This
get
list
watch
rule,
which
is
all
what
we
need
to
list
pods
in
a
in
a
webinar
namespace.
B
If
we
create
a
role
binding.
So
now
we
are
creating
a
role
binding
in
the
webinar
namespace
and
we
are
referring
to
the
service
account
that
we
have
just
created
and
the
cluster
or
view.
So.
The
cluster
role
view
is
built
in
set
of
permissions,
and
now,
let's
try
again
sending
the
same
request
and
this
time
we
we
it
succeeded.
B
Obviously
we
don't
have
any
pods
any
workloads
running
in
this
namespace,
but
the
request
was
allowed
and
we
can
also
see
all
that
in
the
in
the
audit
log.
There
is
always
an
entry
with
a
annotations
saying
that
it
was
allowed
and
also
giving
the
reason
you
could
troubleshoot
and
make
sure
that
this
is
exactly
object,
that
you
want
to
grant
permission
through.
B
If
it
didn't
work
for
some
reason
in
your
environment,
then
he
there
is
this
alf.
Can
I
again
for
the
rescue
it.
Has
this
interesting
dash
dash
list
parameter
which,
instead
of
returning
yes
or
no
lists
all
permissions
and
another
feature
of
this
building
command?
We
are
using
impersonation,
so
remember
when
you
learn,
run
cube
control.
It
is
using
the
current
context
and
this
current
context
has
a
current
user.
B
B
If
it's
not
enough,
you
could
narrow
down
to
a
verb
and
the
resource
name
and
again
using
the
impersonation.
You
can
see
that
the
answer
is
yes
very
often,
I'm
checking
whether
I
could
do
some
disallowed
functions.
So,
for
example,
we
are
talking
about
view
permissions.
I
want
to
make
sure
that
the
service
account
cannot
create
bots
right
in
my
context
with
my
demo.
So
the
answer
is
no.
B
If
things
go
wrong,
you
would
like
to
see
why
or
whether
a
given
subject
has
permission
to
a
given
resource
or
not.
So
this
is
where
who
can
plugin
gives
you
this
information
and
the
first
row?
Actually
the
best
is
to
read
this
output
from
the
right
to
the
left.
Is
you
see
that
the
service
account
in
a
webinar
namespace?
B
Has
a
viewer
all
granted
to
the
webinar
namespace
admin
view
role
binding,
so
this
those
are
the
tools
to
to
troubleshoot
and
and
create
our
back
objects.
Another
thing
that
I
would
like
to
show
you
is
to
see
what
happens
when
you
create
a
pod
with
a
default
service
account.
You
remember
that
in
the
webinar
namespace
we
have
a
default
service
account
created.
If
you
don't
specify
it
explicitly.
B
When
you
run
a
pod,
this
is
going
to
be
used
and
it
is.
It
is
mounted
at
a
particular
path
in
the
container
file
system
right,
so
I
have
created
the
ipod
in
the
webinar
namespace.
I
didn't
specify
any
service
account
to
run
this
container
with.
So
this
is
the
access
token
of
the
default
service
account
and
also
I
can
see
that
by
default
it
doesn't
have
any
permission
which
is
good
as
long
as
you
don't
grant
extensive
permission
to
the
system
service
accounts
group.
B
B
B
Cluster
roles
that
you
can
extend
them
through
the
aggregation
mechanism
and
pretty
typical
use
case
is
that
you
know
the
the
view
cluster
role.
This
has
a
rules
for
building
resources
such
as
spots
deployments,
etc,
but
it
doesn't
know
about
any
extensions
or
custom
resources
that
you
might
create
right.
B
So
what
we
can
do,
we
can
actually
create
a
cluster
role
which
defines
the
permission
to
view
vulnerability
reports
and
then,
instead
of
creating
another
cluster
role,
we
could
just
annotate
it
with
a
special
label,
so
we
can
label
it
with
a
with
the
just
a
sec.
I
just
want
to
show
you
how
it
is
triggered
yeah,
so.
B
Yeah,
exactly
that's
the
magic,
so
so
we
have
to
label
the
view
vulnerabilities
cluster
role
with
the
rbac
aggregate
to
view
through
view.
As
you
remember,
this
is
a
built-in
cluster
and
then
it
is
picked
up
by
the
controller
which
is
running
in
a
control
plane
and
it
is
extending
the
set
of
permissions
of
the
building
view
cluster
role.
We
can
prove
that
by
describing
the
cluster
role,
as
you
can
see
here
now
we
are
eligible
to
list
vulnerability
reports.
If
we
try
again,
we
should
get
the
empty
list
of
vulnerability
reports
there.
B
And
also
something
with
eran
said:
this
is
cool
feature,
but
when
you
use
who
can
plugin
to
troubleshoot,
why
we
have
this
permission?
It
will
show
you
that
it
was
granted
through
the
cluster
world
view
right.
It
doesn't
show
you
this
magic
related
to
annotations,
etc.
Maybe
we
can
extend
this
tool
to
include
this
information,
but
it's
pretty
hard
to
troubleshoot,
so
use
it
consciously,
and
I
think
with
that
yeah
that
was
a
demo.
A
That
was
a
great
demo
daniel.
We
have
some
questions.
Actually,
so,
let's
I'll
try
to
go
through
them
quickly
and
if
you
have
more
guys
or
girls
or
whoever
feel
free
to
to
send
them
through
the
q
a
so
the
first
one
is
on
the
audit
log
when
it
is
successful,
if
you
get
access
from
multiple
access
paths,
which
one
do
you
see
in
the
record,
do
you
want
to
take
that
one?
We
actually
discussed
it
yesterday.
I
think.
B
A
B
Yeah
so
who
can
plug
in?
You
could
go
to
the
aqua
security
github
namespace
and
we
have
a
cubecontrol
who
can
repository.
You
could
install
it
from
sources,
but
the
easier
way
is
to
install
a
crew.
Crew
is
like
brew
for
mac
os.
It's
a
package
manager
for
installing
various
cube
control.
Plugins.
This
index
is
growing.
B
A
A
Can
I,
or
with
the
who,
can
they're
more
specific
to
troubleshooting
for
something
which
is
pinpointed?
You
have
different
solutions.
A
policy,
for
example,
is
one
of
them
that
allows
you
to
do
stuff
like
that,
you
get
you
get
the
full
picture
of
access,
including
direct
and
indirect
data,
and
all
of
it
comes
in
a
very,
very
simple
and
searchable
way.
A
B
Yeah
and
if
I
could,
if
I
could
add
to
that
and
something
that
I
would
like
to
rephrase-
is
that
anan
said
that
we
have
different
types
of
subjects.
We
have
users,
we
have
groups
and
we
have
service
accounts
and
only
service
account
is
stored
in
a
kubernetes
as
an
object.
The
users
and
groups
are
coming
from
the
authorization
provider,
authorization
planning
plugin,
as
you
saw
in
the
demo,
it
can
come
from
the
certificate
some
field
in
the
certificate.
B
It
can
come
from
a
scope
of
the
jwt
token,
but
the
thing
is
that
kubernetes
doesn't
have
all
this
information
stored
in
a
cd
and
accessible
through
the
kubernetes
api.
So
that's
why
keep
control
out?
Can
I
or
who
can
fall
short?
If
this
information
is
not
visible,
you
need
something
more
which
gives
you
like
an
overview
of
all
the
our
back
set
and
that's
the
biggest
challenge
so
far.
I
think.