►
Description
Can you set up a custom registry with Red Hat OpenShift? There are several considerations you'll have to make when choosing which registry is best for your use case and OpenShift conveniently provides an out-of-the-box registry, but you can also choose to use your own. In this episode, we’ll walk through the steps needed to set up a custom registry for OpenShift, and Daniel Messer, Product Manager of Red Hat Quay, will join us to discuss Quay’s integration with OpenShift. Have you ever used Red Hat Quay? Did you find it to be valuable? Join us and share your thoughts and learn more about Quay and registry options in Red Hat OpenShift.
Learn more: https://www.redhat.com/en/topics/cloud-native-apps/what-is-a-container-registry?sc_cid=7013a000002qG1GAAU
Check out another episode on this same topic: https://www.youtube.com/watch?v=dT4hE373rkU
Try Red Hat OpenShift: https://red.ht/3uYcuhU
Follow us:
Randy Russell https://red.ht/rrr-linkedin
Scott McBrien https://twitter.com/stabby_mc
Jaafar Chraibi https://twitter.com/ChraibiJc
OpenShift https://twitter.com/openshift
Subscribe to Red Hat's YouTube channel: https://www.youtube.com/redhat/?sub_confirmation=1
What is the Level Up Hour?
Every other Wednesday at 9am ET we stream live demos on how Red Hat Enterprise Linux (RHEL) users and admins can benefit their organizations and improve their careers by learning how to use containers, Kubernetes, and Red Hat OpenShift.
Learn more at https://red.ht/leveluphour
Level Up Hour on GitHub https://github.com/level-up-hour/
About OpenShift:
Red Hat OpenShift is an open source container application platform based on the Kubernetes container orchestrator for enterprise application development and deployment.
OpenShift on redhat.com https://red.ht/3uXIbaQ
OpenShift on github https://github.com/openshift/
#RedHat #OpenShift #RHEL #tluh
B
B
We
have
daniel
messer,
a
product
manager
for
our
red
hat
registry
called
named
quay,
and
that's
it's
a
good
thing,
because
today
we
are
actually
going
to
speak
about
setting
up
custom
registries
with
the
openshift
and
daniel
would
will
have
the
pleasure
to
explain
how
we
can
use
quay
as
one
of
these
options
with
the
platform
so
yeah
again,
thanks
for
joining
us
today,
thanks
for
everyone,
who's
joining
the
show
daniel.
Would
you
like
to
say
a
few
words
about
you?
A
Manager
at
red
hat,
I
look
after
our
central
multi-cluster
registry
component,
called
red
hat
quay
that
we
have
as
a
strategic
element
of
our
portfolio
strategy
around
openshift
whenever
you
want
to
run
more
than
one
cluster,
so
we
think
that's
a
pretty
important
topic
in
the
future
and
that's
actually
going
to
be
the
model
that
many
people
will
prefer
in
the
future.
Now
that
it
is,
you
know,
very
straightforward
to
run
and
configure
openshift4
in
the
self-managed
fashion.
It
allows
you
to
do
with
all
the
operational
concepts
around
it.
A
So
I
also
look
after
the
hosted
offering
of
quay
that
is
quake.io,
which
is
also
interesting,
because
it's
the
same
code
that
runs
this
pretty
massive
public
registry
service.
You
can
just
sign
up
for
with
your
credit
card,
so
just
give
you
a
couple
of
numbers
for
that.
So
creator
io
serves
over
2
billion
images
per
month
and
it
has
petabytes
of
images
under
management
and
governance,
which
means
organizing
your
storage,
your
tags,
your
access
policies,
scanning
the
content
of
these
images,
building.
A
B
B
B
So
for
those
who
have
been
familiar
with
openshift
we've
shipped
an
integrated
registry
since
the
early
days,
and
even
before
the
acquisition
of
quay
actually,
and
so
that
that's
one
of
the
benefits
of
the
platform
is
that,
as
the
name
platform
implies,
it
has
all
the
components
already
set
up
and
ready
to
use
for
you.
So
we
do
have
the
integrated
registry
that
runs
by
default
with
the
platform.
A
Yeah
I
like
that
you
acknowledge
how
easy
it
is
to
work
with
that
just
out
of
the
box
right,
because
there's
really
not
much
configuration
or
management
overhead
to
it.
The
only
thing
you
really
need
to
do
at
the
very
beginning
when
you
set
up
the
cluster,
is
to
essentially
tell
that
integrated
registry
where
your
storage
is,
and
it
can
use
internal
storage
of
the
cluster
as
well
like
persistent
volumes,
but
you
will
want
to
prefer
object.
Storage
like
redhead,
which
data.
A
Odf,
if,
if
possible
so
yeah,
it's
it's
pretty
convenient
right,
because
it
is
sort
of
working
in
the
background
all
the
time.
So,
whenever
you
import
images
into
openshift
or
you
use
openshift's
build
functionality
to
create
images
as
part
of
a
container
build
process
or
source
image,
it
kind
of
gets
used
in
the
background
right.
So
the
integrated
registry
doesn't
really
have
a
ui
in
the
sense
you
just
use
it
indirectly,
via
openshift
features
like
image
streams
and
build
configs
and
image
stream
tags.
A
B
A
Creating
credentials
defining
what
these
users
can
see
and
don't
see
and
then
distribute
those
credentials
to
the
cluster.
All
that
happens
automatically
with
integrated
registry.
You
never
have
to
worry
about
pull
secrets
or
permissions
or
repositories
namespaces
that
need
to
get
created
up
front
all
this
happens.
You
know
in
soon
when
you
create
projects
in
openshift
and
image
streams
and
openshift,
and
you
start
to
use
those
right.
A
So
the
one
caveat,
though,
is,
is
that
the
whole
concept
of
this
integrated
registry
is
the
whole
context,
is
really
just
that
one
cluster
right,
so
it
lives
inside
that
cluster.
You
can
technically
export
it.
So
others
can,
you
know,
push
to
it
or
pull
content
from,
but
it
is
not
meant
to
be
used
outside
of
the
cluster,
in
the
sense
that
you
have
a
multi-tenancy
scenario,
because
the
tendency
of
this
integrated
registry
is
really
tied
to
that
cluster.
A
So,
in
order
to
make
other
clusters
use
that
you
would
need
to
be
able
to
do
things
like
permission
management,
you
know
creating
our
back
definitions,
creating
users,
user
groups,
please
put
them
into
a
sort
of
a
bucket.
That's
called
a
namespace
in
registry
or
an
organization
as
we
call
it.
So
that's
these
are
things
that
aren't
possible
with
the
internal
registry
because
it's
not
supposed
to
be
used
outside
of
the
overshift
apis.
A
So
the
moment
you
want
to
have
something
central.
You
need
to
do
a
little
bit
more
setup
right
and
we
think
having
a
central
registry
is
sort
of
a
common
architectural
pattern
that
we'll
see
way
more
in
the
future.
So
I'm
going
to
share
a
slide
here,
real
quick
just
to
show
that
so
we
see
red
hat
quay
as
such,
an
integrated
external
central
registry
to
openshift
multi-cluster
deployments,
and
this
has
various
benefits
right.
A
So
one
of
the
benefits
is
that
you
manage
all
your
content,
all
the
definitions
of
who
your
users
are,
which
teams
they
belong
to
which
access
rights
they
have
to
the
various
content
in
the
registry.
You
manage
all
of
that
in
a
single
place
right,
so
you
can
see
all
the
content
in
a
single
place
as
well.
You
can
see
what
exists,
what
versions
of
images
are
available
and
you
can
also
see
inside
those
images
with
clay.
So
quay
does
not
only
store
and
serve
your
images
according
to
permissions
that
you
set
up.
A
It
also
scans
the
images
and
indexes
the
content
inside,
so
it
can
recognize
rpms,
debian
package
files,
alpine
package
files,
but
even
python
pip
packages
or
most
recently
added
is
tech,
preview,
java
archives
and
it
will
index
information,
and
one
reason
it
does.
That
is,
is
in
order
to
tell
you
when
those
components
have
known
security,
vulnerabilities,
so
quay,
also
scans
your
images
for
cves
and
to
give
you
a
an
analysis
of
the
security
posture
that
you
have
from
the
content
perspective
before
anything
even
hits
the
cluster
right.
A
So
that's
that's
a
pretty
central
aspect
and
the
moment
you
have
multiple
clusters,
multiple
providers
and
even
maybe
from
multiple
vendors.
You
definitely
want
to
have
something
as
central
as
that,
but
when
you
do
that,
you
also
kind
of
put
all
your
axe
in
one
basket
right,
which
is
you
know,
operationally
sort
of
something
you
need
to
plan
for
and
account
for.
Such
a
registry
cannot
be
done
like
even
for
five
minutes
so
like
if
the
internal
registry
is
down
in
an
openshift
cluster.
A
Well,
that
will
only
impact
workloads
that
come
from
that
internal
registry,
so
you
know
image
streams
that
you've
imported
or
things
that
you've
built
inside
the
cluster.
But
if
you
connect
a
comp,
an
entire
op
shift
cluster,
multiple
of
those
to
a
central
registry.
That
means
also
the
images
that
the
cluster
itself
uses
come
from
that
registry
right,
and
you
want
that
because
you
want
to
centrally
manage
which
openshift
versions
are
available
to
install,
which
openshift
versions
you
can
update
to
which
applications
operators
are
available.
A
So
all
this
needs
to
have
basically,
the
uptime
of
the
red
hat
registry
that
you
would
normally
use
to
to
do
these
things
right
so
and
quays
architecture
is,
is
very
well
primed
for
this
kind
of
h,
a
scenario
I
said
earlier
that
we
run
quay
io
the
service
on
the
same
code
base.
We
run
it
really
in
the
same
architecture
as
well
as
a
product
in
the
cluster
as
well.
So
you
can
run
clay
in
an
openshift
cluster
as
a
workload
management
operator,
but
also
on
rail
nodes.
B
B
A
The
same
scale
out
architecture,
the
same
age,
a
architecture
that
you
know
can
scale
like
from
a
couple
of
handful
of
clusters
to
hundreds
of
clusters
from
a
performance
perspective
right
so
and-
and
that
is
something
you
really
need
if
you
are
going
to
have
a
central
registry.
Okay.
So
when
you
have
that,
you
also
start
to
have
questions
about
well,
what
happens
if,
let's
say
one
of
these
clusters
here
is
very
far
away.
A
B
A
B
A
You
get
this
basically
out
of
the
box
for
free,
and
you
have
a
really
really
robust
registry
at
hand
which
you
really
need,
because
the
moment
your
registry
is
down,
you
will
notice
within
your
clusters,
basically
within
five
minutes
so
like
there
are
so
many
events
in
the
cluster
that
need
to
talk
to
a
registry
that
it
ranges
from.
You
can't
reconfigure
yourself
there
you
can't
scale
out
your
deployments.
A
You
can't
change
your
cluster
configuration.
You
cannot
expand
your
cluster
by
additional
nodes.
Nodes
cannot
even
reboot.
If
the
registry,
the
cluster
is
served
from,
is,
is
momentarily
down,
so
it's
pretty
impactful
right,
so
uptime
is
really
important
and
quay
delivers
that
very
confidently
across
multiple
clusters,
and
that's
why
we
can
have
such
a
central
approach
to
all
of
this.
B
Okay,
so
yeah
thanks
a
lot
daniel.
So
just
to
to
summarize
one
of
the
key
compo
core
features
I
hear
here
is
that
it
allows
you
to
have
a
central
repository
that,
because
it's
becoming
such
an
crucial
part
of
your
architecture
and
of
your
clusters,
it
needs
to
be,
and
also
if
you
have
clusters
spread
out
around
the
planet.
B
Maybe
you
are
in
different
geographies
and
you
have
some
in
apex
some
in
the
u.s,
some
in
europe,
for
instance,
having
all
the
clusters
talk
to
a
single
located
registry
doesn't
really
play
in
terms
of
having
great
performances.
So
what
I'm
hearing
here
is
that
you
can
have
geo-replicated
instances
that
have
all
the
content
that
is
mirrored
across
all
those
local
registries,
but
it's
managed
centrally
still
you
don't
have
to
manually.
B
So
yeah,
that's
I
mean
that's,
that's
a
pretty
good
reason
actually
to
switch
to
using
such
a
kind
of
registry.
So
before
we
go
into
a
demonstration.
Actually
we
have
a
question
so
some
someone
says
I
tried
to
install
the
query
operator
on
my
home
lab
and
the
resource
requirements
were
a
bit
too
high
for
small
nodes.
B
A
But
in
general
you
know
you
will
not
really
get
below
a
requirement
of
at
least
two
vcbus
and
six
cores
for
quay.
If
you
enable
clear
security
image
scanning,
that
will
be
another
two
cores,
and
at
least
four
gigs
of
memory
quay
and
clear.
The
scanning
engine
need
both
need
databases,
so
these
need
to
be
postgres
databases.
They
usually
come
with
at
least
two
to
four
gig
of
memory
as
well,
and
at
least
one
vcpu
for
the
clear
database.
A
So
if
you,
if
you
like,
disable
some
of
these
features,
you
will
save
on
some
resources
and
if
you
just
want
to
use
mirroring,
then
you
can
certainly
disable
a
couple
of
things
like
that.
But
I
would
say
the
operator-based
deployment
is
probably
is
potentially
always
going
to
be
a
little
bit
more
difficult
in
an
edge
scenario
for
edge
deployments.
We
have
actually
released
the
the
packaged
version
of
quay,
where
just
a
minimal
instance
of
quay
gets
deployed.
A
We
call
this
the
mirror
registry
for
openshift,
and
the
use
case
here
is
to
really
provide
a
bootstrap
registry
for
an
edge
cluster
that
has
no
direct
connectivity
to
a
central
data
center.
So
it
relies
on
this
registry
to
have
the
openshift
core
images
for
installation
and
running
the
cluster
inside,
and
for
that
we
have
the
mirror
registry,
which
is
really
a
simplified
installer
running
on
a
rail
8
node
deploying
quay
in
part,
man
containers
spotlight
parts
actually
for
you,
so
that
has
a
simple
requirement:
2
vc
views
and
6g
of
memory.
A
B
A
A
B
Yeah
thanks
thanks
daniel.
So
that's
a
very
extensive
answer.
I
mean
having
also
gone
through
that
there's
a
lot
of
very
point
on
topics
that
you
have
addressed.
I'm
not
sure
if
stefan
is
very
familiar
with
that,
but
yeah,
basically
the
hpa.
The
horizontal,
auto
scaler
is
responsible
for
reserving
those
amounts
of
resources
and
you
can
lower
it.
But
basically,
I
would
say
the
query
operator
is
intended
for
production
use.
B
So
if
the
end
goal
is
really
to
try
quay
and
in,
I
would
say,
non-production
and
very
minimal
footprint
without
using
the
the
scan
or
such
things,
there's
a
section
in
the
documentation
where
we
can
deploy
quay
for
poc
and
you
can
actually
just
run
quay
in
a
container,
and
you
know
just
having
palm
and
run
the
clay
registering
itself
and
you
can
play
with
it.
So
this
is
going
to
to
take
even
much
lower
resources.
B
If,
if,
if
you
wanted
to
try
that
stephen,
so
yeah
there's
all
kinds
of
possibilities,
but
again
the
operator
has
some
advanced
capabilities
and
it's
aimed
at,
I
would
say,
providing
a
production
grade
registry
and
that's
that's.
Why
there's
this
this
notion
of
resources,
requests
and
such
things
all
right?
So
thanks
very
interesting
question
and
thanks
daniel
for
the
for
the
detailed
answer.
B
B
Okay,
so
what
I
have
here
is
an
openshift
cluster
that
has
actually
a
quay
instance
running
on
it.
So
there's,
as
you
can
see
here,
a
route
that
will
take
us
to
the
queen
that
is
hosted
within
this
platform.
It
has
been
installed
with
the
que
operator
and,
as
we
can
see
here,
we
have
already
some
repositories
that
have
been
created
in
the
registry
and
there
are
some
organizations
and
users
that
have
been
already
set
up
with
the
platform.
B
B
B
So
I'm
going
to
choose
to
use
a
builder
image
and
what
this
image
does
is
it's
going
to
use
the
what
we
call
the
source
to
image
process
that
will
turn
my
git
code
into
a
container
image
that
is
going
to
be
pushed
to
the
default
registry
that
comes
with
openshift
is
if
we
are
doing
things
by
default,
so
yeah.
Let's
just
give
it
a
name
here
so
for
level
up
node,
for
instance,
and
again
level
up
node.
So
it's
going
to
create
the
deployment
etc.
B
B
B
So
we
can
see
here
that
it
also
created
an
organization
and
it
created
some
users
for
us
to
be
able
to
build
the
images
to
deploy
them
and
to
pull
them
from
this
registry
back
into
openshift,
so
yeah.
While
everything
goes,
I
mean
splc
and
pushed
okay,
so
it
seems
everything
is,
is
complete.
Let's,
let's
have
a
look
at
the
the
the
repository
that
has
been
created.
B
We
can
see
that
it
has
pushed
a
latest
tag
image
a
minute
ago
and
it
has
also
run
some
security
scans
for
it.
So
I
mean
that's
pretty
impressive,
because
I
I
didn't
have
to
set
up
anything
for
this
to
work,
although
this
is
not
using
the
internal
registry,
this
is
using
the
external
quay
that
happens
to
run
on
the
cluster
itself,
but
it
could
run
anywhere.
It
could
be
quay
io.
It
could
be
a
central
query
elsewhere.
A
Sure
I
guess
you
can
already
guess
that
since
I'm,
you
know
as
a
product
manager
looking
after
quay
and
also
part
of
the
operator
framework,
it
has
to
do
with
operators
right.
So
there's
actually
an
operator
installed
on
the
cluster
that
you
were
starting
to
build
on,
and
it's
called
the
quay
bridge
operator
and.
A
So
on
so
this
is
pretty
much
the
magic
right,
so
its
job
is
to
essentially
replicate
the
same
user
experience
you
previously
had
with
the
internal
registry,
which
means
you
can
store
your
images.
Whenever
we
need
it,
you
can
retrieve
them
whenever
they
need
it.
You
never
need
to
worry
about
getting
credentials
first,
setting
that
up
in
your
cluster
pre-creating
a
landing
zone
in
the
registry.
So,
let's
say
all
of
it
just
happens
in
the
background
right,
so
this
operator
basically
talks
to
koi.
You
configure
it
with
a
custom
resource.
A
That's
called
core
integration,
so
if
you
want
to
click
that
you
have
one
there,
so
this
is
how
you
configure
this
operator
and
what
you
tell
the
operator
here
is.
Basically,
where
is
your
quay
registry
that
you
want
to
integrate
with
right?
Where
is
the
url?
What
are
the
credentials-
and
you
configure
also
your
cluster
id
here-
this
will
be
used
as
a
prefix
for
anything
that
is
created
as
part
of
automation
in
that
registry.
A
B
A
Can
also
give
the
operator
like
a
unique
prefix
per
cluster
here
to
avoid
any
collisions,
and
you
can
totally
have
dozens
of
clusters
running
the
bridge
operator
with
just
one
coin
instance.
So
the
fact
that
this
way
registry
runs
on
your
cluster
is
totally
transparent.
It
could
run
anywhere
right,
but
here
you
basically
tell
the
operator
where
to
find
the
registry,
how
to
authenticate
to
it
and
what
prefix
to
use
to
create
stuff
there.
A
A
Yeah,
that's
another
configuration
option
so
so
by
default,
this
operator
will
watch
for
a
couple
of
things
to
happen
in
the
cluster.
So,
for
instance,
whenever
you
create
a
project
in
openshift,
it
will
create
that
organization.
So
when
you
created
that
project
called
level
up
earlier,
it
actually
already
created
the
organization.
The
organization.
A
A
B
So
another
question:
is
it
possible
to
have
multiple
query
integrations
running
on
the
same
cluster
directing
or
targeting
different
registries
or
targeting?
So,
for
instance,
I
have
10
namespaces
that
I
want
to
push
to
this
specific
way,
or
instance,
or
maybe
I
want
to
prefix
them
with
something
different.
B
A
Yeah,
that
makes
sense
to
be
honest
with
you.
That's
an
extremely
interesting
question.
I
haven't
gotten
so
far,
so
most
of
our
users
basically
use
one
central
registry,
okay-
and
I
have
the
cluster
prefix
actually
determined
by
the
operator
itself,
so
it
would
use
the
overshift
cluster
id
for
that.
Okay,
but
I
guess
in
theory.
Yes,
that
would
be
how
it
works.
I'm
not
sure,
though
I
have
never
tried
it.
A
Okay
and
it's
not
the
way
we
test
it,
but
since
the
operator
really
just
reacts
to
these
events
and
sets
up
watches,
I
think
that
could
be
an
option.
We
might
need
to
try
that
first,
but
okay
yeah,
what
most
users
really
are
doing
is
like
setting
it
up
to
one
central
registry
and
then
let
the
prefix
magic
do
its
work.
B
All
right,
okay,
so
thanks!
So
basically
this
is
the
I
would
say
the
magic.
Can
you
tell
us
a
bit
more?
What
happens
in
in
the
background
so
say,
for
instance,
I
have
so
traditionally
when
we
are
using
the
the
default
openshift
registry
is
going
to
create
some
some
things
that
are
specific
to
openshift,
like
like
image
streams
and
image
stream
tags.
So
these
are
basically
pointers
to
to
the
images.
So
with
openshift
we
don't
directly
use
the
docker
pull
spec
or
the
container
the
image
pull
spec
hardened
it's.
A
A
A
Created
in
quay
with
the
prefix
in
the
same
name
as
the
project,
what
also
happens
is
that
whenever
you
create
an
image
stream,
a
repository
in
that
organization
in
kuwait
will
be
created.
So
remember
like
the
project
name
and
openshift
maps
to
the
organization
name
and
image
stream
in
that
openshift
project
will
create
a
repository
in
quay.
So
if
you
go
back
to
quay,
you
see
that
within
openshift
level
up
it
has
created
this
repository
called
level
up,
node
right.
So.
B
B
A
Instead
of
the
internal
registry,
so
if
you
were
to
actually
repeat
the
build
on
the
node.js
app
that
you
had
before,
we
can
just
do
that.
It
would
actually
create
a
new
image.
I
think
actions
and
then,
when
I
go
to
build,
config
run
that
one
again
and
when
that's
happening,
it's
actually
going
to
push
another
image.
A
A
A
A
So
you
see
here,
it
has
now
pushed
a
newer
tag,
and
if
you
go
in
the
left-hand
navigation
pane
to
that
little
clock
icon,
you
can
see
that
it
actually
moved
the
tag
right,
because
now
the
tag
was
pointing
to
something
newer,
which
is
that
newer
shot.
You
also
see
that
there's
a
the
ability
to
revert
that
so
quay
has
a
time
machine
feature
that
allows
you
to
revert
those
tag
overrides
in
case.
B
A
A
Registry
does
that
just
out
of
the
box
right,
but
it
also
nicely
integrates,
as
we
have
seen
with
that
flow,
that
you
usually
have
with
s2i
and
build
configs
and
really
put
stuff
in
there
so
yeah.
So
this
is
happening
all
the
time
when
you
do
a
build
now
that
is
associated
to
such
an
image
stream
and,
as
you
have
seen
it
already
rolled
out
that
new
image.
So
if
you
go
to
your
project,
you
should
see
that
that
deployment
has
actually
been
wrapped
and
has
now
updated.
B
A
B
B
B
That's
awesome:
yeah
thanks
thanks
a
lot
daniel
for
going
to
those
detailed
features
so
so
yeah.
Basically,
everything
has
happened
automatically
thanks
to
the
quay
bridge
operator,
intercepting
those
openshift
events
and
and
transforming
them
into.
I
mean
talking
to
the
api
and
creating
things
like
the
organizations,
the
users,
the
secrets
to
be
able
to
pull
and
and
push
the
the
images
per
namespace
etc.
B
So
so
what
does
what
this
means
is
that
if
I
wanted
to
use
an
external
registry
which
is
not
like
quay,
these
are
things
that
I
should
do
manually.
Is
that
correct?
I
mean
that's
exactly
the
same
as
as
with
any
kubernetes
cluster,
when
you
want
to
configure
an
integration
from
kubernetes
to
an
external
registry.
B
B
If
that
notion
exists
in
in
the
registry,
and
I
will
have
to
create
all
those
secrets,
I
will
have
to
create
the
service
accounts
or
what
we
call
the
robot
robot
manually.
So
so
this
is
also
possible.
With
I
mean
it's
possible
to
use
an
external
registry
other
than
quay,
except
that
we
would
not
benefit
from
this
automation,
and
we
will
have
to
create
all
of
those
things
manually,
as
we
would
do
with
with
an
open
shift
with
the
kubernetes
traditional
cluster.
A
A
The
admin
perspective
yeah,
so
it
doesn't
show
anything
now,
but
in
probably
10
minutes
or
so
or
to
show
image
vulnerabilities
here,
because
you're
running
an
image
that
has
vulnerabilities
in
in
quay.
So
if
you
go
switch
back
to
the
quay
view,
you
will
have
seen
that
kwait
told
you
that
there
are
like
six
high
vulnerabilities
in.
B
A
And
the
total
numbers
is
probably
higher
right
is
51
medium
as
well,
so
these
are
all
the
cdes
that
quay
has
found
inside
that
image.
So
these
are
packages
that
have
known
vulnerabilities
that
can
be
exploited
and
quay
will
tell
you
what
those
are,
and
it
will
also
tell
you,
which
component
has
that
vulnerability.
So
we
see
here
there's
obviously
a
python
library
called
url
lib
free
that
has
vulnerability
or
there's
a
vulnerable
bin
minimal
executable
in
that
container
image.
A
So
this
is
information
that
you
want
to
have
as
a
admin
or
as
a
developer
of
these
images.
To
kind
of
reduce
your
attack.
Surface
way
also
tells
you
in
which
newer
version
of
that
package-
this
is
actually
been
fixed.
So
this
propagation
of
vulnerabilities
is
asynchronous,
so
it
will
take
a
little
while
per
image,
but
you
can
see.
B
A
Right,
yeah,
that
will
tell
you
which
parts
are
affected
by
this.
So
this
is
an
image,
that's
vulnerable,
but
you
know
the
running
part
is
what
counts
right.
So
there's
apparently
like
a
single
part
here
that
runs
this
and
could
be
more
than
one
right,
but
what
this
does
is
essentially
looking
at
all
the
parts
running
in
your
cluster
and
figuring
out.
A
If
they
come
from
images
that
are
served
by
a
quay
registry,
it
could
be
quite
a
dio
could
be
your
query
here
on
a
cluster,
an
external
quiz
somewhere
else,
and
when
that's
the
case,
it
will
interrogate
that
query
instance
for
any
vulnerabilities
that
these
image
might
have
been
repeating
as
part
of
the
scanning.
So
this
is
not
scanning
in
the
cluster.
A
It's
basically
just
asking
quay
for
the
scan
results
and
soon
your
nginx
will
pop
up
here
like
the
one
from
cmec
there,
so
that
kind
of
projects,
all
the
vulnerability
information
right
inside
your
console,
so
that
you
can
see
what
is
the
vulnerable
stuff
that
you
are
running
and
what
is
where
is
it
running
and
who
does
it
belong
to
right
so
as
an
admin
that
would
be
pretty
handy
again.
This
is
live
scanning
in
the
cluster.
Already
everything
has
been.
A
B
A
Yeah
or
if
you
scroll
down,
there's
actually
a
bunch
of
details
already
in
this
view,
so
you'll
see
also
which
packages
have
been
identified,
which
cbe
or
redhead
security
advisory
is
actually
associated
to
that
in
which
newer
version
of
the
package-
it's
it's
it's
fixed,
so
this
seems
to
come
from
a
fairly
old
rel7
base
image.
That's
why
it
has
so
many
vulnerabilities,
and
that
really
shows
you,
the
value
of
you
know.
Rebuilding
your
images
very
regularly
of
newer
base.
A
Images
and
ubi
is
really
really
nice
to
do
to
use
for
that,
because
it
gets
updated
extremely
often
by
red
hat,
and
you
just
need
to
rebuild
your
image
of
a
newer
ubi
version.
You
don't
backcode
stuff
in
uei.
It
always
rolls
forward,
but
we
have
floating
tags
like
ubi
8
that
always
point
to
the
latest.
Ubi8
version.
That's
out
there,
if
you
rebuild
on
top
of
that,
you
will
essentially
always
be
able
to
maybe
educate
a
lot
of
cpes
that
are
just
part
of
the
base
image
that
aren't
even
part
of
your
organization
right.
A
So
having
that
view
is
super
useful,
it's
just
static
image
analysis,
so
it
doesn't.
Do
a
whole
lot
of
contextual
analysis
like
our
acs
product
does,
but
you
kind
of
get
it
with
quay.
As
part
of
another
operator,
that's
called
the
quay
security
operator,
which
is
also
installed
in
this
cluster,
which
makes
all
this
ui
integration
happen.
B
But
again
it
does
bring
a
lot
more
features.
This
notion
of
h.a,
the
security
scanning
capabilities,
the
geo
location
so
yeah,
and
the
fact
that
the
openshift
experience
remains
untouched
is,
I
think,
a
really
awesome
experience,
because,
as
an
openshift
user,
even
if
I
switch
to
que
it's
gonna
be
transparent
to
me,
I
don't
have
to
like
recreate
or
rewire
image
stream
tags
to
point
out
to
the
to
the
outside
registry.
B
So
basically,
if
you
want
to
to
look
at
it,
let's
go
to
user
management,
for
instance,
and
switch
to
our
level
up
pro
namespace,
and
we
see
here
in
the
service
accounts
that
we
have
a
builder
service
account.
This
is
the
one
that
is
used
by
default
by
openshift
whenever
we
kick
off
a
build
process,
so
here,
for
instance,
we
see
yeah,
we
see.
B
B
B
So
this
is
a
a
build
config
that
I
have
manually
changed
before
installing
the
query
of
operator.
So
basically
I
created
the
app
in
openshift,
but
I
had
to
manually
change
the
output
docker
reference
to
to
point
out
to
this.
My
app
node.js
repository
that
I
have
created
manually
also
on
the
external
registry.
B
So,
basically,
if
you
are
using
the
external
registry,
which
is
not
query
and
not
with
the
bridge,
these
are
the
things
that
you
have
to
to
to
do.
You
have
to
change
basically,
those
output
settings
to
say
this
is
the
tag
or
the
pull
spec
that
you
need
to
to
push
to,
and
these
are
the
secrets
that
you
need
to
to
to
use
to
be
able
to
authenticate
to
that
external
registry.
A
Thanks
jafar,
no,
I
think
this
this.
This
was
a
pretty
comprehensive
overview,
so
going
from
the
internal
registry
to
an
external
one,
you
know
explaining
why
that
is
a
good
idea.
But
what
is
the
management
over
that
comes
with
that
and
how
you
can
lower
that
with
something
like
an
operator
and
also
get
some
of
the
unique
registry
features
right
into
the
cluster
with
another
operator.
B
All
right,
yeah
thanks,
so
I
just
wanted
to
show
something
from
an
admin
perspective
on
how
you
need
to
manage
the
cluster
configuration
to
to
point
out
two
different
registries.
So
we
have
something
custom,
resource
or
custom
resource
definition.
We
have
created
for
openshift
that
you
need
to
use
in
order
to
administrate
the
registries
and
basically,
if
you
wanted
to
add
an
external
registry,
you
would
have
to,
for
instance,
if
it's
an
insecure
registry.
B
B
A
Right
and
and
to
add
to
that
this
is
so,
the
insecure
part
is
really
needed
if
you
have
a
self-signed
tls
certificate
in
place
correct,
so
what
I
find
most
customers
are
doing
is
like
they
trust
the
ca
that
openshift
uses
to
generate
those
certificates.
The
openshift
ca
is
generally
trusted.
If
that's
in
place,
and
you
run
quay
on
top
of
openshift,
it
will
automatically
create
a
route
endpoint
by
the
operator
and
that
will
have
a
certificate
that's
signed
by
that
trusted
ca.
So
it's
usually.
A
B
Cool
so
yeah.
Maybe
we
can
talk
about
that
for
another
topic,
but
there's
a
search,
cert
manager
operator
that
we
can
use
to
delegate
the
certificate
management
for
some
of
these
components.
So
we
do
that
natively
for
the
openshift
components
and
for
all
the
ingresses
and
droughts
that
we
create
using
the
the
trusted
ca
with
the
openstack
cluster,
but
yeah.
If
we
wanted
to
delegate
that,
for
example,
to
let's
encrypt
or
whatever,
we
could
also
go
the
search
manager
path
and
and
use
that
operator
to
do
this
kind
of
things
all
right.
B
B
We
call
it
the
custom
registry,
but
it's
a
way
to
actually
say
not
using
the
default
registry
that
comes
with
openshift,
so
yeah
thanks
a
lot
and
great
job
on
what
you
guys
did
with
the
with
the
quay
operator
and
the
bridge,
because
it
makes
it
very
transparent
in
terms
of
usage
and
still
brings
all
the
quay
capabilities
to
to
openshift
seamlessly
all
right
thanks
a
lot.
I
think
we
are
just
a
little
bit
over
time,
but
we
started
also
a
little
bit
later.