►
From YouTube: OpenShift Commons Briefing #136: Governance, Containers and Trust with ARRIS and Black Duck/Synopsys
Description
Guest Speakers:
Larry Brigman, Principal Software Engineer with ARRIS Group
Tim Mackey, Technical Evangelist at Black Duck by Synopsys
Host: Diane Mueller, Director, Community Development Red Hat Cloud Platform
Containers have restructured the way we think about our infrastructure, bringing development and operations teams closer together than ever before, and placing applications center stage in the infrastructure environment. Teams are massively scaling containerized deployments with Kubernetes and Kubernetes-based solutions, like Red Hat’s enterprise-grade container orchestration platform, OpenShift Container Platform. But in containerized deployments, because applications sit closer to the infrastructure, without an intervening hypervisor and host OS, application security is more important than ever. In fact, security remains among the most important barriers to container adoption. Issues of Governance, Trust and License Management are top of mind for companies like ARRIS Group with large deployments on OpenShift. Figuring out how to get the licenses of all the code within a container automatically and generate a proper attribution file are non-trivial in the new containerized world order.
Together Tim and Larry will have a conversation about the best practices and address some of these issues and others in this briefing.
Tim Mackey works within the Synopsys Software Integrity Group as a technology evangelist. He joined Synopsys as part of the Black Duck Software acquisition where he worked to bring integrated security scanning technology to Red Hat OpenShift and the Kubernetes container orchestration platforms.
A
Hello,
everybody
and
welcome
to
another
openshift
Commons
briefing.
This
briefing
came
out
of
a
conversation
that
I
had
with
Larry
and
Tim
at
red
hat
summit
that
can
may,
and
so
we're
gonna
do
a
slightly
different
format
today
than
we
usually
do.
This
is
going
to
be
a
bit
of
a
conversation
between
Larry
and
Tim,
because
Larry
Bregman,
who
is
the
principal
software
engineer
at
eros
group,
had
a
whole
bunch
of
conversations
and
thoughts
about
governance
and
containers
and
trusts
and
Tim.
B
So,
if
any
questions
come
out
of
that
happy
to
to
take
those
honest
as
we
go
forward
and
Thank
You
Larry
for
putting
all
this
together,
we're
going
to
try
and
if
you
do
have
a
little
bit
of
a
deck
in
here
and
we're
going
to
try
and
run
from
one
deck.
So
occasionally
we
have
to
revert
back
to
the
proverbial
click
next
of
the
world.
B
So
there's
gonna
be
a
couple
of
stats
that
we'll
have
throughout
the
slides
in
here
that
come
out
of
the
black
duck,
open
source
security
and
risk
analysis
report.
This
is
something
that
we
put
out
every
year
and
looks
at
the
inertial
audits
or
audits
of
commercial
software
that
the
on-demand
division
of
Blackduck
has
done
for
quite
some
time
now.
B
Last
year's
a
little
over
1,100
code
bases
that
we
looked
at
from
about
500
companies,
and
so
what
we
do
is
we
just
the
anonymized
data
out
of
that
and
put
it
out
there
and
anyone
who
wants
to
get
a
copy
of
it.
That's
actually
on
the
last
line.
You
can
go
click
a
lot
of
a
wee
little
form
on
there
and
we'll
happily
get
you
a
download.
If
that
doesn't
work,
definitely
feel
free
to
hit
me
up
and
I
will
get
you
a
copy,
no
big
deal.
So
let's
try
and
go
so.
B
Today's
applications
are
fundamentally
a
case
of
a
certain
amount
of
proprietary
code,
fairly
heavy
reliance
on
open
source
components.
Some
third
party
API,
is
it's
starting
to
become
more
of
a
mash
up
world
and,
of
course
my
application
is
behavior
in
configuration
is
going
to
be
different
than
Larry's
is
going
to
be
different
than
everyone
else's.
But
that's
fundamentally
what
the
application
looks
like
today,
and
the
CNC
F
put
out
a
analysis
of
their
landscape
application
last
fall.
The
basically
showed
that
their
quote
unquote.
B
Proprietary
code
represented
only
0.1
percent
of
the
actual
code
that
was
running
to
enable
their
containerized
node.js
based
solution,
and
so
that's
that's
a
pretty
typical
scenario
for
what
we
see
and
so
next
so
from
a
governance
perspective.
The
way
I
like
to
look
at
it
is
that
what
we're
really
trying
to
do
is
find
ways
to
mitigate
risk
as
we
move
through
a
software
supply
chain
that
we
effectively
aren't
the
people
who
are
left
holding
the
bag
so
for
pretty
much
everybody
who's
on
the
call
open-source
license.
B
A
B
Obligations
and
we
don't
try
and
create
too
many
weird
wonderful
versions
of
our
own.
The
fairly
straightforward
process
to
work
through
there's
also
open
source
security,
the
use
of
vulnerable
open
source
components.
That
was
something
that
came
to
the
fore
with
heartbleed
and
open
SSL
four
years
ago,
but
is
still
very
much
something
that
we
see
today
and
it's
as
you'll
see
in
a
later
slide
a
kind
of
ever-increasing
daunting
task,
something
that
I
refer
to
as
operational
risk,
which
is
really
the
identification
of
point
in
time.
B
Decisions
so
which
component
from
which
fork
of
which
distribution
channel
is
the
version.
That
makes
sense,
and
why
was
that
decision
made
how
our
patch
is
going
to
be
brought
in
who's,
going
to
be
monitoring
for
any
changes
in
functionality
or
API
versions
and
who's
actually
documented.
Whatever
the
security
response
process
for
that
project
might
be.
Obviously,
if
you're
getting
a
component
from
the
Red
Hat
container
catalog,
it's
going
to
have
a
pretty
mature
response
process
for
any
security
issues.
B
But
if
you
go
full
upstream,
your
mileage
definitely
does
vary
and,
as
I
alluded
to
earlier,
API
usage
is
something
that
we're
increasingly
seeing
where
it's
a
a
service
driven
or
an
anything
as
a
service
where
I
might,
for
example,
have
a
a
credit
card
processor,
or
something
like
that.
That's
third-party
to
me,
but
I
need
to
attend
to
well
what
data
is
actually
being
passed.
What
are
they
doing
with
that
data
if
they
change
the
contract
terms,
who
owns
compliance
associated
with
it
and
so
forth?.
B
And
so
that
fundamentally
gets
us
into
the
license
categories
that
we're
all
familiar
with
I'm,
not
going
to
go
into
this
in
great
detail,
except
to
say
that,
from
a
global
perspective,
the
permissive
licenses
that
we
are
familiar
with
the
reciprocal
licenses
that
we're
familiar
with
they
may
not
necessarily
map
out
when
you
start
looking
at
things
like
whatever
the
the
legal
requirements
are
in
your
particular
geography.
So,
for
example,
a
public
domain
license
is
a
concept
that
can
exists
cheerfully
in
the
US,
but
may
not
exist
in
other
countries
and
so
uncertain
unknown
licenses.
B
Those
are
the
ones
you
really
need
to
pay
attention
and
for
practical
purposes.
All
of
these
things
ultimately
get
triggered
by
a
distribution.
So
obviously,
if
you're
working
on
a
project
internally,
there's
not
really
a
distribution,
that's
happening.
If
you're
creating
something
that's
going
to
be
used
internally
by
your
employees,
that's
not
really
a
distribution
either.
You
start
to
bleed
over
into
other
license
types.
When
you
create
an
application,
it's
going
to
be
used
in
a
SAS
framework.
B
If
you
have
a
conglomerate
of
companies,
you
may
or
may
not
have
a
distribution
depending
on
what
the
actual
usage
is
and
where
it's
being
used.
Similarly,
contractors
and
suppliers,
that's
something
to
attest
to
and
for
practical
purposes.
Most
IP
attorneys
within
an
organization
are
going
to
be
familiar
with
the
core
concepts
of
what
to
use
when
to
use
it
and
why
to
use
it.
But
things
do
change
and
Larry
if
you
want
to
click
Next.
One
of
the
things
that
surprised
me
caused
me
to
start
thinking
a
little
bit
differently.
B
Last
year
was
when
someone
asked
the
question.
So
what
does
it
mean
to
actually
push
an
image
to
docker
hub
and
so
I
thought
about
it
for
a
second
and
fundamentally,
if
you're
pushing
an
image
to
any
public
repository,
you've
effectively
distributed
that
binary,
and
so
that
means
that
whatever
the
obligations
are
that
are
associated
with
the
licenses
inside
or
for
the
komak
and
components
inside
that
image,
those
become
your
joy
of
ownership,
and
so
you
need
to
start
paying
attention
to
those
details
and
from
our
audit.
B
One
of
the
things
that
we
saw
was
that
those
code
bases
85%
of
them
had
some
form
of
license,
conflict
or
unknown
or
uncertain
license,
and
more
alarming.
From
my
perspective,
was
that
44%
of
them
had
some
form
of
GPL
conflict
in
play,
and
so,
as
the
complexity
of
software
grows,
being
able
to
meet
those
obligations
is
a
key
challenge.
C
So,
to
give
you
a
context,
eros
typically
has
been
a
hardware
company
and
a
lot
of
stuff.
Their
software
is
a
secondary
piece
of
their
hardware.
It's
ridiculous
in
that
hardware,
but
now
we're
moving
into
providing
services
and
applications
to
our
customers
so
we're,
and
in
that
case,
we're
needing
to
build
applications
that
can
be
run
in
a
multitude
of
places
like
on
kubernetes
and
OpenShift,
which
means
we
have
to
do
it
in
containers
and
we
need
to
be
able
to
move
quickly
in
that
aspect.
C
C
So
I
understand
there's
licenses
and
the
piece
with
a
container
it.
It
becomes
more
like
a
Linux
distribution
or
a
mini
Linux
distribution,
because
you
have
to
acknowledge
everything.
That's
in
there
and
Tim
Tim
mentioned
it
in
his
slide
when
it.
When
do
we
have
to
meet
those,
and
he
says
when
we
push
it
when
when
we
make
that
distribution.
So
if
it
went
to
a
public
repository
or
a
customer
site,
we're
now
required
to
make
those.
B
Unfortunately,
for
everyone,
the
story
didn't
get
any
better,
so
IBM
published
their
data
set
for
the
2018
looking
back
at
2017
last
Wednesday,
and
they
found
that
in
the
US,
the
cost
of
the
data
breach
went
up
to
seven
point.
Nine
million
lost
business
went
up
to
four
point
two
and
the
average
time
the
identifying
container
breach
grew
by
45
days.
B
Now
they
also
put
in
a
little
bit
of
a
footnote
and
said
that
they
removed
mega
breaches
like
Equifax
from
this
data
set,
and
so
the
overall
cost
of
a
mega
breached,
such
as
what
would
seem
with
Equifax
simply
is
not
part
of
this
data,
but
click
Next.
One
of
the
things
that
we
can
say
is
that
the
Equifax
breach
really
focused
attention
on
what
open
source
does
role
in
modern
technology.
Stacks
was
all
about.
B
I've
had
quite
a
number
of
conversations
with
people
over
the
course
of
the
last
eight
nine
months.
That
start
out
with
should
I
keep
using
Apache
struts.
It
should
struts,
be
part
of
my
environment.
Should
I
move
on
to
something
else,
and
while
it's
a
fair
thing
to
continually
reassess
those
frameworks,
just
because
one
organization
has
a
breach
or
there
happens
to
be
a
vulnerability
in
one
framework,
doesn't
mean
that
the
next
version
of
the
framework
or
another
framework
isn't
equally
at
risk.
B
It's
all
comes
down
to
how
you
manage
software
in
your
environment,
whether
it
be
some
internally
generated
code
or
a
dependency
on
an
open
source.
Stack
like
Apache
stress
so
fundamentally,
struts
is
as
good
as
it
ever
was,
and
will
continue
to
be
so,
and
the
community
is
very
active
there
and
that's
the
kind
of
thing
that
we
want
to
be
able
to
see
next.
B
Those
vendors
have
a
way
to
push
that
information
into
an
organization,
but
when
it
comes
to
open
source
and
it's
exactly
the
opposite,
open
source,
we
click
Next
is
all
about
being
able
to
engage
with
the
community.
If
the
community
doesn't
know
that
you've
downloaded
their
component,
they
have
no
way
to
alert
you
to
having
a
new
security
update,
a
new
patch
new
hotfix,
maybe
end-of-life
and
a
version,
and
so
community
engagement
becomes
quote.
Unquote.
B
The
cost
of
ownership
in
the
procurement
model
that
needs
to
work
make
the
overall
security
posture
of
an
open
source
environment
a
more
efficient,
but
next,
and
so
this
is
one
of
the
things
that
we
saw
last
year
as
well,
that
78%
of
the
code
bases
had
at
least
one
vulnerability,
but
there
were
an
average
of
64
vulnerabilities
in
each
codebase.
That
was
an
increase
of
134
percent
over
what
we
saw
in
2016.
B
So
the
report
looks
at
the
2017
data
54%
of
the
vulnerabilities
that
we
found
had
high
risk
vulnerabilities,
but
the
more
alarming
snap
for
me
is
that
the
average
age,
those
vulnerabilities,
was
nearly
6
years,
but
we
have
a
major
long-tailed
problem
on
our
hands
as
an
industry
that
needs
to
not
work
its
way
into
containerized
deployments
that
the
traditional
app
awareness
model
needs
to
change.
So
traditional
security
analysis
is
fundamentally
blind
to
the
way
that
open-source
works.
B
We've
got
a
lot
of
tools
that
are
out
there
that
can
do
a
static
analysis,
looking
for
bad
code
patterns
or
fuzz
api's.
Those
are
all
generally
things
that
are
going
to
be
focused
on
the
code
that
is
created
within
an
organization,
vulnerability,
analysis
or
software
composition.
Analysis,
that's
determined
that
the
Gartner
folks
like
to
use
is
looking
at
what
is
the
risk
associated
with
any
of
the
dependencies
that
are
coming
in
then
last
year
there
were
over
14,000
new
disclosures,
that's
roughly
40
a
day.
B
But
next
they'll
give
a
couple
examples
for
a
container
design.
First
thing
that
we
start
out
with
is
determining
what
is
our
base
image
and
we're
going
to
decide
what
components
are
going
to
come
along
for
the
ride
and
then
we're
going
to
assemble
them
when
we
do
a
docker
build
that
image
is
then
going
to
be
sent
off
for
tests.
So
we
can
use
the
fact
that
the
image
itself
is
a
reusable
component
to
facilitate
our
testing
environment.
B
C
So
this
comes
back
to
the
point
of
knowing,
what's
in
your
container
and
part
of
that
it
becomes.
What's
you
know
your
application
very
well
and
its
dependencies,
but
you
don't
necessarily
know
what
is
in
your
base
container
and
your
if
you're
doing
a
distribution
of
that
container
and
knowing
license
obligations
as
most
development
teams.
Do
you
also
need
you
own
that
container
because
you're
distributing
it,
you
need
to
figure
out
where
to
obtain
patches
and
fixes,
and
the
like,
before
everything
in
that
container.
C
So
the
piece
here
is:
what's
the
team
to
do
it's
really
there's
containers
kind
of
bring
a
new
paradigm
to
this
development
model
that
has
a
lot
I.
Think
what
we're
going
to
present
here
is
very
typical
use
cases,
use
of
public
containers
and
base
containers
and
the
the
real
question
overall.
Is
what
of
this?
Can
you
trust.
B
And
so,
when
we
look
at
trust,
we
need
to
actually
take
a
little
bit
of
a
step
back
and
say
what
can
go
wrong.
So
the
first
thing
that
we
need
to
identify
is
who
actually
owns
that
base
image
and
what
did
they
put
in
there?
We
need
to
identify
what
the
health
of
that
base
image
might
be.
So
the
Red
Hat
container
catalog,
for
example,
has
a
health
metric
associated
with
any
image
that
can
come
from
their
public
registry.
B
The
information
that's
in
there
that's
similar
to
a
certain
degree
to
what
you
can
get
from
some
images
that
are
in
docker
hub.
But
not
all
registries
are
created
equal.
Not
all
registries
are
producing
the
information
in
the
same
manner
and
there's
not
as
much
transparency
as
to
how
that
in
health
metric
is
being
calculated
plus
when
you
go
to
do
a
docker
pull.
B
There's
no
mechanism
in
that
protocol
to
actually
say
I
want
the
healthy
version,
not
the
one
that
is
a
little
bit
behind
now
when
you
create
the
image,
you're,
updating
it
at
Build
time
and
there's
cash
aspects
that
come
in
there.
You
trust
your
build
servers.
You
have
to
start
asking
questions
around:
how
can
containers
start
in
the
environment,
who's
responsible
for
who's
responsible
for
modifying
container
images?
If
that
base
image
registry
goes
away,
do
you
have
the
facilities
in
which
that
you
can
rebuild
it
if
you're
basing
things
on
tags?
B
What
happens
if
the
owner
of
that
image
decides
to
remove
that
tag,
because
those
are
human,
modifiable
components
when
security
disclosures
happen?
What
are
the
process
to
determine
impacts
and
so
forth?
These
are
all
steps
that
are
part
of
establishing
the
trust
of
the
application
when
it's
deployed-
and
we
quite
simply
don't
have
enough
time
to
go
through
every
one
of
these
in
detail.
But
we
have
a
couple
of
examples
to
talk
through.
B
B
So
anything
that
was
patched
between
six
weeks
prior
and
seven
days
prior
is
captured
in
that
yum
update.
But
every
security
update
from
the
point
of
that
cache
creation
forward
is
simply
not
applied.
We
don't
have
necessarily
visibility
into
what
the
vulnerability
state
of
any
of
the
files
that
were
copied
in
two
days.
B
Prior,
but
you
can
see
here
an
example
of
how
the
image
cache
mechanism
inside
the
docker
engine
can
pollute
your
expectations,
because
if
you
look
solely
at
the
docker
file,
you'll
see
that
the
actual
steps
that
you
would
expect
to
have
to
deploy
a
good
application.
They
all
exist,
but
the
docker
cache
in
this
instance
kind
of
caused
it
to
go
off
the
rails.
Look
next.
B
Another
example
is
what,
if
I
want
to
pull
images
and
I'm
going
to
use
one
of
the
three
models
for
pulling
that
image
I
can
either
pull
it
by
latest
I
can
pull
it
by
a
tag.
So
in
this
case,
I've
pulled
latest
I'm
scaling
it
to
two
replicas
I
have
two
of
whatever
latest
is
if
I
now
pull
by
a
tag
of
101
and
scale
that
up
I
now
have
two
replicas
of
that,
and,
let's
just
assume
for
the
sake
of
argument
that
they
happen
to
be
the
same
thing.
B
I
can
then
go
and
pull
by
the
fully
qualified
pull
spec
I
end
up
with
that
Shaw
one
two
three,
four
five
and
I
can
scale
that
up.
I
can
then
also
go
and
delete
the
tag
and
scaled
one.
Oh
one,
two
three
replicas,
and
the
reason
that
this
works
is
that
the
local
docker
engine,
if
the
pull
specification
for
the
image
says
that
it
can
use
the
cache.
Well,
it
already
has
it
in
the
cache,
so
it
can
scale
it
up.
B
B
B
That
I
intend
to
use
for
a
be
testing
for
my
for
my
patch
mechanism,
I'm,
going
to
define
a
strategy,
that's
going
to
roll
forward
and
I'm
going
to
maybe
have
an
automated
patch
mechanism.
That's
going
to
detect
that
there's
a
new
update
and
I
want
to
move
this
for
and
in
principle
this
seems
like
a
really
good
idea
until
you
look
at
the
patch
history
itself,
and
so
if
you
click
Next,
here's
what
the
patch
history
for
Apache
struts
look
like
for
the
2.3
series
over
the
course
of
the
last
little.
B
B
So
we
click
Next,
a
better
model
might
be
to
have
a
description
that
says.
Apache
struts
is
a
Model
View
controller
that
has
a
plug-in
architecture
supporting
rest
and
Ajax
in
JSON.
The
affected
versions
of
Apache
struts,
including
these
versions
in
this
using
an
extreme
handler
for
D
serialization,
can
result
in
remote
code
execution.
B
Successful
exploitation
of
the
flaw
can
enable
a
hacker
to
gain
full
control
of
the
affected
server,
and
also
we
click
Next
include
information
that
says
something
to
the
effect
of
is
possible
for
some
rest
actions
to
stop
working
because
of
applied
default
restrictions
on
available
classes.
In
such
cases,
please
investigate
the
new
interfaces
that
were
introduced
to
allow
new
class
restrictions
per
action,
so,
in
other
words,
functional
change
is
correct
it.
So
this
type
of
information
flow.
It
is
important
to
successfully
patch
things
and
we
click
Next.
C
So
we're,
finally
getting
to
the
scenarios
that
I
guess
most
teams
will
end
up
doing
Tim
had
a
slide
earlier
about
saying
just
like
1%
of
the
total
application
is
proprietary
code
turns
out
that
you,
this
is
a
piece
of
your
application,
you're
going
to
be
using
something
like
in
flux,
our
Prometheus
from
your
perspective,
there's
no
value.
Add
except
I
need
that
service,
so
you
provide
a
public
public
container
and
there's
no
modifications
to
that
container
image.
C
There's
no
insertions
we're
only
using
some
configuration
to
say
what's
needed
to
say
what
ports
and
whatnot
for
our
application
usage.
So
we're
going
to
be
pulling
this
from
an
external
registry
and
it's
not
being
distributed
with
our
application.
So
what's
what's
the
issues
here?
What's
the
benefits
and
drawbacks
for
using
this
type
of
thing,
though,
the.
B
The
scenario
that
that
I
look
at
with
this
is
I'm
simply
referencing,
this
inside
of,
say
a
template.
This
is
an
image
that
I
want
to
have.
I
now
have
triggered
a
from
a
governance
perspective,
a
point-in-time
decision,
I'm
going
to
be
using
this.
This
version
of
a
component
and
by
extension,
I,
should
have
something
that
says
how
it's
going
to
be
managed
and
maintained
effectively
a
runbook
associated
with
it.
B
That
can
create
a
governance
issue
on
the
license
obligation
side,
but
there's
also
the
security
side
that
stock
image
was
produced
by
somebody,
and
it
may
be
quote
the
official
image
as
determined
by
docker
hub,
but
by
extension
it
doesn't
necessarily
give
you
any
clarity.
As
to
what
could
be
in
that,
and
what
the
the
components
and
associated
risks
might
be,.
C
All
right,
so,
let's
go
on
to
a
variation
of
this
same
scenario
and
I'm,
not
sure
it
really
makes
any
difference,
but
similar
public
container
we're
going
to
be
using
something
like
key
cloak
or
maybe
even
open
shift.
We're
not
going
to
modify
anything
we're
just
going
to
provide
a
overlay
to
change
the
visual
representation.
C
We
need
to
put
make
it
look
sort
of
like
our
application
and
we're
doing
this
from
external
of
the
image
via
config,
Maps
or
mounts
or
Annette
containers,
and
we're
doing
this.
The
same
way
as
the
previous
scenario
we're
pulling
it
from
an
external
repository
not
into
our
stuff
or
it's
deploying
at
the
application.
Runtime.
B
B
The
canonical
example
for
me
would
be
if
this
happened
to
be
a
UI
framework
that
was
licensed
under
a
GPL.
The
fact
that
we've
created
a
theme,
whether
we're
mounting
that
by
volume,
Mouse
or
otherwise
now
could
be
a
scenario
where
that
theme
needs
to
be
redistributed,
and
so
we
have
to
have
a
level
of
awareness
for
what
the
license
obligations
are
within
the
container.
We
have
the
same
concerns
about
security.
B
B
So
let's
say
that
there
was
a
this
was
simply
a
UI
framework
that
was
licensed
under
a
GPL
and
a
GPL
says.
The
entire
experience
is
something
that
needs
to
be
made
available
in
source
form.
The
fact
that
we
have
skinned
this
in
some
way
to
make
it
look
like
ours
becomes
now
the
obligation
that
needs
to
be
met
on
our
part.
Ok,.
C
Nothing
on
so
we're
going
to
provide
a
public
service,
we're
going
to
use
a
public
container
again
we're
not
going
to
actually
modify
the
actual
running
code,
but
we
have
to
the
docker
scripts
themselves:
didn't
do
a
good
job
of
managing
best
practices.
So
it's
not
running
in
an
open
shift
correctly
without
changing
the
security
model.
So
we're
going
to
fix
that
by
put
changing
the
startup
scripts
only
and
user
mappings
such
that
we
can
run
it
as
a
run
any
still
pulling
from
a
public
repository
doing
the
runtime
deployment
of
this.
So.
B
In
this
variation,
what
we're
looking
at
is
an
image
that,
for
example,
had
a
hard-coded
user
of
some
form,
and
you
want
to
go
down
the
path
of
we
care
about
modifying
the
security
context
with
an
open
shift
or
we
we
want
to
modify
the
image
itself
because
it
becomes
slightly
different,
depending
on
which
path
that
we're
permitted
to
go
down.
Yeah.
B
B
There
are
two
ways
of
solving
this
the
one
way,
and
this
would
of
course
require
security.
Approvals
from
from
the
governance
folks
would
be
to
create
a
namespace
specific
for
this
application
that
allows
for
that
elevated
security
context
and
has
additional
monitoring
in
place
to
ensure
that
no
bad
things
are
going
to
happen.
In
other
words,
there
are
compensating
controls
for
this.
That's
going
to
be
obviously
an
internal
conversation,
and
it's
going
to
potentially
expose
that
cluster
to
of
additional
risks
in
the
event
of
compromise.
B
The
second
option
is
to
go
and
effectively
use
that
public
container
as
if
it
was
a
base
image
and
then
add
some
additional
layers
that
are
going
to
modify
whatever
the
user
mapping
security
mappings
are,
and
that
becomes
the
entity
that
we've
deployed
the
moment
that
we
now
deploy,
that
that
becomes
our
image
and
the
obligations
that
are
part
of
that
base.
Image
need
to
also
be
met
by
us,
and
so
we
now
are
triggering
additional
life
governance
issues.
C
So
this
is
probably
the
most
typical
for
distributing
applications.
We'll
use
a
base
container
as
our
starting
point
and
we'll
put
our
application
tendencies
into
the
container
and
then
when,
when
we
send
that
out,
we'll
insert
the
configuration
at
runtime
typical
standard,
docker,
OpenShift
kubernetes
model.
B
Yeah,
in
this
case,
you
definitely
you're
owning
a
lot
here,
but
a
lot
of
risk
is
also
being
transferred.
So
whatever
that
base
container
image
is,
if
you
can
get
something
that
is
coming
from
a
very
trusted
source
like
say,
a
fedora
base
image
or
a
sent
to
us
or
a
releves
image.
You
know
that
that
distribution
channel
is
more
trusted
than
if
you
get
Tim
and
Larry's
great
and
wonderful
OS
bundle,
because
lord
only
knows
what
we've
put
in
there
and
we've
what
our
objectives
were,
even
though
it
may
work
for
the
requirements.
B
It's
not
not
the
way
that
you
want
to
be
building
your
base
images,
because
the
risks
that
we've
created
get
transferred
downstream,
and
so
that's
that's
the
whole
supply
chain
risk
model
and
where
you
want
to
be
holding
as
little
of
the
the
overall
risk
as
possible.
So
in
this
case,
if
you
take
a
public
base
image
from
a
very
trusted
source
and
then
you're
adding
your
application
and
your
dependencies
that
are
in
there,
obviously
your
application
is
going
to
have
its
instead
of
obligations
that
can
be
met.
That's
more
of
a
traditional
governance
model.
B
The
distribution
of
that
container
image
is
obviously
going
to
trigger
license
obligations,
and
so,
if
something
hasn't
been
met
in
that
base
image,
then
we
may
be
on
the
hook
to
to
attend
to
it,
depending
on
what
our
customer
expectations
are.
But
the
overall
security
is
now
an
amalgam
of
what
that
base
images
and
what
our
applications
requirements
are.
C
C
B
B
B
If,
on
the
other
hand,
you
can
work
with
a
a
language
like
say
golang
that
allows
you
to
compile
the
entire
application
into
a
single
binary
you're
now
in
a
much
more
manageable
space,
because
your
entire
term
image
might
actually
consists
of
a
couple
of
configuration.
Files
may
be
some
form
of
TLS
certificate,
bundle
of
one
form
or
another,
and
then
the
golang
binary.
B
So,
at
that
point,
building
from
scratch
doesn't
necessarily
have
the
the
management
overhead
that
it
could
have
if
you
have
to
go
and
determine,
for
example,
what
are
the
actual
true
dependencies
this
have
ocation
has
when
it
comes
to
the
JVM
s,
dependencies
on
user
space
components,
and
so
that's
that's
precondition
number
one.
Maybe
the
maybe
the
language
choice
is
something
that
needs
to
be
revisited.
B
You
may
be
in
a
position
where
going
full
upstream,
for
these
components
is
going
to
be
the
right
answer,
and
so
this
scenario
number
for
this.
This
is
definitely
one
that
I
like
as
I
mentioned.
I've
done
this
a
few
times,
but
I've
done
it
more
successfully
with
golang
than
I
have
with
other
environments,
just
because
of
the
ability
to
compile
to
a
single
single
binary,
Tim.
A
Tim
this
is
Diane
I'd
have
to
ask,
was
when
someone
says
from
scratch:
I
start
scratching
my
head
and
just
want
to
qualify
or
ask
you
from
your
perspective.
So
at
Red
Hat
we
have
something
called
certified
container
catalogs,
so
we
have
a
container
that
is
a
relic,
the
middleware
images
and
you
know
H
a
proxy
images
and
there
when
you're
sayings
from
scratch
here
you're
not
saying
or
are
you
saying,
build
Linux
from
scratch?
C
Actually,
what
the
question
here
is
that,
what's
the
difference
between
this
scenario,
this
number
four
and
number
three
so
number
three
is
like
what
you're
talking
about
is:
where
were
we
would
pull
a
certified
image
from
red
hat
or
CentOS
and
then
put
our
stuff
on
top
of
it,
and
this
case
we're
not
pulling
anything
from
a
public
repository.
We
may
replicate
the
docker
file
to
build
the
container,
but
we
will
build
everything
that
are
build,
that
container
ourselves
and
not
reference
external.
B
So
the
there's
a
within
the
docker
file,
the
first
line
is
always
from
something,
and
so
you
can
create
one
that
is
from
scratch
and
scratches
effectively
the
the
null
container.
The
null
base
image,
though
you're,
effectively
saying
from
nothing.
It's
going
to
start
with
a
zero
bite
layer,
and
then,
at
that
point
the
decisions
are
all
yours
to
make
for
good
or
for
bad.
D
A
B
So
what
we'll
want
to
do
is
any
api's
that
are,
there
will
run
through
those
professors,
any
type
of
static
analysis
that
we
can
do
we're
going
to
run
through
that
as
well.
We'll
make
certain
that
we
have
all
of
the
the
the
dependency
mapping
in
place.
So
we
know
where
we're
getting
things
from
so
we
again
taking
the
goaline
concept
that
we
don't
end
up
in
vendor
madness
and
end
up
being
dependent
upon
something
that
was
from
somebody's
random
fork,
as
opposed
to
true
upstream.
D
B
That
way,
you
never
blindsided,
but
importantly,
in
the
event
that
something
is
to
be
rolled
back,
that
you
have
a
way
to
understand
what
the
current
state
of
the
system
is.
We
also
recognize
that,
if
you're
running
a
production
cluster,
you
don't
need
another
console
in
there.
So
we
want
to
annotate
the
pods.
B
So
our
developers
are
going
to
do
what
developers
do
build
systems
are
going
to
do
what
build
systems
do
and,
of
course,
risk
assessment
is
performed
at
build
and
throughout
many
stages
of
the
build
pipeline
itself
and
in
test
automation.
They
all
have
feedback
mechanisms
into
defect
tracking
system,
but
once
this
deployment
occurs
in
a
docker
push
occurs
and
it's
now
in
a
production
environment.
The
traditional
mindset
is
well
that,
because
this
continuous
monitoring
piece
becomes
somebody
else's
problem.
B
B
We
don't
need
to
go
and
throw
an
agent
into
every
running
container
or
for
that
matter,
put
an
agent
on
every
host
when
we
know
that
the
container
image
is
immutable,
but
let's
use
that
property
and
move
forward
with
it.
So
that's
that
some
of
our
thinking
behind
how
to
bring
things
at
true
scale
into
an
open
shift
environment
I
think
this
might
be
our
last
slide.
Yeah.
C
The
piece
that
I'm
taking
away
from
this
is
as
you're
building
your
pipeline,
your
build
package
and
test
automation
has
a
tendency
to
get
more
complex
because
you
need
to
have
that
risk
assessment
piece
with
the
feedback
loop
which,
in
traditional
build
environments.
You
may
be
doing
that
with
static
analysis
and
code
coverage
like
things,
but
this
is
a
new
area
when
you're
doing
containers
that
has
to
be
added
on
top
of
things.
Yeah.
B
So,
for
example,
we
have
one
customer
whose
view
of
the
world
is
that
every
single
container
image
needs
to
be
monitored
in
perpetuity
or
for
seven
years.
Whichever
comes
first
and
that's
an
enormous
amount
of
data
to
have
for
things
that
were
just
a
simple
typo
that
got
fixed
and
there's
now
a
redo
of
a
docker
build,
so
I
think
that
overall,
the
governance
models
are
still
evolving
when
it
comes
to
container
deployments
and
will
probably
be
still
able
to
have
a
discussion
like
this
next
year.
A
An
awesome
job
Larry
of
like
getting
the
questions
answered
and
and
I
really
appreciate
it.
There's
one
other
question
that
keeps
popping
up
in
the
chat
and
and
the
other
Diane
Diane
Fatima
has
asked
it
a
couple
of
times
in
different
ways
and
she's
still
wondering
if
anyone-
and
this
might
be
the
old-school
way,
does
bit
for
bit
checks
on
public
repositories
to
make
sure
that
they're
not
being
corrupted.
You
know
and.
B
What
I'm
seeing
is
that
it's
more
akin
to
I
don't
want
to
be
in
a
position
where
something
could
change
the
configuration
of
the
public
repository
somebody
could
go
and
delete
the
image
reference
that
sort
of
thing
so
I'm
going
to
effectively
bring
a
copy
into
whatever
I'm,
using
for
my
docker
registry
or
my
binary
repo.
So
at
least
I
know
that
worst
case
I've
got
a
copy
of
this
thing.
That's
quote
known
good
and
that's
one
of
the
point-in-time
risks
that
we
try
and
identify.
D
Background
and
with
scientific
data
like
climate
data,
you
periodically
check
to
make
sure
all
the
bits
are
exactly
what
they
were
before,
and
so
they
do
bit
for
bit.
Checks
and
I
know
people
say
other
things
are
good
enough.
You
know
like
check
sums
and
whatever
is
good
enough,
but
is
it
really
good
enough
and,
like
so
I'm
just
wondering
like?
Is
there
a
company
out
there?
That's
doing
this
for
the
public
repositories
and
saying
you
know
this.
This
image
really
is
exactly
what
it
was.
You
know
last
year
or
yesterday,
or
something
like
that.
D
C
This
is
kind
of
I've
been
using
the
tool
that
ships
with
OpenShift
and
I
don't
know
how
to
pronounce
it.
It's
sk
o
peo
that
actually
allows
you
to
inspect
a
container
scope,
EO
the
inspect
the
container
metadata,
and
you
can
use
that
it'll
give
you
the
digest,
which
is
a
sha-256,
and
it
will
also
expand
out
all
the
layers
with
a
sha-256
with
that
and
a
copy
of
your
piece,
maybe
I'm,
making
an
assumption
that
the
shop
256
is
mu
is
hard
to
replicate.
C
D
B
D
A
B
A
So
I
think
that
that
that
would
be
a
topic
for
another
open
ship
commons
briefing
to
get
someone
to
dive
deep
into
that
from
the
scope,
EO
team
and
and
how
an
the
damon
stuff
is
I
think
they're
yeah
that
clarifying
that
would
be
great
and
we
are
at
the
end
of
our
hour.
So
I
want
to
respect
people's
time
here,
and-
and
thank
you
guys
for
for
doing
this-
I
don't
see
too
many
more
questions
or
any
more
questions.
A
Sorry
I
spelt
it
wrong,
go,
go
Bo,
SK,
ope,
oh
and
I'll
get
someone
to
come
and
do
a
deep
dive
on
scope,
EO
and
and
talk
about
what
the
dr.
Damon
is
actually
doing
when
it
closed
it
in
because
I
think
we
need
to
clarify
that
a
little
bit
better
and
we've
got
some
definitely
Dan,
Walsh's
type,
folks
out
there
who
can
come
in
and
deep
dive
on
that
and
there's
a
gentleman
I'm,
pretty
sure
he's
in
Italy
I
can't
think
of
his
name.
B
A
Agree,
image
shining
and
that
that's
that's
a
perfect,
perfect
sort
of
combination
and
another
conversation
that
we
should
have
I
really
do
want
to.
Thank
you
guys
for
taking
the
time
and
sharing
that
conversation
that
we
had
at
red
hat
summit
in
this
format.
I
think
it
was
useful.
I
actually
think
it
was
interesting
to
have
the
end
user
perspective
driving
what
the
questions
were
here
today
and
I'll.
A
Try
and
reproduce
it
again,
and
thank
you
Tim
or
taking
the
time
and
folks
on
the
call,
if
you
are
not
in
the
slack
channel,
open
ship,
common
and
slack
channel
and
you'd
like
to
be
just
reach
out
to
me
at
D,
mu
e,
ll
er
at
Red,
Hat,
comm
and
I'll.
Add
you
in,
and
we
can
continue
these
conversations
there
and
on
the
mailing
list.
So
thanks
guys,
and
if
you
can
send
me
your
slide,
deck
I
will
also
include
that
when
I
upload
it
all
to
YouTube
later
today,
all
right.