►
From YouTube: 5 Key Steps to Securing a Default Kubernetes Cluster
Description
Don't miss out! Join us at our upcoming event: KubeCon + CloudNativeCon Europe in Amsterdam, The Netherlands from 18 - 21 April, 2023. 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
Hello,
everyone
and
thank
you
for
joining
me
for
today's
webinar
in
thank
you
cncf
for
hosting
it.
My
name
is
Travis
Rogers
I'm,
a
developer
relations
engineer
over
at
teleport,
where
we
provide
identity,
native
infrastructure,
access
for
engineers
and
machines.
Now
we're
going
to
see
a
demo
of
how
teleport
works
with
kubernetes
later,
but
that's
not
the
main
reason
we're
here
today.
The
main
reason
we're
here
today
is
to
discuss
kubernetes
clusters
and
how
to
secure
them.
A
Now,
if,
at
any
point
during
the
presentation,
you
have
questions
or
at
any
point
afterwards,
my
email
is
right
here
on
the
slide
at
travis.rogers
got
teleport.com
I'd
love
to
hear
from
you
feel
free
to
email
me.
But
if
you
want
to
access
the
broader
teleport
Community,
then
check
out
air
Community
slack
you
can
get
to
that
at
go
teleport.com
Slack!
A
We
are
an
open
source
project,
so
the
link
to
our
GitHub
is
right
here
as
well,
and
if
you
want
to
try
it
out,
we
have
a
Labs
page
where
we
actually
spin
up
the
servers
and
teach
you
how
to
use
it.
That's
at
go
teleport.com
labs
and
finally,
you
can
find
us
on
YouTube,
where
we
do
tutorials
webinars
videos
like
this.
So
with
all
of
that
out
of
the
way,
let's
get
started
with
the
webinar
okay.
So
here's
a
diagram
of
how
I
think
people
are
in
kubernetes
so
they're
at
the
starting
point.
A
Maybe
their
job
is
asking
them
to
learn
these
skills
to
manage
their
clusters
for
them,
maybe
they're
learning
it
on
the
side.
It's
like
a
hobby
or
an
interest,
but
usually
you
start
out
here
and
you
think:
hey
I
got
this
checklist.
I
gotta
check
off
to
learn
kubernetes.
But
what
really
happens
is
you
get
pushed
into
this
Scribble
fast,
there's
just
so
many
things
to
learn
with
kubernetes.
A
So
many
moving
Parts,
it's
a
pretty
complex
machine,
so
you
get
in
there
and
you
realize
hey,
wait:
I
I
need
to
I,
don't
even
know
containerization
I'm
going
to
learn
that
first
and
then
you
get
in
there
and
there's
so
many
little
parts
to
it.
It's
just
pretty
complicated
to
learn
kubernetes
exhaustively.
So
normally
you
get
in
here
you
scribble
around
a
little
bit.
A
You
come
out,
and
you
understand
kubernetes
great
at
that
point-
you're
able
to
get
your
cluster
up
and
running
you're
able
to
deploy
a
cluster
you're
able
to
deploy
an
application
without
errors,
because
we
all
know
the
first
time
we
try
to
do
that.
We
get
lots
of
Errors
crash
Loop
backoffs
things
like
that,
so
you
can
get
the
cluster
up
and
running.
You
can
deploy
your
application
without
errors,
it's
running
out
there
in
kubernetes
and
you
can
navigate
the
cluster.
A
You
can
use
Cube
cuddle,
you
know
about
services
and
stateful
sets
and
pods,
and
all
of
that
good
stuff.
But
there's
one
main
key.
That's
left
out
here,
and
that
is
the
fact
that
kubernetes
isn't
safe
by
default.
You've
deployed
your
cluster,
you
have
applications
running
in
it.
You
can
manage
the
cluster,
but
you
didn't
do
anything
to
the
cluster's
configuration
in
that
configuration
that
was
deployed
untouched,
isn't
safe
by
default.
It
has
to
be
configured
to
better
increase
its
security
posture
to
make
your
cluster
more
secure.
A
Now
let
me
show
you
something
that
reinforces
that.
So
this
is
the
2022
state
of
kubernetes
security
report
by
red
hat.
So
red
hat
polled
300,
devops
engineers
and
Security
Experts,
and
here
here
was
the
result.
Basically,
respondents
worry
the
most
about
exposures
due
to
misconfigurations
in
their
container
in
kubernetes
environments.
So
almost
half
of
all
of
these
people
polled
worried
about
exposures
due
to
misconfigurations
in
their
container
in
kubernetes
environments.
A
This
was
nearly
three
times
the
level
of
concern
over
attacks,
which
was
16
and
with
vulnerabilities
as
the
second
leading
cause
of
worry
at
28,
and
so
in
this
video
I
decided
I
would
try
to
give
you
some
tips
on
tightening
up
the
security
posture
of
your
kubernetes
cluster,
your
default
kubernetes
kubernetes
cluster.
Now,
if
you're
using
managed
kubernetes
like
AKs
or
eks,
you
get
a
lot
of
these
Security
benefits.
A
But
if
not,
you
just
deploy
your
your
cluster
you're
going
to
have
to
do
things
to
make
it
more
secure
and
that's
what
this
video
is
about.
So
we're
going
to
look
at
five
ways
that
you
can
secure
your
cluster,
so
let's
secure
kubernetes,
okay,
so
the
First
Security
measure
we're
going
to
talk
about
in
regards
to
your
kubernetes
cluster
is
at
CD
security
and
secret
management.
So
you
probably
already
know:
etcd
is
a
highly
available
key
value
store
for
cluster
data,
including
your
secrets,
so
securing
at
CD
is
critical
to
a
cluster
security.
A
If
someone
obtains
read
or
write
access
to
etcd,
it's
basically
giving
them
root
access
to
the
cluster,
so
you're
going
to
have
to
do
your
due
diligence
to
secure
this
vital
piece.
Now,
how
do
you
do
that?
Well,
we're
going
to
give
three
ways
today.
First,
you
need
to
encrypt
your
hcd
data
at
rest,
your
default
kubernetes
cluster
does
not
do
this,
your
NCD
data
and
your
secrets
are
in
plain
text.
So
if
an
attacker
were
to
get
your
SCD,
they
can
just
read
your
data
as
plain
text.
A
So
the
first
thing
you
can
do
is
encrypt
that
etcd
data
at
rest
and
I'm
going
to
show
you
Hands-On
how
to
do
that
today.
So
let's
go
to
the
kubernetes
documentation,
there's
a
page
called
encrypting
secret
data
at
rest
and
basically
there's
four
steps.
First,
you
need
to
create
an
encryption
configuration
object.
So
here's
the
encryption
configuration
object.
You
specify
your
resources,
so
here
we
have
secrets
and
config
maps
and
then
you
specify
your
providers
or
your
encryption
type.
So
today
we're
going
to
be
using
AES
CBC
as
seen
down
here
in
the
tutorial.
A
A
A
.Yaml
and
inside
of
that
file,
I'm
going
to
paste
the
contents
we
just
copied
from
the
kubernetes
documentation,
so
I'm
going
to
go
up
here.
First
I'm
going
to
erase
this
other
resource
and
I'm
actually
going
to
erase
config
Maps
too,
because
that's
not
really
pertinent
to
what
we're
doing
today.
So
we
have
resources
secrets
and
we
have
this
provider
at
es
CBC.
We
have
a
key
named
key
one
and
a
secret.
We
don't
have
a
secret.
A
Yet
we
need
to
generate
a
secret
so
to
do
that
on
the
documentation,
there's
actually
a
command,
we
can
run
so,
let's
go
back.
There
run
this
command.
This
will
generate
us
just
a
random
string
of
numbers
and
letters,
so
I'm
going
to
open
a
new
window
and
just
paste
that
in
and
copy
this
string
of
characters-
and
that's
going
to
be
my
key.
This
key
is:
what's
going
to
encrypt
my
secrets,
I'm
going
to
come
here
and
just
paste
that
and
I'm
going
to
save
it
in
that
location.
A
So,
right
here
in
this
ENC
folder
I
have
an
encryption
configuration
file.
That
much
is
done.
So
the
next
step
is,
you
want
to
add
this
encryption
provider
config
flag
on
your
Cube
API
server
manifest
file.
So
you
want
to
add
this
as
a
flag
and
have
it
point
to
that
encryption
configuration
object,
you
just
created
and
then
we
need
to
add
that
folder
is
a
volume
and
then
mount
it.
A
So
let's
do
that
so
I'm
going
to
go
back
a
folder
go
to
manifests
and
within
that
there
is
a
manifest
file
called
Cube
API
server.
So
let's
do
sudo
Vim
Cube
API
server
open
that
up.
So
the
first
thing
we
want
to
do
is
we
want
to
add
that
encryption
provider
config
flag.
So
let's
do
this
in
alphabetical
order,
I'm
just
going
to
put
it
right
below
this.
A
Encryption
and
what
was
an
encryption
provider,
config
encryption
provider
config,
so
encryption
provider
config
equals
and
then
the
path
to
our
file,
so
Etsy
kubernetes
ENC
ryption
configuration.yaml.
So
it
points
to
air
file.
That's
the
first
thing!
Second,
you
want
to
go
down
and
I'm
going
to
do
a
page
down
down
to
the
end
and
add
a
new
volume.
A
A
A
And
when
we
do
that,
it's
going
to
recreate
that
API
server
pod,
so
I
think
when
we
exit
we're
not
going
to
be
able
to
do
anything
yet,
okay
get
pods
yeah.
We
can't
do
anything
yet
it
might
take
a
minute
to
get
this
back
up
and
running.
But
when
this
comes
back
up,
any
secrets
that
you
create
from
this
point
on
will
be
encrypted
and
we'll
go
and
check
that
to
make
sure
that
it's
working,
let's
try
it
again:
okay,
get
pods.
Okay,
our
API
server
is
back
up
and
running.
A
So
what's
next
in
the
documentation,
how
do
we
verify
this
so
verifying
that
data
is
encrypted?
We
first
want
to
create
a
new
secret,
so
we're
going
to
create
a
new
secret
and
then
we're
going
to
read
that
secret
out
of
etcd
using
etcd
cuddle
and
see
that
it's
encrypted.
So
let's
create
a
new
Secret,
so
I'm
going
to
run
this
command
and
it's
going
to
create
a
secret
called
secret
one
secret
created
and
then,
like
I,
said
we're
going
to
read
that
secret
out
of
SCD.
A
Now
they
give
a
command
here
that
you're
supposed
to
run
on
the
edcd
server
I'm
going
to
add
a
cube
exec
to
it
so
that
I
exec
into
that
SCD
server
and
spit
out
that
secret
and
then
I'm
going
to
do
the
hex
dump.
So
it's
the
same
as
this
I'm
just
adding
a
couple
commands
to
it
and
then
I'm
separating
the
hex
dump
part
of
the
command.
A
So
when
it
says
key
one,
it's
going
to
be
encrypted.
So
as
long
as
you
have
the
AES
CBC
here
showing
you
know
that
your
data,
your
secrets,
are
encrypted,
and
this
is
going
to
encrypt
all
of
the
secrets
going
forward
from
this
point
now.
If
you
want
to
go
back
and
encrypt
all
the
previous
secrets
that
you
had
before
this
just
follow
the
documentation
down
where
it
says:
decrypting
all
data
you're,
going
to
move
this
identity,
value
and
you're
going
to
run
this
command
and
that
encrypts
all
of
your
old
secrets.
A
So
that's
encrypting
your
NCD
data
at
rest.
That's
the
first
thing
you
can
do,
but
there
are
a
couple
of
problems
with
this.
The
way
we
did
it,
so
the
first
problem
is
going
to
be
that
the
encryption
key
on
the
server
is
in
plain
text.
So
if
somebody
gets
on
your
control,
plane
node,
they
can
just
check
out
that
encryption
configuration
file
and
there's
the
key
and
that
key
unlocks
everything
it's
in
plain
text.
A
The
second
problem
is
that
you
face
manual
key
rotation
which
can
be
pretty
cumbersome
and
third,
this
encryption
type
is
actually
not
recommended,
the
one
that
they
show
on
their
website,
the
one
that
we
just
followed.
So
if
you
go
here
and
go
back
up
to
this
provider,
chart
you'll
see
that
there's
a
number
of
providers,
so
we
use
this
AES
CBC
provider.
The
strength
for
that
is
weak.
It's
not
recommended
due
to
cbc's
vulnerability
to
padding
Oracle
attacks.
So
what
else
do
we
use?
A
Well,
we
could
use
secret
box,
which
is
strong,
but
it's
a
newer
standard
and
may
not
be
considered
acceptable
in
environments
that
require
high
levels
of
review.
There's
an
AES
GCM
that
is
not
recommended
for
use,
except
when
an
automated
key
rotation
scheme
is
implemented
and
then
there's
identity,
which
is
no
encryption.
So
what
do
they
recommend?
A
They
recommend
the
KMS
provider
here
the
recommended
choice
for
using
a
third-party
tool
for
Key
Management
in
the
key
to
this
KMS
provider
or
Key
Management
Service
is
that
you
can
manage
your
encryption
key
outside
of
your
cluster,
so
think,
AWS,
KMS,
Google,
Cloud,
KMS
or
hashicorp
vault,
there's
some
great
documentation
for
these
providers
out
there,
and
that
is
the
recommended
way
to
go.
That
is
the
strongest
and
has
the
most
benefits.
A
Now.
Let's
move
on
to
number
two,
so
the
number
two
way
of
securing
your
NCD
or
Secrets
is
to
restrict
access
to
your
SCD,
and
that
involves
isolating
your
NCD
server.
So
the
only
thing
that
should
talk
to
etcd
is
the
API
server.
What
you
can
do
is
stick
a
firewall
between
the
two
just
to
ensure
that
only
API
server
traffic
can
get
to
etcd
and
nothing
else,
and
then
finally,
the
third
step
is
to
ensure
that
the
API
server
is
using
TLS
all
right.
A
So
the
second
way
you
can
better
secure
a
default
kubernetes
cluster
is
by
using
network
policies
by
default.
Kubernetes
allows
All
pod
to
pod
traffic,
inbound
and
outbound
so
see
here
in
this
diagram
we
have
a
namespace.
All
pods
can
talk
to
other
pods
freely,
but
if
an
attacker
were
to
gain
access
to
one
of
those
pods,
they
would
be
able
to
freely
move
to
other
pods.
A
A
So,
instead
of
allowing
All
pod
to
pod
traffic,
allow
no
pod
to
pod
traffic
in
a
namespace
and
what's
neat
about
Network
policies,
is
they
are
additive?
So
once
you
deny
all
this
traffic,
you
can
then
add
on
traffic
rules
as
needed,
so
set
an
all-out,
deny
policy
and
then
add
allows
as
needed.
Here's
an
example.
Let's
say
you
have
a
front-end
application
in
react.
You
have
a
back-end
application
or
pod
in
net
and
you
have
a
database
a
mySQL
database
in
another
pod
by
default.
A
Well,
first,
we
would
set
again
this
all-out
deny
policy
so
set
this
network
policy
to
this
namespace,
and
none
of
these
pods
can
talk
to
each
other
and
from
there
we
can
add,
allows
as
needed.
So
if
we
add
another
Network
policy
to
allow
traffic
from
the
back
into
the
database,
we
get
this.
So
this
network
policy
is
applied
to
pods
with
this
label
it's
Ingress
and
it
matches
the
labels
with
backend
at
Port
3306.
So
this
network
policy
allows
our
back
end
to
talk
to
the
database.
It
allows
Ingress
into
the
database.
A
We
would
also
want
to
create
one
from
the
front
end
to
the
back
end,
and
by
doing
so
we
restrict
this
wide
open
access
between
pods
to
allow
only
the
access
that's
needed.
So
this
is
Network
policies,
and
if
you
need
this
kind
of
protection,
not
at
the
network
or
transport
layers,
but
at
the
application
layer,
then
you
can
look
into
a
service
mesh
solution
like
istio,
which
allows
networking
policies
at
the
application
layer.
A
All
right
number
three
on
our
list
and
similar
to
the
previous
is
POD
to
pod
communication
by
default.
Kubernetes
allows
pod
to
pod
traffic
unencrypted,
so
previously
we
saw
that
kubernetes
allows
free-flowing
networking.
Well
here
we
see
that
that
traffic
is
unencrypted
by
default
and
we
definitely
want
to
encrypt
our
data.
So
right
here
in
the
diagram
without
TLS,
we
go
pod
to
pod
in
plain
text
for
any
attacker
to
pick
up
with
TLS,
we
go
pod
to
pod
with
encrypted
traffic.
A
So
what's
the
solution
to
this
well,
the
easiest
solution
is
to
introduce
either
istio
or
Linker
D
to
your
cluster,
because
both
enforce
Mutual
TLS
between
meshed
pods
and
that's
enabled
on
both
by
default.
So
by
introducing
either
one
of
these
Solutions
you
get
Mutual
TLS
within
meshed
pods
in
the
case
of
istio
istio,
deploys
an
Envoy
proxy
to
each
application
container
that
will
enforce
TLS
encryption
within
the
service
mesh.
A
So
here's
the
istio
mesh
within
that
within
each
application
container,
there's
an
Envoy
proxy
that
enforces
TLS
encryption
and
if
you
go
with
istio,
make
sure
you
set
the
mtls
mode
to
strict
and
not
permissive
strict
enforces.
Tls,
only
permissive
allows
TLS
and
plain
text
number
four:
let's
look
at
secure
access,
so
any
user
that
presents
a
valid
certificate
is
considered
authenticated.
With
that
in
mind,
we
want
to
disable
Anonymous
auth
and
we
do
that
in
the
cube.
Api
server
manifest
like
the
one
we
visited
earlier.
A
We
do
that
by
adding
this
Anonymous
auth
equals
false
flag
that
will
disable
anonymous
auth.
Now,
if
Anonymous
auth
must
be
used
like
in
your
circumstances
or
with
your
company,
you
need
Anonymous
auth.
For
some
reason,
our
back
should
greatly
limit
what
these
users
can
do
so
use
rbac
to
greatly
limit
Anonymous
users
as
a
whole
number
two.
You
want
to
disable
the
insecure
Port,
so
the
API
server
actually
has
a
secure
and
an
insecure
Port.
You
want
to
go
in
and
disable
that
insecure
port.
A
Why?
Because
this
insecure
Port
bypasses
authorization
in
authentication
checks
and
to
do
that
again,
you
go
to
the
cube
API
server
manifest
and
you
set
a
flag
of
insecure
Port
equals
zero
number.
Three.
You
want
a
well-maintained
our
back.
This
is
not
something
you
said
and
forget.
This
is
something
that
is
well
defined
and
well
maintained
regularly,
so
that's
a
well-maintained
rbac
and
then
finally,
you
want
to
introduce
some
kind
of
corporate
solution
management,
so
admin
should
consider
managing
normal
user
accounts
with
corporate
Solutions
like
active
directory
OCTA
Etc
via
oidc.
A
And
I'm
actually
going
to
log
in
passwordless,
so
I
can
choose
passwordless
and
then
I'm
going
to
use
a
pass
key,
that's
stored
on
my
phone
if
you're
not
familiar
with
passkeys
they're,
a
new
and
secure
replacement
for
passwords
teleport
supports
it
and
I.
Think
more
and
more
applications
will,
as
the
year
goes
on
so
I'm,
going
to
scan
this
with
my
phone
and
sign
in
with
my
pass
key.
A
Okay,
so
this
is
the
UI
of
my
teleport
cluster
I'm,
signed
in
as
teleport
admin.
That's
a
user!
If
I
go
to
kubernetes
I,
see
that
I
have
no
kubernetes
clusters
to
access
via
teleport.
So
we
need
to
add
one
what's
neat
about.
This
is
that
if
you
go
to
Team,
you
can
create
users
and
you
can
assign
them
roles
here
in
teleport,
so
you
can
enroll
all
of
your
kubernetes
clusters
here
that
you
can
access
and
you
can
use
rbac
to
control
who
has
access
to
what
and
we'll
see
that
in
just
a
minute.
A
A
All
right,
so
my
Helm
repo
is
added
and
step
two
generate
a
command
to
automatically
configure
and
install
the
teleport
agent
namespace,
so
teleport
service,
namespace
I'm,
just
going
to
put
teleport,
is
going
to
be
on
my
namespace.
The
name
of
my
cluster
is
going
to
be
a
mini
Cube
cluster
and
click
on
generate
command.
What
this
does
is
it
generates
a
command
for
you
to
enroll
your
kubernetes
cluster
with
teleport.
So
the
first
thing
it
does.
A
A
A
Let
me
clear
the
terminal
here
and
while
the
container
is
spinning
up,
this
wizard
takes
you
through
another
couple
of
steps
of
setting
up
access
and
testing
the
connection.
I'm
not
going
to
do
this
because
I
don't
have
any
roles
configured
yet
so
I'm
just
going
to
exit
out
of
this
once
this
is
done
so
I'm
not
really
concerned
about
this
timer
that
detects
the
teleport
service.
All
right.
If
I
check
my
pods
now,
okay
get
Pawns
a
you'll,
see
that
my
teleport
agent
is
running.
A
So
if
I
go
back
out
to
teleport
and
click
on
kubernetes
I
should
have
my
cluster
listed.
That's
how
you
enroll
a
kubernetes
cluster
to
teleport
so
from
here.
I
can
connect
to
the
cluster,
and
you
do
so
by
clicking
connect
and
following
these
instructions,
so
number
one
log
into
teleport.
So
teleport
comes
with
a
couple
of
cli's
there's
the
tctl
CLI
t-cuddle,
which
is
the
administrative
CLI
and
then
there's
this
TSH
CLI,
which
we
can
use
to
log
in
and
log
out,
and
things
like
that.
A
So
the
first
thing
we
need
to
do
is
log
into
teleport
via
the
command
line,
because
that's
where
we're
going
to
be
using
Cube
cuddle,
so
I'm
going
to
paste
that
command
in
here
I'm
actually
going
to
erase
this
last
part,
and
here
I
have
the
proxy
flag
for
my
proxy,
which
is
teleport.
Tr.Astroid.Earth
I
have
my
auth
and
my
user
of
teleport
Dash
admin.
So
this
will
log
me
in
enter
my
password,
my
password
and
then
tap
any
security
key
I'm
using
my
yubikey,
so
tap
that
for
second
Factor.
A
And
there
we
go
I'm
now
logged
into
teleport
via
my
teleport
user
teleport
admin
for
12
hours,
and
this
is
configurable
but
valid
for
12
hours.
I
have
a
12
hour
certificate,
so
I've
logged
in
what
do
I
do
next.
Well,
next,
is
an
optional
command.
You
can
run
to
set
a
different
Cube
cuddle
configuration
we're
going
to
use
the
global,
so
we're
going
to
skip
to
step
two
which
is
select
the
kubernetes
cluster.
A
Now
let
me
show
you
this:
if
I
do
a
cube,
cuddle,
config
view,
you'll
see
that
my
current
context
is
minicube,
we
don't
want
that.
We
don't
want
to
access
minicube
directly,
because
you
know
that's
on
my
local
computer.
We
want
to
access
this
kubernetes
cluster
through
the
secure
functionality
of
teleport.
So
that's
what
this
command
is
going
to
do.
This
is
going
to
issue
us
a
short-lived
certificate,
so
TSH
Cube,
login
minicube
cluster.
A
So
let's
run
this
command.
Let
me
clear
this
run
this
command
logged
into
kubernetes
cluster
mini
Cube
cluster.
Try
Cube
cuddle
version
to
test
the
connection.
Let's
try
that
out
cube
cuddle
version,
all
right,
everything's
working
now,
if
we
do
Cube
cuddle
config
view,
you'll
see
that
my
current
context
is
now
teleport
tr.astroid.earth
slash
minicube
cluster,
so
it
looks
like
we're
using
teleport
and
the
last
command
is
to
connect
to
the
kubernetes
cluster.
So
we
just
need
to
run
Cube
cuddle,
get
pods
so
clear.
This
again,
Cube
cuddle
get
pods.
A
What
do
you
think
is
going
to
happen?
Well,
this
user
cannot
access
kubernetes
unable
to
list
resource
pods.
This
user
cannot
request.
Kubernetes
access
has
no
assigned
groups
or
users.
Why
is
that?
Because
our
teleport
admin
doesn't
have
any
roles.
It
has
no
privileges
to
access
this
kubernetes
cluster.
Even
though
this
kubernetes
cluster
is
enrolled
with
teleport,
we
still
have
our
back
in
place
to
control
who
has
access
to
what.
So,
let's
do
this?
A
With
this
role
and
I'm
actually
going
to
erase
this
kubernetes
users,
because
I
don't
need
that
at
the
moment
and
under
kubernetes
groups
I'm
going
to
put
system
Masters-
and
this
is
never
recommended-
this
gives
you
admin
access
to
the
cluster
based
on
a
system
Masters
default
role
that
kubernetes
has
but
just
for
demonstration
and
this
kubernetes
admins
group.
Let's
do
that
click,
save
changes
and
then
let's
go
to
users
and
my
teleport
admin
user,
let's
edit
and
add
that
role
to
that
user,
so
kubernetes,
admins
and
Save.
A
A
All
right,
great
and
you'll
see
now
that
kubernetes
cluster
says
mini
Cube
cluster
in
our
kubernetes
groups,
for
this
user
is
system
Masters.
So
at
any
point
you
can
do
TSH
status
to
see
your
status
and
now
that
we
have
that
system
Masters
group,
we
should
be
able
to
do
okay
get
pods
and
it
do
it
successfully
because
we
now
have
the
Privileges
to
do
so.
A
And
whatever
else,
so
that
is
the
role
we're
going
to
give
to
teleport
admin,
but
what,
if
we
have
other
users
come
on
the
scene
like?
Let's
imagine
that
we
we
have
this
role.
We
have
these
users
come
in
that
you
just
want
to
give
them
read
access.
They
should
only
be
able
to
read
the
PODS
of
a
kubernetes
cluster,
so
let's
create
a
new
role.
Let's
call
it
developer,
read
and
again,
let's
erase
all
this
stuff,
we
don't
need
it.
A
And
for
kubernetes
groups
I'm
going
to
erase
the
users
also
for
kubernetes
groups.
Let's
imagine
there's
a
group
called
developer
read
this
is
a
developer
read-only
group.
So
let's
save
this
and
what
we're
going
to
do
is
we're
going
to
create
some
roles
in
kubernetes.
So
this
is
not
teleport.
This
is
kubernetes
related
and
I
have
some
examples
that
we're
going
to
use
so
we're
going
to
create
a
role
in
kubernetes,
called
Dev.
A
Read,
resources
will
be
pods
and
pods
slash
log
and
the
verbs
will
be
get
list
watch
so
a
read-only
role,
then
we're
going
to
create
a
role
binding,
called
Dev,
read
binding
that
binds
this
role.
This
Dev
read
role
to
a
group
called
developer,
read
so
let's
go
ahead
and
do
that
and
actually
I
have
both
of
these
roles
already
on
my
system.
So
let
me
just
apply
that
so
Cube
cuddle
create
Dash,
F,
Dev,
read
role,
I
think
it's
called.
A
All
right
and
then
we
create
the
role
binding
and
again
this
is
not
teleport.
This
is
just
kubernetes.
This
is
creating
a
group
in
kubernetes
called
Dev
read
that
only
has
read
access
to
pods
so
now
in
teleport.
This
role
that
we
created
edit
gives
access
to
a
kubernetes
group
called
developer,
read,
which
is
the
the
group
that
we
just
created
in
kubernetes.
A
A
So
let's
save
that
and
here's
a
link,
an
invite
link
that
I
would
send
to
bomb
so
I'm
going
to
send
this
link
to
Bob
he's
going
to
click
on
it
and
set
himself
up
so
get
started.
Bob,
let's
create
a
password
for
Bob
and
click
next
and
we're
going
to
use
a
Hardware
Key,
try
another
way
in
a
USB
security
key,
which
is
my
UB
key
and
registration,
successful
great.
A
A
A
A
A
And
now,
if
we
go
back
to
team
and
rolls,
if
you
look
at
this
role,
developer
read
and
go
to
edit
there's
a
section
called
kubernetes
labels
that
has
these
two
stars.
This
means
that
basically,
you
can
access
any
cluster,
given
that
you
have
the
right
group
or
the
right
other
access,
but
this
labels
gives
you
access
to
clusters
with
any
label.
Well,
remember
we
added
here
this
EnV.
If
we
go
back
to
kubernetes,
we
added
this
EnV
Dev
label.
A
So
let's
say
that
this
developer
read:
we
only
wanted
them
to
access
prod
clusters.
We
could
come
in
here
and
do
EnV
prod
and
then
I
can
maybe
change
the
name
to
developer,
read
prod,
but
what
this
is
going
to
do
is
this
is
going
to
take
Bob
and
not
allow
him
access
to
that
cluster,
because
that's
a
Dev
cluster.
He
only
now
has
access
to
product
clusters.
So
there's
a
lot
of
ways
you
can
limit
access
for
your
users
now.
The
final
thing
I
want
to
look
at
in
this
demo
is
audit
logs.
A
So
if
you
go
to
activity
and
go
to
audit
log,
we
can
see
everything
that
everybody
did
and,
more
importantly,
all
the
cube
cuddle
commands
ran
now.
Remember:
Bob
has
access
to
the
developer,
read
group,
so
everybody
using
that
developer
read
group.
The
logs
are
not
really
going
to
help
us
a
lot.
We're
going
to
see
that
somebody
used
developer,
read
developer,
read
different
people.
A
Well,
this
audit
log
is
going
to
show
us
which
user
did
what
with
lots
of
info
so
right
here,
kubernetes
request
user
Bob
received
a
200
from
get
pods,
so
this
tells
us
that
Bob
ran
the
cube
cuddle,
get
pods
command
to
this
kubernetes
cluster
minicube
cluster.
Imagine
if
you
had
15
clusters
and
50
users,
you
would
be
able
to
see
the
audit
logs
for
every
individual
person
here.
If
you
need
details
on
it
there.
A
It
is
more
information
here
in
the
details
button
we
see
here
that
Bob
got
a
403
when
he
tried
to
get
services
so
that
audit
log
is
very,
very,
very
helpful
for
teams.
So
here's
a
diagram
of
what
we
just
saw
so
the
users
are
going
to
do
this.
Tsh
login
to
log
into
the
teleport
cluster
from
there
from
their
machine
they
can
run
Cube
cuddle,
get
pods
or
whatever
commands
to
the
kubernetes
cluster.
At
no
point
do
they
access
the
cluster
directly.
They
only
talk
to
this
teleport
proxy.
A
A
So
here's
a
bit
of
a
backstory
a
few
years
back
I
got
put
on
a
team
and
none
of
us
really
knew
a
lot
about
kubernetes
or
containerization,
and
we
were
asked
to
contain
our
eyes
a
lot
of
apps,
create
Helm
charts
for
those
apps
and
deploy
them
into
kubernetes.
So,
going
back
to
that
first
diagram.
We
started
that
journey
of
learning,
kubernetes
and
containerization,
and
we
thought
we
knew
a
lot.
So
we
got
these
applications
containerized.
A
We
figured
out
Helm
charts,
we
created
Helm
charts
and
we
deployed
them
to
kubernetes,
but
we
were
application
developers
once
that
application
was
running
we,
you
know
high
five
checked
it
off
the
list,
we're
good
to
go.
We
didn't
think
much
about
pod
security
because
we
didn't
know
a
lot
about
it,
but
pod
security
is
very
important
if
you're
pulling
images,
Docker
images
or
Helm
repos
from
third-party
websites,
they
possibly
could
introduce
problems
like
root
access
or
some
misconfigurations
that
weaken
your
cluster
security
and
the
reason
I
gave.
A
That
example
is
because
there
are
are
a
lot
of
app
talented
application
developers
that
containerize
applications
they
throw
them
into
kubernetes
and
they're
good
to
go.
They
don't
know
a
lot
about
maintaining
kubernetes
and
kubernetes
security,
they're
they're
not
really
supposed
to
they're
application
developers,
but
you
need
somebody
on
your
team
to
overlook
that
security.
So
when
it
comes
to
yaml
configurations
that
are
introduced
to
the
environment
or
containers
that
come
into
the
environment,
they
need
to
be
audited.
Now
you
can
do
this
manually
by
having
someone
or
a
team.
A
You
can
also
utilize
security
contexts,
as
you
can
see
here,
there's
a
security
context
on
this
pod
with
run
as
non-root
as
true
and
what
this
does.
If
you
have
this
setting,
the
cubelet
will
refuse
to
start
any
image
that
defaults
to
the
root
user.
So
hopefully,
when
you
containerize
your
application,
you
set
a
user
ID
and
a
group
ID,
but
sometimes,
if
you're,
not
careful,
those
containers
will
come
over
with
root
access
and
by
setting
the
security
context
setting
it
will
refuse
to
start
the
image
that
defaults
to
the
root
user.
A
That's
another
protection
and
there
are
more
security
contacts
things
you
can
look
into.
You
can
see
it
here
on
the
API
page,
so
again
make
sure
your
yaml
and
your
containers
are
audited
when
they
come
into
the
ecosystem,
either
manually
or
with
vulnerability
scanners
and
then
use
tools
like
the
security
context.
To
make
sure
none
of
your
pods
are
running
as
root
and
with
number
five
being
done.
That
leads
us
to
our
conclusion.
So
again,
five
things
to
check
on
your
default
cluster
is
number
one.