►
From YouTube: What Do You Mean K8s Doesn't Have Users? How Do I Manage User Access Then? - Jussi Nummelin
Description
Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon North America 2021 in Los Angeles, CA from October 12-15. 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.
What Do You Mean K8s Doesn't Have Users? How Do I Manage User Access Then? - Jussi Nummelin, Mirantis Inc.
What if I told you that once you give someone client certificate access to your Kubernetes cluster you can't take it away again? It's true. Once you create an authentication key and give it access to the cluster, there's no way to revoke it. That person has access forever. And that's just one of the weird things about Kubernetes Authentication and Authorization. In this session, you will learn about how Kubernetes handles users and permissions, and how to set up your cluster to do it more efficiently and securely. You'll learn: How access keys work How permissions work How to segment your cluster for greater security How Role-Based Access Control limits what individual users can see and do How to use OpenID Connect to get around the issue of permanent access without having to manage hundreds or thousands of individual Roles You will leave this session ready to create a more secure and convenient way to manage your cluster.
A
The
whole
talk
kind
of
stems
from
from
different
different
discussions
that
I've
had
with
with
people
new
or
newer
into
the
into
the
world
of
kubernetes
and
and
kind
of
the
blood
of
confusion
that
that
yeah.
I
have
now
my
cluster
up
and
running.
So
how
do
I,
how
do
I
actually
grant
access
to
to
another
set
of
users
for
my
my
cluster?
A
So
we
are
at
cubecon,
2021
and
and
we're
on
the
101
track,
so
we're
not
gonna
dive
too
deep
into
the
into
the
whole
whole
topics
and
different
different
configuration
options,
for
example,
but
but
we're
we
are
gonna,
look
at
the
the
kind
of
high
level
high
level
topics
and
and
concepts.
How
do
how
do
you
actually,
then,
then
really
manage
the
access
for
your
users
into
your
your
clusters,
so
yeah
hi,
I'm
I'm
yusuf
malin
working
at
miranda's
engineering.
A
I've
been
working
with
kubernetes
and
and
different
cloud
native
technologies
for
the
past.
Quite
quite
a
few
years,
even
even
actually
before
they
were
really
called
like
cloud
native
stuff
in
the
past
year
or
so,
I've
been
I've
been
mostly
working
with,
with
the
new
open
source,
kubernetes
distro
called
k0s,
and
and
and
and
that's
basically,
that
the
reason
why
you
see
some
some
mentions
of
it
and
in
the
in
the
examples.
So
so.
This
is
not
really
a
topic
on
case
stores
itself,
but
but
you'll
see
some
examples.
A
How
we
do
things
in
case
zeros,
for
example,
and
and
of
course,
as
I
said,
it's
open
source.
So
you
can.
You
can
dig
into
that
if
you,
if
you
really
want,
although
not
entirely
correct,
but
the
kind
of
good
way
to
get
your
mindset
into
in
the
correct
correct
kind
of
direction
when
when
when
when
thinking
about
this
whole
users
in
in
kubernetes
topic
is,
is
like
really
really
kind
of
realize.
A
A
A
What
what
the
authentication
really
really
does
is
is
that
it?
It
really
looks
at
the
kind
of
the
incoming
request
and
then
figures
out
that
okay,
what
is
that?
What
is
the
user
identity
of
the
of
the
thing
either
a
human
or
or
some
other
service?
That's
actually
making
the
call
and
every
single
call
is-
is
either
rejected
us
as
unauthorized
or.
A
A
The
service
accounts,
which
probably
everybody
everybody
has
been,
has
been
kind
of
kind
of
stumbling
over
and
and
service
accounts
are
really
really
kind
of
access,
controls
and
access
identities
intended
to
be
used
for
for
processes
like
like
your
your
core
dns
server
running
in
a
pod
in
a
cluster.
Of
course
it
needs
to
talk
to
the
api,
so
we
have
to
have
some
sort
of
a
authentication
and
identity
for
for
koreans.
A
If
we
look
at
the
kubernetes
documentation,
there's
actually
actually
quite
a
sort
of
good
explanation
and,
and
especially
is
one
one
kind
of
sentence,
really
nails
nails
it.
It
really
really
well.
So
the
api
server
really
really
expects
that
the
there's
always
something
something.
That's
that's
more
or
less
external
to
the
cluster
itself
that
manages
the
the
user
access
and
and
manages
the
user
information.
A
So,
essentially,
user
is
more
or
less
like
a
transient
thing.
So
so
so
the
user
data
is
not
really
stored
on
it,
cd,
which
of
course
means
that
there's
no
like
like
user
management
capabilities.
So
I
cannot
grab
my
my
admin
access
to
my
cluster
and
say
say:
like
cube,
cdl
create
user.
Just
that's
that's
not
possible,
and
I
said
that
the
api
server
has
this
sort
of
a
configurable
plugable
pluggable
different,
multiple
different
ways:
how
to
how
to
actually
then
identify
who
is
the
user
and
and
then
authenticate
the
user?
A
There's
basically,
four
different
options
out
of
box
on
the
api
server
there's
client
certificates.
We
can
use
static
tokens.
We
can
use
external
service
to
validate
a
token,
and
then
we
can
use
this
more
slightly
more
complex
protocol
called
open
id
connect,
it's
kind
of
more,
like
kind
of
like
oauth,
with
some
some
some
nuances.
A
So
as
as
long
as
you
can
create
a
certificate
that
is
signed
by
the
by
the
ca,
the
api
server
can
use
the
information
from
the
certificate
itself
to
really
identify
the
user
because
it
trusts
it.
It
has
been
signing
the
kubernetes
ca
and
the
kubernetes
control
plane
kind
of
itself
has
been
signing
that
the
certificate
so,
of
course,
it'll
it'll
trust
a
trusted
certificate.
A
A
Your
your
distro,
tooling,
might
might
bring
some
helpers
like
we
we've
done,
for
example
in
k0.
So
you
can
you,
you
might
get
these
handy,
handy
command
line,
helper
tools
to
actually
create
you
like
a
cheap,
convict,
friendly,
parse,
then
and
speed
out
with
that
with
the
client
certificates
created
in
them.
A
Of
course,
we,
as
with
any
system
and
and
as
with
any
solution,
there's
there's
of
course,
some
good
just
and
and
for
the
client,
certain
cert
authentication.
The
the
main
thing
to
understand
is
the
fact
that
that
once
you
create,
and
once
you
give
a
certificate
for
your
user,
it's
it's
pretty
much
impossible
to
actually
revoke
the
access
so
and
that's
basically
because
the
the
the
ca
is
is
more
or
less
kind
of
static
for
the
lifetime
of
the
cluster.
A
So
if
you
go
and
actually
change
the
ca
or
want
to
recreate
the
ca,
you
have
to
reconfigure
a
lot
of
things
on
the
on
the
api
server
and
on
the
on
the
current
program
in
general
and
and
then
again,
it's
not
really
like
it's
not
difficult,
but
it's
it's
not
trivial.
To
create
this
client
search,
either
and
and
of
course,
requires
a
bit
of
effort,
so
it
doesn't
kind
of
make
sense
to
have
this
sort
of
a
super
short-lived
certificates.
A
A
A
So
basically,
I
have
a
token
as
the
as
the
first
field
and
then
user
information
group
information,
and
after
that
I
can.
I
can
use
the
token,
as
as
a
barrier
token
on
on
my
api
requests
and
and
that's
it
and
of
course
you
tube
cdl,
for
example,
and
and
keep
config
format
has,
has
support.
Of
course,
these
these
static
tokens
too.
A
So
that's
that's,
like
super
super
simple
way
to
manage,
manage
your
your
user
access,
but
well,
of
course,
there's
gonna
be
a,
but
the
main
thing
to
understand
with
these
tokens
is
the
fact
that
whenever
you
want
to
change
something
in
the
tokens,
you
want
to
revoke
access
from
your
co-worker
or
somebody
who
left
the
company.
You
want
to
change
a
token.
You
want
to
create
a
new
token
for
new
user.
A
What
not
you
have
to
always
reboot
the
api
server
or
restart
the
api
server,
so
the
apis
are
really
reads
in
the
tokens
only
only
when
it
starts,
and
then,
if
you
are
running
like
like
multiple
controllers
in
a
in
a
highly
available
setup.
Of
course,
you
have
to
keep
this
whole
thing
in
sync
across
all
of
the
all
of
the
different
different
controllers
and,
of
course,
as
you
saw
that
the
tokens
are
in
plain
text.
So
it's
a
bit
sketchy.
Maybe.
A
Webhook
token
authentication
it's
it's
essentially
essentially
a
kind
of
a
external
web
web
hook
service
that
the
api
server
calls
to
really
both
authenticate
the
token
and
then
give
the
give
the
user
information
for
the
for
the
user.
Who
owns
the
token?
So
so,
let's
say
that
the
api
server
sees
a
call
with
this
sort
of
a
token
one,
zero
one,
four
f
blah
blah
blah.
A
What
it
actually
actually
does
is
that,
of
course,
it
needs
to
be
configured
to
do
this,
but
but,
but
essentially
it
calls
this
external
webhook
service
and
then
passes
on
the
token.
In
this
situation,
token
review
json
format
and
then
the
webhook
will
will
basically
respond
that
that
yeah,
it's
a
known
token
for
a
known
user,
so
yeah
good,
authenticate
it,
and
then
it
also
passes
passes
on
the
the
user
information
based
on
whatever
system
it
can
figure
this
out
from
it
doesn't
for
the
for
the
kubernetes
api.
A
A
A
So
you
have
to
pass
in
that
the
address
for
the
web
hook
and
web
hook
service
and
whatnot
and,
most
importantly,
you
have
to
be
able
to
configure
this
mutual
trust
between
the
api
server
and
the
webhook
service,
of
course,
that
it
doesn't
make
any
sense
for
that
for
the
api
server
to
just
spit
out
the
talk
and
do
any
random
service
and
then
expect
to
get
a
like
a
valid
valid
answer
back
and
and
just
trust
it.
So
that's
not
really
really
a
possibility.
A
A
Open
ids
is
is
kind
of
kind
of
similar,
but
then
then
again,
then
again,
really
not
not,
but
slightly
similar,
at
least
to
that
to
the
web
token.
So
also
in
the
case
of
case
of
open
id
connect
that
the
whole
identity
management
is
like
fully
external
to
the
api
server.
So
there's
no
like
like
token
files
or
token
csvs
or
or
anything
stored
on
the
on
the
api
server.
A
A
So
again
we
have
to
configure
this
sort
of
mutual
trust
between
the
api
server
and
the
the
the
identity
provider.
Essentially,
what's
cool
about
this,
this,
this
open
id
and
and
basically
on
on
json
web
tokens
in
general-
is
the
fact
that
the
json
web
token
is
is
cryptographically
signed.
So
when
you've
configured
this
mutual
trust,
anybody
can
actually
like
like
really
easily
validate
and
and
verify
that
that
yeah.
This
is
a
valid
token
and
then,
after
after
validating,
we
can
dig
out
all
the
needed
information
from
the
token
itself.
A
So
at
that
point
we
don't
actually
have
to
call
any
other
external
service
anymore.
So
so
we
can
really
really
just
like,
validate
and
verify
that
that
token
itself
and
then
take
out
alternating
information.
So
so
it's
it's
in
a
sense
from
the
from
the
processing
point
of
view,
it's
it's
much
much
much
simpler
and
then,
of
course,
clients
like
like
chip
cdl,
for
example,
they
can
be
configured
to
to
or
automatically
handle
this
token
renewal
with
that
with
the
client
and
the
identity
provider
itself.
A
Setting
up
the
cas
is
well
as
with
anything
anything
that
has
to
do
with
certificates
a
bit
a
bit
of
a
tedious
thing
if
you,
especially
if
you're
doing
the
first
time,
but
but
in
most
cases
your
your
distro,
tooling
and
distro,
this
throw
itself
kind
of
handles
that
part.
So
so
it's
it's.
It's
pretty
pretty
pretty
simple
and
stay
straightforward
to
use
a
setup,
but
but
both
of
them
are
are
actually
quite
inflexible
in
in
a
way.
A
A
But
but
but
I
don't,
I
don't
think
that's
that's
like
like
a
nightmare
or
anything.
So
it's
just
a
bit
more
work
and
a
bit
more
complexity
on
that
odc
super
flexible,
of
course,
because
the
identity
is
provided
fully
by
by
an
external
service
external
system
like,
for
example,
like
google
accounts
or
or
whatnot.
A
A
So
so?
Basically,
the
second
stage
on
the
on
the
kind
of
api
called
kind
of
processing
processing
pipeline
is,
is
authorization
so
and
and
basically
on
the
authorization
stage.
We
we,
the
api
server,
starts
to
figure
out
that
yeah.
Okay.
Now
we
know
that
the
user
is
usually
he's
trying
to
create
a
port,
but
is
he
allowed
to
do
it
as
we
know
that
the
kubernetes
api
provides
a
really
super
fine,
fine-grained
role-based
access
control
system?
A
So
we
can
actually
control
the
the
access
to
the
api
based
on
different
apis
api
groups.
Different
api
objects
on
on
the
level
like,
like
even
sub
objects
that
that
yeah
can
a
user
read
logs
of
a
pod
and
then,
of
course,
as
the
authentication
stage
kind
of
gives
us
the
identities
of
the
users
we
we.
We
have
to
then
tie
the
the
users
and
groups
into
the
role-based
access
control
rules,
and
to
do
that,
we
we
basically
basically
on
our
back
level.
A
It
says
that
that
whoever
gets
assigned
a
this,
this
specific
role,
can
can
access
pods
and
can
access
it
with
verbs,
get
watch
and
list.
So
basically,
all
the
all
the
verbs
that
are
intended
for
reading
information
from
the
api,
and
then
we
use
role
bindings
to
bind
a
a
user
which,
for
the
r
back
itself,
it's
just
a
string.
It's
not
an
object
or
anything.
It's
just
a
string.
A
We
bind
it
to
the
role
that
we
just
defined
and,
of
course
we
can.
We
can
bind
point
users
to
the
the
roles
either
directly
to
a
single
user
or
then
we
can
also
bind
a
a
group
of
users
and
both
remember
that
the
both
of
these
user
and
group
information
is
pretty
much
always
provided
by
something
that
is
external
to
the
api
server
itself.
So
it's
not
another
user
information
or
group
information
object
that
we
store
on
the
api
server
itself.
A
So,
having
said
that,
user
really
is
a
more
or
less
like
what
I
I'm
not
sure
whether
this
is
a
I'm,
not
a
native
english
speaker.
So,
but
I
I
always
call
call
user
is
as
a
transient
thing.
So
it's
not
it's
something
that
we
that
we
kind
of
figure
out
on
the
fly.
We
keep
the
information
in
memory
during
the
processing
of
the
request,
but
but
that's
it.
A
This
uranus
doesn't
really
store
the
information,
after
that,
the
user,
identification
and
and
sort
of
authentication,
of
course
is,
is
more
or
less
externalized
from
the
api
server
point
of
view,
whether
whether
I'm
using
terms
sort
of
because,
on
the
other
hand,
having
the
the
ca
the
certificate
authority,
for
example,
stored
along
the
api
server
on
the
node,
it's
whether
that's
really
truly
external
or
not,
that's
a
that's
a
different
discussion,
but
but
at
least
from
the
api
service
point
of
api
server
point
of
view.
It
is
an
external
thing.
A
Hopefully
I
provided
the
kind
of
good
information
for
for
people
to
kind
of
understand
and
get
into
the
mindset
that
that
that
yeah
there's
the
user
user
management
is,
is
somewhat
complex
and
and
not
that
straightforward
in
kubernetes.
Well,
what
is
what
is
straightforward
in
kubernetes,
but
but
but
at
least
gives
you
a
kind
of
good
segue
into
into
learning,
more
and
and
and
and
diving
driving
into
into
more
details
into
into
each
of
the
each
of
the
different
different
options
and
whatnot
I'll
be
hanging
out
on
the
on
the
event
platform.