►
From YouTube: Automating Security in OpenShift Pipelines
Description
Red Hat OpenShift Pipelines is a cloud-native CI/CD solution that uses Tekton building blocks to automate deployments. Tekton introduces a number of standard Custom Resource Definitions (CRDs) for defining CI/CD pipelines that are portable across Kubernetes distributions.
Watch our office hours to learn about how to embed and automate security into Red Hat OpenShift Pipelines. We will show you:
- Common security checks that you should include in your container images and deployment configurations
- Step-by-step instructions on how to automate the security checks
- How to enable developers to fix security issues in builds and deployments earlier
Get your DevSecOps questions answered and start embedding must-have security checks into OpenShift Pipelines for a more resilient application.
A
Hello:
everyone
welcome
to
this
week's
office
hours
on
automating
security
in
openshift
pipelines,
I'm
chris
porter,
I'm
a
director
of
solutions,
architecture
at
red
hat-
and
I
have
here
today,
neil
carpenter,
who
will
be
doing
most
of
the
present
presenting
he
is
a
senior
principal
specialist
solution,
architect
at
red
hat.
Both
of
us
come
to
red
hat
from
the
acquisition
of
a
company
called
stackrocks.
You
may
hear
us
slip
up
a
little
bit
use
that
term
you'll
see
the
logo
here.
A
A
This
is
not
a
product
presentation
or
you
know
any
sort
of
slide
deck.
It
is
a
live
environment
with
demos
and
discussion
and
we
would
love
your
input
using
the
q,
a
interface
that
you'll
find
in
the
on24
session
that
you're
logged
into
there.
This
is
not
going
to
be
an
introduction
to
security
in
containers.
A
We'll
probably
talk
about
some
of
the
topics
that
are
relevant
there,
but
we
will
have
links
to
resources
that
you
can
use
some
of
the
basic
stuff
and
we'll
be
referring
to
that
throughout
this
resources
like
product
documentation,
open
source
projects
like
cube
linter
that
we'll
be
talking
about,
as
well
as
some
of
the
code.
Examples
that
we'll
use
and
we'll
walk
you
through
here.
So
since
we
don't
have
any
questions
yet
we'll
encourage
you
guys
to
start
off
with
that,
but
I'm
gonna
hand
it
over
to
neil
for
an
introduction.
A
B
B
It
means
we're
secure
out
of
the
box,
and,
and
so
what
we
really
want
to
do
is
take
those
things
that
we're
looking
for,
when
something's
deployed
making
sure
that
it's
properly
configured
properly
built
that
we
have
that
the
vulnerabilities
in
there
are
acceptable-
and
you
know
I
think,
between
us.
We
both
agree
that
there's
no
there's
no
such
thing
as
running
with
no
vulnerabilities,
but
we
do
want
to
catch
the
vulnerabilities
that
are
critical,
that
are
exploitable
that
are
problematic
and
the
earlier
we
can
address
those
in
in
the
cycle.
B
The
better
off
we
are
so
really.
This
is
about
taking
those
those
security
policies
and
those
security
concepts,
shifting
them
left
into
ci
and
finding
those
problems
and
making
developers
aware
of
them,
potentially
setting
gates
where
we
block,
where
we
block
builds,
we
block
deployments
based
on
them
if
they're
critical
enough,
so
I
think
step
one
you
know,
and
this
this
also
goes
back
to
devsecops
as
a
concept
right.
How
do
we
bring?
How
do
we
bring
security
into
devops?
B
B
What
we
really
start
doing
here
is
taking
security
criteria,
security
policy
and
treating
it
the
same
way.
So
not
only
does
it
pass,
my
unit
test
doesn't
do
what
I
expect
it
to
do.
Does
it
play
well
with
everything
else?
Does
it
meet
our
defined
security
policy?
Does
it
include
things
that
aren't
not
to
include?
B
That's
the
overall
thought,
the
thought
process
here
and
I
wanted
to
show
it
with
openshift
pipelines.
I've
been
doing
a
lot
of
work
with
openshift
pipelines,
which
is
based
on
tech
time,
and
it
is
it's
becoming
one
of
my
favorite
ci
pipelines.
Just
because
there's
a
lot
you
can
do
with
it.
There's
some
really
neat
capabilities.
I'll
show
you
I'll
show
you
one
of
those
as
we
dive
into
it.
But
it's
it's
a
it's
a
really
great.
B
B
I've
also
got
red
hat
acs,
what
used
to
be
stack,
rocks
up
and
running,
providing
policies
and
providing
the
scanning
and
we're
going
to
look
at
a
couple
of
a
couple
of
a
couple
of
scenarios
in
here
just
to
get
a
feel
for
what's
going
on,
and
so
I
want
to
start
actually
in
advanced
cluster
security
in
in
acs
now.
This
is,
there
are
lots
of
different
tools
that
I
could
I
could
do.
B
This
sort
of
integration
with
acs
happens
to
be
a
convenient
one
for
you
and
me
because
we
work
with
the
product
every
day,
but
you
know
I
can
use
other
tools
like
cube.
Linter
is
one
you'll
see
is
as
when
I
shift
back
to
pipelines.
I've
been
writing
an
integration
for
cube
winter,
which
is
a
an
open
source
tool
that
allows
you
to
look
at
kubernetes
deployments
and
find
problems.
B
So
there
are
lots
of
things
that
you
can
do
this
with
acs
just
happens
to
be
the
one
that
I'm
I'm
using
today,
and
so
what
I
want
to
show
you
in
acs
before
we
dive
into
it
into
a
couple
of
pipelines
and
tasks,
is
what
in
acs
directly
influences
this.
So
in
acs
we
have
policies.
Our
policies
are
really
the
heart
of
the
product
right.
They
define
what
we
want
visibility
into.
B
This
is
this
is
a
policy
around
vulnerabilities,
and
if
I
edit
this,
let
me
just
show
you
what
we're
looking
for
here.
So
we're
looking
for
vulnerabilities
where
they
have
they
have
what's
called
a
cbss
branch
is
the
which
is
a
measure
of
the
criticality
of
the
vulnerability,
the
common
vulnerability
scoring.
B
So
that's
a
ten
point
scale
and
we're
looking
for
anything,
seven
or
higher,
which
is
higher
critical
severity
vulnerabilities
and
we're
looking
for
ones
where
a
fix
is
available,
but
it
hasn't
been
fixed.
So
there's
it's.
The
vulnerability
is
present
in
our
image
and
it,
but
we
haven't,
we
haven't
fixed
it,
even
though
we
cut
it.
So
this
is
a.
This
is
a
pretty
typical
policy.
This
is
the
sort
of
thing
from
the
security
architect
perspective
that
I
might
be
looking
for
right.
B
If
I
have
higher
critical
severity
vulnerabilities
that
you
could
fix-
and
you
haven't
obviously
you're
going
to
be
in
better
shape
if
you
fix
those
things
than
if
you're
done
now.
There's
some
other
policies
in
here
that
I
really
like
a
lot
of
times.
When
people
look
at
security
integration
in
ci,
they
really
really
focus
on
vulnerabilities,
and
we
know
from
long
and
difficult
sort
of
you
know
the
last
15
years
watching
things
get
compromised
watching
when
people
get
their
companies
get
compromised.
B
We
know
vulnerabilities
are
certainly
a
major
piece
of
that,
but
misconfigurations
are
also
a
problematic
piece
of
that
providing
attackers
with,
with
you
know,
poorly
configured
code
or
poorly
configured
images,
poorly
configured
deployments,
providing
them
with
tools
once
they
once
they
manage
to
gain
a
foothold
that
allow
them
to
do
more
things.
There's
a
lot
of
other
things
that
we
can
look
for,
and
I'll
show
you
this
is.
This
is
one
I
I
particularly
like,
and
that
is
do
we
have
the
package
manager
in
the
image.
B
B
B
B
B
B
We
have
some
other
policies
built
in
around
things
like
curl
and
w
they
fit
in
the
same
sort
of
space.
I
shouldn't
need
curl
or
w
get
in
a
production
application,
that's
running
in
kubernetes
world.
So
we
can.
We
can
look
for
those
sorts
of
things.
We
can
look
for
things
around
how
the
images
are
actually
composed,
for
example,
if
I
can
find
it
while
I'm
talking
here,
docker
says
you
shouldn't
use
the
add
command
unless
you
absolutely
require
it
in
the
docker
file
and
building
an
image
you
should
use
the
copy
command.
B
Add
has
a
lot
of
a
lot
broader
set
of
capabilities.
You
can
read
the
rationale
there
in
what's
displayed
right
now,
but
it's
best
practice
to
use
copy,
not
add.
So
we
can
look
at
that
sort
of
thing.
Are
we
building
images
in
a
way
that
beats
best
practice,
and
then
we
can
also
look
at
deploy
time
things?
So
not
only
have
I
built
the
image
what's
in
it
does
it
does
it
have
critical
vulnerabilities?
Does
it
have
the
package
manager
all
of
those
things
those
are
important,
but
also
especially
in
a
kubernetes
world.
B
B
You
know
so,
as
an
example,
running
is
privileged.
This
is
this
is
one
of
those
configurations
that
is,
there
are
some
pieces
of
kubernetes
and
openshift
and
acs
that
need
to
run
as
privileged
because
they
do
infrastructure
types
of
things,
but
my
application
should
never
be
running
as
privileged.
If
I'm
you
know
whatever
I'm,
whatever
my
application,
my
workloads
are
running
is
privileged.
They
shouldn't
need
that
sort
of
privilege.
I
guess
is
the
right
word,
so
I
want
to
catch
those
sorts
of
things
at
deploy
time
and
say
hey
now.
B
This
is
this
shouldn't
be
running.
It's
privileged.
This
is
problematic.
You
know
there
are
lots
of
other
ones
right.
We
want
to
specify
resource
requests
and
limits
for
exactly
what
it
says
there.
If
I
don't
do
that,
if
somebody
compromises
my
running
container,
even
if
they
can't
use
it
to
do
something
useful
like
find
data
move
to
other
move
to
other
running
containers,
if
I
don't
have
resource
limits
specified,
an
attacker
could
potentially
use
my
container
that
they
compromise
to
run
that
node
out
of
available
memory
or
available
cpu
effectively
take
it
offline.
B
B
So
what
I've
done
in
here,
the
way
pipelines
work
is
there
are
they're
building
blocks
or
the
way
openshift
pipelines.
Techton
specifically
works.
There
are
building
blocks
called
tasks
and
I've
got
I've
got
some
tasks.
I've
got
some
cluster
tasks.
The
only
difference
is
a
cluster
task
is
available
in
every
namespace
every
project.
So
it's
much
easier
to
consume
those
across
lots
of
different
things,
and
so
I've
got
a
I've
got
a
task
here
that
wraps
up
rock
ctr
rock
ctl
is
a
command
line
tool.
B
B
B
If
I
look
at
a
sample-
and
I
look
at
my
image
check-
what
I'm
getting
back
is
actionable
intelligence
from
the
security
tool
from
acs
telling
me
first
of
all
my
my
build
fan
and
it
failed
because
we're
enforcing
the
policy
that
we
looked
at
earlier,
fixable
cbs
s
greater
than
equal
to
seven
or
do
we
have
fixable
vulnerabilities
that
are
higher,
and
so
I
can
see
that.
I'm
feeling
that-
and
I
can
see
you
know
why-
I'm
failing
that.
B
What
I
need
to
do
to
fix
that-
and
I
can
see
the
vulnerabilities
right
here
that
I
that
I
have
to
go
fix
to
in
order
to
succeed.
So
I've
got,
for
instance,
a
couple
of
libex
slt
vulnerabilities
in
this
image.
I've
got
1.1.31r1,
ip1.1.333-2,
etc.
So
I
go
fix
those
things
and
then
obviously
rebuild
the
image
and
succeed.
B
But
I
can
also
look
there's
some
there's
some
policies
in
here
that
aren't
enforced,
so
they're
not
breaking
my
build,
but
still,
while
I'm
fixing
these
vulnerabilities,
I
should,
for
example,
add
a
user
directive,
so
they
might,
it
runs
as
a
specific
user,
not
azure,
so
not
just
to
run.
This
word:
it's
expected
to
run
as
a
limited
user
and
do
it.
B
B
Now
that's
with
the
image
we
mentioned
deployments
and
ci
cd
and
a
lot
of
times.
We
talk
only
about
the
ci
half
of
that
right,
but
continuous,
continuously,
building
things
and
then
continuously
deploying
them.
So
as
part
of
continuous
deployment,
we
can
use
a
tool
like
acs
or
like
cube,
linter
or
some
other
tool.
That's
also
going
to
look
at
the
deployment
and
all
of
those
deploy
time
things
you
know.
Is
it
running
as
privileged?
Does
it
take
capabilities,
doesn't
have
resource
requests
and
limits
set.
B
All
of
those
things
we
can
look
at
the
deployment
as
well
and
see
is:
is
this
good
is
this?
Is
this
worth
it?
Is
this
problematic
or
not,
and
so
I've
got
another
task,
unsurprisingly,
that
wraps
up
roc
ctl
deployment
check,
and
I
can
see
that
and
I
can
run
that
against
against
something
now
in
this
case
it
succeeded
because
I'm
not
enforcing
any
of
those
policies,
but
I
can
see
that
I
have
a
number
of
problems
in
this
particular
deployment.
One
of
the
containers
in
this
deployment
is
running
is
privileged.
B
B
B
If
we
have
things
that
are
that
are
outside
of
our
traditional
ci
process,
how
can
we
manage
those
and
take
action
as
well
and
triggers
are
really
cool
for
that?
So
what
I've
done
here
is
I've
got
a
an
event
listener
that
listens
in
this
case
for
a
web
hook
coming
in
from
the
the
public,
and
so
this
is
set
up
to
listen
to
create
a
listener.
B
In
my
way,
repo
I've
said
it
to
send
a
web
book
every
time
a
new
image
gets
gets,
pushed
to
quay
to
that
particular
repo,
and
then
I've
got
I've
got
bindings.
I've
got
a
template
and
a
binding
that
essentially
tie
this
together
to
run
that
same
image
check
every
time,
a
new
every
time
a
new
image
gets
pushed
to
my
registry,
and
so
you
see
here
it
takes.
B
I
can
see
very
similar,
I
had
I
had
an
image
pushed
away
and
it
scanned
and
it
returned
a
failure,
and
so
I
can
do
something
with
that
and
catch
those
things,
and
this
is
this-
is
this
is
really
interesting
for
a
lot
of
reasons.
I
am,
I
talked
to
a
few
telecoms
recently
and
then
so
a
thing
I
don't
think
a
lot
of
people
know,
but
all
of
the
5g
infrastructure
to
support
5g
phones
is
being
delivered
on
top
of
kubernetes
and
openshift.
B
So
as
a
telecom
you're,
getting
these
things
from
your
providers,
your
vendors
that
are
essentially
human,
artifacts
and
then
you're
pushing
those
into
kubernetes
right
then
running
the
infrastructure
that
all
of
our
phones
run
on,
which
is
super
cool,
but
one
of
the
problems
they
have
is,
if
we're
pulling
this
stuff
in
for
vendors,
how
do
we
make
sure
that
it
meets
our
security
policy?
And
this
is
this
is
one
of
the
things
we
were
talking
about?
B
A
That's
a
pretty
powerful
yeah,
it's
a
pretty
powerful
mechanism
there.
Just
to
you
know,
just
to
you
know
on
that
dig
down
on
that
subject
a
little
bit
here.
You
know
essentially
because
organizations
are
are
busy
establishing
this.
So,
let's
face
it,
not
every
organization
has
got
things
organized
yet
and
has
their
full
ci
cd
pipeline
built.
But
if
we
have
the
registry
available,
that's
kind
of
that
point
of
control.
A
This
allows
me
to
get
that
visibility
for
the
security
team.
Even
if
you
know
my
development
team
is
still
catching
up
to
the
best
practices.
So
it
sounds
like
a
great
way
to
you
know,
get
the
security
team,
the
visibility
they
need
without
too
much
work
on
the
part
of
the
developers,
and
we
can
slowly,
you
know,
roll
their
their
their
work
into
into
the
the
model
here
right.
A
A
I've
been
hearing
those
stats
for
you
know
20
plus
years,
but
but
here
because
organizations
are
transforming
their
the
way
they're
building
applications,
we've
finally
got
a
place
where
that
kind
of
activity
is
like
it's
a
natural,
it's
a
natural
fit
for
this,
so
even
in
cloud
even
with
virtualization,
everything
is
still
a
bit
of
a
an
awkward
introduction
to
get
like
a
devsecops
pipeline
going
in
those
kind
of
worlds.
But
here
it
seems
like
it
just
fits
pretty
easily.
B
B
All
really
goes
together
and
the
fact
that
the
way
that
the
pipelines
are
architected
so
that
I
can
really
you
know
so
that
we
automate
all
of
the
sort
of
acceptance
of
testing
and
all
of
these
things,
so
that
I
can
inject
security
policy
into
that
and
really,
where
necessary
and
force
that
anywhere
along
there
is,
is
very,
very
powerful.
It's
a
it's.
A
great
combination
of
all
of
these
things
to
to
apply
security
policy.
Programmatically.
A
Now,
for
folks
who
may
have
joined
a
little
bit
late,
we
are
taking
questions
live.
So
if
you
have
something
you'd
like
to
ask
about
product
pipelines
strategy,
you
know
industry
practices,
comments,
something
that
you'd
like
to
ask
there.
We
can.
We
can
answer
those,
you
know
we
do.
We
do
have
one
and
one
that
we
get
quite
a
bit
about.
You
know
those
vulnerabilities
that
we
see
on
this.
The
screen
there
you
know
do
I
have
to
fix
all
of
them
like.
A
Is
that
the
only
option
you
know
generally
developers
are
presented
with
a
list
like
this
and
go?
You
know
I
you
know,
I'm
not
using
some
of
these
things.
Why?
Why
are
they
coming
up
as
as
vulnerabilities?
This
isn't
my
code?
Do
I
have
to
deal
with
this?
Can
I
get
an
exception
right,
like
that's
the
first
kind
of
reaction
there?
I
guess.
B
A
reasonable,
even
a
reasonable
sort
of
image,
may
have
half
a
dozen
vulnerabilities
that
are
tripping
over
whatever
the
policy
is,
and
I
find
there
are
a
couple
of
approaches
to
this
right.
First,
yes,
I
think,
I
think
we
all
have
to
have
some
understanding
that
everything
runs
with
some
vulnerabilities
right.
It's
I've
had
a
few
security
organizations
who
really
tried
to
stick
with
hey
we're
going
to
run
with
no
vulnerabilities
and
that's
not
a
reasonable
world.
The
only
the
only
way
to
run
with
no
vulnerabilities
is
to
have
incomplete
vulnerability
scanning.
B
B
So
there
were,
there
were
a
ton
of
vulnerabilities
that
they
didn't
see
because
they
weren't
scanning
the
application
layers
of
things,
and
so
their
security
team
was
happy
that
there
were
no
reported
vulnerabilities,
but
there
were
actually
a
lot
of
vulnerabilities
inside
of
what
was
there.
So
you
know,
I
think,
certainly
that's
that's
a
an
open
question
of
making
sure
that
you're
getting
all
the
vulnerabilities
but
step,
one
is
absolutely
figuring
out.
What's
what's
really
critical
but
step
two
is
looking
at.
B
You
know
not
just
fixing
vulnerabilities
but
maybe
working
around
them,
and-
and
this
is
what
I've
got
on
screen
here-
is
a
great
example.
So
apk
tools
I
I'll
be
I'll,
be
the
first
to
admit.
I
I've
not
spent
as
much
time
with
alpine
as
I
have
with
other
with
other
platforms,
and
I
think
that
this
particular
image
is
alpine
based,
but
I'm
pretty
sure
apk
apk
tools
are
tools
for
manipulating
and
installing
packages
in
alpine
I
may
be
wrong,
and
if
I
am,
let's
just
pretend
I'm
right,
you
know.
B
If
that's
what
this
is,
then
why
do
I
have
it
in
an
image
once
again
I
like
to
having
the
package
manager
in
there
there's
no
reason.
I
should
need
a
component
that
manages
alpine
packages,
so
let's
just
strip
that
out,
let's
just
instead
of
fixing
the
vulnerability,
let's
remove
the
component
entirely.
B
A
If
I
find
that
I've
got
all
these
components
that
I
didn't
even
know
that
I
had-
and
this
message
is
making
it
clear
to
me
that
it's
my
responsibility
to
maintain
those-
I
you
know
I
don't
want
to
so
like
if
I'm
not
using
it
like
busybox-
might
be
really
useful
but
it.
But
if
it's
not
something
that
my
application
depends
on,
I'm
just
going
to
get
rid
of
it.
I
suppose
the
you
know
the
corollary
to
that
too
would
be.
A
A
For
me
right,
like
as
the
developer,
I
want
to
get
this
information,
because
maybe
I
don't
want
to
go
to
1133
r3.
I
want
to
go
to
1134
right,
like
I
want
to
have
some
flexibility,
because
something
naively
applying
a
fix
to
a
known,
fixed
version
has
the
potential
to
just
break
the
whole
thing
right.
A
So
I
mean
it
seems
like
this
is
a
great
way
for
a
developer
to
get
you
know,
kind
of
that
pre-flight
check
and
understand,
what's
going
to
trip
him
up
but
make
an
intelligent
decision
about
which
direction
to
go
with
all
of
this
right.
I
don't
necessarily
have
to
go
to
that
version.
I
don't
necessarily
have
to
have
that
library
in
there.
If
I
can
just
go
out
and
and
and
make
a
change
that
would
as
long
as
I
get
to
a
resolved
version,
then
you
know
security's
happy
with
that
right.
A
B
B
Even
then
I
mean
I,
I
spent
some
time
behind
some
of
those
things
you
know
at
microsoft.
There
are
jokes
about
patch
tuesday,
because
the
wednesday
after
patch
tuesday,
there's
always
a
flood
of
support,
calls
for
things
that
people
think
updates
broke,
and
sometimes
they
did.
You
know
it's
much
more
critical
when
you
start
looking
at
libraries
like
you
said
that
are
linked
to
other
libraries
that
you
get
that
right
and
you
have
somebody
who
understands
it,
you
don't
just
automatically
update
versions
and
see
what
happens
so
yeah.
I
think
that
that's
a
this
is.
A
B
Yeah
so
annoyingly,
one
of
the
things
pipeline
doesn't
do
that
I
can
find,
is
show
me
how
long
each
stage
took
to
run
but
typically
yeah.
That's
I
hadn't
realized
that
wasn't
there,
I'm
so
used
to
seeing
it
in
jenkins,
for
example,
typically
our
the
image
scanning
takes
like
15
to
30
seconds,
if
actually
it.
I
know
it
takes
less
than
28
seconds
in
almost
every
every
instance
because
of
some
other
work
we've
done.
B
So
it's
a
matter
of
pulling
the
image
and
then
decomposing
the
image
into
the
components
and
then
matching
that
up
with
known
vulnerability
data.
Presuming
that
the
image
pull
doesn't
take
very
long
yeah.
It's
going
to
be
very,
very
quick.
It's
going
to
be
10
to
15
seconds
to
add
this
into
into
a
pipeline.
A
Right
and
when
a
new
vulnerability
is
discovered
that
data's
already
in
acs
because
we're
pulling
it
from
the
various
sources
out
there,
and
so
every
run
that
I
have
here
could
potentially
be
different
right.
Something
could
be
newly
discovered
in
the
interval
between
this
morning's
run
and
this
afternoons,
and
I've
got
something
else
that
I
have
to
deal
with,
namely
a
newly
discovered
vulnerability
right.
B
Yep
yep
and
then
you
know,
I
think,
the
other,
the
second
half
of
that
question.
How
long
does
it
take
to
mitigate
you
know?
That's
a
that's
a
much
more
difficult
question
right
because
that
that
gets
back
to.
We
need
somebody
to
do
the
work,
so
you
know
we
can.
We
can
see
that
the
pipeline
failed,
or
you
know,
in
a
sort
of
larger
acs
environment.
We
might
create
a
jira
task
or
do
something
like
that.
So
then
there
becomes
a
question
of
that
human
element
of
how
do
we?
B
How
do
we
prioritize
that
somebody
picks
it
up?
Does
the
work
potentially
finds
there
are
other
libraries
linked
to
that
library
that
they
have
to
update
you
know,
so
I
think
that
there's
certainly
a
finite
period
of
time,
that's
much
longer
than
15
seconds
that
it
takes
to
fix
it
after
it's
after
it's
found,
but
adding
this
adding
this
into
a
pipeline
for
almost
any
of
the
tools
I've
looked
at
is
is
reasonably
quick
right.
B
A
Well,
if
I'm
a
developer-
and
I
know
what
I'm
doing-
I'm
going
to
quickly
try
to
automate
the
package
updates
for
the
things
that
I
do
depend
on
right,
because
keeping
us
updated
with
every
single
build
kind
of
gets
ahead
of
the
problem
right.
Instead
of
getting
this
report
going
back
researching
the
versions
of
this
stuff,
you
know
I
I
just
want
to
say:
hey,
you
know,
use
apk
and
alpine
to
update
the
package
sources
and
get
the
latest
version
in
there
right.
A
I
want
to
have
a
way
that
I'm
going
to
get
the
vast
majority
of
that
just
by
running
the
build
again
rather
than
having
to
deal
with
them
piece
by
piece,
and
I
suppose
the
other
side,
you
know
good,
a
good
developer
is
an
impatient
developer.
I
might
spend
a
little
bit
of
time
up
front
to
try
to
reduce
the
surface
area.
That's
on
that
alpine
image
or
whatever,
so
that
I'm
not
bringing
in
so
much
in
the
first
place,
because
if
it's,
if
it's
not
there,
then
I
don't
have
to
maintain
it.
B
Yeah
absolutely-
and
I
think
you
know,
alpine
red
hat
ubi
are
great
places
to
start
for
that
sort
of
minimalism
and
you
know
even
possibly
moving
towards
scratch
containers
for
things
that
are
very,
very
single
purpose,
but
I
think
it
yeah
taking
taking
a
platform
that
is
minimal
to
begin
with
and
then
adding
only
what
you
need
and
then
figuring
out
yeah
can
I
have
a
can.
I
have
a
reasonable
update
cycle
to
just
you
know,
update
all
of
the
all
the
libraries
I'm
using
and
then
you
know
you.
B
I
think
you've
got
to
have
some
knowledge
of
where
you
have
to
pin
libraries
to
a
particular
version.
If
there's
a
risk
of
updates
breaking
something.
But
that's
that's
all
developer
stuff
right.
That's
somebody's
got
to
figure
that
out
and
have
have
the
have
the
expertise
to
do
it
or
they're
going
to
be
chasing
failures
later
on.
A
B
Yeah,
so,
unfortunately,
today
was
the
day
I
had
some
time
to
work
on
that,
so
I
haven't.
I
haven't
actually
gotten
my
pipeline
working
on
working
yet
so
you
catch
me
a
little
bit
off
guard,
but
it's
a
good
look
at
cube,
linter!
Sorry,
I
know
chris
was
going
to
ask
that
I
would
have
already
had
it
open,
but
if
you're
not
familiar
with
it
cube
linter
is
a
tool
for
analyzing
yaml
files
and
helm,
charts
that
you're
going
to
deploy
kubernetes
stuff
with
and
looking
for
typical
security
misconfiguration.
B
So
it's
a
great
tool.
You
know,
I
think
I
was
hoping
that
there
was
an
example
here
of
output
from
it.
It's
just
not
going
to
be
my
day
for
that,
but
this
is
a
great
tool
for
doing
some
of
the
stuff,
like
the
rock
ctl
deployment
check,
does
but
doing
it
without
a
back
end
of
some
sort.
Right.
Just
saying
here
are
the
tests
we're
going
to
run
we're
going
to
look
at
is
this
running
privileged?
B
Is
it
setting
resource
requests
and
limits
all
of
those
sorts
of
things,
and
so
really
what
I'm?
What
I'm
doing,
and
actually
chris
I'm
glad
you
asked
this
because
there's
another
thing
that
I'm
gonna
I'm
going
to
oh
yeah,
there
is
some
output
here
that
I
did
want
to
show
before
we
run
out
of
time.
So
this
is.
This
is
a
typical.
You
know,
here's
here's,
a
there's,
a
deployment
yaml,
you
run
cube,
linter
lint
and
it
returns
some
errors
here,
indicating
that
it
does
not
have
a
read,
only
root
file
system.
B
B
B
All
of
this
is
in
the
github
stackrocks
contributions,
repo,
there's
a
ci
area
here
that
shows
typical
stackrock's
acsci
integrations
and
everything
I've
done
today
is
in
the
tecton
in
the
tecton
piece.
Actually
I
take
it
back.
The
trigger
is
not
here
yet
I'm
going
to
be
writing
up
the
trigger
and
adding
it
here
and
when
I
get
the
the
cube,
linter
task
running,
we'll
add
that
here
as
well.
B
A
Yep,
so
this
is
just
a
question
about
these
links
to
these
repos
and
things
like
that,
we'll
make
that
all
available,
which
should
be
part
of
the
resources
that
are
part
of
this.
This
this
event
is
also
being
recorded.
So
we'll
get
you
get
you
all
of
that
information
out
there,
but
this
is
on
the
public
organization.
Called
stack,
rocks
on
github
you'll
see
a
few
things
in
there.
This
is
going
to
be
part
of
the
going
forward.
Part
of
the
the
stack
rocks
community.
A
So
contributions
like
this
were
you
know,
taking
from
from
our
customers
from
users
out
there
and
all
of
the
the
code
that
you
saw
in
the
pipeline.
There
is
is
available
today
in
in
with
the
repository
that
neil
built
as
nielsen
saying,
there's-
probably
not
a
ci
or
cd
tool
that
we've
seen
that
doesn't
work
with
that.
We
can't
make
to
work
with
this
this
model,
because
the
ci
tools
all
take
this
task
based
approach,
these
different
terminology,
it's
pretty
broadly
compatible
with
these
kind
of
checks.
B
A
A
B
A
With
I've
been
meaning
to
ask
you
about
this,
because
you
and
I
have
both
worked
on
some
of
these
and
and
have
had
various
tools
that
we've
worked
with
and
we've
we've
noted
the
problem
that
you
know.
You've
got
to
get
the
rock
ctl
tool
here
in
the
first
place
right
and
you
know,
authentication
and
all
that
now
and
they're,
keeping
with
the
open
nature
of
red
hat
that
rock
ctl
binary
is
now
available
through
red
hat
sources.
Does
that.
B
Us
a
little
bit
more
flexibility
yeah.
So
what
chris
is
referring
to
here
in
my
sample
you'll
see
that
that
what
I
do
is
reach
out
to
central,
which
is
the
the
management
piece
of
your
acs
deployment
and
grab
the
latest
copy
of
rox
ctl,
make
it
executable
and
then
use
it.
I
think
there
are
a
couple
of
approaches
here,
and
this
is
sort
of
going
to
depend
on
the
tool
and
what
you
want
to
accomplish.
B
B
You
know,
that's
that's
useful,
because
there
are
certainly
some
changes
over
time
in
rock
ctl.
There
have
been
some
things
that
have
been
added
and
changed,
and
so
it
just
reduces
the
chance
of
a
change
being
introduced
which
breaks
something
and
then
I
end
up.
You
know
spending
time
troubleshooting
that
trying
to
figure
out
what
happened.
I
think
it's
certainly
acceptable.
If
you
want
to
manage
the.
B
If
you
want
to
download
the
binary
and
manage
it
in
a
you
know,
if
you
want
to
use
an
image
that
has
that
binary
embedded
in
it,
if
you
want
to
do
something
else
like
that,
I
think
there
are
a
lot
of
approaches
for
roxy
tail.
For
example,
there
is
a
there
is
an
image
out
there
that
has
rock
ctl
embedded
in
it.
You
can
use
that
instead,
if
that's
what
you
wanted
to
do,
and
you
don't
have
to
to
download
it
to
run
it.
You
know
I
think
yeah.
A
Yeah,
certainly
downloading
it
from
the
control.
Plane
works
better
for
me,
if
I'm
running
everything
on-prem
or
just
in
a
private
cloud
environment
where
you
know,
hopefully
my
dev
systems,
don't
actually
have
internet
access
right
where
the
you
know,
there's
security
restrictions
at
the
perimeter.
That
would
prevent
me
from
getting
out
because,
that's
you
know
off
topic
for
this
conversation,
but
a
good
practice.
A
lot
of
enterprises
follow-
and
I
hope
our
5g
telecom
folks
are
following
that.
But
this
is.
B
Yeah
yeah-
and
you
know
lots
lots
of
ways
to
approach
that
this
is
these.
What's
up
here
is
really
intended
as
samples,
so
I
try
to
make
them
as
broadly
applicable
and
as
whatever
the
opposite
of
prone
to
failure
stable.
I
guess,
as
I
can
make
them,
and
so
for
me
this
is
the
easiest
approach.
I
think,
if
you
know,
if
you
see
this
as
a
problem,
because
it
introduces
an
extra
half
second
in
every
run
and
that's
that's
unacceptable
and
you
can
take
a
different
approach
and
figure
out
how
to
manage
that.
A
Now
I
saw
somewhere
else,
you
also
had
the
image
scan,
which
is
like
the
machine,
readable
output
for
images
right.
That
means
a
lot
of
different
requirements
that
you
know,
maybe
I'm
not
being
able
to
to
meet
today
with
like
the
human
readable
output
like
I
want
something
in
a
you
know:
csv
spreadsheet,
or
something
right.
B
Yeah,
and
so
so
what
chris
is
referring
to?
Let
me
let
me
grab
a
pipeline
here,
so
you
actually
see
I
do
an
image
scan
and
an
image
check
image
scan,
so
image
check
returns
that
policy
based
this
passes
all
the
policies.
It
fails
this
one
this
one
in
this
one
image
scan
returns
all
of
the
vulnerability
data
in
a
couple
of
different
formats
or
possibly
in
different
formats.
B
So
it
gives
me
every
vulnerability,
the
component,
it's
in
what
layer
it's
in
in
my
image,
all
of
that
information,
so
here,
like
I've,
got
this
output
in
csv,
so
I
could
capture
this
as
a
file
make
it
available
as
an
artifact.
So
if
my
developers
look
at
this
information
and
go
well,
I
don't
I
don't
know
where
node.js
came
from.
B
They
can
go
to
this
data
and
look
at
every
component
vulnerability
in
here
and
see
all
right
that
was
introduced
in
this
is.
This
is
actually
a
a.
This
is
a
a
scratch
image,
so
there's
not
much
in
the
layers,
but
it
was
a
better
image
I
could
see
which
layers
each
of
these
things
was
introduced
in,
and
we
can
do
that
in
in
acs.
We
can
do
that
in
json
format.
B
If
I
want
to
parse
it
myself,
if
I
want
to
use
that
in
some
sort
of
machine
readable
way,
we
can
do
it
in
csv
output
and
we
can
do
it
in
what
in
pretty
output,
where
it's
much
more
human
readable.
If
I
want
to
just
consume
it
in
line
here
but
yeah,
that
is,
that
gives
me
the
ability
to
not
just
get
so.
Here's
what
failed,
but
to
get
every
vulnerability
with
its
cvss
score
and
whether
it's
fixable
and
all
of
that
information.
A
B
Is
obviously
my
csv
output,
I
wouldn't
want
to
save
off
and
open
up
somewhere
else.
You
know.
If
I
look
at
it
and
say
pretty
format,
it
has
some
control
characters
in
here
I
haven't
figured
out
how
to
strip
those
off,
but
you
can
see
here
it's
it's
much,
it's
mostly
more
readable,
so
I
can
see,
for
example,
here's
a
here's,
a
layer
in
my
docker
file
and
here
are
all
the
the
components
and
vulnerabilities
and
those
components
in
those
layers.
B
So,
for
example,
this
was
the
one
where
we
saw
the
libex
slt
vulnerabilities.
There
are
those
vulnerabilities
and
I
can
go
look
and
say
all
right.
That's
in
this
layer
where
I
run
apt-get,
I
think
it's
a
really
long
layer
but
yeah
yeah,
so
I'm
using
I'm
pulling
all
these
things
in.
So
I
can
go
back
and
say
all
right.
Here's
where
here's,
where
I
would
have
to
go
to
fix
that
those
particular
vulnerabilities.
A
Interesting,
so
the
layers
are
separated
out.
That's
a
cool
thing
because
you
know
potentially
I'm
not
the
one
who
built
like
you
know.
I
didn't
build
the
base
image
I
may
not
have
built.
You
know
what
I
would
what
gets
handed
to
me
to
use
here.
I
may
have
built
on
top
of
somebody
else's
work,
so
I
can
easily
tell
if
this
is
something
that
my
own
code
introduced
or
if
it
came,
you
know
from
another
team,
that's
responsible
for
building
images.
A
So
that's
that's
pretty
cool
and
learned
something
new
yeah
so
back
to
the
audience.
Folks,
if
you
have
any
more
questions,
if
there's
anything,
that's
unclear
here
that
you
want
us
to
review
again
we're
happy
to
take
those.
This
is
going
to
be
recorded,
so
you'll
be
able
to
review
this
later
or
send
it
to
others.
It'll
be
out
on
on
the
stacks
community
channel
for
for
youtube.
A
Great
well,
thank
you,
everyone.
It
was
certainly
wonderful
to
have
so
many
people
on
listening.
Hopefully
it
was
valuable
for
you
if
you
like
this,
we're
going
to
have
a
continued
series
of
these
keep
an
eye
out
for
both
neil
and
I
as
part
of
red
hat
events
as
well.
Generally,
if
you
see
red
hat
and
open
shift
and
security
you'll
probably
see
one
of
our
names
attached
to
those
events
out
there
we're
looking
forward
to
it
we're
looking
forward
to
getting
back
to
meeting
folks
in
person
someday.