►
Description
[SIG-Network] Ingress NGINX Bi-Weekly Meeting for 20220426
A
Okay,
so
welcome.
Everyone
today
is
april,
26
2022..
This
is
the
sig
network,
ingress
engine
axle
project
meeting.
My
name
is
ricardo.
I'm
gonna
be
your
host.
For
today
I
this
meeting
is
getting
recorded.
So
please
be
aware
of
that
and
don't
say,
don't
say
anything
that
you
don't
want
to
get
to
get
recorded
and
persisted
in
the
internet.
A
We
are
under
the
code
of
conduct
here
we
need
to
comply
to
the
count
of
conduct,
so
please
be
nice
with
each
other
and
any
violation
of
the
conduct
of
conduct
feel
free
to
reach
me
or
contact
at
kubernetes.io
or
the
slap
channel
code
of
conduct,
and
with
that
said,
let's
get
started.
I'm
going
to
share
my
screen
with
you.
We
have
a
pretty
small
agenda
for
today,
but
let's
see
if
we
are
missing
something
okay,
so
I
don't
think
we
have
any
new
member
here.
A
We
are
only
in
four
people
today.
So
let's
keep
this.
I'm
gonna
come
back
to
the
issue
triage
and
the
action
items
from
the
next
meeting
from
the
last
meeting
after
the
open
topics,
so
long
suggested
that
the
open
topic
for
today
would
be
a
follow-up
on
the
cve
and
what
happened
and-
and
so
I
want
to
just
give
some
some
explanation
on
that.
A
So
we've
been
aware
of
that
cve,
I
guess
for
the
last
the
next,
the
last
three
months:
okay,
those
were
two
which
were
actually
variations
of
the
previous
cves,
where
someone
can
use
some
well-crafted
configuration
or
a
well-crafted
annotation,
or
even
something
inside
ingress
path,
which
is
not
validated
by
kubernetes
api
server,
and
we
thought
that
it
was
and
with
that
they
can
use
those
well-crafted
strings
to
to
to
inject
some
comments
that
can
be
used
to
turn
into
nginx
configurations
that
can
then
be
used
to
extract
informations
like
a
kubernetes
security
service,
account
or
or
a
certificate,
or
something
some
configuration.
A
That's
persisted
in
inside
the
enginex
language,
in
gynex
container
and
and
then,
while
discussing
that,
with
with
security
folks
like
cj
cj
from
google
and
also
alvin
and
james.
So
we
we
couldn't
actually
announce
that
to
the
rest
of
the
community,
and
I
am-
I
am
really
sorry
for
that.
But
when
we
got
cve's
announcement
we
need
to
to
to
keep
them
embargoed
in
a
sense
that
it
doesn't
became
a
zero
day
where
people
can
actively
exploit
without
a
fix
right.
A
So
this
happens
sometimes,
and
we
we
cannot.
We
cannot
work
in
in
the
wild
with
them.
A
So
we
need
to
work
with
them
in
a
more
more
silent
way,
and
that
said,
we
started
to
discuss,
which
would
be
the
best
approach
to
get
rid
of
that
that
recurrent
problems
of
having
someone
actually
abusing
of
of
the
lack
of
sanitization
on
the
template
from
from
from
our
controller
to
do
whatever
they
want
in
nginx
configurations,
and
one
thing
that
wasn't
actually
that
wasn't
actually
considered
right
now
was
to
work
on
on
the
sanitization
of
the
thinkplate
functions,
because
our
templates,
they
are
pretty
complex.
A
So
we
know
that
we
could,
in
a
in
a
way
like
close,
a
a
hole
and
then
another
hole
would
open
in
that
case,
because
we,
our
template,
is
pretty
big
and
it
generates
some
bigger
and
nginx
configuration
files
and
closing
that
it
would
be
really
hard,
and
it
would
take
a
lot
of
a
lot
of
time
to
make
all
of
the
assessments
of
which
string
could
be
added
in
which
place
and
could
also
generate
a
lot
of
breaking
changes.
A
So
the
best
approach
would
be
to
actually
to
split
the
gynex
conf,
the
gynex
container,
the
nginx
service
from
from
the
ingress
controller,
but
also
that's
not
something.
That's
like
a
short-term
solution,
so
we
would
need
to
to
have
a
ami
term.
That
thing
would
be
actually
a
mid-term
solution,
because
again
it
would
have
some
breaking
changes.
It
would.
It
would
change
a
lot
of
how
we
do
the
things
inside
ingress
controller,
and
we
still
want
to
do
that.
We
still
plan
to
do
that,
but
it
wasn't
like.
A
The
cve
was
open
like
for
one
or
two
months,
and
we
didn't
got
a
proper
answer
for
that
or
a
proper
solution
for
that
right.
So
we
came
with
the
dch
root
the
jailing
in
a
sense
of
okay.
I
may
have
control
plane
and
data
plane
splitted
between
them,
but
running
on
the
same
container
on
the
same
pod
or
in
the
same
container
right
now.
A
So
it
would
be
at
least
easier
to
isolate
to
to
reduce
the
blast
of
of
the
vulnerability
inside
the
container
right,
so
instead
even
compromising
the
container
which,
in
my
opinion,
is
still
possible
in
some
scenarios,
but
even
compromising
the
container.
The
the
the
attacker
would
just
have
access
to
the
file
system
inside
that
siege
route
and
and
it
would
be,
the
blast-
would
be
smaller
and
and
the
other
thing
was
the
deep
inspector
which
is
okay.
A
We
know
at
least
what
are
the
key
words
that
some
people
they
are
using
for
that.
We
know
that
some
of
them
they
are
dangerous,
like
root
and
alias,
but
we
cannot
remove
them
or
block
them
because
they
are
part
of
nginx
car.
So,
let's
just
block
them
in
any
of
the
fields
of
of
the
ingress
object
and
then
doing
the
same
thing
that
we
did
in
the
annotations
and
the
plan
is
actually
to
have
the
deep
inspector
as
just
one
thing
in
the
future.
A
So
right
now,
what
we
are
doing
is
actually
stopping
some
attacker
in
a
in
a
multi-tenant
environment.
Of
of
adding
dangerous
configurations
in
in
in
english
are
things
that
may
be
used
to
escape
the
the
the
config
right
so
still
escaping
some,
sometimes
the
escaping
the
strings.
A
They
are
possible,
but
it
would
end
into
let's
say
it:
wouldn't
it
may
end
with
something
not
usable
to
to
get
privileged
access
into
nginx
so
far,
but
we
are
gonna
still
keep
looking
into
usages
of
other
of
other
directives.
We
know
that
some
of
them
they
are
gonna
appear.
A
I
wrote
a
blog
blog
post
that
that's
been
reviewed
about
that
to
be
published
in
kubernetes
in
kubernetes
official
site,
in
a
way
that
letting
people
know
that
ingress
controllers
and
ingress
proxies.
They
are
actually
the
most
risky
component
in
in
kubernetes
right
now,
right
because
they
are
an
http
proxy
exposed.
A
Usually
to
the
internet
and
with
privileged
access
to
kubernetes
api
server.
So
we
know
we
know
that
the
the
the
problem
that
we
have
in
our
hands
and
we
are
actually
trying
to
get
some
commitment
on
improving
more
and
more
the
security
of
ingress
in
generics,
and
we
expect
the
community
to
first
of
all
understand
that
any
piece
of
software
can
have
problems
and
and
and
also
to
help
us
figuring
out
which
rules
we
need
to
in
certain
and
keep
doing
keep
blocking
attempts
of
compromising
ingress
for
them
their
own
security.
B
Should
we
respond
back
on
the
issues
or
chats
saying
that
basically
fleshing
out
the
issues
are
saying,
can
you
please
demonstrate
the
exploit
in
a
private
communication?
Is
that
the
right
word
to
proceed?
Yeah.
A
Yeah,
so
if,
if
someone
finds
some
some
vulnerability
and
says
hey,
I
could
exploit
it
the
right
way
of
doing
that
is
actually
ascending
to
security,
dot
security
at
kubernetes,
dot,
io
right,
because
then
they
are
gonna
actually
take
that
seriously
in
in
a
sense
of
not
just
ignoring
the
issue
which
happens
sometimes
with
us,
because
not
because
we
are
jerks,
but
because
sometimes
we
do
have
a
lot
of
things
to
do,
and
in
my
case
I
keep
keep
missing
all
of
the
the
the
github
notifications,
so
actually
the
security
committee
when
they
receive
an
exploit
or
a
vulnerability
notification.
A
They
take
really
seriously
on
that
and
they
keep
pinging
us
and
they
kept
keep
following
us
and
they
they
do
the
cve
allocation
and
all
of
the
other
things
so
yeah
the
right
process.
In
this
case,
when
someone
says
hey,
I
found
a
vulnerability
and
I
want
to
report-
and
this
is
why
we
do
have
this
thing
as
well-
is
actually
following
the
security
report-
the
security-
not
this
one,
sorry,
but
they
should
follow
this.
A
This
thing
here
and
and
also
this
one
here
and
they
can
reach
us.
So
this
is
how
a
new
a
new
vulnerability
should
be
reported
so
point
people
to
this
page
if
they
find
something
like
that
long
and
kindly
ask
them
to
report
this
in
privately
with
how
they
exploited
how
how
this
can
be
used,
how
dangerous
it
is.
A
So
they
do
have
a
template
and
they're
gonna
keep
in
touch
with
the
people
that
reports
vulnerabilities,
okay,
okay,
okay,
got
it
yeah
just
to,
and
I
ask
people
not
to
disclose
your
vulnerabilities
in
github
issues.
A
If
you
see
something
like
that,
please
ask
them
to
like
I
mean
not
putting
actually
the
exploit
there,
because
when
they
do
that
they
are
actually
exposing,
they
are
not
giving
us
a
chance
to
to,
and
they
are
exposing
others
for,
like
other
other
other
clusters,
other
people
to
that
vulnerability,
and
they
won't
have
the
chance
also
to
fix.
So
if
you
do
something,
just
kindly
ask
them
hey.
B
Okay,
just.
B
Okay,
just
as
a
note
besides,
the
cv
is
reported.
There's
also
one
issue
open.
I
don't
have
a
number
right
now,
but
it's
about
somebody
saying
there
is
a
vulnerability
with
the
certificates
as
far
as
in
if
multiple
subjects
and
alternatives
are
in
the
sni
for
one
single
certificate,
then
there's
an
issue
which
says
there
are
actually
two
issues
report
saying
that
is
a
that's
a
that's,
not
secure.
B
A
Okay,
send
them
to
me
and
I
I
will
take
a
look
into
them.
I
mean
right
now
that
I
that
I
could
get
rid
of
all
of
those
cves.
I
I
I'm
planning.
Actually,
I
need
to
create
some
way
like
some
spreadsheet,
or
something
like
that
to
me
that
I
know
what
what
is
actually
my
kiwi,
the
things
that
I
keep
promising
you,
how
you
know
the
meetings
to
review
and
I
keep
forgetting
so
sent
those
to
me.
A
I
will
just
open
a
spreadsheet
for
myself
and
and
prioritize
those
for
me
to
take
a
look
if
they
are
real
or
if
they
are
something
that
can
be
like
okay.
It's
not
that
thing
that
you've
seen
that
you
said
so
yeah,
okay
and
thank
you.
A
A
Any
any
issue
triage
that
you
folks
wanna
take
a
look
right
now
are
pull
requests
that
should
be
taken,
because
I
can
take
a
look
into.
Let
me
see,
I
have
five
more
minutes,
so
I
can
take
a
look
into
some
pull
requests
or
something
that's
already.
Let's
talk
and
we
can
we
can
take
a
look.
So
do
you
have
anything
in
mind
that
you
you
remember
on.
A
A
I
will
start
looking
again
into
my
qe
and
and
feel
free
to
send
them,
or
I
will
even
open
a
spreadsheet
or
something
like
that
that
that
we
can
probably
have
some
better
control
on
issues
and
pull
requests
that
need
attentions
of
each
person.
Like
me,
alvin,
gentile
and
other
folks.
A
B
Okay,
oh,
what's
the?
What
is
the
rough
estimate
for
releasing
that
ingress?
Con
english
annotation
english
class
ingress.class
annotation
becoming.
A
Yeah,
actually,
we
need
to
start
working
on
that
right.
So
what
I'm
doing
right
now
is
that
I
noah
did
a
great
job
with
certain
manager
folks
and
he
opened.
Let
me
show
you
he.
I
think
you
saw
that,
but
he
opened
a
pr
actually
improving
the
documentations
right
so-
and
this
is
this
is
great,
because
we
will
have
actually
a
contract
with
with
with
c
network
and
with
kubernetes
on
how
should
how?
A
What
I
want
to
do
is
actually
take
this
description,
sit
down
and
and
and
start
drawing
all
of
the
ingress
class
scenarios,
and
I
will
need
your
help
on
that
one.
So,
as
an
example,
how
can
we
allow
people
to
run
ingress
in
ginx
without
clusters
copied
permissions
right,
so
they
still
need
ingress
class
as
an
example,
but
ingress
class
can
be
an
annotation,
an
ingress
controller
reconciling
by
that
annotation.
So
this
is
one
approach
and
they
may
use
scoped
permissions
or
not.
A
So
I
would
actually-
and
this
is
something
that
I
I
asked
for
noah
as
well,
so
probably
we
three
should
do
an
architectural
design
on
that
before
I
start
developing
right
and
by
architectural
design,
I
mean
like
we
should
establish
the
scenarios
like
what
users
complain
and
what
we
think
it
should
happen
when
we
do
have
like
an
english
class
and
an
ingress
class.
And
how
can
we
even
keep
the
compatibility
in
a
sense
of
not
breaking
users,
and
then
we
can
start
actually
working
on
the
code.
B
Okay,
but
I
think
I
think
the
focus
is
just
two
bullet
two
points
focus
one
is
if
the
documentation,
if
the
official
documentation
already
starts,
saying
that
the
annotation
is
given
priority,
but
the
actual
code
in
the
controller
doesn't
do
that.
Then
we
have
to
have
an
understanding
among
us
that
if
somebody
raises
an
issue
or
currently,
we
should
just
update
them.
A
A
It's
not
it's
not.
Actually,
it's
not
actually
a
a
shame
on
saying
we
did
a
mistake.
We
didn't
follow
it.
What
the
annotations
said
when
we
were
developing
this
and
we
break
actually
the
desired
way.
So
now
we
are
not
going
to
roll
back
the
whole
behavior,
because
we
know
that
it
may
breaks
for
other
users,
but
we
are
thinking
on
a
better
approach
for
everyone
and
we
are
sorry
for
the
inconvenience.
That's
I
think
that's
fine.
In
my
opinion,.
B
Yeah
yeah,
I
think
I
think
we
should
just
have
general
understanding
that
that's
what
we
will
do,
but
I
was
just
saying
that
this
pr
is
already
in
place
for
documentation
right
and
I
didn't.
I
read
it
only
once,
but
I
think
it
says
that
the
annotation
is
is
officially
the
preferred
option,
but
our
controller
is
not
yet
implementing
that.
A
Sounds
good
and
if
you
see
like
a
lot
of
people
opening
the
same
issue
just
make
markers
duplicate,
close
and
point
to
the
other
one,
that's
fine,
so
we
may
work
in
just
one
okay,
we
can,
even
if
you
want,
we
can
even
open
like
an
umbrella
issue
from
ourselves
saying
we
need
to
improve
ingress
class.
We
know
this
this
and
that
problem,
and
if
people
keeps
opening,
we
say,
okay,
the
official
issue
is
this:
one
that
we
are
actually
following.
B
A
Okay,
all
right,
so
I
think
that's
all
for
today
I
really
have
to
drop
as
well
folks,
but
thank
you
all
and
feel
free
to
reach
me
in
I'm
checking
slack
more
on
these
days.
Now
that
I
have
some
a
bit
more
time
and
thank
you.
A
Thank
you,
everybody
for,
for
the
great
things
that
we've
been
achieving
so
far,
the
feel
free
to
ping
me
if
you
need
and
see
ya
and
I
by
the
way
I
think
that
the
next
meeting,
let
me
see
what
I
think
it's
gonna
be
during
cubecon.