►
Description
Be sure to check out the Application Infrastructure Security planning board: https://gitlab.com/groups/gitlab-org/-/boards/1420731?label_name[]=group%3A%3Aapplication%20infrastructure%20security
A
Hello
again,
this
is
Matt
Wilson
senior
p.m.
for
defend
and
I
am
filling
in
once
again
for
Sam
Kerr,
who
is
the
regular
product
manager
for
the
application
infrastructure
security
group.
So
today
we're
going
to
be
talking
about
the
release
items
for
the
upcoming
12.7
iterations,
which
is
about
to
kick
off.
So
let's
go
ahead
and
start
by
sharing
what
we've
got
planned
for
twelve
seven.
A
So
normally
I
would
focus
just
on
things
that
are
already
in
the
twelve
seven
column,
but
I'm
actually
going
to
show
what's
in
twelve
six
right
now,
because
these
two
items
are,
there
were
stretch
goals,
which
means
that
the
engineering
teams
had
committed
to
start
looking
at
them,
but
not
to
actually
delivering
them
in
a
particular
release.
So
these
two
items
are
going
to
go
at
the
top
of
12
seven
and
are
likely
going
to
consume
the
majority
of
the
release,
and,
what's
that's
what
we're
gonna
see
in
the
actual
12?
Some
relates
itself.
A
So,
let's
jump
into
the
first
item.
So
this
is
the
minimum
viable
change
for
container
intrusion,
detection
system
or
IDs.
So
what
we're
trying
to
do
with
this
is
give
our
users
a
way
to
detect
any
sort
of
malicious
activity
that
may
be
attacking
the
application
or
the
infrastructure
itself.
So
this
would
be
something
that
sets,
after
the
actual
any
sort
of
network
security,
detection
piece
and
closer
to
the
application
with
the
container
itself.
A
What
we
are
proposing
with
this
MVC
is
to
leverage
the
open
source,
Falco
project
or
software,
and
allow
that
to
be
deployed
into
get
lab,
managed
clusters,
so
Falco
will
then
start
detect
events
that
are
happening
and
we're
going
to
provide
a
minimal
way
to
actually
display
that
information
to
our
users.
So
what
are
we
going
to
cover
with
this?
So
as
I
mentioned
Falco,
that's
the
technology
that
we've
selected
for
this
MVC
and
we're
going
to
give
users
a
way
to
deploy
that
like.
A
If
your
configuration
file
as
prayer
kind
of
our
normal
way
of
doing
things
around
here
and
then
we
also
will,
of
course
allowed
to
be
uninstalled.
If
you
tear
down
your
your
cluster
or
you
need
to
remove
it
after
installation,
the
other
key
piece
is
giving
people
an
ability
to
view
logs
now.
This
is
likely
not
going
to
be
fancy,
probably
not
a
whole
lot
of
UI
work,
but
at
a
minimum
allowing
users
to
tale
the
contents
of
the
container
that's
running
Falco,
so
that
we
can
actually
see
what's
what's
going
through.
A
What's
going
on,
this
is
going
to
be
the
first
and
kind
of
laying
the
groundwork
for
future
logging
statistics,
reporting
and
visualizations
of
what's
actually
happening
inside
the
IDS's.
So
that's
the
first
item
for
twelve
seven
and
the
second
is
also
a
continuation
of
work
that
started
in
twelve
six.
So
this
is
a
related
MVC.
So
this
is
for
our
container
network
security
component.
A
Specifically,
we
are
going
to
install
a
default
network
policy
object
into
your
gaze
lab,
manage
Kay
it's
clusters,
so
one
thing
about
kubernetes
clusters
is
by
default.
Any
pods
can
track
or
can
accept
traffic
from
any
other
container
and
pods,
but
that
also
means
that
they
could
accept
traffic
from
any
pot
or
container
inside
the
cluster.
A
So
if
you
do
have
any
sort
of
a
breach-
and
there
is
malicious
activity
happening
from
somewhere
else
with
inside
the
cluster,
even
if
it's
from
a
particular
pod
that
wouldn't
normally
talk
to
other
other
parts
like
an
application
pond,
for
instance-
there's
no
way
to
prevent
that
by
default.
So
what
we're
proposing
it
just
kind
of
start
down
the
path
of
helping
to
lock
that
down
is
applying
a
container
network
security
piece.
We
we
debated
back
and
forth
between
calico
and
psyllium.
A
So
for
this
NBC,
like
many
things
that
you've
heard
us
say
we
are
going
to
provide
basic
functionality,
and
this
involves
really
more
sort
of
installation
and
listening
now,
because
the
network
policies
have
the
potential
for
even
a
we'll
say,
a
same
set
of
defaults.
We
can't
guarantee
that
in
every
cluster
situation,
it's
not
going
to
accidentally
block
traffic.
So
for
that
reason
we
are
not
going
to
actually
apply
a
default
policy
with
this
MVC.
A
So
as
it
says
here
we're
going
to
try
to
provide
an
acceptable
and
sane
permissive
policy,
but
we're
going
to
leave
it
disabled
or
commented
out
so
any
users
that
are
knowledgeable
enough
to
look
at
that
default
policy
and
decide
that
they
will
work
for
their
needs
and
turn
on.
They
do
so
and
will
also
allow
you
to
make
any
configuration
changes
needed,
but
we're
not
actually
going
to
be
doing
any
enforcement
by
default.