►
From YouTube: TGI Kubernetes 128: RBAC tooling!
Description
Come hang out with Duffie Cooley as he does a bit of hands on hacking of Kubernetes and related topics. Some of this will be Duffie talking about the things he knows. Some of this will be Duffie exploring something new with the audience. Come join the fun, ask questions, comment, and participate in the live chat!
A
A
We
have
a
lot,
there's
a
there's,
a
ton
of
stuff
out
there
for
our
back,
so
it
should
be
a
fun
one.
I'm
looking
forward
to
this
one.
So,
let's
see
who
we
got
with
us
in
the
chat
today
we
got
mr
rory
mccrew
and
mccoon,
saying
hello
from
scotland
and
chuckles,
saying
hello
from
jakarta,
david,
michael
checking
in
from
minnesota
and
rodolfo
ready
to
learn.
I'm
ready
to
learn
too.
The
best
thing
about
this
show
is
learning
every
day,
every
friday
maddie
good
to
see
you.
This
is
your
idea
for
an
episode.
A
A
Salt
from
oulu,
finland
good
to
see
you
aj,
saying
hello
and
good
afternoon
and
martin
from
the
netherlands
good
to
see
you
martin
very
consistent
viewer,
mr
martinez
juco
from
helsinki,
finland
and
jeremy,
saying
hello,
checking
in
and
home
from
israel
and
tim,
my
good
buddy
timmy
carr
hanging
out
and
ready
to
hammer
on
some
our
back
and
we
got
bojonsh
from
macedonia
and
rada.
Saying
hello
from
arizona
today
in
alameda
is
a
seasonably.
I
guess
very
warm
day
comparatively
and
I
think,
like
the
outside
temperatures,
like
I
don't
know.
A
Actually,
let's
I'm
curious.
Let's
find
out
alameda
weather,
it's
85
degrees
outside,
oh,
my
god,
it's
so
hot!
I'm
kidding
california
weather
you
know
so
for
for
us
for
us
for
us
californians.
This
is
quite
warm
in
alameda
and
there's
like
no
wind
or
anything
so
kind
of
surprisingly,
surprisingly
toasty,
but
I
was
reminded
of
that
because
texas
and
arizona
you
know
like
my
meager
85
degrees,
is
sort
of
a
terrible
joke
compared
to
like
some
of
the
weather
y'all
get
like.
Oh,
my
goodness,.
A
85
is
probably
closer
to
a
heat
wave
that
rory
mccune
experiences
in
scotland.
That
would
be
like
crazy,
hot
there
or
ian
from
wales
good
to
see
you
yeah,
no,
no,
I'm
good
without
the
humidity.
Thank
you,
though,
like
maui
lyon,
I
grew
up
on.
I
grew
up
on
maui
I
have.
I
have
experienced
humidity
in
my
time,
yeah
from
macedonia,
saying
90
degrees
there,
toasty
weather.
A
Yeah
moved
from
texas
to
toronto-
I
you
know
I've
heard
people
regard
canada
as
texas
north
because
there's
a
lot
of
I
don't
know
if
that's
true
or
not,
but
I
do
feel
like
there's
a
lot
of
people
running
around
in
trucks.
There's
like
huge,
wide,
open
spaces.
It's
like
the
same,
it's
the
same
in
as
texas
in
that
way,
and
that,
like
there's
huge
areas
where
it's
just
like
wide
open,
there's
nothing
there.
Mr
brian
lyle's
checking
in
good
to
see
you
brian
and
sudeep,
saying
no
way.
It's
not.
A
A
A
Tom
saying
hello
from
the
netherlands
all
right,
so
this
week's
notes
we
got
some
interesting
stuff
happening,
including
some
of
the
work
by
the
sig
cluster
or
sig,
or
is
it
a
working
group?
Let's
take
a
look
at
this
article
introducing
hierarchical
name,
spaces
which
in
itself
should
kind
of
break
your
brain
a
little
bit
because
it
kind
of
breaks
my
brain
a
little
bit.
But
you
know
it
is
what
it
is.
A
Those
sorts
of
things
right
or
do
you
consider
a
namespace
to
be
associated
with
a
person,
and
do
you
represent
that?
Do
you
represent
that
the
the
content
of
that
name
space
to
a
specific
group
or
to
a
person-
and
you
know
I
think
these
are
the
these-
are
the
questions
that,
like
I
think
in
almost
literally
every
kubernetes
discussion.
A
I've
ever
had
that
goes
into
any
depth
at
all,
like
we
always
come
to
this
very
topic,
and
so
I
think,
with
the
multi-tenancy
group,
we're
actually
starting
to
try
and
think
about
some
of
the
other
ways
to
solve
this
problem.
So
they
have
a
hierarchical,
namespace
controller
that
you
can
play
with
today
and
deploy
with,
and
it
might
be
kind
of
an
interesting
thing
to
do.
An
episode
on
explore
these
things.
A
They've
started
digging
into
like
some
of
the
ideas
of
how
some
of
the
behaviors
of
how
these
things,
how
something
like
a
multi-um,
how
a
hierarchical
name
space
would
be
able
to
handle
inheritance
inherited.
So
things
like
role,
bindings
or
policy
top
objects
copied
from
the
parent
to
the
child.
Things
like
this
and
then
delegated
creation.
A
So
like,
if
you
are
the,
if
you
are,
you
are
an
administrative
role
for
a
hierarchical
namespace,
then
you
should
probably
also
have
the
ability
to
create
the
lower
name
spaces
underneath
that
level,
and
actually
you
also
haven't
looked
into
this
myself
yet,
but
I
wonder
how
high
up
the
stack
it
goes
like?
Is
there
only
one
level
of
hierarchy
or
is
it
or
can
you
actually
create?
Multiple,
I
don't
know
might
be
one
of
those
things
we
dig
into
when
we
actually
do
this
episode.
A
A
A
And
yeah
I
mean
they
talk
about
like
network
policy.
They
talk
about
different
objects.
They
talk
about.
They
have
this
idea
from
in
labels
that
math
that
mark
the
map
that
you
inherited
from
that
kind
of
thing.
So,
if
you're
interested
definitely
check
it
out,
might
be
kind
of
some
a
fun
weekend
project
to
explore
and
play
with
mr
steve
wade
good
to
see
you
again.
A
So
that's
an
exciting
new
time,
that's
an
exciting
new
project
and
it
seems
like
they're
in
a
place
now,
where
they're
ready
for
some
feedback
and
they're
interested
in,
like
digging
into
a
bit
more.
The
119
release
team
is
on
break
to
prep
for
kubecon
and
will
resume
on
the
24th
of
august.
119
is
is
pretty
close
right,
we're
almost
to
the
point
where
we're
ready
to
kick
119
out
the
door
and
in
sudoing
we've
also
started
to
explore
the
120
release
team.
Mr
jeremy
ricard
will
be
the
120
release.
A
A
A
A
A
since
money-
so
this
is
a
bump
to
this-
is
a
bump
of
the
go
version
bump
and
go
to
1
13
15.
there's
been
a
lot
of
revolution.
I
mean
been
a
lot
of
cycles
on
go
lately,
it's
been
releasing
pretty
hot
and
heavy
lately,
so
I
imagine
this
is
a
this
has
been
part
of
that,
so
this
is
basically
bumping
the
go
version.
A
lot
of
the
bigger
changes
were
in
earlier
versions,
but
still
good
to
get
updated
if
you're
tracking
this.
A
In
the
cloud
native
ecosystem
monday
begins
the
exciting
the
excitement
of
kubecon
cloud
native
europe
virtual
con
convention.
This
is
the
one
that
we
would
have
had
in
amsterdam
earlier
this
year,
but
with
the
world
being
what
it
is.
It
became
a
virtual
first,
it
was
the
date
changed
and
now
it's
been
turned
into
a
virtual
conference
and
you
can
access
the
schedule.
You
can
definitely
check
out
the
mentoring
sessions
which,
which
will
be
really
pretty
exciting.
A
I
know
that
they've
been
we've
been
trying
to
build
like
a
good
number
of
people
who
are
going
to
be
there
to
mentor
folks.
So
if
you're
listening
to
this
or
you're
checking
out
tjik,
because
you're
interested
in
becoming
a
little
a
part
of
the
project
or
starting
to
actually
contribute,
this
is
an
incredible
opportunity,
the
mentors
that
we
have
and
the
the
people
involved
in
this.
A
It's
just
it's
an
incredible
opportunity
whether
they
are
peers,
people
who
have
already
been
contributing,
and
you
want
to
like
catch
up
and
and
chat
with
some
of
the
other
folks
who
are
working,
perhaps
in
different
areas
of
the
code
base,
whether
it's
like
the
first
one,
whether
whether
it's
your
first
one
like
what
you
want
to
do,
whether
you
want
to
become
a
maintainer
of
a
particular
group.
There's
lots
of
really
great
opportunities
here,
definitely
check
it
out.
A
That
will
be
happening
next
week.
You
can
see
the
schedules
and
stuff
one
of
the
other
big
pieces
of
news
that
happened
this
week
is
docker,
has
an
updated
image
retention
policy
policy
policy
and
I
imagine
it'll
be
really
interesting
to
see
what
happens.
Octant
is
free
and
oss
exactly
saying
for
it's
free,
you
get
critique,
saying
hello
from
india
and
just
for
saying
from
the
hey
from
the
medellin
good
to
see
you
got
scott
nichols
checking
in
and
the
dean.
Do
you
have
a
graphical
interface
instead
of
a
command
line
on
your
face?
A
I
do
I.
I
typically
do
a
lot
of
stuff
in
the
in
the
cli
but
yeah.
Definitely
the
octant
is
the
bomb
and
it's
actually
really
neat
seeing
it
extend
over
time.
I
do
have
a
talk
this
year,
I'll
be
doing
a
talk
on
sitcom
profiles
on
you.
It's
like
a
jungle
guide
and
cycon
profiles
and
so
definitely
check
out
the
schedule.
Look
for
yours!
Truly!
You
should
be
able
to
see
that
one
I've
already
recorded
it
and
I
recorded
it
myself.
A
All
right
hanging
out
with
the
fam
we
got
deem
saying
hello
from
saudi
arabia.
Yeah
setcomp
operator
is
the
bomb
and
it
actually
does
make
it.
It
does
make
a
presence
in
the
in
my
talk
for
for
what's
happening
there,
because
I
think
this
comp
operator
is
like
a
a
very
important
step
that
allows
us
to
figure
out
how
to
actually
get
sitcom
profiles
down
to
those
nodes
where
we
can
actually
refrigerate
them
and
jenkins
x
is
doing
an
amazing
thing
with
octane
yeah,
that's
really
cool.
A
Yes,
you
have
brian.
Yes,
you
have
all
right:
hey.
Can
you
close
the
doors
for
me?
Also,
thank
you
all
right.
So
this
one
content
container
image
retention
policy
make
kind
of
a
splash
and
what
they're
doing
I
think
what
they're
trying
to
do.
This
is
perhaps
not
communicated
super
clear,
but
what
they're
trying
to
do
is
you
know,
reduce
the
storage
cost
and
reduce
the
retention
policy
for
images
that
are
not
in
use
how
they
measure.
A
There
you
go
that
like.
If
you
look
at
the
poll
counts
for
things
like
sometimes
it'll
be
hundreds
of
poll
counts,
and
I
think
that
partially
that's
due
to
the
fact
that,
like
there
are
many
services
like
docker
and
kubernetes,
and
tools
like
that,
that
actually
just
check
to
see
if
the
images
is
there
and
that
they
have
a
rational,
manifest
for
what's
on
disk
before
proceeding,
and
I
think
that
counts
sometimes
as
a
poll
count.
A
So
what
they're
trying
to
do
is
actually
remove
images
that
have
not
increased
in
pole
count
over
a
period
of
six
months,
I'm
still
a
little
bit
at
sea
about
like
how
this
will
actually
affect
folks
in
real
life.
I'm
curious
about
it
myself,
I'm
pretty
curious
to
see
like
if
this
will,
if
this
will
just
happen
and
not
actually
damage
folks
or
if
it's
like,
or
if
it's
going
to
have
like
fall-down
effects
that
we
don't
expect
but
yeah.
A
It
should
be
pretty
interesting
how
it
shakes
out
so
be
aware
of
that,
and
they
and-
and
you
know,
keep
your
eye
on
it
could
be,
could
be
some
interesting
stuff
coming
up
helm
releases,
helm
version,
330
focuses
on
helm,
lint
and
general
stability
fixes,
which
ought
to
be
pretty
interesting
and
then
2.
16
10
is
a
final
bug
release
the
final
bug,
fix
release
for
home
b2,
which
is
pretty
exciting.
A
So
I
do
remember
looking
at
this
one.
This
one
is
about
like
how
do
you
know
like
what
happens
when
you
handle
the
roll
out
of
a
new
version
of
an
object
like
with
the
traffic
that
was
going
to
the
old
one
right?
Do
we
immediately
do
we
just
like
you
know,
eof
all
the
connections
that
were
going
to
that
old
one?
A
What
happens
right
and
they
do
and
daniel
does
a
great
job
of
like
really
digging
into
like,
what's
happening
here
and
how
that
happens,
and
talking
about
readiness,
checks
and
liveness
checks.
So
if
you're
curious
about
that,
and
specifically
just
to
be
really
explicit,
what
this
is
digging
into
is
say,
you
have
like
two
versions
of
an
application.
The
first
version
is
deployed
and
you've
got
stuff
and
you've
got
connections
going
to
it.
Things
are
working,
and
then
you
start
deploying
the
next
one.
A
Well
as
part
of
that
process,
we're
going
to
be
turning
off
the
first
version
and
turning
on
the
second
version
and
when
we
turn
off
the
first
version,
what
what
sort
like?
What
can
we
do
to
ensure
that
connections
that
are
still
in
flight
against
that
old
version?
Don't
just
get
dropped
right?
Let
them
finish
their
transaction
before,
like
actually
killing
off
that
process
right.
How
do
we
handle
that
mechanism?
And
that's
actually,
where
a
lot
of
this,
where
a
lot
of
this
article
goes?
A
Mr
quentin
machu
wrote
a
really
interesting
article.
He
is
like
the
lead
platform
at
bitmex
and
does
a
huge
kubernetes
deployment
there
that
actually
handles
a
lot
of
the
bitcoin
transactions
that
happen
and
they've
been
playing
with
weavenet
for
a
very
long
time-
and
recently,
I
guess
they've
just
had
some
more
they've
had
more
challenges
with
we've
net,
and
so
they
decided
to
actually
try
to
make
a
move
from
weavenet
to
calico
live
in
production,
and
this
is
a
fascinating
write-up
about
how
that
happens.
A
I
mean
like
swapping
a
cni,
a
little
component
like
cni
out
in
a
live
cluster,
let
alone
a
production
cluster
that
is
a
that
is
an
undertaking
right,
so
definitely
worth
checking
out.
If
that
is
kind
of
interesting
to
you,
but
yeah
cni
live
migration,
fascinating
work,
great
work
from
quentin
and
the
team
at
bitmex.
A
And
then
we
get
into
it
all
right,
cool.
Let's
go
back
to
the
chat,
see
how
everybody's
doing
in
the
chat
rio,
saying
hello
from
the
netherlands
and
today,
I'm
checking
in
from
saudi
arabia.
Do
you
have
any
project
in
saudi
arabia?
I
don't
personally
have
any
projects
in
saudi
arabia
taco.
I
really
think
that
we
should
they
should
yeah.
A
A
I
wonder
that
because
it's
they're,
they
seem
to
be
targeting
inactive
instances
right
and
like
and
and
like
I
said
before,
what
I've
seen
from
the
image
pull
count
is
crazy
town,
as
far
as
like
you
know
like,
if
you
have
any
reference
to
an
image,
it's
very
it's
very
easy
to
see
that
image
count
grow
right.
So,
even
if,
like
a
restarted,
pod
represents
a
new
pole,
count
right,
and
so
I
have
a
hard
time
believing
that
it's
going
to
have
like
a
really
big
detrimental
effect.
A
Be
all
right,
so
first
thing
I
want
to
point
out-
is
rbac.dev
if
you're
interested
in
role-based
access,
control
and
kubernetes
and
that
sort
of
stuff
definitely
check
this
out.
There's
been
like
this
is
a
great
aggregate
for
content
related
to
our
back,
that's
being
hosted
by
michael
housenblast,
so
definitely
check
it
out.
I'm
probably
slaughtering
his
name,
but
he
also
has
a
bunch
of
recipes
like
different
recipes
for
handling
things,
and
I'm
actually
planning
on
exploring
this
a
little
bit
today.
A
The
aggregate
roles
like
how
they
work,
and
so
I
want
to
play
with
that
a
little
bit
today
as
we
as
we
dig
into
the
detail
and
stuff,
but
he
has
links
to
different
applications
like
I
guess
there
is
no
link
there,
but
good
practice
to
leverage
audit
to
our
back.
We'll
talk
about
audit
to
our
back.
I
didn't
put
a
link
into
that.
One
probably
should
have,
though
so
I'll
link
it
here
and
let's
go
ahead
and
add
that.
A
A
Audit
to
our
back,
this
is
actually
a
fascinating
tool
that
jordan
wrote
like
a
million
years
ago.
So
let's
talk
about
it,
real,
quick
and
then
we'll
kind
of
get
into
the
rest
of
it
here.
So
what
our
audit
to
our
back
does-
and
it
looks
like
the
last
update-
was
about
seven
months
ago,
moving
kate's
to
117.2
and
go
113..
A
And
then
generate
an
rbac,
roll
and
binding
based
on
what
is
learned
from
the
audit
log,
because
if
you
think
about
it,
each
call
that
we
see
to
the
api
server.
It
can
be
caught
by
the
audit
log,
and
this
tooling,
basically
tries
to
like
treat
it
like.
A
learning
exercise
right,
where
we
grant
a
particular
service
account
admin
level
access
to
a
given
name,
space
right,
and
then
we
watch
that
service
account
go
through
the
lifecycle
of
managing
whatever
it
is.
A
So
like
say
you
have
an
operator
that
needs
to
be
able
to
create
things
or
change
things
or
modify
things
as
you
exercise.
All
of
the
api
calls
that
that
operator
might
make
against
the
api
server.
All
of
those
calls
will
show
up
in
the
audit
log,
and
we
can
take
that
audit
log
as
input
and
generate
a
role
and
a
binding
associated
with
that
service,
account
that
you
had
granted
like
a
higher
permission
to
and
then
reduce
the
scope
of
those
permissions
to
fit
exactly
what
that
role
exactly.
A
Oh,
I
think
I
blew
away
my
notes,
if
only
I
knew
where
they
were
tgik,
I
o
dot,
io,
slash,
notes
all
right
and
then
go
back
to
rbac.dev
yeah,
and
then
they
they
link
to
the
kubernetes
official
kubernetes
docs.
They
link
into
some
of
the
different
talks
and
and
pieces
that
are
around
our
back.
I
highly
recommend
this
effective.
Our
back
talk
by
jordan.
A
So
just
I
make
the
plea
to
everyone:
who's
like
building
things
with
a
hardback,
remember
least
privilege.
Remember
that,
like
you
know
just
granting
an
operator
or
an
application,
or
something
like
that,
the
highest
permission
to
the
admin
level
to
a
namespace
or
something,
although
it's
easy,
it
doesn't
mean
it's
like
secure
or
rational,
because
if
somebody
takes
over
that
particular
application,
they're
going
to
have
quite
a
bit
more
control
over
your
environment
than
they
should
so.
Keep
this
in
mind.
It's
it's
an
important
one.
A
Oh
nice,
you
know
what
the
only
thing
that
I
was
just
realizing.
He
also
michael
also
links
a
bunch
of
interactive
query
tools,
and
I've
got
a
bunch
of
these
in
my
list,
but
not
all
of
them
bind
role
from
finding
kubernetes
roles
bound
to
a
specified
service,
account
group
or
user.
We
might
look
at
that.
One
too.
That
was
not
on
my
list,
so.
A
A
Oh,
I
really
like
this
one
rory
I
forgot
about
that
quote
from
ian
good
friend,
my
good
friend
ian
saying
we
are
all
made
of
stars,
but
your
our
back
shouldn't
be
and
I'll
show
you
what
that
means
here
in
a
second,
that's
beautiful
all
right
before
we
get
into
that.
Let's
get
into
this,
so
I
think
this
is
really
really
pretty
fascinating,
so
aws
eks
clusters.
A
Actually
I
wonder
if
this
is
even
related
to
our
back
or
whether
I
should
mention
this
at
all,
but
I
think
it's
fascinating,
so
we're
going
to
mention
it
anyway,
so
this
is
actually
about
authentication
rather
than
authorization.
Our
back
is
generally
about
authorization,
not
authentication,
but
from
an
authentication
perspective
and
a
little
bit
of
crossover
into
authorization.
I
find
this
idea
to
be
fascinating
and
I
wanted
to
share
it
with
you.
A
It's
not
just
aws,
and
so
some
very
creative
people
came
up
with
at
a
jet
stack,
came
up
with
a
way
to
bolt
oidc
on
in
such
a
way
that
you
can
actually
leverage
an
external
oadc
provider,
something
like
dex
or
github
or
whatever
you
want
to
use
that
understands
oadc,
and
then
they
effectively
map
permissions
from
that
from
the
authentication
call
to
to
the
oidc
provider
back
to
a
role
that
has
been
defined
within
the
cluster
natively
leveraging.
Kubernetes
are
back.
A
A
What
just
happened
so
what
they
do
is
they
like
put
an
odc
provider
out
front
like
your
cube
kettle,
configuration
would
authenticate
to
that
right.
Your
only
c
would
it
would
authenticate
to
the
oidc
piece
and
you
get
your
token
or
what
have
you
and
then
your
authentication
call
and
then,
when
you
actually
go
to
interact
with
the
cluster
you're
mapped
back
down
to
a
token
that
the
api
server
can
understand
or
forward
it
to
a
forward
as
an
authenticated
user
to
the
api
server
through
that
through
that
oidc
proxy
right.
A
So
you
authenticate
to
the
proxy
inside
cube.
Kettle
is
the
proxy.
When
you
are
authenticated
through
the
proxy,
it
then
maps
the
call
it
basically
forward
it
like
re-encrypts
the
call
back
with
the
service
account
or
token
of
the
cluster
back
to
that
api
server.
So
your
cube
kettle
configuration
doesn't
talk
to
the
api
server
directly.
It
talks
to
the
reverse
proxy.
A
Oh
sorry,
it
talks
to
the
proxy
and
and
basically
there's
a
mapping
between
folks
that
can
authenticate
and
the
roles
the
built-in
roles
inside
of
kubernetes
are
back,
which
is
super
amazing
to
me
like
yeah.
I
am
rolls
for
service
accounts
kind
of
similar
yep,
and
so
I
thought
this
was
like
super
super
fascinating
and,
if
you're
interested
in
this
kind
of
stuff,
I
think
it's
great
because
it
actually
gives
you
the
ability,
as
they
call
out
the
beginning
of
the
document.
A
They
give
you
the
ability
to
actually
provide
an
authentic
provide
for
authentication
when
you
don't
have
controls
over
the
api
server.
That
would
allow
for
a
native
integration
which
is
fascinating
to
me
anyway.
I
just
wanted
to
share
that
with
you,
because
I
was
like
it
kind
of
blew
my
mind
when
I
saw
it.
So
I
thought,
like
you
know,
y'all
might
like
that
too.
A
A
Ma
is
saying:
hi
we
got
kohaken
chicken
in
or
coquigan
checking
in
from
argentina
good
to
see
you
and
what
else
we
got
all
right.
So
here
we
are
inside
a
book
inside
of
our
cluster.
So
let's
I
covered
this
a
little
bit
in
a
previous
episode
when
I
was
doing
a
groking
kubernetes
session
about
authentication
and
authorization,
but
I'm
going
to
recap
here
a
little
bit
because
I
think
it's
important
to
know
like
what's
built
in
here
so
first,
if
I
do
cube
kettle.
A
Can
I
list
which
is
a
relatively
new
command
came
in,
like
I
think
it
was
1
16
115
somewhere
in
there,
so
with
cube
kettle
auth
can
I
list.
I
can
actually
take
a
look
at
the
authentication
or
the
what
I
what
I,
as
a
authenticated
user
against
kubernetes,
can
do,
and
this
very
first
line
means
that
I
can
do
anything
right.
So
this
is
like
any
verb
any
resource,
any
anything
I
can
I
can.
I
can.
A
I
can
modify,
get
delete
whatever
I
want
to
do
to
any
resource
within
the
entire
cluster,
and
this
is
actually
what
ian
was
referring
to
so
eloquently
by.
We
are
all
made
of
stars,
but
your
our
back
should
not
be.
If
you
see
a
line
like
this,
when
you
see
when
you
run
the
output
of
that
it
means
you're
running
as
effectively
root
within
the
cluster,
you
can
do
anything
you
could
delete
stuff,
you
could
be.
A
Now,
let's
go
ahead
and
create
a
different
role
and
we'll
show
the
difference
between,
like
the
you
know,
phenomenal
cosmic
power
and
some
more
rational
set
of
powers
that
you
might
grant
to
a
person
in
a
name
space
right.
So
let's
do
cube
kiddo
and
for
a
lot
of
this
initial
stuff,
I'm
just
gonna
use
service
accounts
to
create
essay,
ns
admin.
A
A
And
it
looks
very
different
right,
it
looks
very
different
and
we
can
see
that
there's
a
very
diff,
a
very
big
difference,
a
very
big
difference
between
the
previous
one
right.
The
previous
one
has
like
I
don't
know-
maybe
10
12
lines,
including
this
crazy
wild
card
up
here
at
the
top.
But
the
admin
role
is
very
much
more.
Po
is
very
much
more
controlled
right.
A
I
can
see
that
I
have
tons
and
tons
of
permissions
inside
of
the
inside
of
the
default
namespace
right
and
that's
mapping.
This
service
account
the
default
ns
admin
service
account
inside
of
the
default.
Namespace
gives
me
tons
of
permissions,
but
if
I
look
at
some
other
namespace,
I
have
no
permissions
and
that's
what
it
means
to
be
an
admin
within
a
given
namespace.
Now
I
still
have
these
permissions.
I
can
still
do
things
like
self-subject
access
reviews
and
self-subject
rules,
reviews
which
are
tools
which
I'm
actually
leveraging
right
here.
A
A
And
I
could
actually
do
it.
I
know
that
there's
a
way
to
either
modify
the
bash
completion
or
register
the
batch
completion
in
such
a
way
that
it
actually
applies
against
k
as
well
as
cube
kettle,
but
I
have
not
taken
I've
not
dug
into
that,
so
it
hasn't
really
been
worth
it
to
me
all
right.
So
our
first
few
examples
here
are
cube
kettle
auth.
A
Can
I
and
dash
dash
as
and
dash
dash
list.
So
these
are
incredible
tools
built
in
the
box
that
you
can
use
to
understand
what
permissions
and
things
are
but
remember
that
nice,
but
remember
that,
like
when
we
look
at
these
permissions
right
and
we,
when
we
look
at
the
example
of
the
permissions
that
we
have
system
service
account
default
and
this
admin.
A
When
we
look
at
these
permissions,
what
we
are
looking
at
is
an
affected
and
aggregate
effective
permission
set
for
that
particular
user.
Given
that
given
name
in
that
particular
namespace
and
while
that
is
like
you
know,
super
valuable
to
understand,
if
you're
like,
if
you're
just
trying
to
understand
like
what
type
of
permissions
a
given
entity,
might
have
it's
not
going
to
make
it
any
easier
to
understand.
A
Like
some
of
the
other
questions
that
you
might
ask
like,
some
of
the
other
questions
you
might
ask
are
like
what
can?
Can
I
get
a
list
of
users
or
entities
that
have
a
particular
type
of
access
or
a
particular
role,
binding
or
or
or
those
sorts
of
things,
and
that's
where
we
start
getting
into
some
of
the
other?
Yes
exactly
where
we
start
getting
into
some
of
the
other
tools
that
I
thought
do
break
that
down
into
an
easier
way.
A
A
A
So
let's
take
a
look
at
some
of
the
other
tooling
that
is
available
to
us
and
I
think
the
next
thing
we're
going
to
do.
I
have
crew
installed.
I
don't
okay.
Well,
let's
go
get
crew.
Shall
we
next
thing
you
think
we're
going
to
do?
Is
we're
going
to
start
looking
at
some
of
the
client-side
tools
that
we
have
things?
Like
our
back
view,
our
back
look
up
access
matrix
who
can
cube
kettle
studio?
A
A
A
A
A
A
A
A
A
So
this
actually
kind
of
reminds
me
of
some
of
the
stuff
that
we
worked
on
in
tectonic:
wow,
that's
cool,
okay.
This
reminds
me
of
like
the
view
that
we
built
in
into
tectonic
and
also,
I
think,
a
view
that
expo
that
is
used
within
openshift
now
and
what
it
does
is
it
breaks
down
the
roles
so
different
subjects
that
are
associated
with
it
and
they
give
you
the
ability
to
search
and
also
gives
you
the
roles
that
are
associated
with
different
admins
or
different
subjects.
A
So
there's
the
cluster
admin
role,
which
is
the
wild
card,
one
that
we
looked
at
before.
That
was
me
authenticating,
without
any
permissions
or
with
the
built-in
admin
role
that
comes
as
part
of
cuba
dm
and
then
what
I'm
not
seeing
seems
to
be
kind
of
a
bug
here
like
it
doesn't
actually
show
me
the.
A
A
I'm
expecting
to
see
an
output
like
this
right,
we're
in
effectively
it's
sort
of
a
ui
version
of
mapping.
This
particular
permission
set
in
such
a
way
that
we
can
understand
it,
and
I
don't
see
that
in
the
ui
so
or
in
the
yeah
in
the
ui,
that's
trippy
now
before
we
go
too
much
further.
I
also
want
to
kick
up
octane
and
take
a
look
at
what
octant
would
show
us
here.
So
let's
do
that.
A
A
Resources
so
for
this
resource
role
bindings,
we
can
see
create
delete,
delete
collection,
get
list,
patch,
update
and
watch
and
as
we
move
down
the
set
we'll
be
able
to
see,
there's
like
seven
pages
of
these
right.
So
we
can.
We
can
bump
this
up
to
like
100
and
we
can
see
like
all
of
the
permissions
associated
with
the
admin
role
or
with
the
admin
cluster
rule
pretty
awesome,
and
we
can
see
that
there
is
a
resource
called
the
admin
resource
and
then
I'm
actually
curious.
If
we
see
the
role
binding.
A
A
A
A
A
A
A
A
Like
you
know,
when
you
do
a
cube,
kiddo
get
pods
dash
a
you,
get
back
a
list
object,
and
that
represents
like
a
collection
of
things,
and
you
can
actually
make
a
request
to
the
api
server
to
delete
a
list
of
things,
but
because
at
that
point
it
would
not
be
considered
a
list.
It
is
a
collection
right.
So
deleting
a
collection
means
like
delete.
Pods
dash
dash,
all
would
be,
would
be
deleting
a
collection.
A
A
A
A
A
A
A
A
A
And
so,
if
I
wanted
to
see
what
all
of
the
grants
are,
what
all
of
the
roles
associated
with
a
given
user
are
that's
admin
I
can
see.
I
created
both
of
these
in
the
same
default
name
space.
If
I
created
one
I've
given
permission
in
a
different
name
space,
I
would
see
that
differently,
but
I
can
see
the
roles
that
are
associated
with
it
and
then
I
think
they
have
a
dash
of
wide,
which
gives
like
a
little
bit
more
information.
A
This
is
yeah
nice,
so
there's
a
mapping
to
the
source.
How
this
permission
was
granted
right.
So
in
this
initial
output,
it's
just
saying
the
subject
name
is,
and
it's
admin,
the
namespace
is
default
and
the
role
associated
with
it
is
this
role,
and
when
in
dash
o
wide,
you
can
actually
see
the
mapping
about
y
right.
A
A
Some
of
the
permission
sets
that
you
have
an
incredible
tool
for
diagnostic
for
diagnosing
permissions
when
you
when
I,
if
this
were
to
say
yes-
and
I
was
like
okay-
but
why?
Why
are
they
able
to
do
that
right?
Then?
I
could
use
something
like
our
back
lookup
and
the
ns
admin
subject
to
understand
what
permissions
were
being
granted
and
that
would
greatly
narrow
the
field
for
me
in
such
a
way
that
I
could
understand.
A
Okay,
well,
here's
how
we're
granting
scope
we're
granting
permissions
to
a
particular
user
to
that
particular
subject
and
then,
from
there
we
can
figure
out
which
of
those
roles
has
a
more
has
a
more
permissive
permission
than
we
expected
right.
But
it's
not
a
one-stop
shop,
for
example
like
there's
no
way,
as
far
as
I
know,
there's
no
way
for
us
to
say
like
for
this
particular
call.
I
want
to
understand
how
get
pods
was
granted
explicitly.
I
want
to
understand
how
getpods
was
granted
to
the
ns
admin
subject
in
a
given
scope.
A
A
A
A
A
A
Great
question
anyway:
anybody
else
got
something
like
that
was
our
back
look
up,
yeah
in
a
huge
organization,
thousands
of
clusters,
large
number
of
essay
roles
enrolled
by
next
to
multiple
tenants
because
very
challenging.
Yes,
it
does
to
me
to
manage
an
audit
are
back
from
a
single
plane
of
glass.
I
completely
agree
cd
and
that's
actually
one
of
the
definitely
an
interesting
area
to
watch.
A
A
A
This
admin
no
name
space
given
this
implies
cluster
scope,
and
this
is
really
awesome,
because
we
can
see
that
we
have
no
cluster
scope
whatsoever,
which
is
kind
of
a
good
thing
in
my
opinion,
except
that
we
have
these
two
things:
a
cluster
scope,
which
is
fine
right.
This
gives
us
the
ability
to
actually
introspect
our
permissions,
but
let's
try
and
kick
this
against
the
default
namespace
and
now
we
have
a
really
neat
visualization.
A
A
This
permission
is
really
like,
very
similar
to
the
permission
stuff
that
we
saw
from
often
and
from
some
of
the
other
uis
right.
It's
mapping,
basically,
yes
or
no
binary.
Can
you
can
you
do
the
thing
or
not
to
do
the
thing
and
then
breaking
it
across
the
permission?
Set,
let's
create,
update
and
delete
access.
Matrix
does
look
pretty
neat.
I
like
the
visualization
doesn't
handle
like
there's
some
things
that
it
doesn't
quite
do
doesn't
seem.
A
Let's
see
just
intuitively
this
works,
it
doesn't
do
anything
all
right
like
it
doesn't
handle
like
collections
and
it
doesn't
handle.
It
doesn't
look
like
it
handles
things
that
may
be
like
an
extension
to
the
aps.
It's
like
crds
and
stuff,
but
what's
here
already,
is
actually
pretty
neat
so
cool
stuff.
A
A
A
A
So
this
is
closer
in
that
it
can
get
us
to
a
place
where
we
can
say
for
a
given
object
globally.
What
can
who
can?
Who
can
do
what
to
it
right
so,
like
you
know,
we
can
see
like
the
permissions
for
system
masters
or
for
this
particular
group
they've
been
granted
everything
across
everything
and
so
they're
able
to
do
anything
for
the
controller
manager
group.
It's
able
to
list
any
resource
any
config
map,
but
not
able
to
create
them
not
able
to
update
them
or
delete
them.
A
A
A
That's,
I
think
you
know
the
missing
piece
so
that
our
back
lookup
was
actually
providing
was
like.
How
do
we
like
when
you
do
the
dash
o
wide?
You
can
actually
understand
that
how
the
permission
was
granted
or
you
can
understand
the
roles
that
were
used
to
grant
ns
admin
permission
to
things
which
is
actually
pretty
cool.
A
A
If
you're
looking
for
a
way
to
audit
the
permissions
that
have
been
granted,
the
decent
way
to
do
it-
and
this
is
actually
from
liz-
was
awesome-
so
definitely
solving
problems
that
folks
have
that's,
that's
actually
coming
from
aqua
security.
It's
another
good
tool.
This
one
I
wanted
to
play
with
cube
kettle.
Sudo
is
really
really
cool,
and
I
wanted
to
show
this
one
off
a
little
bit,
because
I
think
it
really
highlights
kind
of
a.
I
think,
a
better
permissions
model
for
managing
permissions
within
a
cluster.
A
Who
am
I
oh
yeah?
Who,
who
am?
I
is
interesting
because
it's
going
to
basically
put
there's
no
built-in
mechanism
within
kubernetes
to
describe
who
the
calling
subject
is
right,
and
so
the
only
way
you
can
really
understand
that
is
by
looking
at
the
credential
that
you
have,
that
you
have
access
to
and
understanding
from
that
credential
like
what.
What,
if
there's
some
way
of
understanding
who
you
are
right
so
like?
A
If
you
look
at
the
certificates,
have
been
granted
they'll
be
like
a
subject
alternate
name
or
if
you're
using
a
token
a
service
account
token
and
you
decode
that
token
you
can
see
within
that
token
who's
who
the
user
is.
But
you
can't
like,
but
beyond
that
like
there's
no
way
to
actually
understand
who
you
are
because
cube
kubernetes
doesn't
keep
a
list
of
users,
and
even
in
our
back
we
associ,
we
don't
associate.
We
generally
don't
associate
permissions
with
a
perhaps
with
a
user
we
might
grant.
A
We
might
grant
that
permission
to
a
group
or
to
a
an
identity,
but
there's
not
like
a
record
of
a
user.
We're
not
we're
not
the
first
we're
not
the
first
record
right.
We
are
that
for
service
accounts
and
things
like
that.
But
we're
not
like
the
first
rec,
the
first
record
for
users
and
groups
that
you
might
associate
with
like
an
oidc
entity
or
something
like
that,
and
so
who
am.
A
I
gets
interesting
because
in
some
cases,
there's
not
a
way
for
kubernetes
to
answer
that
question
right:
we're
farming,
authentication
out
to
your
oidc
provider,
we're
farming
authentication
out
to
whatever
you've
got
wired
up
in
the
system,
and
so
we
would
have
to
like
forward
that
request
to
somebody
who
knew
because
it
isn't
going
to
be
kubernetes
understands
whether
you're
authenticated
or
not,
not
necessarily
who
you
were
kind
of
interesting
stuff.
Yeah.
A
I
want
to
talk
about
our
back
manager,
but
let's
talk
about
this
first
so
and
I'm
not
going
to
spend
a
whole
lot
of
time
on
it,
because
it's
already
2
12
and
we're
running
a
little
bit
over.
But
I
wanted
to
kind
of
talk
about
this
first
and
then
we'll
talk
about
the
other
two
and
then
that'll
be
our
show
for
the
day.
A
So
this
is
a
fascinating
pattern
and
I've
spent
a
lot
of
time
talking
to
customers
about
this,
because
I
do
think
it
is
actually
really
a
great
improvement
if
we
think
about
linux
as
a
system.
The
way
that
we
grant
users
permissions
in
linux
is
a
little
different
than
we
grant
permissions
to
things
like
within
a
cluster
right.
You
wouldn't
necessarily
operate
your
linux
laptop
or
whatever
as
root
you
would
probably,
or
even
your
mac
right.
You
wouldn't
operate
as
root
all
the
time.
I
hope.
A
Instead,
you
would
operate
as
a
regular
user
and
you
would
grant
maybe
sudo
access
to
a
user
so
that
they
could
make
like
big
changes.
Install
software
reboot,
the
machine
do
kind
of
do
stuff
like
that,
but
you
wouldn't,
but,
but
that
gives
you
like
a
separation
of
concerns,
right
you're,
going
to
allow
the
regular
user
to
impersonate
root
or
to
operate
a
command
as
root
which
gives
which
gives
you
the
ability
to
elevate
their
permissions
for
specific
use
cases
or
for
specific
reasons,
and
this
is
a
great
pattern
like
it
really.
A
I
think
greatly
simplifies
the
way
that
we
think
about
our
back
within
kubernetes
right
in
that
we
can
provide,
for
example,
a
group
we
could
provide
a
group
and
then
leveraging
leveraging
that
impersonalization
piece
that
we
talked
about
before
we
could
provide
a.
We
could
create
a
new
group.
We
could
associate
with
that
group
some
higher
permission,
and
then
we
could
allow
impersonalization
for
that
particular
group
from
a
given
user
set,
and
so
by
default,
when
a
user
is
added
to
a
kubernetes
cluster,
you
can
grant
them
like
a
read-only
role.
A
All
users
in
kubernetes
clusters
have
read-only.
This
is
like
a
way
that
you
might
model
this
right.
So
if
you
are
a
part
of
an
ldap
group
in
the
enterprise
that
gives
you
access
to
kubernetes
clusters,
you'd
be
able
to
grab
a
credential
you'd,
be
able
to
authenticate
to
kubernetes,
and
you
would
only
have
read-only
view
of
things.
A
But
then,
if
you
wanted
to
elevate
your
permissions,
then
we
would
want
to
be
able
to
like
give
you
the
ability
to
impersonate
a
different
group
that
has
maybe
perhaps
those
other
elevated
permissions,
and
that
gives
us
the
ability
to
grant
you
more
permissions
based
on
the
access
that
you
have
right.
So,
like
a
sudo
access,
a
sudo
level
access
what
this
does.
What
falls
out
of
this
is
two
really
cool
things.
A
First,
it
greatly
simplifies
associating
permissions,
because
you're
really
only
creating
different
roles
or
different
groups
that
have
access
to
given
a
given
subset
of
permissions
and
then
you're
mapping
those
roles
down
to
users
that
can
impersonate
them
and
second,
it
greatly
reduces
the
noise
that
you're
watching
for
in
the
audit
log
right,
if
you're,
using
the
sudo
access,
if
you're,
using
the
the
sudo
access
model.
Here.
A
What
this
allows
us
to
do
is
say
that
is
to
watch
for
events
that
include
a
key
phrase:
impersonated
user
right,
and
so
we
still
understand
who
made
the
you
who
made
the
call
who
they
impersonated
and
what
the
actual
account
and
what
the
actual
call
was.
But
it
greatly
gives
it
gives
us
the
ability
to
greatly
reduce
the
review.
A
A
It's
actually
really
really
cool,
so
I
think
it's,
I
think
it's
an
awesome
model
and
you
can
see
kind
of
like
how
this
would
map
down
right,
the
impersonator
cluster
role
and
what
types
of
impersonalization
it
can
do.
It's
really
pretty
neat.
It's
already
216,
though,
so
I'm
not
going
to
demonstrate
that
today,
but
I
do
think
it's
worth
considering
if
you're
thinking
about
how
you
grant
permissions
to
clusters
or
to
multiple
clusters
and
those
sorts
of
things.
This
is
a
great
model
for
that.
A
But
what
happens
is
that
you
have
a
way
of
defining
policy
and
such
and
access
to
given
roles.
You
have
the
ability
to
configure
our
back
declaratively
and
then
to
have
an
operator
within
the
cluster
implement
that
inside
the
cluster
right,
and
so
in
this
way
you
can
be
very
declarative
about
the
permissions
that
you
grant,
rather
than
actually
having
to
be
imperative
about
the
permissions
you
grant
now.
A
Unfortunately,
if
I'm
using
cube
kettle
to
configure
rbac,
that
is
very
imperative
right
in
that,
unlike
a
deployment
where
I
might
like
say
here
is
the
manifest
associated
with
a
given
deployment.
I
want
kubernetes
to
actually
take
the
impetus
to
go
ahead
and
make
that
real,
and
if
I
wanted
to
change
what
the
declared
state
or
what
the
desired
state
is,
I
could
just
modify
or
create
a
new
deployment
and
it
will
move
toward
that
new
modified
state
with
our
back.
That's
not
the
case
with
our
back.
There
are
a
lot
of
sharp
edges.
A
A
A
We
don't
know
exactly
what
that
desired.
State
is
right.
If
you
were
to
change,
if
you
were
to,
you,
know,
define
a
role
binding
or
to
find
a
role
and
then
want
to
modify
that
role
and
asso
and
change
the
actually
in
roles
it
works.
If
you
wanted
to
modify
role,
binding
and
change
it
and
then
apply
it
again,
then
what
you're
going
to
get
back
from
kubernetes
is
that
we
can't
apply
it
because
it's
already
been
defined.
A
A
Do
you
want
this
to
be
additive
right,
and
this
is
basically
what
cubekittle
auth
reconcile
will
allow
us
to
do
so,
it's
sort
of
like
apply
for
things
like
our
back,
but
gives
us
a
little
bit
more
a
little
bit
more
control
over
what
happens,
whether
it's
an
additive
or
whether
it's
subtractive
like
when
we
make
a
change
and
like
what
sorts
of
things
can
be
done.
There's
great
dry
run
capability
here,
and
this
is
a
kind
of
a
good
way
of
actually
framing
the
subject
of
how
how
these
permissions
and
things
work.
A
What
our
back
manager
does
is
it
takes
it
a
step
forward
right
with
our
back
manager.
We're
saying:
look
we're
going
to
define
what
the
desired
state
is
and
we're
going
to
define
that
in
this
idea
of
a
crd
and
we're
going
to
derive
from
that
custom
resource
definition,
what
the
actual
configuration
should
look
like
and
apply
it
over
time,
basically
moving
the
level
of
control
over
how
these
things
are
defined.
A
One
level
up
right,
so
you
have
a
place
to
actually
put
that
source
of
truth
and
implement
it,
and
then
the
rbac
manager
operator
will
enforce
it
and
will
handle
any
conflicts
based
on
the
source
of
truth
that
it
learned
from
that
custom
resource
definition,
which
is
a
killer
feature
and
again,
because
now
we
are
in
a
declarative
state.
We
can
actually
define
those
crds
in
git
and
apply
them
to
our
clusters
as
we
move
forward,
and
it's
very,
very
a
very
cool
thing
to
think
about
and
how
this
works.
A
So
if
you
wanted
to
explore
that
one
or
if
you
want
to
see
me
explore
that
one,
I
might
do
that
one
in
our
next
session,
but
I
feel
like
it
will
take
us
more
time
than
we
have
today.
It's
already
almost
2
30,
but
I
do
think
it
would
be
really
fun
to
kind
of
model
this,
and
if
I
were
to
model
this,
I
think
I'd
probably
want
to
get
somebody
from
reactive,
waps,
perhaps
like
involved,
so
that
they
could
answer
questions
so
that
might
be
our
next,
our
next
co-presentation
anyway.
A
Let
me
flip
back
to
face
here.
That's
our
session.
I
hope
that
was
helpful
and
fun
for
y'all.
I
hope
you
like
my
new
background.
Let's
see
so
I
would
like
I
would
look
forward
to
a
single
tool.
Both
declarative,
get
ops
and
centralized
audit
tool
with
intelligence
to
identify
potential
yeah.
That
is
a
neat
one
and
we're
working
on
some
stuff,
like
that
kind
of,
like
here
at
vmware,
to
know
that
we're
not
the
only
ones
doing
it.
So
it's
a
real
problem
and
I
think
people
are
trying
to
solve
it.