►
Description
Here you can find our monthly show focused on all things security, cloud native, and open source projects. Today we are discussing:
- Supply chain Security and Red Hat's NEW validated DevSecOps Pattern with Jonathan Rickard and William Henry!
- Updates for KubeCon EU and Red Hat summit
- RHACS 4.0 is coming out next month! We'll discuss the details.
Get started with Red Hat Validated patterns here - https://hybrid-cloud-patterns.io/patterns/
Make sure to subscribe and leave your comments for the team!
A
B
B
So
we
have
a
packed
house.
We
got
three
of
the
authors
and
contributors
to
the
devsecops
validated
pattern.
It
is
validated
pattern,
I
believe
they're
going
to
come
in
and
correct
the
record
of
everything
we
say,
but
I
just
want
to
get
into
a
couple
of
the
notes
before
we
bring
them
in.
We
have
just
some
quick
announcements.
You
know,
kubecon
EU
is
coming
up.
B
A
B
And
that's
May
23rd
25th,
that's
in
Boston
and
ansible
Fest
is
at
the
same
time
as
well
I'm
going
to
be
there
we're
going
to
be
talking,
openshift
platform
plus
and
giving
a
Hands-On
demo.
So
if
you're
interested
tickets
are
available
and,
of
course,
Boston's
just
so
lovely
in
May,
so
we
look
forward
to
seeing
you
there
I
think
well,
there's
some
big
news
and
then
some
news,
that's
upcoming,
cert
manager,
1.0
is
officially
available.
B
Ga,
so
I
know
that
Anjali
and
some
of
the
product
managers
been
working
very
very
hard
to
get
that
out.
So
cert
manager,
1.0
is
live
and
I
could
tell
you
that
just
from
managing
certifications
in
openshift
and
with
ACS
that
can
somewhat
be.
You
know
a
little
bit
of
a
pain
so
definitely
worth
checking
it
out.
I
put
the
link
in
the
chat
and
I'll
try
to
post
them
to
YouTube
as
well
after.
B
B
All
right!
Well
so,
if
you're
part
of
the
community
in
stack
rocks
you,
you
know
that
we've
been
talking
about
4.0
for
a
while
3.74
just
came
out
and
there's
questions
about
hey.
Why
are
we
going
to
4.0
and
that's
largely
because
of
some
breaking
changes,
we're
changing
the
back
end,
so
it's
going
to
postgres
as
the
default
database.
That
really
allows
it
to
scale,
especially
with
the
cloud
service
that
we're
coming
out
with.
It
also
allows
for
some
new
features
that
were
not
necessarily
available
in
the
CLI
and
things
of
that
sort.
B
So
again,
4.0
is
going
to
be
extremely
exciting.
The
goal
is
mid
to
late
April,
but
stay
tuned.
If
and
especially,
if
you're,
in
that
Community
slack
channel
for
stack,
rocks
you're
going
to
get
all
your
notifications
and
updates
there,
and
you
can
ask
us
questions
because
the
next
community
meeting
is
the
second
Tuesday
of
April.
So
Matthias
myself
will
be
answering
all
your
questions
for
4.0
updates,
breaking
changes
and
the
like.
But
of
course
you
know
we
have
a
support
Matrix
for
six
months,
so
you
don't
understand
they
need
to
upgrade.
B
But
I
can
tell
you
yeah
everything
I'm
getting
some
back
Channel
ping
saying
everything
is
not
so
secret
on
the
secure
cloudcast
yeah,
but
listen
there.
We
want
you
to
go
check
out
3.74
because
there's
a
ton
of
new
features,
a
new
network
graph,
new
policy
Collections
and
whole
policy
workflow.
So
it's
definitely
worth
checking
out
Kim.
Anything
else
that
you
wanted
to
talk.
Slash
not
talk
about
secret,
not
serious.
Before
we
bring
the
the
gang
on
in.
B
Now,
let's
bring
him
on
in
so
there's
three
I,
don't
know
exactly
what
we're
going
to
introduce
them
in
we'll
see
how
they
appear.
We
have
William
Henry,
we
have
Johnny
Rickard
and
we
have
Anthony
Anthony
her.
Hopefully,
I
got
all
that
right.
Fellas,
you've
all
been
working
on
the
the
devsecops
and
the
validated
patterns
for
a
long
time
now,
starting
with
William.
You
want
to
introduce
yourself.
Let
us
know
what
you've
been
up
to
and
what
you
do
at
Red,
Hat.
C
C
Yeah
I've
been
working
on
lots
of
different
projects
over
the
years
of
red
hat,
but
more
recently,
they've
been
working
on
this
validated
patterns,
effort
which
we'll
get
into
in
a
moment
and
specifically
working
with
Anthony
and
Johnny
on
the
multi-cluster
devsecops
pattern,
which
is
all
about
security
and
stuff
like
that.
So.
D
Go
yeah
I
mean
I'm
I'm,
pretty
much.
You
know,
known
everywhere,
famous
I'd
sign
autographs
to
Target
in
Walmart
all
the
time.
You
know
it's
like
that's
my
thing,
but
no
I'm,
Johnny
Rickard
I've
been
at
red
hat
for
seven
years
and
I'm
on
the
validated
patterns
team
with
William
and
Anthony
I've
I've
been
doing
this
I
think
coming
up
on
little
two
years.
This
summer,
I
think
will
be.
D
You
know
my
time
on
service
or
whatever,
but
I
came
from
Consulting
I
Was
An
Architect
for
a
while
I'm.
Also
the
co-host
on
ask
an
openshift
admin
with
Andrew
Sullivan.
So
if
you
want
to
nerd
out
on
you
know,
openshift
and
all
things
open
shift,
you
know
make
sure
you
come
check
us
out
on
Wednesdays.
E
E
B
E
E
From
my
side,
William
brought
this
to
our
our
attention
kind
of
working
through
most
when
I
joined,
Red
Hat,
specifically
I
I,
came
in
as
a
PM
for
a
couple
different
products,
and
my
goal
was
to
just
try
to
have
a
little
experience
with
the
products.
So
I
took
our
reference.
Architectures
I
got
to
about
the
third
step
and
it
broke,
and
that's
just
because
they're
not
maintained
over
time.
It's
the
way
documentation
works
is,
if
you
don't
have
a
constant
update
process
that
even
the
best
procedures
will
go
out
of
date.
E
So
we've
had
this
initiative
so
that
we
can
have
more
living
use
cases
and
focus
on
the
business
outcomes
looking
at
things
at
a
portfolio
level,
not
at
a
single
product
level.
So
we
have
these
use
cases
and
the
main
goal
is
to
keep
them
active,
keep
them
alive
over
a
long
period
of
time,
so
customers
can
trust.
What
we
put
together
is
is
something
that
they
can
use.
D
C
And
so
testing,
every
single
combination
of
all
of
these
different
products
together
is
just
too
difficult
and
too
daunting.
However,
if
we
see
patterns
that
are
being
developed
within
customers
or
partners-
and
we
take
those
in-house,
we
try
to
automate
them
and
run
them
through
continuous
integration
processes.
C
Then
we
can
kind
of
say,
hey
this
architecture,
this
deployment
this
pattern,
it
still
works
R,
we
can
say
it's
broken
and
that's
what
happened,
because
if
we
can
turn
around
and
identify
where
patterns
get
broken,
then
we're
making
sure
that
you
know
customers
and
partners
aren't
discovering
it
first
we're
helping
them.
We're
preempting
that,
because,
when
you
have
all
these
things
working
together,
it
gets
very
complicated,
very
complex,
there's
a
lot
of
handshaking
and
plumbing,
and
all
that
good
stuff
between
different
processes
and
trying
to
keep
that
working
is
is
hard.
D
Yeah
and
just
to
pile
on
right
like
it
comes
down
to
you
know,
the
idea
is
like
trying
to
show
our
customers
the
art
of
the
reality
versus
The
Art
of
the
possible
right,
because
you
know,
like
we've,
all
been
we've
all
dealt
with
technical
Engineers
where
they
come
in,
they
whiteboard
it
and
they're
like
oh
man.
This
is
so
awesome
and
then,
when
you
try
and
Implement
that
thing
it's
like
well,
okay,
this
doesn't
necessarily
work
this
way.
D
Because
of
this,
we
actually
put
all
like
the
rubber
to
the
road
right,
so
we
do
all
the
Integrations
between
the
products
and
so
we're
when
we're
showing
off
like
the
the
pattern,
the
demo
on
the
pattern,
it's
actually
a
working
living,
breathing
demo
that
can
work
that,
like
it's
a
tool
set
that
you
can
use
in
your
environment.
If
that's
the
thing
that
you're
trying
to
go
after
so
I
mean
I.
Think
that
that's
the
important
part
the
other
piece
to
it
is
that
well,
I
lost
my
train
of
thought.
B
For
you
actually,
no,
it's
fine,
so
I
posted
a
link
to
the
valet
patterns
in
the
chat,
but
you
know
this
has
been
an
issue
for
a
while
I
know
it
had
been
a
community
pattern
for
a
significant
time
before.
Can
you
explain
the
difference
before
we
deep
dive
into
the
actual
technology
you
know
is
validated
the
value
of
each.
B
E
You
go,
I
was
going
to
put
in
what
you
have
up
there
is
our
red
hat
get
Ops
patterns
site.
Most
of
the
material
we
have
is
with
customers,
partners
and
services
organizations
kind
of
focused
on
it
is
in
our
hybrid
Cloud
pattern,
so
we'll
put
a
different
Link
in
there,
but
it
has
the
community
patterns
in
it.
So,
from
a
community
perspective,
the
goal
is
to
have
as
small
or
as
large,
of
a
get
Ops
building
block,
as
you'd
like
our
stuff
is
all
very
modular.
E
So
if
you'd,
like
storage
from
one
vendor
or
another,
you
can
pull
what
we
have
out
and
replace
it
with
what
you'd
like
very
easily
and-
and
it's
all
customizable
from
that
perspective,
Community
is,
is
driven
by
anyone.
It
is
a
sense,
a
community
if
you'd
like
to
add
something
in
there.
Please
feel
free
to
do
so,
and
work
with
us
engage
with
the
team
and
add
in
your
components
or
your
your
services.
E
C
C
So
it
could
be
410
49
411
for
12,
depending
on
when
we
started
off
the
pattern
and
then
we
we
test
it
on
all
three
platforms
for
those
specific
versions
and
all
the
different
products
that
are
the
sort
of
latest
on
that
version,
and
we
make
sure
that
as
new
products
come
on
board,
things
don't
break.
So
we
have
a
full
CI
process
that
Flags
us
through
slack
and
tells
us
hey
last
night.
C
This
thing
broke
because
you
know
there
was
an
upgrade
to
Kafka
or
something
like
that
or
our
open
shift
pipelines
or
something-
and
so
that's
really
important
too,
and
one
of
the
things
I
would
say
about
the
devsecops
one
which
is
kind
of
unique
is
that
we
are
CI
in
it
right
now,
because
it's
in
process
with
some
different
partners
and
customers.
We,
we
can't
really
say
it's
in
production
yet,
but
we're
anticipating
it
quite
a
bit.
B
C
Correct
so
the
idea
would
be
that,
for
example,
let's
take
the
devsecops
pattern.
If
there
was
a
tool
as
part
of
the
pipelines
that
you
wanted
to
swap
out,
maybe
it's
a
you
wanted
to
use
Claire
instead
of
something
like
stack
rocks
for
the
vulnerability
scanning
you
could.
You
could
swap
that
out
if
you
wanted
to
make
sure
that
that's
part
of
your
pipeline
tasks,
so
Johnny
did
you
want
to
add
to
that
too
yeah.
D
It's
the
idea
is
that
you
take
the
common
part
of
our
framework.
That's
that's
our
bread
and
butter
right.
That's
where
you
get
all
the
validated
pattern
stuff
out
right.
The
demo
sits
on
top
of
so
with
multi-cluster
dubstack
Ops
as
an
example
each
one
of
those
pieces,
you
know
like
you,
you
guys,
are
well
aware,
there's
a
tool
for
everything
and
if
there's
a
tool,
there's
probably
four
tools-
and
you
know
everybody
has
an
opinion
on
which
one
is
better.
B
And
okay
I
think
when
I
was
reviewing
all
the
code
and
everything
that
went
into
it,
I
think
just
the
sheer
scale
of
what
needs
to
happen
for
you
to
have
like
supply
chain
security,
everything
signed
and
validated
all
the
way
to
run
time.
It
was
kind
of
eye-opening,
so
I
think
part
of
those
patterns
really
gives
you
a
sense
of
what's
necessary
right
right.
C
It's
an
important
thing
that
Johnny
brings
up
too.
Is
that
a
lot
of
the
times
we'll
talk
about
a
specific
architecture
working
in
the
field?
We'll
say
hey!
This
worked
right,
but
without
the
code
behind
it,
it's
not
very
clear
how
it
worked
right,
and
so,
as
you
probably
know,
a
lot
of
The
Operators
that
we
use
today
are
often
quite
merely
installers
right
there.
C
You
deploy
the
operator,
but
you
don't
have
everything
that
you
need
to
be
up
and
running,
and
you
certainly
don't
have
it
integrated
with
things
and
so
part
of
what
patterns
is?
Is
we
we
can
install
things,
but
we
also
have
to
configure
them
within
the
architecture.
So
that's
what
I
was
talking
about
earlier
with
the
plumbing
there's
a
lot
of
handshaking
between,
particularly
if
you're
doing,
multiple
clusters
like
in
the
devsecops
one.
We
have
Hub
clusters
and
development
clusters
and
production
clusters
in
our
industrial
Edge
pattern.
C
We
have
you,
know:
data
centers
and
Edge
devices
out
on
factories,
Edge
clusters
on
factories.
So
when
you're
doing
that
sort
of
thing
there's
a
lot
of
like
hey,
you
need
to
have
this
API
link
and
you
need
to
have
this
secret
to
contact
me
and
here's
my
token
and
all
those
things
have
to
be
moved
around
and
so
with
a
validated
pattern.
We
don't
just
you
know,
bring
up
things
and
install
a
bunch
of
operators.
C
So
the
pattern
won't
fail
on
install
because
something
doesn't
exist
yet
right.
So
there's
a
lot
going
on
with
between
git
Ops
and
between
multi-cluster
management
and
secrets,
handling
and
API
URLs,
and
all
that
sort
of
stuff.
That
has
to
be
done
and
that's
what
we're
doing
with
the
patterns
and
validated
the
devsecops
pattern
is,
is
particularly
gnarly
right.
C
D
B
C
B
Yeah,
speaking
of
which
so
you
gave
us
the
whole
life
cycle
behind
validated
in
community
patterns,
we've
talked
about
the
multi-cluster
defsecops
pattern.
You
want
to
tell
us
what's
involved
with
it,
what
was
the
goal?
Because
I
know
I've
watched,
Jafar
work
on
this
for
two?
You
know
a
year
and
a
half
I
remember
when
we
first
got
acquired
stack
Crocs.
This
was
there's
Rumblings
of
this
getting
created
so
was
hoping
you
could.
You
know
talk
about
the
use
case,
trying
to
solve
and
all
the
pieces
that
are
involved
in
it.
C
The
hit
the
history
kind
of
behind
it
was,
we
were
looking
at
openshift
platform
plus
and
those
components
first,
and
we
were
saying
well,
okay,
what
is
open
source
shift
platform
plus,
and
it's
made
up
of
these
different
components,
open
data
foundation
and
Advanced
cluster
security
and
advanced
cluster
management
and
Quay
Enterprise,
and
we
were
saying
okay
yeah.
But
what
what
is
it
really
far?
And
then
we
were
looking
at
the
secure
supply
chain
or
Supply
chains.
Software
supply
chain
security,
which
is
there?
C
C
That's
why
we
have
to
go
after
and
so
assembling
the
opp
components
across
multiple
clusters
and
handshaking,
and
all
that
and
then
the
big
work
that
that
Jafar
and
Johnny
were
working
on
was
around
and
and
some
other
folks
as
well,
that
were
working
on
the
pipelines
within
the
development
environment
too,
which
I
think
is,
is
what
we're
really
focusing
on.
Today,
a
bit
Johnny
anything.
D
So
a
lot
of
times
we'll
see
where
a
customer
has
they've
bought
all
these
tools
right,
they
have,
they
bought
OPP
right,
but
they're
like
okay,
I
I,
now
don't
know
what
to
do
with
this,
and
so
the
idea
is
like
okay
well
here,
let
me
give
you
an
example
of
what
you
can
do
to
get
going,
it's
to
help
get
rid
of
the
empty
cluster
right
or
or
you
have
the
customer,
that's
they're
on
the
fence
about
buying
something
and
now
we're
like
hey.
Well,
here's
what
you
can
actually
do
with
this.
D
You
know
so
I
think
that
those
are
really
the
problems
that
we're
trying
to
solve.
Get
people
using
it
get
people
buzzword,
Bingo
here,
shifting
left
with
security
right
and
baking
things
in,
and
you
know
it
actually
making
that
real.
You
know:
I
was
on
a
project
a
couple
years
ago
with
the
Air
Force
and
they
were
real
big
on
this
devsec
Ops.
You
know
so
they
they
wanted
to
essentially
do
what
we're
doing
now
and
yeah.
D
C
C
I
need
and
kind
of
be
confident
in
the
tools,
but
they're
also
dealing
with
the
fact
that,
as
I
said
talked
about
earlier,
this
accelerated
CI
CD
space
with
things
like
containers
and
Automation
and
container
platforms,
and
all
that
good
stuff
people
are
becoming
very,
very
productive.
Pushing
things
want
to
push
things
to
production
as
fast
as
possible,
but
you
also
want
to
have
the
confidence
that
you
can
trust
what
you're
putting
into
production
and
so
by
using
git
Ops
by
using
devops
and
devsecops.
A
D
Yeah
I
I
think
you
know.
In
my
experience
right,
it's
been
the
vendor
lock-in
right,
like
that's,
that's
a
huge
huge
issue
with
people
as
vendor,
lock
and
so
I
think.
When
we
go
in
we
we
talk
about
like
Hey,
we're
Red
Hat,
open
shift.
You
know
at
the
end
of
the
day,
Red
Hat
open
shift
is
kubernetes
right.
It's
just
Enterprise
kubernetes,
but
if
you
look
at
the
tools
that
we're
using
throughout
the
pipeline,
we're
using
all
Open
Source
Products,
you
know.
D
So
if
you
look
at
like
within
the
actual
pipeline
itself,
we're
using
things
like
Nexus
Sono
son.
Excuse
me
sonar
Cube,
Gatling,
there's
all
kinds
of
tools
that
are
upstream
and
that
that
we
can
use
and
that
are
entertainable.
So
if
you
have
your
own,
then
you
could
use
that
as
well
and
the
other
part
is
it's:
it's
cost
right
and
that
kind
of
goes.
It's
not
synonymous,
but
it's
kind
of
like
it
goes
hand
in
hand
with
with
vendor
lock-in
right.
I
could
get
the
same
thing
for
free.
D
You
know
Downstream
or
I.
Could
you
know
I
could
pay
a
little
bit
less
for
this,
but
I
think
that
you
know
at
the
end
of
the
day
it's
a
matter
of
just
going
in
showing
what
we
can
do
with
you
know,
op,
p
and
and
the
tooling
and
say:
how
can
we
put
your
tools
on
this
pipeline
to
make
this
work,
but
yeah,
it's
I,
think
just
initially
those
are
the
big
ones
that
I
see
a
lot
like.
D
C
I
think
the
the
complexity
itself
can
be
very,
as
I
said
earlier,
can
be
very
daunting
and
the
Very
fact
that,
with
this
get
Ops
based
approach,
we
can
rapidly
deploy
a
complete
architecture,
all
wired
up
together
and
show
people,
the
different
components,
show
owners,
Partners
or
whatever
the
different
components
and
say
look.
This
is
not
out
of
your
reach.
This
is
something
that
can
be
done
for
you
in
an
automated
fashion.
C
You
can
maintain
you
can
Fork
from
the
patterns
upstream
and
essentially
then
make
your
your
changes
on
your
own
branches
as
needed,
and
you
can
get
again
we're
talking
about
life
cycle
here.
You
can
then
turn
around
and
continue
to
pull
down
components
that
you
think
would
benefit
you.
So
you
can
keep
in
sync
with
the
pattern
and
also,
if
you,
as
a
customer
partner,
see
something
that
the
pattern
could
benefit
from.
You
can
do
a
pull
request
and
bring
it
up.
So
we
want
a
community
around
this.
C
B
Yeah
thanks
for
that
guys,
just
as
somebody
who
deals
with
analysts
on
a
day
to
day
I
think
that
there's
a
big
disconnect
between
what's
implemented
and
practical
in
day-to-day
activities
and
then
the
bleeding
edge
features
that
are
being
requested.
So
I
really
think
it's.
The
the
pattern
has
really
driven
the
conversation
around
like
what
features
are
useful.
B
I
know
that
yeah
s-bombs
is
coming
up
in
ACS
and
stack
rocks
this
year,
and
a
lot
of
it
was
basically
because
we
need
to
make
sure
that
s-bombs
are
properly
taken
care
of
and
that
the
right
people
are
making
sure
that
you
know
that
we
can
map
these
to
vulnerabilities,
that
we
can
accurately
get
an
assessment
of
risk
without
just
chucking
information
in
right.
So
all
those
Integrations
and
those
practical
use
cases
help
feed
and
make
other
products
better
right.
It's
not
just
a
smorgasbord
of
Integrations
that
you
know.
B
C
I
when
I
heard
the
term
s-bomb
by
the
way,
I
was
like
what
is
this.
It
sounds
so
scary,
it's
like
me
and
then
I
was
like
looking
it
up.
Oh
it's
a
software
build
of
materials.
We've
had
these
forever,
but
the
difference
is
when
you've
got
a
rapidly
changing
CI
CD
pipeline.
That's
pushing
things
out.
You've
got
to
make
sure
that
your
bill
of
materials
is,
is
well
known
and
verified
and
signed,
and
all
that
good
stuff.
C
So
yeah,
that's
a
very
important
and
very
important
piece
of
this
and
the
Technologies
change,
but
I
think
that
the
the
the
the
value
of
the
patterns
is
that
we're
not
stuck
in
any
time
right.
We're
not
stuck
at
this
is
how
you
deploy
it
forever.
What
we're
saying
is
this
is
what
we're
deploying
right
now
with
the
tools
that
are
available
today,
but
we
believe
the
pattern
framework
allows
us
to
swap.
C
D
Our
heads
around
this
right
now
like
that
we've
got
some
serious
issues
and
if
we
don't
do
something
about
it,
then
we're
going
to
have
another
I,
don't
want
to
call
them
out,
but
we're
gonna
have
another
one
of
the
you
know:
Big
Supply
Chain
issues.
That's
going
to
affect
everybody,
you
know,
and
we
definitely
don't
want
to
be
in
the
news
for
that
and
nobody
does
right,
and
so
it's.
D
But
that's
that's
just
it,
though,
that
as
as
this
Tech
is
emerging,
it
is
coming
out
and
we're
getting
better
and
better
with
it.
That's
the
tooling
is
going
to
get
better
around
it
and
then
you
know
we're
gonna.
We're
gonna
have
better
standards,
because,
right
now
it
is
very
fluid.
So
just
hopefully,
hopefully,
we'll
have
something
concrete
soon.
D
B
Yeah,
so
with
my
marketing
hat
on
I'm
gonna
challenge
you
guys
to
to
come
up
with
your
best,
like
25
50,
word
segment
of
if
you
implement
multi-cluster
devsecops
pattern.
What
is
your
outcome?
Is
it
you
know
like
for
me?
It's
signed
and
authorized
build
to
the
build,
deploy
and
runtime
process
in
whatever
your
application
is
on
kubernetes,
or
something
like
that
right,
I'm
kind
of
because,
like
you
said,
some
of
the
parts
are
swappable,
you
don't
necessarily
need
to
do
enforcement
at
runtime,
so
I'm
kind
of
curious.
C
C
I'm
gonna
jump
in
yeah
I'll
jump
in
first,
because,
even
though
I'm
like
afraid
to
but
I
think
for
me,
it's
one
of
the
things
that
we're
seeing
from
a
practical
perspective,
particularly
with
some
of
the
our
system.
Integrator
Partners.
Is
it's
really
about
a
kind
of
time
to
value
for
customers
and
partners?
They
want
to
Implement
something
as
daunting
as
I
said,
as
this
multi-cluster
devsecops
environment,
with
development
clusters
and
production
clusters
and
central
control,
plane
clusters
and
that
sort
of
thing
they
don't
know
how
to
get
there.
C
With
that
context,
I
would
say
it's
really
about
an
automated
best
practices
for
getting
a
getting
supply
chain
security
for
your
for
your
software
in
a
automated
and
continuously
integrated
way.
Words
tested
Etc
that
that
would
be
for
me.
Anthony
might
have
a
better
a
better
product
manager
definition
not.
E
Sure
I
can
do
it
in
25
words,
that's
the
problem.
This
is
an
example.
I
mean
a
reference
architecture,
a
a
golden
build.
It's
a
way
to
do
this.
If
you're
an
admin
just
getting
started,
to
show
you
how
to
get
it
done
quickly
and
from
there
it's
modifiable
editable
to
do
it.
The
way
you
want
to
do
it
over
time.
C
Yeah
one
of
the
things
I'd
say
too,
is
that
and
I'm
gonna,
let
Johnny
Jump
in
on
the
pipeline
side,
but
a
lot
of
people
focus
when
it
comes
to
secure
supply
chain
just
on
the
pipeline
right,
and
they
say
these
are
the
steps
that
need
to
be
happening,
and
so
therefore,
maybe
I
need
to
install
these
sort
of
tools
along
the
way
or
they
need
to
be
available
in
some
way
right.
However,
the
pattern
is
more
about
is
also
about
making
sure
that
all
of
that
infrastructure
for
those
tools
is
available.
C
So
it
makes
sure,
for
example,
that
advanced
cluster
security
gets
deployed
on
a
main
Hub,
as
both
secured
and
a
central
Hub
right,
so
that
other
clusters
can
contact
it
for
cluster
security.
You
know
making
sure
it's
compliant
all
that
good
stuff,
but
also
for
call
out
for
vulnerability
scanning
Etc,
so
setting
that
up
is
complex
and
making
sure
it
connects
to
different
clusters
like
production.
Development
is
also
complex,
setting
up
a
central
registry
and
the
handshaking
between
something
like
Quay,
Enterprise
and
The
Quay
bridge
on
the
development
clusters
and
on
the
production
clusters.
C
C
D
So
that's
going
to
be
across
your
multiple
clusters
and
then
on
top
of
that,
it's
going
to
be
that
tooling,
that
you
want
integrated
with
that
Enterprise,
ready
infrastructure
and
then
now
your
processes
or
our
processes
that
you
can
you
can
adopt
or
not
will
be
available
to
you
for
your
builds
and
then
that
allows
you
to
promote.
We
don't
do
releases
in
this,
but
like
the
idea,
is
there
right?
Where
you
have
the
concept
of
going
from?
You
know
Dev
to
Stage
to
production
right
so
like
at
the
end
of
the
day.
D
B
C
B
Yeah,
that's
it's
interesting.
You
say
that
because
coming
from
The
Stack
Rock
side,
especially
pre-acquisition,
you
know
we're
coming
in
we're
taking
a
different
approach,
two
containers
and
container
security.
It's
a
new
paradigm
and
half
of
the
challenge
was
just
figuring
out
how
mature
certain
companies
were.
Did
they
have
a
process
where
all
the
applications
on
internally
were
following
the
same
build
system?
B
Because
if
that
was
the
case,
then
it
was
pretty
easy
to
implement
a
security
control
in
it
and
actually
do
it
at
scale
right
so
but
then
sometimes
you
come
in,
and
every
single
team
has
a
different
build
system,
they're
doing
something
different.
Well,
how
does
the
Securities
even
come
in
and
give
you
know
practical
advice,
Upstream
yeah.
D
B
Yeah
and
so
I
feel
like,
like
you,
said,
that
build
process
and
setting
a
standard
practice
for
hey.
This
is
how
we're
going
to
build
and
deploy
and
manage
at
runtime.
Well,
then,
now
you
can
bring
in
your
security
tools,
doesn't
have
to
be
ACS,
it
can
be
other.
You
know,
partners
that
we
have,
and
things
like
that
you
can
bring
those
in
and
make
their
controls
even
stronger
right.
It
makes
those
security
tools
perform
even
better
instead
of
focusing
on
the
marketing
features
of.
Let's.
D
Say
the
next
top
thing
right
and
to
me
the
thing
I
really
like
the
most
and
I
mean
there's
a
lot
of
things.
I
like
right,
and
this
is
just
I'm
a
fanboy
of
what
we
do.
Yeah
so
I
mean
it's
also.
You
know
a
thing,
but
you
know
we're
also.
We
also
want
to
involve
the
community.
You
know
and
I
think
that
that's
something
that,
like
from
a
red
hat
product
perspective,
like
that's
something,
that's
awesome
right.
D
D
B
Mm-Hmm
yeah
well-being,
open
source
and
freely
available
to
do
it
right,
I
think
yep.
That's
that's
one
of
the
big
advantages,
obviously
speaking
of
which
so
I
put
this
question
here,
I'm
trying
to
figure
out
exactly
how
to
word
it,
but
I.
Think
one
of
the
biggest
challenges
towards
like
the
next
step
of
that
build
process
is
the
efficiency,
because
I
think
you
know,
as
you
build
more
and
more
controls,
you're
also
slowing
down,
builds
a
little
bit
too.
You
know
you're
increasing
Cycles,
which
means
added
cost.
B
So
how
do
you
practically
fit
into
the
different
systems?
Is
it
like
hey,
let's
start
with
like
one
check
and
we're
going
to
limit
vulnerabilities
and
then
the
next
one's,
like,
let's
just
inform
just
to
make
sure
that
the
signature
from
the
bill
to
deploy
is
the
same
right.
You
know
what
are
some,
let's
say:
considerations
when
you're
thinking
about
implementing
a
strategy
like
this,
especially
around
efficiency,.
D
C
To
you,
yeah
I,
you
know
Johnny
and
I've
been
talking
about
this.
The
way
you
phrased
it
right
now
is
very
interesting.
That
question,
because
for
me,
I
would
not
have
looked
at
it
as
a
you
know,
starting
to
introduce
different
concepts
of
the
security
supply
chain,
one
at
a
time
I
would
have
looked
at
it
as
oh.
C
We
want
to
be
able
to
support
pipelines
that
are
kind
of
you
know
if
you
like,
open
shifts
instance
type
of
pipeline,
but
we
also
are
taking
advantage
of,
can
take
advantage
of
pipelines
as
code
which
allows
you
to
have
the
pipeline
as
part
of
the
git
repo,
where
your
application
is
as
well
but
I
I.
Think
to
this
question:
it's
I
I,
guess
you
could
pull
some
pieces
out
and
try
to
test
minimal,
but
I'd
be
more
inclined
to
go
look.
This
is
this
is
a
a
pipeline.
D
Yeah,
so
there's
some
things,
probably
that
we
do
like
right
away
right
like
there's.
There
are
certain
things
that
we
just
don't
want
in
the
builds
at
all
and
one
one
of
those
is
like
a
package
manager
right.
So
what
we'll
do
is
we'll
use
an
ACS
policy
that
will,
during
the
build,
go
out
and
say,
hey,
you've
got
RPM
or
you've
got
dnf
or
micro,
dnf
or
whatever
installed,
and
so
we'll
we'll
kick
that
out
in
the
build.
So
essentially,
what
we
want
to
do
is
we
want
to
have
that
image.
D
Come
up,
go
through
its
process.
Do
its
thing:
if
that's
something
that
like,
if
that's
what
our
organization
doesn't
want
right,
I
think
a
good
idea
is
we
don't
want
to.
We
want
to
reduce
the
attack
surface,
and
so
we
want
to
pull
out
that
package
manager.
So
all
right,
let's,
let's
go
ahead
and
rip
that
out
now,
let's
go
through
our
building,
essentially
like
we
do
go
through
and
test
each
one
of
those
tasks
like
to
okay.
Can
we
build
and
deploy
it?
D
This
way
are
my
scans
actually
catching
what
I
think
that
they
should
be
scanning
so
in
the
sense
of
the
pattern
and
reusability
I.
Think
that
that's
where
we're
adding
efficiency,
because
you
like,
when
you
take
this
Pipeline
and
you
run
it
you're
like
okay,
this
has
already
been
through
the
ringer.
This
is
in
CI
we're
testing
the
crap
out
of
this.
You
know,
but
the
other
thing
I
think
that
we
do
is
once
you
get
off
of
that
Hub
and
the
development
clusters.
D
We
really
start
to
right
size,
the
cluster
right,
so
we
really
want
to
make
sure
that
the
cluster
is
only
doing
what
the
cluster
is
supposed
to
be
doing.
So
we
might
have
like
an
ACS
secure,
that's
sitting
out
on
that
cluster.
So
that
way
we
can
scan,
but
then
it
should
only
be
that
application
that
we're
deploying
into
staging,
and
then
you
know
promoting
up
to
the
the
next
environment.
D
So
essentially,
we
might
have
a
big
cluster
up
front
and
it
might
cost
us
a
lot
up
front
and
and
either
development
or
resources,
but
as
we
get
further
and
further
along
and
closer
to
production
in
our
customer
that
that
actually
gets
smaller
and
smaller,
because
we've
right
sized
the
cluster
now
we've
only
got
the
resources
that
we
need
to
run
our
thing
and-
and
that's
really
it.
You
know-
I
mean
the
tooling
and
stuff
like
that.
We
test
it
and
you
try
and
make
it
as
easy
as
possible
to
reuse.
But.
C
And
obviously
the
the
more
application
workloads
you
can
put
through
this,
the
greater
efficiencies
and
in
terms
of
costs
that
you're
getting
right
like
this
is,
you
know,
probably
too
big
for
a
single
small.
You
know
app
right,
and
certainly
all
our
demos
are
now
right.
Our
demos,
like
you'd,
probably
look
and
go.
C
Oh,
my
gosh
pet
clinic
we're
doing
a
pet
clinic
and
we've
got
this
huge
infrastructure
to
support
it,
but
you
think
of
you
know
much
larger
applications
and
multiple
applications
and
applications
that
are
connected
together,
and
then
it
becomes
a
much
smarter
deployment.
Also
things
that
we're
doing
like
you
know,
concentrating
a
lot
of
the
central
control
on
a
single
cluster.
Having
different
development
clusters
are,
are
sharing
a
cluster
for
developers,
as
is
also
possible,
and
so
you
get
a
scale
there
for
develop
uppers.
C
You
know
they
all
have
they're
all
participating
in
the
single
pipeline.
That's
are
are
at
least
a
single
platform
with
pipelines
that
are
assured
and
tested
Etc,
and
then,
when
it
comes
to
production
environments,
those
are
very
important
to
be
right
sized
right,
so
they
could
be
even
single
node
openshift
or
they
could
be.
You
know,
potentially
we're
looking
at
patterns
that
are
where
the
edge
is
is
just
Rel
with
podman
and
stuff
like
that
as
well.
C
So
there's
a
lot
of
efficiencies
you
can
gain
from
this,
but
probably
right
up
front
you're,
gonna,
you're
gonna
take
a
little
hit
in
deploying
this
pattern
to
try
to
for
a
single
app
but
you're
going
to
have
to
do
it
to
try
to
like
once
you
get
it.
You
know
you
can
start
unloading
your
your
container
native,
your
Cloud
native
workloads
as
fast
as
possible.
B
Yeah
I
really
like
that.
You
touched
on
a
realistic
situation,
which
is
it's
gonna
hit
you
with
costs,
especially
if
you're
doing
a
migration
like
that
around
you
know
a
complete
reorg
container
security,
devsecops
approach,
I
think
a
lot
of
the
messaging
around
kubernetes
adoption
was
that's
going
to
be
cheaper.
It's
gonna
go
the
cloud
you're
going
to
deploy
faster
when
reality.
The
first
two
three
years
are
normally
never
like
that
right,
yeah,
but
and
I.
Think
part
of
this
pattern
is
to
say:
hey
everybody
get
on
the
same
page.
Here's
the
pattern!
B
Here's
the
build
process!
Also,
your
containers
don't
need
to
be
three
gigabits
in
size
because
I've
seen
that
right.
Yes,
so
it's
like
hey,
let's
strip
everything
out
and
then
that's
where
the
efficiencies
come,
and
it's
that
visibility
of,
like
across
teams
that
you
know
you're
you're,
you're,
shrinking
the
container
footprint.
At
the
same
time,.
C
It's
certainly
certainly
going
to
be
more
efficient
than
everybody
have
on
their
own,
their
own
virtual
machine
infrastructure
to
manage
their
own
apps
right
once
you
get
into
the
Container
environment
and
started
using
the
container
platform
you're
already
hitting
the
economies
of
scale
right,
but
the
you
know
turning
that
into
a
secure
supply
chain
with
all
the
components.
Yes,
that's
going
to
be
you,
you
need
to
start
getting
as
much
workload
on
that
as
fast
as
possible.
C
E
I
do
have
one
thing
really,
quick
from
these
patterns
and
other
patterns
for
perspectives.
We
do
have
a
sizing
guide
on
the
website,
so,
if
you're
really
looking
for
what
it
would
take
to
deploy
a
medical
diagnosis
or
the
the
devsecops
pattern,
you
can
go
onto
the
site
and
it
walks
you
through
both
the
installation
as
well
as
what
to
expect
just
to
try
it
out
and
approve
a
concept
environment
in
in
the
cloud
space.
D
One
thing
to
add
to
that,
too,
is
like
if
you,
because
if
you
brought
a
medical
diagnosis,
if
you
look
at
if
you're
going
out
and
you're
looking
at
these
patterns,
look
at
it
beyond
the
initial
demo
right.
Think
about,
like
a
medical
diagnosis,
is
it's
at
the
end
of
the
day,
it's
really
object.
Detection
right,
it's
using
a
AIML
pipeline
to
do
object,
detection,
but
then
you
know
images
well
how
what
else
could
be
doing
that
right
like
there,
we
could
be
looking
at
packages.
We
could
be
looking
at.
D
You
know
people
walking
through
machines
at
you,
know
the
airport
through
TSA
and
stuff,
like
that.
So
try,
try
and
think
use
cases
beyond
that.
You
might
not
be
like.
Oh
okay,
I!
Don't
care
about
x-rays
but,
like
you
might
care
about
object,
object,
detection
in
an
image,
but
the
industrial
Edge.
You
might
care
about
sensor
data
and
the
iot
devices
right
and
how
those
things
are
interacting.
We
have
ansible
Edge,
get
Ops
right.
How
do
I?
D
How
do
I
do
things
Beyond
and
or
how
do
I
do
things
Beyond
openshift,
you
know,
I
still
have
multiple
environments,
environments
I
may
have
a
VMware
environment.
I
may
have
a
bare
metal
environment.
How
can
I
manage
those
resources
within
openshift,
you
know
and
and
so
like
we
have
these
use
cases.
So
if
you
look
at
them,
that's
one.
It's
one
like
right
in
your
face
like
yes,
we
have
a
demo
for
that.
It's
awesome,
but
at
the
end
of
the
day,
how
do
I
take
that
and
how
do
I
make
that
work?
D
B
B
I
appreciate
it
and
we
appreciate
Johnny,
Anthony
and
William.
We
appreciate
you
coming
on
and
talking
about
the
community
pattern,
hopefully
validated
soon.
We'll
we'll
see
you
we'll
do
a
big
announcement,
then
until
then,
we
have
obviously
kubecon
next
month,
Summit
in
May
23rd
to
25th
and
ACS.
4.0
is
out
next
month
so
tune
in
to
the
show
on
the
the
fourth
Tuesday
and
yeah,
we'll
be
back
with
a
new
topic
and
new
people
other
than
that
Kim.
Take
us
away.