►
From YouTube: Defend:Container Security Weekly Group Discussion
Description
Weekly meeting for the Defend:Container Security group
A
All
right
welcome
everyone
to
our
container
security
group
discussion
like
today.
We
don't
have
very
many
agenda
items,
just
the
one
that
I
added
so
I
just
wanted
to
go
over
and
do
a
quick
review
of
what
we
have
planned
for
13
to,
especially
with
the
the
adjustments
and
allocation
for
this
group,
especially
I,
wanted
to
confirm
lucky
Tiago
our
plans
for
what
we
saw
that
we're
getting
people
over
class.
A
A
A
Which
we
do
now
our
final
designs
from
Andy,
which
is
great,
so
I-
think
we're
in
a
really
good
spot.
There
I
just
wanted
to
check,
as
all
of
these
implementation
ones
were
March,
13,
3
and
13.
For
so
I
didn't
want
to
check
and
see.
Do
you
see
us
getting
to
any
of
that
in
13
at
all,
or
are
we
pulling
out.
B
Possibly
so
I've
if
I
remember
correctly
the
last
time
I
organized
these
were
way
before
the
start
of
the
iteration.
So
I
was
being
sort
of
just
spread,
spread
the
goodness
around
a
few
iterations.
So
we
might
be
able
to
pull
some
okay
I've
added
a
a
an
item
to
the
agenda
and
apologies
for
not
doing
before
the
meeting
but
I
get
to
the
planning
breakdown.
So
did
you
wanna
dijanna
review
the
backlog
first,
so
it
you
wanna,
have
a
look
at
this
planning
brief
yeah.
A
I
I,
don't
I
mean
I
posted
this
new
issue.
This
planning
issue
in
the
black
channel,
but
I
also
wanted
to
just
discuss
it
real
briefly
in
this
meeting
as
well,
just
to
see
if
there
was
any
additional
feedback,
especially
from
you,
Arthur
and
the
mayor
he's
not
here
at
the
moment,
but
you
know
right
now:
we've
got
things
spread.
Some
things
are
issues
some
things
or
ethics.
You
know,
we've
got
like
the
high
level.
A
B
To
add
to
this
Sam
for
anyone
wondering
why
we
created
this:
it's
because
the
ethics
featuring
it
lab
doesn't
doesn't
support
showing
epics
in
the
in
the
board.
So
if
you,
if
you
have,
if
you
want
to
prioritize
an
epic
above
everything
else,
there's
no
way
to
communicate
that
using
just
a
board.
So
this
decisions
a
bit
of
a
stopgap
measure
until
we
have
that
built
in
to
get
lab
right.
B
A
C
Scented
I,
don't
think
it's
helpful
to
me
personally.
I
usually
felt
like
I
need
to
know
what
to
do
in
the
iteration
and
then
once
I
get
into
that
iteration
I
just
focus
on
my
issues
and
I
know
my
priorities.
My
priorities
and
of
what
I'm
working
on
before
so
I
I
say
that
it
will
be
useful
for
geography,
for
example,
if
I
will
stop
or
finish
something
a
bit
earlier,
he
will
get
a
sense
of
information
about
what
should
we
prioritize
next?
A
All
right:
well,
thanks
for
that
feedback
and
then
I
had
to
say
a
couple
of
questions.
Just
a
couple
coordination
questions.
So
this
adoption
in
usage
metrics,
one
I,
think
we
marked
as
done
and
curate
and
I
can
post
this
on
the
AC
T,
but
I'm
wondering
has
anyone
actually
looked
to
see
if
we
can
get
this
data
all
the
way
through
and
into
into
our
siphon
dashboards
or
periscope
dashboards,
or
we
just
verified
that
we're
reporting
it
as
part
of
these
each
being
kind
of
ended
off
there,
I've
I
think.
B
B
A
B
Should
I
should
know
if
you're
not
familiar
with
that,
it's
not
obvious
at
all
that
I've
that
I've
redacted
it
and
the
the
second
part
of
your
question,
maybe
Lindsey
knows
I,
do
not
know.
I
would
assume
I
assume
that
this
does
end
up
in
periscope,
but
I
wouldn't
know
how
to
find
out.
Do
you
Lindsey
I.
D
B
B
A
B
C
A
C
Sorry,
we
have
created
delay
for
this
amendment
and
a
sign
I
think
we
definitely
won't
be
able
to
finish
it
in
13.2,
because
I
haven't
started
and
they
just
refining
it,
and
it's
a
really
watch
one
I
think
the
real
weight
of
all
the
issues
will
be
around
20
I
would
assume
somewhere
in
the
area.
So
it's
more
than
the
single
iteration
differently
was.
A
A
A
A
B
Ahead,
you
can
you?
Can
you
bring
up
the
agenda
item?
The
planning
breakdown
issues,
the
second,
the
second
link
there.
So
the
first
one
is
that
one
doesn't
mean
has
been
working
on
it
and
there
were
two
tasks
that
we
hit:
that
that
discussion
about
the
scope
of
pot
security
policies,
whereas
me
was
saying
upon
security
policy-
applies
to
to
the
whole
cluster,
and
then
our
two
Arthur
found
security
context
that
can
reduce
their
constitute
context
to
just
a
pod.
B
A
B
And
that
was
the
plan,
the
the
reason
this
was.
This
was
a
mere
thinking
out
of
the
box
and
and
trying
to
come
up
with
a
solution
just
to
propose
something
instead
of
just
bringing
hey
I'm
stuck
he
he.
He
came
up
with
that.
It's
it's
okay,
that
it
that
we
should
amuse
me
now
that
that's
fine,
but
we
I
think
we
still
need
to
understand.
B
Do
we
have
a
problem
with
with
isolating
the
the
scope
using
just
here
more
files?
Do
we
need
to
think
of
something
else
or
as
engineering?
Do
we
just
need
to
dig
dig
a
little
bit
more
research,
a
bit
more
and
and
see
if
we
can
do
yam
so
I,
don't
know
the
answer.
I
just
wanted
to
throw
it
out
there.
After
have
you
picked
up
any
any
of
these
off
since
your
last
comment
suggesting
security
context,
no.
C
I
honestly,
because
you
said
I
feel
like
after
the
last
comment
them
may
sing
some
context.
So
I
will
probably
not
comment
any
further.
This
look
at
stage,
but
to
just
clarify
a
bit
to
some.
The
policy
is
based
upon
security
policies,
a
bit
unique
in
the
way
they
deport
the
cost
divided
by
definition,
but
then
they
have
to
be
linked
to
a
specific.
C
I
personal
opinion,
it's
better
to
handle
it
possible
in
UI
that
it's
we're
building
for
the
network
policies
rather
than
creating
a
separate
view,
I
think
it's
from
my
understanding.
It
should
be
possible
to
resolve
some
of
these
Sammy
is
saying
by
pre
defining
all
this
is
classified
policies
along
with
service
account.
This
is
called
your
link
to
the
namespace.
It's
it's
a
bit
technical,
complicated,
so
I'm
not
gonna,
spend
much
that.
C
B
Sam
correct
me
if
I'm
wrong,
but
the
the
preference
that
we
have
right
now
is
to
avoid
a
solution
that
involves
UX,
because
we
still
doing
work
in
that
space
and
we
want
to
consider
it
a
little
bit
more
globally
or
consistently
across
the
board.
So
if
there
is
a
solution,
even
if
it,
even
if
he
changes
a
little
bit
the
the
requirements
or
creates
some
caveats,
we
would
we
would
strongly
prefer
a
yamo
solution.
A
Correct,
yes,
that
is
a
fair
summation
and
it
sounds
like
the
challenges
are
mostly
around
installing
cloud
security
policy.
The
finder
stood
Arthur
right,
and
that
actually
makes
me
happy
because
we
will
want
to
apply
these
at
the
namespace
and
the
pod
levels.
It's
going
to
cause.
A
number
of
complications
were
not
able
to
do
that
so
I'm
I'm
hopeful
that
that
functionality
actually
does
exist
within
pod
security
policies
and
there's
just
a
hurdle
around
installation.
Yeah.
C
It's
I
think
again
to
emphasize
my
understanding
is
that
it's
or
to
develop
specific,
because
how
to
do
ops
is
using
restricted
account
again,
if
you
will
go
with
the
policy
you
are
today,
building
account
that
way,
isn't
up
there,
it's
less
restricted
and
it
has
administrative
permissions
on
the
kosta.
So
we
definitely
have
less
problems
up
there.
So
I
would
say:
maybe
just
defer
this
decision
until
they
have
a
policy
beauty
and
maybe
make
it
up
there.
It's
you
probably
need
to
constantly.
B
Would
I
think
I
think
for
Sam
to
first
allows
Sam
to
make
a
call?
We
would
need
to
investigate
a
proposal.
Explain
what
the
the
trade-off
would
be
in
terms
of
handling
the
permission
issues
on
the
auto
devops
side.
So
if
we,
if
we're
doing
that
through
yamo,
are
we
gonna
have
to
introduce
a
privileged
account
or
we're
gonna
have
to
have
a
escalation
of
privilege
and
introduce
anything
like
that
in
the
in
the
framework
that
doesn't
exist.
So
if
that
becomes
a
lot
more
work,
then
I
think
I
think
that
would
change
Sam's
decision.
B
Engineering
we
take
that
back
Arthur,
we,
you
you
and
you
and
Zamir
Zamir-
takes
a
lead
on
on
this,
but
I
think
I.
Think
you
appreciate
a
need
you
your
help
on
this
and
then
and
then
we
come
up
with
a
with
a
with
a
with
an
offer
to
Sam,
say:
hey
here's
what
we
found
out,
we
can
do
yeah
mo,
but
it's
gonna
take
this
or
we
can
wait
and
do
in
the
UX
and
already
use
the
stuff.
That's
in
there.