►
From YouTube: Five Things You Didn’t Know You Could Do with SPIFFE and SPIRE - Andrew Jessup & Andrés Vega
Description
Join us for Kubernetes Forums Seoul, Sydney, Bengaluru and Delhi - learn more at kubecon.io
Don't miss KubeCon + CloudNativeCon 2020 events in Amsterdam March 30 - April 2, Shanghai July 28-30 and Boston November 17-20! Learn more at kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects
Five Things You Didn’t Know You Could Do with SPIFFE and SPIRE - Andrew Jessup & Andrés Vega, Scytale
Zero Trust networking and secure authentication are hot topics in security team meetings all over the world. But how do you actually get started? The open-source SPIFFE and SPIRE projects are your foundation for building ridiculously secure software, even between multiple clouds and clusters. In this talk, we will guide you through five practical applications with the open-source SPIFFE and SPIRE projects, including automatic authentication and mutual TLS encryption between: workloads on two different clouds, a workload in a virtual machine and an Istio cluster, a container in a Google Container Engine cluster and Amazon Web Services a workload in a Kubernetes cluster and a MySQL database a workload in a Kubernetes cluster and a Hashicorp Vault cluster a workload in a Kubernetes cluster and an API gateway And we’ll do all of this without any annoying passwords, API keys, or secrets. This talk focuses on real, practical examples of the SPIFFE and SPIRE projects. It assumes no prior knowledge of them, though some passing familiarity with Kubernetes will be helpful.
https://sched.co/VGpG
A
Alright,
let's
kick
things
off
hi
everybody!
Thank
you
for,
first
of
all,
welcome
to
coop
con.
Thank
you
so
much
for
coming
out
with
us
today
coming
out
finding
us
and
finding
this
room
I
know
as
a
bit
of
a
trek.
We've
got
a
lot
to
talk
about
today.
We
when
Andres
and
I
were
putting
together
this
talk.
A
We
had
this
hugely
ambitious
scope
for
all
the
cool
things
that
have
been
going
on
in
the
spiffy
inspired
projects
that
we
wanted
to
show
you
and
wanted
to
talk
about,
and
then
we
remembered
that
we've
only
got
30
minutes
to
get
through
it.
So
we're
going
to
show
you
a
what
we're
going
to
try
and
condense
much
of
that
ambition
into
these
30
minutes
as
possible.
A
My
goal
personally
out
of
this
talk
is
to
have
as
many
of
you
as
possible,
to
be
asking
questions
afterwards.
I
want
this
to
whet
appetites
and
to
get
people
curious.
It's
certainly
not
going
to
answer
we're
not
gonna,
be
able
to
answer
all
of
the
questions
in
the
next
30
minutes.
The
good
news
is,
though,
we're
a
group
con.
So
most
of
most
of
the
folks
who
work
on
spiffy
inspire
are
here.
A
lot
of
us
will
be
at
the
site.
Sale
booth
a
little
bit
later
as
well.
A
So
for
any
questions
we
don't
actually
get
to
in
the
talk
we'll
have
a
little
bit
of
time
afterwards
to
go,
go
deeper
on
some
of
these
topics.
So
by
the
way,
just
quick
introduction,
my
name
is
Andrew
I've
been
involved
with
spiffy,
more
or
less
since
its
inception,
and
my
colleague
Andres
and
I
both
work
at
site,
el,
very
important,
Andres
and
I.
We
look
similar.
We
have
similar
names.
We
are
in
fact
distinct,
unique
people.
A
We
have
our
own
personalities
and
a
capable
of
independent
thought-
that's
not
relevant
to
this
presentation,
but
I
thought
it
was
important.
You
all
know
that,
so
we
both
work
at
site
l.
We
both
work
on
spiffy,
inspire
spiffy,
inspire
for
those
who
don't
know
cloud
native
computing
foundation
projects
and
have
been
for
a
couple
of
years
now,
but
at
Scytale
it's
very
important
to
our
vision
as
a
company
that
spiffy
inspire
be
successful.
So
we've
invested
a
lot
in
it.
A
A
What
we
want
to
do
in
this
talk,
you
know
more
than
talk
about
specific
features
or
specific
capabilities
of
the
project.
What
we
really
want
to
show
you
in
the
next
30
minutes
is
kind
of
a
magic
trick
and
the
magic
trick
is
going
to
be
we're
going
to
show
you
a
you
know:
a
real
application,
and
by
real
we
mean
not
just
that
it
exists,
but
that
it
has
a
lot
of
the
properties
that
the
real
messy
applications
tend
to
have.
It
has
multiple
databases
it
needs
to
talk
to.
A
It
has
cloud
platforms
it
needs
to
talk
to.
It
has
multiple
independent
systems,
micro
services,
that
it
needs
to
talk
to
some
of
its
running
on
cuban
areas
and
some
of
its
not,
and
we
want
to
be
able
to
show
how
all
the
different
moving
parts
of
this
system
can
trust
each
other
and
that,
crucially,
though,
the
part
of
the
magic
part
of
the
magic
trick
is
they're
going
to
trust
each
other
without
usernames
and
passwords,
or
the
network
or
shared
secrets
of
any
kind.
A
So
to
take
a
step
back
and
show
why
that's
important
and
why
that
might
be
significant.
It's
worth
talking
a
little
bit
about
what
spiffy
inspire
actually
do,
and
why
why
it's
important?
Why
these
projects-
or
we
feel
these
projects,
are
important
now
so
spiffy
stands
for
the
secure
production,
identity
framework
for
everyone
and
what
that
means
in
maybe
more
boys,
simpler
language
is
spiffy,
helps
desist
components
of
a
distributed
system,
learn
to
trust
each
other,
and
we've
been
building
distributed
systems
for
a
long
time.
A
So
why
is
trust
suddenly
a
new
problem
for
a
while
the
systems
we
built?
You
know
10-15
years
ago
we're
distributed,
but
usually
pretty
simple.
You
know,
you'd
have
a
web
application,
maybe
a
piece
of
middleware,
maybe
a
database
of
some
kind,
but
for
the
most
part
these
things
ran
on
ran
in
a
single
environments.
Maybe
a
single
data
center
or
a
couple
of
data
centers
that
typically
the
company
that
built
the
software
also
owns,
runs
and
managers.
A
If
we
fast
forward
to
today,
though,
the
typical
application
and
by
application
I
mean
you
know,
the
set
of
things
that
need
to
come
together
for
a
customer
experience,
looks
much
much
more
complicated
than
that
and
there's
a
few
reasons
why
our
lives
have
become
more
complicated.
One
of
them
is
with
just
the
sheer
number
of
services
that
were
running
these
days.
A
The
micro
services
buzzword
has
taken
hold,
so
there
are
more
and
more
and
more
discrete
software
systems
that
need
to
communicate
each
other
to
each
other
over
a
network,
whereas
previously
they
might
have
been
talking
to
each
other
using
a
shared
data
structure.
The
other
reason
things
have
gotten
more
complicated
is
this
cloud
thing
which
is
apparently
very
popular
and
as
more
and
more
software
systems
and
workloads
start
moving
over
to
cloud,
then
you
know,
then
that
creates
two
interesting
challenges.
One
of
them
is
now.
A
These
things
are
running
in
data
centers
and
on
networks
and
and
hardware
and
switches
that
I
don't
own
and
run
anymore,
but
what
it
also
means
is
that
these
workloads
have
started
to
become
a
lot
more
ephemeral
and
elastic
than
they
used
to
be
in
the
old
world.
I
would
buy
in
rack
machines.
Now,
of
course,
these
things
are
dynamically
provisioned
and
then,
on
top
of
that
I'm
running
all
of
this
middleware
now
I'm
running
things
like
cube,
Annette
is
or
Hadoop
or
mesosphere
or
Cloud
Foundry.
A
It's
even
it's
harder
if
we
want
to
start
segmenting
that
perimeter
into
into
groups
of
applications
or
groups
of
services
that
we
want
to
make
sure
are
logically
isolated
from
each
other.
So
the
the
networking
model
has
started
to
fall
down
a
little
bit
in
the
in
terms
of
actually
establishing
trust
between
these
different
components,
and
some
folks
have
gone
to
the
point
now,
where
they're
admitting
that
we
really
don't
want
to.
We
really
don't
want
to
trust
this
network
at
all.
A
Even
if
we're
running
VPNs
and
V
pcs
between
these
different
locations
can
I
trust
that
a
every
single
software
system,
that's
inside,
that
perimeter
is
actually
behaving
as
it
should
be
that
it
hasn't
been
backdoor
that
if
an
attacker
was
able
to
compromise
it,
they
couldn't
start
laterally
moving
into
other
parts
of
the
organization.
So
this
is
led
to
a
new
someone
use
somewhat
of
a
new
paradigm
in
security,
which
a
lot
of
folks
are
calling
zero
trust
networking,
which
is
how
do
we
again?
A
How
do
I
assert
trust
between
components
in
a
software
system
if
I,
don't
trust
the
network
that
they're
talking
on
the
good
news
is
again.
This
is
also
not
a
new
problem.
In
fact,
every
time
you
use
a
web
browser,
you
are,
you
are
asserting
trust
between
a
browser
and
a
server
running
somewhere
over
this
vast
untrusted
network
that
we
call
the
Internet,
and
that
is
done
through
a
technology
called
TLS
transport
layer,
security.
Again,
it's
been
around
for
a
long
time,
the
and
the
way
transport
layer
security
works.
A
A
B
has
what
we
call
a
certificate
chain
that
it
can
use
to
verify
the
certificate
of
a
and
therefore
the
the
private
key
of
a
and
the
nice
thing
about
this,
and
then
from
that
Trust
they
can
establish
an
encrypted
channel
and
there's
two
really
nice
properties
that
this
gives
us
right.
It
gives
us
first
of
all
the
ability
to
assert
Trust
over
an
untrusted
medium
because
we're
relying
on
this
asymmetric
cryptography.
That's
been
pre
pre.
Aesthetic
of
this
trust-
that's
been
pre
established
through
these
shared
keys
and
secrets.
A
Sorry,
through
the
shared
keys
and
certificates,
the
other
nice
property
of
it
is,
is
that
once
we've
established
the
trust
we've
established,
the
workload
B
has
been
able
to
establish
the
provenance
of
a
were
then
also
able
to
establish
a
secure
channel,
which
means
that
we
can
guarantee
that
other
claud's
haven't
been
able
to
to
to
view
the
data.
That's
been
passed
between
these
view.
The
messages
we've
also
been
able
to
assert
that
those
messages
haven't
been
modified
in
transit.
A
So
we
start
to
establish
a
world
where,
even
when
we
don't
trust
the
network,
individual
systems
can
talk
to
each
other,
so
TLS
has
been
around
for
a
long
time,
but
we
don't
use
it
a
lot
inside
data
centers,
typically,
and
the
reason
for
that
is
not
because
of
the
TLS
problem.
Again,
that's
been
largely
solved
and
solved
in
lots
of
libraries
solved
in
proxies
saw
embedded
into
many
products.
The
challenge
has
been
actually
getting
the
key
material
and
the
certificates
to
the
to
these
workloads
in
the
first
place,
and
this
is
a
particular
challenge.
A
When
again,
we
start
thinking
about
these
very
elastic,
very
dynamic
environments.
It's
one
thing
to
give
a
certificate
to
a
physical
piece
of
hardware.
It's
quite
another
thing
to
give
a
certificate
to
a
pod
that
may
not
have
existed
half
a
second
ago
and
may
not
exist
in
two
seconds
time,
and
so
this
was
really
the
the
challenge
that
spiffing
inspire
have
tried
to
step
in
to
solve.
A
For
and
the
first
thing
we
did,
you
know
in
the
lead-up
to
our
launch
in
2017
was
work
with
several
partners,
including
Google
and
tai
Guerra,
and
a
few
other
folks
in
the
community
to
establish
a
set
of
standards
that
can
help
software
systems
easily
retrieve
valid
credentials
that
they
can
use
to
prove
this
identity,
and
we
have
some
other
talks
where
we
dive
into
these
standards
in
a
bit
more
detail.
But
just
in
brief,
there
are
certificates
which
we
call
x509
despard's
we've
standardized
on
the
which
is
a
subset
of
the
x.509
standard.
A
A
The
workload
api
is
how
a
workload
or
or
something
like
a
proxy
on
behalf
of
that
workload
is
able
to
retrieve
automatically
and
in
a
standard
way,
the
key
material
that
it
needs
to
be
able
to
assert
trusts
to
other
systems,
whether
that's
retrieving
a
key
retrieving,
a
certificate,
retrieving
a
certificate,
bundle
or
creating
or
validating
a
token.
And
again
this
is
a
standard.
This
is
a,
or
rather
it's
a
specification
and
the
the
specification
we
always
for
Seoul
being
implemented
by
many
different
products.
Maybe
eventually
you
know,
platforms
and
cloud
providers
would
offer.
A
A
So
that's
that
that
was
that
took
us
up
until
2017
to
start
to
get
that
specification
and
some
early
versions
of
spire.
Together
we
launched
that
at
coop
con
in
2017
in
2018.
We
spent
a
lot
of
time
building
on
that
foundation
to
build
up
a
set
of
integrations
into
other
target
platforms
and
environments.
Spiffy
in
spire
I
should
say,
is
extremely
extensible
and
so
there's
lots
of
different
ways.
A
It
can
be
extended
into
cloud
platforms
into
two
different
orchestrators,
as
well
as
into
other
upstream
products
like
proxies,
for
example,
one
proxy
in
particular
that
we
spent
a
lot
of
time
on
is
is
with
envoy
and
the
growing
popularity
of
the
Envoy
project
to
make
sure
that's
natively
supported
within
the
spire
by
spire.
But
again
we
now
support
all
three
cloud
providers.
We
have
great
rich
support
for
Kuban.
It
is
and
we're
building
our
support
for
more
and
more
capabilities.
We're
also
starting
to
see
the
community
coalesce
around
these
two.
A
So
we've
had
plugins
for
specific
TPMS.
We've
had
plug-ins
for
OpenStack.
We've
had
plugins
to
use
different
backing
CAS,
for
example,
so
there's
a
there's,
a
rich
sort
of
extensibility
ecosystem.
That's
building
out
as
well
Amazon
have
come
to
the
table
and
contributed
some
plugins,
for
example,
so
we're
seeing
a
lot
of
activity
coalescing
around
spire
as
a
framework
to
to
deliver
on
the
deliver,
deliver
spiffy
into
more
and
more
environments.
A
In
the
meantime,
though,
as
well
as
I
mentioned,
you
know,
spiffy
is
is
fundamentally
a
you
know,
not
just
a
software
product.
It's
a
it's
a
it's!
A
specification-
and
so
we've
seen
other
vendors
start
to
implement
spiffy
and
spire.
In
fact,
some
of
these
vendors
have
actually
built
products
that
build
on
spire
itself,
which
has
been
really
and
really
neat
to
see.
So
you
know
you
can
see
the
logos
here,
but
what
we're
starting
to
see
now
is
more
and
more
different.
A
They
might
support
spiffy
IDs.
What
would
happen
is
different.
Parts
of
an
organization
would
pick
up
different
parts
of
these
projects
or
so
will
pick
up
different
implementations
for
different
use
cases.
But
then,
at
some
point
these
workloads
running
on
these
different
islands
still
want
to
be
able
to
trust
each
other.
And
so
how
can
you
do
that?
And
so
the
answer
to
that,
of
course,
much
is
with
with
many
other
protocols,
was
to
was
to
think
about
Federation
and
federating
these
these
capabilities
together.
A
So
a
huge
focus
for
us
in
in
2018
and
2019
was
again
to
go
back
and
work
with
many
of
these
partners
on
a
specification
for
federating
different
different
spiffy
identity
providers
together,
and
so
we
we
cannot.
We
made
that
canonical
in
the
spiffy
Federation
API
and
you
know
we'd
say
it's
still
very
early
days
for
this,
but
we're
really
excited
by
a
lot
of
the
energy
that
we're
seeing
around
this
API
and
what
it
means.
A
For
you
know
a
broader
workload,
identity,
ecosystem
well,
there'll,
be
a
talk
a
little
bit
later,
where
some,
some
folks
from
Scytale
and
folks
from
Google
will
be
talking
about
how
this
is
getting
implemented
in
ISTE.
Oh
and
there's
other
projects
as
well
as
starting
to
pick
this
up,
either
directly
or
indirectly,
because
they're
being
built
on
top
of
spire.
So
we're
really
excited
to
see
this
kind
of
coalesce,
and
so
you
drive
some
more
interesting
use
cases.
A
But
now
we
kind
of
move
into
2019
and
brings
us
bring
yourselves
bringing
us
up
to
today
and
we've
seen
we've
seen.
People
want
to
push
on
spire
more
and
more
and
one
of
the
most
common
questions
that
we've
one
pieces
of
feedback
we've
heard
is:
listen.
We
love
that
you
can
we
love
that
you
can
support
x.509.
We
love
that
you
can
support
Judt's.
We
love
that
spire
can
work
in
all
of
these
different
environments
and
spiffy
can
work
in
all
of
these
different
environments,
but
we'd
like
to
go
further.
A
You
know
up
until
now:
we've
talked
about
workloads
that
are
either
workloads
that
you've
built
yourself
and
therefore
you
can
design
them
to
to
talk
to
things
like
the
workload
api
or
you
can
wrap
them
in
a
proxy
and
the
proxy
can
talk
to
the
workload
api
or
not
on
a
workloads
behalf
and
that's
fine,
but
often
you
want
to
go
a
little
bit
further.
A
very
common
use
case
is
talking
to
something
like
a
database.
A
For
example,
you
know
how
can
I
do
that,
but
stay
true
to
all
of
the
principles
of
spiffy
inspire,
which
is
that
I
should
be
able
to
make
this
communication
work
even
if
I,
don't
necessarily
trust
the
network.
Another
common
use
case
that
comes
up
is
things
like
cloud
providers.
How
do
I
talk
to
not
just
a
workload
running
in
Amazon,
but
how
do
I
talk
to
Amazon
itself?
A
The
remainder
of
this
time
for
and
I'm
gonna
hand
over
to
my
my
colleague
Andres,
to
to
show
the
magic
trick
here
is
to
show
you
a
real
world
example
of
how
spire
can
come
together
and
how
spiffy
can
come
together
to
solve
for
a
few
of
these
different
use
cases,
and
we
think
this
is
a
really
exciting
additional
direction
for
the
project.
This
is
very
new.
We've
started
to
explore
this.
A
In
the
last
few
months,
we've
started
to
put
out
some
white
papers
and
some
demos
the
showcase,
how
it
works
and
we're
starting
to
invest
back
into
the
project
to
help
support
some
of
these
use
cases.
So
it's
a
really
exciting
thing
for
us
and
we
I'll
hand
over
to
Andres
at
this
point,
to
show
you
a
little
bit
more
concretely
how
it
actually
works.
So
with
that
my
Colombian
alter-ego
Andres.
B
What's
up
everybody,
let's
do
some
spiffy
so
for
a
bit
to
unpack,
but
from
what
Andrew
said
might
take
away?
Is
this
multi
cloud
thing
everyone's
been
talking
about?
Doing
is
not
just
made
possible
by
spiffy,
but
it's
made
possible
in
a
secure
way
to
illustrate
for
that.
We
have
put
together
a
sample
banking
application.
This
application
is
composed
by
five
different
services
which
are
going
to
be
seeing
on
screen.
All
of
these
services
run
and
kubernetes.
B
We
are
relying
on
Android
proxy,
we're
not
using
Android
proxy
as
a
service
mesh,
we're
using
Android
proxy
as
a
proxy
for
the
STS
API
and
establishing
mutual
TLS
between
the
different
services.
The
customer
details
service,
you
see
at
the
bottom
of
the
screen,
it's
talking
to
the
details
database
using
direct
certificate
authentication,
so
the
grant
table
of
this
database.
The
user
has
been
altered
to
not
require
password
but
require
an
x.509
certificate
with
a
particular
dns
name
and
for
the
transactions
talking
over
to
RDS
we're
relying
on
Oh
IDC
Federation.
B
We
are
identifying
a
workload
assigning
it
its
identity
document
that
is
a
esvet
jot
and
we're
using
that
sv
jawed
to
talk
over
to
AWS,
Napa
and
I
am
roll,
and
you
said,
I
am
roll
to
retrieve
an
SDS
token
to
talk
over
to
RDS
break,
breaking
it
up
a
little
bit
in
chugs
and
and
grab.
Let
me
switch
back
and
forth
and
to
the
browser
here
that
is.
This
is
my
customer
portal
for
the
banking
application.
B
You
can
see
my
personal
information,
which
is
coming
from
the
kubernetes
database,
the
database
that's
running
in
kubernetes
and
all
the
transaction
details
you
see.
This
is
actually
within
RDS.
I
switched
apps
here
this
is
RDS,
you
see
it
set
up,
and
here
let
me
show
case
the
different
services
that
are
running
in
kubernetes.
B
Each
of
these
has
their
corresponding
sidecar
proxy
again,
with
the
exception
of
the
database,
to
which
were
speaking
spiffy
directly
now
for
the
certificate
that
we
have
attested
the
database
and
issue
it
its
own
and
the
same,
the
the
service
talking
to
it.
The
server
is
accessing
it
when
we
give
it
its
its
certificate.
Here
you
see
the
parent
ID
of
the
note
that
that
is
running
on,
and
you
see
the
spiffy
ID
for
the
workload
itself.
You
see
a
configurable
dns
name.
This
could
also
be
a
configurable
CN.
B
If
that
is
the
authentication
strategy
of
chosen
but
important
to
note,
there
is
no
API
key.
There's
no
secret.
There's
no
username
and
password
at
play
in
here
asks
for
RDS
to
unpack
that
a
little
bit
there's
a
sequence
of
steps
that
happen
for
that
esvet
to
be
used
to
retrieve
the
STS
token.
So
the
first
operation
is
part
of
this
is
for
a
spy
to
serve
an
endpoint
on
which
the
OID
C
discovery
process
is
going
to
happen.
That
discovery
document
is
exposed
on
port
443.
B
B
The
note
that
the
service
is
running
on
will
mint
a
jot
s
fit.
We
talked
about
x.509,
we
talked
about
dots.
We
want
to
use
dot
for
the
purposes
of
Ord,
see
oh
I
DC,
but
oh
another
use
case
for
making
Josh
over
x.509,
as
if
you
wanna
integrity
into
fidelity,
where
you
have
layer,
7
termination
and
between,
and
that's
something
we
can
spend
more
time
covering
if
it's
a
use
case
of
interest
for
you
guys.
B
B
B
B
Changing
the
DNS
and
if
I
were
to
refresh
my
app
I,
should
not
be
able
to
retrieve
my
information,
but
I
still
see
it
as
if
it's
been
cached.
Let
me
open
a
new
tab
here.
As
you
see,
the
the
personal
information
is
no
longer
accessible.
I
can
quickly
modify
the
DNS
name
again
to
meet
the
requirement
that
my
sequel
has
and
it
should
be
restored
here
and
the
case
of
wanting
to
test
RDS
I
could
simply
revoke
access
by
changing
the
spiffy
ID
or,
if
that
that
would
ever
be
to
be
exfiltrated
aspire.
B
A
way
to
think
about.
It
is
doing
high
velocity
fully
automated
PKI.
If
you
have
a
rotation
that
it's
an
hour
long,
you
pretty
much
shorten
the
risk
of
exfiltration
for
how
long
that
credential
would
be
usable.
So,
as
AJ
stated,
we
set
out
a
very
ambitious
goal
to
demonstrate
a
lot
of
capabilities,
a
lot
of
what
has
been
shown
or
well
what
the
little
that
I've
shown
actually
hides
a
lot
of
the
complexity.
That's
underneath.
B
With
that
where
to
go
from
here,
you
can
find
us
at
the
sponsor
floor
of
the
spiffy
inspire
our
fast
growing
thriving
projects.
A
great
start
at
starting
spot
is
the
spiffy
a
yo
website.
Please
join
lack
for
at
spiffy,
slack
calm.
The
github
repo
is
here,
here's
some
of
the
other
talks
we
have
going
for
the
rest
of
the
week
you're
more
than
welcome
to
come,
and
please
find
us
on
the
hallway.
Please
find
us
on
the
floor.
A
B
A
Yeah,
that's
a
great
question.
The
the
official
answer
is
no
not
today,
but
we've.
We've
talked
to
folks
at
both
Google
and
Microsoft.
To
working
on
this
Microsoft
actually
does
have
some
Oh
IDC
Federation
capability
natively.
It
doesn't
support
all
of
the
JW
KS
endpoints
that
we
need,
but
we're
told
that's
going
to
change
and
Google
is,
is
considering
adding
support
for
that
as
well.
So
it's
a
we
should.
We
should
hopefully
see
some
movement
on
that
in
the
next
six
months
or
so.
D
With
the
OID
C
support
on
the
cloud
providers,
is
there
any
have
you
seen
anything
where
there's
additional
ways
to
lock
down
access
to
your
your
ID
Oh,
a
DC
key
provider,
because
there's
a
lot
of
times
where
it's
like,
oh
you're,
trying
to
run
that
private,
etc,
etc?
But
the
cloud
providers
are
gonna
call
in
to
it
from
anywhere.
Have
you
seen
anything
on
implementations.
A
The
other
thing
that
spire
supports
is
in
terms
of
the
thing:
that's
actually
signing
these
credentials
and
validating
them.
You
can
use
spires
built
in
CA
if
you
will,
but
this
you
can
back
out
to
something
else
as
well.
So
if
you're
running
on
Amazon
trying
to
do
IDC,
something
else
you
can
use,
Amazon
certificate
manager
or
Amazon's
secret
store
will
actually
do
the
signing
operation
or
you
can
use
something
like
vaults
if
you'd
prefer
to
use
that.
B
A
So,
there's
a
couple
of
ways
to
enforce
that
with
the
it's
worth,
noting
that
in
this
case
you
weren't
just
trusting
the
the
certificate
authority,
but
it
was
the
database.
Post-Crisis
in
this
case
was
actually
identifying
the
workload
and
matching
it
to
an
internal
username
and
password.
So
there's
a
specific
binding
between
specific
workloads
and
the
entitlements
on
the
day.
So
you
might
be
able
to
establish
a
connection
from
any
workload
inside
the
CA,
but
that
doesn't
necessarily
mean,
but
the
entitlements
that
a
workload
has
to
the
database.
A
A
So,
first
of
all,
thanks
again
everyone
for
coming
down
thanks
for
coming
all
the
way
to
find
us
for,
for
those
who
are
thinking
about
spiffy
or
have
questions
a
whole
lot
of
us
will
be
at
the
site,
ale
booth
in
the
sponsor
showcase
and
we're
running
a
bunch
of
lightning
talks
as
well
as
underestimation.
So
we'd
love
to
see
you
there.
If
your
good
time
and
thanks
again
yeah.