►
From YouTube: OCB AMA: Clair Overview and Road Map with Louis DeLosSantos, Aleš Raszka, and Hank Donnay (Red Hat)
Description
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 will give an introduction to Clair, demonstrate its 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
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
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,
so
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
them.
B
B
As
you
can
imagine,
the
manifest
structure
itself
expresses
that
child's
parent
relationship
of
the
layers,
so
the
client
no
longer
needs
to
it's
much
more
intuitive
to
deal
with
that
schema
versus
having
to
deal
with
the
layer
pushes
yourself
clear.
V4
has
content
addressability
as
a
first-class
citizen.
I
put
a
little
star
there
because
it
plays
a
key
role
in
claire
v4
and
it's
a
concept
in
the
rest
of
this
talk.
B
B
As
long
as
the
binary
bits
don't
change,
you
can
be
sure
that
that
checksum
identifies
the
data
at
hand,
claire
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
yaml
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
clair
we've
completely
rewritten
the
notification
subsystem.
B
A
B
So
how
claire
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
matcher
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
contents
and
it'll
place
it
into
an
ultimate
vulnerability
report
and
return
that
to
the
client,
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
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
ubia
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
have
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
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
there
are
new
vulnerabilities
discovered
all
the
time
so
that,
in
this
matching
process
is
handling
this
more
rapidly
changing
data
or
the
data
that
changes
at
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
that
we
gained
the
same
same
sort
of
content.
Addressability
benefits
there
next
slide,
please
and
updaters
updaters.
D
D
So
in
the
process
of
building
the
new
version,
we
ended
up
actually
rewriting
just
about
everything.
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
to
claire,
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.
C
C
So
if
you
either
build
or
push
container
into
play
registry
clear
in
the
background
index
the
image
and
produce
index
and
vulnerability
report,
as
was
described
earlier,
those
reports
are
visible
in
a
user
interface
and
the
user
can
check
whether
their
container
is
vulnerable
and
whether
they
need
to
rebuild
the
container
to
update
the
latest
version
in
the
previous
version
of
quay.
Claire
v2
was
used
up
until
way.
V
3.3,
where
claire
version
4
was
available
as
a
tech
preview,
and
it
becomes
default
a
container
security
tool
moving
forward.
C
C
C
This
means
that
every
image
that
is
produced
by
red,
hat
or
isv
partner
is
scanned
using
clear
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
ship
the
container
and
instead
we
rebuilt
the
container
because
we
don't
want
to
ship
content
that
is
vulnerable
to
customers.
C
It's
a
scale
from
a
to
f
previously,
in
a
red
hat,
we
used
the
custom
solution
for
container
scanning,
but
since
it
was
completely
internal
and
we
didn't
have-
or
our
customers
didn't
have
a
way
how
to
reproduce
upgrades
in
2019,
we
replaced
the
custom
solution
with
unofficial
version,
clear
version,
and
last
year
in
october,
2020
we
upgrade
upgraded
to
the
current
latest
version
of
clerk
version.
4.
B
Hey
everyone,
so
let's
go
over
what
we
expect
from
claire
v41,
clara
before
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
I
would
like
to
address
goling
and
definitely
get
some
javascript.
The
node
npm
ecosystem
in
there
hank
is
currently
plugging
away
vigorously
on
a
kubernetes
operator,
which
should
just
make
the
deployment
of
clear
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.
B
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.
You
know
the
downstream
database
and
making
sure
we
really
push
the
right
errors
forward.
So
clients
can
react
to
their
various
states
of
clair.
B
So
for
contributions,
we're
going
to
begin
community
development
meetings
at
a
bi-weekly
cadence
starting
in
march,
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.
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
way
before.
A
A
D
Our
our
own
ultimate
goal
is
to
make
it
sort
of
seamless
into
the
claire
operator.
So
if
you
install
the
yeah
the
yeah
sorry
quay
operator
the
play
operator,
it
pulls
it
in
sort
of
transparently
behind
the
scenes
and
get
all
the
scalability
benefits
of
something
that
understands
claire's
workload
that
is
just
comes
along
for
free
with
your
container
registry.
A
And
louis
you
were
talking
about
performance
and
scale
analysis
and
and
and
trying
to
get
some
better,
a
better
grip
around.
You
know
how
how
claire
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.
B
That
yeah
definitely
I
mean
that,
would
that
would
be
really
great.
If
this
does
pique
anyone's
interest,
they
can
definitely
contact
us
in
a
couple
places.
Definitely
posting
anything
on
the
mailing
list,
we'll
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
Because
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.
B
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
tag
together,
like
together
with
kafka,
so
we
are
able
to
see
some
metrics
directly
in
kibana.
A
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,
et
cetera,
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.
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,
closed
sourced
or
aggregated
data.
B
We
really
do
want
to
keep
a
consistency
and
a
level
of
accuracy
by
going
to
the
sources,
so
the
long-winded
way
of
answering
your
question.
Definitely
we
will
go
out
to
you,
know
maven,
central
or
any
of
the
official
sources
that
we
can
find.
As
long
as
we
can
grab
the
data
in
a
open
source
way,
any
kind
of
closed
source
data
sources.
We
have
to
open
up
to
more
of
a
discussion
around
how
that
could
work,
but
we
haven't
had
that
happen
yet.
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
topical.
B
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
they'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
there's
another
relationship
where
we
can
get
more
performance
and
scalability
from
people
using
that
and
so
there's
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
to
for
anyone
who's
watching
this
and
not
in
the
chat,
was
murthy's
question
on.
Can
partners
build,
custom
matchers
are
cut
our
custom
matchers
using
python,
and
you
had
a
nice
answer
for
that
too,
as
well
lewis,.
B
Yeah
definitely
so
we
we
support
remote
matching,
which
is
when,
in
the
process
of
of
looking
at
the
data,
that
the
matcher
service
received
from
an
index
report
not
to
get
too
technical
in
terminology.
But
it
can
take
a
look
at
those
contents
and
then,
instead
of
looking
at
its
own
internal
database,
it
can
go
out
to
an
api.
B
B
You
will
have
to
write
it
in
go
at
this
time
and
it
will
need
to
reside
in
the
clear
repository
at
this
time.
We
are
working
on
on
possibly
allowing
x
out
of
tree
matchers
so
matches
that
live
in
other
repositories,
but
yeah.
If
you
are
interested
in
in
the
cross
platform
looking
into
our
remote
matching,
might
be
applicable
to
you.
A
B
Cool,
so
what
I
have
here
is
a
local
claire
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
been
involved
composed,
but
you
can
just
look
at
the
repository
for
that
and
what
it
does
is
it
sets
up
clay
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.
E
E
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
makes.
B
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
files,
I'm
just
going
to
continue
so
yeah.
These
will
this.
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
92
are
interested.
B
So
it's
nice
because,
even
though
we're
kind
of
fanning
out
we're
not
really
doing
a
lot
of
work,
only
one
of
the
matches
actually
wind
up
doing
work
in
the
common
case.
So
this
is
the
the
match
of
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
presented
here
so
yeah.
You
can
do
all
this
right
now.
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
triage
it
we'll
work
with
you
to
understand.