►
From YouTube: Defend: Container Security Weekly Group Discussion
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
B
So
I
really
just
have
one
for
today,
which
is
to
provide
an
out
of
the
box
network
policy
set
and
really
the
work
here
is
both
for
engineering
to
propose
what
that
policy
set
would
be
so
first
to
develop
and
get
approval
on
a
default
policy
set,
and
then
the
second
step
would
be
to
deploy
it
by
default
in
a
disabled
state
when
psyllium
is
first
installed,
and
so
that
process
could
just
be
instructions
in
our
documentation
on
how
to
deploy
that
default
policy
set.
B
But
in
any
case
the
user
would
be
able
to.
You
know
by
default,
launch
that
that
out
of
the
box
policy
set,
you
know
if
we're
doing
it
for
them,
it
should
become
disabled
by
default,
and
then
they
could
enable
it.
You
know
if
it's
just
documentation,
then
obviously
they
can
choose
whether
to
enable
or
disable
it
depending
on
what
they
want
to
do
so,
hopefully
a
fairly
small
one.
Are
there
any
questions
on
this?
B
I
did
start
a
small
list
of
things
that
I
might
include,
but
you
know
I
was
just
trying
to
feed
the
discussion
here.
I
feel
like
I'm,
not
the
expert
in
this
case
that
I
would
really
look
to
probably
somebody
like
arthur.
You
know
who's
more
experienced
with
phillium
to
put
together
what
they
would
propose
as
a
default
set
of
rules
here
or
default
container
network
policies.
C
I
have
a
question:
we
would
ask
the
we
would
get
the
input
from
the
user
in
terms
of
the
name
space,
and
things
like
this
is
that
the
call.
B
So
I,
where
this
is
a
default
out
of
the
box
one,
you
know,
I'm
envisioning
this
being
something
similar
to
like
our
default
owasp
policy
set
with
with
the
web
application
firewall
where
you
know.
Hopefully,
we
write
these
policies
in
a
generic
way
that
it's
something
that
most
users
would
want
applied
to
all
of
their
environment
and
all
of
their
name,
spaces.
B
D
I
got
a
follow-up
question
so
so
it
sounded
like
we
don't
we
don't
much
care
about
the
namespace.
It
would
apply
to
to
the
whole,
to
all
the
containers
or
to
all
the
namespaces.
D
And
all
the
clusters
all
right
and
then
the
second
thing
is:
if
the
spirit
of
this
of
the
problem
to
solve
is
that
get
get
like
a
give
users
a
head
start
or
give
them
some
some
some
idea
of
what
policies
look
like.
D
Should
we
have
some
some
blocking
rules
instead
of
just
logging,
because
they're
going
to
be
deployed
in
a
you
know,
audit
only
that's!
I
think
I
think
I
read
that
somewhere
and
do
you
think
that
would
cause
issues
if
they
decided
to
enforce
that
and
stop
breakers.
Most
things
will
be,
will
be
doing
like
port
443
or
80
or
some
other
service,
and
everything
else
should
be
disabled.
So
if
we
provide
those
rules,
it
probably
does
what
most
of
the
users
want.
B
B
You
can't
control
that
on
a
per
policy
basis
right
now
very
well,
it's
more
of
you
know
once
you
put
it
into
blocking
mode
where
all
of
cilium
is
blocking,
then
you
write
rules
that
are
exceptions
to
that
and
allow
traffic
through,
and
so
we
would
not
want
to
recommend
customers
to
go
down
that
route,
because
that's
going
to
be
a
pretty,
you
know
difficult
path
to
go
unless
they
write
rules
that
allow
all
of
the
traffic
through
that's
legitimate
and
unless
they're
experienced
at
writing
psyllium
network
policies.
B
B
So
you
would
be
logging
anything
that
you
know
may
be
malicious
or
suspicious
or
things
that
you
know
may
be
cause
of
concern.
But
you
know
the
intent.
The
the
sort
of
prime
directive
or
imperative
here
is
like,
let's
not
block
valid
production
traffic,
but
at
the
same
time,
can
we
give
them
an
out
of
the
box
set
that
lets
them.
B
F
I
just
wanted
to
say
that
we
tried
to
solve
this
problem
once
and
when
we
were
all
in
psyllium
and
we
were
discussing
which
policies
to
deploy
by
default
and
the
outcome
was
that
we
don't
really
know
much
about
users
deployments
and
based
on
that,
I
actually
struggle
to
suggest
even
right
now
something
sensible,
rather
than
block
everything
yeah.
The
only
idea
I
have
is
to
leverage
applications
that
we
bundle
kind
of
into
the
github,
like
congress.
A
F
Stack
y
and
d,
you
know
other
software
that
you
can
sound
to
your
cluster
for
the
github
and
maybe
write
policies
around
that.
So
essentially,
when
you
install
elastic
stack,
you
will
have
an
ability
to
isolate
it
and
pass
the
traffic
from
elastic
stack
to
your
application
in
in
the
opposite
direction,
but
something
more
generic.
It's
it's
really
tricky
ports
are
not
necessary,
will
be
18443
for
applications
in
kubernetes.
So,
even
like
writing.
F
A
policy
for
http
traffic
is
a
bit
tricky
and
we
can't
really
use
any
static
information
like
let's
say
a
product
or
ccp,
but
then
which
part
to
use
to
block
specific
traffic
like
let's
say
http
in
the
app
it's
huge
you
know
like
if
you
go
and
check
network
policy
app
right
now,
it's
actually
it
sports
are
not
serving
http
traffic
on
port
80.
They
are
serving
on
8080
and
then
ssl
termination
is
actually
happens
usually
on
in
in
grass.
B
Yeah
I
mean
so
the
deployments
are
going
to
be
so
diverse
that
you
know
the
only
rules
that
we
can
really
write
are
ones
that
are
likely
to
be
very
common
across
all
of
them.
You
know
so,
like
the
examples
that
I
have
here.
You
know
logging
all
traffic
between
namespaces
sort
of
the
assumption
there
is
you
know
that
in
a
typical
cluster
you
wouldn't
really
want
or
need
traffic
to
cross
between
namespaces.
B
You
know
now,
there's
always
going
to
be
an
exception
to
that
every
you
know
for
every
one
of
these
you're
going
to
find
a
customer.
That
has
a
reason
not
to
do
that,
but
if
we
can
stick
with
rules
that
are
common
for
you
know
the
way
that
most
people
use
it.
That's
really
where
I'm
headed,
and
we
definitely
don't
want
to
block
anything
because
there's
a
chance
that
we
have
the
rules
wrong
because
we
don't
know
each
individual
customer's
environment,
but
the
intent
of
this
is
just
to
provide
a
base
set
for
them.
B
You
know
where
they
can
see
like
you
know.
This
is
a
starting
point
and
they
can
customize
it.
So
if
they've
got
traffic
going
out
of
port
8080,
instead
of
you
know
443,
they
can
go
in
and
just
tweak
that
you
know
same
thing
with
these
other
ones,
like
logging,
traffic
between
containers
and
the
host.
B
The
assumption
there
is
that
you
know
that
should
be
infrequent
if
at
all,
and
so
you
at
least
want
to
log
that
logging
any
outbound
initiated
traffic,
that
you
know
any
egress
traffic
again
assuming
most
traffic
should
be
inbound,
not
outbound,
and
then
you
know
some
sort
of
like
port
filter,
but
I
don't
know,
do
you
feel
like
these
are
too
specific
still
or.
F
No,
it's
just
from
implementation
perspective
like
you're,
saying
logo
traffic
between
namespaces.
It
means
like
on
on
implementation
level
like
if
I
was
a
devops
engineer,
and
I
wanted
to
do
that.
I
would
go
and
place
a
policy
in
each
specific
namespace
that
I
want
to
isolate
against
other
namespaces.
So
to
implement
that
I
need
to
need.
I
need
to
know
namespaces
where
to
put
those
I
know
namespaces
of
the
app
but
other
than
that.
F
F
I
I
I
just
can't
get
this
information
right
now
from
anywhere.
It's
really
a
tough
one
to
be
honest,
yeah
and
then
outbound
traffic
outbound
traffic
is
somewhat
easier.
But
again
it's
namespace
specific.
I
can
let's
say
a
wall
or
outbound
traffic
or
block
all
outbound
traffic
in
namespace
and
again
policies
name,
space
scope.
F
F
So
those
two
we
know
as
in
that
it's
like
completely
gray
area
to
us
right
now
and
I
think
github
doesn't
really
try
to
get
up
there,
at
least
from
understanding
from
what
this
configure
group
is
doing,
they're
trying
to
isolate
themselves
into
like
corner
of
the
cluster
and
don't
get
permissions
to
anything
else,
unnecessary,
so
yeah.
F
I
will
try
to
think
about
it,
but
we
will
still
might
need
to
some
kind
of
user
input.
We
I
mean
we
can't
define
a
policy
that
is
ready
to
use
completely.
We
still
might
need
some
kind
of
using
so.
F
F
D
B
D
F
F
C
Yeah,
that's
that's
why,
in
the
beginning,
I
was
thinking
that
we
would
have
a
little
bit
more
input
to
be
able
to
handle
this.
I
have
a
question
sent.
Do
you
think
that
there
would
be
a
place
in
in
gitlab
that
we
can
have
like
a
suggestion
of
network
policy
that
I
don't
know?
C
I
don't
know
how
the
ui
would
be
for
that,
and
then
the
person
would
would
click
a
couple
of
options
and
based
on
the
options,
we
would
have
the
network
policy
with
the
labels
if
needed
or
namespace,
or
things
like
this.
So
then,
in
a
way
that
the
customer
doesn't
know
exactly
how
the
policy
is
formatted,
but
they
can
figure
out
something.
F
F
I
I
was
saying
that
I
see
this
feature
is
more
as
a
template
rather
than
finished
thing
like.
Let's
say
what
indie
is
working
on
right
now
is
the
builder
right
some
kind
of
ui.
We
could
produce
templates
up
there,
something
that
will
allow
them
to
create
a
policy
a
bit
faster
by
selecting
a
predefined
template
and
then
put
some
values
in
there
and
it's
ready
to
go.
But
I
really
it's
really
hard
to
imagine
right
now,
something
that
will
work
out
of
the
box
without
additional
user
guidance
on
like
across
multiple
clusters.
F
D
A
couple
of
questions
before
just
can
ask
about
the
logging
we'll
go
back
to
the
other
one.
D
But
sam
do
you
mean
like
just
his
log,
fluency
or
or
some
some
something
more
like
in
terms
of
metrics
like
doing
stuffing
from
ethius.
D
Effort
so
arthur
going
back
to
something
you
you
mentioned
before.
You
said
that
psyllium
supports
cluster-wide
policies.
Would
would
that
be
an
option
just
recommending
or
suggesting
that
all
right,
if,
if
you
wanna,
if
you
wanna,
have
these
gitlab
supported
templates,
you
need
to
be
using.
F
For
some
of
those-
but
I
think
intention
of
the
classified
policy
is
to
work
with
external
traffic
to
the
question
from
the
question
to
the
question,
because
it
works
across
namespaces
like
it's
to
control
cluster
in
grey,
so
ingress
so
yeah.
Some
of
those
might
work
based
on
the
serium
cluster
white
policies,
but
I
need
to
do
a
bit
more
investigation
than
that
with
like
we
have
not
tried
to
deploy
those
yet
so
yeah.
I
have
only
limited
knowledge
in
this
area.
D
I'm
making
some
notes,
I'm
gonna,
I'm
gonna.
Add
these
comments
to
the
to
the
design
issues
that
okay,
sam
would
prefer
them
on
the
epic.
I
think
I
think
they
should
go
on
the
design
issue,
because
that's
the
that
was
the
point
of
creating
an
epic
to
leave
it
sort
of
clean.
I.
D
B
A
B
Okay,
well,
it
sounds
like
this.
One
is
not
quite
ready
for
refinement,
then
I
guess
I
don't
know.
I
don't
want
to
put
words
in
your
mouth
thiago.
This
list
here
is
not
definitive,
though
you
know,
we
can
remove
things.
We
can
add
things.
We
can
change
things
in
this
list
again.
You
know
this.
The
requirements
are
up
here.
D
Yeah,
I'm
gonna
go,
I'm
gonna
be
going
back
to
the
problem
to
solve
and
if
it
doesn't,
if
we
come
up
with
something
that
doesn't
fit
there,
that
that's
okay,
but
it's
about
giving
users
a
starting
point
and
and
some
tablets
that
show
show
them
what
what
we
can
support
and
what
they
can
do,
whether
or
not
they
they
need
to
do
a
little
bit
of
extra
work.
Where
we're
gonna
try
to
query
the
cluster
to
to
come
up
with
some
pre-field
values.
D
I
don't
know
I'll
rely
on
zamir
and
arthur
to
to
kind
of
guide
me
guide
us
on
that.
D
So
yeah
I'll
we'll
be
following
up
this
week.
Hopefully
next
week,
we'll
have
some
up
before
that
to
have
something
a
bit
more
concrete.
A
D
The
solution
so
yeah.
F
Yeah,
I
don't
have
an
input
on
the
process,
but
yeah.
I
will
try
to
research
a
bit
more
and
see
what
we
can
do
up
there,
but
yeah.
We
we
tried
it
once,
and
it
was
a
really
tough
one
to
like
put
something
generic
that
would
work
from
our
perspective
to
multiple
users.
We
had
a
really
long
thread
before
and
I
think
it's
gonna
like
if
you
want
just
generalized
in
some
way
like
templating
or
something
it's
just
gonna,
be
another
thread.
F
D
So
given
given
that
sam,
this
is
probably
not
what
you
want
to
hear,
but
given
that
you're
gonna
do
some
research
anyway
should
should
I
have
a
ticket
in
that
epic
to
track
the
this
research
track?
Some
experiments
define
define
what
we're
trying
to
find
out
the
answers
that
we're
trying
to
get.
A
F
Find
at
this
case
maybe
zamir
will
come
up
with
something,
and
I
come
up
with
something
then
maybe
out
of
the
discussion.
We
will
find
some
trends
or
something
because
it's
all
about
it,
feels
to
me
finding
something
that
will
work
in
most
cases
without
like
having
too
many
hk
situations
that
will
not
work
for
users.
G
Yeah,
I
think
so
samia
you
happy
with
that.
Yeah
yeah.
B
D
F
F
They
just
will
be
in
the
ui
like
the
constant
strings
in
the
chord
and
then
user
can
have
an
option
to
enable
it
and
when
it's
enabled
it
automatically
goes
into
cluster
and
then
it's
there
policy
rather
than
hours,
because
it
will
be,
it
will
have
id
inside
the
quest
and
they
will
be
able
to
manage
it
as
it
was
all
their
own
policy.
So
implementation
is
not
hard.
I
think
it's
quite
an
easy
part
of
this
specific
job,
but
finding
good
defaults.
That's
the
my
main
problem
for
me:
cool,
okay,.
B
I
know
I
know
we're
up
on
time.
I
had
a
couple
other
notes
there.
For
the
most
part,
you
can
just
go
read
those
on
your
own,
but
I
just
do
want
to
show
and
highlight
you
know
this
new
road
map
section
that
I
have
on
our
category
direction
pages.
If
you
haven't
seen
that
take
a
look
at
it.
I've
also
built
out
pretty
much
everything
for
container
behavior
analytics
to
viable
and
network
security,
I'm
still
getting
there,
but
I'm
getting
close
to
having
everything
in
there
to
go
to
viable.