►
From YouTube: Security Self Assessment: Cluster API - Part 1
Description
Part of Kubernetes SIG Security under CNCF
A
A
We
will
start
going
through
the
working
dock
and
see
what
needs
more
content,
and
if
there
are
new
github
issues
that
are
coming
out
of
the
discussion,
those
can
be
something
we
can
also
link
to
this
talk
so
that
we
know
that
those
two
things
are
related
might
be
useful.
There
may
be
to
use
some
sort
of
a
label
to
filter
on
all
of
these
issues
that
are
related
to
this,
but
something
we
can
do
later.
B
A
Sorry
I
went
on
mute.
Do
you
think
we
can
keep
this
diagram
aside
for
now
and
start
with
a
high
level
diagram
first,
where
we
very
very
at
a
ten
thousand
twenty
thousand
feet
level
explanation
of
how
cluster
api
components
will
interact
with
each
other
and
then
kind
of
keep
driving
deeper
and
deeper
as
we
go
from
there.
A
Basically,
the
idea
is
there
are
each
box
represents
a
component
arrows
represent
the
flows
from
and
to
then
there
are
trust
boundaries
which
can
be
sometimes
network,
firewalls
or
actual
physical
boundaries
of
regions
or
data
centers,
which
we
have
to
draw
with
dotted
lines
sometimes,
and
then
there
are
ports,
sometimes
that
we
also
use
in
the
data
flow
diagram,
to
explain
that
these
ports
are
open
and
these
ports
from
this,
and
this
component
talk
to
each
other.
So
I'm
thinking
of
kind
of
starting
from
there.
A
We
can
also
create
cluster
boundaries
for
the
management
cluster
and
then
workload
cluster
and
then
sort
of
continue
how
how
to
go
from
there.
So
I
I'll
start
drawing
this
diagram
from
scratch.
With
all
of
you
help
me
and
tell
me
what
to
draw
I'm
kind
of
your
pen
right
now,
and
then
we
can
kind
of
we'll
see
how
far
we
go.
C
No,
I
the
only
thing
I
would
comment.
Is
you
know
it's
probably
not
as
important
for
for
this
exercise
to
you
know
annotate
the
ports,
you
know,
maybe,
if
we're
starting
to
do
scans
or
something
that'll
be
useful
to
document
somewhere,
but
I
think
it'd
be
more
important
to
indicate
you
know
at
least
some
form
for
a
little
lock
icon
or
use
different
colors.
But
you
know
where,
where
the
encrypted
data
flows
are,
where
you
know
where,
if
there's
any
sensitive,
keying
materials
stuff
like
that,
that
yeah.
A
A
A
A
A
A
A
B
A
A
B
If
we
take
the
default
case
for
kaffir,
then
yeah
so
yeah,
it's
a
vpc
boundary
and
the
default
case.
Just
because
the
way
this
sort
of
quickstart
works
is
we're
exposing
the
api
server
endpoint
of
the
workload
cluster
on
the
internet,
so
that
on
using
the
elastic
load
balancer.
So
the
instances
are
on
private
subnets.
A
Okay
sounds
good,
so
we
have
two
boundaries
established
now.
Let's
take
a
point
in
time
where
workload
cluster
does
not
exist,
management
cluster
exists
and
the
end
goal
for
this
flow
would
be
workload.
Cluster
exists
and
management
cluster
continues
to
exist
as
well,
and
then
we
can
go
through
the
next
iteration
of
adding
a
node
or
deleting
a
cluster
or
creating
another
cluster
and
how
those
two
workload
clusters
if
they
at
all
they
interact
with
each
other.
A
A
B
B
B
A
A
B
B
A
D
A
B
Certainly
in
the
default
case,
if
you
want,
I
mean
I
don't
want
to
complicate
things
right
now,
but
what
what
people
do
and
if
you
look
at
our
product
so,
like
you
know,
tanty
frame,
fancy
kubernetes
grid
or
something
you're
going
to
create
a
self-managed
cluster.
At
the
end
of
this,
and
quite
often
you're
going
to
run
the
cappy
components
co-located
with
the
control
plane,
but
I
don't
think
well,
I
think
we
can
come
to
that
as
another
snapshot
in
time.
Maybe,
okay.
A
Yeah,
I
think
that
makes
sense
so
for
now
we'll
assume
both
are
in
the
same
node.
So
that's
why
we
have
this
node
boundary,
which
means
that
these
two
components
exist
in
the
same
node
anytime.
We
know
for
sure
some
component
is
in
a
different
node,
we'll
create
another
one
that
will
be
similar
to
this.
So
just
keep
this
in
mind
as
we
continue.
B
A
B
A
B
B
We
need
to
create
a
we.
We
need
to
create
some
network
for
in
which
the
cluster
is
going
to
live
in.
So
that's
that's
a
aws
cluster
resource
and
then
a
control
plane
is
going
to
spin
up.
Well
it's
to
create
a
control
plane.
We
need
to
create
some
machines,
so
there's
a
dual
representation
in
sense,
so
the
core
controllers
have
a
machine
resource
and
then
the
infrastructure
providers
have
an
intro
machine
resource.
So
I
guess
I
can.
I
think
we
can
probably
put
on
now
their
other
controllers.
I
guess
so.
B
B
C
A
B
D
A
A
A
Okay,
interesting,
okay,
and
where
would
that
be
located?
You
can
store
them
on
the
api
server
sequence
right.
So
why
api
server
into
xcd,
yeah,
okay,
so
we'll
and
correct
me
if
I'm
wrong
in
this
whole
thing,
whatever
happening
in
this
node
boundary
that
we
have
created
will
be
common
for
all
the
nodes
of
the
control
plane
nodes
right.
It's
just
like
one
instance
of
things
happening,
but
the
same
thing
can
happen
in
second
node.
Third,
node
of
the
control
plane,
cluster.
A
B
A
A
A
A
B
So
once
it's
created
a
bunch
of
key
material,
the
the
control
plane
controller
is
going
to
create
a
machine
resource
a
and
stamp
out
a
bootstrap
config
resource
to
match
the
machine
and
an
infra,
an
aws
machine
resource
to
match
the
machine.
So
there's
only
if
you've
got
machine
resources
and
a
corresponding
cube,
adm
config
resource.
C
B
B
A
B
B
A
B
D
A
A
B
B
A
A
A
B
A
B
Yeah,
so
it
it,
I
mean
it
just
keeps
pinging
dns
see
if
that
elb
is
alive
and
eventually
it's
there
once
we
got
that
the
aws
controller,
given
all
the
other
coordination,
that's
happened
with
the
cloud
in
it
being
generated.
It's
now
ready
to
it
create,
goes
back
to
dc2
api
actually
and
creates
a
ec2
instance.
B
A
B
Oh
yeah,
that's
true
yeah,
so
this
is
the
yes
you're
right.
I
have
forgotten
about
that.
Also.
This
is
more
representative
of
the
other
providers,
so
the
default
behavior
for
aws
is
actually
different,
so
yeah,
so
the
default
behavior
for
aws
is
actually
before
sorry
before
we
create
the
machine
we
call
out
to
another
api
as
which
is
aws
secrets
manager.
So
the
secrets
manager,
api.
B
B
B
F
B
A
B
A
A
B
No,
that's
fine.
I
mean
to
be
fair.
It's
not
generally
well
understood
this
process,
even
within
the
cluster
api
community,
some
extent.
So
it's
this
is.
This
is
spelling
it
out
like
this
is
really
helpful,
so
we've
got
so
and
then
we've
got
another
component.
I
guess
it's
within
well
I
mean
it's
on
the
aws
boundary,
it's
not
on
the
internet,
it's
the
hypervisor
boundary.
I
guess
so.
We've
got
the
instance
metadata
service.
A
B
A
Okay,
got
it
all
right,
so
probably
worth
mentioning
here.
Notes
notes
are
assumed
to
be
vms,
all
right
and
then
you're
saying
there
is
a
hypervisor
boundary
between
the
physical
node
and
this
vm,
and
there
is
a
component
that
exists
on
the
physical
node
that
can
interact
with
this
vm,
which
is
called
instance
metadata
service.
Correct.
B
A
A
A
B
A
B
B
B
B
A
A
A
B
B
A
B
A
B
A
A
B
A
B
B
B
A
A
B
A
B
B
A
And
I
think
that
makes
sense,
it
would
need
it
for
sure
okay.
So
I
think
that
makes
sense
to
me
so
now,
after
it
fetches
the
user
data,
which
is
essentially
the
ca,
search
and
private
keys,
it
stores
it
locally
and
then
deletes
it
in
secrets,
manager,
api,
yeah,
okay,
so
then
the
secrets
manager
repair
doesn't
have
it
anymore.
A
A
C
A
A
G
B
A
B
Yeah,
so
I
think
now's
the
time
to
bring
it.
So
the
we've
got
that
we've
got
the
real
user
data
now,
which
has
all
the
key
material
cloud.
Init
restarts
and
executes
the
real
user
data
yaml
and
now
at
some
point
it's
going
to
execute
cube
adm
you
can
do
a
whole
bunch
of
other
stuff,
but
the
bit
that
we
care
about
is
cuba.
Idm.
A
B
A
A
A
Okay,
make
sense
so
that
changes
my
color
all
right
so
for
anyone
listening.
The
reason
for
asking
this
question
is:
cubedium
is
sort
of
the
most
important
thing
for
cluster
api
and
without
that
it
would
be
very
hard
to
do
what
we
are
able
to
do.
So.
This
is
probably
the
most
important
thing
or
component
in
this
whole
flow.
That
makes
things
possible.
B
A
B
Cloud
in
it,
so
one
of
so
along
with
the
key
material
there's
also
a
cube
adm
configuration
that
was
generated
by
the
bootstrap
controller.
So
we
execute
cube
adm
in
it
with
that
yaml
file
and
all
the
ca
bits
and
pieces
as
and
cube
adm
in
it
is
going
to
drop,
was
gonna
drop.
The
key
material
into
the
correct
locations
on
disk,
create
the
static
pod,
manifest
that
and
start
or
restart
kubelet.
A
B
A
A
A
B
A
B
They
should
start.
We
also
do
kind
of
have
a
presumption
that
the
oci
images
are
pre-staged
on
the
machine
like
it,
it's
not
going
to
have
to
go
out
to
the
internet
to
pull
down
those
images.
It's
not
a
requirement,
but
in
order
to
have
consistent
boot
times,
we
consider
the
core
kubernetes
images
to
be
pre-bait.
A
A
A
A
B
G
I
mean
it's
kind
of
complicated,
but
eventually
you
get
a
valid
client
certificate
from
the
side
by
the
controller
manager,
and
you
don't
really
need
a
socket
to
communicate
between
the
two
components.
The
way
you
bootstrap
is
for
cube
adm
to
write
these
files
on
disk
and
trigger
restarts
of
the
kubernetes
so
that,
basically
it
it
eventually
boosts
throughout
the
load.
B
A
G
A
B
Let's
assume,
then:
we've
got
our
we've
got
our
control
plane
running
okay,
so
at
this
point
hold
on,
let's
see,
there's
a
couple
controllers
that
could
be
talking
to
we've.
We
now
have
at
least
the
capi
core
controller
and
the
control
plane
controller
talking
to
the
api
server
and
wired
a
load
balancer.
A
A
A
B
D
B
The
control
plane
endpoint,
that's
recorded
in
the
cluster,
which
is
going
to
be
the
load
balancer,
so
it
doesn't
really
have
a
way
to
talk
to
the
node
directly
because
node
is
on
the
private
ip
address,
it's
not
on
the
internet.
So
it's
only
going.
It's
only
ever
going
to
be
mediated
through
the
elastic
load.
Balancer.
C
A
B
It's
it's
more
or
less
running.
I
think
we
need
to
report
yeah
I
mean
it
will
be
running,
it'll,
be
a
single
node,
but
it
will
be
running.
The
workflow
is
a
bit
marginally
different
for
a
worker
node
in
the
sense
that
we're
not
shoving
key
material
around
and
even
actually
for
a
second
control
plane
instance.
So
right
it
changes
a
bit
then,
but
we
do
otherwise
have
a
running
cluster.
A
A
A
A
Potentially
we
could
give
everyone
a
break
for
a
week
after
as
well.
I
need
some
time
to
kind
of
get
myself
up
to
normal
energy
after
kubecon,
maybe
end
of
october.
We
can
see
if
we
can
meet
again
and
kind
of
continue
from
there
in
the
meantime,
I'll
make
this
diagram
a
bit
better,
potentially
put
it
in
the
document
and
see
if
see,
if
we
need
to
do
anything
else
next
time.
What
what
do
everyone
think
about
this.
A
A
B
Yeah,
maybe
actually
one
thing
that
came
to
mind
is
like
there
is
an
interesting
point
that
we've
created
this
machine
and
we've
we've
said:
there's
a
bunch
of
prerequisites
on
it,
but
yeah
the
that
machines,
the
templates
come
from
somewhere,
the
image
has
come
from
somewhere
and
we've
also
how
how's
the,
how
we
told
the
ec2
api
to
you
to
get
that
to
use
that
particular
image
as
well.
So
I
don't
know
how
best
to
represent
it.
A
B
C
A
G
The
same
applies
to
custom
image
repositories.
If
somebody
gives
you
a
corrupted
api
server
or
something
like
that,
you
can
potentially
take
all
those
api
calls
into
something
with
them
or
use
mining
or
whatever
yeah,
so
is
anything
that
is.
Custom
feels
like
a
potential
entry
point
for
security,
breach
it's
in
the
hands
of
the
user,
to
make
sure
it's
not.
A
Compromised
yeah
yeah
exactly
I
mean
essentially
the
core
point
of
always
have
your
trusted
users
as
admins
for
control,
plane,
cluster
and
workload
cluster,
because
otherwise
they
can
essentially
do
anything
they
want
so
yeah.
I
agree
I
may
have
something
that
comes
to
mind
when
managing
privileged
user
actions
or
a
malicious
insider
scenario.
A
Do
we
have
any
auditing
enabled
by
default
for
control,
plane,
api
server
control,
plane
clusters,
api
server,
where,
if
somebody
puts
in
something
that's
malicious
or
a
new
image,
is
requested
from
ec2
api?
Do
we
have
audit
logs
that
we
can
go
back
and
check
like
did
that?
Did
this
person
really
do
this,
and
when
did
when
did
this
happen?.
B
You
mean
on
the
management
cluster,
that's
no!
Not
by
all
right.
I
mean,
if
they're
doing
the
kind
bootstrap
workflow,
no
not
by
default,
but
then
they're
only
acting
on
their
local
laptop
anyway.
So
that's
not
really
useful.
So
it's
going
to
be
up
to
the
cluster
operator
who's
operating
that
management
cluster,
that
they're
setting
up
some
auditing
on
there.
G
G
We
do
not
perform
a
check
against
a
specific
share
against
a
specific
tag
to
verify
that
this
image
is
the
original
one.
We
don't
signal
any
warnings
to
the
user.
The
we
basically
guarantee
that
the
only
secure
images
are
those
that
we
they
can
pull
from
gcr
those
have
the
sha's
checksums.
Everything
is
valid
there,
but
the
moment
you
establish
a
custom
repository
it
it's
in
the
hands
of
the
user,
to
verify
right.
B
B
We
build
node
images,
okay,
using
packer
from
our
laptop
using
the
upstream
image
builder
project
right
and
store
them
in
that
in
a
specific
ec2
account.
So
if
you
don't
specify
an
image
id,
it's
just
going
to
go
and
look
for
them
there.
So
it's
taken
on
trust
from
us,
okay,
yeah
and
it,
but
that
account
is
I
it
is
secured
with.
Is
I
think
it
pretty
serious
too?
If
I
can't
remember
but
yeah,
I'm
sorry.
A
B
A
A
I
think
I've
got
a
lot
from
this
for
sure.
Hopefully,
this
was
useful
for
everyone
as
well
any
fighting
thoughts,
and
we
could.
We
should
probably
plan
for
a
break
next
time
if
we
are
gonna
meet
for
90
minutes
or
more.
I
apologize
for
forgetting
about
that
today,
yeah
any
anything
else
before
we
drop
off
and
I'll
schedule
something
for
future,
but
want
to
give
five
minutes
for
everyone
else
to
join,
and
especially
folks
who
have
been
quiet
throughout
the
call
anything
you
want
to
share
go
for
it.