►
From YouTube: OpenShift Commons Operator Framework SIG Mtg Image Signing and Scanning Operator 2019 Feb 15
Description
OpenShift Commons Operator Framework SIG Mtg
Image Signing and Scanning Service Operator
Andrew Block & Matt Bagnara
2019 Feb 15
https://github.com/redhat-cop/image-scanning-signing-service
Image Scanning and Signing Service
Services to support image scanning and signing on the OpenShift Container Platform
A
All
right,
so
it's
been
a
few
moments
talking
about
the
image
signing
and
image
scanning
service
with
itself
as
an
operator,
we
can
kind
of
talk
about
how
this
project
kind
of
unfolded
over
the
course
of
the
last
year
or
so.
First
of
all,
my
name
is
Andrew
block
my
senior
principal
consultant
at
Red,
Hat
I'm,
also,
the
co
manager
of
the
container
and
past
moody's
practice
within
Red
Hat.
A
The
community
of
practice
program
within
Red
Hat
is
a
way
for
those
who
are
interested
in
a
particular
area
or
field
of
interest
to
get
together
talk
about
it,
build
new
solutions,
but
then,
most
importantly,
go
out
and
share
their
learnings
with
the
community,
not
only
within
red
hat,
but
also
in
the
open
source
community.
Very
much
like
we're
doing
today
and
my.
B
A
First,
want
talks
about
some
of
the
background
of
the
image
signing
image
scanning
problem
space
that
we
are
trying
to
solve
here.
First
of
all,
we
wanted
to
leverage
a
lot
of
the
existing
open
ship
ecosystem.
Obviously
there's
a
number
of
third-party
vendors
that
have
to
in
signing
and
image
scanning
solutions,
but
we
wanted
to
look
first
to
leverage
the
native
tool
within
open
ships
and
most
important
thing.
We
need
to
think
about
it,
especially
around
the
terms
of
security.
A
How
do
we
guarantee
that
our
images
are
safe
for
you,
especially
the
ones
that
are
developers
who
are
developing
on
open
ships
are
building?
How
do
we
guarantee
that
they're,
not
including
them,
either
from
invalid
or
notorious
upstream
images
or
they're,
putting
some
dangerous
libraries
into
their
application?
A
The
goal
here
is
obviously
to
increase
security
within
the
platform
and
in
application,
and
also
to
mitigate
vulnerability.
As
I
mentioned,
we
need
to
go
ahead
and
utilize
over
just
native
ecosystems
of
tools,
but
then
this
solution
needs
to
be
highly
integrated
into
continuous
integration
and
continuous
delivery
pipelines
that
a
lot
of
our
customers
work
with
very
much
like
Matt
mentioned.
I
work
very
much
with
different
customers,
all
shapes
and
sizes
going
this
small,
as
you
know,
somewhat
startups
to
upwards
of
top
Fortune
142
companies.
A
So
we
need
to
think
about
a
wide
range
of
customer
use
cases,
so
this
project
has
evolved
quite
a
bit
over
time.
It
first
started
out,
as
we
called
the
image
signing
and
image
scanning
projects
that
was
very
much
python-based.
We
were
leveraging
a
tool
that
was
developed
by
the
red,
a
community
of
practice
that
basically
watched
four
events
from
the
open
ships
event
API.
This
is
way
before
the
days
of
you
know
the
operator
lifecycle
manager,
operators,
general
steam
before
customer
resource
definition.
A
They
reacted
on
changes
from
image
and
image
stream
events
and
the
open
ship
API
and
did
leverage
a
number
of
open
ships
native
tools
that
it
was
leveraged
by
the
platform,
everything
from
open
ships,
open
sketch
scanning
and
the
atomic
scanning
tools
as
well.
Unfortunately,
it
did
have
a
bit
of
a
frail
architecture,
as
certain
events
could
be
missed
or
duplicated.
So
we
had
to
put
some
additional
logic
into
you
know
our
application
and
also
come.
You
know,
with
the
assumption
that
yeah
we
could
end
up
having
duplicated
events
and
functionality.
A
Honestly,
really
wasn't
that
great.
So
then,
our
customer
resource
definition
helped
us
get
a
little
little
bit
further
down
the
road
where
we
were
able
to
get
away
from
that
Python
base
library
and
a
venting
model,
and
to
leverage
customer
resource
definitions
and
more
of
a
native
feel
to
how
we
were
interacting
with
open
ship.
We
were
no
longer
going
up
after
the
events,
API
and
utilizing.
You
know
just
great
event
and
triggers
from
that.
We
went
ahead
in
started,
leveraging
more
of
a
native
solution.
A
B
A
Honestly,
there
was
two
things:
it
was
a
challenge
of
pain,
but
also
a
learning
experience,
so
we
were
able
to
create
a
brand
new
repository
built
upon
the
solution
and
it
worked.
It
was
great.
It
still
required
a
number
of
custom
logic
that
I
built
and
by
myself
and
the
team
built
to
talk
to
the
open,
shipped
API
and
to
monitor
the
different
resources
and
then
really
what
things
the
game
for
us
was.
The
you
know
the
unveiling
of
the
operator
framework.
Last
May.
A
And
creating
our
custom
resources,
the
libraries
that
models,
those
and
basically
the
standardize
on
that
operator.
Framer
logic
which
basically
gave
us
the
boilerplate
that
we
needed
so
I
basically
went
ahead
and
eliminated
about
90%
of
our
code
base,
went
ahead,
remodeled
on
the
out
open,
shipped
off
part
man,
the
operator
framework,
and
what
David
says
instead
worried
about.
A
A
The
framework
provided
that,
for
me,
all
I
need
to
do
is
change
my
logic
slightly
to
implement
with
the
framework
needed
and
also
it
also
gave
our
team
the
ability
to
then
be
able
to
interact
with
the
burgeoning
community
that
the
operator
framework
had.
We
were
able
to
talk
with
others
that
were
having
some
other
challenges
for
dressing
with
dopey,
just
API
winnings
and
best
practices.
Lessons
learned,
and
that's
really
what
we
started
to
do
is
start
interacting
with
the
community
and
able
to
harden
the
support
and
stability
of
our
project.
A
So
what
exactly
does
the
architecture
of
the
image
signing
and
image
scanning
service
look
like?
So
for
those
of
you
familiar
with
OpenShift
they're,
familiar
with
the
fact
that
you
can
perform
various
build
types
on
the
platform,
you
can
create
images
and
then
push
those
to
open
ships
registry
and
then
make
use
of
image
stream.
So
the
first
step
is
for
a
user
to
start
a
build
and
to
have
the
platform
build
that
image
and
push
it
to
open
ships
integrated
registry
once.
A
A
And
then
it
goes
ahead
and
creates
a
signing
pod
and
then
that
signing
pod
will
go
in
and
sign
the
image
it
has
a
gbg
key.
So
that's
what
the
atomic
tools
leverages
by
default
that
is
automatically
configured
inside
the
cluster
as
a
default
key
that
can
be
leveraged.
However,
in
addition,
let's
say
a
development
team
has
their
own
key.
They
want
to
use
for
their
image.
A
They
can
provide
that
as
a
secret
within
their
projects,
and
the
signing,
Cod
and
controller
will
go
ahead
and
configure
that
to
be
used
by
the
signing
process
and
then,
finally,
once
once
the
signing
process
completes,
it
can
go
in
and
then
push
that
updated
image
to
the
open
ship
registry
for
deployment
time.
We
also
provide,
in
addition
to
signing,
we
also
use
open
sketch
scanning
as
well.
So
you
would,
instead
of
having
an
image
signing
request.
A
B
B
D
B
Want
to
give
the
security
folks
in
this
organization
a
warm
feeling
about
what
they're
using
so
what
we're
able
to
utilize
in
this
case
is
some
of
the
security
scanning
for
runtime
images.
Like
I
said
in
a
production
environment.
You
have
all
these
containers
running.
We
want
the
developers
to
be
able
to
self
provision
their
own
scanning
requests
for
these
images
that
they're
building
it
utilizes
atomic
scan
under
the
scenes.
B
But,
however,
that's
also
that's
also
pluggable
you
can
you
can
substitute
different
getting
mechanisms
and
we
know
there's
a
number
of
tools
out
there,
but
this
is
primarily
focusing
on
the
open
chip
suite
of
tools
available
security
folks
also
want
to
ensure
container
image
provenance
so
having
this
chain-of-custody
through
the
form
of
digital
signatures
is
key,
so
something
that
gets
deployed
into
production.
We
want
to
be
able
to
trace
that
signature
back
to
when
it
was
built,
match
those
up
and
say.
B
Yes,
this
is
the
same
artifact
that
was
built
in
the
dev
environment,
then
that
is
being
deployed
in
production
and
then
finally,
for
production.
If
deployment
security
organizations
can
enforce
these
image
scans,
so
they
can
initiate
an
image
scan
and
upon
successful
completion
they
can
scan.
They
can
sign
that
that
image
so
back
to
the
previous
example
developer,
creates
an
image
it
gets
scanned
in
the
development
pipeline
that
also
that
that
successful
scan
triggers
a
sign
mechanism
or
a
sign
object
to
be
created
using
the
operator
crd.
A
I'm
sure
Diane's
gonna
go
ahead
and
share
those
out
this
deck
out
afterwards,
so
we'll
be
able
to
share
that
out
with
the
entire
community.
We
have
our
repositories
resources.
We
also
have
a
demo
that
demonstrates
this
entire
process
for
image
signing
and
even
scanning.
We
also
have
some
links
to
other
tools
that
are
being
leveraged
during
our
our
actual
operator
logics.
A
E
I
have
a
quick
question
for
you
about
ongoing
support
for
this
I
know.
This
is
in
your
your
repo
right
now,
but
is
there
any
thought
about
maybe
moving
this
over
over
into
openness
gap
and
asking
the
community
there
to
work
with
this
and
maintain
it,
and
what
are
your
plans
for,
like
maybe
moving
this
into
the
community
operators
so.
A
A
To
a
new
version
in
the
next
few
months,
this
is
certainly
an
area
that
we
want
to
make
sure
that
we
make
as
compatible
as
possible
for
the
new
ecosystem.
If
there
is
any
changes
or
unfortunately,
there
shouldn't
be,
but
that
is
a
good
opportunity
to
be
able
to
reengage
and
look
at
the
architecture
moving
forward.
B
And
also
for
customers
who
are
looking
to
utilize
this
to
be
a
good
opportunity,
because
I
know
in
my
environment
you
have
a
lot
of
issues
with
identity
and
whether
or
not
these
community
products
or
projects,
if
red,
hats,
willing
or
companies
are
willing
to
absorb
any
legal
risk
associated
with
using
that
in
the
production
environment.
So.
E
E
A
Yeah,
we
can
definitely
go
ahead
and
have
some
conversations.
I
know
one
area
that
I
know
we're
a
man.
Sorry
we
investigated
to
go
into
the
poro.
Is
the
utilization
of
docker
I
know,
there's
a
heavy
dependence
on
docker
right
now.
So
that's
one
area
of
improvement
and
evolution
that
we're
going
to
have
into
the
four
oh
babe
yeah.
C
It's
really
awesome
seeing
what
people
are
building.
Thank
you
for
sharing
some
of
your
operators
today
in
the
chat
we
were
talking
about,
the
storage,
OS
cluster
operator
and
so
excited
to
see
things
like
that
coming
to
help
folks
better,
take
advantage
of
some
of
the
kubernetes
features
around
storage
versus
in
volumes
logging.
All
that
good
stuff,
there's
a
really
great
set
of
operators
underway
to
help
with
all
that
so
we'd
love
to
get
those
added
to
our
community
Rico,
so
that
everybody.
E
Cool
and
I
don't
know
if
Simon
is
still
on,
but
maybe
our
next
meeting
is
going
to
be
again
on
the
third
Friday
of
the
month
would
have
which
happens
too.
E
Let
us
know
and
I
will
try
and
coerce
them
into
sharing
their
stories
and
telling
you
more
about
it
and
again
the
we
had
the
it's
in
the
calendar,
but
I'll
send
an
announcement
to
the
Google
group
and
post
it
on
the
kubernetes
operators
about
operators
for
ansible
people
which
will
be
March
sticks.
So
that's
that's
the
other
thing
and.
D
E
E
What
we're
really
trying
to
see
is
is
what
we
can
learn
from
each
other
here
so
and
if
you
need
advice
or
help
just
one
jump
on
the
Google,
Group
I
think
the
link
the
link
is
down
below
on
the
page
here,
nope
didn't,
but
all
that
now,
if
you
haven't,
joined
the
Guru,
that's.
B
E
The
Commons,
which
is
the
open,
shift
Commons
community
calendar,
so
it
should
be
you're
seeing
my
screen,
but
all
of
the
events
that
are
in
all
of
the
other
SIG's
as
well,
whether
it's
learning
Bellco
and
others
all
here
and
there's
an
RSS
feed
that
you
can
subscribe
to
it
songwriters
at
the
bottom.
If
you
look,
if
you're
looking
to
keep
track
of
everything,
that
Diane
is
trying
to
keep
track
of
it's
it's
here.
B
E
There's
also
going
to
be
some
really
interesting
and
I,
don't
know
where
you're
based
Simon,
but
the
the
trainings
haven't
been
listed
here.
But
there's
going
to
be
a
whole
whole
lot
of
talk
about
operators
in
the
morning.
At
this
open
ship,
Commons
gathering
and
I'm
also
going
to
run
a
parallel
track
and
in
the
afternoon
from
1:00
to
4:00
Michael
with
neck,
and
that
Doorn
are
going
to
repeat
the
hands-on
community
humanities
hoping
operator
framework
workshop
I.
D
E
And
yeah,
that
would
be
great,
so
there's
lots
going
on.
There
will
also
be
a
hands-on
workshop
at
Red
Hat
Summit
in
parallel
with
the
open
ship
comms
gathering
there
in
May
as
well
and
I,
just
keep
trying
to
wherever
I
do
anything
book
an
extra
room
so
that
we
can
also
do
the
operator
framework
workshop.
So
look
for
those
announcements
and
I'll
send
those
out
onto
the
mailing
list.
E
But
if
you
haven't
signed
up
anyone
who's
on
this
hall
and
it
has
not
signed
up
for
the
Google
Group,
please
do
so
it's
really
where
all
of
the
announcements
go
out
there.
You
go
anything
else.
Anyone
wants
to
add
because
I'm
two
minutes
away
from
having
to
go
to
another
call.
So
I
am
going
to
let
you
it
ask
any
questions
in
the
Google
group
or
in
the
slack
Channel
and
kubernetes
kubernetes
operators
for
real
technical
conversations
too.
So
please
reach
out
and
thank
you
all
for
joining
us
today.
Much
appreciated.
E
D
D
Hi
Bree
I
saw
one
of
two
messages:
there's
the
key,
the
little
group
where
people
were
trying
to
do
the
same,
so
that
was
quite
inspired.
Artists
to
create
this
library
and,
of
course,
we'd
love
people
for
five
years
who
and
use
it
for
themselves
or
even
contribute
to
it
motivation.
Then
users
always
welcome.