►
Description
Join us for Kubernetes Forums Seoul, Sydney, Bengaluru and Delhi - learn more at kubecon.io
Don't miss KubeCon + CloudNativeCon 2020 events in Amsterdam March 30 - April 2, Shanghai July 28-30 and Boston November 17-20! Learn more at kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects
Defining Mutli-Tenant Access Controls for a Cluster - Anund McKague, Atlassian
What we've learned while building an internal PaaS allowing automated self service access to our multi-tenant clusters. Teams have access to create service based namespaces on demand. Beginning with how users authenicate via our open source cli tool connecting ldap and 2fa, continuing through our use of authentication webhooks, on to our use of authorization webhooks and RBAC, and finishing with how we manage creation of dynamic RBAC based roles. Talk will touch on authentication webhooks, github.com/atlassian/kubetoken, mutating and validating webhooks, api servers as proxies to internal services, managing rbac roles and dynamic creation of role bindings, along with some of the security implications of cluster roles and cluster role bindings.
To learn more: https://sched.co/GrUF
A
A
A
So
far,
existing
has
the
thing
that
we
had
to
move
from
had
lets.
Users
deploy
their
service
and
its
resources
in
various
availability
zones,
in
particular
regions
and
dev.
Staging
and
prog
we
would
have
to
kubernetes
is
pretty
much
the
same.
Only
now
it's
namespaces
the
resources
that
they
were,
allowing
them
to
create
their
own
objects,
provisioning,
the
same
resources
and
still
doing
it
in
separate
custer's
and
testing
and
product
I'll
talk
about
some
of
our
use
cases,
the
very
basic
use
case,
just
to
start
it
off
I,
giving
users
access
to
the
cluster.
A
A
We
also
have
to
let
some
existing
automation
and
automation,
tooling,
and
the
external
services
be
able
to
talk
to
the
cluster
using
for
the
most
part
what
they
already
use
for
internal
services
service
communication.
This
all
needs
to
be
chunked
into
particular
pieces
across
here,
not
bubble.
Clustering,
all
by
itself,
and
at
times
we
need
to
be
able
to
deny
the
contents
of
requests
based
on
the
contents
of
the
object
that
they're
submitting,
not
necessarily
just
what
are
like.
A
A
How
do
we
deny
access
based
on
the
requests?
Contents
of
the
requests
I'll
be
talking
about
these
ones
individually,
in
order
to
let
you
use
it,
they
need
to
properly
authenticate.
In
order
to
do
this.
For
the
most
part,
we
define
a
set
of
static.
Our
back
rolls
as
I
get
and
for
the
more
sensitive
things
instead
of
static.
Are
our
bankroll
bindings
all
of
these
to
play
to
the
clusters.
This
works
for
our
admin
accounts.
A
It
doesn't
work
so
well
for
teams,
especially
when
the
teams
come
in
and
define
their
own
names
basis
by
themselves
than
in
typically
dynamically.
This
case
here,
I'm
familiar
it's
just
a
basic
example
of
an
our
back
role.
For
this
talk
we'll
be
highlighting
important
things
in
green.
This
is
the
roll
it
lets.
A
A
A
As
I
said,
I
named
one
of
the
things
that
comes
up
is
dynamically,
generating
these
role
bindings.
Every
time
someone
comes
in
Chris
and
names
base.
We
don't
really
want
to
be
defining
the
role
binding
that
lets
a
team
into
the
namespace
every
time
through
some
sort
of
manual
process
with
say,
ticketing
and
get
requests
and
things.
Oh.
A
Good,
we
need
a
little
bit
of
an
aside
I'll
talk
about
our
experience
with
these
roles.
Carini's
itself
is
a
bunch
of
built-in
groups,
one
of
which
is
system
authenticated.
You
could
think
about
associating
role
bindings
with
this
role,
but
it's
a
bit
treacherous
you
end
up
with,
because
service
accounts
are
also
in
this
group,
giving
pods
permissions.
You
didn't
think
you
were
giving
if
you
associate
a
system
indicated
with,
say
some
low-level
read-only
access,
the
are
back
definition
for
role
binding
for
a
group.
Almost
the
same,
it's
just
a
group
kind.
A
For
the
most
part,
this
comes
down
to
service
accounts
and
some
sort
of
service
to
service
authentication,
at
least
if
you're,
using
built-in
primitives
for
communities.
In
our
particular
case
we
have
to
generate,
or
we
choose
to
generate
a
GWT
token
as
part
of
the
build
and
passed
that,
along
as
the
authorization
authorization
you
taught
authorization
header
towards
the
cluster,
this
sort
of
gets
us
around.
A
A
A
A
A
This
may
or
may
not
be
a
more
paying
more
or
less
painful,
depending
on
what
sort
of
control
you
have
on
the
tools
used
to
generate
the
token
in
the
first
place
as
another
as
a
consequence
of
urbex
additive
permission
model.
This
also
means
you
have
to
be
careful
about
what
group
contexts
you
put
into
the
token
in
the
first
place,
if
you
put
in
all
the
groups
to
user
as
part
of
all
of
your
system,
mints
are
now
always
system
in
there.
Never
anything
else,
even
if
they
want
to
be
something
less.
A
For
us,
we
use
a
custom
resource
and
names
for
lack
of
a
better
term
in
the
namespace
creator.
It
does
two
things
for
us
it
when
it's
created
it
generates
the
namespace
object
in
the
first
place,
and
then
it
fills
in
all
of
the
associated
role
bindings
in
this
particular
case
needed
to
let
users
come
in
users.
I
particularly
use
this
particular
team
enter
the
cluster.
A
A
The
customer
service
itself
is
cluster
scoped.
This
prove
this
has
problems,
or
we
have
problems
with
our
backs
in
our
back
itself.
Doesn't
let
us
say
only
this
team
can
create
this
particular
cluster
scoped
object
and
we
would
like
them
to
come
along
and
create
it
when
they're
ready,
rather
than
pre
created
for
them
with
some
sort
of
blank
data.
A
It
almost
start
back
almost
has
enough
tools
to
work
around
it
and
the
way
we've
pieced
the
way
piece
together
a
mechanism
to
do
this
is
by
combining
two
features.
Two
extra
features
of
our
back.
One
is
resource
names.
Normally,
if
you
associate
resource
names
with
the
resource
names
field
to
a
cluster
role,
that
cluster
rule
will
only
apply
to
a
particular
object.
A
A
A
We
can
define
the
cluster
rule
that
uses
a
custom
verb
associated
with
a
resource
name,
and
then
you,
a
subject.
Taxes
review,
requests
to
figure
out
during
a
create
whether
or
not
the
incoming
user
has.
The
allah
has
the
enough
permissions
to
actually
create
the
object
using
this
custom
verb
as
a
proxy.
A
One
of
the
other
things
is
that
defining
namespace
creation
by
an
intermediate
custom
resource
allows
us
to
do
is
sort
of
lock
that
process
down
behind
a
bunch
of
business
rules,
simple
things
like
saying:
you
can't
clash
with
other
other
namespaces
other
teams,
namespaces
and
more
complicated
things
like,
even
though
the
namespaces,
and
even
though
the
namespace
cube
system
is
not
inside
our
list
of
teams.
You're
not
allowed
to
ask
for
a
cube
system
itself.
A
This
is
an
example.
What
the
role
binding
looks
like
when
we
char
the
excuse
me.
The
role
looks
like
when
we
try
to
assist.
We
generate
it,
try
to
generate
it
with
a
particular
team
and
the
custom
verb
claim.
In
this
particular
case.
You
can
associate
this
role
with
a
role
binding,
say
for
routine.
You
can
then
use,
subject
access
review,
API
to
say:
does
this
user,
given
the
content
of
the
original
request,
have
access
to
claim
this
particular
resource
and,
of
course
the
binding
itself
is
very
straight
forward.
A
It
just
says:
bind
to
that
thing
as
this
Dan
one
of
the
things
you
have
to
note
before
I
go
too
much
further
with
this
during
the
process
of
role
creation,
if
the
service
account
that's
doing,
that's
managing
the
permissions
of
this
process
is
running
inside
of
the
cluster.
That
service
account
needs
to
have
the
effective
permissions
of
any
bindings
that
it
creates.
A
A
It
talked
about
limiting
the
creation
of
our
top-level
namespace
objects
to
particular
team.
In
order
to
do
that,
we
have
to
know
that
a
team
wants
it
in
the
first
place,
since
teams
coming
to
go
inside
the
company.
The
way
we
do
this
mostly
to
keep,
keep
things
consistent
between
the
old
paths
and
the
new
path
is
by
running
an
API
server
as
a
bridge
between
the
pre-existing
service
we
have
for
this
process
of
namespacing
teams
are
getting
fresh
names
routines
and
the
new
cluster
lets
us
bridge
it.
A
One
of
the
other
things
that
implementing
it
is
an
API
server
helps
us
do
is
avoid
some
sort
of
manual
synchronization
task.
That
would
say
talk
to
the
old
service.
Read
all
the
service
read
all
of
its
information
for
its
entire
list
of
teams
that
should
exist
and
then
dumping
it
into
the
cluster
is
some
sort
of
config
object
or
secret
into
a
particular
namespace
somewhere
that
has
to
be
special.
A
Instead,
what
we
can
do
is
implement
watch
on
the
API
server
and
then
anything
running
in
the
cluster
that
needs
to
know
about
changes
just
watches
that
as
if
it
were
any
other
object
at
the
beginning.
We
did
this
from
scratch.
We
tried
we
implemented
pieces
of
the
entire,
the
API
server
contract
more
recently,
and
it
is
doable.
You
can
use
things
like
cube,
CTL,
with
increased
verbosity,
to
figure
out
who's
talking
to
what
and
how
and
then
just
work
backwards.
A
But
more
recently,
we've
picked
up
using
the
communities,
API
server
library
moving
a
little
bit
lower
than
what
it
wants
it
hasn't
it
intended.
It
intends
you
to
do
since
we
don't
want
to
use
etcd
for
storage
here,
we're
using
an
external
service,
but
did
save
this
a
fair
number
of
implementation,
steps
that
we
otherwise
would
have
to
do.
The
most
notable
for
these
are
authorization
mostly
making
sure
that,
when
the
aggregated
API
server
talks
to
our
API
server,
we
check
that
the
cert
is
valid.
A
We
check
through
the
certain
matches
the
API
server,
that
sort
of
thing
it
also
runs.
Subject:
acts
through
you
requests
for
you
as
a
secondary
thing
in
case
someone
is
somehow
bypassed
the
core
I
created
server,
and
it
gives
us
auditing
code
for
basically
free
in
the
same
shape
as
everything
else
in
the
kubernetes
auditing
system.
A
Back
end,
it's
on
it's
done
some.
Some
of
our
wish
lists.
We
haven't
had
a
whole
lot
of
time
to
experiment
with
sorry
backing
up.
Have
we
tried
to
use
vault
to
intermediate
access
to
the
cluster
I
assume
vault
can
miss
you
tokens
the
way
I've
talked
about
it's
on
our
wish
list
for
various
reasons.
No,
we
haven't
actually
started
to
use
it.
A
lot
of
that
has
to
do
with
just
making
the
existing
stuff
work
I'm
not
having
to
transition
all
the
existing
stuff
to
something.
A
One
of
the
other
things
you
have
to
do
after
you
said
all
of
this
are
back
permission
up,
is
worried
about
users,
creating
objects
that
have
global
scope.
The
easiest
easiest
example
of
this
is:
if
you
want
to,
let
users
create
ingress
objects.
You
have
to
make
sure
that
when
they
create
their
DNS
names
over
their
backends,
they
aren't
clashing
with
things
that
already
exist
in
the
cluster.
A
One
of
the
things
to
be
careful
with,
though,
when
you
start
to
do
this
sort
of
thing
is
not
to
try
and
wander
into
user
and
group
based
authorization
inside
the
validating
web
hook.
If
you
ever
try
and
start
if
you
start
trying
to
write
white
lists
for
a
user
and
group
based
authorization,
you're,
probably
just
gonna,
have
a
bad
time
in
this
particular
case.
Our
first-time
experience
with
this
was
accidentally
disabling.
A
In
our
experience,
these
are
the
sort
of
things
web
hooks
are
good
and
bad
at
there's
valid
encounters
in
the
object
I
was
discussing
with
ingress.
This
also
comes
up
when
you
have
your
own
yeah
for
us.
This
also
comes
up
when
you
have
your
own
resource
definition.
Objects
for
asking
for
things
like.
Please
give
me
that
AWS
database
over
in
that
other
accounts
somewhere
you'd
prefer
that
users
couldn't
go
ahead
and
steal
someone
else's
resource
just
by
carefully
crafting
their
code.
We
can
use
object
even
though
they
create
themselves.
A
It's
a
nice
place
to
perform.
Subject
access
review
requests
by
proxy
if
you
want
at
this
point
in
time
in
the
in
the
predict
you
in
the
call
chain,
you
have
the
original
object,
you
have
the
user,
they
have
successfully
authenticated.
You
can
now
say
you
can
now
craft
your
own
subject,
access
review,
requests
to,
say:
here's
the
object,
here's
the
verb
or
any
other
mutations.
You
want
to
make
here's
the
user.
A
A
A
In
our
particular
case,
this
often
comes
up
with
custom
resources
and
trying
to
define
some
schema
validation,
errors
that
aren't
kubernetes
default,
built-in
schema
validation,
which
is
fairly
generic
and
not
particularly
user-friendly
when
it
vomits
back
the
entire
schema
to
the
user
couple
of
things.
What
books
are
bad
at.
A
A
Geez,
look
over
there
sorry
mutation,
it's
not
a
good
thing
to
do.
It's
not
while
mutating
webhooks
can
do
more
than
just
add
defaults
to
an
object,
or
first
year
these
case,
mostly
in
the
Sierra
T
case,
not
in
the
built-in
objects
or
an
extra
information.
You
need
to
say
pods.
It's
we
found
it
been.
It's
been
particularly
bad
to
remove
fields
for
users.
A
They
tend
to
get
fairly
confused
when
the
thing
that
they
had
then
get
doesn't
match
the
Cygnus
in
the
cluster
and
things
are
missing:
they're,
also
pretty
terrible
at
running
long,
expensive
checks.
So
if
you
need
to
do
anything
fancy
in
your
validation,
it
needs
to
be
fairly
quick,
because
this
all
happens
in
line
with
everything
else
in
a
synchronous
manner,
so
you'll
slow,
the
whole
cluster
down
the
whole
cluster
you'll
slow,
the
whole
user
interaction
pattern
for
that
particular
object
down.
If
you're
particularly
slowing
your
your
equipment,
which
is
not
fun.
A
A
The
first
one
is
certs,
it's
fairly
vanilla,
you
know,
Lee,
let's
see
do
users
and
groups,
you
have
to
generate
the
client
search
for
the
user.
The
second
one
is
open,
ID
Connect
tokens.
This
mostly
comes
up
for
managed
clusters
because
they
tend
to
be
the
only
way
you
can
get
in
again.
Its
users
name
is
groups.
The
last
one
is
a
full-on
authenticated
proxy
sitting
in
front
of
the
kubernetes
api
and
chatting
with
it
over
to
our
headers.
A
This,
like
a
semi,
giving
web
book
tokens
lets,
you
add
not
just
user
group
information,
but
also
extras
information.
So
if
you
want
to
go
down
the
road
of
writing
your
own
authorizer,
because
our
back
just
won't
do
it
and
you
can't
copy
the
sort
of
workarounds
that
I've
talked
about
today,
you
can
include
extra
information.
This
method,
either
with
this
with
the
authenticating
proxy
or
with
the
webhook
API,
that
your
authorizer
can
then
pick
up
later
and
figure
out
whether
or
not
user
can't
actually
do
what
they're
trying
to
do.
A
If
you
want
to
look
at
the,
if
you'd,
like
an
example
of
how
to
how
to
do
the
token
access
request
pattern
thing,
although
in
this
particular
case
it's
generating
clients
Hertz,
we
do
have
a
project
called
queue
token
on
github.
That
does
do
this.
That
does
manage
the
dance
of
talk
to
LDAP
figure
out
what
this
user
is
figure
out.
What
teams
he's
on
then
talk
to
to
if
a
figure
out,
if
the
user
is
who
they
say,
they
are
run
an
authentication
dance
again
over
LDAP?
A
A
So,
in
closing
the
main
points
touch
on
today-
and
hopefully
you
have
some
better
idea
of
how
they
work
is
customizing
authentication
using
your
own
hooks,
hooks
or
proxy
or
tokens
to
get
user
information
into
the
cluster
working
around
a
few
of
the
quirks
in
our
back
to
sort
of
expand.
What
what
is
expressible
to
be
something
a
little
bit
more
than
a
namespace
using
API
servers
to
bring
extra
context
into
the
cluster,
so
you
can
make
you
can
sort
of
begin
to
make.
This
is
the
role
binding
this.