►
From YouTube: Protect PM/CS Sync - February 2021
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
so
just
to
dive
into
some
of
the
things
that
we've
got
coming
up
in
the
near
term
that
I
wanted
to
share
with
the
group
today
in
1390
we're
releasing
alert
and
an
alert
dashboard,
which
is
a
big
deal.
We've
been
working
on
this
for
a
long
time.
It's
our
first
release
in
the
new
security
orchestration
category.
A
What
this
does
is
it
lets
you
take
security
alerts
across
the
company
and
surface
them
on
a
dashboard
and
provides
a
workflow
for
users
to
triage
those
and
respond
to
them.
So
I'll
show
you
a
quick
demo
of
this,
so
this
is
in
staging
and
I
never
know
what
I'm
actually
gonna
get.
So
I
come
here
and
I
just
hope
it
all
works
and
right
now
it's
actually
very
similar
to
the
monitor
teams,
alert
dashboard.
In
fact,
we
reused
a
lot
of
code
from
their
area
of
the
product.
A
So
for
this
very
first
release,
the
only
type
of
alert
that
we
support
right
now
is
alerts
coming
from
your
network
policies,
your
your
basically
from
get
labs
container
network
security.
A
So
to
set
these
up,
you
actually
go
to
your
policies
section
when
you
go
to
create
a
new
policy,
a
new
network
policy
you're
able
to
specify
your
rule
that
allows
the
traffic
in
because
solium
works
in
a
mode
where
it
denies
all
traffic
that
does
not
match
a
rule
and
then
so
you
create
this
say
you
know,
I'm
looking
for
traffic,
that's
inbound
to
you
know
any
entity
on
you
know.
Port
22
is
what
I'm
interested
in.
In
that
case,
you
know
really.
Nobody
should
be
sshing
into
a
live
container.
A
That's
running!
That's
not
best
practice,
but
there
may
be
a
business
need
to
allow
this
to
happen.
Perhaps
you
know
administrators
just
absolutely
have
to
have
a
back
door
into
the
containers
to
keep
them
up
and
running
if
something
goes
wrong.
So
in
that
case,
from
a
security
perspective,
the
business
requires
it.
So
you
want
to
allow
the
traffic
in,
but
you
also
want
to
monitor
that
very
closely.
So
you
come
in
here.
A
A
This
is
not
intended
to
be
a
logging
tool
like
if
you're
just
trying
to
capture
all
traffic,
then
you're
misusing
alerts
alerts
should
be,
as
it
says
here
in
this.
This
message,
right,
like
alerts,
should
be
things
that
are
limited
to
low
volume,
events
that
are
concerning,
and
you
actually
have
a
human
reviewing.
Those
events-
it's
not
just
you,
know,
log
all
traffic,
that's
inbound
on
on
port
80.
That
would
be
overwhelming.
A
You
might
also
want
to
generate
an
alert
for
traffic
detected
traffic
attempts
outbound.
You
know
from
the
container
which
might
indicate
some
kind
of
data
exfiltration,
so
at
a
super
high
level.
That's
where
we're
at.
We
have
a
lot
of
issues
planned
to
improve
the
ui
experience
here.
A
The
only
other,
big
thing
that
I
wanted
to
cover
real
briefly,
is
we're
our
work
in
security,
orchestration,
we're
working
to
create
a
policies
page
where
you
can
configure
require
scans
to
be
run
for
certain
projects,
and
this
will
have
a
different
set
of
permissions
than
editing
the
gitlabci.yaml
file.
So
that
way,
only
maintainers
will
be
able
to
propose
changes
to
these
policies
and
then
only
a
named
list
of
individuals.
A
Typically,
your
security
team
will
have
the
authority
to
approve
those
policy
changes
and
once
you
have
a
policy
set
up
to
require
a
scan
to
take
place
again,
like
your
average
developer,
can't
turn
that
off
it
takes
precedence,
regardless
of
what's
in
your
getlabsti.yaml
file.
So
it
ensures
that
you
know
no
matter
what
you
can
sleep
easy
at
night.
Knowing
that
you
know
your
dash
scan
is
going
to
run
with
the
configuration
that
you
specify.
A
So
that's
the
next
big
thing
that
we're
working
on
here
and
I'll
leave
it
with
that
sort
of
short
overview
just
for
the
sake
of
time.
But
if
there
are
customers
that
would
have
feedback
in
any
either
of
those
two
areas,
we're
we're
very
interested
in
that
we're
doing
research
in
that
area
right
now,
trying
to
make
sure
that
it's
going
to
meet
their
needs.
B
B
A
A
Your
scan
policies
that
I
just
talked
about
right,
which
don't
exist
in
the
product
yet
today,
but
will
in
the
future
that
you
know
you
might
want
to
flag
or
get
an
alert
when
a
new
critical
vulnerability
is
identified
in
certain
projects.
So
we
want
to
give
you
the
ability
to
schedule
scans
and
also
to
generate
alerts
off
of
that.
So
you
can
say:
okay
run
a
scan
once
a
week
against.
A
You
know
these
sensitive
projects
and
if
I
see
any
new
critical
vulnerabilities,
send
me
an
alert,
so
I
can
go
review
it
and
then
the
other
area
that
we're
thinking
about
is
git
lab
itself,
so
suppose
a
user.
You
know
this
is
a
little
bit
in
the
insider
threat
realm,
but
suppose
a
user
logs
in
from
the
u.s
one
day,
and
then
you
know
five
minutes
later
also
logs
into
gitlab
from
russia.
Well,
there's
no
way
they
were
in
two
places.
A
A
That's
what
we
plan
to
surface
in
that
page.
If
it's
something
that
can
be
handled
programmatically,
you
know
like.
If
you
know
that
you
want
to
drop
the
traffic,
you
don't
need
to
generate
an
alert
for
that.
You
just
drop
the
traffic
right,
but
these
are
things
that
actually
warrant.
Human
review
is
what
that
page
is
intended
to
be.
B
Any
kind
of
activity
going
on
on
the
code
repository,
so
this
is
all
happening
in
the
ci
space
right
now,
presumably
because
there
will
be
some
scans
going
on
and
then
once
the
continuous
delivery
portion
occurs
and
then
there's
that
monitoring
piece
going
on,
but
I'm
kind
of
pulling
it
further
upstream.
If
there's
anything
going
on
there.
A
Yeah,
so
my
vision
is
definitely
inclusive
of
that,
like
I
said
anything
that
would
constitute
a
security
alert
in
anywhere
in
gitlab.
This
is
the
dashboard
for
that.
We
do
not
have
any
like
definitive
roadmap
plans
to
make
that
happen.
What
you're
talking
about,
but
it's
definitely
part
of
the
vision.
B
Good,
no,
that
that's
that
helps
yeah.
We
can't
get
there
yet,
but
it's
nice
to
know
that
you're
planning
for
a
bigger
vision
on
that
which
is
kind
of
cool.
B
A
So
that
is
not.
We
are
explicitly
not
trying
to
be
a
sim.
A
Deduplicate
them
enrich
the
data
aggregate
them
like.
So
so,
no,
that's
not
part
of
the
vision
for
people
who
are
not
using
kubernetes,
though
that
is
part
of
our
vision,
but
it's
not
part
of
the
near-term
vision.
So
right
now
we're
very
laser
focused
on
kubernetes.
A
Only
at
some
point
you
know
we're
going
to
go
from
infancy
here
to
viable
and
complete,
and
at
that
point
we're
going
to
start
branching
out
looking
at
serverless
on
the
one
side
and
vms,
and
you
know
bare
metal
machines
on
the
other
side,
but
that
would
probably
involve
the
creation
of
new
groups
inside
of
protect
like
right
now.
Protect
just
has
the
container
security
group,
but
you
can
imagine
a
serverless
group
in
the
future
or
a
you
know.
A
On-Prem
group
in
the
future,
but
that's
that's
pretty
far
into
the
future
right
now
we're
kubernetes
only
and
you
know
we
want
to
nail
it
there
before
we
expand
out
understood.
B
So
in
the
realm
of
kubernetes,
for
example,
aws
might
have
some
similar
things
that
it's
doing
with
regards
to
alerts
and
monitoring.
B
A
Yeah,
so
network
policies,
kubernetes
network
policies,
especially
are
widely
used
all
over
the
place.
Customers
can
just
use
them
on
their
own.
They
don't
need
to
get
loud.
You
know,
google
and
amazon
have
integrations
with
network
policies
and
we
do
too
right.
So
this
is
a
replacement
for
that,
but
I
believe
we're
in
a
better
position
to
manage
that,
because
we
own
the
code
repository
cool.
So
that's
really
the
story.
There
is
that
you're
able
to
manage
your
network
policies
as
code.
In
your
code
repository
you
have
full
change.
Log
auditing.
A
You
can
put
it
through
an
approval
process.
You
know
so
a
lot
of
these
other
tools.
Even
you
know
tools
like
twist
lock
and
you
know
other
professional
tools
that
do
this
are
lacking
some
of
those
capabilities.
So
there's
a
lot
that
we
offer,
just
by
being
a
code
repository
and
handling
some
of
these
security
policies.
As
code.
B
Cool,
that's
that's
powerful!
That
message
is
very,
very
powerful,
I
think,
and
then
last
but
not
least,
I
have
a
lot
of
customers
running
openshift.
B
A
It's
on
more
of
the
long-term
radar.
It's
tricky
because
right
now
we're
using
app
armor
and
openshift
doesn't
support
app
armor
and
we're
also
installing
through
gitlab
managed
apps
version
2,
which
requires
admin.
Privileges
in
the
cluster
and
root
access
and
openshift
doesn't
allow
root
access
so
we're
a
ways
away
from
supporting
openshift
the
new
gitlab
kubernetes
agent.
A
I
don't
know
how
familiar
you
are
with
that,
but
the
configure
team
has
been
working
on
that
will
help,
because
that
does
not
require
root
access,
so
that
gives
us
a
way
to
go
in
and
install
without
requiring
that.
A
So
I
I
don't
know
we're
gonna
have
to
wait
till
we
actually
test
it
out,
but
I
suspect
you
know
once
that
work
is
done,
we'll
have
partial
support
for
openshift,
but
we
require
app
armor
for
our
blocking
and
so
that
piece
may
just
never
work
on
openshift
unless
we
move
away
from
app
armor
to
something
else,
but
eventually
yes,
we'd
like
to
support
it,
but
it's
it's
gonna
be
a
slow
process
to
get
there.
B
Okay,
I
think
maybe
you
know-
I
know
we're
a
little
bit
over
time
at
this
point,
but
I'm
just
maybe
maybe
we
can
take
it
up
offline
or
asynchronous
to
discuss
a
little
bit,
because
there
is
the
there's.
The
end
goal
approach
which
is
like
you
described
to
be
able
to
do
everything
automated,
but
then
there
might
be
a
maybe
secondary
option
where
we
can
offer
hey
you
install
what
you
want
to
install
there
by
your
admins,
but
then
once
it's
installed,
then
we
can
connect
to
it.
Somehow
if.
A
Yes,
I
think
the
the
biggest
sticky
point
is
app
armor.
I
don't
think
openshift
supports
app
armor
at
all.
If
I'm
not
mistaken,
so
that's
not
even
like
you
know,
even
an
admin
can't
really
do
that.
A
So
I
I
don't
know,
there's
a
lot
to
be
done
there.
Quite
frankly,
it's
lower
on
our
priority
list
right
now,
because
we
are
just
in
our
infancy
like
we're
just
trying
to
get
these
features
going,
but
it
is
on
our
radar
at
least
like
I'm
well
aware
of
the
need
for
openshift,
it's
probably
something
that
we're
going
to
circle
back
to,
and
you
know
you
know
basically,
once
we
get
this
initial
work
done,
we'll
kind
of
pop
our
heads
up
and
look
around
and
say:
okay.
A
Well,
where
are
we
at
and
what's
the
delta
between
here
and
openshift
support,
like
I
said,
it's
very
possible
that
we'll
have
at
least
partial
support
for
some
or
most
of
our
features,
even
if
you
know
so
like
eighty
percent,
but
getting
to
that
hundred
percent
is
going
to
be
a
lot
of
extra
work.
B
Yeah,
no,
I
I
I
completely
understand
that
and
it
you
know
it's
not
just
this
team,
that's
struggling
through
that
it's
it's
all
across
gitlab
that
we're
struggling
with
openshift
as
a
whole.
So.
A
Very
cool,
I
know
the
the
actual
discussion
part
of
this
was
a
little
bit
short,
but
thanks
for
that
discussion,
and
if
you
have
other
things,
please
feel
free
to
send
them
async
or
or
in
our
pmcs
sync
channel,
and
that
would
be
it
would
be
great.
B
Yep
we'll
get
right
on
it
and
get
get
some
of
that
movement
going.
Thank
you
for
showing
this
stuff
sam.
This
was
excellent.
I
think
this
is
the
right
direction,
right
kind
of
tone
that
you're
setting
here
with
what
we
want
to
be
doing.
I
can't
wait
for
this
to
come
out.
This
will
be
really
cool
awesome.
Well,
thanks.
I
appreciate
it.
Thank
you.
Have
a
good
one.