►
From YouTube: Kubernetes SIG Security 20211202
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
All
right,
hello,
everybody
it
is
for
after
we
are
going
to
declare
ourselves
quarat,
and
so
I
will
say
welcome.
Thank
you
all
so
much
for
coming
to
another
kubernetes
sig
security,
we'll
we'll
see
how
the
energy
is
today
it
is.
It
is
going
to
be
all
right
if
it's
a
quiet
group,
but
we
have
some.
We
do
have
some
neat
things
on
the
list,
so
I'm
looking
forward
to
that
we
can.
A
We
can
popcorn
some
some
quick
introductions
around
just
for
folks
who
are
folks
who
are
new
and
also
just
to
help
us
all
to
stay
in
touch
with
each
other.
I'm
I'm
tabitha,
I'm
one
of
the
co-chairs.
A
I
help
to
make
this
space
for
us
so
that
together
we
can
do
things
that
help
to
improve
the
safety
of
kubernetes
users,
helped
to
improve
the
the
security
of
the
project,
and
I'm
really
glad
that
that
I
get
to
hack
things
and
make
friends
with
so
many
of
you.
Anybody
who
wants
to
jump
in.
C
Hi
everyone-
this
is
pushkar.
I
try
and
help
improve
tooling
from
security
and
help
all
the
other
sub
projects
that
this
great
security
group
has
and
always
excited
to
talk
to
new
folks
and
make
them
comfortable.
D
Hey
everyone,
I'm
rahul
jadhav.
I
work
for
a
startup
called
as
equinox.
We
work
on
runtime
security,
I'm
a
contributor
to
celium
and
we
also
got
one
of
our
project
in
cncf
sandbox
last
week
called
cube
armor.
So
I'm
a
contributor
to
that
as
well.
So
runtime
security
is
my
focus
area.
I'm
glad
to
be
here
and
looking
forward
to
contribute
more.
B
Community,
hey
everyone-
this
is
avita
here.
I
I'm
here
to
learn
and
share
knowledge
with
everyone.
I
also
help
lead
a
sex
security
documentation.
A
All
right,
I
am
so
I'm
I'm
so
glad
to
see
all
the
familiar
faces
new
faces,
folks
who
folks,
who
want
to
speak
up
and
folks
who
want
to
remain
quiet
space
for
all
of
us
here.
So
let's,
let's
hear
about
a
little
bit
about
what's
going
on
with
subgroup
reports,
I
will
convey
ray's
message
about
the
progress
in
the
third
party
audit
subproject,
which
is
fundamentally
that
contracting
is
hard,
but
it's
important
to
get
it
right,
and
so
the
vendor
selection
process
continues
and
we
will
find
out
more
when
it
comes
to
completion.
A
Would
you
would
you
like
to
share
with
us
what's
going
on
with
docs.
B
Sure
so
the
first
thing
first
shout
out
to
jim
b,
because
I
don't
know
how
to
say
his
last
name,
I'm
sorry
and
robert
and
everyone
who
worked
on
the
policy
management
white
paper,
whoever
reviewed
pushkar
thanks
to
everyone,
so
that's
merged,
and
there
is
a
link
in
the
agenda.
Please
go
check
it
out
if
you
are
interested
in
learning
more
and
if
you
have
any
other
feedback
reach
out
to
the
working
group
policy
management
working
group
mentioned
in
the
paper.
B
I
think
it's
the
end
and
the
next
up
is
a
reminder.
Rory
is
working
on
two
things
here:
admission
controller
threat
model
and
there
is
a
draft
blog
post
coming
up
on
the
same
topic.
I
think
so.
The
deadline
to
review
and
provide
feedback
is
this
friday.
B
So
if
you
haven't
checked
it
out,
please
go
check
it
out
as
well.
We
are
meeting
after
this
meeting,
so
I
don't
have
a
new
update,
probably
maybe
after
the
today's
meeting
you
might
have
something
which
I
can
come
and
share
next
time.
A
G
Sorry,
I
might
be
asking
something
that
might
not
be
related
to
dogs,
but
sarita
is
dogs
kind
of
like
the
way
to
contribute
in
the
form
of
blog
documents.
B
Sure,
yes,
so
we
we
are
new
and
we
are
still.
We
have
like
a
lot
of
places
where
we
could
improve
the
community
security
documentation
and
blogs
is
definitely
one
of
the
places
and
if.
G
B
Interested
we
do
have
a
meeting,
that's
happening
at
two
o'clock
eastern,
I
I
don't
know
the
upc.
I
need
to
just
it's
two
hours
now
so
come
join
us
and
sorry.
If
I
cut
you,
I
know
you
were.
G
C
Yes,
so
couple
of
pr's
were
marched
this
week
or
since
we
met
last
time,
we
have
been
doing
build
time
scanning
for
all
the
go
modules
for
a
while
now,
and
there
was
good
in
terms
of
signal
to
noise
ratio
on
it.
So
far,
we've
been
picking
up
things
that
we
might
have
picked
a
bit
later,
but
there
wasn't
anything
in
terms
of
documentation.
That
was
very
clear
to
explain
what
actually
happens.
C
So
this
pr
was
essentially
document
in
terms
of
how
the
scanning
works
where
what
is
being
scanned
and
how
frequently
does
it
happen
and
give
some
examples
of
how
it
looks
like.
So.
That's
that's
the
pr
that
got
worse.
The
second
one
is
about
one
of
the
future
caps.
We
are
hoping
to
author,
which
is
about
creating
a
cve
feed,
which
has
been
an
ass
from
multiple
people,
on
kk,
repo
or
in
website.
C
In
terms
of
people
who
have
created
issues
saying
we
need
a
way
to
programmatically
fetch
cvs
that
have
been
fixed
and
announced
by
src.
So
this
was
a
prerequisite
to
get
that
label
in
place.
That
would
allow
us
to
identify
all
of
those
issues.
So
that
label
now
exists.
I
tried
it
on
one
of
the
issues
it
works,
which
is
great
so
now
it's
just
about
adding
the
labels
to
all
the
relevant
issues
and
then
some
more
steps
that
would
need
discussions
and
some
design
reviews
to
get
the
feed
in
in
place.
C
Second
third
update
is
this
was
one
of
the
things
that
came
out
from
sfc.
I
think
tim
shared
this
initially,
we
we
know
very
limited
in
terms
of
what
happened,
but
based
on
what
it
looks
like
is.
C
There
are
chances
where
a
dependency
that
kubernetes
is
picking
up
becomes
orphan
in
a
way
and
then
that
particular
org
can
can
be
deleted,
and
then
there
is
a
time
in
point
in
time
when
the
arm
doesn't
exist
and
an
attacker
can
create
an
org
with
the
same
name
and
essentially
kind
of
spoof
the
original
arc,
so
a
kept
to
detect
that
would
have
been
worth
discussing
based
on
last
call,
so
we
created
a
google
doc
to
start
the
discussion.
C
It
has
a
similar
template
as
the
cap,
and
I
see
ours
and
benjamin
and
some
others
starting
to
discuss
some
stuff
on
it.
If
others
want
to
contribute,
you
are
all
welcome
to
go
to
that.
Google
doc
and
start
typing
your
thoughts
and
questions
and
everything
else
next
update
and
this
kind
of
ties
to
the
self-assessments
also
I'll
be
out
most
of
the
rest
of
the
month.
So
there
is
a
chance.
C
I
won't
be
able
to
lead
the
tooling
meetings
that
we
might
have
or
join
the
meetings
like
this,
but
I
do
want
to
encourage
people
who
are
interested
and
if
you
are
available-
and
there
are
more
people
more
than
one
or
two
or
whatever
number
of
people
want
to
just
talk
about
tooling
and
learn.
Something
together
definitely
encourage
all
of
you
to
join
want
to
hear
thoughts
from
chairs
also
because
this
might
be
the
first
time.
C
Maybe
one
of
us
isn't
available
for
a
few
weeks
versus
like
one
week
or
other
in
terms
of
how
to
manage
that,
but
yeah.
I
want
to
encourage
instead
of
just
canceling,
because
I'm
not
there
all
the
meetings
to
just
meet
if
people
want
to
meet
and
have
this
as
a
common
place.
I
should
be
back
fingers
crossed
in
january
and
then
we'll
continue
I'll
pause
before
moving
on
to
self-assessments
to
see
if
people
have
questions
and
thoughts.
C
B
I
I
would
make
a
post
and
then
see
how
many
people
are
interested
and
then
I'll
be
the
moderator
host
kind.
I
don't
know
how
much
I'll
be
able
to
contribute,
but
I
will
be
there
if
someone
needs
and
I
could
manage
to
zoom
and
notes
and
stuff
like
that.
Okay,
that
would
be
great.
Thank
you.
A
I'll
I'll
bring
up
two
things
for
that
one.
I
I
wrote
in
the
in
the
notes,
but
there
is
one
of
the
periodic
src
meetings
coming
up
soon,
and
so
I
will
bring
to
that
meeting
that
we
have
the
we
have
the
label
now
for
the
like:
the
restricted
label
for
cve
issues
and
so
I'll
I'll
bring
that
up
in
the
src
meeting,
and
we
will
see
what
we
can
do
to
get,
though,
to
get
that
label
applied
to
all
of
the
previous.
A
The
existing
cve
tracking
issues
that
are
that
are
in
kkk,
and
I
also
just
wanted
to
say
thank
you
so
much
for
your
concern
about
making
sure
that
the
various
meetings
remain
a
space
for
all
of
us
to
come
together,
which
means
that
nobody,
no,
but
nobody
is
required
to
to
show
up
it
is.
It
is
not
mandatory
that
these
meetings
happen,
but
also
it's
important
that
they
be
able
to
happen
if
they
are,
if
they
are
useful
and
important
to
folks
and
so
yeah.
Calling
that
out.
A
Thank
you
so
much
zavita
for
for,
for
volunteering
to
to
show
up
and
help
to
hold
the
space
for
folks
and
yeah
anybody
else.
Who
has
some
some
interest
in
helping
to
make
this
helping
to
make
this
space
happen
so
that
folks
can
have
a
place
to
come
together
and
do
the
work
you
know
talk
to
talk
to
any
of
us
talk
to
either
of
us
co-chairs
talk
to
to
pushkar
savita
ray
about
how
you
can
how
you
can
help
to
do
that
because
we
are.
C
One
thing
I
wanted
to
add
on
the
labeling
thing,
so
good
thing
is
we
have
found,
I
think,
all
the
appropriate
cv
issues
that
need
labeling,
so
I
should
be
able
to
label
those.
What
I
want
maybe
src
to
confirm
is
if
I
end
up
labeling
something
that
is
not
something
we
want
to
share
as
an
official
cve
fee,
so
okay,
yeah
so
sort
of
like
second
pair
of
eyes
when
I'm
labeling
in
case
I
miss
something
or
I
do
some
add
a
label
to
something
that
is
not
relevant.
I
think
just
correcting
me
there.
C
And
the
second
piece
would
be
on
the
non-existent
dependency
url
topic
of
anything
else
that
is
possible
to
share
publicly
in
terms
of
details
of
how
this
attack
could
have
been
possible.
C
Rendering.
How
is
this
rendering
dependencies
is
is
something
that
seems
like
a
mitigation
control
and
how
it
actually
helped
mitigating
this
particular
threat.
I
think
that
kind
of
information
will
really
help
folks
who
are
discussing
that
topic
and
probably
will
improve
the
overall
quality
of
the
cap.
F
Yeah
related
to
that,
I
was
looking
into
that
and
added
some
comments
into
the
document
and
slack
about
the
vendoring
process
and
whether
or
not
we
we
auto
bump
dependency
versions,
because
if
we're
automatically,
you
know
we
vendor,
but
if
we
in
the
build
process
automatically
bump
minor
version
dependencies
or
something
like
that,
that's
still
a
a
potential
attack
vector
so
just
kind
of
tagging.
F
On
that
what
push
car
is
saying,
understanding
our
build
process
and
when
we
do
version
dependency
updates
a
little
better
or
adding
that
in
the
document
would
be
very
helpful.
C
Okay,
cool,
so
that
I
think
for
the
dependency
bumps
is:
there
is
a
sig
called
sig
architecture
and
they
have
a
kx
code
organization,
subgroup
or
sub
project
that
is
basically
tracking
and
keeping
care
taking
care
of
all
the
dependencies
for
kubernetes,
especially
the
build
time
ones
which
is
relevant
to
this
gap.
C
C
So,
if
you're
interested,
then
I
would
recommend
subscribing
to
their
google
group,
the
sig
architecture,
google
group,
so
you'll
get
an
invite
on
the
kids
code
organization,
sub
project
meeting
when
they
meet
and
then
just
joining
there
and
kind
of
opening.
This
topic
up
might
be
worth
getting
some
feedback
from
them.
F
Okay,
yeah
I'll,
take
that
as
an
action
item
to
to
jump
on
one
of
their
meetings
and
and
see.
If
I
can
pull
somebody
else
into
this.
A
Thank
you,
something
like
this
works
so
well
when
we
can
talk
to
all
of
the
various
folks
who
are
involved
in
it
and
then
make
sure
that
that
what
we
do
is
based
on
the
best
shared
understanding
like
if
the
way
that
we
vendor
and
the
way
that
we
upgrade
vendor
dependencies
is
itself
an
important
mitigation
against
certain
kinds
of
potential
threats.
That's
wonderful,
but
it
also
means
that
it's
important
that
everyone
be
aware
that
that
procedure
is
done.
A
The
way
it's
done
on
purpose
in
order
to
give
us
certain
properties,
so
that
that
will
help
to
reduce
the
chance
that
in
the
future,
something
has
changed
about
the
procedure
in
a
way
that
would
reduce
the
protection
by
it.
You
know,
if
folks
realize
that
it
is
an
important
mechanism,
then
it
helps
to
make
sure
that
it
is
not
accidentally
regressed.
So,
thank
you
so
much
for
for
for
going
and
talking
to
them,
looking
to
looking
forward
to
hearing
what
they
have
to
say
on
it.
A
C
All
right,
cool,
okay,
so
there
was
one
issue,
looks
like
we
did
live
merging
on
it.
While
the
meeting
is
in
progress,
so
I'm
happy
about
that
tabby
ian.
Whoever
did
it
thank
you,
and
that
this
really
allows
us
now
to
open
this
forum
up
for
self
assessments
for
all
our
kubernetes
sub
projects
under
kubernetes
organ
kubernetes,
six,
and
if
people
need
help
like
cluster
api
team
has
been
getting
some
help
from
us.
I
think
this
would
be
a
way
to
start
that
process.
C
Now
they
can
create
an
issue
and
it
will
be
there.
We
won't
forget
about
it
and
then
we
can
pick
it
up
when
there
are
enough
people
to
work
on
it
and
start
discussing
it.
So
thank
you
for
that
and
then
no
new
update
on
cluster
api,
this
time,
we'll
reconvene
the
meetings
in
jan.
I
know
some
folks
on
that
sega
are
also
unavailable,
so
we
thought
might
as
well
started
in
jan
again.
C
Until
then
we'll
have
we
have
a
dog
that
is
a
working
dog.
So
we'll
continue
to
do
a
sync
progress
on
that.
A
All
right
I'll
jump
on
this
next,
one
which
I
am
bringing
to
us
courtesy.
A
All
right
cool!
Thank
you
all.
So
we
we
received
some
information
about
an
interesting
use
of
namespace
creation
here,
which
is
when
you
create
a
service,
and
you
create
a
namespace.
A
Not
to
that,
you
know
public
dns
name
on
the
internet,
and
we
talked
about
this
within
the
src,
and
it's
in
that
sort
of
awkward
space
where
it
seems
like
the
sort
of
thing
that
not
a
lot
of
folks
realize,
but
also
that
is
how
service
discovery
and
name
resolution
works.
A
Creating
namespaces
is
one
of
the
most
highly
privileged
operations
you
can
make
on
a
kubernetes
cluster,
because
everything
else
keys
off
of
namespaces
are
back
decisions,
key
off
of
namespaces
and
so
on,
and
so
we
thought
that
it
was
best
to
bring
this
concern
to
this
group
and
see
what
we
could
come
up
with
for
ways
to
help
make
it
less
of
a
surprise
that
creating
namespace
names
that
are
harmful
could
be
harmful
in
the
in
the
past,
with
similar
sorts
of
things
like,
for
example,
the
the
issue
where
a
kubeconfig
file
can
be
crafted
in
such
a
way
that
it
is
harmful
to
the
user
who
uses
it.
A
A
Please
be
aware
of
them,
and
you
know,
treat
untrusted
coop,
config
files
with
care
and
so
kind
of
inspired
by
that
one
possibility
that
we
thought
of
would
be
adding
some
sort
of
information
to
the
namespace
documentation
or
the
service
discovery
documentation,
or
something
like
that,
pointing
out
that.
A
Allowing
the
creation
of
namespaces
carelessly
within
a
cluster
could
have
consequences
that
you
may
not
have
intended,
but
wanted
to
wanted
to
bring
this
to
the
group
and
and
see
what
people
think
about
it.
As
far
as
as
far
as
that
idea
or
other
ideas
for
for
ways
to
move
forward
with
making
this
a
little
less
surprising.
For
some
folks.
I
I
guess
docs
is
the
obvious
place
to
pick
it
up.
The
other
one,
I
suppose
could
be
if
you
tried
to
create
a
namespace
with
well-known
tld.
So
if
you're
trying
to
do
cubepedal
create
namespace
com,
it
goes
hey.
Do
you
really
want
to
do
that?
That's
a
really
bad
idea,
but
then,
of
course,
you
get
like
there's
a
billion
different
tlds
these
days,
so
it's
less
easy
than
it
would
have
been
in
the
old
days.
You
could,
or
maybe
just
do
it
for
the
main
ones.
A
You
know
one
one
thing
related
to
that
that
we
had
discussed
in
the
src.
Was
you
know
whether
you
know
I
mean
first
off
whether
someone
may
be
doing
that
on
purpose
within
a
cluster
and
and
that
would
that
would
be.
You
know,
take
to
take
away
that
ability
might
might
be
harmful
to
such
a
such
a
user.
A
I
think,
if
they're
doing
something
that
clever
they're,
probably
also
setting
themselves
up
for
mysterious
failures
in
the
future,
but
it
like
one
idea
that
came
out
of
that
was
that
this
might
be
a
a
useful
thing
to
add
to
the
policy
libraries
of
some
of
the
popular
feature
for
third-party
admission
controllers.
A
J
It
seems
like
the
place
where
this
is
the
most
dangerous
is
in
multi-tenant
clusters.
So
if
I
were
operating
a
multi-tenant
cluster,
I
would
not
want
a
user
to
be
able
to
select
a
project
name
of
com
or
io,
or
you
know
one
of
these
other
well-known
domains
so
yeah.
It
would
be
nice
if
we
had
some
documentation
or
policy
available
for
operators
of
such
clusters
to
kind
of
have
a
drop-in
solution
for
this
problem.
I
think
probably
most
cluster
clusters
just
won't
be
an
issue
because
people
who
can
create
name
spaces
are
trusted.
J
A
A
I
don't
know,
force
the
addition
of
a
of
a
prefix
to
the
namespace
name
in
order
to
prevent
any
sort
of
shenanigans
of
that
type
or
or
who
knows
what
but
yeah
any
any
other
thoughts
here
does.
Does
the
idea
of
of
adding
something
to
the
docs
feel
good
to
folks?
Does
it
does
anyone
have
a
have
a
good
argument,
or
or
even
just
a
a
fear
about
adding
something
to
the
docs.
C
A
A
You
know,
for
example,
putting
a
trailing
dot
on
all
of
the
dns
names
that
you
look
up
so
that
your
resolver
knows
not
to
attempt
to
do
not
to
attempt
to
add
search
paths
to
the
to
the
end.
There
is
the
end,
dots
and
other
related
dns
resolver
configuration
items
that
you
can
put
into
the
pod
spec
that
you
could
use
to
opt
your
pod
out
of
this
kind
of
shortening.
So
then,
if
you
wanted
to
talk
to,
you
know.
A
Github.Com.Service.Local,
you
would
have
to
specify
the
entire
thing
rather
than
just
the
github.com.
I
have
that
website
open
on
my
computer
right
now.
So
so
it's
it's
on
my
mind,
if
you
mean
like
from
a
within
kubernetes,
would
it
be
possible
to
block
the
creation
of
namespaces
with
special
names?
A
There's
there
is
the
code
that
you
know
there's
the
possibility
of
of
creating
a
built-in
admission
controller.
That
would
do
this.
There's
the
possibility
of
adding
a
you
know
a
web
hook,
admission
controller
that
would
block
such
a
thing.
A
K
K
K
Well,
I
mean
I've,
I
remember
back
in
the
day
when
ipsec
was
using
ip
addresses,
as
you
know,
secure
ids,
and
that
you
know
that
doesn't
work
well
when
me,
when
it's
when
things
are
ephemeral
or
not
in
your
control,
you
know
from
an
id.
You
know
the
ids
that
we're
using.
So
this
seems
like
a
similar
brand
this
that
dns
names
are
being
used
for
namespaces
or
are
you
know,
they're
together?
Basically
so.
I
So,
as
far
as
I
know,
I
guess
that
the
challenge
is
that
kubernetes
uses
dns
for
service
discovery,
but
that's
how
service
discovery
works?
If
you
didn't
have
you
could
turn.
F
I
But
you'd
lose
service
discovery,
which
is
obviously
something
which
is
probably
fairly
heavily
used.
There
has
been
a
kind
of
similar
thing
recently
with
the
wild
card.
The
fact
you
can
do
wild
card
discovery
at
the
moment
and
you
can
discover
every
service
in
a
cluster
with
one
dns
query
and
the
core
dns
people
are
looking
at
changing
their
behavior
because
that
apparently
isn't
used
anywhere.
I
I
don't
so
the
place.
I
think
if
it
was
going
to
be
changed
anywhere,
it
would
probably
be
somewhere
in
core
dns
land,
but
because
this
is
like
tied
to
service
discovery,
I
can't
up
top
my
head
think
of
a
way
of
saying
how
do
you
block
it
at
dns
level
without
breaking
you
know,
someone
actually
did
create
a
namespace
called.
I
o
they
would
be
really
upset.
Suddenly
their
service
discovery
didn't
work.
I
A
Maybe
I
have
maybe
I
have
a
a
microservices
architecture
that
features
storage
servers
that
save
all
of
my
data
for
me
and
that
subsystem
is
called
io
yeah.
I
I
A
F
You
know
ensure
that
you
don't
create
namespaces,
that
collide
with
top-level
domains
or
important
services
that
your
consumers
may
rely
on.
It's
probably
the
best
choice
here,
rather
than
like
you
said,
trying
to
chase.
You
know
always
chase
down
something
that
that
also
leads
to
attack
vectors
right
with
denial
of
service
type
stuff,
or
things
like
that.
A
Yeah
yeah,
like
I
guess
my
my
worry
the
tension
anyway
in
my
worry
here
is
you
know
I
never
feel
good
saying
users
should
know,
but
also
I
don't
want
to
you
know,
design
features
that
will
give
users
a
false
sense
of
safety
either,
and
you
know
where
the
right,
where
the
right
balance
there
is,
is
always
an
interesting
and
challenging
question,
which
is,
which
is
why
I'm
glad
that
we
can
all
talk
about
these
things
in
this
forum,
rather
than
just
any
one
of
us
having
to
try
and
make
these
decisions
by
ourselves.
A
F
Does
the
somebody
else
would
know
this
better
than
I
would
just
does
the
core
dns
service
implement
dns
sec?
Is
that
something
that
we
could
rely
on
within
the
cluster.
L
I
don't
think
it
would
there
right
because
the
dns
spec
at
that
point,
if
it
is
service
discovery
like
io
as
we've,
been
saying
it,
wouldn't
go
out
to
look
for
the
keys
for
io
at
that
point,
would
it
if
it
sees
I
o
internally
and
resolves
it.
F
Right
so
so
my
what
I
was
getting
at
there
is,
if
yeah,
I'm
not
sure
how
that
would
work
like
if
the
you'd
have
to
know
that
the
signing
of
I
o
before
you
implemented
any
of
the
you
know
conflicting
name
spaces
internally
and
then
say:
there's
a
conflict
here
right.
L
One
of
the
things
that
could
be
considered
but
kind
of
is
not
really
changes.
The
order
of
things
in
dns
is
if
there
was
a
flag
in
coordinates
or
something
to
do,
the
searches
without
the
suffix
or
the
you
know
the
search
namespace
first
and
then,
if
that
returns
return
that
before
then
looking
inside
the
cluster,
because
that.
L
A
A
Or
a
name
with
n
dots,
dots
or
fewer
in
it,
then
it
tries
adding
all
of
the
search
all
of
the
domains
in
the
domain
search
path
and
doing
those
lookups
before
it
tries
it
naked,
and
this
is
where
that
weird
thing
of
like
you
can
sometimes
make
your
application
go
a
little
faster
by
putting
a
dot
at
the
end
of
your
domain.
Name
thing
comes
from.
A
You
know,
like
the
old
1990s
web
browsing
speed,
improvement
trick
where
you
type
a
dot
after
the
com
in
order
to
make
your
web
browser
load
a
couple
of
seconds
faster,
because
dns
dns
lookups
took
a
long
time
in
the
90s
like.
I
think
that
I
think
that's
still
with
us
today,
in
both
good
and
bad
ways.
L
Sure
I
forgot
that
it
was
the
client
doing
the
enumeration
of
the
search
namespace,
which
is
like
both
good
and
bad
right.
It
is
good
and
bad.
You
can
have
different
search
namespaces
for
different
pods
and
all
sorts
right.
I
guess,
then
would
would
it
be
possible
because
if
I
recall,
the
resolver
that
is
set
for
a
pod
is
kind
of
itself,
and
I
think
kubernetes
does
something
underneath
that
could
that
be
configured
to
then
do
it
in
this
manner.
A
J
A
J
As
I
understand
it
that
in
your
pod
spec,
you
can
specify
a
set
of
search
paths
and
it
merges
it
with
the
cluster
default
search
paths
and
but
I
I'm
not
sure
of
a
way
to
specify
the
other
options.
Like
the
end.
Dots.
C
Another
thing
I
think,
if
on
the
vein
of
docs
update,
would
be
to
not
only
highlight
that
this
issue
exists,
but
what
can
we
do
about
it
without
changing
kubernetes
cluster
that
you're
already
trying
to
secure
so
few
things
come
up?
To
my
mind
is
if
you
don't
have
anything
something
like
a
naming
convention
that
is
followed
when
a
create
namespace
is
created,
that
you
can
easily
look
up
to
and
match
when
you're.
C
Looking
at
your
kubernetes
api
server
audit
logs,
I
think
that
will
go
a
long
way
in
kind
of
somebody
trying
to
use
a
name
that
will
have
this
issue
and
then,
similarly,
if
you
have
some
domains
or
urls
that
you
don't
want
your
namespace
to
be
named,
having
those
alerts
for
api
audit
logs,
where
somebody
creates
a
namespace
on
github.com
and
then
you
want
to
get
alerted
on
it,
because
the
chance
of
this
actually
happening
is
rare.
But
if
it
happens,
you
do
want
to
know
about
it.
A
Yeah,
I
I
think
I
agree
with
that
and
like
similarly
with
various
pod
options,
it's
possible
to
armor
your
pod
against
some
kind
of
abuse
like
this
by.
A
By
passing
certain
options
so
that,
even
if
you
are
like
so
that
you're,
essentially
opting
out
of
these
easier
parts
of
service
discovery,
you
know
passing
passing
n
dots
zero.
There
is
a
dns
policy
where
you
could
choose.
You
know
where
you
could
choose,
none
which
would
cause
various
parts
of
the
of
the
dns
policy
not
to
be
merged
in
from
the
cluster
level
to
your
pod.
L
M
M
That
this
could
break
something
a
different,
I'm
kind
of
thinking
of
something
like
metadata.cloud.internal
in
google
cloud
clusters
or
something
is
there
a
concern
that
this
provider
is
using
some
form
of
kind
of
cloud?
I
am
interaction
that
this
could
break.
I
don't
think
it
would
work
with
the
google
cloud
ones.
That's
what
there's
three
levels
there,
but
I'm
just
trying
to
work.
L
L
M
M
A
Yeah
I
mean
if
you
wanted
to
get
really
mean
about
it.
When
you
start
up
the
cluster,
the
the
svc.cluster.local
is
is
only
a
default.
I
don't.
I
don't
recall
right
offhand
how
to
change
it,
but
like
within
a
particular
kubernetes
cluster.
A
It
would
be
possible
to
alter
that
so
that,
then,
if
you,
you
know,
if
you
wanted
to
do
something
like
this
and
you
have
not
only
the
ability
to
create
namespaces
but
also
to
define
the
cluster-wide
dns
policy,
you
could
change
that
default,
that's
svc.cluster.local
to
say
com,
and
then
this
same
problem
would
occur,
but
with
one
extra
dot
where
it
would
be,
the
service
name
turns
into
the
hostname.
The
namespace
name
turns
into
the
domain
name,
and
then
the
auto
completion
from
service
discovery
fills
in
the
com
or
or
org
or
whatever.
H
It's
a
default,
but
it's
a
standard
by
defacto
that
if
I'm
using
a
helm
chart
somebody
else
they
might
be.
You
know,
anticipating
that
that
would
exist
and
I'm
sorry
I've
been
kind
of
having
to
deal
with
work
stuff
in
the
middle
of
this.
Can
you
give
me
an
example
of
a
namespace?
That's
problematic.
A
F
H
H
F
L
I
Yeah,
it's
something
that
I
think
you
would
want
people
to
know
they
can
do
so.
If
you
say
right,
my
job
is
I'm
going
to
have
name
space
as
a
service
and
I'm
going
to
let
people
just
rock
up
and
create
a
namespace.
Then
you
would
probably
take
the
risk
decision
yep.
I
want
that
list
and
I
wanted
to
block
like
everything
and.
I
A
A
I
A
Oh
savita,
in
the
chat
here
says,
created,
created
an
issue
for
for
this
topic.
Thank
you
very
much.
B
Thank
you.
I
didn't
want
to
interrupt
because
the
good
car
I
wanted
a
good
conversation
to
keep
going.
I
will
condense
the
gist
and
put
it
in
the
put
it
as
a
comment
and
if
anyone
has
anything
more
to
add,
please
feel
free
to
add
there
as
well.
If
we
are
going
to
add
recommendations,
I
think
we
might
have
to
pull
in
other
six
as
well.
I
don't
know
which
seg
or
is
it
just
us?
Can
we
go
and
add
recommendations?
B
A
Yeah,
I
think
that
I
think
you're
right.
This
is
certainly.
This
is
certainly
the
sort
of
thing
where
those
of
us
in
this
room
can
and
should
come
up
with.
What
is
our
opinion
on
the
matter,
but
that
we
are
not
the
last
word
on
it
and
I'm
not
totally
sure
offhand
who
else
would
be
would
be
the
best
folks
to
pull
in
like
who
owns
the
concept
of
service
discovery.
A
A
Yeah
yeah,
I
I
think
that
if
we
have
ideas
continuing
to
move
forward
on
those
and
then
as
they
firm
up,
you
know,
reaching
out
to
other
folks
who
might
have
an
interest
is
a
good
way
to
is
a
good
way
to
go
forward
on
that.
You
know
to
be
able
to
to
do
something
without
being
paralyzed
by
needing
to
talk
to
everybody,
but
also
without
stomping
our
opinions
all
over
everybody
else.
B
A
Like
hey
we're
concerned
about
this
thing,
we're
we
have
this
rough
draft
with,
with
our
thoughts
on
on
what
cluster
operators
and
and
workload
writers
could
do,
would
you
do
do
you
have
anything
you'd
like
to
add
to
it?
Inviting
people
inviting
people
in
is
is
how
we
do
around
here.
So
yeah.
F
A
E
I
I
was
just
trying
to
understand
what
are
all
the
other
agenda
items
that
is
on
this
team's
reading,
a
to-do
list
so
that
I
can
just
sort
of
learn
a
little
bit
more.
Is
there
a
resource
that
I
can
look
at
or
a
website
or
url.
A
If
you
go
through
the
secur,
the
sig
security
meeting
notes
doc,
you
can
see
what
things
have
have
been
discussed
in
the
past.
There
is
a
there
is
a
tracking
issue
board
which
is
linked
up
near
the
top
of
the
meeting
notes
dock,
where
it
says,
issue
pr
search
links.
The
first
one
says
project
board,
and
that
contains
most
of
the
things
that
are
currently
in
progress
and
otherwise
in
general.
A
This
is
a
place
for
folks
to
bring
up
anything
that
is
in
scope.
So
if
it's
about
kubernetes
security,
you
can
you
can
come
and
ask
other
folks
who
other
folks
who
care-
and
you
know,
find
the
find
the
critical
mass
of
people
that
you
need
to
rally
around
whatever,
whatever
issue
you
may
have
and
and
go
to
help
with
it.
A
Yeah,
the
project
board
might
be
the
simplest
place
to
start
as
far
as
getting
an
overview
of
what
kinds
of
things
are
currently
in
flight.
E
A
All
right,
that's
it!
Thank
you
all
so
much
for
coming.
You
know,
as
always,
the
slack
channel
is
open
24
hours
a
day.
Please
feel
free
to
drop
any
anything
that
comes
up
in
between
now
and
then
into
there
and
otherwise.
Thank
you
all
so
much
for
coming
and
look
forward
to
seeing
folks
again
soon
goodbye.