►
From YouTube: Keyless container image signing with GitLab
Description
Demo of the new keyless signing integration with GitLab, available now on GitLab.com.
- Release post: https://about.gitlab.com/releases/2023/07/22/gitlab-16-2-released/#support-for-keyless-signing-with-cosign
- Code used in this video: https://gitlab.com/bwill/container-signing/-/tree/aeb9ba494f2b5fb761c91ca53a221295eaf79ef3
- Cosign project: https://github.com/sigstore/cosign
- Sigstore policy controller: https://github.com/sigstore/policy-controller
A
A
What
this
is
is
a
tool
that
allows
you
to
sign
your
container
images
with
a
cryptographically,
verifiable
signature,
and
you
can
use
that
to
control
what
images
are
able
to
be
run
in
your
production
environment.
So
I
have
an
example,
project
setup
here,
where
I
have
added
signing
to
the
end
of
the
docker
build
process.
A
A
We
can
also
sign
this
image
and
store
the
signature
in
a
container
registry
there's
a
few
things
that
need
to
happen.
In
order
to
do
this,
we
have
the
cosine,
yes,
true
variable.
This
is
just
to
accept,
like
an
end
user
agreement
with
with
sixture,
to
use
their
infrastructure
that
they
host
for
public
public
usage.
A
It
exposes
an
authentication
token
and
see
our
job
variables,
which
allows
cosine
to
authenticate
to
fossio,
which
is
a
service
that
issues
temporary
cryptographic
keys,
and
so
this
lets
us
do
both
signing
and
verification
without
having
to
manage
our
own
cryptographic.
Keys,
it's
done
using
temporary
ephemeral
keys
and
it
and
the
signatures
can
be
verified
using
a
similar
process.
A
A
A
A
A
Then,
for
the
sake
of
example,
we
have
a
verification
job
which
verifies
the
image.
This
requires
no
credentials
at
all.
It
does
not
require
any
keys.
It
just
does
this
using
the
public
key
infrastructure
hosted
by
sixword,
and
this
image
is
valid,
but
you
typically
would
not
want
to
do
your
verification
in
the
pipeline.
What
you
would
want
to
do
is
have
your
kubernetes
cluster
verify
that
the
image
is
signed
and
you
can
do
that
using
the
Sig
store
admission
controller.
A
If
you
verify
that
the
image
was
built
by
a
pipeline,
that's
on
a
protected
Branch
such
as
main
or
maybe
one
of
your
release,
branches
or
your
development
branch,
and
you
can
use
protective
Branch
rules
to
ensure
that
people
cannot
merge
any
changes
to
those
branches.
Without
approvals-
and
this
lets
you
add
an
extra
layer
of
control
to
ensure
that
people
cannot
run
arbitrary
images
in
the
kubernetes
cluster.
It
has
to
have
gone
through
code
view
as
I've
gone
through
approval.
It
has
to
have
been
built
by
the
CR
pipeline.
A
A
A
A
A
And
now
it
works
I'm
allowed
to
create
my
deployment,
so
this
is
a
way
that
you
can
have
cryptographically
verified,
Patrol,
Firefly,
remote
controls
under
kubernetes
cluster
that
Ensure,
that
on
the
images
that
went
through
your
code
review
process
and
your
build
processes
are
allowed
to
run
in
your
kubernetes
cluster.
Thank
you.