►
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.
Who Are You? I Really Want to Know… the Magic Behind OIDC - Eddie Zaneski, Chainguard
Open ID Connect, or OIDC, is a mechanism for identity authentication. It is built on top of OAuth 2.0 and is used to establish and verify the identity of a user or service. OIDC is used throughout the Cloud Native world for workload identity federation. This allows your CI pipeline to obtain an API token for your cloud provider without the need to provision long-lived secrets. In this talk, you will learn the ins and outs of how OIDC works. You'll understand the spec and how you can use machine identities to secure your workloads. You'll also see examples of what's possible with OIDC from open source projects like Kubernetes, SPIFFE/SPIRE, and Sigstore.
A
My
name
is
Eddie
zanewski
I
work
for
a
company
called
chain
guard
where
we
do
software
supply
chain,
security
for
containers
and
all
the
cool
kubernetes
stuff.
That's
out
there,
but
today
we're
telling
you
to
talk
about
an
awesome
thing
called
oidc
and
of
course,
I
had
to
come
up
with
a
fun
title
for
this
talk,
so
I
can't
sing
it
or
else
they
will
cease
and
desist
the
LF
so
just
sing
the
song
in
your
head
for
a
minute.
A
So
quick
bit
about
me,
I'm,
a
software
engineer
chain
guard
I
mentioned
that
you
can
find
me
on
the
Internet.
It's
at
Eddie,
Zane
I
live
in
Denver
Colorado
and
I
like
to
climb
big
mountains,
I'm
a
maintainer
for
the
kubernetes
and
six
store
projects,
so
I
work
on
Cube
control
and
all
things
CLI.
So
you
can
at
me
in
Sig,
store
I
work
on
a
tool
called
git
sign
which
we'll
take
a
look
at
in
a
bit
and
I
am
not
a
cryptographer
or
a
security
engineer.
A
A
So
the
first
thing
we
have
to
talk
about
is
I'm
sure
I've
seen
slides
in
almost
every
talk
for
this
is
authentication
versus
authorization
are
folks
familiar
with
the
difference
here.
We
don't
spend
too
long
on
it.
Okay,
we'll
mention
it
so
authentication
is
generally
who
you
are.
Authorization
is
what
you're
allowed
to
do.
Octa
has
some
really
good
docs
on
this.
A
If
you
want
to
check
those
out
and
I
have
a
link
to
the
slides
at
the
end,
but
it's
that
specification,
so
we
usually
call
this
authen
and
ALT
C
and
so
rewind
back
to
2007.
This
is
also
from
an
OCTA
blog
post,
but
this
was
how
Yelp
would
check
your
contact
list
for
if
your
friends
were
also
signed
into
Yelp
right.
A
Come
Away
since
then,
there's
obviously
a
problem
doing
it
this
way,
and
so
that's
what
led
us
to
something
we
like
to
call
oauth
right
and
so
you've
all
probably
used
oauth
before
right,
I'm
assuming
everyone
has
you've
signed
in
with
the
service
provider
before
so
here,
I
am
signing
in
with
my
Google
account,
and
you
can
see
the
Scopes
and
all
the
things
that
this
app
is
requesting.
So
access
to
my
calendar,
all
these
things
are
just
Scopes
in
a
a
docs
file
that
this
app
pulled
in
and
said.
A
A
A
There's
different
flows
as
part
of
oauth
and
some
of
these
I
didn't
actually
know
about
until
I
started,
researching
it.
Authorization
flow
is
the
one
that
you're
most
familiar
with.
This
is
where
you
go
through,
that
consent
form
where
you
can
get
a
code
back
and
that
code
either
has
like
a
refresh
token
that
can
be
used
to
refresh
and
make
long-lived
requests.
A
Client
credentials
are
machine
to
machine
identity.
So
this
is
where
your
oath
application
would
authenticate
just
to
the
API
and
get
a
token
it
can
use
so
not
accessing
users.
Data
device
flow
so
if
you've
ever
had
to
type
a
code
in
from
a
thing
on
a
command
line
which
says
open
this
thing
and
type
this
code
in
or
if
you've
signed
into
Netflix
or
Hulu
on
your
Google
TV
or
something,
and
it
shows
you
the
code
that
you
can
go
to
netflix.com,
activate
and
type
in.
A
That's
actually,
the
oauth
device
flow
behind
the
scenes
and
then
there's
the
implicit
flow
which
is
for
client-side
applications.
This
is
typically
discouraged
because
it's
all
client-side.
This
is
where
you
don't
have
secrets
that
you
can
keep
from
the
user,
so
the
industry
is
trying
to
move
away
from
this
implicit
flow.
A
All
these
oops
requests
have
these
things
called
Scopes.
They
are
just
arbitrary
strings
to
the
provider
that
they
make
up
whatever
the
hell
they
want
and
they
represent
certain
permissions.
So
the
user
read
email
is
from
Spotify,
that's
one
of
the
Scopes.
You
can
request.
If
you're
using
OCTA,
you
can
octa.uses.read
as
the
scope
or,
if
you're
using
Google
and
the
the
Google
Sheets
API.
They
just
throw
a
URL
at
you,
so
completely
arbitrary
things
that
the
provider
decides
on
and
if
we
look
at
this,
these
are
the
Google
Docs.
A
They
have
all
of
their
Scopes
in
a
single
dock
which
is
really
cool,
so
you
can
come
in
and
find
the
service
that
you
want
see
the
different
scope,
permissions
that
you
can
get.
You
can
access
read-only
Fitness
data,
so
it's
pretty
cool
that
it's
all
in
there
and
then
a
oauth
URL
for
that
authorization
flow
that
you've
all
probably
used
at
some
point.
This
is
what
one
of
those
URLs
looks
like.
So
this
is
kind
of
the
magic
behind
the
scenes.
Is
your
web
server
would
construct
this
URL?
A
You
can
see
that
there's
the
path
in
there
oauth
2,
V2,
auth
client
ID,
which
is
kind
of
a
username
for
your
oauth
client.
It
sticks
in
a
redirect
URI,
that's
one
of
the
the
other
confusing
things
when
you're
a
kid
at
a
hackathon,
you
don't
understand
how
it
works.
So
that's
kind
of
just
where
Google
is
going
to
redirect
the
request
with
your
actual
code
that
can
be
pulled
out
and
response
type
code.
Some
other
Scopes
in
there
right.
A
You
can't
talk
about
ogc
without
talking
about
oauth,
and
so,
if
you
ever
go
and
create
a
oauth
app
somewhere,
this
is
creating
one
in
Octa
you
get
that
client
ID,
which
is
kind
of
your
username.
It
identifies
your
client,
that's
public
and
then
the
client
secret,
which
is
locked
and
kept
on
the
back
end.
That's
what
you
would
use,
along
with
that
front-end
browser
code
to
trade
for
an
actual
access
token-
and
you
can
see
here
there's
some
of
those
callback
Uris
that
you'd
have
to
specify.
A
So
this
would
be
your
production
web
application
callback.
This
is
a
documentation
of
what
that
flow
looks
like
also
from
OCTA.
They
have
some
really
great
Docs
glance
over
pretty
quickly.
You
hit
that
authorized.
Endpoint
redirects
you
back.
You
get
that
consent,
which
is
the
pop-up
I,
showed
you
got
that
authorization
code
server
will
post
that
to
token,
with
your
secret
from
the
back
end.
A
You'll
get
that
access
token
back
and
refresh
token,
so
you
can
renew
it
once
it
expires,
and
then
you
can
use
that
access
token
to
make
API
requests
on
behalf
of
that
user.
So
that's
what
you
would
save
pretty
straightforward
and
so
I
have
a
quick
demo
of
that.
So
I
have
a
Spotify
webflow
here
and
any
go
developers
in
the
room.
Yeah.
Quite
a
few
go
has
some
really
great
unique
oauth
libraries
that
are
part
of
the
standard
library
for
the
most
part,
I
got
secrets
in
here
that
I'm
going
to
delete
afterwards.
A
That's
going
to
take
me
to
the
browser
browsers
after
I
consent
is
going
to
send
me
to
this
oauth
callback.
One
I
grab
the
code
out
of
the
URL
parameters.
Do
some
error
checking
call
this
magic
exchange
method,
which
is
what
takes
my
secret
and
posts
it?
For
that
token,
cool
cool
and
then
I'm,
hitting
the
slash
me
endpoint
on
Spotify
right,
so
very
straightforward,
so
I'm
just
going
to
run
this.
A
A
That's
the
flow
we
went
through
just
quick
diagram
of
it.
If
you
want
to
look
later
in
the
slides.
Oh
one,
more
thing
get
signed
demo
right,
so
git
sign
is
a
project
from
Sig
store
which
is
artifact
signing
and
so
I
have
a
a
git
repo
here
that
I
can
commit,
and
it's
going
to
use,
git
sign
which
will
sign
my
git
commit
with
with
Sig
store,
and
this
is
something
you'll
see
in
a
lot
of
developer
tools
where
you'll
do
something
it'll
pop
out
a
URL
open
your
browser.
A
What
it's
actually
doing
is
running
a
local
web
server.
Listening
for
that
callback,
which
is
really
cool,
so
you
use
oauth
a
ton,
you
might
not
realize
it
so
I'm
going
to
authorize
a
Google.
It's
going
to
that's
a
new
page,
that's
nice,
and
it's
going
to
give
it
back
to
git
sign
sign
that
commit
cool
right
gcloud.
A
Does
this
too,
if
you
log,
in
with
the
gcloud
CLI
a
lot
of
tools,
use
this
mechanism
to
get
a
code
to
a
CLI
tool
from
your
browser,
very
neat
and
then
so,
but
there's
issues
with
the
loss.
It
was
again
originally
designed
for
authorization,
not
authentication,
which
is
what
a
lot
of
people
started
using
it
for
I,
don't
actually
want
to
access
resources
on
your
behalf.
I
just
want
to
know
who
you
are
and
give
you
an
easy
way
to
log
into
my
application.
A
There
are
no
standard
Scopes,
as
I
showed
before
right,
arbitrary
strings.
You
don't
know
what
one
provider
is
going
to
do.
Some
have
different
crazy
stuff.
In
there
there
was
no
standard
who
am
I
in
point
right.
That
endpoint
I
hit
from
Spotify
was
like
slash,
API,
slash.
V1
me,
there
was
no
standard
way
for
you
to
know
who
you
had
an
API
token.
For
and
again
these
are
Long
Live
credentials
right,
so
the
root
of
all
evil.
We
all
know
this.
A
We
don't
want
to
provision
these
things
and
have
them
sitting
around
all
right.
I
already
leaked
my
Spotify
credentials
by
showing
you
that
file,
and
so
Discovery
is
another
mechanism
in
here.
There
is
actually
oauth
discovery
which
I'll
show
you
a
bit
later,
but
that
matters
a
bit
more
with
oidc
Spotify.
Has
this
endpoint
that
you
can
hit
it's
well-known,
oauth
authorization
server
and
this
kind
of
tells
you
about
their
oauth
provider,
which
is
neat.
This
isn't
used
as
much
honestly
as
it
is
in
the
oidc
world.
A
But
here
you
can
know,
that's
where
you
send
a
user
to
get
a
token
and
there's
a
slash
token
endpoint
some
here.
That's
that
tells
you
where
you
would
post
this
to
so
a
bit
of
an
afterthought
cool
so
enter
oidc.
So
oidc
stands
for
open
ID
connect,
open
ID
was
another
form
of
authentication
that
kind
of
got
shut
down
by
a
lot
of
people.
It
was
a
way
to
have
Federated
logins,
but
it
kind
of
was
replaced
with
oauth
and
then
brought
back
again
through
oidc.
A
It
is
an
extension
to
olap,
so
it's
a
thin
layer
built
on
top
of
oauth.
It
uses
Json
web
tokens.
It
has
this
concept
of
an
ID
token.
So,
along
with
that
access
token,
you
would
get
back.
You
would
get
back
an
ID
token,
and
this
is
supposed
to
contain
information
about
the
user
by
itself
as
a
standalone.
A
A
It
comes
with
a
standard
set
of
Scopes
open
ID
is
the
scope
that
you
introduced.
That's
pretty
much
the
only
magic
behind
getting
an
oidc
token
from
a
oauth
provider.
Usually
is
you
have
to
stick
in
the
open,
ID
scope,
the
profile,
scope
and
I
mentioned
Discovery
before
so?
Idc
has
well-known
discovery,
which
I'll
show
in
a
second
quick
breakdown
of
Json
web
tokens.
You
may
have
seen
before
usually
called
jots.
There's
three
big
section
in
it.
It
has
a
header.
A
The
header
contains
the
algorithm,
the
key
ID,
what
it
was
signed
with
all
that
jazz.
It
has
a
section
called
payloads
or
claims.
This
is
actually
what
is
assigned.
So
this
holds
the
information
about
the
token
who
it's
for
who
created
it,
how
long
it
lasts
for
and
then
there's
that
signature,
which
is
the
first
two
parts
put
together
and
kind
of
sign
with
an
RSA
signature.
A
The
claims
section
there's
some
pretty
standard
claims
that
we
use
everywhere
a
subject
or
sub.
This
is
the
client
ID
that
you
would
usually
use
throw
off.
So
this
identifies,
who
this
token
is,
is
for
who
owns
this
token,
the
audience
field?
This
is
who
the
token
is
intended
for
so
that
auth's
over,
so
who
should
accept
this
token?
A
The
issuer
this
is
who
who
minted
this
token,
who
created
this
token,
so
accounts.google.com
accounts.spotify.com
issued
at
timestamp,
expires
time
stamp,
and
then
this
jsonweb
token.io
site's
pretty
great.
So
you
can
come
in
here
and
paste
the
token
in
and
see
the
breakdown
of
what
it
looks
like
decoded.
A
So
you
can
see
the
algorithm
that
this
is
signed
with
the
type
of
token
the
subject:
arbitrary
field
called
name
and
then
when
this
was
issued,
and
then
you
can
verify
the
signature
so
cool,
that's
the
Json
web
token
and
there's
also
step
CLI,
which
is
rad.
If
you
want
to
do
this
on
the
command
line,
you
can
use
a
step
CLI,
the
folks
over
at
step,
crypto
Json
web
token
inspect
insecure,
because
we're
not
going
to
verify
the
signature
and
it'll
print
out
the
same
thing.
A
So
I
stood
up
a
development
environment
for
OCTA
very
straightforward
stuff,
so
this
is
a
full
proper
two-spec
oidc
flow
right.
So
this
shows
the
oauth
endpoint
URL.
It's
got
my
client
ID
in
there
response
type,
blah
blah
blah
callback
and
then
the
Scopes.
It
shows
profile,
open,
ID
and
email
start
up
a
server
same
thing
as
before
call
back
at
that
code,
trade,
it
out
more
credentials
to
leak
grab
the
access
token
grab
the
ID
token
right.
A
A
A
Don't
actually
leak
this
one.
This
is
important
there
we
go
sign
in
get
that
call
back
cool.
So
here
we
have
the
access
token
that
came
back,
so
we
can
take
a
look
at
that.
Octa
actually
uses
a
Json
web
token
as
their
access
token
there's
nothing
wrong
with
doing
that.
It's
just
they're
using
that
as
a
mechanism.
Instead
of
sending
you
some
arbitrary
API
key.
So
we
can
pop
that
in
here
see
the
key
ID
that
it
was
signed
with
the
algorithm
information
about
me.
A
Here's
the
issuer,
my
OCTA
domain,
the
Scopes
that
are
on
it,
the
subject,
that's
my
email
cool
and
then
we
can
look
at
the
actual
ID
token
that
came
back,
which
will
have
a
bit
more
I
sat
down
and
compared
the
two
again.
Octa
is
a
special
case
where
they
use
the
Json
web
token
for
both.
But
this
has
a
bit
more
information
about
me
as
a
person,
so
it
has
my
preferred.
Username
I
was
trying
to
get
like
my
city
and
stuff
in
here.
A
I
couldn't
figure
out
how
to
do
that
right,
but
this
would
identify
me
as
a
user
same
kind
of
stuff
there's
the
audience.
That's
my
user,
ID
and
OCTA
the
subject
so
cool
and
then
below
was
that
user
info
endpoint
right
so
pretty
much
the
same
stuff.
That's
in
there
just
turned
into
a
Json
web
token
see
this
one
has
more
info
like
my
time
zone,
stuff.
A
A
Accounts.Google.Com
is
Google's
issuer.
There's
this
well-known
field,
which
is
really
neat.
So
this
is
where
you
can
go
check
out.
The
open,
ID
configuration
for
any
sort
of
Provider,
that's
just
public
information,
so
I
like
showing
Googles
so
Google
shows
their
issuer
authorization
endpoint
same
thing
with
the
the
oauth
I
showed
before,
but
it's
used
a
lot
more
in
oidc.
So
if
you
go
to
attach
this
to
a
service
or
provider,
it's
saying:
hey
trust,
my
identity
provider.
A
It's
going
to
go
and
actually
grab
this,
take
a
fingerprint
of
it
and
that's
how
it's
going
to
save
and
you
know,
register
if
anything
changes.
A
couple.
Other
bits
raised
with
a
token
endpoint
the
claims
that
it
supports
some
of
some
providers.
Don't
do
this
and
some
don't
respect
the
claims
in
the
first
place,
the
token
types
that
hands
out:
Jason,
Webb
Bearer
token
right
all
that
stuff,
always
the
field
I'm.
Actually,
looking
for!
Oh
here,
you
go
the
Jason
Webb
key
set
ID
right.
So
that's
the
next
field,
that's
in
here!
A
So
the
jwks.
This
is
what
the
basically
the
public
Key
Ring
of
that
provider.
So
it
has
to
tell
inside
of
that
well-known
configuration
point
where
the
consumer
should
go
to
get
their
keys
and
that's
how
it
does
it.
So
Google's
is
actually
at
this
URL
same
kind
of
deal.
This
is
again
a
Jason
Webb
key
set
has
a
key
type
key
ID.
A
These
are
the
the
parameters
to
generating
that
key
right.
The
exponent
All
That
Jazz,
these
rotate
there's
a
whole
bunch
of
magic
and
procedure
behind
how
this
rotates
you're
supposed
to
keep
the
old
one
around
for
a
little
bit.
So
I
think
that
there's
two
yeah
there's
two
in
here,
so
here's
the
one
that
they're
probably
using
right
now
to
sign
and
then
here's
the
one
that's
being
deprecated
and
phased
out.
A
All
this
is
tied
under
an
umbrella
called
Josie
or
Jose.
Json
objects
signing
an
encryption.
So
if
you
want
to
know
more
about
how
this
works
check
out,
those
rfcs
and
specs
I
actually
had
to
implement
a
few
of
them
from
scratch
and
python.
It
was
miserable,
but
that's
where
all
this
is
umbrella
under,
and
so
why
do
we
care
about
oidc?
And
so
this
is
the
point
of
talk.
A
Is
this
concept
of
federation
I
have
folks
familiar
with
Federation
yeah,
maybe
a
little
bit
so
Federation
is
just
kind
of
like
a
magic
trust
relationship
between
an
issuer
and
a
resource
provider.
Right
Google
provides
a
service
called
workload.
Identity
Federation,
that's
rad,
but
what
really
is
is
just
like
a
trusted
person
sitting
in
a
cardboard
box
that
takes
a
token
from
this
one
and
hands
it
out
this
side.
There's
no.
Like
actual
you
know,
spec
or
RFC
behind
any
of
this
works,
it
could
be
solved
by
a
person
in
a
box.
A
There's
no
longer
lived
credentials
with
Federation,
which
is
great,
and
so
this
would
be
I'll
show
you
a
demo
in
a
second,
where
your
CI
CD
provider
injects
a
unique
oidc
token
into
every
pipeline
run
that
can
be
traded
out
for
a
gcp
credential,
an
AWS
credential,
so
you
no
longer
have
to
provision
those
long-lived
identities,
store
them
as
environment
Secrets
inside
of
your
CI
provider,
and
have
to
worry
about
them
leaking
or
anything.
There's
no
search,
it's
just
trust,
usually
the
the
provider.
A
What
will
happen
is
it
will
take
that
oidc
token
hand
it
to
the
trusted
source
so
go
to
Google
cloud
and
usually
assume
a
roller
identity,
so
this
is
tied
to
an
actual
service
account
it's
super
auditable.
So
all
this
is
auditable.
You
can
track
who
assumed
that
I
identity
where
it
came
from
in
the
case
of
GitHub
when
they
issue
tokens,
you
know
the
pipeline
ID
that
ran.
You
know
the
repo
the
time.
What
caused
that
pipeline
to
start?
A
Where
can
you
do
this
and
where
will
you
find
these
so
I
mentioned
cicd,
GitHub,
gitlab,
Circle,
CI,
I
think
semaphore
a
bunch
of
different
providers,
so
this
is
becoming
way
more
Pro
prominent
now,
injecting
this
token
into
every
run,
which
is
cool.
There's
a
Jenkins
plugin
if
you're
using
Jenkins
to
get
oidc
tokens
issued.
A
A
There
kubernetes
clusters
do
this,
so
I
have
a
kubernetes
demo
somewhere
I
showed
you
Sig
store
signing
with
Sig
store,
signing
I
show
doing
it
manually
and
I
had
to
go
through
the
oauth
flow,
but
if
you're
doing
say
a
again
of
action
to
release
a
binary
and
you
want
to
sign
a
binary
as
part
of
an
action
pipeline.
You
can
take
that
oidc
token
trade,
that
for
a
a
Sig
store
signing
certificate
without
any
you
know
pop-up
or
oauth
flow,
and
it
gets
tied
back
to
that
actual
workload.
A
So
you
know
the
provenance
of
where
that
artifact
was
built
and
all
that's
signed
in
a
testable.
So
this
is
a
GitHub
action
token.
This
is
injected.
If
you
set
a
I.
Think
it's
like
token
right,
true
or
something
and
your
permissions
for
your
your
GitHub
manifest
same
kind
of
deal.
You
can
see
the
subject
here.
A
That's
going
to
identify
the
repo,
the
environment
actions
has
the
concept
of
different
environments
that
you
can
use
for
different
Secrets
audience
right
who
this
is
the
repo
is
for
the
ref
of
that
thing,
right
so
very
unique
stuff
to
a
CI
provider,
but
they
can
all
get
put
in
there
actor
ID
bunch
of
other
stuff
right,
so
very
cool.
The
issuer
is
issuer
or
tokens,
not
actions.githubuser
content.com
right.
So
your
Cloud
would
trust
this.
A
A
I,
don't
even
know
how
long
I
have,
let's
see
I
have
no
person
or
timer.
Thank
you,
perfect
timing.
Actually,
so
I
can
come
into
my
GitHub
here,
for
this
project
show
you
what
this
manifest
looks
like
right.
So
this
is
a
manual
dispatch.
There's
that
permission.
So
this
is
how
you
get
the
token
injected.
I
just
have
that
job
blah
blah
blah
runs
on.
So
this
is
going
to
check
out
the
repo
it's
going
to
set
up
that
Google
up.
A
So
that's
actually
the
magic
thing
that
happens
here
so
I
have
a
trust
relationship
I've
set
up
in
gcp
that
it's
trusting
this
particular
pipeline
in
this
action.
So
it
has
the
mapping
there,
and
so
this
action
will
set
up
and
trade
out
for
a
token
which
I
have
a
manual
workflow
for
too,
and
then
it
has
the
service
account
that
it's
assuming
inside
of
gcp
and
then
it's
going
to
run
that
gcloud,
CLI
and
just
kind
of
list
out
who
I
am
so.
Let's
kick
that
off.
A
Setting
up
gcloud
this
is
the
longest
step.
It's
got
to
download
the
the
binary.
It's
already
set
up
the
credentials
you
can
see
it
created
Created
credentials
file
at
this
path,
so
it
already
has
the
the
token
exchanged
it's
going
to
run
that
who
am
I
there.
We
go
right,
so
you
can
see
that
it
is
actually
assumed
that
service
account
so
that
works
cool.
A
A
Open
ID
configuration
right,
so
every
kubernetes
cluster,
that's
in
a
managed
service
will
have
an
oidc
provider,
that's
usually
backed
by
their
Im.
So
gcp
will
tie
this
to
service
accounts
inside
of
IM
there
same
thing
with
eks.
You
can
do
this
in
your
own
clusters
too.
You
can
provide
your
own
oidc
provider
or
kubernetes
will
run
one
on
your
behalf
and
tie
it.
But
you
can
see
here
is
the
issuer
from
my
cluster
right,
it's
tied
to
a
specific
project
and
a
certain
region
and
the
cluster
name
right.
A
There's
where
you
could
find
that
the
key
store
for
my
cluster.
Let's
see,
is
it
public?
That's
a
private
IP.
What's
supported
right,
so
every
kubernetes
cluster
has
this,
which
is
really
cool.
So
if
you
have
your
your
workload
run
and
tecton
actually
does
this.
Anyone
use
tecton
for
CI
CD
tecton
is
a
a
open
source
project
for
CI
CD,
that's
kubernetes
native,
and
it
will
use
this
provider
to
do
all
of
your
federating
and
signing
and
a
testing.
So
it's
really
cool.
A
So
I've
been
calling
this
oidc
wave
2.
everything
I
just
showed
you
that
GitHub
action
pipeline,
my
kubernetes
cluster,
none
of
those
are
actually
attached
to
oauth
at
all
and
I'm
sure,
there's
someone
out
there
who
will
have
a
better
explanation
or
definition
of
what
this
is.
But
for
my
naive
self,
this
is
a
extension
beyond
what
oidc
was
intended
for
this
machine
to
machine
authentication
right.
Github
actions
was
really
the
first
provider
to
do
this,
where
they
were
injecting
these
tokens
into
those
runs.
A
There
is
no
oauth
involved
at
all
with
how
they
mint
those
tokens.
It
is
a
machine
identity
right.
This
is
where
we're
all
moving
towards
I.
Don't
think
we'll
have
time
to
talk
about
spiffy
Inspire,
but
the
the
idea
of
having
your
trust
relationship
between
a
identity
provider
and
a
resource
consumer
or
a
producer
is
just
that
implicit
trust.
So
it's
there's
no
long-lived
credentials
on
either
side.
A
So
it's
just
it's
just
interesting
to
see
how
this
has
evolved
beyond
the
need
for
having
oauth
attached
to
it
and
at
the
end
of
the
day,
who
do
you
want
signing
your
releases?
Do
you
want
your
releases
assigned
to
a
Eddie
at
chain
guard.dev
that
you
know
may
still
may
have
been
signed
like
three
years
ago,
but
I
haven't
worked
there
for
two
years.
A
A
With
all
with
all
things,
you
need
to
trust
but
verify
the
fun
thing
is
that
anyone
could
actually
mint
a
valid
oidc
token
there's
nothing
that
really
says
otherwise.
The
claims
actually
matter
that
are
inside
there.
You
can
put
whatever
you
want
in
that
audience
and
subject
field
issue.
Subject:
audience
are
really
important
ones
that
you
want
to
make
sure
are
verifiable.
A
What
happens
if
there
was
a
service
who
were
to
issue
tokens
with
whatever
I
went
and
built
one
for
fun,
I
called
it
just
trustme.dev,
and
so
this
is
a
service
that
you
should
not
use
for
anything
real,
but
it's
fun,
and
so
it
will
just
mint
tokens
with
whatever
you
pass
in
as
the
URL
parameters.
So
here
we
have
a
token
that
let
me
toss
this
debug
parameter
in
the
URL
right,
so
I
have
issued
a
token.
That
is
the
audience,
is
sts.amazonaws.com
cool?
A
A
Cool
still
a
valid
token.
Well,
what
if
I
also
have
the
subject
in
here
of
something
like
admin
at
cncf.io
right
so,
if
I
hand
this
this
is
a
valid
token.
You
can
totally
verify
the
signature
if
I
hand
this
off
to
a
provider
what's
to
stop
them
from
trusting
it.
What's
to
stop
them
from
actually
knowing
this
is
forged.
A
Well,
thankfully,
smart
people
have
figured
out
how
to
prevent
this,
though
there
are
definitely
Services
out
there
that
are
not
checking
the
fields
and
and
they're
just
getting
a
valid
token
with
the
issuer
and
they're,
definitely
not
verifying
that
it's
who
it's
for
or
where
it's
coming
from
and
so
I
had
a
quick
AWS
demo,
where
I
can
do
AWS
a
simple
token
service,
assume
role
with
web
identity.
I
have
a
a
RN,
a
role
in
here
session,
name,
duration,
cool
and
then
I
just
have
to
pop
in
this
web
identity.
A
A
A
Right
so
I
have
a
trust
relationship
set
up.
It's
just
gonna
trust,
whatever
I
said
in
this
case
this.
This
is
what
it's
supposed
to
happen,
but
the
the
way
that
the
cloud
provider
gets
around
this
is
you
actually
have
to
specify
outside
of
the
token
who
your
audience
is
for
right.
So
it's
just
another
step
here:
the
protection
against
so
verify
token
and
claims
you
want
to
make
sure
you're
actually
matching
that
issuer
to
the
issuer's
key
right.
So
the
key
shouldn't
match.
A
If
you
do
it
the
incorrect
way,
you
want
to
pass
the
audience
alongside
that
token,
so,
Google
Cloud
does
it
cool
too.
They
have
the
docs
right
here,
the
the
token
Amazon's
the
same
way.
So
you
have
the
token
here
that
you
would
passed,
but
you
also
specify
the
audience
as
well,
so
the
audience
and
the
requests
should
match.
What's
in
the
token
and
that's
how
you
can
ensure
that
it's
for
the
correct
project,
Dex
is
a
a
front
end
for
other
apps
I.
A
Don't
think
I
have
much
time
to
talk
about
it,
but
if
you
go
through
that,
Sig
store
oil
flow
and
where
I,
where
I
showed
signing
that
git
commit
that's
actually
decks.
That's
running
behind
the
scenes,
so
decks
can
Federate
those
different
identity
providers
to
a
different
application,
so
it
can
handle
all
the
attaching
and
plugging
in
50
spiers
for
machine
identities.
I'm
not
going
to
try
to
explain
that,
because
I'm
running
out
of
time,
the
one
last
thing
I
wanted
to
show
was
how
this
workload
Federation
Works
behind
the
scenes.
A
So
this
is
grabbing
an
oidc
token.
This
is
a
valid
one
for
my
service,
so
gcp
is
set
up
to
trust
me,
and
so,
if
we
look
at
what
that
token
looks
like
real
quick,
so
you
can
see
that
the
audience
is
my
gcp
identity
pool
that
I
set
up
issuer
and
the
the
subject
Google
actually
takes
that
and
it
gets
traded
for
a
Federated
access
token.
So
this
is
kind
of
like
a
secret
proprietary,
this
basically
Marshalls
into
a
protobuf,
and
so
your
service
gets
back
this
identity
token
after
it
talks
to
Google.
A
You
have
to
take
that
then,
and
you
have
to
take
hit
another
endpoint
that
says:
hey
I
have
a
Federated
identity.
Token
can
I.
Please
have
an
access
token
on
behalf
of
this
user,
so
Google
will
go
and
mint
that,
and
that's
actually
the
token
that
you
can
use
to
hit
that
who
am
I
endpoint.
So
that's
what
this
is
showing
so
with
that
I
am
most
likely
out
of
time.
If
you
want
the
slides,
you
can
take
a
picture
of
that.