►
From YouTube: Kubernetes SIG Security 20210701
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
Hello,
everyone,
thank
you
so
much
for
coming
to
another
kubernetes
sig
security.
We've
got
some
some
things
on
the
agenda
here.
Pushkar
is
taking
notes.
Thank
you
very
much
for
that
and
let's,
let's
get
right
into
the
things
that
we
already
have
on
here.
The
first
one
is
audit.
Sub
group
report
ray
tell
us
where.
B
Yes,
so
good
news,
we
do
have
a
fourth
proposal
that
was
submitted,
so
that
means
the
rfp
closing
date
is
now
set
to
july
6
and
the
vendor
announcement
date
is
set
to
july
20..
The
question
closing
period
also
ends
on
july
6th
as
well.
We
will
start
access
reviewing
and
assessing
all
the
proposals
on
july
7th
I
do
have.
I
do
want
to
bring
something
up
to
stick
security
into
the
group
here.
B
We
do
intend
to
have
a
more
private
group
to
do
the
vendor
assessments
just
thought
on
on
the
last
external
audit
security
call
we
talked
about
having
it
either
be
a
re-opt-in
process
or
an
invite
process,
and
either
way
I
would
like
to
have.
The
process
also
include
to
have
folks
who
are
part
of
the
vendor
assessment
to
agree.
B
Excuse
me
degree
with
the
embargo
policy
and
to
agree
with
the
no
conflict
statement
as
well,
and
I
will
have
this
outlined
in
a
pull
request,
so
be
in
one
of
these
six
security
directories
in
github.
Just
thoughts
on
that.
A
Yeah
plus
plus
one
the
the
vendor
assessment
process,
you
know,
could
get
pretty
personal.
You
know
discussing
people's
opinions
of
the
relative
merit
of
the
vendor,
supplied
rfp
responses,
and
you
know
that
that
seems
like
a
thing
where
the
balance
between
our
openness
as
a
community
and
our
you
know
responsibility
to
be
good
citizens
of
the
like
broader
infosec
ecosystem
kind
of
come
into
some
conflict
there
and
yeah
having
that
take
place
in
a
more
private
setting,
so
that
people
can
speak
their
minds
quite
freely
without
having
to
worry
about.
A
D
B
2019
we
did
review
it.
It
was
a
more
informal
process,
so
there
was
only
like
a
handful
of
folks
that
that
was
already
kind
of
in
a
very
private
group,
so
it
was-
and
that's
something
I
want
to
change
as
well-
to
have
a
more
formal
process.
It's
actually
laid
out
in
the
github
repository
for
six
for
six
security,
so
that
folks,
who
do
join
in
the
next
rounds.
You
know
they're,
aware
of
all
the
the
process
and
that
this
is
involved.
A
We
would
love
to
keep
you
all
around
for
the
next
go
around,
but
we
would
also
love
for
you
to
have
other
things
come
up
in
your
life
that
take
you
away
from
it
and
have
a
totally
new
group
be
able
to
come
along
and
and
build
off
of
your
success.
So
yeah
leaving
leaving
documentation
is
a
great
way
to
help
those
future
people
all
right.
A
If
that
is
the
the
story
about
audit
working
group,
I'm
looking
forward
to
lgtming
some
of
those
prs
and
looking
forward
to
hearing
who
who
is
selected
to
do
the
do.
The
assessment
for
docs
savita
would
normally
come
and
tell
us
what's
going
on
with
docs.
She
mentioned
in
slack
that
she
won't
be
able
to.
So
I
will
I
will
announce
the
the
docs
news
here.
A
Grace
who,
I
think
is
on
the
call
with
us
got
her
first
kubernetes
pr
merged,
putting
a
putting
a
warning
in
the
documentation
for
the
coop
config
file,
because
there
are
several
really
wonderful
and
powerful.
Coupe
config
features
that
that
solve
a
lot
of
important
use
cases,
but
also
mean
that
it's
important
to
trust
where
your
coop
configs
come
from
and
that
I
think,
has
not
been
very
well
known
in
the
community.
I
don't
know
of
any
badness
that
has
happened
in
the
real
world
with
people.
A
You
know
mailing
around
malicious
coop
config
files,
but
I
feel
like
letting
people
know
that
they
need
to
look
at
those
things
before
something
bad
happens
is
is
a
great
way
to
be,
and
so
so
grace
wrote
a
wrote,
a
good
warning
into
the
kubernetes
docs
there,
and
now
I
believe,
is
working
on
a
blog
post
to
follow
up
on
that
with
some
more
details.
A
E
Hello,
everyone-
this
is
my
first
security
meeting
so
happy
to
be
here.
I
am
working
on
a
cncf
blog
post
and
chadwitha
helped
me
yesterday,
with
kind
of
figuring
out
the
path
to
write,
a
malicious
cubeconfig,
so
that
one's
great,
I
will
keep
you
all
updated.
A
Thank
you
so
much.
It's
super
super
helpful
and,
like
honestly,
it
was
fun
to
to
hack
kubernetes
with
you
other
other
updates
from
sabita
are
that
you
know
this.
Has
this
has
given
several
more
ideas
for
good
first
issue,
type
of
of
docs
updates
issues
and
so
expect
her
to
be
filing
some
of
those
in
github
soon,
and
just
as
always,
if
there's
something
that
you
don't
like
in
the
docs.
F
F
These
people,
someone
picking
up
this
issue,
may
never
have
worked
with
github
before
they
may
never
have
thought
to
repo.
We
are
really
open
to
people
joining
and
making
their
first
contribution
to
any
open
source
project.
That
way,
so
just
bear
that
in
mind.
That's
the
level
that
we
we
and
sig
docs
are
aiming
for
with
our
good
first
issues.
A
Awesome
that
has
been
the
that
has
been
the
kind
of
level
that
that
we
have
aimed
for
with
the
few
good
first
issues
that
we
have
flagged
in
the
past,
where,
where
yeah
it
gives
somebody,
it
gives
somebody
a
chance
to
learn
about
some
sub-topic
in
kubernetes
security
and
also
to
get
their
feet
wet
with
with
the
tools
and
process
that
we
use
to
actually
update
these
things
so
yeah.
Thank
you.
F
There's
slash
help
so
if
you,
if
you
flag
an
issue
with
slash,
help
and
don't
put
good
first
issue
on
it,
like
that's,
that's
a
sign
that
it's
not
for
your.
Your
your
greenish,
greener
contributors,.
A
F
Yeah
and
that
help
label
you
know,
is
what
am
I
trying
to
say
here.
It's
a
way
of
saying
you
don't
have
to
go
and
research
the
background
to
this
security
topic.
We've
done
that
bit
for
you
that
be
you
know
I
wouldn't
expect
to
have
anyone
do
that
research
with
a
help,
labeled
issue.
A
Yeah
that
makes
that
makes
sense.
Thank
you.
Thank
you
very
much.
So
that's
a
that's
a
good
thing
for
us
to
keep
in
mind
that
some
issues
will
be
good
to
put
good
first
issue
on,
and
others
will
be
good
to
put
help
on
depending
on
where
we
want
to
aim
for
awesome.
A
All
right,
tooling,
I
will
take
over
taking
notes.
While
you
tell
us
about
tooling.
D
A
D
So
we
have
we
had
a
great
fortnight,
I
would
say
from
dueling
group,
because
we
were
able
to
work
on
many
things
and
we
also
have
some
new
members
submitting
prs
as
part
of
it.
So
first
I
would
say
quickly
is
we
have
a
pr
open
that
covers
two
things?
One
is
a
policy
for
managing
vulnerabilities
that
are
related
to
kubernetes
and
how
would
we
resolve
it
based
on
the
category
of
vulnerabilities
that
pr
is
submitted?
D
D
We
will
be
able
to
run
a
scan
on
that
and
figure
out
if
we
are
getting
a
cv
inside
kubernetes
code,
which
may
or
may
not
be
actually
under
code
execution
path,
so
that
job
is
running
today
it
runs
every
six
hours
and
in
the
first
run
we
identified
a
vulnerability
that
was
for
a
transient
dependency.
D
We
were
able
to
push
a
fix
for
it
to
move
it
to
a
fork
that
fixes
it
and,
as
a
result
of
that
now
the
scan
is
basically
clean
without
anything
last
I
saw
so
for
the
group
in
the
call
anything
any
feedback
comments
you
can
share
on
this.
Pr
are
really
welcome.
We're
look
looking
forward
to
anything
that
we
can
do
to
improve
it,
anything
that
we
may
have
missed
in
terms
of
scoping
or
any
questions.
D
D
Good
all
right,
if
no
questions
there,
I
can
move
to
the
next
part.
So
this
was
another
collaboration
which
I
really
like
to
do
between
six
so
sig
release,
team
and
sig
test
infra
team-
or
maybe
it's
a
group,
I
might
be
missing
that
they
were
trying
to
figure
out.
How
can
we
make
the
unit
testing
in
kubernetes?
D
There
was
a
lot
of
effort
done
to
fix
some
unit
tests
that
would
make
allow
make
unit
testing
to
run
as
non-root
to
begin
with,
and
there
was
only
one
unit
test
that
was
basically
failing
before
it
could
move
to
the
non-root,
and
luckily
we
were
able
to
merge
the
pr
which
fixes
that
unit
test
and
now,
if
you
run,
make
test
on
kubernetes
as
an
on-route
user
on
your
laptop,
it
will
work
which
it
couldn't
before
you
had
to
either
become
root
using
sudo
or
have
to
do
sudo
make
test.
D
So
that's
great,
and
then
I
don't
know
if
vinayak
is
here,
he
suggested
even
more
future
feature
which
could
reduce
the
privileges
even
further.
So
that
seems
like
is
probably
a
good
next
pr,
maybe
when
I,
if
you
want
to
and
can
share
some
details
on
the
suggestion
you
made
on.
H
This
sorry,
I
was
struggling
to
find
the
unmute
button.
The
yeah,
I
think
the
suggestions
are
more
around
completeness
of
like
we
could
set
like
runners
group
and
like
explicitly
drop
all
the
capabilities
yeah.
H
I
think
they're
more
around
completeness
than
like
just
depriving
me,
because
I
think
I'm
not
sure
what
the
behavior
is.
If
you
don't
specify
run
as
group,
is
it
still
running
as
group
zero?
I
think
so
right
so
yeah.
We
probably
want
to
drop
that
as
well.
D
C
D
C
D
Okay,
cool
and
then
last
one
I
have
is:
oh,
I
guess
oh
yeah,
yes,
so,
as
you
know,
some
of
us
in
the
group
mainly
tabitha,
ian
and
others,
and
some
people
in
sight.
I
worked
on
port
security
replacement
and
right,
maybe
two,
three
days
ago,
the
initial
pr
was
merged
and
some
other
checks
were
needed
to
be
implemented.
D
So
we
were
able
to
get
in
there
and
submit
some
peers.
I
submitted
one
samuel
roth,
who
joined
us
in
the
last
six
security
tooling
meeting
submitted
to,
I
think
and
correct
me
if
I'm
missing
anyone
else
there.
So
as
a
result
of
that,
essentially,
because
the
code
freeze
deadline
is
to
tomorrow
or
next
week,
we
are
able
to
help
out
on
making
sure
this
goes
before
the
code
phrase
and
then
we'll
have
this
as
a
alpha
feature
in
122..
A
Tabitha
that
that
is,
that
is
all
fabulous
news.
Thank
you
so
much
for
for
helping
to
bring
people
together
to
to
do
all
of
those
things
and
then
for
coming
and
sharing
the
good
news
here
with
the
group.
Does
anyone
does
anyone
have
any
last
things
that
they
want
to
bring
up
about
that
before
we.
E
Move
on
I'm
sorry,
I'm
also
the
enhancement
shadow
and
I
was
looking
at
the
paw
security
policy
and
in
the
issue
in
in
enhancement,
there's
only
one
kk
pr
linked.
So
I
don't
know
if
there's
only
one
but
it'd
be
great.
If
y'all
can
link
all
the
pr's
related
to
the
psp,
and
so
I
can
make
sure
I
keep
an
eye
on
everything.
I
Yeah
we
can
do
try
and
do
a
better
job
of
tying
those
back
to
the
enhancement
issue.
We
also
have
a
project
board
that
I
can
link
you
to
that
has
all
of
the
issues
and
pr's
in.
D
F
Please
release
comms
question
about
psp
because
I'm
writing
a
blog
or
drafting
a
blog
about
api
removal
and
I'm
going
to
talk
about
the
1.25
api
removals
and
that
brings
pod
security
policy
into
scope.
It
sure
does
so.
F
If
there
is
an
announcement
about
you
know
a
1.22
announcement
about
pod
security
replacement
the
earlier
I
can
get
a
feel
for
the
shape
of
that
announcement,
the
better
I
can
communicate
the
1.25
stuff
in
an
article
that's
going
to
go
out
before
the
release,
so
it's
about
quite
a
lot
of
meshing
together,
really
does
that
make
sense
to
people
what
I
want
to
do.
A
The
feeling
that
I
kind
of
get
from
it
is
since
you
are
going
to
be
stirring,
the
psp
is
going
away
pot.
You
want
to
be
able
to
include
even
more
detail
than
we
were
able
to
include
in
the
initial
blog
post
in
the
blog
post.
We
said
we
have
a
cap,
and
so
now
you
would
like
to
be
able
to
say
the
cap
is
implemented
and
the
replacement
is
on
track
to
be
available
as
an
alpha
in
1.22
like
at
this
time.
F
I
have
it
is
so
I
have
looked
looking
at
this
in
the
last
couple
of
days.
I
am
trying
to
work
out
how
critical
it
is,
and
every
time
I
look
at
it,
I
find
another
thing:
that's
even
more
critical
or
you
know,
I'm
still
trying
to
work
out
what
to
say,
never
mind
how
to
write
it.
So
I
don't
know
the
timing,
but
it
feels
like
getting
these
details
soon
is
is
important.
The
release
is,
is
creeping
up
on
us
really
quickly.
That's
how
it
feels
to
me.
A
A
Then
then
yeah
tim
you're
closer
to
the
writing
of
the
code
than
I
am.
Do
you
feel
like
it's
safe
for
him
to
go
ahead
and
write
that
it's
that
it's
going
to
be
alpha
in
1.22.
I
Yeah,
I'm
100
confident
that
we'll
have
the
framework
and
the
first
pass
of
the
checks
policy
checks
in
for
122.,
I'm
working
very
hard
to
get
the
web
hook.
Implementation
done
as
well,
because
that
will
make
it
much
easier
for
folks
to
try
this
out
on
a
cluster
that
doesn't
have
the
alpha
feature.
Gate
enabled.
F
To
me
is
to
to
liaise
with
who's
whoever's,
doing
your
release,
calms
tim.
A
All
right
tim:
let's,
let's
talk
about
capabilities.
I
All
right,
let
me
present
the.
I
I
And
I
can
just
walk
through
it.
Oh
can
you
either
present
it
for
me
or.
G
A
I
Looks
readable
to
me
all
right
yeah,
so
we've
already
been
talking
about
pod
security,
admission
replacement
for
cloud
security
policy,
that's
based
off
of
the
pod
security
standards
for
anyone
who's
not
in
the
know.
This
is
the
three-tier
kind
of
standard
profiles
for
pod
security
restriction.
I
So
we
have
privileged,
which
is
what
it
sounds
like
everything
goes
baseline,
which
is
sort
of
allowing
the
kubernetes
default
level
of
security,
but
not
allowing
you
to
elevate
above
that
and
restricted,
which
is
more
of
a
best
practices.
Tier
the
main
difference
between
restricted
and
baseline
is
baseline,
can't
require
anything
to
be
set
and
so
restricted
at
several
policies
that
you
must
set
or
modify
the
kind
of
defaults
and
the
kind
of
the
main
feature
there
is
kind
of
run
as
non-root
and
some
associated
checks.
I
So
when
we
originally
wrote
this
or
when
I
originally
wrote
this,
I
thought
that
capabilities
were
completely
dropped
when
switching
to
non-root
user
and
setting
allow
privilege
escalation
equals
false
sets.
The
no
new
privs
flag,
which
blocks
file
capabilities
from
being
used,
but
tabitha
made
a
pretty
interesting
discovery
that
it
does
not
have
that
effect
on
the
entry
point
of
the
container,
so
the
capabilities,
even
if
you're
running
as
a
non-root
user
with
allow
privilege
escalation
set
to
false,
you
can
still
use
file
capabilities
from
the
default
set
or
anything.
I
And
the
last
piece
of
background
is
that
some
capabilities,
specifically
cap
net,
bind
services
or
service
are
widely
used
and
well,
let's
talk
about
that
one
later
so,
anyhow,
the
I
think
the
original
pod
security
standards
didn't
have
any
capabilities
requirements
for
the
restricted
level
we
sort
of
suggested
dropping
all,
but
it
wasn't
a
requirement.
I
So
the
proposal
that
I
have
here
what
we
want
to
add
to
the
pod
security
standards
and
as
a
check
for
the
new
pod
security
admission
controller,
is
to
require
restricted
pods
to
drop
all
capabilities.
I
And
then
you
can
you
you
can
combine,
drop
with
add
and
so
drop
happens
first.
So
if
you
say
drop
all
that
like
kind
of
empties
out
the
default
set,
and
then
you
can
add
explicitly
add
only
the
capabilities
you
need,
so
the
proposal
for
restricted
is
require,
dropping
all
and
then
allow
a
small
set
of
deemed
safe
capabilities
for
non-root
users.
I
I
I
I
Writing
audit
events
seems
like
a
low
privilege
operation,
but
could
also
be
used
by
a
malicious
user
to
inject
malformed
events
or
overflow,
the
audit
buffer,
in
a
way
that
caused
events
to
be
dropped.
So
I
actually
propose
that
we
leave
this
one
out
unless
someone
comes
along
with
a
strong
use
case,
I'll
pause.
A
You
should
be
having
pretty
strong
control
over
what
your
container
images
are
anyway,
and
then
those
are
capabilities
that
could
be
quite
useful
to
me
as
an
attacker
after
I
somehow
broke
out
of
the
container,
and
therefore
denying
them
to
me
is
a
good
idea.
But
that's
that's
where
the
discussion
has
been
thus
far
and
want
to
make
sure
that
it's
open
to
more
of
us.
H
I
had
a
question:
why
don't
we
drop
capabilities
from
a
non-root
container
by
default
in
kubernetes?
Why
why
don't
we
always
like
append
that
drop
like
you
can,
you
can
say,
drop
all
right
like
in
the
security
context
like
so
why
don't
we
always
do
that
for
non-root
containers
as
a
default.
I
So
a
lot
of
the
a
lot
of
the
kubernetes
defaults
are
inherited
from
docker
defaults.
In
the
early
days
of
kubernetes.
It
was
pretty
tightly
coupled
to
docker.
I
don't
know
the
historic
context
around
why
they
didn't
do
that,
probably
because
root
really
doesn't
behave
as
you
would
expect
root
to
run.
If
you
drop
all
capabilities.
H
So
I
was
kind
of
only
talking
when,
when
somebody
puts
like
explicitly
specifies
run
as
user
right
to
say,
like
a
non
root
number
like
like
a
nonsense
number.
So
in
that
case,
wouldn't
it
be
like,
wouldn't
we
be
more
secure
if
we
just
always
started
by
dropping
like
if
somebody
did
that
we
always
drop
all
the
capabilities
by
default.
I
Yeah,
if,
if
we
were
going
back
and
redoing
the
api,
I
would
definitely
say
run
as
non-root
user
should
drop
all
capabilities
and
set
allow
privilege
escalation
to
false
by
default.
At
this
point,
I
think
it's
pretty
hard
to
change
those
defaults.
I
A
When
you
run
a
certain
binary,
no
longer
work,
and
so
then
you
know
in
in
these
days,
when
you
had
the
ping
binary
was
often
set
to
have
the
file
capability
of
capnet
raw
so
that
it
could
send
so
that
it
could
form
and
send
the
icmp
echo
requests,
because
I
believe
this
was
before
the
linux
kernel
got.
The
ping
socket
type
is
hilarious.
A
How
much
ping
has
been
a
permissions
problem
in
unix
for
like
25
years,
but
anyway,
like
that
sort
of
use
case
is,
is
my
understanding
of
why
capabilities
weren't
dropped
for
non-root
containers
in
like
docker,
because
because
those
capabilities
are
present
in
all
users
allowed
set
or
excuse
me,
bounding
set
for
a
normal
unprivileged
user
on
linux,
and
so
then,
if
you
drop
them
out
of
the
bounding
set
inside
the
container,
then
long-standing
habits.
People
had
to
make
certain
things.
Work
would
no
longer
work
in
the
container.
H
Because
what
I
was
thinking
is
like,
if
we
already
drop
it
by
default
right,
then
then
they
could
put
the
file
capability
on
the
binary
and
then
they
could
add
exactly
what
they
needed,
and
so
the
bonding
side
would
have
exactly
what
they
needed,
as
opposed
to
like
a
bunch
of
things
that
they
don't
really
need
yeah.
But
I.
A
H
I
feel
like
we
should
be
able
to
write,
because,
like
capabilities
for
non-root
does
not
work
today,
right,
like
does
not
work
unless
you
apply
the
file
capabilities.
So
if
somebody's
applying
the
file
capabilities,
they
really
know
exactly
what
they
want
to
add
right
because
they
added
the
file
capability.
So
we.
A
For
usability,
on
the
other
hand,
it
can
be
kind
of
terrifying,
so
yeah,
it's
it's
rough
like
if
you
are
making
the
container
yourself
and
you
are
setting
the
file
capabilities
yourself,
then
I
100
agree,
but
for
things
where
you
don't
even
realize
somebody
set
file
capabilities
for
you,
then
then
that's
rough,
but
I
hope
someday.
We
could
get
to
a
place
where
we
dropped
capabilities
as
non-root
as
non-root
users.
C
One
question
I
asked
I
had
about
the
about
this
is
where
we're
already
saying
mustard
is
non-root
and
I
don't
allow
privilege
escalation.
Would
I
be
in
saying
that
people
would
have
to
have
manually
set
the
file
capability
on
the
binary
for
that
cap
by
net
binding
service
to
actually
work?
C
I
This
this
is
a
great
segue
into
the
next
topic
on
our
agenda,
but
actually
I
do
want
to
just
kind
of
wrap
up
some
of
the
pod
security
admission
control
things
before
we
move
on
to
that.
So
maybe,
let's
just
kind
of
hold
off
on
that
discussion
for
a
few
more
minutes.
I
Are
there
any
other
comments
on
like
whether
this
policy
kind
of
aside
from
setting
or
changing
kubernetes
defaults,
which
is
a
much
larger
discussion?
Are
there?
Is
there
any
other
feedback
on
this
policy
for
an
initial
pass
at
a
restricted
capabilities
policy?.
K
I'll
just
mention
that
I
reached
out
to
some
of
the
some
of
my
colleagues
who've
been
working
with
primarily
in
the
telco
space
who
have
particularly
strong
security
concerns.
K
I
Okay,
thanks
yeah
I'd
love
to
hear
that
if
you
get
more
feedback,
we
are
kind
of
on
a
time
crunch
on
this
one.
How
what's
the
like
this.
I
Yeah
so
code
freezes,
I
think
july
8th
someone
mentioned
so
we're
hoping
to
get
the
policies
in
this
week.
We
could
still
kind
of
throw
in
a
change
next
week,
but
one
of
the
great
things
about
the
design
of
this
feature
is
we
kind
of
built
it
for
changing
versions
from
the
start.
So
if
we
change
our
mind
on
this,
we
can
always
tweak
it
in
123
or
beyond.
Okay,.
I
I
I
I
The
problem
is,
we
don't
know
if
that's
been
overridden
at
admission
time,
so
we
can
say
you're
allowed
to
set
the
default,
but
you
can't
explicitly
request
unconfined
and
that
will
honor
the
container
default.
There's
also
a
change
in
the
works
to
get
that
default
switched
over
to
runtime
default
always
and
the
second
change
was
this
actually
isn't
a
change
from
the
the
policy,
but
just
to
reiterate
for
baseline
capabilities,
we're
saying
that
you're
allowed
to
add
all
of
the
capabilities
from
the
docker
default
set,
except
for
cap
net
raw.
I
Where
we
say
we
want
to
allow
you
to
add
capabilities
to
kind
of
use
that
pattern
where
you
drop
all
and
then
add
just
the
ones
you
need,
but
we
don't
want
to
allow
escalating
to
cap
net
raw
when
it's
been
disabled
at
the
runtime
layer.
I
So
it's
it's
not
the
ideal
ux,
but
we
haven't
been
able
to
come
up
with
anything
better
for
that.
A
I
feel
like
in
an
ideal
world
the
admission
layer
would
be
able
to
know
what
the
configuration
of
the
runtime
is
and
be
able
to
say
you
can
drop
all
and
re-add
anything
that
the
runtime
allows
in
its
default,
but
since
it
can't
do
that,
we
have
to
try
to
make
a
balanced,
a
balanced
guess
as
to
what
gives
the
best
combination
of
not
being
unsafe
for
common
use.
Cases
such
as
reconfiguring
the
runtime
to
remove
capnet
raw
from
the
default,
and
not
being
you
know
too
much
too
much
developer.
A
A
This
is
the
result
of
several
of
us
arguing
for
quite
some
time
about
the
various
imperfect
solutions
and,
and
hopefully
it's
good-
and
you
know
more
more
voices
in
favor
of
it
or
or
that
have
a
better
idea
is
helpful.
I
can't
see
anybody's
video
right
now,
because
I'm
screen
sharing
without
dual
monitor
modes.
So
please
just
you
know,
speak
up
and
and
try
not
to
speak
over
each
other.
L
Hi
I
had
a
quick
thought,
which
is
that
it
may
be
useful
when
discussing
the
various
merits
of
the
controls
that
we
want
to
put
into
one
of
the
three
tiers
to
have
a
type
of
reference
workload
that
we're
expecting
to
be
able
to
run
within
that
tier,
because
otherwise,
we're
kind
of
it
feels
like
there's
a
bunch
of
discussions
about
controls
without
a
context
to
help
you
understand
which,
which
of
the
tiers
you
really
should
be
binding
it
to
or
which
of
the
expectations
for
a
tear,
you're
breaching
by
either
having
or
not
having
a
control.
L
L
I'm
certainly
happy
to
help
with
the
conversation
and
would
be
happy
to
contribute
docs
just
as
and
when
I
can
find
time
to
do
it.
You
know
to
your
comment
earlier
about
the
docs
is
a
good
place
to
do
your
first
stuff.
It
is,
but
also
there
is
10
supporting
information
and
guide
docs.
You
have
are
supposed
to
read
before
you
before
you
write
a
doc's
post.
L
So
actually,
I
would
argue
if
you
can
write
go
like
docs
is
not
the
easiest
place
to
go,
write
your
first
commit
and
and
yeah,
but
that
said,
I've
been
through
it
I'll.
Do
it
again,
it's
fine!
L
So
if
you
think,
but
if
we
had,
if
you
think
a
couple
of
reference
workloads
not
going
to
the
point
of
actually
like
specking
them
out,
but
if
we
had
just
descriptions
of
the
types
of
workloads
we
expected
to
be
able
to
run
and
a
group
of
assertions
we
expected
to
be
able
to
make
about
like
how
the
containers
within
those
workloads
are
behaving.
A
If
I
can,
if
I
can
also
put
you
on
the
spot,
but
less
firmly
than
tim
did,
can
I
ask
you
to
file
an
issue
in
k
website
with
exactly
the
idea
that
that
you
just
had
and
then,
like
you
know,
post
that
back
into
into
the
security
slack
channel,
because
that
seems
like
a
great
way
to
get
this
idea,
which
I
think
is
a
very
good
idea
out
to
a
broader
part
of
the
community
than
what
we
have
assembled
right
here.
Yes,.
L
F
A
All
right
we'll
move
on
to
the
to
the
the
next
thing.
Unfortunately,
vineyard
had
to
drop
so
I'm
I'm
I'm
sad
to
have
lost
him,
but
I've
been
following
along
with
this
a
little
bit,
so
I
I
will
give
a
shout
out
to
the
ambient
capabilities
in
kubernetes
cap.
The
link
is
in
the
notes.
There
has
been
a
lot
of
great
discussion
about
the
various
trade-offs
involved
in
providing
a
good
user
experience,
providing
a
maintainable
api
service.
A
So,
like
the
I,
it
has
been
great
to
watch
this
to
watch
this
cap
mature,
and
it
is
also
a
good
place
to
come
and
have
a
look
at
what
the
discussion
has
already
been
and
and
add
to
it.
If
you
have
thoughts
to
add
to
it,.
I
Just
to
tie
this
to
our
earlier
discussion,
I
think
rory
raised
the
question
of.
I
can't
quite
remember
how
you
phrased
it.
But
what
happens
if
you
add
capability,
or
can
we
just
make
capabilities
work
as
expected
for
non-route
containers,
was
that.
C
Does
someone
who
wants
to
run
get
the
cap
net
by
service
working?
Do
they
have
to
explicitly
add
a
file
cap,
or
will
it
just
work
because
I'm
guessing
if
they
had
to
add
explicit
file
cap
most
image
writers,
don't
know
that
and
therefore
probably
can't
do
that
today?
But
if
it
just
works,
then
obviously
more
images
will
have
that
setup.
I
So
if
ambient
capability
or
if
it's
in
the
ambient
set,
then
it
just
works,
you
don't
need
the
file
capability
for
it,
and
so
I
would
like
to
add
cabinet
bind
service
to
the
default
ambient
capability
set
because,
as
we
were
talking
about
earlier,
like
I
just
I
don't
see
much
or
if
any
risk
associated
with
that
one
there's
some
discussion
around
whether
we
want
to
expose
an
api
for
adding
additional
capabilities
to
the
ambient
set
other
than
netbind
service,
and
that's
kind
of
the
ongoing
discussion
on
that
cap
but
yeah.
A
Please
come
and
talk
to
me
at
kubecon
and
and
share
your
share,
your
your
weird
trivia,
over
a
non-alcoholic
cocktail,
but
adding
more
of
that
worries
me
so
like
that
that
is.
That
is
the
opposition
that
I
have
to
doing
it,
despite
the
fact
that
it
would
be
wonderful.
So
now
now
you've
heard
both
sides.
K
Yeah,
I
think
I
I
kind
of
second,
your
concern:
tabitha
yeah
and,
and
we
have
a
number
of
customers-
I
will
say
our
most
security
conscious
customers.
K
These
days
are
in
telco,
you'd,
think
it
would
be
fsi,
but
but
it
tends
to
be
telco
in
part
because
they
have
workloads
that
that
do
care
about
you
know
networking
and
and
historically,
and
they
haven't
adjusted
them
yet
to
to
really
take
advantage
of
cni,
etc,
and
so
there's
an
awful
lot
of
kind
of
wildly
privileged
things
being
requested
and
and
and
the
security
folks
at
the
carriers
are
very
concerned
about
attack
vectors.
A
Because
fsi
knows
they
have
dangerous
information
when
you're
a
carrier
when
you're
a
carrier.
You
know
that
there's
probably
dangerous
information
somewhere,
but
you
don't
even
know
where
it
is
because
it's
in
your
customer
data
that
you're
carrying
so
you
got
to
have
an
even
bigger
word.
It's
your
unknown
unknowns.
That's
scary!.
K
A
It's
frightening,
so
yeah,
please,
please
come
and
talk
about
ambient
capabilities,
because
this
is
another
one
of
those
things
where
you
know
several
of
us
are
are
doing
our
best
to
to
argue
in
good
faith
and
move
us
towards
something,
that's
better
for
everybody.
But
there
is
no
clearly
obviously
right
answer
and
so
we'll
get
there
as
a
group.
K
D
A
A
Thank
you.
Thank
you.
Welcome,
as
you
have
seen
mostly,
we
call
out
problems,
talk
about
our
feelings
about
those
problems
and
then
that
helps
us
converge
towards
solutions.
So
thank
you
so
much
for
for
coming
and
being
a
part
of
that
part
of
those.
M
Discussions
so
hi,
I'm
mikhail.
I
work
for
souza
and
I'm
pretty
much
mostly
interested
in
what's
going
on
with
psp
replacement,
and
I
got
a
lot
of
answers
in
music,
which
I
really
appreciate
and
I'm
my
goal
so
far
is
in
general
watched
watch
that
area
of
security
policies
in
kubernetes
and
how
they
are
gonna.
Look
in
the.
A
J
Hey
amirba,
I
work
on
the
search
manager
project
I
joined
for
the
first
time.
I
was
mostly
just
interested
in
some,
maybe
some
good
practices
that
you
folks
are
doing
that.
We
could
also
inherit,
like
things
like
dependencies
scanning.
It's
quite
interesting,
so
yeah.
A
Yeah,
if
you
have
the
more
specific
questions,
please
feel
free
to
bring
them
to
slack,
because
there's
yeah,
there's
there's
great
community
in
there,
people
who
are
working
on
it
here
within
kubernetes,
and
also
people
who
are
working
on
it
within
different
aspects
of
their
day
jobs.
You
get
a
good
cross-section
of
a
lot
of
the
industry.
A
J
N
Hi
there,
my
name
is
jeremy
cowan.
I
recently
joined
aws
as
a
developer
advocate
and
I'm
looking
at
how
I
can
get
more
involved
in
the
sig
security
community.
A
Thank
you.
Thank
you
all.
Thank
you
all
so
much
for
for
coming.
We
got.
We
got
a
couple
more
minutes
here
and
so
rory
I
wanted
to.
I
wanted
to
jump
back
to
something
that
you
had
said
about,
like
the
the
capabilities
being
added
or
removed
from
pods
that
are
running
under
the
restricted
pod
security
standard,
and
it
made
me
think
about
how
there's
kind
of
two
different
aspects
of
threat
modeling.
What
do
we
put
into
these
pod
into
the
pod
security
standards?
A
There's
the
there's
the
like
people
are
running
pods
like
trusted
administrators
are
running
pods
and
then
what
hardening
settings
are
put
on
those
pods
in
order
to
make
life
more
unhappy
for
an
attacker?
Who
has
you
know
gotten
gotten
inappropriate?
You
know
code
execution
in
one
of
those
pods,
but
then
I
think
another.
A
Another
part
of
the
threat
model
of
these
is
reducing
the
reducing
the
the
power
that
create
pod
within
the
name.
Space
controlled
by
that
pod
security
standard
offers.
You,
and
so
you
know,
without
any
admission
control
create
pod,
is
the
same
thing
as
root
on
every
node
in
the
cluster,
and
so
then,
with
the
baseline
pod
security
standard,
you
know
it.
It
aims
to
cut
off
known
privilege
escalations
so
that,
hopefully,
if
you
can
create
pod
in
a
namespace,
that's
controlled
by
the
baseline
pod
security
standard.
A
Hopefully
that
is
code
execution
as
a
non-privileged
user
on
every
node
in
the
cluster
and
so
then,
with
with
restricted,
I
feel
like
it's
trying
to
to
achieve
that
same
kind
of
goal,
but
in
a
more
hardened
way,
and
so
the
like
drop
all
capabilities
becoming
part
of
the
restricted
pod
security
standard.
A
I
think
is
related
more
to
that
second
aspect
of
the
threat
model
where,
like
normally
container
images,
don't
have
very
many
binaries
with
file
caps
set
on
them
yeah
but
then
like.
If
I
am
a
malicious
kubernetes
user
like
I
have
legitimate
kubernetes
access
to
a
namespace
controlled
by
the
restricted
pod
security
standard.
A
So
then,
like
that's,
why
I
wrote
that
comment
on
github
with
the
with
the
docker
file
that
if
you
build
it,
it
gives
you
all
the
capabilities
all
the
time,
because
you
know
it
does
like
a
recursive
set
cap
of
all
of
those
available
capabilities
onto
everything
in
the
file
system.
And
so,
if
you,
as
the
like
cluster
super
administrator,
had
given
me
access
to
a
namespace
with
restricted,
you
may
not
think
that
I
would
be
able
to
get
access
to
any
capabilities.
C
C
So
in
terms
of
surprise
yeah,
it's
going
to
surprise
me
that
by
default
it's
actually
getting
parts
of
refresh
via
capabilities,
so
yeah,
absolutely
in
terms
of
like
minimum
minimizing
surprise
to
me
once
you're
saying,
you're,
not
root
and
you're,
no
prives,
I'm
going
to
assume
that
you've
got
no
caps
and
and
finding
out
that
you
do
would.
If
I
wasn't
already
like
versed
in
what
we've
talked
about
today,
I
would
probably
come
as
a
surprise
would
be
my
guess.
A
A
C
A
A
Huzzah
we're
we're
one
minute
over,
but
I
I
I
really
was
hoping
to
you
know
to
make
to
make
space
if
anybody
else
wanted
to
weigh
in
on
that
question
of
the
the
sort
of
two
competing
threat
models
that
you
might
be
thinking
of
when
you
apply
admission,
control
to
a
namespace,
so
last
call
I'm
gonna
give
it
some
thought.
A
Awesome
come
and
join
us
on
slack.
Let's
all,
let's
all
argue
about,
let's
all
argue
about
admission
control
threat
models.
I
I
could.
I
could
do
this
all
day
with
y'all
love.