►
From YouTube: Lightning Talk: Security Considerations with Fulcio and OIDC JWTs - Zach Steindler, GitHub
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: Security Considerations with Fulcio and OIDC JWTs - Zach Steindler, GitHub
Fulcio relies on OIDC JWTs to authenticate requests, as well as providing information about the build environment if the OIDC provider supports it. This is great, as it allows trust between systems without having to manage long-lived API keys, but there's security considerations to be aware of as you use these JWTs. Specifically, we'll go over what data is sent when interacting with Fulcio and Rekor, why it's good to customize the audience when you request a JWT from your OIDC provider, how to approach validating fields, and things to look out for if you find yourself writing code to validate JWTs.
A
Hello:
everyone,
as
mentioned
I'm
Zach,
you
can
find
me
pretty
much
everywhere
at
stizer
and
I
am
one
of
several
people
working
on
the
integration
between
npm
and
six
door,
so
that
npm
packages
contain
verifiable
links
back
to
their
source
code
and
also
their
build
instructions.
As
we've
undertaken.
This
work
there's
a
couple
of
issues.
A
I
think
that
lots
of
people
in
this
room
know
this
better
than
I
do,
but
just
to
kind
of
zoom
into
the
one
specific
part
that
we're
talking
about
in
the
six
door
ecosystem.
This
is
the
so-called
keyless
signing
flow,
so
you're
in
a
cloud
CI
CD
system,
you're,
building
your
npm
package
and
then
in
order
to
get
your
signing
certificate
from
Full
Co
you
call
cosine
signed.
A
What
does
that?
Look
like
I
was
actually
scooped
by
other
Zach
from
six
store.
I
think
he
was
the
first
one
to
put
the
the
oydc
jwts
up.
This
particular
example
is
from
GitHub,
but
it's
important
to
note
that
our
implementation
in
npm,
which
is
going
to
work
with
any
cloud
cicd
provider
that
supports
oidc
jwts
and
has
specific
properties.
A
There's
a
link
on
here
to
the
GitHub
docs
I
should
have
posted
a
link
to
these
slides.
If
you
go
to
coffeehousecoders.org
I've
linked
the
slides
there
as
well
and
I'll
put
them
in
slack
after
this
talk,
there's
a
number
of
attributes
on
the
left
that
folsio
is
already
looking
at
that
we're
going
to
talk
about
in
more
detail
and
then
I've
added
some
additional
attributes
on
the
right
in
the
different
providers.
A
These
fields
have
different
names,
but
we're
hoping
to
work
with
all
Cloud
CSD
providers
to
provide
this
information
in
one
form
or
another,
so
the
First
Security
consideration
I
want
to
talk
about
is
data
privacy.
This
is
a
very
tricky
one.
So,
first
of
all
just
to
highlight,
there's
some
things
in
here
that
you
might
consider
a
pii,
of
course,
if
you're
part
of
an
open
source
project,
this
information
is
probably
already
in
your
public
Source
repository.
So
it
might
not
be
considered
that
sensitive,
but
some
governments
are
talking
about
a
right
to
be
forgotten.
A
That
will
come
back
to
it.
A
second
so
I
just
wanted
to
highlight
here
the
name
of
your
branch,
the
name
of
your
account,
the
name
of
your
repository,
the
name
of
your
build
workflow,
and
also
the
name
of
the
file
of
the
build
workflow
and
so
less
so
for
open
source,
but
maybe,
if
you're,
using
this
for
an
inner,
Source
or
other
sort
of
like
Enterprise
application.
You
want
to
be
careful
about.
You
know
sending
this
information
to
public
servers.
Other
people
will
be
able
to
see
it.
A
It's
not
exactly
clear
what
a
right
to
be
forgotten
means
in
this
context.
Certainly
people
are
voluntarily
sending
this
information
to
full
Co,
but
then
in
the
future,
if
they
don't
want
this
information
to
be
publicly
available,
it's
not
exactly
clear
what
that
would
look
like
and
so
I
think
that's
going
to
be
an
ongoing
conversation
in
the
in
the
community,
how
we
might
support
or
handle
those
types
of
requests.
A
The
second
consideration
is
a
custom
audience.
Six
door
is
doing
a
great
job
here,
10
out
of
10.,
when
customers
or
when
people
are
provisioning,
these
oidc
tokens
in
their
cloud
provider.
We
want
to
ensure
that
they
are
doing
so
with
a
custom
audience.
This
is
so
that
when
you
can't
use
a
token
from
one
compromise
system
to
another
one,
if
someone
was
able
to
compromise
one
of
the
systems,
that's
receiving
these
YDC
tokens,
the
cosine
already
handles
this.
A
For
you,
if
you,
if
you're
using
the
the
workflow
instructions
it
will,
it
will
create
call
into
the
apis
to
ensure
that
that
custom
audience
is
there.
But
if
you're,
if
you're
operating
a
cloud,
cicd
provider
be
sure
to
allow
people
to
do
this
customization
and
then,
if
you're,
building
some
sort
of
integration
ensure
that
you're
using
some
sort
of
unique
string
so
that
people
can't
take
a
token
imported
onto
another
service
and
then
the
last
issue.
A
I,
don't
have
a
great
solution
for
so,
in
addition
to
having
the
repository
name
or
the
organization
name,
those
resources
can
actually
change.
Maybe
a
company
gets
acquired.
Maybe
a
personal
project
becomes
a
company
project.
Maybe
someone
just
decides?
They
don't
want
something
to
be
open
source
anymore
and
they
delete
it.
A
So
the
way
this
is
being
handled
currently
in
the
GitHub
oidc
token
is
that,
in
addition
to
including
the
repository
and
the
repository
owner,
we
also
include
these
fields,
repository
ID
and
repository
owner
ID,
and
if
the
resource
is
deleted
or
renamed
or
otherwise
recreated,
we
guarantee
that
this
value
will
change
what
exactly
we
do
with
these
values.
It's
not
clear
yet
polcio
isn't
looking
for
this
information,
yet
arguably
this
isn't
something
that
six
store
should
have
to
solve.
A
Maybe
this
is
something
that
package
managers
should
consider
as
they're
accepting
these
signing
certificates
and
I
would
like
to
discourage
us
from
saying
that
end
users
should
handle
it.
I
think
that
they
probably
already
have
enough
to
to
worry
about
it'd
be
nice.
If
we
could
do
something
that
more
transparency
more
transparently,
let
people
know
when
an
underlying
resource
that
an
attestation
points
at
changes
and
that's
really
it.
Those
are
three
consider
security
considerations
for
thinking
about,
as
you
work
with
oidc
tokens
thanks,
everyone.