►
Description
Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon Europe 2023 in Amsterdam, The Netherlands from April 17-21. 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.
Lightning Talk: Helm and the Sigstore Ecosystem - Andrew Block, Red Hat
Helm has become an integral mechanism for packaging and deploying applications within Kubernetes environments. Similar to any other Kubernetes workload represented as containers, Helm chart contents should be signed and verified. Fortunately, efforts within the Sigstore community have brought forth new capabilities when working with Helm in this space. In this lightning talk, attendees will be introduced to the various efforts related to signing and verifying Helm charts using the Sigstore ecosystem. In particular, attendees will: * Learn the various methods that Helm charts can be signed and verified. * Leverage the capabilities provided by the Sigstore project to manage Helm content. * Be introduced to the Helm charts provided by Sigstore and how they can be used. * Understand how they can contribute to the Sigstore project and interact with the community.
A
So
my
name
is
Andrew
block
I'm,
a
distinguished
architect
at
Red,
Hat
I've
been
working
in
the
Sig
store
Community
for
quite
some
time.
Obviously,
Red
Hat,
being
one
of
the
key
members
of
the
project.
I
do
a
lot
with
open
source,
obviously
being
the
kind
of
the
lead
of
Helm
Integrations
and
efforts
around
Sig
store,
but
I
also
am
a
Helm
maintainer
within
the
helm
project.
A
So
definitely,
if
you're
interested
in
more
in
Helm
come
swing
by
on
Thursday
at
11,
I
think
it
is
as
we're
going
to
have
our
Helm
maintainer
talk,
so
I
definitely
want
to
get
as
many
people
who
are
interested
in
Helm
to
swing
on
by
and
I
do
write
a
lot.
I
do
like
to
share
my
knowledge
with
the
community.
A
I
have
two
books
that
are
coming
out
this
year,
one
which
just
dropped
about
two
weeks
ago,
which
is
the
second
edition
of
managing
kubernetes
Resources
with
Helm,
and
then
there's
a
new
one
coming
out
in
December
from
Manning
around
kubernetes
Secrets
management,
so
some
cool
stuff.
If
you're
interested
in
either
one
of
those
topics.
A
So
we
know
a
Sig
store.
You
know
signing
signing
the
container
really
is
just
the
tip
of
the
iceberg.
There
is
an
entire
ecosystem
for
managing
application
delivery.
There's
everything
from
oh,
my
God.
This
is
just
one
small.
As
you
know,
this
is
taken
from
the
cloud
native
landscape.
So
it's
one
small
little
component
of
the
cloud
native
landscape
in
there
near
the
top
right
is
Helm.
Helm
is
what
you
would
say
is
the
canonical
package
manager
of
kubernetes.
It's
been
a
cncf
project
for
a
while.
A
It
has
an
active
developer,
Community
13,
000
contributors,
a
lot
of
committers
and
trust
me
as
being
a
maintainer.
The
flood
never
stops
it's
just
like
you
know
the
the
guys
are
just
coming
and
coming
and
coming
that's
good.
It
means
it's
a
healthy
Community.
The
only
problem
is
obviously
you
want
to
make
sure
to
keep
the
community
moving
when
you
still
have
a
limited
number
of
resources.
A
So,
but
if
you're
interested
in
Helm
want
to
join
the
project
or
a
great
community,
so
definitely
stop
on
by
and
do
more
on
that
side
of
things
all
right
now
the
fun
for
those
of
you
who
don't
know
how?
How
many
here
have
never
used
Helm
before
okay,
good
I
can
go,
I
can
go
through
some
of
the
basics
and
it
won't
go.
I
won't
bore
everyone
so
perfect.
So
Helm
has
a
conscious
of
charts.
It's
a
set
of
templated
resources
and
you
combine
those
with
value
which
are
parameters.
A
You
combine
them
using
this
Helm
CLI
and
you
get
a
release
into
into
kubernetes,
and
a
release
can
be
anything
any
kubernetes
resource.
It
can
be
just
one
config
map
or
a
entire
application
of
deployments.
Stateful
sets
secrets,
you
know
you
name
it.
It
can
all
be
then
created
inside
of
a
kubernetes
resource,
all
right,
kubernetes
cluster,
a
Helm
chart
is
composed
of
the
following
attributes,
or
basically
the
following
components.
At
the
start,
you
have
your
chart.yaml
file.
This
is
going
to
be
your
metadata.
What
is
the
name
of
the
chart?
A
Are
there
independencies
any
metadata
that
goes
alongside
it,
because
we
can
use
certain
pieces
of
metadata
to
provide
Rich
information
for
certain
user
interfaces?
Artifact
Hub
is
one
of
them.
That's
an
easy
way
to
find
all
the
different
charts
that
might
be
on
the
ecosystem.
You
can
provide
annotations
in
your
yaml
file
and
that
can
be
populated
in
a
nice
user
interface
for
users
to
take
a
look
at
aside
from
that,
you
have
your
values.yaml
file.
A
These
are
the
parameters,
the
specific
injections
saying:
okay,
I
may
want
two
and
two
instances
or
two
replicas
of
my
of
my
charge
or
have,
and
then
you
have
a
template
folder,
which
is
going
to
be
all
your
different
templated
resources.
It
uses
gold
length
templates
as
the
underlying
language
and
as
well
as
the
sprig
module,
a
library
to
add
in
some
special
sauce,
so
you
can
have
a
number
of
reusable
components
for
it
in
libraries.
A
A
There
is
a
concept
of
a
Providence
file.
It
basically
is
a
way
that
you
can
prove
the
identity
for
your
Helm
chart.
It
consists
of
three
specific
components:
the
first
being
just
the
output
of
the
chart.yaml
file,
the
Sha
of
the
packaged
Helm
chart
and
the
signature
of
the
Providence
file
itself,
and
you
use
the
helm
CLI
to
create
an
apartment
to
sign
the
chart.
You
sign
it
using
Helm
package
Dash
as
sign
you
specify
the
key.
A
A
Perfect.
That's
what
I
thought
not
much
the
adoption
sucks.
So
why
does
it?
Why
does
sex
store
in
Hell
matter
because
well,
three
reasons,
one
Hellman's
very
popular
in
the
kubernetes
ecosystem?
It
is
the
de
facto
package
manager
for
kubernetes
two.
We
want
to
support
different
ways
of
deploying
thing
store
resources
and,
while
number
three,
most
importantly,
we
want
to
sign
all
the
things
so
might
as
well
sign
Helm
charge
2..
A
A
The
three
things
get
sent
to
the
recore
server
from
the
signed
Helm
chart
first
is
the
public
key
that
was
used
to
sign
the
chart,
the
the
signature
of
the
chart
itself,
the
Providence
file
and
the
hash
of
the
chart,
and
it
obviously
provides
that
one
additional
level
of
verification
as
you're
installing
the
chart
to
a
kubernetes
cluster
and
here's
a
typical
workflow
of
how
you
would
go
ahead
and
make
use
of
this
plugin.
First,
you
would
just
go
ahead
and
create
a
charge.
A
If
you
want
to
go
ahead
and
reverse
it
verify,
you
just
use
the
helmetics
or
verify,
and
you
can
also
search
to
see
if
the
chart
happens
to
be
in
record
just
say:
does
this
sign
chart?
Is
it
in
Recoil
or
not,
and
if
you
want
to
look
at
the
nitty-gritty
of
what
actually
gets
stored
in
record
here
is
the
output
of
what
the
helm
record
entry
looks
like
how
many
of
you
have
actually
looked
at
what
all
the
entries
in
recore
itself.
A
Also
knew
someone
newer
is
the
ga
availability
of
storing
Helm
charts
itself
in
record
in
oci
artifacts
in
oci
Registries,
as
oci
artifacts
oci
is
artifacts
are
supported
in
most
container
Registries.
There
are
a
few
out
there
that
do
not
support
OC
artifacts,
the
big
one.
The
big
outlier
right
now
is
Docker
hub
one
of
these
days
soccer
Hub,
one
of
these
days,
I
promise
I've,
heard
good
things
that
it's
coming
very
soon
by
signing
oci
artifacts
using
six
stores
capabilities.
It's
very
familiar
with
signing
container
images.
A
You
just
point
it
at
an
existing
and
away
it
goes,
and
cosine
can
be
used
to
sign
and
verify
the
contents.
You
can
also
go.
Instead
of
signing
the
package
chart
itself
or
the
published
charts
to
an
oci
artifact,
you
can
just
sign
the
blobs
sign
the
package
charts.
You
can
sign
the
Providence
file,
one
or
the
other
or
both,
and
then
you
can
once
again
you
have
two
files.
You
can
do
whatever
you
want
with
it.
A
A
So
that
is
one
that
is
certainly
one
way
that
we're
continuing
to
dog
food,
more
of
our
capabilities
because,
as
we
do
produce
the
the
various
contents
in
Sig
store,
we
are
using
many
of
the
same
capabilities
when
I
when
we
go
ahead
and
we
publish
the
Helm
stick
store,
plugin
we're
going
ahead
and
Publishing
itself
to
recore.
So
dog
fooding
is
great
because
you
can
find
Bugs
see
where
things
are
working
and
not
working
for
different
use
cases.
A
A
We
want
to
be
able
to
scaffold
an
entire
six-store
ecosystem
within
a
kubernetes
environment
and,
as
I
mentioned
earlier,
eat
our
own
dog
food.
I
can't
tell
you
how
many
bugs
I
found
and
new
enhancements
have
been
created
based
on
this
dog
fooding
I,
always
love
dog
pudding,
because
I
found
so
many
issues
with
my
own
technology,
because
I
think.
Oh,
it
works
in
this
great
use
case,
but
then
I
try
applying
it
somewhere
else.
Not
so
much
so
be
able
to
get
a
greater
way
of
testing
the
different
components
out
there.
A
We
have
all
the
different
key
components
of
six
store.
We
have
a
number
of
utilities
as
home
charts
and
we
have
an
overarching
scaffolding
capability
for
you
to
stand
up
an
entire
sing
store
ecosystem.
So,
looking
ahead
and
talked
about
all
the
great
things,
two
areas
that
I
say
we
want
to
go
forward.
We
want
to
be
able
to
evolve
the
existing
content
in
content
creation
and
we
want
to
increase
the
adoption
of
six
door
within
the
helm.
Community,
that's
one
of
the
things.
I
am
very
much
interested
in.
A
How
can
we
go
ahead
and
get
more
interest
in
six
store
within
Helm,
because
here's
a
problem
Helm
only
supports
one
way
of
signing
charts
gpg
stocks,
it
sucks!
That's
why
our
project
exists,
let's
go
ahead
and
let's
try
to
bring
new
ways
of
signing
Helm
charts
six
words,
not
the
only
the
only
one
in
in
the
play
in
in
play,
but
it
could
be
one
of
the
various
options
that
can
be
used
in
Helm
to
sign
content.
So
let's
go
ahead
and
let's
try
to
make
it
happen.
A
A
We
have
we
chat
quite
a
bit
on
the
six
door,
slack
Channel
and
the
kubernetes
channel.
Please
come
to
our
GitHub
representative
repositories.
There's
a
Helm
charts
repository
in
six
store,
as
well
as
the
helm,
sync
store
plug-in
and
then,
if
you
are
interested
in
moving
the
conversation
up
to
helm
to
brioble,
to
assign
additional
methods
of
content,
please
go
ahead
and
contribute
there.