►
From YouTube: Clair Overview and Road Map Louis DeLosSantos, Hank Donnay, Ales Raszka (Red Hat) OpenShift Commons
Description
Clair Overview and Road Map
Louis DeLosSantos, Hank Donnay, and Ales Raszka (Red Hat)
OpenShift Commons Briefing AMA hosted by Diane Mueller (Red Hat)
Clair is an open source project for the static analysis of vulnerabilities in application containers (currently including OCI and docker). Clients use the Clair API to index their container images and can then match it against known vulnerabilities. Our goal is to enable a more transparent view of the security of container-based infrastructure.
In this AMA-style briefing, Red Hat’s Louis, Hank and Ales give an introduction to Clair, demonstrate it’s use, and talk about the road map for future releases – and then take live questions from the audience.
A
This
today
is
claire,
which
has
been
associated
with
quay
and
project
quay
as
well,
but
we're
gonna
get
an
update
on
that
project
from
three
of
the
key
folks
from
that
team
and
there's
alice
and
hank
donae
and
luis
de
los
santos
is
going
to
take
us
through
what's
going
on
in
the
claire
community
and
give
us
an
update
on
the
latest
release.
So
ask
your
questions
in
the
chat.
A
B
B
B
So
why
does
claire
matter
right,
as
most
of
you
know,
we're
moving
to
distributing
applications
in
containers
before
this?
It's
more
likely
that
you
would
deploy
applications
on
servers
right
you
to
use
ansible
or
some
kind
of
configuration
management
and
deploy
your
application
there.
If
you
had
issues
vulnerability,
vulnerable
dependencies
on
those
deployments,
the
splash
damage
was
confined,
they
were
confined
to
the
servers
you
deployed
it
on
now
that
we're
shipping
containers
as
the
default
way
to
package
and
deploy
applications.
B
B
There's
also
something
to
be
said
about
the
recent
supply
chain,
attacks
of
the
solarwinds
hack.
Obviously,
when
you're
moving
to
a
centralized
repository
where
your
artifacts
go
for
deployment,
that
repository
can
become
subject
to
attack,
as
you
probably
are
aware
of,
if
you've
been
following
any
of
that,
so
what's
new
in
claire
v4,
so
previously
in
clear
v2,
the
api
was
layer
based.
B
B
B
As
long
as
the
binary
bits
don't
change,
you
can
be
sure
that
that
checksum
identifies
the
data
at
hand,
clear
utilize.
This
and
you'll
learn
more
about
this.
In
a
couple
slides,
we
have
completely
updated
all
the
security
advisory
data
sources
that
we
go
out
to.
We
moved
away
from
doing
any
kind
of
ad
hoc
database
parsing,
where
we
can't
avoid
it.
B
That
would
be
json
dumps
or
gamble
dumps.
We
now
favor
oval
as
the
standard
and
we're
able
to
move
most
of
the
database
or
data
security
sources
to
oval,
which
is
nice
because
we're
able
to
create
some
tooling
around
oval
that
makes
parsing
pretty
quick.
On
our
end,
we
now
have
a
native
cli
tool.
We
no
longer
depend
on
external
repositories
to
provide
a
cli
tool
for
claire
we've,
completely
rewritten
the
notification
subsystem.
B
C
B
Trends
so
how
clear
works?
This
is
the
30
000
foot
view
of
what
claire
does
right.
There
is
a
container
we'll
use
container
and
manifest
somewhat
interchangeably.
Manifest
is
just
our
json
schema.
It
represents
a
container
and
claire
is
broken
up
into
three
services:
the
indexer,
the
matcher
and
the
notifier.
B
The
indexer
is
responsible
for
taking
a
manifesto
or
container
and
parsing
out
the
contents.
You
know
typical
things
like
packages
repositories,
what
distribution
those
containers
are
representing
and
it
places
these
contents
in
a
report
that
we
dubbed
the
index
report.
The
matcher,
on
the
other
hand,
is
responsible
for
generating
reports
of
flagged
content.
So
when
the
master
gets
a
request,
saying
hey,
does
this
manifest?
Have
any
vulnerabilities
affecting
it?
It
goes
to
the
index
and
says:
hey:
do
you
even
have
an
index
report
to
this
for
this
manifest?
B
If
you
do,
can
I
have
it
so
when
it
receives
it,
it
goes
to
its
database
and
just
sees
that
there's
any
flagged
content
packages,
distributions
repositories
it'll
take
all
that
flagged
content
and
it'll
place
it
into
an
ultimate
vulnerability
report
and
return
that
to
the
client
and
the
notifier
just
hangs
out
down
there.
He
watches
the
matcher
and
the
indexer,
and
he
identifies
new
updates
that
come
into
the
system
and
and
then
asks
the
indexer
hey.
Do
these
vulnerabilities
I've
just
entered
the
system?
B
B
B
So
how
does
indexing
actually
work?
First
thing
that
happens
is
claire
needs
to
identify
if
the
manifest
should
be
scanned,
when
claire
gets
a
manifest
submitted
to
it.
It's
going
to
check
hey.
Have
I
ever
seen
this
content
addressable
identifier
right?
Have
I
ever
seen
this
manifest
hash
before
in
this
case
it
hasn't.
So
it
goes
okay.
Yes,
you
should
be
scanned.
Let's
move
to
the
next
phase.
B
Next,
it
determines
what
layers
it
needs
to
actually
scan.
I
express
a
common
case
here
in
that
the
base
layer
might
have
been
seen
a
million
times
by
claire
right.
This
might
be
a
ubi8
base
layer,
so
it
says:
hey.
I
don't
need
to
scan
this.
I
already
saw
this
but
the
subsequent
layers
it
has
never
seen
before.
So
it's
going
to
mark
those
as
yes,
we
need
to
scan
these.
I
have
no
content
available
for
this
when
it
actually
goes
to
perform
the
scan.
B
The
base
layer
is
simply
just
retrieved
from
the
database.
Any
content
we
know
about
it
is
not
there's
no
work
performed.
It
is
just
a
get
from
the
database.
The
subsequent
layers
are
actually
scanned.
This
is
the
process
of
going
to
fetch
the
layers
decompressing
them
looking
for
packaged
databases
identifying
the
characteristics
of
the
individual
layers.
B
If
it
sees
it
again,
it's
going
to
say:
okay,
yes,
I
I
have
this
data.
We
already
scanned
this
by
looking
at
the
manifest
hash
it
can
already
know.
I
scanned
all
those
layers
right,
because
if
the
layers
changed,
the
manifest
hash
would
change
cool.
So,
for
the
matching
part,
I'm
actually
going
to
hand
it
over
to
hank
who's
going
to
demonstrate
this
further,
and
just
give
me
a
small
cue
when
you
want
me
to
change
the
slides.
D
Will
do
okay,
yeah
so
now
that
we've
got
this
index
of
what's
in
these
contents
and
it's
content
addressed.
Obviously,
when,
obviously,
we
don't
need
to
redo
the
work
because
it
won't
change.
But
what
does
change
over
time
is
the
vulnerabilities
their
new
vulnerabilities
discovered
all
the
time
so
that,
in
this
matching
process,
is
handling
this
more
rapidly
changing
data
or
the
data
that
changes
it
all
yeah?
So
next
slide.
D
Next
slide,
the
the
matchers
take
the
this
index
report
and
all
of
them
in
parallel
examine
the
the
index
report
for
the
sorts
of
data
they
know
about
so
here
in
this.
In
this
example,
we
have
bits
of
code
all
at
the
same
time,
looking
for
rel
packages,
another
one
looking
for
ubuntu
packages,
another
looking
for
alpine
packages.
Most
of
these
won't
find
anything
and
the
ones
that
do
return
their
results
and
we
combine
all
of
them
together
and
return
the
matcher
doing
it
this
or
return
the
report
doing
it.
D
This
way
means
we
can
just
sort
of
additively,
add
bits
to
look
at
new
parts.
So,
for
example,
our
language
support
is
implemented
as
a
as
a
box
on
this
second
row
here
and
any
sort
of
os
just
automatically
gains
that
support,
because
of
doing
it.
This
way-
and
these
are
all
then
fed
and
kept
under
the
same-
the
same
hash
as
the
index
report.
D
D
D
So
the
api
is
completely
different.
Again,
it's
manifest
driven,
not
sort
of
layer,
stitching
and
all
of
our
internal
data
is
completely
different,
so
you
do
have
to
resubmit
images
declare.
But
you
know
it
should
be
faster.
So
a
little
initial
pain
and
some
win
on
the
back
end
and
now
I'm
going
to
hand
it
off
to
elash.
B
C
C
C
C
C
This
means
that
every
image
that
is
produced
by
red,
hat
or
isv
partner
is
scanned
using
claire
security
scanning
tool
and
the
release
process
is
driven
by
the
results.
So
if
we
discover
vulnerability
into
the
report,
we
don't
ship
the
co
ship
the
container
and
instead
we
rebuild
the
container
because
we
don't
want
to
ship
content
that
is
vulnerable
to
customers.
C
B
Hey
everyone,
so,
let's
go
over
what
we
expect
from
claire
v41
clairv4
hit
ga
a
couple
weeks
ago.
So
this
is
a
roadmap
for
the
next
minor
version.
We'd
like
to
expand
on
language
support
quite
a
bit.
I
believe
there
are
some
plans
already
for
java,
which
are
going
to
make
its
way
in
via
another
collaboration
with
code
ready
containers.
B
The
node
npm
ecosystem
in
there
hank
is
currently
plugging
away
vigorously
on
a
kubernetes
operator
which
should
just
make
the
deployment
of
claire
and
the
various
architectures
that
you
can
deploy
claire
in
pretty
trivial,
to
set
up
we're
going
to
put
an
emphasis
on
performance
and
scale
analysis.
So
we
really
want
to
know.
You
know
how
well
claire
scales
in
the
event
of
excess
traffic,
trendy
and
bursty
traffic,
so
we'll
be
putting
a
lot
of
effort
into
that
and
then
just
general
reliability
efforts,
things
like
making
sure
database
connections
don't
flood.
B
B
I
will
have
a
link
to
those
meetings
in
a
subsequent
email
burst,
along
with
the
mailing
list
blast
and
other
ways
that
we
go
about,
disseminating
that
information.
There's
a
quick
link
to
our
mailing
list.
I
would
go
follow
this
if
you
are
interested
in
community
development
or
further
openshift
briefing
meetings,
we'll
definitely
be
posting
there.
We'll
also
be
placing
a
lot
of
information
in
the
repository,
which
is
a
quay
claire.
B
The
discussions
area
of
that
will
be
placing
a
lot
of
information
about
how
to
interact
with
the
community
moving
forward
and
then
yeah
there's
just
a
couple
contacts
here
and
if
you
need
to
reach
out
to
us,
these
are
our
emails
and
then
there's
a
general
way
email,
so
that
kind
of
wraps
it
up.
I
hope
that
was
informative,
built
you
in
on
you
know
the
work
we've
been
doing
on
before.
A
A
A
And
louis
you
were
talking
about
performance
and
scale
analysis
and
and
trying
to
get
some
better,
a
better
grip
around.
You
know
how
how
clara
was
doing
out
there
in
the
wild
if
there's
folks
out
there
who
want
to
work
with
you
on
that
or
give
you
feedback
on
that.
What's
the
best
place,
is
it
that
clear
mailing
list
to
reach
out
to
folks
to
do
that.
B
Yeah
definitely
I
mean
that.
Would
that
would
be
really
great
if
this
does
peak
anyone's
interest,
they
can
definitely
contact
us
in
a
couple
places.
Definitely
posting
anything
on
the
mailing
list
will
get
our
attention
github
issues
or
github
discussions,
we'll
get
our
attention
pretty
immediately
or
just
shoot
us
an
email,
and
you
know
we'll
we'll
take
a
look
at
that,
but
yeah
there's
a
couple
options
right
now:
all
of
them
should
be
pretty
viable.
A
I
know
that
the
use
of
it
in-house
alice
referenced
the
a
million
images
scanned
with
inside
of
red
hat,
or
we
have
created
a
million.
I
think
we've
created
more
than
that,
but
personally
I
think
I
might
have
made
a
whole
bunch
of
messy
images
that
should
be
scanned,
but
that's
growing
to
other
organizations
that
can
can
utilize
the
performance
and
analysis
metrics
and
give
us
feedback.
Is
there
any
telemetry
being
added
into
claire
or
anything
like
that
to
to
collect
that
from
outside
external.
D
C
Is
capable
to
send
the
metrics
into
jagger,
it's
like
building
a
feature
and,
of
course
things
like
making
logs
available
in
the
system
that
can
easily
make
a
dashboard
out
of
it.
For
example,
in
our
use
case,
we
use
the
alex
tech
together,
like
together
with
kafka,
so
we
are
able
to
see
some
metrics
directly
in
a
kibana.
A
Dashboard,
okay
and
I'm
going
to
read
out
one
of
the
questions.
I
know
you
answered
it
in
the
chat,
but
I'm
going
to
read
it
out
for
people
who
might
be
watching
the
video
here
later.
Will
the
expanded
language
support
for
java
etc?
Include
sources
outside
of
red
hat,
I.e,
maven
central
or
will
it
be
primarily
focused
on
libraries
that
red
hat
supports
and
lewis
had
a
nice
answer
to
that.
A
B
Takes
an
open
source
approach
to
begin
with,
so
all
the
data
that
we
collect
are
independently
upstream
managed
and
the
reason
we
do
that
is
because
the
most
accurate
data
is
the
source
of
the
data
right.
So
we
go
out
to
your
pulp,
manifests
for
red
hat
data,
we'll
go
out
to
the
ubuntu
security
tracker
for
ubuntu
data.
We
are
pretty
adamant
on
not
using
quote
unquote,
close-sourced
or
aggregated
data.
B
B
D
D
A
And
there's
one
more
question
in
in
the
chat
the,
and
this
is
probably
top
of
mind
for
a
few
folks.
How
would
you
define
the
relationship
between
claire
and
stack
rocks?
Are
they
mutually
beneficial
or
is
one
a
super
set
or
subset
of
the
other?
How
does
this
we
just
had
the
cube
linter
folks
on
last
week.
I
think
so.
It's
probably.
B
Topical
yeah,
so
I
can
talk
about
what
I
know
so
far.
I
know
that
there's
no
official
talks
of
how
the
teams
will
work
together,
but
they
utilize
clear
v2.
So
we've
already
started
discussing
at
a
high
level
what
clearv4
can
offer
them,
and
I
imagine
that
there'll
be
a
pretty
tight
collaboration
in
the
future.
B
As
long
as
you
know,
it's
a
little
bit
above
my
pay
grade
to
determine
those
things,
but
as
far
as
I
can
tell
they
utilize
claire
as
a
product,
and
they
would
be
interested
in
claire
b4,
so
we
should
see
more
of
a
merging
than
a
you
know,
any
kind
of
separation
or
a
schism
between
the
products.
I
imagine
that
they,
it
would
fall
online
pretty
well,
since
the
underlying
technology
they
use
for
at
least
the
scanning
portion
of
their
product
is
the
same.
So
it
works
out
pretty
well.
A
There's
another
relationship
where
we
can
get
more
performance
and
scalability
from
people
using
that
and
so
there's
an
another
whole
chunk
of
the
ecosystem,
plus
more
engineering
resources
coming,
hopefully
our
way
to
work
on
this,
and
so
that
that's
always
always
always
a
good
thing.
So
yeah,
that's.
A
That's
always
the
most
exciting
part,
one
other
earlier
question
that
I
just
wanted
to
get
a
readout
on
too
for
for
anyone
who's
watching
this
and
not
in
the
chat,
was
murthy's
question
on.
Can
partners
build
custom,
matchers
or
cut
our
custom
matchers
using
python,
and
you
had
a
nice
answer
for
that
too,
as
well.
Luis.
B
So
anyone
can
go
and
write
an
api
in
any
language.
You'd
like
if
you
do
want
native
matching
support,
which
obviously
there's
some
advantages
there.
You
will
have
to
write
it
in
go
at
this
time
and
it
will
need
to
reside
in
the
bear
repository
at
this
time.
We
are
working
on
on
a
possibly
allowing
x
out
of
tree
matchers,
so
matches
that
live
in
other
repositories,
but
yeah.
If
you
are
interested
in
the
cross
platform
looking
into
our
remote
matching,
might
be
applicable
to
you.
A
B
B
B
Cool,
so
what
I
have
here
is
a
local,
clear
environment.
You
can
do
this
today.
If
you
want
to,
you,
can
go
and
pull
the
claire
repository
and
do
this
command
make
local
dev
up
just
make
sure
you
have
the
necessary
dependencies.
We
won't
go
into
that
right
now.
It's
involved
stock
compose,
but
you
can
just
look
at
the
repository
for
that
and
what
it
does
is
it
sets
up
quai
and
claire
locally
on
your
machine
and
quay
lives
at
localhost
8080..
B
B
When
you're
utilizing
the
local
environment,
you
can
use
podman
as
far
as
logging
in
and
pushing
an
image
to
the
local
container
or
the
local
repository
you'll
want
to
specify
this
tls
verify
false,
because
it's
a
local
environment.
We
just
didn't
bother
to
wire
in
ssl
it
just
kind
of
gets
in
the
way.
B
So
what
we
can
do
is
a
login
and
that's
at
port
8080.
So
this
will
log
into
the
quay
instance
that
is
running
here
and
I
have
a
container
it's
just
ubuntu
latest
and
we
can
go
ahead
and
we
can
push
that
you'll
notice.
That
you'll
have
to
tag
images
with
the
local
host
8080,
and
then
we
can
go
ahead
and
push
that
to
the
local
quay
instance.
B
B
B
If
you
go
to
this
tag
area
you'll
see
that
we
have
successfully
scanned.
Let
me
make
this
bigger,
I'm
sure
it's
quite
small
right
now.
This
was
the
image
we
just
pushed
and
then
claire
was
able
to
scan
it.
You
can
go
and
you
can
dig
into
the
security
information
via
this
gui
yeah.
So
if
you'd
like,
we
can
just
give
you
a
quick
overview
of
what
claire
actually
did.
D
Yeah
well,
lewis
pulls
this
up
like
again.
One
of
the
cool
things
is
because
everything
is
driven
off
of
this
content
addressability
here,
because
claire
did
the
work
of
scanning
this.
This
base
image
once
any
new
container
that
shows
up
only
the
new
layers
need
to
get
analyzed,
which
makes
it
a
bit
snappier
yep.
B
Makes
things
pretty
quick?
So
if
we
just
scan
through
the
logs
right
here,
you
know
you,
probably
you
have
to
be
acquainted
with
the
application
a
little
bit
to
understand,
but
the
indexer
is
really
going
and
it
is
it's
doing
an
analysis
on
the
layer
right.
It
didn't
find
an
os
release
file.
Okay,
so
we
couldn't
identify
it
so
the
match
identified
for
the
aws
distribution.
B
Oh
okay,
I
can't
find
not
post
release
file,
so
I'm
just
going
to
continue
so
yeah.
These
will
basic.
The
indexer
itself
is
doing
this.
It's
grabbing
the
layers,
it's
identifying
any
items
it
can
and
then
it's
storing
and
then
it's
storing
the
index
report
and
then
the
claire
matcher
is
really
just
going
ahead
and
it's
it's
issuing
these
these
matching.
So,
as
you
can
see,
it's
a
ubuntu
image
it
found
that
is
92
are
interested.
B
So
this
is
the
the
master
basically
evaluating
the
pushed
content.
So
this
process
will
return
a
vulnerability
report
and
then
that
vulnerability
report
is
pretty
much
just
parsed
by
quay
and
present
it
here
so
yeah.
You
can
do
all
this
right
now.
If
you
wanted
to
go
and
pull
the
clear
repository
and
play
around
with
it
again,
you
will
just
basically
go
and
run.
B
If
you
have
any
troubles
with
that,
you
know
just
just
we've
been
doing
a
new
thing
where,
if
you
have
like
quick,
quick
support,
questions
drop
them
on
discussions,
q,
a
on
github
and
that
seems
to
work
pretty
well,
we
can
mark
things
as
like.
Yes,
this
is
the
correct
answer,
but
it's
been
a
nice
place
to
put
anything
really
supportive,
you're,
not
sure.
If
it's
a
bug
right,
you
should
put
something
there,
we'll
we'll
triage
it
we'll
work
with
you
to
understand.