►
From YouTube: SPIFFE Deep Dive - Andrew Jessup, Emiliano Berenbaum, Scytale, Inc., & Neel Shah, VMware
Description
Want to view more sessions and keep the conversations going? Join us for KubeCon + CloudNativeCon North America in Seattle, December 11 - 13, 2018 (http://bit.ly/KCCNCNA18) or in Shanghai, November 14-15 (http://bit.ly/kccncchina18).
SPIFFE Deep Dive - Andrew Jessup, Emiliano Berenbaum, Scytale, Inc., & Neel Shah, VMware (Intermediate Skill Level)
SPIFFE (Secure Production Infrastructure for Everyone) and SPIRE are two of the newest projects to join the CNCF. These projects build on designs first championed at Google, Twitter and elsewhere to provide robust authentication and trust between disparate micro-services in heterogeneous operating environments. This talk will expand on concepts introduced during the SPIFFE Intro Session to explore in detail how SPIRE performs attestation to workloads in diverse infrastructure and middleware settings, how it leans on different secrets storage backends and how PKI material is automatically delivered to a node and workload. The talk also will cover how these capabilities can be extended and customized through SPIRE’s plugin framework. In this session, we will demo a Kerberos Node-Attestor for SPIRE in a Kubernetes cluster using the pluggable SPIRE model; Using Project Lightwave—an open source multi-tenanted and enterprise-grade Kerberized identity platform—we will demonstrate how enterprise identity stacks can be used to identify and trust the next generation of cloud-native workloads.
About Emiliano
He is the CTO at Scytale, Inc.
About Andrew
Andrew is the co-founder of Scytale, who are helping bring SPIFFE into the world. Find out more at https://github.com/spiffe/spiffe Andrew is an engineer, and entrepreneur with a passion for building tools that help bring simplicity to software development. Prior to co-founding Scytale, Andrew was a product manager on Google’s Cloud Platform, launching many of the automation primitives on Google Compute Engine (including Auto-scaling, Managed Instance Groups, and Deployment Manager), helping improve developer workflow with the Spinnaker and Container Builder projects, and helping improve accessibility to developers and operations teams. As an Australian in the San Francisco Bay Area, Andrew spends most of his spare time trying to sell his Midwestern wife on the virtues of Vegemite.
About Neel
Neel Shah is a software engineer in the Cloud Native Group at VMware. At VMware, he has implemented secure dynamic DNS update with Kerberos GSS-API and actively works on an enterprise grade Kubernetes as a service solution. Outside of VMware, he maintains an open source SDN/NFV platform, OpenNetVM, and has worked on improving cloud security and reliability using Xen. As an open source contributor, Neel is deeply passionate about integrating distributed and low-level systems with security.
Join us for KubeCon + CloudNativeCon in Barcelona May 20 - 23, Shanghai June 24 - 26, and San Diego November 18 - 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.
A
A
So
today,
I'm
going
to
walk
you
through
spiffy,
we'll
talk
about
the
spire
plugin.
How
that
works,
how
to
use
that
then
I'll
show
you
no
data
station
or
an
attestation.
How
a
spire
implements
that
at
that
point
on
the
handed
over
to
a
shop
that
yeah
we're
working
with,
basically
create
no
testers
for
Kerberos
and
then
we'll
just
questioners
how
about,
if
you're
asking
did
anyone
see
and
injustice
spiffy
at
yesterday?
A
A
A
Sp
is
a
x.509
certificate,
as
big
was
the
first
identity
document
that
the
community
came
up
with
what
it
really
does
is
it
describes
what
goes
into
x.509
certificate?
What
extensions
were
using
or
that-
and
we
didn't
want
to
create
our
own
inspections
or
any
aside,
that
want
exceptions,
because
we
wanted
to
make
s
vids
as
simple
as
possible,
so
work
with
most
pay
less
tax
and
right
now,
during
one
of
our.
A
In
six
pack,
which
is
our
Sikh
guru,
the
works
on
the
busy
specification,
we
are
working
on
job
estimates.
So
that's
the
next
identity
document,
okay,
together,
that
you
would
use
for
HP
base
for
vaults,
then
the
workload
API,
so
the
workload
API
and
the
attendant
documents.
You
know
we're
working
with
that
and
it's
expect
and
that's
being
led
by
every
ailment.
It's
like
them.
A
So
if
you're
interested
in
participating
or
seeing
what's
going
out
there,
we
have
weekly
sick
meetings
and
you
could
join
and
so
the
workload
API
we
recently
just
came
out
with
our
1.0
of
that
and
we
implemented
a
C++
library
for
them
created
a
demo
using
nginx
nginx
modules.
So
we
just
published
a
blog
post
on
that
and
I'll
show
you
the
link
of
that.
But
if
you
look
in
our
side,
tail
block
dot
sight,
L,
dot,
IO
you'll
find
that
our
blog
post.
Now,
let
me
just
show
you
what
that
API
looks
like.
A
A
So
we
have
the
S
feeds
that
are
delivered
to
a
calling
workload,
also
the
interest
federated
bundles,
which
basically
means
that
the
workload
API
will
deliver
a
bag
of
search.
Everything
that
you
need
to
talk
to
other
workloads,
and
we
are
also
have
a
space
there
for
a
revocation
list
that
we
have
in
our
roadmap
to
implement
later
on
this
year.
So
that
not
only
would
you
deliver
search,
but
you
would
also
deliver
replications
through
the
API.
A
All
righty
and
again
we're
working
right
now
on
the
jot
s
fit,
which
would
be
the
next
identity
document,
and
that
would
have
a
job
as
FID
and
aspect
of
what
goes
into
the
jot,
plus
the
API
associated
with
that
now
spire.
So
what
spire
is
is
our
implementation
of
the
spiffy
runtime
environment?
So
it's
just
it's
something
that
you
could
use
that
implements.
Spiffy
and
spire
is
made
up
of
two
parts:
spire
server
and
a
spire
agent.
A
The
spire
server
does
a
density
mapping
NOAA
data
station
as
issuance
and
the
spire
eight,
or
that
was
a
spire
server.
The
spire
agent
does
a
workload
attestation
and
the
workload
API,
and
the
thing
to
see
is
that
we
have
api's
and
plugins.
The
api's
will
call
on
the
plugins
and
each
plug-in
has
a
protobuf
definition
that
also
you
could
find
in
the
github
repo
when
we
first
put
out
spire
plugins
were
external
processes.
A
So
I'm
going
to
just
walk
over
I'm,
going
to
just
go
over
some
of
the
plugins
on
each
side.
So
the
first
one
is
the
Noda
tester.
So
the
Noda
tester
is
responsible
for
testing
the
identity,
proof
of
a
node
and
they
work
in
conjunction
with
the
Noda
tests,
are
on
the
spire
agents.
So
they
come
in
pairs
and
they're
really
dependent
on
the
environment
that
you're
running
in.
So
we
have
one.
A
We
have
an
AWS,
a
tester
and
we
also
have
a
token
a
tester,
and
what
Neil's
going
to
show
is
his
Kerberos,
a
tester
that
he
wrote
then
the
node
resolver
that
will
basically
discover
additional
metadata
about
the
attested
node.
So,
for
instance,
for
AWS
we
will
verify
sir
will
attest
the
signed
metadata
for
that
instance,
and
the
node
resolver
would
basically
look
and
determine
you
know
what
label
security
group
or
AG
that
that
process
is
running
under
the
CA
is
responsible
for
processing
CSR
request
by
the
spire
agent.
A
It's
also
responsible
for
generating
CSRs
for
intermediates
signing
certs
and
storing
the
related
keys,
and
the
the
upstream
CA
allows
us
to
integrate
with
an
existing
PKI
system.
So
you
could
either
run
this
as
have
the
spire
server
have
a
self-signed
cert
or
you
could
hook
it
up
and
have
it
be
downstream
from
your
your
own
PKI.
If
you
already
have
one
existing
and
then
the
data
store
is
responsible
for
providing
a
registry
to
store
all
the
workload,
identities
and
attestation
policies.
A
A
The
Noda
tester
is
the
pair
of
the
Noda
tester
on
the
on
the
spire
server
and
that's
responsible
for
performing
platform,
specific
proof
of
identity
of
that
node
and
then
the
last
piece
is
the
workload
of
tester.
So
the
workload
of
tester
is
responsible
for
testing
the
workload
when
called
it
performed.
You
could
have
multiple
selectors
workload
to
testers
associated
with
that
workload.
The
API
will
verify
and
check
the
attestation
policy
and
use
one
of
the
workload
of
testers
that
are
associated
with
that
policy.
Once
the
policy
is
satisfied,
the
API
will
deliver
the
s.
A
So
now
I'm
just
walk
through
this
show
what
that
looks
like.
So
this
is
basically
what
the
final
system
looks
like
after
everything
has
been
delivered,
so
we'll
see
how
we
get
there.
So
when
you
start
up,
there's
nothing
there
and
the
spire
server
has
to
create
and
generate
its
signing
keys
for
that
server.
A
It
calls
the
CA
the
upstream
CA
if
that's
been
configured
at
that
point,
we
deliver
the
intermediate
cert
that
has
been
signed
correctly.
That
cert
has
a
TTL
and
is
rotated.
Also
now
we're
gonna
start
registering
things,
so
we
call
the
registration
API.
This
is
what
you
use
to
register
the
attestation
policy.
Basically,
the
mapping
of
what
selectors
are
using
and
what
spiffy
ID
that
that
relates
to
and
then
it's
stored
in
the
data
store
where
it's
persisted
for
NOAA
data
station.
A
The
now
the
the
note
comes
up
online,
and
so
the
one
thing
to
note
here
is
that
we
have
preceded
that
node,
with
the
bundle
of
trust
from
the
spire
server.
The
Noda
tester
runs
basically
checks.
Whatever
metadata
is
on
that
node
it'll
generate
a
CSR
request.
The
node
API
is
called
the
Noda
test
on
the
server
side,
verifies
that
the
signing
data,
whatever
data
was
passed
over.
It's
correct.
A
The
node
resolver
is
called
after
that
to
see,
if
there's
any
other
data
that
it
could
figure
out,
and
then
it
looks
it
up
in
the
data
store,
and
then
we
sign
the
CSR
request.
At
that
point,
we
deliver
what
we
call
the
base
s
vid
to
the
calling
node.
So
one
thing
to
point
out
here
is
that
at
this
point
we
just
have
an
identity
for
the
node
and
the
workload
that
runs
on
that
node
will
have
a
different
identity.
A
A
Sorry
I'm
just
trying
to
make
figure
out
my
notes,
so
at
the
same
time,
what
we've
also
done
is
we've
delivered
all
the
attestation
policy,
that's
associated
with
that
with
that
node
to
the
to
the
cache
to
local
cache
on
that
node.
So
we're
telling
it
these
are
the
workloads
that
can
run
on
that
on
that
node.
A
Now,
when
the
when
the
node
goes
to
talk
to
the
Aspire
server,
again
he's
going
to
use
that
s
fade
and
that
you
that
s
fade
will
be
used
by
the
by
the
by
the
server
to
basically
figure
out
who's
talking
to
it,
so
we
use
that
to
to
map
nodes
to
to
the
corresponding
entries
in
the
inspire
server.
So
now
what
we're
gonna
do
is
we're
gonna
start
generating
generate
search
for
the
workloads
that
can
run
on
that.
A
On
that
note,
so,
like
I
said,
we've
delivered
everything
now
is
cached
locally
on
the
on
the
agent,
the
node
API
is
called
again,
and
the
csr
request
was
generated
from
the
key
manager
it's
signed,
and
then
we
deliver
it
back
to
the
to
the
node
and
he
cashes
it.
So
the
whole
idea
is
that
you've
preached
enervated
all
the
identities
that
are
allowed
to
run
on
that
machine.
On
that
on
that
node
they
also
have
a
TTL.
A
So
this
is
constantly
being
updated
and
running
and
when
a
workload
comes
up,
it
would
just
once
it
passes
attestation
all
its
identity
would
be
delivered.
So
now
we
go
into
the
workload
attestation.
So
now
the
workload
comes
up
and
he
talks
to
a
well-known
endpoint
for
the
workload
API.
At
that
point,
the
workload
API
will
attest
the
calling
workload
it
will
determine
if
all
the
criteria
in
the
in
the
attestation
policy
for
that
workload
is
satisfied
and
if
everything
is
satisfied,
it
will
deliver
the
cert
to
that.
A
B
So
Kerberos
is
a
predominant
identity,
stack
for
enterprise
and
most
cloud
native
workloads.
Don't
have
an
easy
way
to
integrate
with
the
enterprise
identity
stacks
and
because
of
that,
Kerberos
is
an
ideal.
Bootstrap
for
spire
to
you
know,
attest
different
nodes
in
a
cloud
native
environment.
Spire
has
does
not
have
a
mechanism
to
use
Kerberos.
As
of
yet
and
with
Kerberos
support.
Spira
can
manage.
Identity
is
tied
very
close
to
existing
enterprise
infrastructure.
B
The
way
Kerberos
works
is
it's
comprised
of
at
least
three
different
players.
The
first
is
a
trusted
third
party
known
as
a
key
distribution
center
or
the
KDC.
The
KDC
has
two
services
within
an
authentication
service
and
a
ticket
granting
service
and
I'll
get
into
how
they're
used
in
a
second.
The
next
player
is
a
server.
B
The
KDC,
the
authentication
service
will
give
Bob
what's
called
a
ticket
granting
ticket
a
TGT
and
with
this
ticket
Bob
can
now
talk
to
the
second
component
of
the
KDC,
the
ticket
service
in,
and
he
can
request
service
tickets
or
long
lived
service
tickets
to
request
access
to
any
particular
service.
Within
this
realm,
a
realm
is
an
environment
in
which
Kerberos
operates
once
Bob
receives
the
service
ticket.
He
will
then
present
it
to
the
web
server
that
is
hosting
the
service
that
Bob
wants
to
access.
B
Then
the
web
server
will
look
at
this
ticket
and
since
the
server
trusts
the
KDC,
it
will
recognize
that
this
service
ticket
was
signed
by
its
trusted
KDC
and
therefore
it
will
trust
the
service
ticket,
and
it
will
trust
that
Bob
is
a
user
who's
allowed
to
access
resources.
In
this
realm,
Trevor
Burrus
is
typically
run
within
a
domain.
A
domain
controller
such
as
Active
Directory,
can
really
help
automate
Kerberos
management.
B
Whenever
you
join
a
computer
to
a
domain,
a
machine
account
which
is
very
similar
to
a
user
account,
but
this
account
is
used
to
identify
the
actual
computer
or
the
machine
that
is
joined
to
this
domain,
and
once
the
machine
is
joined
to
a
domain,
you
can
use
a
machines
user
account
the
same
way
as
you
would
a
user
account
in
Active
Directory.
The
domain
is
the
same
thing
as
a
Kerberos
realm
solemn.
B
Take
a
tangent
for
a
second
and
talk
about
project
light
wave
project
light
wave
is
an
open
source,
multi-tenant
cloud
directory
service
offering
from
VMware-
and
it
is
comprised
of
you-
know,
directory
service
that
LDAP
compliant
Kerberos
KDC
and
ultimate
support
a
bunch
of
different
authentication
services
such
as
o
fo,
IDC
sam'l.
We
have
our
own
certificate
authority
and
we
also
have
our
own
DNS
server.
That
is
tied
very
closely
to
Kerberos
as
well
and
in
Lightwave
all
of
the
different
authentication
services
that
we
support
come
together
and
converge
in
our
directory
service
with
Kerberos.
B
Let's
get
straight
into
node.
Add
a
station
with
Kerberos.
Now
so
Emiliano
mentioned
whenever
a
node
agent
first
comes
up,
it
will
talk
to
the
spire
control,
plane
and
say
hi
I'm,
a
node.
Do
you
know
me,
and
if
this
node
hasn't
been
attested
before,
then
the
server
will
respond
back,
saying,
I,
don't
know
you
need
to
attach
yourself
and
I
will
say:
I
support.
All
these
attestation
methods
and
a
node
can
be
configured
to
use
a
particular
adaptation
method.
B
In
this
case
Kerberos
then,
once
it
receives
that
request
from
the
control
plane,
it
will
start
no
attestation.
If
you
remember,
the
first
step
is
login,
which
is
what
the
node
agent
will
do.
It
will
talk
to
the
Lightwave
KDC
and
it
will
then
get
the
long
long-lived
session
ticket
from
that
login
TGT
that
was
returned
to
it.
B
Then
it
would
use
that
TGT
to
get
this
long
live
service
ticket
and
once
it
has
the
service
ticket,
it
can
then
present
that
service
ticket
back
to
the
spire
control
plane
the
node
agent
server
there,
and
then
the
node
agent
server
will
validate
the
service
ticket.
That's
presented
to
it
once
this
ticket
has
been
validated,
it
can
do
additional
node,
lookups
and
process
selector
lookups,
and
with
that
information,
once
it
has
everything
it
needs,
it
will
then
respond
to
the
node
agent
with
this
50
ID.
For
it.
B
This
is
a
bird's-eye
view
of
the
demo.
Now,
on
the
left
hand,
side
we
have
the
spire
server
and
the
spire
server
is
also
a
domain
controller,
and
this
domain
controller
is
running
the
Kerberos
node,
a
tester
server
as
well
and
on
the
right
hand,
side.
We
have
the
spire
agent.
The
spire
agent
is
another
VM
that
is
domain
joined
to
the
Lightwave
domain.
That's
on
that's
run
from
the
spire
server
and
that's
where
the
spire
agent
will
be
running
and
the
Noda
test.
B
Your
agent
will
be
running
there
once
the
spire
agent
has
been
a
tested.
We
will
then
create
or
register
a
new
workload
that
can
be
run
on
this
host,
and
this
will
just
be
a
UNIX
workload
and
then,
once
the
workload
is
registered,
we
can
then
simulate
the
workload
API
to
show
that
it
is
getting
the
correct
identity
after
it
has
been
attested.
B
B
If
you
go
back
to
the
agent-
and
we
can
start
the
spire
agent
here
and
as
soon
as
the
spire
agent
runs,
it
will
start
node
at
a
station
with
Kerberos,
because
our
plug-in
configuration
has
been
set
to
use
the
Kerberos
a
tester.
So
if
I
hit
run
here,
we
can
see
that
no
pre-existing
s
whit
was
found
will
perform
node
at
a
station.
So
if
we
go
back
to
the
spire
server,
we
can
see
that
we
got
a
CSR
for
the
client
host
the
agent
host
and
we
attested
it
through
the
Kerberos
a
tester.
B
We
can
see
that
the
Kerberos
handshake
was
actually
performed.
We
can
see
how
the
first
step
here,
which
is
login
the
agent
hostname
P
dev,
go
to
was
logged
in
and
then
that
same
host
tried
to
request
a
long-lived
service
ticket
for
the
server
which
is
P
dev
go
once
this
node
has
a
tested
itself.
We
can
register
a
workload
for
that
host
from
the
server.
B
We're
saying
here
that
on
this
particular
host
the
agent
that
we
just
attested
through
Kerberos,
we
want
to
register
this
workload
for
a
named
Neil.
So
that's
the
username
of
the
workload
or
the
name
of
the
workload
and
the
selector
is
a
UNIX
UID
and
that's
the
you
idea
of
the
user
Neil
on
that
other
host.
So
if
I
create
this,
a
workload
has
been
associated
to
this
node
and
if
we
see
here
in
the
server,
we
signed
an
S
vid
for
that
workload
on
that
node.
B
If
you
go
back
to
that
node
now
we
see
that
we
actually
received
the
s
vid
for
that
workload,
that
we
just
registered
to
verify
that
my
UID
is
indeed
one
thousand
and
two.
We
can
see
that
here
and
then
the
next
thing
we
can
do
is
we
can
simulate
the
workload
API
by
calling
the
spire
agent
API
to
fetch
the
workloads
information,
the
identity,
information
for
that
workload,
and
we
can
do
that.
B
As
my
a
user
Neill
that
we
associated
the
ID
to,
we
can
see
that
once
we
ran
that
command,
we
received
a
cert
bundle
that
contains
the
spiffy
ID
for
the
particular
workload,
which
is
my
user,
and
we
can
also
see
from
the
agents
output
that
we
attested
this
one
process
and
the
selectors
found
associated
to
that
process
were
a
UNIX,
UID
and
the
UID
matches
and
to
verify.
We
can
take
a
look
at
the
certificate
that
was
given
to
us
from
running
that
command.
B
B
And
if
you
want
to
check
a
little
take
a
look
at
the
Kerberos
to
test
your
code,
it's
on
github!
Let
me
put
this
back
on
presenter
view
and
yeah.
You
can
go
poke
around
that
up
there
and
there's
a
link
to
Lightwave
and
the
operating
system
that
we
ran
it
all
on
photon
OS,
which
is
also
another
offering
from
VMware.
C
A
So
just
for
us,
then
these
are
the
places
the
the
repos
that
a
lot
of
this
code
lives.
Spiffy
spiffy
is
the
specification
spire
is,
is
the
spark
code
and
spiffy
example.
What
we
do
is
every
month
or
two
months
we
put
out
an
example
showing
the
current
state
of
the
of
the
system.
The
last
one
we
did
was
using
nginx
with
the
with
support
for
the
workload
API,
one
that
oh
and
again,
there's
a
blog
post
associated
with
that
I.
You
should
go
check
it
out
and
you
know
previously.
A
C
A
C
D
Actually,
you're
quite
correct:
it's
still
that
you
have
to
be
on
our.
You
have
to
be
within
a
routable
networks,
so
client,
server
and
KDC
will
all
have
to
be
on
the
same
network
on
the
MIT
KDC
on
the
MIT
curb
stuff,
there's
actually
a
feature
that
allows
you
to
ignore
that
notion
of
basis,
saying
you
have
to
be
on
the
network,
but
in
general
you're,
absolutely
right.
We
always
are
on
the
same
route.
Herbal
network.
B
Yes,
yes,
yes,
so
that
that's
the
notion
of
the
short
the
what
the
question
was
for
Kerberos
IO
station
to
work.
You
would
still
need
to
bootstrap
the
node
to
have
a
Kerberos
key
tab
or
a
Kerberos
configuration
set
on
it.
And-
and
the
answer
to
that
is.
It
is
automated,
through
domain
controllers,
in
the
concept
of
a
domain,
so
for
a
light
wave,
for
example,
and
for
Active
Directory
as
well.
Whenever
you
join
a
host
to
a
domain,
the
key
tab
in
the
Kerberos
configuration
is
automatically
placed
on
that
node.
D
D
You
you
actually
describe
it
exactly
the
way
we
actually
do
it
do
as
well.
So
you
we
one
of
the
things
you
do
in
Kerberos
is
you
have
the
domain
controller
and
macey?
Then
you
have
accounts
that
are
authorized
to
actually
perform
to
be
enjoying
to
perform
a
domain
joint,
because
you
really
don't
want
to
use
your
domain
administrators
credential
to
do
the
domain
joint,
so
you
want
to
have
a
a
delegated
ordinary
user.
D
Who's
has
the
only
rights
to
actually
say
join
machines
in
so
that's
one
level
of
security
already
get
in
and
you
actually
discover
it
just
perfectly
the
way
we
actually
do
it
internally.
So
what
we
do
in
VM
Vere's,
we
basically
use
lightweight,
but
lightweight
also
supports
OAuth
as
well.
You
know
he
talked
about.
He
talked
about
convergence
of
Hoth
and
Kerberos
because
we
treat
the
we
unify.
We
converge
the
identity.
What
a
client
registration
is
is
a
service
principle
for
us.
We
do
that,
that's
one!
D
D
C
C
D
No,
your
Active
Directory
quite
well.
But
what
happens
is
you
know
one
of
the
points
again
I'm,
so
sort
of
blown
away,
especially
because
for
me,
I'm,
an
old
curb
Louis
hand
and
the
way
I
look
at
spiffy
is
spiffy
is
sort
of
modernizing
sort
of
it's
the
perfect
hybrid.
It's
x-file,
it's
like
urbanizing,
sorry,
all
right,
Shane
as
well.
It's.
D
So
I
have
not
so
what
let
me
ask
you
a
question
for
us.
What
happens
is
on
every
node.
You
actually
have
a
daemon
running
and
what-
and
so
we
make
this
available
so
the
source
code
we
make.
The
clients
have
a
daemon
running
on
it
too,
and
the
statement
is
something
we
call
the
AFD
daemon
and
what
the
FT
Damon
does.
Is
it
manages
once
you
do
the
domain
join
it's
managing
its
Kerberos
key
table
right.
So
what
it
does
right
now
is.
D
It
is
like
a
security
principle
and
it
is
a
client
to
the
directory
service.
So
what
it
does
is
it
scans
the
directory
periodically
and
on
the
top
of
the
directory?
Is
the
domain
policy
object
and
on
the
domain
policy
object?
We
tell
you
what
the
default
policy
is
to
sort
of
refresh
your
machine
password
and
so
periodically
we're
tracking
that
it
was
saying.
Ok,
30
days
up
and
the
default
typically
in
Active,
Directory
environment
is
30
days.
We
track
it,
you
could
configure
it
there
and
then
we'll
Auto
refresh
in
we'll.
F
So
but
but
what
does
this
spiffy
stuff
then
give
that
kerberos
doesn't
already
done
too,
if
you
encode
your
service
principal
name
like
a
path
or
something
I,
that's
still
sort
of
the
thing
with
with
all
of
this,
for
never
something
it's
something
that
shows
up.
It's
just
like
it
said
every
implementation
of
Kerberos.
D
Spiffy
is
kind
of
really
quite
elegant.
The
concepts
are
very
similar.
I
mean
the
first
concept
that
probably
Kerberos
put
in
place
was
the
notion
of
a
UPN
or
a
service
principle
name,
and
basically,
what
that
means
is
whether
you're
a
service,
whether
you're,
a
user
or
whether
you
know
whether
you're
an
ordered
human
user
or
whether
you're
a
service.
D
Fundamentally
naming
is
a
key
part
of
it
and
what
you
have
out
there
is
this
notion
of
in
a
cloud
native
world.
You
have
this
notion
of
a
name.
That's
point
number
one,
that's
50
gives
you
the
second
thing
that
spiffy
does,
which
basically
is
what
Kerberos
Kerberos
was
always
built
around
usernames
and
passwords
right,
and
you
have
to
realize
those
days
are
long
gone
and
if
that's
not
secure
and
so
what's
50
does,
which
I
think
is
also
really
elegant.
D
It's
moved
away
from
a
symmetric
key
system
into
PKI
right,
and
so
that's
point
number
two
I'm
going
to
put
that.
The
problem
with
PK
in
Pai
in
the
old
world
is
that
PK
I
never
had
in
any
of
the
x.509
world.
Pk
I
never
had
a
model
in
which
you
could
handle
the
things
that
Kerberos
could
do.
You
didn't
have
the
equivalent
of
an
MIT
Kerberos
API
or
like
the
one
that
and
the
only
other
one
which
really
did
the
automation
of
Kerberos.
D
D
Does
it
sort
of
marries
that
world
of
a
Kerberos
system
using
an
esse
metric
key,
a
key
I'm
on,
and
that
is
I-
think
it's
well
over
and
time
well
over
to
you
that
we
actually
do
this
so
I
think
that
is
a
that
is
the
relevant
that
that's
a
kind
really
cool
thing.
That's
come
about
on
by
the
way
it
breaks
this
whole.
The
IP
address
problem,
I.
Think.