►
From YouTube: KubeCon EU Office Hour: The Future of StackRox
Description
The Stackrox community has a new home! Join us at this office hour to find out -- and ask questions about -- Stackrox, KubeLinter, and our plans for open source technology.
A
B
Hey
there,
so
this
has
actually
been
very
exciting.
As
people
watching
probably
know,
red
hat
acquired
stack
rocks
earlier
this
year
we
have
with
us
michael
foster
and
chris
porter
from
stackrocks,
who
are
going
to
talk
a
little
bit
about
what
they
have
been
doing
since
then,
and
about
some
exciting
plans
for
the
near
future
and
maybe
even
a
fancy
new
website.
D
Yeah
sure,
hey
thanks
for
the
intro
that
was
pretty
spot
on
I'm
mike
foster.
I
was
a
cloud
native
advocate
at
stack
rocks
and
now
I
got
a
diet,
product
marketing
title
at
red
hat,
so
excited
to
be
here.
I'm
looking
forward
to
doing
more
technical
content,
specifically
on
the
stack
rock
side,
a
little
bit
more
so
yeah
chris
go
ahead.
C
D
D
Been
a
fun
change,
yeah
and
josh,
you
nailed
it
we're
just
looking
to
to
talk
to
you
about.
You
know:
what's
changed
the
last
couple
months
talk
to
you
about
community
first,
I
think
I
can
hand
it
over
to
chris,
because
I
know
we
want
to
go
over
some
changes.
What's
happened
since
starcraft's
been
acquired
a
lot
of
new
functionality
that
we've
added
and
hopefully
open
the
floor.
I
think
to
some
questions.
C
Yeah,
let's
start
with
that,
if
you're
familiar
with
stack
rocks
as
a
software
company,
you
know
we
focused
on
kubernetes
native
security
and
I'm
really
that
mission
really
hasn't
changed.
We
have
always
supported
the
enterprise
kubernetes
platform,
the
openshift
platform
from
red
hat.
Quite
a
few
customers
using
that
today
across
you
know,
enterprise
government.
C
For
for
our
customers,
you
know
the
stack
rocks
product
is
really
about.
You
know
about
that.
The
kubernetes
native
nature
of
it
right.
So
it's
a
security
product,
but
it's
also
kubernetes
native,
and
you
know,
the
thing
that
we
hit
upon
here
at
stackrocks
was
that
you
know
this
product
can
not
just
work
with
kubernetes.
It's
not
just
a
container
security
product
that
happens
to
work
with
containers
on
on
openshift,
but
rather
like
actually
leverages
the
platform.
C
So
I
like
to
talk
about
this
in
terms
of
you
know
what
the
developers
get
like.
The
advantage
of
of
choosing
security
through
this
approach
means
that
you
get
to
preserve
the
the
power
of
the
openshift
platform
right.
This
cloud
native
development-
and
you
know
the
the
the
insensitive
security
products
that
are
out
there,
that
deal
with
virtual
machines
and
other
security
topics
just
kind
of
miss
out
on
that
opportunity.
Like
we
love
the
flexibility
of
the
platform.
C
On
the
other
hand,
you
know
the
security
team
has
real
concerns
right.
When
you
give
a
lot
of
the
power
to
the
developers,
there
just
needs
to
be
a
little
bit
of
of
oversight.
You
know
that
we're
trying
to
to
make
make
both
sides
happy
here.
There's
often
conflict
in
organizations
between
you
know
the
go
at
a
million
miles
an
hour
new
development
cloud
native,
but
at
the
same
time
there's
a
security
team.
C
That's
trying
to
you
know,
hold
the
brakes
here
to
say:
hey
we've
got
to
make
sure
this
is
all
secure
before
we
go
out
into
production
or
we
have
you
know
we
have
compliance,
concerns
that
we
have
to
to
address
right.
There's
got
to
be
an
adult
in
the
room
who
says
hey,
we
we
have
to
make
sure
that
we
dot
our
eyes
and
cross
rts
here.
So
you
know
at
red
hat.
It's
still
the
same
product
that
you
hopefully
know
and
love
the
same
focus.
C
This
will
be
quite
familiar
the
same
as
the
you
know,
the
red
hat
openshift
dashboard
here,
which
we'll
get
into
just
really
to
be
in
line
with
the
you
know,
the
product
standards
that
are
met
here,
because
stack
rocks,
has
always
operated
on
an
agile
kind
of
development
model,
we'll
have
new
releases
every
three
weeks
right
and
that
that
cadence
has
been
kept
up
for
the
last
few
years.
Here.
It
means
that
we
can
make
incremental
changes.
We
can
rapidly
roll
out.
C
You
know,
fixes
and
updates
and
accommodate
new
new
feature
changes
from
from
product
management
or
from
customer
requests
if
you're
not
familiar
with
stackrocks.
Well,
you
know,
overall,
the
product
is
here
to
help
the
security
teams
get
what
they
need
out
of
application
security
right.
It's
visibility,
it's
understanding
where
common
security
problems
like
vulnerability
management
and
configuration
risk
exist
in
the
environment.
It's
about
runtime
monitoring,
which
is
an
extra
layer
of
detail,
that's
really
kind
of
hard
to
get
any
other
way.
C
If
you're
a
developer.
This
interface
is,
you
know,
certainly
interesting.
I
think
it
provides
a
lot
of
insight,
especially
when
it's
hard
to
dig
into
things
like
networking
to
show
you.
You
know
what
your
micro
service
applications
relationship
to
each
other
are,
but
we
really
don't
want
to
force
you
into
another
interface
right
security
teams
have
their
tools
developers.
Let's
say
they
don't
really
like
most
security
tools
right
as
a
developer.
C
I
don't
want
to
have
to
go
into
some
log
somewhere
else,
and
I
want
to
have
to
go
open
up
a
ticket
and
investigate
why
my
deployment
got
stopped.
What
I
want
to
do
is
work
in
the
tools
that
I'm
accustomed
to
using
right,
and
maybe
it's
a
pipeline
here
in
in
openshift-
and
you
know
I'm
using
this
to
build
and
deploy
my
applications.
C
So
if
I've
got
a
security
issue,
if
I've
got
a
vulnerability
or
something
I
want
to
see
it
here,
I
want
to
be
able
to
like
on
demand,
like
request
the
of
a
check
from
the
security
team,
to
understand
what
I
got
to
do.
To
get
this
thing
through
the
compliance
gauntlet
right.
Okay,
I
got
to
create
a
non-privileged
user
account.
C
I'm
I'm
encouraged
to
go
out
and
and
resolve
that
right,
especially
if
I
know
you
know
in
particular,
I've
got
you
know.
Particular
library-
and
I
know,
there's
a
new
version
and
I'm
not
being
asked
in
this
interface
to
go
out
and
fix.
You
know
lib,
xslt,
right
or
busybox,
I'm
being
told
that
hey
upstream
has
a
fix
that
that
I
can
incorporate
that
resolves
a
really
serious
vulnerability
right
and
that's
an
easy
thing
for
me
to
do.
I
mean
what
I
like
about
this.
C
Is
that,
honestly,
as
a
developer,
I've
got
a
lot
of
different
choices
here
as
to
what
to
do
with
this.
You
know-
maybe
I
don't
need
these
libraries
and
I
can
go
and
remove
them
from
the
base
operating
system
that
I'm
using
in
my
container
inches
right.
If
it's
not
there,
I
don't
have
to
maintain
it
and
securities,
then,
is
going
to
stop
bugging
me
about
this.
C
If,
if
I
can
switch
to
a
different
base,
image,
maybe
go
to
a
more
minimal
base
image
that
doesn't
have
all
these
utilities,
then
you
know,
maybe
I'm
better
off
anyway.
So
the
idea
is:
we've
empowered
developers
with
this
control
over
the
infrastructure,
right
of
driving
the
application
requirements
being
able
to
make
changes
right
that
agility.
That
gives
me
a
quick
resolution
to
problems
that
that
same
agility.
Flexibility
here
is
what
we
want
to
do
for
security
right.
It's
really
about
saying:
hey
openshift
is
a
great
platform
for
running
applications
on
and
handling
infrastructure.
C
It's
also
a
great
platform
for
security.
So
when
we
talk
about
things
like
vulnerability,
management,
right,
minimizing
privileges
and
other
configuration
issues
restricting
network
access,
everything
here
is
done
in
that
open
shift
shade
right.
So
you
know
vulnerability.
Scanning
is
one
of
those
towering
topics
in
security.
It's
a
never-ending
problem,
right,
new
vulnerabilities
being
discovered
all
the
time.
What
we're
trying
to
do
here
is
provide
the
security
team
with
some
idea
of
where
the
priorities
are
now
this
one
here,
this
demo
environment
is,
is
a
really
bad.
C
It's
full
of
these
old
fixable
vulnerabilities,
but
you
know:
where
do
I
start
to
tackle
this
right?
This
is
often
an
overwhelming
problem
for
organizations
to
understand
like
where
do
I
start
with
this
right,
especially
if
you're
bringing
statcrux
into
an
environment?
That's
you
know
well
on
its
way
right
like.
C
To
go
to
production
with
this
app
we're
ready
to
launch,
and
you
bring
this
in,
and
you
look
at
this
list
of
these
vulnerabilities.
It
seems
like
an
impossible
task
and-
and
we
sort
of
agree
here
right
vulnerability
management
is
one
of
those
things
that's
necessary
to
tackle,
but
it's
like
only
part
of
the
the
picture.
C
So
what
stack
garage
really
pioneered?
Was
this
idea
of
risk
right
that,
because
of
the
declarative
nature
of
a
kubernetes
application,
we
know
things
like
what
kind
of
privilege
levels
does
this
have
right?
What
kind
of
network
exposure
does
it
have
and
all
of
those
decisions
that
are
being
made
by
the
developer
right
to
expose
a
port
or,
to
you
know,
run
a
privileged
container
or
elevate?
C
You
know
some
some
kernel
capabilities
here
or
my
favorite
down
here
on
the
bottom
run
everything
as
a
cluster
admin
on
the
role
attached
to
the
surface
account
like
all
of
this
stuff
has
an
impact
on
security,
and
so
by
changing
those
settings
or
by
taking
a
recommendation
to
say
you
know,
you
really
should
be
careful
about
running
cluster
admin.
That's
not
something
that
we
would
expect
to
see.
C
The
system
should
not
allow
you
to
deploy
this.
If
you're
trying
to
run
you
know
cluster
admin
or
exposing
a
privileged
port
like
22,
you
know
we're
pushing
back
on
the
development
teams
to
say:
hey,
there's
a
better
way
for
you
to
approach
this
right.
Don't
use
x,
use
why
you
know
if
you're
running
as
a
as
a
root
user,
a
privileged
user
account.
There
are
ways
within
the
infrastructure
that
you
can
go
out
and
you
know
set
a
less
privileged
user
account.
C
So
some
of
the
recent
things
that
we've
done,
if
you
haven't
seen
the
product
recently
we're
now
looking
deeper
into
some
of
the
kubernetes
api.
So
we
can
see
when
one
of
the
users
in
the
environment,
for
example,
is
executing
into
a
pod
right.
This
means
that
they're,
like
administratively
accessing
a
pod,
and
you
know
really
useful
right.
It's
it's
something
that
we
want
teams
to
be
able
to
troubleshoot
their
applications,
of
course.
But
then
security
needs
to
know
that
someone
on
the
devops
team
has
administrative
access
to.
C
You
know
in
this
case,
potentially
a
sensitive
application
that
has
payment
card
data
right
and
right
there
that's
going
to
violate
a
compliance
standard
like
pci
right.
We
have
to
have
you
know,
even
our
developers
right
not
be
able
to
access
that
kind
of
sensitive
private
information,
because
you
know
an
insider
threat
or
you
know
worse.
C
I
add
services,
I'm
gonna
be
deprecating
certain
services,
but
the
pods
are
still
running.
So
this
gives
you
that
bird's
eye
view
of
what's
happening,
and
you
know
what
tools
are
communicating
with
what.
But
you
know
this
is
a
diagram
that
shows
me.
You
know
all
of
my
all
my
clusters
in
one
place,
but,
more
importantly,
we're
trying
to
to
you
know
give
the
hint
to
the
security
team
about
where
the
security
risk
lies
right.
I've
got
this
front-end
environment
and
somebody's
running.
C
You
know
a
wordpress
site
here
if
somebody
compromises
that
the
the
problem
here
is
that
I
can
get
further
right.
The
attacker
can
move
laterally
within
the
environment
and
that's
not
a
new
problem
right.
That's
segmentation,
that's
firewalling!
It's
it's!
A
traditional
problem
in
security
and
one
of
the
big
topics
what's
challenging
here
is
just
the
nature
of
openshift
and
how
that
that
firewalling
is
done,
and
we've
seen
a
lot
of
solutions
out
there
in
the
marketplace
that
have
gone
and
well
they've
built
a
container
firewall
right.
C
They
have
gone
and
and
created
a
solution
that
works
on
on
containers
and
operates
at
the
node
level
or
at
the
container
level,
and
it
solves
the
problem
right.
The
problem,
the
problem
with
that
solution
to
that
problem
is:
are
you
going
to
be
able
to
live
with
it
right?
Do
you
want
to
have
to
to
care
and
feed?
You
know
this,
this
little
firewall
running
in
your
containers.
Are
you
willing
to
to
put
up
with
that
and
we're
betting
that
most
people
don't
right?
C
So
what
we've
approached
this
problem
from
is
that
for
all
of
my
clusters
here
you
know,
openshift
has
the
capability
of
building
these
kind
of
segmentation
rules.
The
network
policies
are
the
right
solution
right
now.
These
are
these,
are
you
know,
part
of
the
kubernetes
spec
they're
enforced
in
openshift
by
the
container
networking
you
know,
but
this
is
in
line
with
with
what
we're
about
right,
that
there's
a
declarative
approach
to
configuration
that
can
improve
security
right.
This
belongs
in
the
code,
along
with
everything
else.
C
It
helps
to
define
the
applications
having
your
your
firewall
rules
in
a
separate
product
sitting
off
somewhere
to
the
side
violates
that
idea
that
your
applications
are
driven
by
a
single
source
code
base
right.
So
this
is
in
line
with
with
that
model.
Now,
over
the
years,
we've
seen
that
network
policy
originally
wasn't
all
that
widely
implemented.
It
was
incomplete,
but
you
know
between
red
hat
and
the
other
major.
You
know
kubernetes
platform
vendors.
This
really
has
become
the
standard,
and
we
think
that
that's
the
right
way
to
do
it.
C
In
fact,
that
idea
of
you
know
hey,
go
fix.
A
security
problem
in
the
code
is
woven.
You
know
entirely
throughout
this
right
that
when
you
have
a
problem
with
security
right,
you've
got
a
process
where
your
images
aren't
getting
up
to
date.
You're,
including
you
know,
utilities
that
are
useful
for
attackers
like
package
managers.
C
You
know
our
solution
is:
go
back
to
the
code
and
fix
the
configuration
that
you
provided
that
caused
this
problem
in
the
first
place.
Right
or
you
know,
maybe
the
problem
is
you
didn't
supply
a
configuration
and
unfortunately
the
defaults
in
in
you
know,
docker
images
and
in
kubernetes
are
often
designed
for
for
productivity.
You
know
usefulness
right
like
get
things
running
right
away,
rather
than
thinking
about
the
the
security.
Now.
The
good
news
here
is
with
openshift
this
one's
actually
going
to
be
a
default.
C
The
other
way
right,
the
security
default
in
openshift-
is
actually
that
you
can't
run
these
things
versus
vanilla
kubernetes,
where
you
can
so
you
know,
openshift
gives
you
kind
of
a
more
secure
configuration
by
default.
It's
a
little
bit
more
more
suitable
for
that
security-minded
approach,
but
still
there's
plenty
of
power
that
you
can
hand
over
to
your
developers
that
results
in
in
them.
You
know,
potentially,
being
you
know,
building
insecure
configurations.
There.
A
B
C
So
the
the
product
focus
is
on
openshift,
but
the
technology
compatibility
hasn't
really
changed,
and
so
the
goal
is
to
to
provide
for
customers
that
are
using
openshift
for
the
dashboard
that
actually
allows
for
them
to
to
run
this
kind
of
oversight
on
on
other
kubernetes
platforms
as
well.
So
you
know
the
configuration
here,
the
you
know
the
rules
that
we're
using
are
very
focused
on
on
kubernetes.
C
Now
the
statcrux
product
has
never
had
as
as
support
as
a
subject
matter.
You
know
the
anything
other
than
containers
running
in
kubernetes,
so
you
won't
see
you
know
cloud
security
topics,
you're
not
going
to
see.
You
know
perimeter
security
topics
in
here,
but
for
containers
and
kubernetes
yeah.
Absolutely.
B
C
Yeah
a
list,
so
everything
in
this
product
is
really
driven
by
policy
right.
A
policy
means
you
know
a
set
of
criteria
that
we're
matching
a
set
of
scopes
that
define
what
we
want
to
look
for
that
criteria
and
it
comes
with
a
whole
bunch
of
built-in
policies
right.
A
policy
really
defines
some
some
conditions
that
we're
going
to
be
searching
for
in
the
environment
and
it's
woven
throughout
the
product
here.
So
the
policies
are
what
create
risk
you
could
think
of
it.
C
As
you
know,
every
policy,
for
example,
like
this
one,
has
a
low
priority.
These
others
have
medium
priorities
and
you
can
think
of
that
as
a
score
and
whoever
scores
the
most
wins
or
loses
in
risk
right.
So
it's
really
kind
of
a
summary
of
all
the
things
that
you're
seeing
here
and
the
customizability
comes
out
of
that
right.
You
know,
maybe
I
don't
care
about.
You
know,
let's
say
privileged
containers
running
now.
I
probably
do
care
about
that.
But
let's
say
I
don't
care
about.
You
know
package
managers
and
others
like.
C
I
can
remove
those
risk
factors
here.
You
won't
see
that
show
up
and
you
have
control
over
that
scoring.
Some
of
it
is
a
little
bit
more
built
in.
In
other
words,
we
take
things
like
reachability
as
a
risk
factor
just
because
you've
exposed
a
service
right,
and
I
can
actually
you
know,
search
for
that,
and
I
can
look
for
that
exposure
level.
So
that's
not
really
configurable
today,
but
it
is
something
where
you
know.
If
you,
it
comes
directly
out
of
a
configuration
that
you've
supplied.
C
What
I
like
about
that
is,
you
know,
security
products
tend
to
have
this
model
of
you
know,
detect
some
condition
based
on
some
set
of
rules
and
then
send
out
an
alert,
and-
and
we
can
do
that
too
right-
I
can
send
out
alerts
every
single
time.
I
find
you
know
a
vulnerability,
but
you
typically
run
into
that
problem,
where
everything
is
security
tools
really
noisy
and
everybody
just
begins
to
ignore
it.
C
C
Listening
to
this,
like
there's,
no
one
setting
that
will
get
you
a
secure
application,
but
if
there
was,
if
there
was
one
shortcut,
it's
to
make
sure
that
your
containers
can't
write
to
the
file
system,
this
eliminates
a
whole
class
of
malware
right,
the
ones
that
are
going
to
try
to
drop
a
payload
onto
disk
and
execute
it.
It's
it's
one
of
the
things
that
really
shows
you
that
containers
are
different
than
vms
right
containers.
C
Don't
have
interesting
lives,
they
don't
do
lots
of
things,
but
the
problem
is
that
this
is
something
that
can
be
hard
to
get
to
right
if
you're
a
developer,
if
you're
migrating
an
application
from
traditional
infrastructure
to
to
containers,
maybe
you're,
relying
on
on
that,
although
you
shouldn't
you
shouldn't,
rely
on
your
file
system
sticking
around,
but
it's
useful
to
track
it
right.
It's
useful
for
me
to
have
this
tracked
in
here
as
a
risk
factor,
even
though,
potentially
today,
I
can't
do
anything
about
it.
C
Right,
realistic
security
is,
is
has
to
understand
that
the
goal
is
to
get
better
at
security.
That
being
perfect
right
off
the
bat
is
not
not
possible,
so
I
might
want
to
know
about
this.
It's
a
risk
factor
when
I
think
about
things
like.
Oh,
you
know
I'm
having
some
runtime
activity.
That
tells
me
somebody's
running
a
shell
in
this
in
this
deployment
like
knowing
that
the
shell
isn't
running
in
there.
C
Knowing
that
a
package
manager
is
running
along
with
the
writable
file
system,
it's
a
pretty
ugly
combination
of
risks,
even
though
I
may
not
at
this
point,
be
ready
to
go
out
and
send
out
alerts
that
hey
people
are
using.
You
know
that
file
system
so
useful
to
track
for
risk.
Even
if
I
really
can't
do
anything
about
this
today,
so.
A
Yep
yeah
one
so
just
in
general,
one
of
the
things
I've
always
liked
about
stack
rocks
is
it's
like
adherence
to
kubernetes
native,
like
standards
right
like
it
uses
kubernetes
components
to
implement
its
security
rules,
that's
right
policies
and
everything
else.
Right
like
from
the
beginning
from
day,
one
y'all
have
said
kubernetes
native,
and
that
has
made
me
very
happy
and
I'm
glad
we've
acquired
stack,
rocks
now
right,
like
it
literally
feels
like
a
hand-in-glove
kind
of
situation.
C
Yeah,
absolutely
and
and
there's
a
lot
of
good
reason
for
that,
and,
to
be
honest,
it
doesn't
make
everybody
happy
people
that
are
used
to
to
particular
security
responses
like
they're
used
to
managing
a
firewall
independently
from
the
application
architecture
right.
There's
this
dividing
line
between
the
assets
that
security
controls
and
the
assets
that
the
developers
control
we're
trying
to
merge
that
together
right,
it's
all
one
one
source
code
base.
You
know
if
I
had
my
way
somebody
someone
from
that
security
team
is
going
to
be
a
code
reviewer
in
in
the
you
know.
C
That's
a
kubernetes
network
policy
that
that
I've
got
to
review
that
I'm
going
to
change,
that's
where
the
security
changes
happen
and
the
other
part
about
about
you
know
using
things
like
the
admission
controller,
that's
built
into
openshift
right
as
a
security
gate
when
we
enforce
that
way,
there's
no
confusion
about
what
happened
right
developers,
don't
like
security
tools,
because
they're
often
insensitive
in
the
way
they
do.
This
enforcement,
it's
a
black
hole
and
my
my
apps
disappear
into,
and
I
can't
figure
out
and
can't
solve
the
problem.
C
So
so
the
emission
controller
makes
you
know
it's
it's
like
hitting
a
brick
wall.
You
know
what
happened.
You
know
immediately.
You
have
the
information
at
hand
that
you
can
use
to
resolve
it
right.
Security
is
not
trying
to
to
create
a
situation.
Necessarily
that
is
hard
to
troubleshoot.
They
want
a
clear
communication
of
hey.
This
is
not
acceptable
from
that
risk
perspective,
and
I
think
that
using
the
platform
makes
a
lot
of
sense.
Your
teams
are
going
to
be
immediately
familiar
with
it
right.
It's
not
a
new
security
action
that
takes
place
right.
D
So
just
wanted
to
announce
that
with
red
hat's,
obviously,
commitment
to
open
source
and
a
lot
of
the
other
projects
that
red
hat
has
open
source
stack
rocks
is
going
to
be
one
of
them.
So,
as
you
saw
chris
demoed
the
stackrock's
product,
but
it's
now
named
acs.
So
that's
going
to
be
downstream
of
the
upstream
project
that
is
rocks
stack,
rocks,
go
on
open
source,
it
will
be
upstreamed
and
yeah
we're
looking
forward
to
everybody
contributing
I.
D
A
D
Yeah
for
everybody
out
there,
if
you
want
to
check
out
the
website,
statcrux.io
is
going
to
be
the
home
of
the
open
source
project
and
we
wanted
to
announce
it
to
to
bring
everyone
into
the
community
through
a
bunch
of
resources
that
we
have
at
our
disposal.
Welcome
people
if
they
want
to
write
blogs,
contribute.
D
D
D
D
Yeah,
so
we
do
office
hours,
we've
done
office
hours
every
every
month.
We
recently
did
one
that
was
on
ebpf,
so
you
can
check
out
our
office
hours
they're
we're
trying
to
do
once
a
month
and
again
hey
we're
we're
trying
to
open
them
up
too
so
there's
office
hours,
and
we
were
looking
to
do
something
on
twitch
if
you
wanted
to
do
something
more
security,
specific
with
stackrock.
D
So
again,
if
you
want
to
get
more
involved,
send
us
an
email,
join
us
on
slack
and
you
can
ping
me
I'm
on
the
cncf
slack
as
well.
So
for
now
it's
it's
a
placeholder
and
we
look
to
bring
you.
You
know
more
and
more
information
as
things
move
forward,
because
the
open
sourcing
process
is
is
a
lot
there's
a
lot
of
considerations
involved
in
setting
up
an
upstream
project
so
we'll
be
with
you
the
whole
way
through
it
and
honestly,
I'm
really
excited
for
it.
A
D
Yeah
yeah
it
was,
we
hit
the
ground
from
day
one.
So
it's
it's
really
honestly
great
to
see
everybody
become
so
interested
in
security.
I
mean
you're
looking
at
kubecon
eu
right
now
and
some
of
the
tracks
we
have
like
101
tracks
talking
about
security.
So
it's
it's.
It's
an
awesome
time.
I'm
glad
that
people
are
are
taking
security
and
kubernetes
more
seriously.
A
B
B
D
For
now,
it's
cube
linter,
there's
some
existing
functionality
that
we
wanted
to
add
on
to
it.
You
can
check
that
out
in
the
github
repo
as
well
there's
the
the
project
roadmap.
I
know
that
it's
it's
a
more.
It's
a
developer
focus
tool.
I
recommend
anybody
specifically
who
wants
to
get
started
with
policies
in
their
ci
to
specifically
check
it
out.
It's
just
a
low
knowledge
gap
really
easy
to
implement
on
the
cli,
so
cube
linters
one
stack
rocks
is
gonna,
be
two.
D
A
B
You
asked
a
question
in
here:
we
produced
some
kubelinter
shirts,
which
I
think
is
the
first
ones
that
have
been
around
and
we
will
be
giving
those
away
and
just
watch
the
chat
for
how
to
claim
yours.
So
we
have
a
question
here.
Magno
picked
up
on
the
comment.
Actually,
the
discussion
of
a
cncf
discussion
of
falco
that
we're
going
to
be
contributing
upstream
patches
to
falco,
based
on
stack,
rocks's
work.
D
Yeah
stack
rocks
has
always
supported
the
falco
project
and,
as
you
saw
robbie
specifically
one
of
our
engineers,
falco
wants
to
move
to
graduating
and
you
know:
we've
just
really
supported
the
project
and
we
wanted
to
make
it
known.
Robbie
actually
just
commented
last
night
about
our
support
and
how
we
supported
graduating.
So
yeah
we're
looking
forward
to
to
just
you
know,
continuing
to
to
help
that
project
in
any
way
that
we
can,
because,
especially
with
falco
and
runtime
security
and
falco
sidekick
they're
doing
some
great
work
over
there.
D
A
B
Awesome
the,
but
I
understand
that
there's
a
number
of
things
where
there's
been
work
done
on,
unlike
existing
projects
by
the
stack
rocks
team
that
you
know,
you
all
have
due
to
acquisition
a
lot
of
other
things
that
had
not
been
able
to
get
around
to
contributing
to
those
projects
that
are
now
going
to
be
going
ahead.
Yeah.
D
Yeah,
it's
that's.
I
should
have
brought
robbie
on
because
that's
more
of
a
question
for
the
engineering
team
yeah
when
you're
yeah
when
you're
trying
to
contribute
these
projects,
there's
there's
a
significant
amount
of
back
and
forth
to
make
sure
that
you
do
it
the
proper
way
right,
which
is
why
you
have
these
sig
governance
and
why
is
part
of
the
graduation
to
cncf?
There
has
to
be
some
sort
of
process
for
for
contributing
so
yeah
it's.
D
You
know
we're
currently
in
the
process
of
working
with
file
code
to
make
sure
that
these
things
are
done
and
done
in
the
proper
way,
and
there
they've
been
nothing
but
helpful
in
in
bringing
us
on
and
and
talking
to
us
through
the
process.
So
yeah,
it's,
let's
just
say
with
the
with
falco
and
the
upstream
stuff.
There's
there's
more
to
come
on
that
side.
B
D
Oh
yeah,
of
course,
listen.
I
I
actually
really
like
the
the
thought
of
opening
the
floor
for
doing
office
hours.
People
coming
in
talking
about
projects,
even
even
if
blogs
something
as
simple
as
you
know,
hey
I'm.
This
is
how
I'm
protecting
my
cute
config
files
and
I
just
use
a
password
and
I'm
encrypting,
my
q
config
files
or
mounting
it
at
a
specific
time
and
then
the
timer's
up
and
it
unmounts
or
you
know
whatever
it
is
some
simple
project
you
want
to
talk
about
it
and
you
know
it's
security.
D
Focus
we
love
to.
Have
you
write
a
blog?
I
think
it's
awesome
to
have.
People
have
works
that
are
published
on
a
public
forum
with
community
following
community
guidelines.
Obviously,
and
then
you
know,
we
can
use
that
as
student
projects
for
leverage,
for
you
know
future
employment
and
future.
You
know
work
in
the
open
source
project.
I
think
it's
awesome
the.
If
you
want
to
to
learn
more,
you
can
join
the
stackrocks
channel
on
slack
to
see
ncf
slack,
it's
an
open
channel.
You
can
also
email
community
stackrocks.io
and
you
can
get
learn
more.
D
A
B
D
Yeah,
we
I
mean,
there's
a
ton
of
stuff
that
they
talk
about.
The
meetings
are
really
well
done
and
managed
by
by
tabby
and
ian
and
yeah
they're
they're,
a
great
group
and
they're
beginning
to
get
more
prominence.
I
think
the
tag
security
is
a
good
step
forward
in
terms
of
getting
plugged
into
a
lot
of
these
projects,
because
six
security
tended
to
just
be.
You
know,
slash
sig,
to
or
slash
six
security
to
get
them
on
to
issues,
but
there
was
really
no
necessarily
process
for
following
up
so
yeah.
B
C
Well,
the
cyborgs
commercial
product
does
work
with
core
kubernetes
right
and
you
can
see
some
of
the
stuff
on
the
stack
rocks
github.
These
are
you
know
the
things
that
our
commercial
customers
are
using
with
other
tools,
as
you
can
imagine,
with
a
tool
like
this,
you
know
it
has
to
be
part
of
the
the
pipeline
and
the
you
know
the
tools
that
you're
using
in
both
your
your
devops
environment,
so
pipelines
chat,
op
systems,
you
know
ticketing
and
others.
It
also
has
to
work
with,
of
course,
the
security
tools.
So
there's
a
whole.
C
You
know
success
suite
of
security
tools
like
security
event,
monitoring
logging.
You
know
things
like
that
that
it
has
to
work
with
and
so
that
that
compatibility
remains.
In
fact,
you
know
part
of
what
drove
well
most
of
what
drove
us
as
a
commercial
product.
Right
was
the
tools
that
our
particular
customers
were
using
and
with
with
the
open
source
community.
Now
we've
we've
got,
I
think,
a
better
potential
to
to
go
in
directions
that,
maybe
you
know
our
commercial
customers
aren't
using
right
new
tools
and
new
ways
of
doing
things.
C
You
know
so
some
of
the
less
popular
ci,
cd
pipelines
or
emerging
patterns
around
git,
ops
and
things
that
you
know
because
they
weren't
in
wide
use
among
our
commercial
customer
base,
but
will
be
more
widely
used
in
the
open
source
community.
I
think
we've
got
a
chance
to
expand
that
that
compatibility.
C
You
know
the
the
red
hat
approach
here.
The
support
for
openshift
doesn't
mean
that
we're
suddenly
going
to
make
it.
You
know
open
shift
only
or
that
we're
going
to
be.
You
know
doing
that.
It
means
things
like
you
know.
Single
sign-on
is
going
to
be
consolidated
with
with
openshift
for
our
enterprise
customers
to
enjoy
just
some
convenience
and
assurance
there.
That
doesn't
mean
that
we're
going
to
suddenly
take
away.
You
know
some
of
these
other
other.
You
know
the
other
integrations,
because
the
the
kubernetes
community
has
remained
pretty.
C
You
know
unfragmented
right.
The
api
drives
that
whole
community
that
level
of
compatibility,
and
as
chris
mentioned
you
know,
the
stack
rocks
focus
on
leveraging
that
api
really
means
that
we
can
enjoy
that
that
compatibility
out
there.
It
also
means
that
there's
work
to
do
when
things
like
psps
get
deprecated
right,
so
our
product
has
to
keep
up
with
that
and
as
new
new
standards
are
emerging
and
are
being
proposed
in
cncf.
C
You
know
there's
an
opportunity
there
for
us
to
take
advantage
of
those
new
things,
we're
always
thinking
about.
How
does
this
new
kubernetes
feature?
How
does
a
technology
like
service
mesh,
for
example,
enable
us
to
do
better
security
right,
and
that's
one
of
the
things
we're
thinking
about
down
the
road?
How
do
we
get
better
security
out
of
what
is
ostensibly
an
infrastructure
and
productivity
convenience,
but
maybe
we
can
leverage
it
for
security,
so
we're
looking
forward
to
that
part
of
it.
C
That's
right:
it's
not
the
first
time
where
you
know
a
new
platform
that
everybody's
racing
for
people
think
about
security
kind
of
as
an
afterthought.
It's
happened
with
cloud,
it
happened
with
virtualization.
I
suppose
it
means
that
you
know
there'll
always
be
opportunities
for
security
folks
because
it
gets
it
gets.
Thought
of
you
know
second,
but
especially
with
the
community
focus
here,
we've
got
an
opportunity
to
get
ahead
of
that
problem
and
say
hey.
We
can
leverage
this
for
better
security.
You
know.
C
Yep,
it's
tough
line
to
walk,
I
mean
I
think
stack
rocks
for
the
last.
You
know
three
years
the
commercial
entity
has
proven
that
it
is
walkable
right
that
we
can
maybe
make
the
security
teams
happy
and
the
developers
happy.
At
the
same
time,
we
can
allow
security
people
to
come
in
and
say
instead
of
being
the
the
team
in
the
room
that
says
no,
we
can't
use
this
technology,
it's
too
much
of
a
risk.
D
I
don't
think
you
really
had
a
chance
to
get
to
it,
but
there's
a
whole
host
of
integrations
right
with
other
platforms.
So
yeah,
one
of
the
big
thing
is,
you
know,
people
don't
necessarily
consider
kubernetes
specific
security
until
after
and
they
already
have
all
these
big
contracts.
And
so
how
do
you
tie
this
in
so
that
people
aren't
moving
through
all
these
different
panes?
And
so,
if
it's,
if
you
didn't
want
to
work
with
the
stackrock's
ui,
you
could
set
up
your
alerts.
Chris
there's
there's
a
whole
ton.
C
That's
right
right
so
when
enterprises
are
selecting
a
product
right,
I
mean
that
and
that's
the
you
know.
The
market
director
is
big
organizations
right
as
a
commercial
product.
We
needed
to
make
sure
this
is
going
to
work
with
the
tools
that
they're
using
and
in
some
cases
that
means
bending
some
of
the
abstractions
a
little
bit
right
so
that
it
works
with
a
tool
like
a
splunk
right
or
a
sumo
logic,
surface
right,
security
and
event,
monitoring
about
an
incident
that
occurs.
C
We
think
about
runtime
security
as
something
that
is
a
great
way
to
inform
our
efforts
to
improve
the
source
code
for
for
hardening
against
runtime
attacks.
Right
runtime
is
a
place
where
we
can
learn
a
lesson
and
apply
that
lesson
going
forward
rather
than
just
something
that
needs
to
be.
You
know
just
continually
monitor,
but
you
know
organizations
have
these
processes
built
around
monitoring
investigation
root,
cause
you
know
and
that's
something
that
we
need
to
be
in
line
with
the
the
list
of
integrations.
C
Of
course,
leverages
standards
as
well,
and
that's
we've
been
able
to
do
some
really
awesome
things
with
that
by
getting
information
out
of
this
product
and
into
other
systems
pretty
easily
through
you
know,
web
hooks
even
syslog.
I
thought
that
protocol
would
have
died
a
long
time
ago,
but
here
here
we
are
it's
2021,
ssrc
yeah,
oh
man,
it's
bringing
me
back
so
syslog
still
one
of
those
standards
and
you
know
there's
more
right.
B
B
D
Yeah
yeah:
it's
open
open
forum
for
for
people
if
they
want
to
write
blogs.
Obviously
it's
a
community
guidelines
that
need
to
be
looked
over
so
recommend
emailing
or
getting
involved
in
the
slack
channel.
You
know
paying
me
if
you
were
looking
to
talk
talk
about
a
specific
topic
but
yeah
so
welcome
to
towards
the
community.
If
you
want
to
talk
about
anything
security
specific
so
and
then
obviously
that's
going
to
be
the
place
for
announcements
moving
forward
as
we
open
source
staccrack's
project.
D
B
D
B
Yeah,
that's
why
that's
why?
Most
of
the
time
when
stuff-
I'm
not
saying
most
of
the
time
when
stuff
originates
here
at
red
hat,
we
try
to
have
a
separate
community
name
from
the
product
name,
so
that
also
it
really
helps
our
people
right,
because
we
do
have
a
whole
support
large
support
staff
and
when
they
get
a
call,
they
want
to
know
what
the
customer
is
talking
about.
For.
D
D
Yeah,
if
you're
just
interested-
and
you
want
to
ask
more
questions-
there's
an
open
forum
on
the
cncf
slack
channel-
it's
just
stackrock's,
channel
and
yeah
feel
free
to
drop
questions
and
we'll
answer
what
we
can
as
moving
forward.
There's
a
ton
of
people
who
work
at
stack
rocks
in
that
channel
and
it's
the
best
way
to
get
in
touch
with
us.
If
you
want
to
learn
more
yeah,
no
heckling,
chris.
No,
no.
A
B
C
So
there's
definitely
oversight
of
you
know.
Where
do
my
components,
my
artifacts
come
from
right.
There
isn't
necessarily
a
restriction
until
a
security
team
decides
that
they
you
know
they
want
to
restrict
that
right.
So
we
we
err
on
the
side
of
flexibility,
like
you
want
to
pull
down
that
five-year-old
image
from
docker
hub
we're
just
going
to
be
very
transparent
about.
What's
in
there
that
you're,
you
know
you
think
about
it.
C
You're,
taking
that
on
as
part
of
your
supply
chain,
you're
taking
responsibility
for
that,
and
we're
going
to
show
you
the
you
know
the
truth
about
about
how
it
was
built-
and
you
know
where
it
is:
there's
there's
a
lot
of
that
abandoned
ware
out
there,
so
no
restrictions
by
default,
but
you
know
certainly
most
of
the
commercial
organizations
that
I
speak
with
are
restricting
that
an
attempt
to
control
that
supply
chain.
I
mean
solarwinds
has
everybody,
you
know
absolutely.
You
know
on
fire
about
this
topic
right.
Where
are
we
getting
this
stuff
from?
C
Are
we
building?
You
know
known
vulnerabilities
into
our
our
applications?
So
that's
where
too,
there
were
stack
rocks.
You
know
the
acs
product
here
fits
in
with
the
larger
picture
of
openshift
right
that
open
shift
platform
has
capabilities
and
registries
like
quay
and
image
signing
and
other
things
that
will
provide
security
teams
with
more
assurances
about
that.
C
I
gotta
say:
I
think,
like
the
problem
with
secure
supply
chain
is
actually
it's
actually
easier
in
this
case,
but
you
think
about
kubernetes
and
everything
that
gets
built
coming
from
source
code,
you've
kind
of
got
that
asset
inventory.
You
know
so
many
of
the
the
breaches
that
you
see
publicly
are
around.
Well,
we,
you
know
we
have
a
maintenance
process,
we
have
a
patching
process,
but
we
missed
that
one
we
forgot
about
it.
It
was
like
somebody
left
that
door
open
and
we
didn't
even
know
there
was
a
door
back
there.
C
So
I
think
that
consolidating
application
strategies
on
a
platform
like
kubernetes
and
openshift
actually
has
that
benefit
that
nothing
goes
invisible
right.
If
we
see
we
see,
if
we
see
every
pod,
we
see
every
image,
that's
in
use
and
it's
a
little
bit
more.
You
know
control
over
the
over
the
source
and
the
supply
of
those
things.
So
without
trying
to
break
everybody's
environment,
the
product
definitely
has
features
there
to
control
that,
but
we're
not
there
to
to
you
know
to
dictate
the
terms
of
it
to
these
organizations.
D
D
E
C
B
B
Postgres
is
an
enterprise
database
and
and
first
rule
of
postgres
security.
Is
you
never
leave
the
postgres
port
open
to
the
internet
because
a
database
port
has
to
emphasize
performance
and
functionality
over
security
and
and
therefore
default
security
rules?
Simply
don't
you
know
restrict
who
can
access
that
port?
C
You
know:
cyber
security,
you
see
three
four
year
old,
exploits
the
same
struts
exploit
that
you
know
that
got
equifax
right,
that
that
exploit
still
exists
in
the
wild
shell
shock
right
yeah.
So
you
know
these
things.
These
things
don't
get
solved
overnight.
Just
because
somebody
has
a
fix,
published.
A
B
D
Chris,
do
you
know
about
that
project?
I
don't
I
don't.
I
yeah
I
was
gonna
say
I
think
it
it
correct
me
if
I'm
wrong
quite
short,
but
it
has
to
do
with
basically
cryptographically
hashing
images,
all
the
way
through
the
supply
chain
and
then
looking
at
runtime
to
verify
that
it's
the
correct
hash
and
that
nothing's
changed
over
the
process.
I
think
it's
really
cool
project.
I
know
red
hat's
actually
contributing
to
that
with
google.
D
I
think
in
in
a
couple
cases,
so
don't
know
what
the
plan
is,
because
I'm
not
that
tied
in
with
with
the
product
and
what
they're
looking
at
in
the
future,
but
I
think
it's
reasonable.
I
think
it's
a
reasonable
to
assume,
probably
in
like
a
three
year
roadmap,
just
because
I
think
it's
a
great
project
that
it
will
get
tied
in
some
aspect
into
openshift.
So
all
right,
I
hope
it
does.
I
I'm
this.
I'm
just
looking
in
my
crystal
ball
right
now,
so
don't
take
anything.
I
say
for
right.
A
E
B
D
D
Speaking
of
just
you
know,
different
implementations
of
hey,
you
have
this
project,
or
this
microservice
and
here's
the
security,
the
impact
just
the
nutrition
label
that
comes
with
a
project.
That's
on
github,
for
everybody
to
see
sort
of
all
the
requests
that
it
needs
and
projects
can
also
interact
with
that,
and
I
thought
it
was
it's
pretty
smart.
Everybody
recognizes
nutrition
labels,
you
don't
have
to
be
security,
focused
to
look
and
say:
oh,
this
could
be
bad
if
I
download
it
and
run
it
right.
So
there's
a
there's.
B
D
Chris
I'll,
let
you
have
the
last
word,
but
in
terms
of
new
things,
just
super
excited
that
we
got
to
get
it
out
and
super
excited
that
red
hat
is,
is
upstreaming
this
and
opening
it
to
the
community
to
to
get
involved
so
excited
for
that
again,
slack
channel,
email,
ping,
us
we're
glad
to
have
you
on
board.
So
chris.
A
D
C
There
you
go
here,
I
am
you
know
I
I
I
love
the
discussion
here
and
I'm
looking
forward
to
more
of
it.
I
think
you
know
what
I
really
love
about.
The
the
community
is
is
all
the
ideas
that
come
in
I
I
love
about
stack
rocks
and
as
a
as
a
you
know,
background
in
security,
the
the
part
I
actually
like
most
about
this-
and
I
hope
the
continue
embraces
this
as
well-
is
that
security
needs
to
work
with
the
platform
we're
trying
hard
to
preserve
the
value
that
you
get
with
this.
C
So
all
the
things
that
we've
talked
about
right
restrictions
and
emission
controllers
and
signing-
and
everything
else
needs
to
remember
that
we're
adopting
these
containerized.
You
know
git,
ops
and
devops.
You
know
driven
process
for
a
reason
right
that
the
applications
are
there
to.
You
know
to
benefit
us,
and-
and
you
know
we
want
to
act
in
an
agile
way.
I
never
want
to
see
security.
Take
away
that
hey,
there's
this
exciting
new
component.
Someone's
pre-built
got
this
thing
that
we
can
add
in
here
to
improve
performance
and
deliver
better
features.
C
B
It
cool
awesome,
so
we'll
have
more
office
hours
this
week,
because
it's
kubecon
week
I've
posted
a
link
in
the
chat
for
where
you
can
find
her
to
schedule
those
and,
if
you're
here,
because
you
really
care
about
security,
you
care
about
stack,
rocks
the
obvious
place
to
go
to
continue.
The
discussion
is
the
new
community
which
you
can
reach
off,
of
stack,
rocks
dot.
Io
you're
also
welcome
to
drop
by
the
red
hat
slack
chat
for
kubecon,
I
on
the
cncf
slack,
but
do
visit
the
new
stackrocks
community.
A
Thank
you
all
for
joining.
Thank
you
to
the
audience
for
participating,
really
appreciate
it.
Next
up
at
8,
1600
central
european
summer
time
we're
going
to
be
talking
about
come
on
calendar
cluster
management
so
feel
free
to
join
us,
then
we'll
be
around
on
the
slacks
and
various
channels
here
and
there,
and
until
next
time
stay
safe
out.
There.