►
From YouTube: SPIFFE and SPIRE in Practice
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
There
we
go.
I
am
libby
schultz
I'll,
be
moderating.
Today's
webinar
we'd
like
to
welcome
our
presenters
dan
feldman
principal
software,
engineer
at
hewlett,
packard,
enterprise
and
umar
khan
marketing
product
marketing
lead
at
hewlett,
packard
enterprise.
Excuse
me
a
few
housekeeping
items
before
we
get
started
during
the
webinar
you're,
not
able
to
talk
as
an
attendee
there's
a
q,
a
box
at
the
bottom
of
your
screen.
A
Please
feel
free
to
drop
your
questions
there
and
we'll
get
to
as
many
as
we
can.
At
the
end.
This
is
an
official
webinar
of
the
cncf
and,
as
such
is
subject
to
the
cncf
code
of
conduct.
Please
do
not
add
anything
to
the
chatter
questions
that
would
be
in
violation
of
that
code
of
conduct.
Basically,
please
be
respectful
of
all
your
fellow
participants
and
presenters.
B
Hey
everyone.
Thank
you.
So
much
for
joining
us
today,
we'll
be
talking
about
specially
inspired
in
practice,
just
curious
just
put
in
the
chat
window.
How
many
of
you
already
know
about
spiffy
inspired,
just
a
plus
one
in
the
chat
window
and
just
to
make
sure
everyone
is
focused.
B
We'll
do
a
quick
recap
for
oh
wow.
I
see
a
lot
of
plus
ones,
so
we'll
do
a
quick
recap
of
spiffing
inspired.
We
won't
spend
too
much
time
on
it
and
so
that,
if
you
know
I
see
a
couple
of
you
are
new
to
spiffy
inspire.
B
So
we
just
want
to
make
sure
that
you
know
we
have
context
for
everyone
and
then
we'll
start
going
into
a
deep
dive
into
some
of
the
use
cases
that
we
have
seen
spiffy
community
members
using
the
projects
for
next
slide.
Please.
B
So,
just
to
give
you
a
quick
recap:
specific
inspire
are
part
of
cncf
hp
is
one
of
the
contributors.
There
are
other
vendors,
other
enterprise
organizations,
cloud
native
organizations
that
are
all
contributing
and
adopting
code
to
the
projects.
I-
and
I
hope
some
of
the
organization
includes
you
know
some
of
the
folks
on
this
call
as
well.
B
The
projects
are
have
recently
moved
to
the
incubate
stage
now
at
cncf
and
it's
tightly
integrated
to
various
open
source
projects
such
as
envoy,
nginx,
hashicorps,
vault
and
a
bunch
of
others
as
well,
and
we
have
seen
more
and
more
public
talking
about
organizations
talking
about
how
they're
adopting
specific
inspire
and
some
of
the
five
use
cases
or
five
patents
or
practices
that
we
have
seen
across
this
company.
We
are
sharing
this
as
well.
Next
slide,
please!
B
So
if
you
take
a
step
back,
what
problem
do
spiffy
inspire
solve
and
not
spending
too
much
time
on
it,
because
it
seems
like
a
lot
of
you
already
have
basic
knowledge
of
spf
inspire.
You
know
everyone
is
is
seeing
you
know
this
explosion
of
you
know
cross-service
communications.
You
have
all
these
software
services
running
across
multiple
platforms
in
the
old
age
you
they
used
to
run
within
your
data
center.
Now
this
on
outside
your
data
center
on
partner
side
on
multiple
cloud
platforms
and
as
you
have
dot
micro
services
based
architecture.
B
This
this
problem
is
even
more
complex
and
now
there's
the
risk
of
all
these
long-lived
service
credentials
across
different
platforms,
and
these
platforms
have
their
own
specific
way
of
managing
credentials
for
these
software
services.
B
But
still
every
day
we
hear
about
a
new
leakage
of
some
sort
that
happened
off
credentials
across
the
board,
so
there's
a
security
problem
that
we
are
solving,
but
if
next
slide,
if
there's
also
what
you
call,
I
want
to
use
the
word
dev
sec
hops.
But
you
know
an
operational
complexity
issue
that
we
are
trying
to
solve
as
well.
The
fact
that
you
have
multiple
authentication
mechanisms,
multiple
ways
of
identifying
software
services
or
saving
your
credentials
across
different
platforms.
B
It's
a
tool
on
development
teams
and
platform
teams
as
well,
because
they
have
to
learn
credential
management,
that's
very
platform
specific
at
times
either
or
they
have
to
do
their
own
authentication
mechanisms
or
write
some
custom
codes
or
learn
encryption
or
integrate
with
existing
systems.
So
they
spend
a
lot
of
time
in
this
when
they
should
be
focused
on
the
business
logic
and,
at
the
same
time,
the
security
teams
as
well.
You
know,
they're
afraid
you
know
of
the
developer
and
platform
teams
at
times
and
they
have
to
they.
B
They
make
sure
that
these
development
organization
or
platform
engineering
organizations
are
abiding
by
their.
You
know
compliance
and
audit
requirements
and
they
have
proper
way
mechanism
of
securing
secrets
and
securing
credentials
for
different
applications
and
there's
there's
a
lot
of
cycles
that
they
are
spending
as
well.
Next
slide,
please,
and
especially,
inspire
really
provide
a
mechanism
of
managing
you
know
giving
you
this
central
uni
universal
identity
control
plane
to
manage
across
platforms
and
dan
is
going
to
talk
a
bit
more
about
the
problem.
They're
solving
and
a
quick
overview.
C
Yeah
sure,
thanks
sumer,
so
we
there's
this
expression
for
infinite
regression
called
it's
turtles
all
the
way
down,
and
we
actually
wrote
a
book
just
a
couple
months
ago
called
solving
the
bottle
bottom
turtle
which
you
can
get
here.
But
what
we're
referring
to
there
is
that,
in
in
every
security
system,
you've
got
a
chain
of
trust,
so
you've
got
maybe
a
certificate
for
your
service.
C
That
then
depends
on
a
secret
store
from
the
platform,
some
kind
of
identity
for
the
platform.
Usually
it
comes
down
to
your
initial
configuration,
the
join
tokens
you
use
to
set
up
kubernetes
the
certificates
you
install
on
the
servers
that
then
depend
on
a
certificate
authority
that
you
configure
manually.
C
What
we're
really
doing
with
spiffy
inspire
is
we're
providing
what
we
call
that
bottom
turtle,
the
the
end
to
the
infinite
regression
where
we
can
distribute
the
root
certificates,
the
root
of
trust
to
everyone
throughout
your
system
without,
depending
on
any
kind
of
initial
configuration,
we
can
get
that
straight
from
your
cloud
provider
straight
from
your
hardware
straight
from
your
configuration
software
and
not
have
to
depend
on
some
kind
of
leaky
abstraction
at
the
bottom,
to
provide
the
route
of
trust
for
your
infrastructure.
C
So
the
key
concepts
behind
spiffy
inspire
that
you
need
to
understand
in
order
to
understand
how
they
work.
First
of
all,
we've
defined
this
thing
called
a
spiffy
id.
This
is
a
standard
format
for
identifying
services
in
your
network.
It
looks
just
like
a
url.
This
is
really
easy.
It's
just
a
string
starting
with
spiffy
colon,
slash,
slash,
and
then
it
has
a
trust
domain
component
which
is
unique
to
your
organization
and
then
a
name
for
your
service.
That's
all
it
is.
C
Then
we've
come
up
with
these
definitions
for
spiffy,
verifiable
identity
documents,
and
these
are
cryptographically
verifiable
documents
that
assert
specific
spiffy
ids
and
when
I
say
cryptographically,
verifiable
document
that
sounds
scary.
What
we're
really
talking
about
is
x509
certificates
and
javascript
web
tokens
or
jots,
and
both
of
those
formats
are
available.
The
advantage
of
using
the
x
509
certificates,
of
course,
is
you
can
use
that
to
establish
tls
connections
that
are
mutually
authenticated
on
both
sides
and
then
the
advantage
of
the
javascript
web
tokens
is.
C
You
can
use
them
in
all
kinds
of
situations
that
require
javascript
web
tokens.
Then
there
are
trust
bundles.
These
are
the
public
keys
that
can
be
used
to
verify
svids.
So
it's
a
single
file
format
that
spiffy
is
is
synchronizing
all
the
time
between
all
the
all
the
nodes
in
your
infrastructure
that
allows
any
service
to
verify
any
spiffy
verifiable
identity
document
in
that
trust
domain.
C
So
this
is
just
like
the
the
root
certificate
bundle
that
comes
with
your
operating
system
or
your
web
browser
except
there's,
just
one
tweak,
which
is
that
it
works
with
both
those
javascript
web
tokens
or
x,
509
certificates.
But
that
that's
a
really
a
minor
detail-
and
this
is
in
a
standard
format
that
actually
a
lot
of
different
services
already
understand
and
finally,
there's
the
workload
api-
and
this
is
this-
is
the
most
important
and
maybe
the
most
subtle
part
of
spiffy.
C
C
We
have
a
lifetime
for
these
identity
documents
of
four
hours,
so
they're
constantly
rotating,
and
this
is
what
makes
spiffy
really
different
from
any
other
kind
of
public
key
infrastructure
that
you
might
have
worked
with,
even
though
the
file
formats
are
the
same,
all
the
credentials
are
constantly
changing
under
the
hood,
which
is
why
you
need
this
workload.
Api.
That's
constantly
pushing
these
documents
to
your
services.
Now,
when
I
say
it's
a
local
api,
why
is
it
a
local
api?
C
C
So
what
are
the
core
differentiators
of
spire
compared
to
other
other
types
of
infrastructure
security
products,
and
I
should
just
clarify
that
spiffy
is
the
open
standard
for
what
we're
doing
with
distributing
trust,
bundles
and
svids
and
and
spiffy
ids
to
infrastructure?
Inspire
is
our
implementation,
so
with
spire
we're
we're
doing
this
real-time
attestation
of
all
the
services
in
your
infrastructure.
C
So
if
it's
a
kubernetes
service,
we're
talking
to
kubernetes
and
verifying
that
your
kubernetes
service
account
that
you're
using
is,
is
what
it's
supposed
to
be.
According
to
the
configuration
we
can,
we
can
check
the
hardware
if,
if
you
have
a
tpm,
we
can
check
the
system
integrity
using
linux
system,
integrity,
measurements.
One
thing:
I'm
working
on
a
lot
right
now
is
checking
if
it's.
C
If
the
binary
that's
running
has
been
signed
by
the
cicd
pipeline
and
we'll
have
a
demo
or
sorry
we'll
have
a
little
bit
more
on
that
later
on.
So
we've
got
all
these
different
attestations
to
make
sure
that
every
service
is
who
it's
supposed
to
be
and
again
these
are
all
short-lived
credentials
and
they're
rotating
frequently
every
couple
of
hours.
So
you
don't
necessarily
need
to
worry
about
revoking
certificates
or
having
too
many
certificates
outstanding,
because
they're
changing
all
the
time
and
we're
reducing
the
overhead
associated
with
the
credential
management.
C
So
none
of
this
is
a
human
process.
The
security
engineers
just
need
to
configure
it
at
the
beginning
and
then
spire
will
will
distribute
all
the
key
material
to
all
the
services
that
are
supposed
to
have
it.
Now,
it's
an
extensible
architecture.
We
have
users
with
hundreds
of
thousands
of
nodes
already
using
many
different
spire
servers
that
are
that
are
interlinked,
so
this
is
really
ready
for
web
scale
environments
in
a
way
that
a
lot
of
a
lot
of
similar
security
products
aren't
quite
yet.
B
B
Yeah,
I
think
now
we're
going
to
go
a
bit
deeper
into
the
use
cases.
What
folks
are
using
spf
inspired
for,
naturally,
it's
great
to
have.
You
know
your
entire
infrastructure
running
on
spire
and
authenticating
across
the
board,
but
these
are
some
of
the
unique
problems
or
unique
angles
other
because
other
users
are
using,
especially
inspired
for.
I
know,
there's
already
a
question
by
jacob
dan.
I
want
to
give
you
a
heads
up.
The
question
is
around:
how
is
it
different
than
service
mesh?
I
think
you
covered
that.
B
You
know
in
a
couple
of
slides
anyway,
so
just
wanted
to
give
you
a
heads
up.
I
think
you
also
is
talking
asking
about
integration
with
linkedin.
We
don't
do
direct
integration
with
liquidity,
yet,
but
dan
will
explain
that
in
much
more
detail
in
a
bit,
yeah.
C
All
right,
so
one
of
the
the
first
things
that
people
want
to
do
with
spiffy
inspire
is
simply
to
establish
mutually
encrypt
mutual
tls
connections
between
two
services.
So
if
you're
in
kubernetes,
you
have
two
services,
maybe
they're
running
on
two
different
nodes,
spiffy
and
spire.
Well,
first
of
all,
you
set
up
a
spire
server
and
then
an
agent
running
on
each
node.
So
this
is
just
a
demon
set
in
kubernetes
terminology
and
it's
giving
each
service
its
svid,
its
trust,
bundle
and
its
spiffy
id
on
the
side.
C
Also
it
has
its
sfed
trust,
bundle
and
spiffy
id
and
then
remember.
One
of
the
formats
that's
available
for
those
svids
is
an
x509
certificate.
So
then,
these
services
can
simply
establish
a
mutual
tls
connection.
Now,
like,
like
jacob
just
said
in
the
in
the
question,
how
is
this
any
different
from
service
mesh,
because
a
lot
of
service
meshes
can
do
this
initially?
C
Well,
the
first
thing
and
something
that
a
lot
of
our
users
are
really
interested
in
is
that
we
have
that
that
low
level
attestation,
so
we're
actually
talking
at
a
low
level,
to
your
hardware,
to
your
cloud
provider,
to
you
to
the
kubernetes
platform,
which
I
guess
most
of
the
service
meshes,
would
be
able
to
do
in
order
to
verify
that
each
service
is
who
it
really
says.
It
is
so
that's
the
first
differentiator
and
then
the
second
is
really
simple.
C
If
you
have
two
different
platforms,
maybe
one's
running
in
kubernetes
one's
running
in
mesos
one's
running
on
windows,
one's
running
on
you
know
a
raw
ec2
instance.
As
long
as
those
platforms
all
have
the
spire
agents
configured,
they
can
still
establish
mutual
tls
connections,
and
none
of
the
service
meshes
really
offer
that
some
of
them
are
are
trying
to
break
outside
the
kubernetes
world
a
little
bit
but
they're,
usually
not
quite
there
yet,
except
for
console,
which
is
more
in
hashicorp,
land,
etc.
C
Each
service
mesh
is
usually
tied
to
a
platform.
Well,
spire
is
platform
agnostic
now,
as
far
as
actually
using
these
asvids,
these
certificates
or
jots.
In
order
to
connect
to
other
services,
well,
there's
a
couple
different
options:
one
is
your
service.
Can
you
can
change
the
code
to
directly
talk
to
the
spire
agent
and
get
its
get
its
asvid
dynamically?
C
Another
option
is
we
provide
a
utility
called
spiffy
helper,
which
literally
just
gets
the
svid
certificate
and
saves
it
to
a
file
and
then
signals
your
service
every
time
that
changes?
That's
actually
really
useful
for
integrating,
with
with
pre-existing
databases,
other
kinds
of
code
that
you
don't
really
want
to
change
and
and
we've
provided
scripts
that
help
integrate,
integrate
spiffy
helper
with
postgres
and
mysql.
C
That
sort
of
thing
and
finally,
the
most
common
configuration
is
actually
to
just
use
envoy
talking
to
the
spire
agent
to
fetch
its
certificates,
because
then
you
get
all
the
other
good
things
that
envoy
provides
in
terms
of
load,
balancing
and
observability
logging.
All
this
amazing
stuff
that
envoy
can
provide,
and
then
you
can
just
add
it's
literally
four
or
five
lines
of
configuration
in
order
to
get
the
svid
and
the
trust
bundle
in
order
to
establish
mutual
tls
connections.
C
So
as
a
comparison
to
service
meshes
so
we're
we
can
work
across
different
service
meshes
and
outside
service
meshes.
We
have
this
lower
level
attestation
we're
talking
to
the
hardware
we're
talking
to
the
cloud
and
you
have
more
fine-grained
control
over
certificate.
So
you
can
change
some
details
of
the
certificates
that
that
some
users
really
want
to
be
able
to
control
like
the
dns
names
that
are
in
the
the
cn
for
the
certificate.
C
B
Yeah,
I
I
think
definitely
what
like,
like
dan
mentioned
like
including
me
and
dan,
and
I
think,
about
10.
More
community
members
from
different
organizations
came
together
last
month
to
create
a
book,
and
that
included
some
case
studies
where
users
like
uber
square
pinterest,
anthem
and
a
bunch
of
others,
and
those
can
be
fine
in
their
book
as
well.
And
you
know,
uber
is
a
great
example.
They've
always
been
talking
about
publicly
about
how
they're
using
50
inspire
and
really
started.
B
If
you
look
at,
you
know
any
of
their
videos
on
youtube
or
any
of
the
studies
that
they've
done
with
cncf
is
basically
you
know
they
had
this
next-gen
infrastructure
based
on
microservices
and
they
realized
they
have
this
legacy,
not
in
a
bad
way,
but
you
know
traditional
infrastructure
as
well
that
they
built
out
and
they
are
using
spy
as
a
bridge
not
only
within
the
next-gen
infrastructure,
but
also
in
their
legacy
infrastructure
as
well.
So
it's
like
end-to-end,
you
know
standard
authentication
across
the
board.
B
I
think
then,
now,
if
you
want,
maybe
you
can
go
a
bit
deep
dive
into
how
we
work
with
service
mesh.
I
think
you
covered
how
we
are
different
than
service
meshes,
but
now,
like
let's
say
how
do
we
work
together
with
service
mesh
and
jacob
feel
free
to
type
another
question?
If
you
know
your
existing
question
wasn't
clear.
C
C
So
if
you've
got
some
kind
of
a
mesh
demon
here,
like
an
istio
agent
or
any
of
the
service
meshes,
you
can
have
the
spire
agent
running
alongside
it,
and
both
of
them,
like
I
said,
can
talk
to
your
envoy
proxy.
C
This
is
a
little
bit
of
a
generic
slide
because
it
doesn't
specify
any
any
particular
service
mesh,
but
then
you
can
use
you
can
use
spire
to
establish
connections
in
a
secure
way
between
multiple
different
service
meshes,
and
this
is
really
important
because
we're
working
with
a
lot
of
huge
companies
that
have
what
I'd
call
heterogeneous
infrastructure.
They
have
a
lot
of
different
teams
using
different
platforms
with
different
ideas
about
what
the
best
service
mesh
is.
Maybe
they're
buying
a
product
from
someone
else
that
includes
the
service
mesh
inside
it.
C
That's
something:
we've
come
across
so
establishing
secure
communications
between
service
meshes
is
actually
really
important
to
a
lot
of
users
and
again,
if
you
have
a
standalone
instance,
maybe
that
you
know
isn't
running
inside
kubernetes
isn't
running
inside
your
service
mesh
at
all.
You
can
still
establish
that
secure
connection.
C
Now,
a
couple
of
the
service
meshes
are
actually
integrating
with
spire
in
various
ways.
So
aws
app
mesh
in
their
beta
actually
does
support
using
spire
to
obtain
all
its
certificates
matter.
Kuma
nginx
service
mesh,
those
guys
are
using
spire
to
provide
their
certificates.
Natively
estio
was
actually
started
at
around
the
same
time
as
the
spire
project,
so
it
actually
produces
spire
compatible
certificates.
C
There
are
some
minor
differences,
but
we
can
we
can
make
them
work
together.
It
just
takes
a
little
bit
of
extra
configuration
in
istio,
but
we
do
have
users
using
istio,
inspire
seamlessly
together
and
network
service
mesh
and
open
service
mesh,
both
use
spire
in
different
ways.
It's
it's
a
little
bit
complicated
to
explain
and
those
ones
are
still
sort
of
emerging
at
this
point,
but
we're
working
closely
with
those
teams
to
make
sure
that
that
they're
using
spire
in
a
way
that's
compatible
with
everyone
else.
B
Yeah
great,
I
think,
they've
been
a
lot
of
experiments
being
done
by
the
community
as
well.
I
think
I
don't
know
if
you
attended
the
last
50
production
identity,
a
co-located
event
at
kubecon
ibm
shared
how
they
have
actually
retrofitted
spy
within
istio
and
replaced
that
their
cert
management
capability
with
spired,
just
because
they
wanted
that
stronger
attestation
piece
again,
that's
more
of
an
official
experiment,
but
they
have
definitely
shared
the
code
and
everything
as
well.
If
anyone
is
interested,
I
can
definitely
put
the
link
to
that
as
well.
B
So
now
we
talked
about
microservices,
we
talked
about.
We
talked
about
service
mesh,
how
we
play
with
those
spiffy
inspired
projects.
Another
thing
really
rudimentary!
If
you
look
at
you
know,
if
you
go
down,
if
you
go
to
the
next
slide,
it's
all
of
a
sudden.
When
you
know
organizations
are
adopting
kubernetes
and
container-based
infrastructures
and
tooling,
they
still
have
some.
These
services
need
to
access
that
are
not
running
on
containers
right
or
are
on
the
same
container
platform
right
so
and
they
typically
end
up.
B
You
know
generating
managing
credentials
or
using
some
sort
of
username
password-based
access
to
these
services,
but
what
we
have
seen
some
of
the
organizations,
especially
at
the
start
of
their
journey,
they
start
with
hey.
I
have
this
app
payroll
app
that
runs
on
you
know
this.
B
This
community's
clusters,
on-prem
or
you
know
a
flavor
of
a
cloud.
It
needs
to
access
this
s3
bucket
or
this
database
right.
How
do
you
do
that
without
you
know,
going
through
five
tools
or
generating
username,
passwords
and
credentials
of
that
and
that
sort
of
stuff?
What
spire
really
allows
you
to
do
in
the
next
slide,
as
dan
will
show?
You
is
basically
you
know
it
eliminates
the
need
to
generate
and
manage
these
credentials.
B
So
you
spy
can
act
as
a
and
can
use
built-in
capable
pki
capabilities
within
databases,
let's
say
to
use
firebase
certificates
to
access
to
databases
or
things
like
oidc,
which
open
id
connect,
which
you
know
dan
is
going
to
mention
that
as
well
and
really
secure
authenticate
into
an
s3
bucket
or
an
rds,
or
things
like
that.
So
this
is
another
getting
started
use
case.
A
lot
of
organizations
are
excited
about
when
they
start.
C
Yeah
sure
so,
first
of
all,
here's
a
bit
of
an
architecture
diagram
of
how
you
might
authenticate
to
aws
using
your
spire
certificates.
So
you
can
configure
spire
to
present
the
public
keys
of
the
trust
bundle
in
in
an
oic
oidc
federation
format.
C
So
this
you
create
a
public,
http,
endpoint
and
then
aws
im
can
can
natively
federate
with
that,
so
any
user
who's
established
on
the
spire
side
can
then
access
aws
resources
like
s3
storage
or
the
rds
database,
and
I'm
actually
going
to
be
showing
this
use
case
in
it
in
a
second
and
then
another
way
to
do
this.
Is
you
can
sorry?
This
diagram
is
a
little
bit
wrong.
C
I
just
realized
that,
but
you
you
can
use
this
to
authenticate
to
postgres,
basically
using
the
same
thing
even
outside
of
aws,
they
shouldn't
say
aws
apis,
but
you
can
use
the
the
same
oidc
federation
mechanism
to
authenticate
to
a
postgres
database
or
or
several
other
different
types
of
databases,
and
I
really
love
this
use
case,
because
there's
no
secret
that
that's
anywhere
that
can
be
stolen,
it
can
be
accidentally
left
enabled.
C
Instead,
every
service,
it's
has
its
identity,
directly,
attested
by
the
hardware
by
the
cloud
infrastructure
and
then
used
in
order
to
authenticate
to
resources.
So
I
do
have
a
quick
demo
here.
This
is
this
is
recorded
because
otherwise
it
would
take
way
too
long,
but
I'll
just
go
through
this
quickly.
So
this
is
an
app
we
created
just
as
a
demo,
app
to
simulate
a
common
customer
use
case.
C
This
is
a
bank
called
scrooge
mcbank
and
this
is
showing
the
user's
current
balance
and
then
their
recent
transactions,
both
of
which
come
from
different
services
that
are
running
in
aws,
but
the
the
main
bank
back
end
is
not
running
in
aws.
C
So
if
I
play
this
demo,
you
can
see
you
can
see
the
balance.
You
can
see
the
transactions
now
on
the
aws
side.
What
we've
done
is
we've
created
an
aws.
I
am
role,
you
can't
see
the
role,
but
this
is
the
identity
policy
document
for
the
role
and,
as
you
can
see,
sorry,
if
I
get
this
set
up,
I
can
draw
for
you
so
what's
here
is
these:
are
the
spiffy
ids
that
are
allowed
to
assume
the
role
you
can
see?
Transaction
service
balance
service?
C
These
are
allowed
to
access
the
the
aws
role
in
order
to
fetch
that
data
from
a
database-
and
then
this
here
this
is
the
location
of
the
oidc
identity
provider.
So
this
is
actually
a
public
http
endpoint,
that's
serving
those
public
keys
for
the
on-prem
services
that
are
outside
aws.
C
C
So
then,
in
the
next
step
of
the
demo
here
we're
actually
showing
the
job
tokens,
and
these
are
the
the
tokens
that
are
provided
by
spire,
and
I
know
you
can't
read
a
jot
token
unless
you're
much
smarter
than
I
am,
but
we've
decoded
these
using
the
jot
utility
and
you
can
see
the
token
that's
provided
by
spire,
you
can
see,
there's
a
there's,
the
spiffy
id
on
the.
So
again,
this
is
the
client,
that's
accessing
aws
and
you
can
see
when
it
was
issued.
C
C
And
then,
just
just
to
demonstrate
that
this
is
really
what's
happening.
We
can.
We
can
change
the
policy
document
on
the
aws
side
just
to
have
a
invalid
spiffy
id
here,
and
what
will
happen
is
now
that
that
spiffy
id
that
the
client
is
using
can
no
longer
talk
to
aws.
It
can't
load
those
transactions
anymore.
So
what's
what
we're
showing
here
is
really
a
powerful
idea
and
it's
a
little
bit
subtle.
C
It's
a
little
bit,
not
what
people
mostly
do,
but
we're
we're
authenticating
a
client
very
strongly
in
order
to
access
aws
without
any
token,
without
any
static
certificate
without
any
username
and
password,
and
then
that
client
can
access
aws
resources-
and
this
is
probably
the
most
powerful
use
case
for
spiffy
inspire,
certainly
the
one
that
I
like
evangelizing
the
most.
But
it's
a
little
bit
subtle,
because
most
organizations
aren't
able
to
do
anything
like
this.
Quite
yet.
B
B
Thanks
dan,
I
think
there
was
another
question
around
utilizing:
spire
with
lambda
functions.
I
think
there's
a
proposal
out
in
the
community
about
lambda
is
that
correct.
C
Oh,
that's
a
great
question,
so
square
square
payments
actually
uses
lambda
functions
extensively
and
they
are
right
now
using
spire
with
lambda
functions,
it's
a
little
bit
experimental
and
it's
a
little
bit
tuned
for
their
use
case.
We've
got
a
proposal.
C
Sort
of
an
rfc,
that's
out
to
the
spire
community
for
a
way
to
implement
lambda
functions
a
little
bit
more
formally
with
a
couple
of
different
options
for
for
how
to
do
it
with
pros
and
cons,
that'll
be
coming
into
spire
relatively
soon
within
the
next,
hopefully,
the
next
six
months
at
least
the
next
year
and
we'll
we'll
be
able
to
authenticate
serverless
functions.
It's
not
quite
there.
Yet,
unless
you
follow
square's
instructions,
they
have
a
blog
post.
C
Actually,
if
you
google
square
aspire,
serverless
all
three
words:
there,
squarespire
serverless
you'll
get
a
blog
post
from
the
square
team
about
how
they
got
it
to
work.
B
Yeah,
no
absolutely
I'll
I'll
post
that
shortly
now
so
going
to
the
next
one
like
you
can
go
ahead,
go
to
the
next
site
then,
and
going
to
the
next
slide,
like
another
use
case
that
we've
seen
a
lot
of
users
come
in
zero
trust
is
definitely
a
big
buzzword.
These
days
right
and
the
reason
is
organizations
realize
that,
because
you
know
the
organization,
boundaries
are
blurring,
you
know
the
traditional
network-based,
fireballs
and
network
networks,
fire
walls,
not
balls
were
basically
you
know,
are
not
enough.
B
Folks
are
using
network-based
network
segmentation
tools,
that's
pretty
hard
to
do
as
well
at
times,
especially
because
the
boundaries
are
blurring
between
their
data,
centers
and
cloud-based
infrastructures,
and
particularly
when
the
notion
of
an
ip
address
is
going
away.
When
you
have
all
these
dynamic,
dynamic
technologies,
cloud
or
containers
going
up
and
down
continuously
right,
so
the
security
parameter
based
security
is
going
away
and
we
have
seen
more
and
more
organizations
adopt
this
zero
trust
model
right
and
next
slide.
Please
and
zero
trust.
You
know.
B
For
those,
I'm
sure
everyone
pretty
much
has
heard
the
word.
Zero
trust
here
is
basically
the
shift
right
going
away
from
you
know,
building
this
trusted
wall
across
your
network
and,
yes,
all
those
technologies
are
important,
but
you
know
going
to
the
next
level
right.
Naturally,
they
are
a
lot
harder
to
do
in
cloud-based
and
dynamic
infrastructures,
but
at
the
same
time,
if
someone
gets
access
to
your
network,
they
can
pretty
much
create
havoc
right.
B
So
we
have
seen
a
lot
of
organizations
adopting
the
zero
trust
model
that,
at
his
core,
believes
in
identifying
authenticating
every
request.
It
doesn't
matter
where
it
runs
on,
but
in
identifying
the
request,
and
if
you
look
at
the
service,
identity
or
workload
identity,
that's
where
spiffy
and
spy
come
in
as
well.
So
if
you
have
zero
trust
initiatives,
if
your
network
teams
have
zero
trust
initiatives
do
if
you
are
working
in
a
network
team
as
well,
you
know
do
share.
You
know
the
applicability
of
spiffy
inspired
there
right.
C
C
Sure
so
so
we
do
have
users
who
are
really
interested
in
just
doing
zero
trust
everything
every
connection
between
services
anywhere
in
their
heterogeneous
infrastructure
has
to
use
mutual
tls
with
an
identity
provided
by
by
a
trusted
authority
that
can
that
can
check
that
services
real
credentials.
C
C
On-Prem
resources
in
the
data
center
sas
providers
manage
databases
that
that's
a
use
case.
C
We've
seen
is
actually
pushing
those
fire
credentials
in
as
the
as
the
user
credentials
to
access
managed
databases
like
rds,
so
each
service
would
get
its
own
unique,
secure
and
provable
identity,
and
one
of
the
users
that
that's
really
interested
in
this
is
anthem,
which
is
a
a
huge
health
insurance
company,
with
a
lot
of
organizational
complexity
like
like
a
lot
of
older
businesses,
a
lot
of
different
stuff
going
on
with
different
divisions
and
subdivisions
and
partners,
and
they
want
to
implement
zero
trust
security
throughout
their
entire
organization.
B
No,
like
I
mentioned
these,
are
these
practitioner
stories
are
available
in
that
book
as
well,
and
they
definitely
bring
to
life.
Why
cause
why
users
and
you
know,
are
actually
using
spiffy
inspire
so
at
anthem?
If
you
ask
them,
you
know
it
was
pretty
much
driven
top
down
because
they
were
building
this
next-gen
infrastructure
and
wanted
to
adopt
a
zero
trust
security
model.
B
They
started
with
exploring
you
know:
cncf
technologies,
zero
trust,
various
technologies,
and
they
that's
how
you
know
they
came
across
fire
and
a
bunch
of
other
products,
because
the
end
goal
is
to
you
know,
move
towards
a
zero
trust,
security,
posture
or
security
model.
However,
you
would
define
that.
C
B
Yeah,
I
think,
a
lot
of
times
we
especially
in
the
cncf
community
as
well,
because
we
have
a
lot
of
devops
flows
or
infrastructure,
folks
or
people
who
manage
devops
pipelines
and
things
of
that
sort.
So
there's
a
value
of
spiffy
inspire
there
as
well
right
like
for
for
the
end
developer,
because
the
complexity
is
gone
and
they
get
this
consistent,
dial
tone
api.
So
there's
a
lot
of
risks
that
you
take
away
from
it.
That
dan
is
going
to
talk
about.
C
C
What
we
can
do
is
we
can
add
to
that
we
can.
We
can
have
the
csd
system.
Obviously
it's
building
the
container
we
can
have
it
also
talk
to
the
spire
server
via
this
fire
servers,
api
and
say
this
container
with
this.
This
identity
should
get
this
spiffy
id.
So
the
cool
thing
about
this
is
that
no
containers
that
haven't
gone
through
the
cicd
system
or
aren't
otherwise
configured
have
any
access
to
the
identity
infrastructure.
C
They
can't
even
connect
to
any
other
services
or
if
a
malicious
user
somehow
changes
the
contents
of
a
container,
then
that
container
will
no
longer
be
able
to
get
an
identity.
So
this
is
something
we're
working
on
we're.
C
There
isn't
any
new
code
required
for
this,
because
the
the
pieces
are
all
there,
but
we're
working
on
some
configuration
and
examples
and
documentation
in
order
to
popularize
this
idea,
so
we're
essentially
signing
the
container
and
then
using
that
signature
to
be
able
to
establish
secure
identities
that
the
container
when
it's
running
can
use
to
connect
to
other
containers,
and
this
is
a
really
powerful
idea.
C
I'm
really
looking
forward
to
to
getting
this
out
there
a
little
bit
more
another
thing
that
some
of
our
users
are
really
interested
in.
This
is
really
simple,
but
it's
just
having
two
different
spire
environments
for
their
dev
and
prod
workloads
or
or
their
dev,
and
staging
improv
workloads,
so
that
a
a
user
on
the
dev
side
can't
accidentally
deploy
something
that
messes
with
prod
and
again
you're.
Probably
doing
this
using
some
kind
of
perimeter
mechanism
like
vpcs
or
having
different
aws
accounts.
C
C
And
oh,
this
is
this
is
essentially
the
same
idea
just
having
two
different
dev
and
prod
inspire
environments
and,
and
then
our
last
user
quote,
is
here
for
for
amir.
B
Yeah,
so
I
guess
bike,
dance
and
tick.
Tock
are
another
one
of
those
big
users
and
high
skill
users
of
specific
inspire,
and
they
have
multiple
talks
on
the
projects
that
you
can
find
as
well,
and
actually
eli
was
one
of
the
book
writers,
as
well
as
people
again,
their
they're
in
spiffy,
inspire
started
when
they
were
looking
for
this
consistent
dial
tone.
Authentication
director
authentication
is
a
word
that
google
has
used
in
the
past
with
a
system
called
google
alts.
Now
it
used
to
be
called
los.
B
I
hope
I'm
seeing
the
right
acronym,
but
the
the
concept
was
that
authentication
needs
to
be
consistent
everywhere,
just
like
dialtone
and
though
you
know,
if
you
remember,
if
you
pick
up
a
phone,
a
wired
phone
and
you
hear
the
dial
tone,
it's
no
matter
where
in
world
you
pick
up
the
phone,
you
hear
the
same
dialogue
right,
similar
concept
with
authentication,
so
it
reduces
the
complexities
of
managing
encryption
credentials
and
all
that
kind
of
stuff
from
development
teams.
B
But
at
the
same
time,
security
teams
sleep
a
lot
happier
because
you
know
it's
consistent
across
the
board
and
you
know
there's
like
there
are
fewer
risks
like
dan
mentioned,
and
you
know
no
one's
going
to
accidentally
use
test
credentials
in
production
and
everything
crashes
as
well.
Right,
that's
a
non-security
rate
benefit.
I
I
think
with
that
we
covered.
We
covered
a
lot
of
content
for
you.
If
you
have
any
more
questions,
feel
free
to
put
them
in
the
chat
right
now,
and
we
really
hope
that
these
five
use
cases
get.
B
You
started
on
spiffy
inspire
projects
dan.
If
you
can
go
to
the
next
slide,
do
join
us
on
slackthor
spiffy.io.
We
have
almost
close
to
a
thousand
engineers
now
on
spiffy
slack
you'll
find
me
and
dan
there
I
help
manage
community
dan
is
naturally
one
of
the
contributors.
B
B
That
book
is
available
freely
for
everyone
to
use,
to
quote,
to
use
in
presentations
in
your.
If
you're
trying
to
convince
your
broader
team
to
adopt
specific,
inspire
as
well
the
github
link.
Is
there
too?
Please
follow
us
there
too,
and
you
know
I'm
gonna
do
a
shameless
plug
as
well
start
start
the
projects
too,
if
you
like
them
and
use
them,
but
you
know
hopefully
looking
forward
to
seeing
you
a
lot
of
you
on
the
spiffy
slack
channel
over
the
coming
months.
B
Any
questions
while
I,
while
we
wait
and
give
chance
to
everyone
to
give
ask
any
questions
dan.
Any
closing
remarks
you
want
to
add
or.
C
No,
but
in
case
you
have
a
question
and-
and
you
can't
formulate
it
quite
now-
feel
free
to
email
us
both
of
our
email
addresses
should
be
in
the
session
description
or
or
you
can
contact
us
on
the
spiffy
slack,
which
is
a
like
umer,
said
it's
a
pretty
active
slack,
a
lot
of
users
from
a
lot
of
different
companies
and
a
lot
of
really
good
ideas
for
how
to
use
spiffy
inspire.
C
And
if
you
ever
encounter
a
problem
or
just
need
a
link
to
resources.
You
can
ask
on
slack
and
get
an
answer
pretty
quickly,
almost
any
time
of
day
or
night
in
the
us
or
europe,
and
I
guess
if
we
don't
have
any
questions,
we'll
I'll
stop
sharing,
and
maybe
we
can
wait
for
another
another
minute
to
see
if
there
are
any
follow-ups.
B
I
I
think
it
was
pretty
good,
I
think,
45
minutes
of
content.
Thank
you,
everyone
for
staying
that
long,
but
I
really
hope
jacob
your
questions,
leonardo.
Your
questions
were
answered.
B
Anything
else
we
can
help
you
with
was
this
session
useful.
Did
it
expand
your
knowledge
of
specifically
inspired?
Did
we
confuse
you
more
or
what
else
should
we
cover
in
future
webinars.
A
Great
job
y'all
thanks
so
much
for
a
great
presentation,
we'll
wait
around
for
a
little
bit
see
if
anybody
else
has
a
question
for
another
minute
or
so,
but
thank
you
everyone
for
joining
us.
The
slides
will
be
up
later
today
on
the
cncf
website,
along
with
the
recording,
and
if
there
are
no
more
questions,
we
will
look
forward
to
seeing
you
in
a
future
webinar
and
I'll.
Let
everybody
go.