►
From YouTube: Securing GitOps Supply Chain with Sigstore and Kyverno - Roberto Carratala & Faz Sadeghi, Red Hat
Description
Securing GitOps Supply Chain with Sigstore and Kyverno - Roberto Carratala & Faz Sadeghi, Red Hat
In this session, we will present how to secure GitOps supply chain by signing and verifying container images within the Argo Workflows pipelines, using open source projects such as Sigstore and Kyverno. We will demonstrate how to eliminate security risks on the software supply chain by signing all container images in public or private registries and ensuring no malicious images are deployed in Kubernetes clusters.
A
We
don't
really
have
too
much
time
to
think
about
security,
but
it's
worked
for
us
so
far.
You
know
we're
developers
we
develop
and
we
deliver
and
it's
working
we're
meeting
our
deadlines,
so
we're
not
bothering
about
that
just
yet
now,
like
I
said
our
release
date
was
today.
The
latest
version
of
our
app
is
already
deployed
and
if
you'd
like
to
see
what
our
app
looks
like,
please
take
your
phones
out
and
scan
that
qr
code
on
the
screen.
A
Is
it
okay
at
the
back?
Can
you
can
you
scan
it?
Okay
right?
So,
if
you've
already
scanned
the
qr
code,
you'll
be
able
to
see
that's
the
open
source
client
we're
working
with.
We
are
developing
the
web
application
for
the
argocon
event,
organizers,
we're
going
to
show
you
how
our
workflows
in
argo
workflows
look
like
in
a
minute,
but
just
on
a
high
level.
So
you
know
what
steps
are
involved
in
our
workflow,
so
we
first
do
a
git
clone
in
our
workflow.
A
B
So
the
first
thing
that
we
need
to
do
is
to
deploy
the
new
pipeline
that
we
are
already
showing
and
we
will
kick
the
second
pipeline
using
the
exact
same
workload
template
we
have
our
our
workflows,
ui
and,
as
you
can
see,
we
are
running
the
cst
pipeline
and
we
will
show
the
cst
pipeline
that
we
already
deployed
before
to
run
and
deploy
our
application
in
our
kubernetes
clusters.
So
we
have
three
different
steps.
We
have
the
git
clone,
we
have
the
container
builds
and
we
have
also
the
apply
manifest
and
update
manifest.
B
B
We
are
building
the
container
and
pushing
this
container
to
the
github
registry
as
well,
and
after
that
we
are
using
the
version
one,
because
this
is
the
version
one
deployment
and
also
we
are
applying
the
different
manifest
within
the
repository
and
as
you
can
see,
the
final
step
will
set
the
image
and
we
will
update
the
image
deploying
our
final
destination
and
our
final
image
as
well.
As
you
can
see,
we
have
the
github
registry
that
is
already
pushed
and
we
already
have
the
second
version,
so
we
run
the
exact
same
pipeline
as
well.
B
That
is
running
in
this
moment,
so
the
exact
same
pipeline
is
happening.
We
have
the
git
clone.
We
have
also
the
container
build.
This
container
build
is
the
exact
same
thing,
but
we
are
storing.
For
example,
we
pushed
this
to
the
race
review
using
the
version
g,
because
we
are
releasing
a
new
version
and
also
we
apply
the
different
manifests
and
another.
It's
updating
the
different
deployments
and
using
this
to
deploy
our
application.
A
B
B
So
the
first
thing
that
we
can
see
is
our
source
code
was
compromised
and
somebody,
a
group
of
hackers,
tried
to
ask
for
money
and
asked
a
ransomware
of
two
million
coins
and
they
also
compromised
the
dockerfile
as
well
introducing
some
changes
and
they
also
hack
the
supply
chain
and
as
you,
we
can
check
that
we
have
compromised
and
they
changed
the
base
image,
and
now
they
are
using
a
base
image
that
contains
the
cves
avactos.
That
compromise,
not
only
this
base
image,
also
the
whole
cluster.
A
This
is
often
described
as
a
more
mature
type
of
cyber
security
attack.
Exactly
for
that
reason,
because
it's
a
lot
more
impactful
than
just
attacking
one
single
target,
you
attack
a
third
party
provider
and,
as
a
result,
you're
reaching
thousands
of
people
or
thousands
of
end
users,
and
as
a
result
of
that,
so
it
turns
out
the
docker
image
that
we
were
using
was
downloaded
from
docker
hub,
and
that
was
the
sort
of
our
compromise
and,
as
a
result,
anything
we
built
on
top
of
that
image
was
compromised
as
well.
A
A
A
A
What
happened
in
solarwinds
was
that
a
group
of
russian
attackers
called
cozybear.
They
got
held
a
hold
of
the
update
server
of
solarwinds,
which
is
a
very
popular
network
monitoring
tool
and,
and
they
just
injected
some
malicious
software
into
the
update
server
and
as
a
result
of
that
over
18
000
organizations
who
use
that
update
were
affected.
A
It's
somehow
reported
that
the
cost
of
recovery
from
solarwinds
could
be
something
in
upwards
of
100
billion
dollars.
Another
example
of
supply
chain
attacks
is
what
happened
to
another
network
monitoring
suffer
which
was
kasaya
again.
They
got
hacked
and
then
the
hackers
were
asking
for
70
million
dollars
in
bitcoin
in
exchange
for
the
universal
decryption
key
another
widespread.
A
Perhaps
the
most
widespread
example
of
these
attacks
is
the
lac
4j.
The
reason
is
the
most
widespread
is
because
in
block4j
is
a
very
popular
logging
library
for
java
applications,
as
we
know,
and
a
lot
of
applications
out,
there
are
using
java.
So
it's
it's
the
most
widespread
it's
described
as
the
most
widespread.
A
B
So
the
answer
of
securing
this
software
supply
chain
lies
in
digital
signing
the
various
artifacts
that
comprises
these
applications,
but
there
are
several
challenges
facing
this
software
supply
chain,
because
sometimes,
and
especially
in
the
open
source
projects,
the
budget
for
these
digital
tools
is
very,
very
low
or
non-existent.
For
example,
and
the
software
it
itself
is
changing
very
frequently,
and
the
management
of
these
private
keys
are
challenging
so
sixto.
That
is
a
project
of
the
linux
foundation.
It's
a
new
approach
for
signing
verifying
and
protecting
software.
B
It
offers
a
set
of
tools
that
the
different
developers
can
use
to
sign
the
software
releases
and,
on
the
other
hand,
also,
the
users
can
use
it
for
verify
these
signatures
as
well,
and
we
have
three
major
components
in
the
six
show.
Project
first
is
record
cosign
and
full
seo
record
is
a
built-in
transparency
and
time
sample
service.
A
So
we're
using
six
store
in
order
to
sign
our
images
and
push
our
signatures,
but
we
still
need
another
product
in
order
to
be
be
able
to
verify
those
signatures
against
our
images,
and
this
is
why
kivarna
comes
into
play.
Kevono
is
a
greek
word
and
it
means
to
govern
and
it's
a
product
which
is
a
kubernetes
policy
engine
and
as
a
kubernetes
policy
engine
it
allows
you
to
verify
and
mutate
or
generate
kubernetes
resources.
A
One
of
the
most
attractive
features
of
kiverno
is
the
fact
that
it's
all
in
yamo,
so
if
you're,
already
familiar
and
working
with
kubernetes,
there's
no
need
to
learn
a
new
language.
It's
it's
already
there
and
the
good
thing
about
yaml
is
that
as
human
beings,
we
pretty
much
could
understand
what
the
hood
does
just
by
looking
at
the
few
lines
of
the
ammo.
Now,
if
you
look
at
that
chord,
we've
got
one
more
red
hat
t-shirt
to
go.
If
anyone
would
like
to
share
what
they
think.
A
A
B
So
to
secure
the
supply
chain,
we
are
using
different
tooling
that
we
have
in
this
picture.
We
have
our
workflows,
cosine,
kaverno
and
arco
cd,
our
workflows,
we
already
discussed
and
show
the
ui
as
well
for
running
the
different
pipelines
that
we
have
also.
We
are
using
cosine
for
signing
and
pushing
the
different
signatures
to
the
github
registry.
B
B
One
is
the
argo
workflows
we
have
all
the
deploying
kyverno
and
finally,
the
wall,
flux
and
blades
as
well,
and
we
have
these
auto
app
of
apps
pattern
that
it's
managing
the
different
argo
cd
applications
as
well,
and
if
we
go
to
the
workflow
templates,
we
will
see
that
ago,
cd
is
managing
the
different
building
blocks
and
that
we
already
have
in
this
pipeline
and
we
have
different.
For
example,
in
this
case,
we
have
the
sign
image,
that
is,
a
warfare
template
and
is
fully
managed
and
fully
deployed
using
itops
and
ago
cd.
B
So,
if
we
go
directly
to
the
workload
templates,
we
can
see
different
things
and
also
two
different
ci
cd
workflows,
so
we
will
deploy
the
next
first.
We
need
to
deploy
the
policy,
and
this
policy
is,
as
you
saw
before,
a
policy
that
it's
a
cluster
policy
for
checking
the
image
against
a
public
image
and,
on
the
other
hand,
we
will
kicked
another
pipeline.
That
includes,
in
this
case
this
sign
image.
B
This
sign
image:
it's
in
step
that
additionally
will
use
cosign
for
signing
using
a
private
key
the
image
and
will
automatically
push
the
signature
against
the
github
reboot.
So
in
this
case,
in
the
github
repository
we
will
have
and
in
the
github
container
register
as
well,
we
will
have
two
different
things.
First,
we'll
have
the
image
and
also
the
signature,
because
we
are
using
this
for
pushing
the
signature
as
well
as
you
can
see
that
it's
running
properly
and
it's
cloning,
the
repo
and
we
can
see
the
different
steps.
A
So,
with
the
workflow
that
roberto
just
run,
we
are
rewinding
to
the
first
step
when
I
started
studying
the
story
about
deploying
our
application.
But
the
difference
is
this
time.
Rather
than
ignoring
security,
we
are
imp
implementing
those
security
steps
which
are
signing
our
images
and
then
verifying
them
against
the
same
signatures
here.
A
So,
instead
of
doing
the
steps
that
we
were
doing,
which
was
the
git
clone,
build
and
then
push
and
deploy
to
kubernetes,
now
we're
doing
the
git
clone
we're
building
our
image
and
now
using
six
store
resigning
the
image
and
also
pushing
the
signature
to
our
container
registry
as
well
and
using
kiverno
as
we
just
saw.
Then
we
verify
these
images
against
the
public
key
that
we
hold
and
based
on
that,
we
decide
whether
we
want
to
deploy
into
kubernetes
or
not.
B
B
Then
we
have
the
sign
image
at
recommended.
Design
image
is
signing
the
container
image
that
we
already
deployed
pushed
to
the
github
registry
and
is
pushing
also
the
signature
into
the
github
registry
as
well,
and
if
we
check
the
github
repository,
we
will
see
first
that
we
already
have
our
container
image
with
this
specific
tag
and
also
alongside
we
have
the
second
signature
that
if
we
checked
matches
with
that,
so
in
this
pipeline
we
are
first
building
the
container
image
and
pushing
the
signature
to
the
github
registry
and
also
kiberno.
B
A
Now,
let's
go
back
to
the
scenario
that
we
had
to
release
under
pressure
and
we
were
ignoring
security
because
we
didn't
have
time
for
it,
but
then
we
got
hacked
and
then
we
realized.
Now
we
need
to
care
about
security
and
knowing
what
we
know
now
about
the
tools
we
just
talked
about.
Let's
see
how
we
can
use
those
in
an
event
that
will
being
hacked
to
prevent
from
those
hacked
images
to
be
deployed
to
our
kubernetes
clusters.
So
this
is
what
our
steps
look
like.
A
We've
got
the
git
clone
and
build
image,
and
if
you
remember,
when
we
were
doing
the
diff
on
git,
we
were
attacked
on
those
two
different
sources.
One
of
them
was
the
github
source,
and
one
of
them
was
the
container
image
that
we
were
using,
but
now
because
we're
using
kiverno
and
we're
only
allowing
the
signed
images
to
be
deployed
to
our
kubernetes
clusters,
because
these
images
are
tampered
with
they're
not
going
to
be
allowed
to
hack
open
at
this
cluster.
So
we
just
put
this
stuff
in
there.
B
So
we
will
rerun
the
exact
same
part
and
meanwhile
we
will
present
the
second
scenario
when
we
are
waiting
till
this
finished,
and
we
can
check
also
the
last
scenario
that
we
have,
that
it's
deploying
the
argo
cd
and
securing
the
ago
city
applications
as
well.
So
we
will
deploy
the
last
demo
and
then
we
can
get
back
to
the
previous
demo
in
order
to
check
if
caiburno
did
and
save
today
as
well.
B
So
we
are
using
argo
cd
for
deploying
also
our
applications,
but
imagine
that
somebody
hacked
our
source
code
and
also
the
a
github
repository
that
ago
city
is
linking,
and
they
pointed
out
to
one
specific
tag
for
the
image
registry,
and
this
github
registry
shows
that
effectively
have
hacked
as
well,
and
somebody
pushed
this
image
h3
to
the
and
hacked
our
imagery
history.
But
using
kiberno
will
check
and
verify
the
image
will
check
for
the
different
signatures
and
then
we'll
deny
the
request,
because
the
signatures
will
mismatch.
B
It's
deploying
it's
preventing
to
deploy
this
application
and,
as
we
can
see
in
here,
if
we
check
the
logs
of
the
container,
the
caverno
admission
webhook
denied
the
request
because
checked
against
the
cluster
policy
of
the
czech
inmates
and
verifies
that
the
image
verification
failed,
because
the
signature
mismatch
then
also
in
both
scenarios.
First,
they
are
workflows
and
also
in
ago
cd
kiveno
save
today,
and
also
along
with
the
sixth
or
signing
the
image.
A
A
So
next
time
you
have
five
minutes,
perhaps
over
a
coffee
break,
I'd
like
to
invite
you
to
have
a
think
about
where
this
solution
might
be
applicable
to
the
way
you're
running
your
pipelines
and
your
github's
workflows,
and
also
how
you're
going
to
take
this
learning
and
implement
it
to
your
work
and
not
only
your
work,
the
work
that
you
do
with
customers,
partners
or
colleagues
of
yours,
because
after
all,
it's
a
chain
and
we're
all
in
it
together.
Thanks
for
today,.