►
From YouTube: Effective RBAC - Jordan Liggitt, Red Hat
Description
Effective RBAC - Jordan Liggitt, Red Hat
The v1 release of role-based access control (RBAC) in Kubernetes 1.8 provides a flexible way to ensure users and applications have proper access to the Kubernetes API. This talk is for administrators who want to secure their clusters, and for anyone who wants their applications to integrate easily in RBAC-enabled environments. This talk will give an overview of the RBAC design and API, explain how to set up an RBAC-enabled cluster, demonstrate applying policies to existing applications, show how to create custom roles to distribute with applications, and answer the question "Can Bob educate dolphins?"
About Jordan Liggitt
Jordan Liggitt is a principal software engineer at Red Hat, and helps lead Kubernetes authentication and authorization efforts.
Join us for KubeCon + CloudNativeCon in Barcelona May 20 - 23, Shanghai June 24 - 26, and San Diego November 18 - 21! Learn more at https://kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy and all of the other CNCF-hosted projects.
A
All
right
well
welcome.
My
name
is
Jordan
Liggett
I
work
at
Red,
Hat,
I,
work
on
kubernetes
and
on
openshift
and
I'm
part
of
the
team
that
helps
lead
the
kubernetes
authentication
and
authorization
efforts,
and
today,
I'm
gonna
be
talking
about
how
you
can
use
our
back
more
effectively
to
secure
your
API
servers
and
your
kubernetes
api
s.
So
what
is
our
back?
Our
back
stands
for
role
based
access
control.
A
It's
one
of
the
authorization
modes
that
you
can
use
with
your
communities,
API
server
and
it's
job
is
to
answer
the
question
for
every
request
that
comes
into
the
server
can
the
subject
that
is
submitting
this
request
to
perform
this
verb
on
this
object,
but
that's
a
little
dry
and
it's
the
last
session
of
the
last
day
and
we're
all
fried
so
I
figured.
Maybe
we'd
start
with
that.
Instead,
so
instead
of
deployments
or
pods
or
whatever
I'm
gonna
walk
you
through
sort
of
conceptually
how
the
our
back
design
is
laid
out.
A
A
His
permissions
are
to
help
the
captain
and
train
the
crew,
and
so,
if
we're
thinking
in
terms
of
roles,
we
can
say
his
role
is
first
mate
and
the
role
is
just
a
named
set
of
permissions,
and
so
the
first
mate
role
includes
the
permissions
of
helping
the
captain
and
training
the
crew,
and
that
role
is
granted
at
a
particular
location.
So
he
has
that
role
on
the
green
ship.
Now
there
are
lots
of
ships.
Every
ship
has
a
first
mate.
A
It
makes
sense
for
the
permissions
to
be
uniform
across
the
ships
right,
so
we're
gonna
define
the
first
mate
role
globally.
It
means
the
same
thing
across
all
the
ships,
but
we
grant
it
locally.
So
Bob
can
only
do
first
mate
things
on
the
green
ship,
alright
defined
globally,
granted
locally.
Now
training
the
crew
got
boring
so
one
day
Bob
asked
if
he
could
also
Train
dolphins
and
his
captain
thought.
That
was
a
little
weird,
but
you.
A
So
he
said
all
right:
Bob
I'm
gonna
give
you,
in
addition
to
your
first
mate
role,
the
role
of
dolphin
trainer
and
you
are
allowed
to
educate
dolphins.
But,
let's
be
honest,
we're
not
going
to
use
this
role
on
any
other
ships,
so
we're
just
going
to
define
this
role
locally.
We're
gonna
keep
this
one
to
ourselves
and
because
it's
defined
locally,
it's
also
only
granted
locally.
So
now
bob
has
two
roles,
dolphin
trainer
first
mate,
and
he
can
do
anything
that
either
of
those
roles
allows.
A
A
Thank
you,
and
so
this
is
a
permission
that
is
dealing
with
something
global.
The
Armada
is
a
global
thing
and
so
the
role
that
allows
it
has
to
be
global
and
it
also
has
to
be
granted
globally.
So
these
are
sort
of
the
the
ways
you
can
think
about
defining
roles
globally
or
locally
and
then
granting
them
globally
or
locally.
So
enough
about
Bob,
let's
look
at
an
actual
API
request
and
the
types
of
questions
that
it
would
ask
of
the
authorization
layer.
So
a
request
comes
into
the
API
server.
A
It's
got
an
HTTP
method
and
a
URL
and
some
headers
and
some
other
stuff,
the
body
stuff.
But
the
first
thing
we
do
is
parse
out
request,
attributes
from
the
verb,
the
method
and
the
the
URL.
So
you
can
see
from
this
the
post
method,
maps
to
the
create
verb
and
we
extract
the
apps
API
group,
the
namespace
and
the
resource,
and
so
this
set
of
request
attributes
becomes
the
input
to
the
authorizer.
A
The
next
step
is
authentication,
so
the
authentication
layer
looks
at
the
request
and
determines
who
is
making
this
request
and
in
this
case
there's
a
bearer
token,
and
so
the
authentication
is
going
to
look
at
that
and
determine
okay.
This
request
is
coming
from
Bob,
and
so
the
request,
attributes
and
the
user
information
become
the
input
to
the
authorizer,
and
so
for
this
request,
the
question
we're
going
to
ask
is:
can
Bob
and
the
group
system
authenticated,
create
apps
deployments
in
this
namespace?
A
So
let's
look
at
how
we
would
set
up
our
back
to
allow
that
this
is
basically
what
we
want.
We
want
Bob,
okay,
it
Bob's
back.
We
want
Bob
to
be
a
deployer
in
namespace
and
s1,
and
we
want
that
to
mean
that
he
can
create
deployments
in
the
apps
API
group.
So
remember
our
roles,
we're
gonna,
set
up
a
deployer
role
and
that
deployer
role
is
going
to
map
to
this
one
permission
create
apps
deployments,
and
then
we
want
to
grant
that
inside
the
NS
one
namespace.
A
So
our
back
uses
API
objects
to
define
this
policy.
So,
first
we're
going
to
create
a
role
object,
and
this
looks
like
every
other
kubernetes
api
object.
You've
seen
it
lives
in
the
our
back
api
group,
which
is
v1
as
of
kubernetes
one
eight.
It
has
a
name
we're
just
going
to
call
it
deployer
and
we're
gonna
create
it
inside
the
NS
one
namespace,
because
that's
where
we
want
to
grant
these
permissions
and
remember,
we
said
that
a
role
is
just
a
named
list
of
permissions.
A
Well,
an
are
back
role,
has
a
list
of
rules
and
each
rule
has
the
opportunity
to
match
the
attributes
on
an
incoming
request,
and
so
this
role
has
one
rule
and
it
matches
the
attributes
on
the
request
that
we
saw
the
create
verb
is
included
in
this
list.
The
apps
API
group
is
included
in
this
list
and
the
deployments
resource
is
included
in
this
list,
and
so
we
can
pass
this
to
keep
control
create
and
we
have
now
defined
a
role
inside
our
namespace
with
the
permissions
we
want.
A
So
the
next
step
is
to
grant
this
role
to
Bob,
and
we
do
that
by
binding
the
role
to
Bob.
So
we
create
a
role
binding
object,
no
surprise
in
the
are
back
API
group.
We
are
also
creating
it
inside
the
ns1
namespace
and
the
location
of
the
role
binding
determines
the
location
of
the
permissions.
So
if
we
created
this
in
a
different
namespace,
we
would
be
trying
to
grant
permissions
in
a
different
namespace,
but
this
is
the
namespace
we're
in.
So
that's
the
first,
the
first
important
thing
about
a
binding.
A
Where
is
it
a
second
important
thing?
What
role
is
it
referencing?
So
this
is
going
to
reference
the
role
we
just
defined
and
the
third
important
thing
who
is
it
binding
the
role
to,
and
so
you
can
reference
one
or
more
subjects.
In
this
case,
it's
just
one,
a
subject
can
be
a
user,
a
group
or
a
service
account,
in
this
case
we're
binding
to
a
user
with
the
name
Bob
and
that's
going
to
match
the
user
info
coming
from
the
authentication
layer.
A
So
once
we
create
both
of
these
objects,
we
have
defined
a
local
role
inside
the
ns1
namespace
and
then
we've
granted
that
role
also
inside
the
ns1
namespace
to
Bob.
So
once
we
do,
this,
Bob
will
be
authorized
to
submit
that
API
request
and
just
like
it
makes
sense
to
reuse
roles
between
name
spaces.
Creating
deployments
is
something
that
would
be
useful
to
be
able
to
grant
in
other
namespaces,
and
it
would
be
a
pain
to
have
to
create
a
copy
of
this
in
every
namespace.
A
We
can
actually
define
this
globally
by
changing
the
kind
from
role
to
cluster
role
and
you
all
that
changes
is
the
kind
and
then
the
kind
inside
the
role
ref.
So
now
we
are
defining
the
permissions
globally,
but
still
granting
them
locally.
If
Alice
was
in
the
ns2
namespace,
we
could
create
an
almost
identical
role,
binding
inside
the
ns2
namespace
referencing,
this
cluster
level
role
and
that
lets
us
reuse
permissions
and
just
maintain
policy
in
one
place,
but
then
granted
in
lots
of
other
places
and
then.
A
A
A
So
that's
the
definition
side
on
the
granting
side
to
objects.
You
can
grant
with
a
cluster
role
binding
to
grant
permissions
across
the
whole
cluster.
You
would
do
this
to
grant
permissions
to
cluster
scoped
resources
like
nodes,
persistent
volumes
or,
if
you
wanted
to
give
cluster
wide
access
and
you
can
grant
with
a
role
binding
object
in
a
particular
namespace.
A
So
that's
the
overview
of
the
rback
api,
two
ways
to
define
permissions
and
two
ways
to
grant
them
depending
on
the
Scopes.
You
want
so
next
I'm
going
to
talk
about
how
you
go
about
setting
up
an
AR
back
enabled
cluster.
So
first
the
easy
way.
This
is
a
one
step
process,
use
a
distribution
or
installer
that
does
it
for
you.
This
is
becoming
more
and
more
realistic.
Actually,
most
major
installers
have
at
least
an
option
for
it,
and
many
do
it
by
default,
so
Cuba
Cuba
atom
distributions
like
OpenShift
gke
tectonic.
A
A
First,
you
tell
the
API
server
start
with
our
back
authorization
and
congratulations.
You're
running
an
are
back
enable
cluster,
but
there's
a
little
more
to
it
than
that.
So
when
you
start
an
API
server
this
way
on
start,
it
automatically
creates
a
set
of
default
roles
and
role
bindings.
Now
these
aren't
magic.
You
can
actually
go
look
in
the
the
github
repo
and
the
the
definitions
are
there.
You
can
look
at
them,
create
them
in
yourself.
You
can
edit
them.
A
The
thing
that
is
helpful
is
that
these
are
Auto
maintained,
so
on
every
start,
the
API
server
will
recreate
these
or
update
them,
adding
in
new
permissions.
So
this
lets
us
go
release
to
release
and
let
these
automatic
roles
continue
working.
You
can
opt
out
of
the
reconciliation
if
you
want,
but
it's
very
handy,
there's
a
set
of
default
bindings
to
system
prefixed
user
names.
So
the
thinking
is,
there's
a
chicken-and-egg
problem
with
any
authorization
system.
A
If
you
start
it
up
and
it
is
denied
by
default,
then
how
can
the
first
user
grant
permission
to
anyone,
and
so
what
this
does
is
pin
the
default
roles
to
a
set
of
system,
prefixed
usernames,
which
lets
you
provision
those
components
to
use
those
usernames
and
they
automatically
have
the
right
roles.
If
you
don't
want
to
use
those
usernames,
you
don't
have
to.
You
can
use
your
own
and
set
up
bindings
yourself,
but
this
makes
the
setup
a
lot
easier
and
we
found
to
work
well
with
most
of
the
installed
methods.
A
The
one
the
one
break
glass
in
case
of
emergency
type
of
permission
you
would
need,
would
be
a
bootstrap
super
user,
and
so,
when
you
are
setting
up
your
cluster,
you
would
want
a
credential
with
the
system
masters
group.
This
is
the
group
that
is
allowed
to
do
anything
to
the
API
server
and
so
typical
use
is
to
set
up
with
this
delegate
more
scoped
permissions
to
other
users
for
normal
day-to-day
use
and
then
put
this
in
a
very
safe
place
and
don't
use
it
for
daily
use.
A
The
second
level
is
the
control,
plane,
components,
cube,
scheduler,
cube
controller
manager
cube
proxy.
If
you
set
these
up
to
use
these
system
prefixed
user
names,
they
will
have
our
back
roles
that
allow
the
thing
is
required
by
those
components.
One
note
with
the
cube
controller
manager,
the
permissions
required
by
the
controller
manager
give
it
enough
permission
to
start
up
all
the
individual
control
loops
that
it
manages.
There
are
actually
individual
roles
for
each
control.
Loop
and
passing
this
flag
to
the
controller
manager
will
tell
it
to
use
service
accounts
for
those
for
those
loops.
A
That's
recommended
so
that
or
exploit
in
one
loop
doesn't
allow
it
to
escape
and
accidentally
start
messing
with
completely
unrelated
resources.
The
goal
is
least
privilege
principle.
Each
control
loop
only
has
the
power
that
it
requires.
The
other
nice
thing
about
this
is
eventually
it
could.
Let
you
run
those
control,
loops,
standalone
in
a
pod,
completely
isolated
and
just
run
a
pod
with
that
control
there
parole
and
it
would
be
scoped
to
just
the
permissions
it
required.
A
That
brings
us
to
cubelets.
So
cubelets
are
interesting.
Originally,
they
started
with
our
back
to
find
role,
but
as
we
as
we
started
thinking
about
what
it
looked
like
to
enforce
a
node
isolation,
our
back
didn't
seem
like
a
great
fit,
so
we
actually
have
a
dedicated
authorizer
for
nodes,
and
the
recommendation
is
to
use
that
in
combination
with
our
back.
So
you
can
start
up
the
API
server,
telling
it
to
use
the
node
authorizer
and
the
our
back
authorizer.
A
And
if
you
give
your
cubelets
well-shaped
credentials,
they
will
be
given
permission
just
to
their
own
pods
and
their
own
secrets
and
their
own
persistent
volumes
and
not
allowed
to
mess
with
other
nodes,
pods
and
secrets.
That
is
what's
recommended
that
interacts
well
with
the
node
TLS
bootstrapping,
but
you
can
provision
credentials
for
your
nodes
manually
or
some
other
process
if
you
want
to
as
long
as
you
make
them
well-formed
with
this
username
in
this
group,
all
right.
A
So
at
this
point
you
have
your
bootstrap
superuser
that
can
set
up
anything
they
need
to
set
up.
You
have
your
control,
plane,
members
working,
you
have
your
cubelets
working.
The
next
step
is
usually
add-ons
write,
Network,
plugins
DNS,
the
random
things
that
you
need
to
run.
Metrics
logging,
whatever
you
are
running
that
is
accessing
the
API.
What
do
you
do
about
that?
Well,
fortunately,
many
already
include
our
back
role:
definitions
in
their
manifests.
A
That's
that's
really
great
to
see
it
makes
it
easy
to
plug
these
into
secured
clusters
and
even
if
you're,
not
using
our
back,
it's
actually
very
handy
to
have
them
sort
of
enumerate
the
API
permissions
that
they
require
for
those
that
don't
you
have
a
few
options.
There
are
some
predefined
roles.
These
are,
these
are
pretty
broadly
scoped.
A
There's
the
cluster
admin
role,
which
is
a
super
user
role,
can
do
anything
to
anything.
Then
we
have
admin
edit
and
view
roles,
and
these
are
kind
of
three
layer.
Three
levels
of
permissions
that
are
designed
to
be
granted
within
a
namespace
so
view
is
read-only
access
to
everything
except
secrets,
because
those
can
be
escalating.
A
Edit
gives
you
write
access
to
all
the
workload
api's
things
that
a
normal
app
developer
would
need
to
create
so
pods
deployments
replica
sets
daemon
sets,
although
all
the
workload
types
of
things
services
stuff
like
that
admin
includes
everything
edit
does
and
also
includes
permission
to
set
up
roles
and
role
bindings
in
the
namespace.
So
then
you
start
getting
into
access
management,
and
so,
if
you're,
looking
at
what
an
addon
needs,
maybe
you
can
identify
well,
this
add-on
would
fit
within
the
view
role.
A
A
So
the
question
was:
if
you're
not
using
our
back
but
a
manifest,
has
our
back
objects?
Can
you
still
deploy
it?
The
answer
is
yes.
Probably
the
API
is
independent
of
the
authorizer.
There
are
some
edge
cases
around
escalation
detection,
where
we
don't
allow
creating
objects
that
have
permissions
that
you
don't
already
have,
and
so
there
are
some
tricky
interactions
there.
If
you're
the
super
user,
if
you're
using
that
bootstrap
super
user.
Yes,
you
can
continue
to
create
anything.
If
you
are
not
the
super
user,
it
gets
a
little
bit
more
complicated.
A
A
In
the
namespace
is
still
using
the
default
service
account
you
can
grant
to
that.
What
you
typically
end
up
with
there
is
a
lot
of
permissions
glommed
onto
the
default
service
account
and
it
gets
hard
to
differentiate
one
app
from
another.
It's
also
not
great
from
an
auditing
perspective.
If
you're
trying
to
figure
out
who
did
this
thing
and
you've
got
16
applications
all
running
his
little
ball
service
account,
it
gets
really
tricky
to
know.
You
know
what
what
caused
the
problem
here.
A
You
can
even
grant
a
permission
to
all
service
accounts
in
that
namespace,
so
you
see
the
we're
addressing
the
group
system
service
accounts
and
then
the
name
of
the
namespace.
This
is
great.
If
you're
deploying
several
related
things
in
their
own
namespace,
you
can
grant
to
all
of
them
at
once
and
then
we've
all
done.
It
sometimes
that's
necessary.
A
A
A
This
describes
the
last
two
years
of
my
life
actually,
and
it
wasn't
great
so
I
built
this
in
kubernetes
1:8.
There
are
structured
audit
logs
which
mean
that
we
can
very
easily
take
a
look
at
who
is
making
requests
and
all
the
details
about
the
requests,
all
the
same
attributes
that
feed
into
the
authorizer
are
available
via
the
audit
logs
and
all
the
user
info
that
feeds
into
the
authorizer
available
via
the
audit
logs,
and
so
this
is
actually
a
really
great
way
to
build
policy
automatically.
A
So
the
first
thing
you
can
do
is
enable
audit
logs
run
the
application
through
its
paces.
Have
it
do
everything
it's
going
to
do
with
a
service
account
that
is
specific
to
that
application
and
then
process
the
audit
logs
and
generate
a
role
that
encompasses
what
it
did
and
so
I
actually
built
this
tool.
So
I
call
this
audit
to
our
back
I'm
from
Red
Hat,
so
it's
shamelessly
stolen
from
audit
to
allow
for
st
lennox,
and
I
want
to
show
you
a
video
demo.
B
A
We
go
okay,
so
when
I
list
pods
I
can
see
that
my
API
request
showed
up
in
the
audit
logs
yeah
I'm
gonna
have
to
come
out
here
and
watch
that's
funny.
Alright,
so
I'm
gonna
create
a
job
here
and
while
it's
getting
going,
let's
look
at
what
the
job
is
gonna
do.
This
is
just
a
bash
script
that
uses
cube
control
to
try
to
use
of
things.
So
it's
gonna
read
a
config
map,
try
to
delete
and
update
it.
A
Look
at
pods
and
a
couple
namespaces
look
at
nodes
and
then
run
and
clean
up
a
couple
sub
jobs,
and
so,
if
I
look
at
the
logs
for
this
thing,
it's
actually
stuck
on
first
step,
which
makes
sense
because
it's
running
as
a
service
account
which
has
zero
permissions.
So
let's
use
audit
to
our
back
to
set
up
a
role.
That's
going
to
let
this
job
do
what
it
needs
to
do.
So.
The
first
thing
we
can
do
is
run
audit
to
our
back
feeding
it.
A
A
So
what
I'm
gonna
do
now
is
set
up
a
loop
that
just
keeps
looking
at
the
log
and
generating
a
role
and
applying
it
and
I'm
actually
gonna
dump
it
out
to
this
yamo
file.
So
we
can
see
what's
going
on,
but
that's
just
for
our
benefit
and
before
I
start
that
I'm
gonna
set
up
a
diff,
so
we
can
see
changes
as
they
come
in
all
right.
So
now
we're
gonna
kick
off
the
apply
loop
and
start
taking
a
look
and
immediately
we
start
see,
create
permissions
come
in.
A
We
see,
delete
and
update
permissions
come
in
now.
Let
me
zoom
out,
so
you
can
see
what's
going
on
or
not
see,
what's
going
on,
it's
dealing
with
batch
jobs,
so
it's
different
API
groups,
it's
moving
and
collapsing
permissions.
So
if
you
start
dealing
with
things
with
multiple
names,
is
it
going
to
combine
those
into
sort
of
the
minimal
rule
that
covers
them?
It's
looking
at
pod
logs,
so
it's
dealing
with
sub
resources
and
we're
just
gonna.
A
Let
this
thing
run
and
by
the
end
we
have
the
role
that
covers
it
and
it
actually
will
differentiate
custom
roles
and
roles.
So
it
will
give
you
cluster
permissions
and
namespace
permissions
and
all
the
bindings
that
are
required
to
set
that
up
and
if
we
wait
for
a
couple
seconds,
I
think
it's
about
done
and.
A
It
was
pre-recorded,
but
there
was
no
editing.
So
this
is
the
kind
of
thing
that
I
would
spend
a
couple
hours
building
by
hand,
and
now
it
gives
us
immediately
something
that
may
require
a
little
bit
of
fix-up.
You
might
look
at
that
and
say:
oh
well,
actually,
I
want
this
to
be
a
little
broader,
a
little
narrower,
but
it
gets
you
like
97%
of
the
way
there
so
just
to
talk
about
a
few
of
the
things
that
this
is
doing.
A
It
does
some
smart
verb
expansion.
So
if
you
list
pods
at
that
point,
authorization
was
you've
already
seen
the
content
of
all
of
those
objects.
So
if
you
list-
and
we
allow
that,
we
also
let
you
get
and
watch
because
that's
not
exposing
any
more
information,
if
you
update
something,
we
give
you
patch
and
update
so
the
kinds
of
things
that
encourage
best
practices
so
that
in
a
month
when
you
figure
out
I'm
getting
a
lot
of
conflicts,
I
should
start
using
patch.
A
You
don't
have
to
come
back
and
like
update
your
role,
you
could
update
we're
gonna,
let
you
patch
as
well.
It
does
multi
name
inference.
So
if
you
access
a
pod
named
a
and
a
pod
named
B,
it
can
collapse
that
and
say
you
can
actually
access
a
pod
with
any
name.
That's
optional!
You
don't
have
to
do
that.
A
But
if
you're
trying
to
infer
roles
from
usage
patterns
letting
exercising
the
app
with
a
few
example
names
across
a
few
example,
namespaces
kind
of
indicates
I'm
going
to
be
working
with
arbitrarily
named
objects,
same
thing
for
a
multi
namespace.
If
you
do
something
to
pods
and
namespace
a
and
you
do
the
same
thing
to
pods
and
name
space,
be
it
actually
moves
that
permission
up
to
a
cluster
role
and
says
granted
across
namespaces,
because
you're
no
longer
constrained
to
a
single
namespace.
Again,
it's
optional.
You
don't
have
to
do
those
expansions.
A
If
you
don't
want
to
so
a
couple
ways
you
could
use
this.
One
is
the
way
we
saw
here
which
is
denied
by
default
watch.
The
audit
log
then
apply
and
allow
that
works
great.
That's
the
most
secure
thing
to
do,
depending
on
the
application
characteristics,
your
your
application
might
be
crashed
looping.
Every
time
it's
denied,
so
I
wrote
mine
to
be
tolerant.
Of
that
and
just
kind
of
keep
retrying,
but
that
might
not
work
well
for
your
application.
A
An
alternative
is
to
run
in
a
test
environment
with
CI
tests
that
just
exercise
everything
your
app
is
going
to
do
and
give
it
full
permission
in
that
environment
and
then,
after
the
fact,
post
process
that
audit
log
build
roles
from
it
and
then
compare
that
to
the
committed
roles.
For
that
app
and
say:
oh,
you
know
what
the
current
build
started
using
more
permissions,
so
I'm
gonna
fail
that
CI
build
and
open
a
pull
request.
Saying:
hey
new
permissions
make
sure
these
are
okay,
so
there
are
lots
of
other
ways
you
could
use.
A
So
one
of
the
one
of
the
things
that
we're
seeing
as
the
extension
capabilities
around
kubernetes
grow
it's
easier
for
people
to
create
custom
resources,
add
in
their
own
API
servers
serving
their
own
API
types.
The
question
is:
how
does
this
interact
with
policy
when
I,
when
I
tell
kubernetes,
hey
I,
have
a
custom
resource?
A
You
do
the
same
thing.
You
delete
your
definition
and
your
role
and
those
permissions
get
pulled
out.
So
this
is
a
really
powerful
way
to
contribute
without
having
to
manage
those
admin.
Edit
view
roles
yourself,
all
right,
I
think
we
have
about
five
minutes
for
questions.
Have
you
answer
any
questions
if
we
run
over
I'll
yell?
No,
this
is
the
last
session.
What
am
I
what
I
was
talking
about?
B
A
So
the
question
was:
can
you
mix
namespace
and
non
namespace
permissions
in
a
single
cluster
role,
and
the
answer
is
no.
You
would
need
two
definitions,
because
if
you
grant
the
first
one
globally
you're
granting
all
the
permissions
defined
in
it
globally.
So
if
you
said,
I
want
to
edit
and
delete
pods
and
you
grant
that
globally
they
get
all
of
those
permissions
globally.
So
you
need
to
to
role
objects
for
that.
B
A
A
A
So
the
question
was:
are
there
special
permissions
for
auto-scaling?
So
the
horizontal
pod
autoscaler
resources
are
their
own
resource,
and
so
you
can
permission
those
individually.
You
could
allow
or
disallow
a
user
from
changing
horizontal
pod,
autoscaler
resources,
the
HPA
controller
uses
scale,
sub
resources
on
deployments
and
replica
sets,
and
so
we
didn't
really
talk
about
sub
resources,
but
some
resources
are
a
way
of
giving
you
a
different
end
point
for
restricted
subsets
of
operations,
so
HP
a
controller
will
work
with
scale,
sub
resources
and
typically
only
it
is
allowed
to
address
those
controllers.
A
Also
update
status,
sub
resources
and
the
API
server
can
permission
those
differently
and
only
pay
attention
to
status
content
when
it
comes
in
via
a
status,
sub
resource
I'm,
not
sure.
If
that
answers
the
question,
but
the
two,
the
two
points
of
permissioning
are
different
resources
like
HPA
and
then
different
sub
resources.
A
A
Okay,
so
the
question
was
our
audit
logs
too
verbose
to
run
in
production,
and
the
answer
is,
it
depends,
there's
actually
a
really
expressive
policy
for
describing
what
you
want
to
show
up
and
awed
it.
So
you
can
scope
events
to
a
particular
user
or
a
particular
resource,
or
a
particular
set
of
resources
and
define
what
verbosity
you
want
for
each
of
those.
So
you
could
say:
I
only
want
metadata
for
this
user
or
I
only
want
metadata
for
these
resources
or
I.
Want
you
to
ignore.
B
A
A
B
A
No,
so
if
you
were
paying
attention
all
of
the
attributes
that
go
to
the
authorizer
come
from
the
URL
and
on
a
create
api
request,
the
name
is
not
in
the
URL,
so
the
name
is
not
available
for
the
create
permission.
What
we
typically
have
seen
done
is
having
a
central
sort
of
namespace
provisioner,
where
you
ask
it
make
a
namespace
for
me
and
it
creates
the
namespace
gives
you
a
role
in
it
and
then
hands
it
to
you.
C
A
A
The
question
was:
are
there
plans
to
add
conditions
to
role
specifications
it's
been
discussed.
We
want
to
be
really
careful
about
not
breaking
delegation
cases,
so
the
more
input
there
is
to
the
authorization
decision,
the
harder
it
gets
to
kind
of
reconstruct
accurately,
all
of
the
context
input
for
a
delegated
check,
and
so
there's
there's
definitely
interest
in
it.
I
think
that
is
something
that
we're
kind
of
currently
talking
about
and
thinking
about,
whether
it
makes
sense
to
do
in
our
back
proper
or
as
a
layer
or
some
combination
of
the
two.
B
A
There's
no
projects
I'm
aware
of
I
mean
the
the
audits
are
back
tool.
Actually.
Does
a
simulated
check
internally
like
the
way
it
works?
Is
it
looks
at
the
role
it's
set
up
so
far
looks
at
the
request
that
was
audit
logged
and
says.
Would
this
have
allowed
that
and
if
not
then
go
at
it?
In
so
I
mean
it's,
it's
not
difficult
to
reuse.
B
A
So
kubernetes
is
philosophy:
around
authentication
is
to
try
to
stay
relatively
neutral
and
not
have
users
be
a
first-class
concept,
because
everybody's
authentication
is
a
special
snowflake,
and
so
there
aren't
api's
around
user
management
as
such,
when
you're
talking
about
like
are
back.
If
the
user
authority
is
over
here
and
the
authorization
decisions
are
over
here.
No
there's
not
not
a
particularly
strong
connection
between
the
two
time
for
one
more
and
then
I'll
stick
around
as
long
as
people
want
to,
but.