►
From YouTube: StackRox Community Meeting #16 - 2023-07-18
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
A
We're
going
to
be
talking
about
the
patch
update,
taking
questions
talking
about
the
road
map,
video
that
will
get
released
later
this
week
and
announcing
that
our
next
meeting
is
on
the
22nd
of
August
I'll,
reiterate
at
the
end,
but
summer
weeks
are
tough
to
plan
around
a
lot
of
Vacations,
so
that'll
be
on
August
22nd,
the
next
meeting
right
before
the
4.2
release.
So
we're
looking
to
have
more
info
for
you,
then
until
then
4.1
was
out
at
the
end
of
June.
A
B
So
actually
we
have
another
patch
in
the
time
in
the
in
the
pipeline
right
now
that
should
be
released
in
the
very
near
future
and
these
patches
together,
because
I'm
basically
wrapping
these
together.
Both
of
these
address
two
rather
important
issues
that
we
have
both
of
them
surrounding
the
operator.
So
if
you
are
using
ACS
or
stack
rocks
with
the
operator,
you
might
want
to
check
out
these
patches.
So
the
first
one
revolves
around
the
operator
upgrade
if
you
are
using
the
kernel
collection
method
for
collector.
B
If
you
use
that
on
a
on
an
older
cluster
or
on
on
an
older
version
of
ACS
and
then
upgraded
in
recent
ACS
versions,
We
or
and
stack
rocks
versions,
We
actually
removed
the
kernel
collection
method,
which
leads
to
the
unfortunate
situation
that
our
operator
might
try
to
upgrade
you
to
a
newest
version
and
the
pods
don't
spin
up,
because
they
are
missing
the
counter
collection
method.
If
that
happens,
we
do
have
a
solution
for
that.
The
workaround
is,
unfortunately,
a
little
bit
involved,
so
we
actually
have
an
a
KCs
article.
B
So
a
knowledge
based
article
for
that
I
have
linked
that
in
our
stack,
Rocks
Community
meeting
notes,
if
you
don't
have
access
to
them
or
don't
know
where
they
are
feel
free
to
hit
us
up
in
the
usual
slack
channel.
So
on
the
cncf
slack,
the
channel
stack
rocks
feel
free
to
to
ask
either
Foster
or
me.
We
can
always
provide
you.
The
link.
The
second
issue
revolved
around
the
operator
as
well.
B
So
what
happened?
There
is,
if
you
are
using
the
operator
to
deploy
the
product
the
platform
and
you
you
deployed
it
originally,
with
pod
security
policies,
enabled
and
then
upgraded.
Your
cluster
same
thing
on
cluster
upgrade
pod
security
policies
got
removed
from
kubernetes
some
some
versions
ago,
which
might
also
lead
you
leave
you
with
an
installation
that
doesn't
want
to
spin
up
pods
because
part
security
policies
are
still
part
of
the
manifests
for
that.
B
There
is
actually
a
workaround
that
you
can
run
on
openshift
clusters
same
thing
here:
I've
linked
that
in
the
community
meeting
notes,
if
you
don't
know
where
to
find
them,
feel
free
to
Ping
us
on
Slack.
It
involves
a
Helm
map,
Cube
apis,
which
is
a
Helm
plugin
that
you
can
use
to
remove
things
from
our
Helm
manifests
that
hinder
the
upgrade
in
this
case
part
security
policies,
because
they're
not
supported
anymore.
B
So
these
are
the
two
main
and
important
things.
These
are
more
actually
more
Downstream,
because
we
are
still
in
the
process
of
looking
into
running
Upstream
with
operator.
That's
also
a
thing
that
we
as
engineering
are
interested
in
doing,
but
it
it
has
proven
a
little
bit
complicated
because
of
all
the
dependencies
that
our
operator
has.
So
it's
a
work
in
progress
for
Upstream
users,
the
patch
update,
or
at
least
these
two
fixes
out
of
the
patch
update,
are
not
super
important
because
they
are
most
likely
not
running
the
operator.
B
But
besides
that,
please
keep
in
mind
or
try
always
try
to
run
on
the
latest
version.
That's
a
general
recommendation
that
we
can
always
give.
We
try
to
make
the
patch
releases
and
general
software
releases
as
stable
as
possible,
and
we
always
recommend
to
run
on
laser
version,
because
it
includes
all
the
fixes
that
you
should
have
and
with
that.
Let
me
give
it
back
to
Foster
with
some
of
the
questions
that
we
got
since
the
last
meeting.
Yeah.
A
That's
spot
on
and
tune
into
the
community
meetings
because
we
did
say
that
system
the
kernel
module
was
getting
removed
in
the
latest.
One
also
core
BPF
I
believe
is
in
Tech
preview
right
as
a
alternative
to
the
BPF
module.
So,
yes,
pretty
cool,
I,
gotta
upgrade
and
test
it
out
to
see
the
see
what's
different
questions
yeah.
So
there
was
two
questions
that
I
wanted
to
point
out
since
our
last
meeting:
I'm.
Sorry,
if
we
don't
necessarily
get
to
it
all
the
time
in
slack,
sometimes
the
questions
are
better.
A
If
they're
long
form
and
discussed
like
this,
the
first
one
is
Ken
stack,
rocks,
generate
an
s-bomb
file
or
any
way
to
track
package
information.
Now
we
can
track
package
information.
We
have
you
know
the
Stack
Rock
scanner,
ACS
scanner,
which
gives
you
all
the
vulnerability
data
as
well
as
looks
at
the
docker
file.
It
compiles
you
a
list
of
all
the
packages
that
you've
installed
in
the
container
now
I'm.
Assuming
that
this
person
that's
asking,
wants
a
comparison
or
wants.
A
You
know
an
s-bomb
itself,
I
believe
Red
Hats
go
to
is
an
spdx
s-bomb
generator,
there's
still
some.
Let's
say
hesitation
in
the
open
source
World
about
if
s
bombs
are
useful,
who
manages
them?
How
are
they
created?
How
are
they
interpreted
so
I
know
that
we're
building
Integrations
into
ACS
in
the
future,
and
there
is
a
roadmap
item
discussing
it
explicitly
that
you
should
be
able
to
see
on
Thursday,
so
stay
tuned
for
more
information
on
that
I
hope
I
did
that
one
Justice
Matthias
anything
you'd
like
to
add.
B
I
would
let
yeah
so
there
is
a
slight
there
is.
There
is
another
angle
I
want
to
give
at
that,
which
is.
We
do
have
scanning
information
for
Docker
images,
so
for
any
image
that
you're
running
on
your
cluster,
we
scan
them
or
you
can
scan
them
for
vulnerabilities.
So
yes,
and
we
kind
of
are
aware
of
which
things
are
installed
in
a
darker
image
or
available
in
a
Docker
image,
because
we
need
we
use
that
to
query
for
CVS
we
also
depending
on
the
Node
OS.
B
We
also
have
a
list
of
installed
packages
on
the
node
system.
This
is
very
a
very
small
in
scale.
For
now
there
is
plans
to
expand
that
at
some
time,
but
in
general
we
have
more
information
about
containers
than
we
have
about
the
nodes
that
you
are
running
kubernetes
on
again.
This
is
about
to
change
or
will
change
in
the
foreseeable
future,
but
in
general
we
don't
generate
an
s-bomb
as
far
as
I'm
aware
of.
A
Typically,
that's
how
I
would
like
to
set
up
the
workflow
right.
You
know
if
we're
doing
s-bomb
and
we're
trying
to
figure
this
out
of
production
about
what's
in
our
container
I,
think
we're
a
little
behind,
but
yeah
very
open-ended
question.
I
know
it
didn't
get
discussion
as
much
in
the
slack
Channel,
probably
because
I
think
it
needs
to
be
narrowed
down
a
little
bit,
but
I
hope
we
answered
that
for
you
and
then
on
to
the
second
one.
A
I
think
this
was
Dane
that
added
this
along
with
a
good
thread,
but
does
anyone
import
their
stack,
rocks
data
into
bigquery
or
anything
else?
Do
you
use
a
script
or
have
you
made
any
specific
processes
now?
In
TS
I
know
there
was
some
chatter
back
and
forth
some
people
using
Crown
jobs,
other
people
using
the
integration.
Do
you
have
any
recommendations
on
best
practice.
B
So
best
practice
would
generally
be
try
to
use
our
apis
as
much
as
possible.
These
are
stable
and
documented.
Besides
that
it
depends
on
your
use
case.
So
for
bigquery
we
don't
have
a
specific
integration,
but,
for
example,
for
Splunk
we
do
have
even
not
only
in
a
specific
integration,
but
also
a
technical
add-on
so
depending
on
which,
which
yeah,
which
sync
data
sync
you
target.
We
have
multiple
options
available
for
you.
We
also
offer
so
we
offer
API
or
yeah
callback
web
hooks
or
even
in
in
general
push.
B
So
even
if
you
are
interested
in
the
order
logs,
you
can,
for
example,
set
up
an
audit
log
Pusher
out
as
an
integration
in
in
stack,
rocks
or
ACS
to
put
to
actively
push
out
data
to
a
Target
sync.
But
besides
that,
if
you
want
to
script
something
yourself,
there
is
always
the
API
available
and
we
take
great
care
in
engineering
to
actually
base
it
around
protobuf
and
auto
generated
apis
as
much
as
possible.
So
you
should,
even
if
you
use
a
language
that
we're
not
necessarily
support.
B
Officially,
you
should
be
able
to
relatively
easy
easily
generate
headers.
For
that
specific
language,
you're
interested
in
that
might
be
a
more
advanced
task.
So
if
you
should
be
interested
in
that
I
know,
I
sound
like
a
broken
record
but
feel
free
to
Ping
us
on
slack,
because
that
might
be
a
discussion
that
we
might
want
to
invest
a
little
bit
more
time
into
and
need
a
little
bit
more
context
from
you,
depending
on
your
use
case.
A
Yeah,
it
gets
good
feedback
all
right
on
to
probably
the
last
important
topic
of
the
day.
The
Stack
Rock
ACS
public
roadmap
has
kind
of
been
has
been
flushed
out
with
some
of
the
PMs
and
looking
at
the
issues
that
have
been
created
in
the
GitHub
repository
now.
This
is
not
it'll,
be
public
on
Thursday
I'm
cutting
the
video
right
now,
along
with
some
slides.
You
know
if
you
go
back
and
look
at
the
other
public
world
map,
that's
on
YouTube,
which
I'll
post
with
it
you'll
see
all
the
progress.
A
That's
been
made
a
lot
of
it
due
to
feedback
from
the
community.
So
thank
you
for
that
and
then
we're
looking
for
more
feedback,
so
I'm,
hoping
that
when
I
publish
publish
this
on
Thursday,
you
can
come
and
say
hey
what
about
this
feature?
What
about
this
feature?
We
want
these
things
and
then
add
them
to
GitHub
as
issues
or
even
just
in
the
slack
Channel.
We
will
try
to
bring
them
up,
but
that
is
my
big
ask
from
y'all
I
think
that
would
be
awesome.
If
we
get
some
feedback
remember.
A
Obviously
the
roadmap
is
subject
to
change.
There's
always
things
that
are
in
flux
and
I'm,
hoping
that
we
change
it
because
we
get
some
awesome
ideas
from
the
community
so
again,
look
forward
to
that
on
Thursday
I
got
a
new
computer
that
luckily
you
can
process
video
a
lot
faster.
So
thankfully
I
have
a
couple.
Less
headaches
and
yeah
you'll
see
a
post
about
that
on
Thursday
and
then
the
last
thing
I
want
to
wrap
up
with
is
the
meeting
on
the
22nd
of
August.
A
It's
when
it's
later
for
and
so
August
22nd
after
Matthias
and
I
get
back
from
vacation
we're
going
to
give
you
an
update
because,
hopefully
we're
in
a
code
freeze
by
then
we
can
tell
you
everything,
that's
going
to
be
in
the
next
release.
We
can
talk
about
the
exact
date.
Hopefully
that's
going
to
come
out
on
and
then
the
next
meeting
in
September
will
be
back
on
track
the
week
of
the
release.
So
come
with
all
your
questions
and
hopefully
it's
a
short
and
quick
and
informative
meeting
right
after
the
release.
B
I,
don't
think
so
so
remember
folks,
the
August
meeting
will
be
hopefully
the
last
one
in
the
foreseeable
future
that
had
that
is
out
of
our
usual
Cadence
after
that
we'll
be
resuming
the
second
second
week
every
every
second
week
of
the
month.
So
for
until
then
folks
take
care.
It's
been
a
pleasure
and
see
you
in
August
see
you
there
take.