►
From YouTube: Kubernetes SIG Security 20220127
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
Okay,
so
it
is
now,
oh
three,
so
I
think
we
might
start
the
meeting.
If
you
have
not
added
yourself
to
the
attendance
list,
then
I
recommend
doing
so.
Oops
we
just
do
name
and
pronouns
there.
A
So
first
thing
on
our
agenda
for
the
day
is
introductions
hi.
My
name
is
ian
coldwater.
I
am
the
co-chair
of
kubernetes
security
and
if
you
are
trying
to
go
to
a
different
sig
meeting
you're
at
the
wrong
one,
but
that's
okay,
we're
happy
to
see
it
anyway.
A
I
am
a
director
of
offensive
security
at
twilio
and
I
like
to
hack
things
and
make
friends,
and
I'm
super
happy
to
be
here.
I
love
you.
B
All
right
I'll
go
next.
My
name
is
ray.
I
am
a
field
engineer
for
susa
by
way
of
ranch.
Labs
also
was
the
1.23
cobra
nice
release
lead,
I'm
the
incoming
sig
docs
co-chair
as
well.
So
I'm
also
the
work
on
or
help
work
on.
The
third
party
audits,
which
I
will
provide
an
update
shortly,.
C
Well,
I'm
rory,
I'm
a
cloud
native
security
advocate
at
aqua
and
I
help
a
bit
on
the
dots
project
and
sig
security
project.
D
I'm
eric
I'm
a
senior
developer
advocate
at
sneak
and
I'm
here
to
help.
E
F
H
Hi,
I'm
mohit,
I'm
a
f-secure
security
consultant.
I
and
I
lead
the
kubernetes
containerization
orchestration
stuff
on
that
site.
I
Hello,
my
name
is
jimmy
ray.
I
am
a
kubernetes
d.a
for
aws,
and
this
is
only
my
second
meeting
here.
So
I'm
really
just
trying
to
get
a
feel
for
what's
going
on
here
and
my
my
background
is
mostly
compliance
and
governance
with
respect
to
kubernetes.
So
I'm
also
looking
at
the
policy
groups
and
sigoth.
J
Hi
everyone
I'm
james,
feberly,
france.
I
work
at
control
plane
and
I'm
a
security
engineer.
It's
my
first
meeting
so
just
looking
to
help
out
really
welcome.
K
Hello,
I'm
hello,
I'm
mae
from
quest
lab
working
as
a
rnd
engineer
and
working
all
about
on
community
security,
and
I
want
to
make
some
contribution
here
so
so
I'm
here.
N
Hi
I'm
alex
alton.
I
work
at
zura
here
in
northern
california
and
I'm
one
of
the
lead
engineers,
security
infrastructure,
engineers
working
on
kubernetes
and
ci
cd
type
stuff
and
I'm
hoping
to
find
something
to
work
on.
Although
it's
got
to
be
kind
of
like
a
weekend
type
work.
So
it's
hard
to
do
it
during
the
week.
A
Fair
enough,
all
right
so,
first
off
on
the
agenda,
we
have
subgroup
reports
and
first,
where
the
our
subgroups
get
to
talk
about
what
they're
up
to
and
first
on
that
one
is
our
third
party
audit
subgroup.
So
what's
up
with
third
party
odds,
things.
B
Yeah,
so
I
we
did
formalize
the
contracts
and
the
msa
that
was
announced
last
week.
I
was
not
on
the
call
last
week
I
just
had
a
new
baby
and
we
had
some
health
issues,
but
baby's
been
fine,
so
we've
been
in
now
the
hospital
so
we'll
have
a
formal
announcement.
That's
been
sort
of
delayed
because
I've
been
in
and
out
we'll
get
a
pr
open
shortly
with
that
formal
announcement.
B
Also,
aside
from
that,
we
are
talking
about
timeline,
so
once
we
get
a
timeline,
a
rough
timeline
involved
we'll
do
a
more
formal,
kickoff
and
I'll
send
out
a
doodle
for
those
who
are
interested
I'll
put
it
on
the
slack
channel
for
those
who
aren't
interested
to
send
to
dm
me,
their
email
sit
down
at
doodle
for
a
kind
of
more
of
a
kickoff
or
kick
off
once
we
get
a
form
once
we
get
more
timelines
situated.
B
So
that's
going
to
come
up
next
few
weeks
or
so
or
so.
I
do
have
a
call
with
the
project
manager
on
the
vendor
side.
So
we'll
see
what
that
timeline
looks
like
shortly.
K
A
Next
up
we
have
sig
security,
docs.
E
I
think
savita
is
out
today,
so
maybe
rory
you
can
talk
or
add
what
I
will
share
on
behalf
of
her
so
looks
like
the
admission
controller
threat
model
and
block
prs
were
merged,
which
is
great
kudos
to
rory,
and
so
many
others
who
contributed.
I
think
they
are
very
well
written
and
pro
probably
a
good
contribution
in
the
overall
security
community
and
then
shout
out
to
mahi
who
did
his
first
contribution
to
kubernetes.
E
I
think
it
just
got
merged
yesterday,
so
great
job
and
kudos
to
savita
for
creating
a
good
first
issue
and
thanks
to
all
the
sick
dogs,
tech
lead
who
shannon
and
tim,
who
both
helped
out
very
well.
For
my
to
get
it
working.
A
E
Okay
sounds
good,
so
tooling,
couple
of
updates.
We
have
a
vulnerability
scanning
job
that
has
been
running
for
a
few
months
now.
It
was
down
for
a
good
reason,
but
we
have
a
pr
that
fixed
it
and
the
docker
shim
deprecation
sort
of
also
helped
to
get
it
back
up
and
running.
So
it's
now
running
if
you're
wondering
what
is
this,
what
does
it
do
happy
to
chat
more
about
it
offline
or
on
in
the
meeting,
and
then
second
update
is.
E
We
are
also
working
on
creating
a
cve
feed
of
src
announced
known
kubernetes
cvs
that
are
fixed,
so
there
were
a
couple
of
proposals
of
how
to
implement
it.
We
discussed
it
with
sigdoc's
technique,
tim
and
neha,
and
so
we
have
two
options
now
and
it
gave
a
good
sort
of
push
for
us
to
now
create
really
like
a
draft
cap
for
this.
E
So
I
think
that's
going
to
be
my
next
action
item,
which
will
be
a
very
short
cap,
which
is
kubernetes
enhancement
proposal
that
describes
how
we
are
going
to
implement
this,
and
then
we
can
get
feedback
from
src
from
sick
dogs
from
maybe
sick
release
and
everybody
else
in
the
call
as
well.
So
that's
update
for
tooling.
I
can
continue
to
the
self-assessments
if
no
more
questions,
but
I
want
to
pause
for
questions.
A
E
E
Okay,
so
next
one,
if
no
questions
and
again
you
can
ask
questions
later
on
security,
tooling
channel
the
self-assessments
we
have,
we
have
been
doing
our
first
self-assessment
for
cluster
api.
I
think
we
started
around
may
june.
Robert
has
been
involved
there
as
well,
so
we
are,
in
the
end,
stay
end
game
now
using
avengers
example,
where
we
pretty
much
have
a
list
of
threats,
we
have
more
or
less
agreed
on
the
threats,
whether
they
are
valid.
Some
work
needs
to
be
done
to
rewrite
or
revisit
some
of
them.
E
If
you
have
subscribe
to
the
security,
google
group
will
be
the
last
one
and
after
that
we
will
essentially
create
a
pr
with
all
of
the
details
inside
along
with
some
diagrams
that
we
came
up
with
and
then
the
idea
is
based
on
that
pr
once
it's
there.
E
All
of
the
mitigations
that
need
to
be
implemented
would
be
converted
to
github
issues
in
cluster
api
repo,
and
then
people
will
start
picking
it
up
and
we
also
get
an
opportunity
to
pick
it
up
and
implement
some
new
things.
So
I
know
some
folks
who
are
looking
for
some
implementation
or
some
new
work
to
do.
I
think
this
will
give
a
lot
of
good
opportunity
for
all
of
us
to
contribute.
E
E
A
Next
we
have
the
open
discussion
section
and
for
people
who
are
newer
to
seek
security,
we
generally
have
an
open
discussion
session
so
that,
if
you
have
thoughts
on
things
that
you've
been
thinking
about
in
relation
to
kubernetes
security,
something
that
you
have
questions
about
something
that
you're
excited
about
learning
about
something
you're.
You
have
concerns
about
something
you
know
you
have
ideas
or
just
want
to
come
to
bring
to
talk
about.
That
is
the
space
for
absolutely
everybody
to
come.
Do
that
and
we
are
what
the
community
makes
it.
A
So,
if
you
have
any
of
those
feel
free
to
stick
it
on
the
agenda
and
we'd
love
to
talk
about
it
with
you,
the
first
thing
on
the
and
currently
the
only-
but
I
don't
know
if
anybody
has
added
anything
yet
on
the
discussion.
Section
is
ian
smart
and
rory
talking
about
some
interesting
and
well
less
well-documented
things
they
found
about
node
proxy
rights
and
barback.
C
Yep
this
is
well.
This
was
fun
like
this.
Is
I
learned
something
new
anyway?
That's
for
sure,
so.
I've
linked
to
hackmd,
where
I
just
like,
hopefully
got
all
the
relevant
information
down
for
reading,
but
I'll
kind
of
like
explain
what
it
is.
Essentially,
the
kubernetes
api
server
is
a
proxy
and
you
can
use
it
to
get
access
to
other
things.
C
You
can
use
it
to
access
the
pods
services
or
nodes,
and
that
means
you
essentially
get
connections
that
come
like
directly
from
the
api
server,
which
is
a
useful
piece
of
functionality
and
but
what
we
realized.
We
were
poking
around
on
this
feature.
Usually
when
you
use
it,
it's
unauthenticated,
so
the
connection
hits
whatever
service
you're
getting
to
without
credits.
C
C
So,
with
the
api
server
proxy,
you
can
do
things
like,
for
example,
list
all
the
pods,
even
if
you
don't
have
get
pod
rights.
So
that's
the
first
kind
of
security
architecture.
Point
is,
if
you,
you
have
node
proxy,
but
you
don't
have
get
pods.
You
still
have
get
pods
because
you
get
it
through
the
cubelet
and
that
was
kind
of
fun,
and
that
was
kind
of
interesting
weird
and
we
were
like
this
is
really
odd.
We
don't
know
why
this
is
doing
it.
We
thought
this
might
be
a
cv.
C
Initially,
we
went
through
the
whole
hacker
one
src
and
after
at
the
end
that
we've
concluded
it's
not
it's.
This
is
by
design
the
possibly
more
interesting
bit
or
it
was
to
me
anyway,
because
it
was
surprising,
is
you
can
go
directly
to
the
cubelet
api
with
credentials
that
have
got
node
proxy
rights
to
the
main
kubernetes
api?
So
if
you've
got
a
user
or
a
service
account,
who's
got
node
proxy
to
the
kubernetes
api.
They
can
talk
to
the
cubelet
api
directly.
C
This
bypasses
audit
logging
and
it
bypasses
admission
control
because,
if
both
of
those
things
only
work
on
the
api
server,
they
don't
work
on
the
cubelet,
so
anyone
who's
got.
Those
rights
can
basically
execute
commands
inside
pods,
or
they
can
list
all
pods,
depending
on
exactly
what
right
they've
got
without
touching
those
two
things,
and
at
the
moment
this
is
kind
of
not
really
called
out
in
the
docks,
and
this
is
why
I
was
saying
I
think
this
is
kind
of
a
docs
issue.
C
C
If
you're,
relying
on
that
for
security,
like
I
will
log
everything
that
happens
via
audit
log,
this
no
longer
holds
because
the
person
can
go
straight
to
the
cubelet
do
stuff,
and
your
audit
log
will
show
nothing
which
is
kind
of
not
great
from
an
architecture
security
standpoint.
So
that
was
like
what
we
found.
We
found
this
kind
of
by
accident.
It
was
ian's
idea.
He
was
doing
something
and
got
and
like
was
what.
G
What
the
heck's
this
one
of
my
colleagues,
found
out
about
service,
slash
proxy
and
went
what
the
heck's
this
thing
and
it
sent
us
down
this
rabbit
hole.
I
think
one
of
the
interesting
things
to
realize
as
well
is
that
node
proxy
create
permissions
effectively
map
to
the
read,
write
permission
to
the
right
permission
on
the
cubelets
and
in
some
of
our
test
environments.
This
can
lead
to
code
execution
in
control,
plane
containers.
G
So
if
you're
a
particularly
nasty
attacker,
you
could
use
it
to
launch
xcdctl
in
the
control
plane
and
then
just
dump
out,
like
literally
everything.
So
it's
effectively
cluster
admin,
if
in
in
some
configurations
at
least.
G
C
C
You
know,
so
that's
what
it
does
when
it
says
web.
What
it
means
is,
I'm
gonna
go
talk
to
the
api
server
and
if
you've
got
rights
there
I'll
give
you
rights
here,
which
I
thought
was
kind
of
like
it
was.
It
was,
as
I
said,
it
was
kind
of
a
surprise
anyway.
The
the
the
hack
md's
got
like
manifests.
You
can
try
it
out
with,
and
I've
got
a
little
embedded
video
just
showing
like
doing
it
but
yeah.
C
I
I
was
thinking
that
perhaps
what
we
should
maybe
do
is
like
do
a
docs
page.
That
says
be
very
careful
with
no
proxy.
C
Oh
and
one
last
thing
actually
right
down
the
bottom
I
found
out.
There
was
another
related
issue
with
with
pod
proxy,
where
you
could
get
the
api
server
to
make
connections
to
arbitrary
ip
addresses
by
essentially
updating
a
pod
repeatedly
and
changing
its
ip
address,
and
then,
when
you
say,
go
to
the
pod
ip
address.
The
api
server
says
oh
I'll
go
out
here,
and
that
was
actually
the
kindle
blog
from
2019
that
I
just
totally
missed,
didn't
see
it.
It
got
kind
of
mentioned
in
kubernetes
dev,
but
not
really
anywhere
else.
C
There's
this
then
the
bottom
I'll
I'll
put
it
in
the
yeah.
I
totally
missed
it,
and,
and
it
was
on
it,
I
think
it
was
before
we
were
doing
like
cvs
or
something
or
I
don't
even
know
it
just
it
went
on
kubernetes
and
I
was
like
oh
really,
and
I
only
found
it
because
I
was
digging
around
for
this
so
yeah.
Let
me
let
me
go,
find,
link
yeah,
let's
go
it's
already.
There
awesome.
A
C
E
This
kind
of
access
is
only
going
to
allow
access
to
the
parts
in
the
local
node
right
any
node
any
node
any
node,
because
you're
sorry.
C
C
Yeah
and-
and
it's
the
thing
that
worries
me
about
this
from
an
architecture
standpoint,
security-
is
this
bypassing
audit
logging
and
bypassing
mission
control,
because
that
a
lot
of
people,
I
think,
are
relying
on
those
two
things
to
block
access
and
then
to
order
access,
and
if
they
realize
that,
no
actually,
you
know
what
not
everything's
going
to
go.
The
weird
thing
I
didn't
know
is:
this
is
actually
used
legitimately
by
things
like
prometheus.
C
C
A
C
Yeah
cause,
nothing
does
everything
and
what
he
told
me
was
no.
What
it
is
is
the
cubelet
watches
the
api
server
and
it
sees
a
new
pod,
that's
assigned
to
it,
and
then
it
starts
it.
Based
on
that,
so
there's
no
cubely
api
call
for
start
new
container,
but
you
do
get
command
exec
in
any
running
container.
I
So
you
so
you
you
couldn't
start
a
pod
nope,
but.
D
C
And
yeah,
and
it's
it's
the
bypass
thing
I
mean.
Obviously,
because
I
mean
the
one
people
might
say:
oh
well,
you
know
node
proxy
is
dangerous.
Right
yeah,
I
don't
think
that's
well
known,
but
b.
Even
if
your
cluster
admin
being
able
to
bypass
audit
logging
is
still
an
escalation,
because
you
know
you're
going
to
go
essentially
around
the
side
here
and
none
of
it.
Even
if
you're
thinking,
oh,
doesn't
matter
my
cluster
admins.
Well,
they
have
that
they're
still
being
loved.
We
still
know
what
they're
doing
we
can.
G
The
other
thing
that
I
found
interesting
was
the
fact
that
the
same
permission
lets
you
create
the
proxy
and
actually
do
the
authentication
on
the
cubelet
side
of
things
yeah.
So
you
can.
You
can
open
the
tunnel,
you
can
open
a
corridor
to
the
door
and
then
open
the
door
with
the
same
key
effectively,
which
is
a
bit
odd.
G
Yeah,
it
was
really
bizarre
when
we
were
digging
into
this
in
china
trying
to
work
out
what,
because
at
first,
we
thought
that
the
api
server
was
offering
us
just
to
anything
we
wanted.
Then
we
started
realizing
like
actually
we're
not
able
to
off
to
arbitrary
services
we're
not
able
to
talk
to
the
api
server,
but
cubelet
just
did
work
like
this.
It
was
lots
of
far
too
much
going
through
documentation,
trying
to
work
out
what
the
heck
was
happening.
G
C
I
H
I
mean,
I
guess
admission
control
has
affected
every
request,
so,
theoretically
you
could
have
a
mission
control
that
limits
down
your
execs.
So
it
says,
are
you
only
allowed
to
do
this
kind
of
exec
and
now
now
you
can
do
whatever
exactly
you
want.
C
Yeah
yeah
yeah,
that's
yeah,
that's
it.
I
think
it's
one
of
these
things
that
I
think
if
people
know
about
it,
that's
that's
good,
because
then
they
can
design
differently
and
they
say
I
can't
rely
on
this
to
do
that
which
they
might
have
exactly.
I
would
have
thought
the
same
thing
if
I
would
try
and
lock
down,
execs
use
admission
control,
because
it's
the
standard
thing
kubernetes
will
say
you
want
something:
weird
security,
wise
use,
mission,
control.
I
So,
are
you
suggesting,
like
a
a
way,
a
modification
to
kublet
such
that,
whatever
it
does,
regardless
of
whether
it
comes
from
api
server
or
not
gets
sent
back
to
api
server
for
an
audit.
C
This
this
that's,
the
bigger
question
is:
does
the
kubernetes
project
want
to
actually
make
a
change
either?
Introducing
audit
logging
on
the
kubelet
would
be
one
option
or
in
some
way
hooking
the
cubelet
into
admission
control,
which
feels
super
messy,
I'm
not
sure
what
the
appetite
for
that
will
be,
but
I
think
the
thing
we've
got.
Control
of
the
thing
we
can
do
here
is
we
can
do
a
doxfix,
and
we
say
very
least
everyone
should
know
about
this.
C
A
G
Yeah,
I
guess
at
sorry,
yeah
sorry.
The
other
thing
is
you
can
always
audit
on
the
calls
for
node
proxy
and
then,
if
it's
got
10
to
50
or
something
vaguely
cubility
at
the
very
least,
that
should
be
enough
to
set
off
any
monitoring
alarm
bells,
assuming
you've
got
sock
alerts
or
something
so
there's.
C
Access
request,
if
you
go
straight
to
kubelet,
because
it
has
to
check
when
you
make
the
request
in
it
has
to
actually
check
you've
got
those
rights.
So
it's
got
to
ask,
but
that's
not
a
great
thing
to
audit
on.
I
mean
like
auditing
on
a
subject.
That's
like
so
many
of
those
a
day
that
that
would
be
super
difficult
to
pull
an
audit
on,
but
in
theory
you
could
get
that.
N
E
N
C
I
think
you
might
have
to
on
up
the
kubelet
audit
log
level
I'll
show
the
cubic
log
level
when
I
was
talking
about
it.
If
I
turned
it
up
like
four,
which
is
like
debug
level,
I
started
getting
that
kind
of
detail
out
so
yeah.
I
think
you
could
turn
the
cube
up
to
debug,
but
I
have
a
feeling
that
if
you
don't
do
that,
you
might
not
get
all
you
need,
but
yeah
that
is
another
option.
Is
people
could
try
hacking
a
like
make
the
cubelet
tell
them
more
peace.
I
So
I
mean
the
documentation
that
you're
thinking
of
writing
is
going
to
explain
this
in
detail,
but
then
also
come
up
with
or
at
least
suggest
patterns
for
how
this
could
be
detected,
prevented,
etc.
Yeah.
C
I
mean
it,
it
it'll
have
to
be
generic,
because
obviously
it's
kubernetes
dark,
so
it
can't
do
platform-specific
stuff,
but
we
can
say
things
like
you
know:
limiting
access,
or
at
least
auditing
access
to
the
kubelet,
a
network
level
will
give
you
either
visibility
or
blocking
that's,
probably
the
main
one.
Turning
up
cube
auditing
turning
up
logging
to
debug
would
be
a
kind
of
I'm
not
sure
what
to
recommend.
Obviously,
it's
an
option.
You
want
more
info.
E
A
A
If
the
answer
to
this
is
no
fair
enough-
and
we
can
all
you
know,
go
do
things
with
our
days
that
are
not
this
and
you
know
part
happily,
but
I
do
want
to
leave
space
for
it.
I
A
Oh,
I
have.
I
didn't
write
this
in
the
discussion
because
I
did
not
have
enough
coffee
this
morning,
but
did
everybody
see
that
recent
linux
kernel
cpe
that
allowed
for
container
escapes
in
username
spaces.
C
A
A
Yeah,
I
I
wanted
to
shout
that
blog
out
and
just
mention
it
to
people
if
they
weren't
aware
of
it,
because
it
is
a
sort
of
it's
an
interesting
one,
because
it's
it's
blocked
by
default.
Docker,
because
default
docker
applies
a
second
profile
that
blocks
onshare,
but
kate's
overrides
that
and
therefore
it's
not
actually
blocked
by
kubernetes
natively
without
doing
stuff
with
it.
So
if
you
haven't
seen
the
blog,
it's
worth
taking
a
look
at
it's
a
fun
volume
and
an
important
thing
to
know
and.
I
I
C
Like
to,
I
think
I
didn't
realize
is
when
they
first
had
the
volume
you
could
read
it
and
go.
Oh,
it
needs
caps.
This
admin,
oh
well,
I
don't
really
care
it's
capsis
admin
right,
but
then
it
says
it's
capsus
admin
in
an
unprivileged
username
space
and
I
was
like
what
now
I
was
like.
Oh
you,
if
you
do
unshare
inside
a
ordinary
pod,
you
get
all
the
capabilities
in
that
username
space
which
doesn't
actually
give
you
more
rights,
but
gives
you
the
code
path
needed
to
exploit
this
thing.
D
H
C
C
A
J
I
just
think
it's
my
perspective
very
solid
example
of
why
setcomp's
useful
yeah.
L
J
So
sometimes
people
really
struggle
to
grapple
the
usefulness
of
applying
it
and
it's
kind
of
that
or
my
personal
experience,
anyways
sort
of
the
bottom
issue
in
in
the
report
being
like
it's
a
best
practice
that
you
should
probably
implement
but
yeah,
be
a
really
useful
example.
Going
forward.
E
One
more
thing
I
found
after
reading:
rory's
blog
was,
like
you
said,
docker
second
filter
blocks
and
share.
Then
I
was
wondering
okay,
but
most
people,
probably
at
runtime,
are
using
something
else
like
container
d.
So
what
is
the
profile
for
container
id
turns
out?
It
also
blocks
unshare,
which
was
a
relief,
so
at
least
the
good
work
done
by
the
docker
folks
kind
of
has
continued
and
continuity
in
terms
of
which
filters
to
use.
A
A
Frizzell,
who
did
the
work
in
the
first
place?
She
did
amazing
work
on
that.
O
I
put
a
short
link
to
some
of
my
notes,
so
this
is
not
like
a
published
blog
or
anything,
but
I
published
this
specific
note
that
I
put
in
the
chat
that
describes
how
you
can
use
on
share
to
gain
that
caps
assignment.
So,
if
you're
interested
in
the
how
how
an
attacker
or
you
or
how
a
user
can
gain
caps,
this
admin
that
that
actually
steps
through
the
through
the
process
itself.
A
Anybody
else
have
anything
they're
thinking
or
do
we
want
to
go?
You
know
drink
some
more
coffee
or
whatever
we're
going
to
do
drink
some
cocktails.
If
you're
worried.
C
A
I
think
that
there
was
a
pancakes
con
talk
done
a
couple
years
ago
about
how
to
make
those.
If
you're
curious,
I
think
it
got
recorded.