►
From YouTube: StackRox Community Meeting #15 - 2023-06-13
Description
The StackRox community meetings are held on the second Tuesday of every month. We use this time to get together and discuss gaps in the product and how best to move forward. Contributors are rewarded with StackRox gear as the RoxStar of the month.
- If you want to learn more about the project, head to StackRox.io
- The project's code repository can be found at https://github.com/stackrox/stackrox
A
Hello
and
welcome
to
the
14th
community
meeting
for
stack,
rocks
the
open
source
project,
I'm
Mike,
Foster
I'm
joined
by
my
co-chair
at
Matthias
medinger
and
we're
well
Fresh
Off
The
4.0
release
obviously
really
excited
for
the
product.
The
cloud
service
launch
coming
from
Red,
Hat
Summit
and
getting
people
hands
on
with
stack,
rocks
and
ACS.
It
was
a
ton
of
fun,
but
we
have
more
news.
We
have
4.1
release
coming
up.
A
I
know
that
the
last
meeting
I
promised
that
a
stack
rocks
roadmap
update
is
coming
we're
going
to
be
recording
that
next
week,
so
stay
tuned.
I
will
post
it
in
the
chat
for
you.
That
being
said,
you
know
any
any
4.0
issues,
we'd
love
to
hear
from
you
in
slack
just
so
that
we
can
adjust.
You
know
open
up
issues
open
up
rfes.
What
do
you
want
to
see
and
that
leads
us
into
the
4.1
release?
So
4.0
obviously
was
huge.
We're
happy
to
hear
success
stories
from
migrations,
especially
operator
in
Helm
charts.
A
Things
are
going
very
smoothly.
I
have
a
lot
of
praise
to
the
engineering
team
that
I've
heard
from
external
users
and
just
wanted
to
you
know
talk
about.
What's
coming,
4.1
highlight
some
of
the
changes
in
in
the
notes.
You'll
see
that
there's
a
change
log
that
I've
put
up
there.
The
projected
date
is
the
end
of
July,
obviously
we'll
know
more,
but
the
code
freezes
happened
right,
Matthias,
I,
hope,
I
didn't
jump
right
into
that.
A
But
maybe
you
can
walk
us
through
a
4.1
timing
and
what
people
are
going
to
see
so.
B
So
if
you
folks
are
actually
interested
in
bleeding
edge
news,
what's
happening
or
what's
deprecated
feel
free
to
stop
by
and
take
a
look
in
the
repository,
it's
all
open
source
and
there
to
see
you
might
be
missing
the
information
from
our
bug
tracker,
because
that
is
not
public
as
far
as
I'm
aware
of,
but
we
try
to
actually
make
the
make
the
entries
self-sufficient
without
the
without
the
bug
tracker
access.
B
Besides
that
we
have
entered
the
code
freeze
for
4.1,
which
means
code,
freeze
was
I,
think
last
Wednesday,
so
projected
date,
end
of
July
and
as
far
as
I'm
aware
of
no
major
road
bumps
hit
just
yet,
but
obviously
we're
kind
of
early
in
the
in
the
release
cutting
process.
So
let's
say
fingers
crossed
everything
works
out
regarding
for
it,
oh
I
was
actually
pleasantly.
B
On
the
one
hand,
I
was
pleasantly
surprised
that
things
worked
out
as
they
did,
because
it
was
still
a
big
change
with
the
database
migration,
but
on
the
other
hand,
it's
not
a
huge
surprise,
because
I
would
argue
that
4.0
was
one
of
our
most
intensely
tested
releases
I've
ever
seen.
B
Let's
talk
a
little
bit
about
highlights,
so
4.0
was
the
very
big
one.
Obviously,
but
we
also
shipped
some
new
features
in
photo.
One.
Some
of
the
highlights
are
the
vulnerability
management.
Workflow
is
actually
updated,
so
we
are
deprecating
or
we
are.
We
are
replacing
some
of
the
some
of
the
parts
and
you
will
see
improvements
coming
or
rolling
out
in
the
next
upgrades.
So
this
is
a
multi-step
process.
B
So
we'll
look
forward
to
actual
improvements
to
that
in
general,
Rox
cattle,
you
might
know
as
the
CLI
tool
to
interact
with
our
platform
and
what
we
did
is
actually
you
used
to
require
an
admin
or
API
token
to
actually
interact
with
it.
Now
we
actually
switch
that
over
to
user
tokens,
so
it's
a
little
bit
more
easily
accessible
now
and
also
user
tokens
are
a
little
better
in
terms
of
scope.
Let's
put
it
that
way.
B
Also,
we
introduced
quite
some
time
ago
the
feature
of
having
a
signature
checking
for
images
that
we
scan
and
we
have
introduced
an
environmental
variable
to
actually
turn
off
signature
fetching
if
you're,
not
using
that
feature
to
actually
minimize
the
amount
of
API
calls
that
we
that
our
product
does
against
against
artifactory
and
the
likes
to
actually
fetch
these.
B
And
finally,
as
maybe
the
more
important
or
or
most
important
thing
to
to
remember,
is
as
we
we
deprecated
some
time
ago,
multiple
access,
Scopes
and
security
contexts
or
sccs
and
Please
be
aware
that
these
will
be
removed
in
the
future.
So
make
sure
that
if
you,
if
your
deployments
or
anything
in
your
environment
use
permission
sets
Define
or
out
of
the
box
permission
sets
or
the
Custom
Security
contact
constraints
of
collector
and
Mission,
Control
or
sensor,
if
you
use
any
of
these,
they
will
be
removed.
B
So
this
might
break
your
environments
if
you
don't
migrate
away
from
these.
So
please
keep
that
in
mind
and
with
that,
actually
that
rounds
up
the
biggest
highlights.
But
if
I
remember
correctly,
we
also
will
have
a
little
bit
of
an
easily
accessible
summary
of
the
biggest
changes
and
what's
new
right.
A
Yeah
exactly
so
I'm
working
on
a
Blog
just
to
capture
this
all,
along
with
a
what's
new
video
for
those
who,
like
audio
video
content
instead
of
reading
a
lengthy
blog
I,
do
want
to
highlight
two
of
the
major
changes
you
know
the
network
graph,
the
2.0
one
is
now
the
in
the
in
the
release.
Net
number
graph
1.0
is
deprecated,
and
now
it's
going
to
be
Network
graph
2.0,
so
that
same
process
is
now
happening
with
the
vulnerability
management.
Workflow
I
could
see
it.
A
It
can
be
a
lot
very
overwhelming,
but
we've
managed
to
make
it
very
sleek
and
useful
for
people
so
definitely
worthwhile.
Checking
out
you'll
see
once
you
get
in
the
dashboard
that
there
is
vulnerability,
management,
1.0
and
2.0
so
go
through
it.
Let
us
know
your
thoughts,
help
us.
You
know
make
2.0
even
better
than
the
first
one.
So,
looking
forward
to
that
and
then
I
think
we
just
had
two
questions
that
were
in
the
slack
Channel.
We
wanted
to
address
correct
me
wrong.
Matthias.
B
As
far
as
I'm
aware
of
yes,
so
we
have,
the
one
is
Dane-
was
asking
I'm
trying
to
sort
through
how
to
get
certain
policies
that
are
runtime
policies
to
Auto
Clause
out,
so
the
problem
with
that
is
I,
assuming
that
Dane
is
talking
about
violations
that
are
triggered
by
policies.
B
Policy
violations
don't
vanish
by
themselves
unless
you
disable
the
policy
that
triggered
them.
So
that
is
actually
a
thing
that
we
don't
want
as
far
as
I'm,
aware
of
because
imagine
someone
spinning
up
a
road
container
or
a
rogue
deployment
and
running
some
code
in
it.
However,
that
worked,
but
if
they
would,
if
we
assume
they
did,
that
it
would
raise
a
violation.
Obviously,
for
example,
I
don't
know
someone
invoked
a
package
manager
and
that
raised
and
raised
a
violation.
B
If
you
now
delete
this
container
and
the
violation
would
go
away,
there
would
be
no
audit
Trail
for
us
to
actually
show
you
that
something
happened
in
your
cluster,
so
we
don't
actually
Auto
close
policies
or
violations.
The
only
moment
that
actually
violations
vanish
is
or
get
closed
is,
if
you
disable
or
delete
the
policy,
if
that,
if
you
do
that
these
vanish,
but
everything
else
you
don't
as
far
as
I'm
aware
of
correct
me,
if
I'm
wrong,
actually
I
I'm,
not
aware
of
any
violations
that
get
Auto
closed.
A
That's
good
I
think,
there's
yeah.
This
question
could
go
two
ways.
One
is
the
violations
aspect
and
one
is
a
timer
on
a
policy
to
be
not
enforced.
Slash
not
notified
I.
Think
in
general,
that
is,
security,
not
best
practice
right
to
have
something:
that's
Auto:
it
needs
to
be
audited
who
set
the
timer
when
it
closes
out,
because
if
all
of
a
sudden
we're
not
enforcing
or
informing
on
a
policy
and
something
happens,
that
is
not
good.
A
You
know
again,
that
being
said,
you
it's
a
little
bit
of
Overkill,
so
I
I'd
like
to
hear
the
use
case
for
automatically
turning
off
a
policy
or
violation
based
on
time.
Right,
maybe
you
know
you
have
30
days
to
make
a
certain
change
to
put
it
in
place.
You
stop
it,
but
then
you
know
the
the
use
case
for
turning
it
off,
removing
it
I
a
hard
press
to
see
the
advantage
over
the
disadvantage
on
that
one.
B
I
mean
I,
the
only
thing
is
I
get
that
this
can
lead
to.
I
wouldn't
I
mean
maybe
a
lot
of
noise,
a
lot
of
violations
depending
on
the
configuration,
and
there
might
be
an
opportunity
for
us
to
actually
review
our
out
of
the
box
rule
set,
but
that
is
actually
also
something
as
it
is,
our
out
of
the
box
rule
set.
That
means
changes
applied
to
each
and
every
customer,
so
we
better
or
I
if
I
raise
that
with
the
rest
of
engineering.
B
I
better
have
a
very
good
example
explaining
or
showing
off
the
benefit
of
actually
changing
something.
So
Dane.
If
you
have
a
good
example
of,
why
wish
what
happens
there
or
could
give
us
a
little
bit
more
information
about.
A
A
Yes
and
then
the
last
one
Nicholas
Richard
I
know
we
talked
about
mounting
to
Docker
sock
in
the
last
two
releases.
There
hasn't
been
any
change
and
I.
Think
that's
for
a
couple
reasons.
One
is
backwards,
compatibility
I
believe.
Do
you
want
to
just
run
through
the
logic
on
that
one.
B
So
in
general
the
docker
suck
mounting
is
so
the
for
anyone
not
aware
some
time
ago
kubernet
has
deprecated
the
docker
shim,
so
docker.suck
is
something
that
kubernetes
used
to
have
and
that
we
used
to
use
to
actually
run
compliance
checks
against
Docker.
Nowadays,
most
of
the
kubernetes
deployments
out
there
don't
run
on
Docker
anymore,
but
the
docker
stock
is
and
also
the
docker
stock
is
completely
gone,
but
we
actually
still
need
to
be
somewhat
backwards
compatible,
so
we
still
actually
support
the
docker
sock,
which
also
means
our
deployments.
B
Try
to
mount
it
if
the
docker
stock
is
not
available,
we
completely
ignore
it.
So
there
is
no
functional
impediment
to
our
product.
If
it's
not
there,
there
is
no
warning
it.
The
the
the
the
Accord
the
accompanying
code
is
just
being
skipped.
B
So
from
that
perspective
there
is
no
problem
of
leaving
it
in
there
well,
but
that
also
means
we're
still
mounting
it,
which
means,
if
you
have
auditing
tools
that
actually
check
for
that
it
will
continue
to
raise
alerts,
and
the
big
question
now
is
from
a
technical
point
of
view.
There
is
multiple
ways
we
could
address
this.
Obviously
we
could.
B
We
could
update
our
deployment
templates
to
only
conditionally
deploy
with
this
mount,
but
the
question
is:
should
we
do
that
and
when
should
we
do,
that?
The
other
option
would
be
to
do
that
in
code
and
basically
because
we
are
an
as
ACS
or
stack
rocks
is
a
native,
secure,
kubernetes
security
platform.
We
have
full
access
and
full
knowledge
about
the
kubernetes
deployment
that
you're
running,
which
means
we
could
just
add
a
version
switch.
B
But
if
we
add
that
version
switch
in
our
code
in
our
platform
code,
we
would
always
still
try
to
mount
it
so
that
wouldn't
help
and
updating
our
Helm
templates
or
in
general,
our
deployment
options
to
how
to
conditionally
Mount.
This
would
most
likely
be
the
correct
way
of
doing
it,
but
as
we
are
not
breaking
any
functionality,
the
the
change
has
not
been
prioritized
very
high.
B
That's
sad
because,
honestly
against
our
product
management,
it
is
kind
of
a
hard
sell
to
say
well,
let's
invest
engineering
time
to
actually
fix
this,
because
there
is
a
lot
of
features
and
Bug
fixes
that
are
very
interesting
and
important
for
for
the
product
itself,
and
this
one
is
one
that
is
annoying
but
functionally
not
impacting
the
product.
The
big
question
now
is
that
is
me
speaking
as
a
single
developer
and
not
for
all
of
ACS,
so
Nicholas.
B
If
you
have
a
compelling
example
of
where
this
actually
impacts
or
or
raises
a
problem
in
using
our
platform,
please
do
let
me
know,
because
you're
actually
giving
me
the
tools
to
correctly
argument
against
the
rest
of
engineering
and
PM,
so
that
would
actually
be
awesome
because,
yes,
it
might
be
annoying
for
you
folks.
A
Yeah,
you
heard
it
here,
the
more
you
raise
issues
and
rfe's
the
more
things
get
taken
seriously
and
I.
Think
that's.
That's
probably
the
biggest
ask
for
a
4.1
release.
I
have
for
the
open
source
communities.
Try
out
that
vulnerability
management
workflow!
Let
us
know
what
you
like,
what
you
don't
like,
raise
issues
so
that
we
can
fix
them
in
a
4.2
release
during
a
patch
release,
but
that
feedback
is
obviously
extremely
important
and
that's
why
we
love
having
you
in
the
channel
so
again,
we'll
be
back.
A
I
want
to
wrap
it
up,
we'll
be
back
next
month.
The
second
Tuesday
of
the
month
in
July
I'll
update
the
calendar
in
the
slack
Channel.
As
always,
the
notes
are
in
the
channel
the
zoom
links
in
the
channel,
and
please
just
share
your
thoughts
with
us
and
open
as
many
issues
as
you
can
any
final
words
Matthias.
B
As
usual,
even
if
it's
not
an
issue
for
you,
but
you
just
feel
there
is
weird
ux
or
you
have
the
feeling
that
dogs
aren't
right,
feel
free
to
contact
us
reach
out
over
GitHub
issues
or
the
slack
Channel,
where
whatever
is
most
fitting
for
you
we're
always
there
we're
always
reading,
always
trying
to
answer
as
much
or
to
address
as
much
as
we
can
and
I.
Guess
with
that
folks,
it's
been
a
pleasure
and
see
you
next
month
take
care.