►
From YouTube: So You Want to Run Your Own Sigstore: Recommendations for a Secure Setup - Hayden Blauzvern, Google
Description
Don't miss out! Join us at our upcoming event: KubeCon + CloudNativeCon Europe in Amsterdam, The Netherlands from 18 - 21 April, 2023. Learn more at https://kubecon.io The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
So You Want to Run Your Own Sigstore: Recommendations for a Secure Setup - Hayden Blauzvern, Google
Sigstore, an open-source standard for signing and verifying artifacts, provides free-to-use services that provide identity-based certificates and auditable signatures through a transparency log. These services work well for FOSS, giving maintainers the tooling needed to create signed builds. However, enterprise organizations may have additional needs that are not addressed by the public instances. This could include availability requirements such as regionalization, data residency requirements, privacy concerns with a public log, or requiring policy controls for admitting entries into a log. This talk will discuss motivations for operating private Sigstore services and expectations on the operators. The talk will discuss differences in the threat modeling between public and private instances. Finally, the talk will cover the requirements for operating private instances, including operating a root trust store and the necessary security properties of a private certificate authority and transparency log.
A
A
We
enable
this
by
providing
free
and
publicly
available
transparency,
login
certificate,
Authority
Services,
which
you
can
also
run
within
your
organization
too,
which
we'll
talk
about
in
a
moment
and
one
of
its
other
goals
is
to
remove
the
need
to
manage
artifact
signing
Keys.
We
found
that
this
is
one
of
the
pain
points
for
adoption.
When
it
comes
to
doing
code,
signing
users
frequently
don't
have
signing
keys
or
they
don't
really
know
how
to
manage
them.
So,
let's
take
a
look
at
how
sigstore
enables
signing
without
having
to
manage
keys.
A
The
first
service
within
Sig
store
is
fulsio,
which
is
six
door
certificate
Authority
and
it
issue
certificates
that
bind
public
Keys,
which
can
either
be
ephemeral,
meaning
from
a
single
signing
event
or
long-lived.
If
the
artifact
owner
maintains
some
signing
key
and
Associates
this
key
with
an
identity
that
comes
from
an
ID
token
obtained
through
the
openid
connector
oidc
protocol,
an
artifact
owner
will
fetch
one
of
these
ID
tokens
and
then
give
this
to
the
certificate
Authority,
along
with
a
public.
Key.
A
Full
seal
will
verify
that
identity
token,
since
it's
signed
and
extract
the
identity
from
it
and
include
that
in
the
certificate
and
this
identity
could
be
an
email
address,
this
identity
could
be
a
service
account.
It
could
also
be
an
identity,
that's
associated
with
a
workflow
run
on
a
CI
platform
such
as
GitHub
actions.
A
The
public
instance
of
focio
will
also
write
to
a
certificate,
transparency,
log
and
we'll
talk
a
bit
more
about
the
role
of
transparency
within
six
store
in
a
minute.
But
roughly
the
purpose
of
this
log
is
so
that
you
can
have
an
immutable
issuance
log
which
holds
the
ca
accountable
to
everything
that
it
issues.
A
After
an
artifact
owner
signs,
an
artifact,
they
will
upload
the
certificate
that
came
back
from
folsio
and
a
signed
artifact,
a
signature
in
the
artifact
hash
to
recore,
and
then
recore
will
return
back
a
proof
saying
that
this
entry
was
included
in
the
log
and,
if
you're
familiar
with
transparency
logs
note
that
I
am
glossing
over
exactly
what
this
proof
entails.
But
roughly
it's
a
cryptographic
proof.
A
The
artifact
owner
can
then
take
that
signed,
artifact
the
certificate
and
the
proof
and
upload
that
somewhere,
let's
say
to
a
package
repository
so
that
any
verifier
that
wants
to
use
a
package
is
able
to
verify
the
signed
artifact.
They
can
verify
that
using
the
public
key
that
comes
from
the
certificate
they
can
verify.
A
The
certificates
matches
a
identity
that
they
were
provided
out
of
band,
that
maps
to
that
artifact,
and
then
they
can
verify
the
proof
to
know
that
the
entry
was
actually
included
in
a
log,
and
the
benefit
of
this
is
much
like
with
certificate
transparency.
It
allows
the
verifier
to
know
that
an
artifact
owner
can
be
monitoring
to
see
how
their
identity
and
their
artifact
shows
up
in
the
log.
Maybe
they
have
some
requirement
that
an
artifact
will
only
show
up
once
in
a
log,
for
example,
this
is
a
an
overview
of
all
of
six
store.
A
Putting
all
the
pieces
together
and
the
main
thing
to
take
away
from
this
diagram
is
that
I've
also
mentioned
cosine.
This
is
the
command
line
utility
that
sigstore
has
created
that
enables
artifact
and
container
signing
and
verification,
and
it's
not
the
only
tool
within
the
sixth
or
ecosystem
too.
We
also
have
some
command
line
utilities
such
as
six
star
python
or
six
door
JS
that
are
actively
being
developed
that
allow
you
to
interact
with
the
services
within
six
store.
A
A
We
have
an
on-call
team
staff
to
monitor
these
services,
and
we
had
recently
back
in
October,
went
General
availability
or
GA
for
these
Services,
declaring
that
these
can
now
be
used
in
production
workflows
with
more
confidence,
but
organizations
may
have
other
requirements
and
want
to
have
their
own
private
instances
of
them.
This
could
be
for
performance
reasons.
Maybe
three
nines
is
not
sufficient
and
the
organization
needs
to
have
higher
availability.
A
A
Another
one
is
privacy,
and
this
is
one
that
comes
up
fairly
frequently.
The
identities
that
are
included
in
certificates
are
written
to
these
public
logs,
and
these
identities,
like
I,
said,
could
include
emails.
It
could
include
service
accounts
associated
with
private
projects.
It
could
include
workflow
information
associated
with
private
repositories
and
organizations
may
not
want
this
information
publicly
available.
So
these
are
all
reasons
that
organizations
might
want
to
operate
a
private
six
store.
A
Note
that
I'm
not
going
to
talk
about
how
to
actually
deploy
Sig
store,
for
example,
how
to
harden
your
kubernetes
environment
or
set
up
apples
appropriately.
They'll
mention
at
the
end
a
slack
Channel
where,
if
you're
interested
in
that
there
are
some
folks
within
the
sigster
community
that
are
working
on
how
to
simplify
deployment
for
six
or
two.
A
Another
consideration
with
managed
artifact
signing
Keys
is
storage.
Where
do
you
actually
store
the
signing
key?
Are
you
going
to
put
it
on
a
flash
drive?
Do
you
encrypt
that
flash
drive?
What
happens
if
you
lose
that
flash
drive?
Are
you
going
to
put
the
key
in
a
cloud
project?
What
happens
if
there
is
shared
access
to
that
project?
A
And
how
do
you
also
audit
access
to
that
signing
key
to
make
sure
there's
not
any
unexpected
access?
And
this
comes
to
the
final
point,
which
is
compromise?
Inevitably
compromise
does
happen,
and
how
do
you
mark
a
key
as
no
longer
trusted
revoke
that
key
within
webpki?
The
way
this
is
done
is
relying
on
certificate
revocation
lists.
These
are
lists
that
Cas
maintain
that
have
a
list
of
certificates
that
should
no
longer
be
trusted,
but
certificate
revocation
lists
are
very
difficult
to
work
with.
They
can
grow
indefinitely,
they're
difficult
to
ship
to
clients.
A
So
this
is
another
thing
to
consider
when
managing
artifacts
signing
Keys,
which
is
what
does
your
revocation
Story
look
like,
and
are
you
able
to
efficiently
work
with
really
large
reputation
lists,
and
this
is
why
Sig
store
defaults
to
ephemeral,
signing
Keys?
The
idea
is
that
for
assigning
events,
Sig
store
or
the
command
line,
utilities
is
going
to
generate
a
single
signing
key
that
will
be
thrown
away
after
the
signing
event,
and
then
we
associate
that
verification
key
with
some
stable
identifier
that
comes
from
an
identity
token,
but
private
organizations
may
not
want
this.
A
They
may
already
have
an
existing
system
in
place
for
managing
artifact
signing
keys
and
sixstore
works
perfectly
fine
with
artifact
signing
keys.
For
example,
when
I
mentioned
the
recore
I
said
that
we
can
upload
certificates,
we
can
also
upload
artifact
signing
Keys
too
I
wrote
a
blog
post
a
little
while
ago
called
adopting,
sixth
or
incrementally
that
kind
of
talked
through
this
problem.
A
It
assumed
that
an
organization
doesn't
want
to
go
from
a
point
where
they
have
managed
signing
Keys,
jumping
all
the
way
to
what
we
sometimes
call
keyless
signing,
or
this
identity
based
signing
and
one
of
the
intermediate
steps
was
that
you
can
issue
identity-based
certificates
for
long-lived
keys
or
for
managed
keys,
folsio
doesn't
enforce
ephemerality,
it
doesn't
have
state
and
track
if
it's
seen
a
key
before
so
the
question
really
comes
down
to.
What
do
you
want
your
verification
policy
to
look
like?
Would
you
prefer
having
keys,
mapped
to
artifacts
or
certificate?
A
But
if
an
organization
already
has
the
right
policies
in
place,
there's
nothing
preventing
them
from
using
artifacts
Simon
keys,
switching
topics.
Now,
let's
talk
about
the
ca
side
of
things,
many
organizations
already
have
managed
Cas.
These
could
be
through
things
like
step,
CA
or
through
a
cloud
providers
such
as
gcp
or
AWS,
and
six
store
will
work
out
of
the
box,
with
certificates
issued
from
NECA,
not
just
full
CO,
as
long
as
they
conform
to
the
full
SEO
certificate
profile.
A
This
includes
things
like
setting
the
identity
in
the
subject:
alternative
name,
and
this
example
here
I've
shown
an
email,
including
an
extension
that
specifies
an
issuer
which
is
the
oidc
provider
that
issued
an
identity,
token
and
optionally,
including
an
extension
that
this
here
is
called
an
SCT,
which
roughly
is
a
proof
that
something
showed
up
in
a
transparency.
Log
you'll
hear
me,
say:
Key
Management
a
lot
throughout
this
talk.
A
This
is
a
common
problem
not
just
with
artifacts
signing
keys,
but
also
with
the
services
that
are
managed
and
have
signing
keys,
and
this
is
something
to
consider
with
managed
Cas
too.
If
the
signing
key
for
the
ca
gets
compromised,
a
attacker
could
mint
certificates
for
any
arbitrary
identity
by
passing
any
sort
of
authorization
checks.
A
If
you
don't
already
have
a
managed
CA,
another
option
is
simply
to
operate
a
private
instance
of
fulsio
from
the
open
source
Repository
the
same
Key
Management
considerations
are
important
here.
Folsio
has
the
concept
of
signing
back-ends,
which
are
roughly
where
the
signing
key
lives.
In
this
example,
here
I
show
it's
within
a
cloud
environment
within
KMS,
and
once
again
you
need
to
make
sure
that
access
controls
are
appropriate
and
that
access
to
that
key
is
locked
down.
A
We'll
talk
more
about
transparency
logs
in
a
moment,
but
I
think
it's
worth
noting
here.
That
I
also
believe
that
it's
critical
that
you
operate
a
certificate
transparency
log
even
within
a
private
environment,
even
if
you
won't
have
these
certificates
public,
because
this
will
give
you
an
immutable
issuance
log
such
that
an
auditor
can
verify
how
identities
are
showing
up
in
a
log
and
make
sure
that
there's
not
anything
unexpected,
and
this
is
beneficial
too.
In
the
case
of
compromise
of
a
CA
signing
key.
A
Roughly
the
leaf
nodes
of
the
tree
are
hashes
of
what's
going
into
the
tree,
and
then
the
parent
nodes
are
hashes
of
the
concatenation
of
their
children,
and
this
construction
allows
you
to
calculate
certain
types
of
proofs
over
this
tree,
and
one
of
them
is
called
inclusion
proofs.
These
are
cryptographic
proofs
that
allow
you
to
show
that
an
entry
actually
is
in
the
tree.
A
Another
type
of
proof
is
what's
called
a
consistency,
proof
and
a
consistency.
Proof
says
that
between
any
two
points
in
the
log
points
defined
by
size,
let's
say
size,
2
and
size
10.,
we
guarantee
that
the
tree
remains
append
only
meaning.
That's
between
those
two
points
what's
in
the
tree
was
not
modified
or
removed,
and
over
time
this
gives
you
the
property
of
immutability.
That
trees
can
only
be
appended
to
and
not
removed
from
or
mutated
more
accurately,
the
mechanism
lets
you
detect
any
sort
of
mutations
over
time.
A
There's
many
applications
of
transparency
logs.
We
saw
certificate
transparency
as
one
example.
A
binary
transparency.
This
is
things
like
recore
on
key
transparency
is
another
one
that
I
want
to
mention,
which
is
useful
within
the
end-to-end
encrypted
messaging
space
that
give
you
a
publicly
auditable
mapping
between
keys
and
identities.
A
Within
sigstore,
we
have
two
primary
uses
for
transparency
logs.
One
is
that
fulsio
writes
its
issued
certificates
to
a
certificate
transparency
log
and
also
that
recore
entries
are
appended
to
a
transparency
log,
which
is
sometimes
a
superset
of
what
goes
into
folsio.
But
there
may
be
use
cases
where
you
only
want
false
here
or
only
want
recore.
A
These
are
all
questions
that
I've
heard
at
some
point
when
discussing
with
maintainers
or
community
members,
which
is
do
I
actually
need
a
transparency
log.
If
I'm
going
to
be
operating
in
a
private
environment
and
I'll,
try
to
convince
you
that
I
do
think
it's
necessary
to
operate.
One
question
is
well
what,
if
I
already
have
an
existing
system
for
audit
logging,
for
example,
maybe
you're
on
a
cloud
platform
that
already
has
audit
logs
one
benefit
of
operating
a
transparency
log
is
that
it
allows
you
a
few
things
one.
A
A
A
The
problem
is
that
as
a
verifier,
I
have
no
way
of
computing
and
inclusion
proof
to
check
that
an
entry
is
actually
in
the
log
and
I
also
can't
calculate
consistency
proofs
that
the
the
log
remains
immutable
and
I
mentioned
this,
because
I
think
it's
worth
considering
when
deciding
on
whether
or
not
you
need
a
private
transparency
log.
If
your
artifacts
are
going
to
be
released
publicly,
it's
likely
that
it's
valuable
to
rely
on
the
public
transparency
log.
A
Another
question
is
well:
can
I
just
use
a
database
if,
let's
say
I
already
have
an
existing
audit
logging
system
and
I
think
what
this
really
comes
down
to
is.
Do
you
want
an
immutable
record?
A
database
is
not
going
to
be
immutable
and
once
again
it's
it's
prone
to
Insider
risk
or
compromise,
and
so
to
me,
I
think.
Transparency
logs
are
really
critical
because
they
provide
this
immutable
record
now.
A
One
detailed
that
I
think
is
worth
noting
is
how
you
actually
get
this
property
of
immutability
and
that's
by
relying
on
monitors
within
the
transparency
log.
Space
monitoring
is
a
little
bit
of
an
overloaded
term.
I've
said:
monitors
a
lot
so
far
referring
to
Identity
monitoring,
where
you
are
querying
the
log
periodically
asking
for
every
entry
in
the
log
and
doing
introspection
on
the
entries
in
the
log
to
look
for
certain
expected
identities.
A
This
type
of
monitor
the
expectation
is
that
it's
there
to
calculate
consistency
proofs
so
periodically.
It
will
query
the
log
and
say:
what's
the
current
state
of
the
log,
it
will
then
query
the
log
again
some
size
later
and
calculate
a
consistency
proof
between
those
two
points
and
if
the
log
is
not
able
to
present
a
valid
consistency,
proof
and
the
monitor
is
not
able
to
verify
it
then
there's
an
expectation.
A
The
monitor
should
alert
the
ecosystem
to
a
potential
compromise,
but
another
very
important
role
of
monitors
is
to
prevent,
what's
called
split
view
attacks,
and
this
is
really
where
everything
kind
of
comes
together,
so
split
view.
Attacks
are
where
the
log
presents
different
views
to
different
callers
and
each
view
can
look
consistent,
but
the
contents
of
what's
being
presented,
might
look
different.
A
I've
left
a
couple
links
here
to
some
of
the
monitors
that
we're
working
on,
one
of
which
is
in
the
six
door
organization
called
record
monitor.
This
is
something
that
I,
along
with
Purdue
University,
have
been
working
on.
This
can
run
on
GitHub
actions,
which
is
useful
for
monitoring
public
transparency
logs,
but
you
can
also
operate
this
yourself.
A
Another
monitor
was
created
by
the
team
behind
trillion
a
trillions,
a
scalable
Merkle
tree
service,
and
this
is
actually
what
backs
recore
and
certificate
transparency
if
you're
interested
in
talking
more
about
monitors,
I'm
happy
to
do
so
after
the
talk
so
next
Let's
Talk,
About,
Time,
stamping.
This
is
a
really
critical
component
of
sigstore.
A
That
is
because
the
certificates
that
get
issued
by
falsio
are
very
short-lived.
This
is
in
contrast
to
SSL
certificates
that
are
typically
issued
for
30
days
90
days
a
year.
It
could
even
be
more
than
that,
and
one
issue
with
the
system
is
if,
for
some
reason,
the
signing
key
material
gets
compromised,
you're
going
to
have
to
revoke
the
certificate.
A
Well,
one
question
is
what,
if
I
don't
want
to
operate
a
private
instance
of
recore
for
some
reason?
Well,
another
option
is
to
rely
on
timestamp
authorities,
and
this
is
actually
quite
an
older
concept.
Within
this
space.
Timestamp
authorities
have
been
around
for
quite
a
while,
but
roughly
the
way
it
works
is
you
have
some
trusted
entity,
a
timestamp
Authority
and
it
signs
over
a
current
time,
along
with
something
associated
with
what
you're
verifying.
A
Typically
it's
an
artifact
signature,
and
this
is
called
a
counter
signing
and
the
sign
the
timestamp
itself
is
signed,
so
it
can
be
verified
and
it's
the
same
as
with
recore.
That's
when
you
want
to
go
verify
a
short-lived
certificate.
You
take
the
timestamp
from
the
sign
timestamp
and
you
check
that
it
falls
in
the
window
of
validity
for
the
certificate.
A
We
can
go
one
step
further
and
use
both
a
timestamp,
Authority
and
recore
to
have
distributed
Trust.
Once
again,
when
I
talk
about
trust
boundaries,
you
can
take
a
time
stamp,
Authority
that
you're
operating
yourself
and
put
it
in
a
different
trust
boundary
than
your
transparency
log,
a
different
trust
boundary
than
your
certificate
authority.
To
reduce
the
impact
of
a
compromise,
you
could
also
rely
on
a
third
party
time
stamp
Authority,
for
example,
digi-ser
Apple
operates
some,
and
maybe
you
choose
to
trust
them
to
be
the
witness
and
to
provide
the
trusted
time.
A
So
in
this
example
as
a
verifier,
what
I
would
do
is
I
would
get
the
signed
time
stamp
and
the
recour
entry
and
I
can
simply
ignore
the
integrated
time
from
the
record
time
stamp.
Sorry
from
the
record
entry,
if
I
want
and
instead
rely
on
the
timestamp
that
comes
from
the
timestamp
authority
when
verifying
the
certificate.
A
A
Once
again,
the
problems
of
Key
Management
come
up
here
with
roots
of
trust.
How
do
you
securely
distribute
them
in
such
a
way
that
an
attacker
isn't
able
to
inject
something
into
the
trust
route.
Storage
is
another
consideration.
How
do
you
lock
down
wherever
these
routes
of
trust
are
stored
once
again,
so
an
attacker
can't
inject
other
ones
and
compromise
is
also
something
to
consider
and
I
think
it's
worth
noting
once
again,
expiration
too.
A
So
in
this
example
here
this
is
what
a
typical
tough
repository
looks
like.
We
have
a
Target
role,
which
is
comprised
of
some
signing
key
I'll
note
that
the
signing
key
could
either
be
offline
or
online.
So
for
the
Target
role,
it's
I
believe
recommended
that
it
be
offline
for
the
root
role.
It's
very
strongly
recommended
that
it
be
offline
and
the
target
role
is
going
to
then
sign
the
metadata
or
a
set
of
files.
Right
and
this
is
this
concludes
the
certificate.
A
App
chart
role
is
responsible
for
specifying
all
of
the
roles
that
should
be
a
part
of
the
system
once
again
as
a
mechanism
to
prevent
injecting
other
roles,
and
the
timestamp
role
is
responsible
for
signing
a
timestamp,
that's
meant
to
frequently
expire
and
this
forces
clients
to
go
online
periodically
and
fetch
the
latest
tough
Repository,
and
this
is
very
beneficial
to
give
us
a
mechanism
for
rotation.
So
let's
say
we
have
some
certificate
that
expired
or
got
compromised.
A
A
Key
holder
and
I
think
it's
important
that
if
an
organization
wants
to
use
tough,
you
have
a
similar
setup
where
you
have
some
keys
that
live
Offline
that
are
very
rarely
used
to
update
the
roles
that
they
delegate
to.
But
you
rely
on
this
mechanism
so
that
you
have
some
sort
of
secure
update
mechanism
for
rotating
in
new
Target
metadata.
A
So
we're
about
at
the
end
of
the
talk,
there's
a
couple
takeaways
from
this
first
Key
Management
is
hard,
and
this
is
whether
you're
referring
to
artifact
signing
keys
or
for
managing
roots
of
trust
or
managing
the
keys
behind
your
service.
So
I
think
it's
really
important
to
when
you're
building
the
system
to
consider
this.
This
is
why
we
recommend
things
like
the
update
framework.
A
Next
auditability
is
critical,
whether
you're
using
the
public
instance
of
six
store
or
whether
you're
operating
a
private
one
I
think
it's
really
critical
to
have
an
issuance
log
of
every
certificate
that
gets
issued
a
log
of
every
artifact
that
gets
signed
because
it
gives
you
this
permanent
immutable
record
of
every
interaction.
That's
happened,
so
you
can
go
back
in
the
event
of
a
compromise,
see
what
happens.
You
can
see
how
your
identities
are
being
used.
A
Like
I
mentioned
in
the
beginning,
I
didn't
talk
about
how
to
actually
deploy
sigster.
If
you're
interested
there
is
a
channel
on
the
six
door,
slack
called
private
six
door
users,
where
some
folks
have
been
working
on
how
to
deploy
A
system.
That
looks
like
this
with
all
of
these
components,
so
feel
free
to
go
check
that
out.
A
Yeah,
so
I
I
think
it
kind
of
depends
right.
It's
it's
where
what
do
you
trust
right?
So,
if
you're
trusting
the
cloud
provider
entirely,
maybe
you
can
rely
on
their
mechanism
for
something
like
a
KMS
to
rotate
out
keys.
I,
think
it
kind
of
depends
on
what
your
environment
looks
like
it's
very,
very
tied
to
that
one
cloud
provider,
maybe
everything's
integrated
and
you
don't
need
to
rely
on
something
like
the
update
framework
but
I
think
once
you
start
Distributing
a
trust.