►
From YouTube: SIG Auth Update and Deep Dive - Mo Khan, Red Hat; Mike Danese, Google; & Tim Allclair, Google
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
SIG Auth Update and Deep Dive - Mo Khan, Red Hat; Mike Danese, Google; & Tim Allclair, Google
This session will cover the inner workings of SIG Auth and its sub projects. The SIG is looking to expand contributors and attending this session is a great way to get involved. An update of the SIG's activities in the last six months will be provided. Based on community feedback, three deep dive topics will be covered: 1. The future of pod security policies Various limitations and structural problems have prevented the PSP API from GA. Possible paths forward will be explored. 2. Open Policy Agent and Gatekeeper Gatekeeper is an early stage project that aims to support policy enforcement via a Kubernetes style, custom resource definition based API. 3. Bound service account tokens, audiences and the future of container identity Asserting identity of Kubernetes workloads to external components is an essential part of access control. Bound SA tokens make this task easier and more secure.
https://sched.co/Uakn
A
I
can
tell
awesome:
okay,
welcome
everyone.
This
is
the
cig
off
intro
and
deep
dive
for
cube
con
north
america.
What
is
this
2019
yeah
good,
so
I
I
won't
let
everyone
know.
This
is
super
informal
if,
as
a
show
of
hands
who
here
in
the
audience,
has
intended
a
cig
auth
meeting
before
okay.
So,
basically,
we
have
like
a
little
agenda
and
anyone
can
join
at
any
time
on
zoom'
and
we
just
talk
about
stuff
and
like
anyone
has
like
anyone,
can
get
right
access
to
our
agenda
and
all
those
things.
B
A
Awesome
so
did
someone
ask
something?
Okay,
so
there's
a
decent
amount
of
us.
I
won't
necessarily
go
over
the
name,
so
my
containment
I
have
been
introduced.
We
have
a
bunch
of
sub
projects
which
sort
of
get
managed
by
a
set
of
different
people,
not
necessarily
us
that
list
of
reviewers
is
not
complete
by
any
means,
and
you
don't,
for
example,
have
to
be
a
reviewer
to
review
our
code,
it's
more
of
just
the
set
of
people
that
are
sort
of
guaranteed
to
get
pinged
by
the
bots.
A
So
of
course
you
have
to
have
an
xkcd
comic,
we're
the
one
that
you
know,
try
to
stop
you
from
connecting
and
talking
to
all
the
things,
or
at
least
not
unless
you
have
em
TLS
or
something,
but
so
the
signal
charter
is
effectively
centered
around
protecting
access
to
pronounced
components,
authentication
and
authorization
being
core
tenants
of
that.
We
do
have
some
level
of
ownership
of
things
like
auditing
and
some
set
of
security
policies.
We
generally
don't
have
ownership
of
things
like
network
policy,
though
even
granted.
Some
people
consider
that
security
as
well.
A
A
If
you
are
familiar
with
the
kms
API
or
the
distinct
rips
in
config
in
general.
Encryption
arrest
is
an
important
piece
of
that.
Multi-Tenancy
is
still
sort
of
in
its
relative
infancy
for
kubernetes
of
the
poll,
but
we
are
making
progress
if
you're
familiar
with
the
node
ID
authorizer
or
the
node
admission,
plugins
or
restriction
plugins,
those
sort
of
encompass,
know
it's
identity
and
isolation.
B
And
also
I
think
what
is
not
on
this
list
is
interesting.
We're
not
a
sig
security.
We
handle
suppose
supposedly
identity
an
authorization,
but
we
sometimes
I
take
on
things
like
encryption
at
rest,
where
there
is
another
good
fit,
but
we
don't
handle
security
for
the
for
the
project.
Security
is
everybody's
responsibility,
so
for
node
security,
that's
something
that
Sigma
I
would
handle.
We
don't
have
a
general
security,
I,
say
kubernetes
and.
C
A
B
A
A
E
A
As
a
question
who,
all
in
the
audience
was
familiar
with
like
feature
states
like
alpha
beta
and
GA
and
sort
of
what
they
mean
to
the
kubernetes
project
as
a
whole,
okay,
so
most
of
you
guys
have
a
decent
idea.
But
the
important
bit
about
beta
is
a
lot
of
providers,
will
enable
the
feature
by
default
and
has
this
perverse
incentive
on
developers
to
get
a
feature
to
beta
and
then
ignore
it
yeah,
and
we
are
somewhat
guilty
of
that.
We
just
got
busy
with
various
places,
but.
F
E
And
then
we're
gonna
be
talking
about
pod
security
policy
in
a
lot
more
detail
later
in
this
talk
or
conversation,
and
then
dynamic
auditing
is
a
feature
in
an
alpha
state
that
was
added
about
a
year
ago,
and
it
has
a
rest,
a
whole
lot
and
so
I
expect
we'll
have
some
more
conversations
around
what
the
future
of
dynamic
auditing
is
going
to
look
like,
but
it's
an
open
question
I
would
say,
and
then
we
also
want
to
deprecate
some
things
and
delete
some
code.
A
back.
Did
we
actually
decide
to
deprecated
a
VAX.
E
E
There's
a
bunch
of
admission
controllers
that
are
not
turned
on
by
default
and
are
already
marked
as
deprecated
or
maybe
those
ones
aren't
that
we
should
be,
and
then
there's
some
that
are
marked
as
deprecated
and
we
want
to
delete
them.
So
a
lot
of
cleanup.
We
are
still
open
to
new
features,
but
a
big
focus
is
going
to
be
kind
of
stabilizing,
adding
better
test
coverage
for
these
things
also.
B
Okay,
so,
along
the
lines
of
that
cleanup,
we
added
a
bunch
of
retroactive
caps
for
some
of
those
beta
features.
So
to
give
background,
for
example,
that
first
one
that
that
API
has
existed
since
kubernetes
1:6
it's
about
three
years,
probably
over
three
and
a
half
years
old.
Now
it's
still
a
beta
API.
We
don't.
We
have
a
lot
of
things
that
we
don't
really
like
about
the
shape
of
it,
but
it's
beta
and
it
is
used
extremely
broadly
among
kubernetes
deployments,
and
it's
it's
a
pretty
critical
API.
B
In
order
to
make
progress
on
this,
we
created
a
kept
for
the
that
describes
the
existing
state
since
the
I
think
the
original
PR
was
that,
like
PR
8000
or
something
this
was
a
long
before
we
had
a
formal
process
for
introducing
these
features.
So
what
we're
gonna
do
with
this
cap
is
we're.
Gonna
use
it
as
a
place
to
initially
write
down
some
user
stories,
which
is
not
something
that
we
had
considered
when
we
implemented
this
API.
B
So
we
want
to
really
understand
how
we
want
people
to
use
it
and
then
from
there
we
can
start
to
discuss
graduation
requirements
and
basically
a
checklist
of
things
that
need
to
happen
before
we
marked
the
API
is
G.
A
similar,
similar
story
for
bad
service
account
tokens
that
was
slightly
predated,
that
Carino's
enhancement
proposals,
so
David
EADS
did
a
bunch
of
work
on
basically
making
every
single
certificate
bundle
that
we
read
from
in
kubernetes
dynamically
rotatable.
B
There's
a
really
old
issue
about
how
difficult
it
is
to
rotate
the
service
count,
see
a
cert
think
it's
like
Eric
tunes
like
issue
and
the
five
thousands
I
think
we've
gone
through.
Basically,
all
of
the
certificates
now
that
they're
reloading,
except
for
I,
think
there's
one
left
to
do,
and
once
we
do
that
we'll
have
a
lot
better
story
for
automated
rotation
of
certs
and
the
cluster.
E
E
We've
restricted
the
labels
that
cubelet
can
add
to
itself.
This
is
sort
of
a
like
multi
release,
rollout
process,
I
think
we
1:18
so
we're
also
adding
some
more
restrictions
on
what
the
cubelet
can
do
to
run
it
as
even
more
lease
privilege,
because
there's
actually
a
lot
of
things
that
cubelet
can
do
a
lot
of
ways.
E
It
can
escalate
privilege
if
we're
not
careful,
but
also
it
turns
out
that
if
you
have
owned
the
node
that
you're
in
trouble
in
a
lot
of
other
ways,
we
talked
about
this
yeah
I
gave
a
talk
on
this
earlier.
Go
back
and
watch
it
if
you
haven't
so
we'll
probably
continue
to
build
out
node
restriction.
But
it's
not
going
to
be
a
big
focus
area
for
us
outside
and.
B
So
if
I
are
any
of
you
familiar
with
the
priority
and
fairness
kept
from
API
machinery,
they're
working
on
building
some
support
for
API
priority,
so
that
you
can't
have
a
disruptive
controller,
overwhelming
the
API
and
destabilizing
the
cluster.
That
feature
is
going
s.
The
fairness
is
keyed
off
of
the
identity
of
the
caller.
So
in
order
for
that
to
be
a
viable
approach
to
implementing
priority
in
fairness,
we
actually
have
have
to
make
authentication
a
lot
faster
than
it
is
today.
B
We've
in
the
past,
probably
three
releases
there's
been
maybe
six
or
seven
major
improvements,
so
the
performance
of
authentication,
so
we're
gonna.
We
have
I
think
one
more
open
to
improve
it
further,
but
we
want
to
make
sure
that
we
are
able
to
meet
the
requirements
of
the
priority
and
fairness
cap
and.
F
B
A
E
The
cig
off
code
can
be
a
little
gnarly
to
get
started
on.
Sometimes
it
can
be
pretty
sensitive
to
subtle
behaviors,
but
we
try
and
tag
issues
with
good
first
issue.
If
you
aren't
super
familiar
with
the
codebase,
that's
a
good
place
to
get
started
or
for
more
experienced
contributors
who
want
to
help
out
the
Help
Wanted
labels
are
for
that
purpose.
A
E
E
B
One
more
question
who
filled
out
the
poll
that
we
sent
out
a
task
about
what
we
should
talk
about
today.
Did
anybody
fill
out
the
poll?
We
got
a
lot
of
responses,
it
was
surprising,
but
then
I
guess
nobody
showed
up
said
there
was
a
group
of
people
that
are
not
here
today
that
select
these
topics
or
YouTube
is
oh.
That.
A
So
our
back
has
no
concept
of
like
label
based
off
our
back
can't
even
do
deny
based
off
so
the
general
question
week
or
the
simplest
question
is:
can
you
run
a
pot
as
privileged
as,
for
example,
that's
sort
of
what
PSP
exists
to
protect
against,
which
is
a
administrator
may
want
to
make
it
so
that
you
can't
just
run
rude,
privileged
pods
everywhere
and
sort
of
kind
of
defeat.
The
point
of
having
containers
in
the
first
place
so
I
already
mentioned
the
route
bit.
A
E
A
F
A
So
what
se
sees
we're
trying
to
solve
was
not
a
well
understood
problem.
We
can
gloss
over
if
it's
well
understood
right
now
or
not,
but
so
PSPs
were
sort
of
based
off
of
that,
but
they're
significantly
stripped
down
or
altered
in
certain
ways,
but
both
the
translation
from
openshift
into
upstream
kubernetes
and
the
fact
that
both
were
built
without
necessarily
a
fine
understanding
of
what
problems
we
would
encounter
in
this
space.
Sorta
has
led
to
like
a
weird
shape
to
everything
on
this,
so
the
first
of
all
some
of
this
basically
gets
everyone.
A
Please
tell
me:
you
can't
see
that
I'm
good.
My
wife
is
text
messaging.
Sorry,
first
of
all,
like
generally
speaking,
when
people
start
using
kubernetes,
they
want
to
go
run
a
pod
because
that's
like
the
first
thing
you
do
and
I
guess
in
an
attempt
to
address
that
use
case.
It
was
sort
of
built
out
that,
if
you're
like
cluster
admin,
we'll
obviously
you
can
do
anything
so
PSP
is
allowed.
A
Basically,
the
user,
who
is
making
the
request
to
authorise
the
pod
or
the
service
account
that
the
pod
is
running,
has
to
authorize
the
pod
right
and
this
sort
of
makes
sense
until
you
realize
that
no
one
is
actually
supposed
to
directly
run
pods.
Okay,
in
any
realistic
scenario,
user
deployment,
which
runs
replica
sets
which
runs
pods.
A
So
you
get
into
this
weird
mode
where
you
yourself
might
have
granted
like
you
know,
you
might
have
had
the
permission,
but
then
you
try
to
run
a
deployment
and
it
fails
because
you
didn't
grant
it
to
the
service
account
or
worse.
You
have
decided
to
grant
the
cluster
admin
to
all
the
controllers
that
run
the
main
control
plane,
and
you
don't
realize
that
that
has
in
fact
caused
it
so
that
all
pods
and
your
cluster
can
run
privileged
right.
A
You
ask:
can
you
use
this
PSP,
but
you
can
bind
that
to
like
a
namespace
level
with
our
back,
but
if
you
bind
like
a
privilege
granting
PSP
in
a
namespace
there's
nothing
keeping
it
inside
that
namespace
as
a
pot,
in
the
sense
that
you
know
you
could
hurt
other
pods
running
on
that
node
in
some
other
namespace
right
so,
like
you
can
think
you've
bound
it
to
someplace.
But
you
happened
right
so
like
it's
completely
unclear
right.
A
Another
aspect
is
that
when
you
roll
this
out
the
you
get
to
roll
it
out
all
at
once.
This
was
never
an
issue
in
openshift
because
there
was
no
release
where
SCC's
weren't
enabled,
by
default
with
some
policy,
not
to
be
fair
in
the
early
days
of
that.
That
caused
a
lot
of
pain
for
open,
shipped
customers,
because
they
couldn't
figure
out
how
to
run
pods.
A
It's
very
strange
having
an
orchestration
platform
that
can't
orchestrate
pods,
it
was
painful,
but
imagine
you
know
you've
been
using
a
cluster
for
some
amount
of
time
and
it's
working
fine.
You
have
workloads
running
and
you're
happy
with
it,
and
now
you
decide
that
and
like
security
is
important,
you
know
you
actually
have
important
things
running
on
it
and
you
want
to
turn
this
thing
on
right.
You
have
to
in
one
fell
swoop,
audit
every
single
workload,
understand
all
of
their
requirements
and
create
policies
that
sort
of
match
all
of
them
in
one
go
right.
A
A
Another
little
bit
is
unlike
sec:
PSP
doesn't
have
a
built
in
policy
and
in
the
sense
of
a
bootstrap
policy
and
I
think
that
was
initially
just
there,
because
we
didn't
know
what
anyone
needed
and
it
didn't
sort
of
make
sense
to
just
take
the
guess,
as
we
made
an
open
shift
and
put
them
out
into
the
world
as
canonical
things.
But,
unlike
our
back,
if
you
sort
of
see
our
back
being
used
and
like
helm,
charts
and
other
places
they
tend
to
include
like
manifests
like
nice,
complete
manifests
of
what
can
the
workload
do?
A
That
sort
of
culture
doesn't
exist
for
PSPs
and
sort
of
the
the
byproduct
of
all
of
this
sort
of
organic
growth
is
basically
it's
just
hard
to
use
right.
There's,
no,
like
real,
well
thought-out
design
of
all
the
things.
I
think
this
one
like
with
a
lot
of
inserted
effort,
could
be
fixed,
but
it's
it's
sort
of
hard
to
justify
at
certain
points.
The
composability
bit
is
also
interesting
like
if
you
think
about
our
back,
you
know
you
can
grant
something
to
permissions
and
it
can
do
either
one
of
those
actions,
then
right.
A
A
H
So
one
of
the
problems
we've
seen
with
pod
security
policies
is
guess
the
lack
of
having
a
pod
security
policy,
but
also
the
lack
of
a
lot
of
public
charts
having
actual
security
context
on
the
pod
definitions
themselves.
So
really
we
can't
expect
them
to
implement
pod
security
policies
when
they
haven't
even
put
the
security
context
for
their
painters
themselves.
Do
they
run
his
route?
Do
they
not
run
a
screwed?
None
of
that
other
stuff
is
populated
ahead
of
time.
A
And
I
think
that's
a
byproduct
of
like
when
we've
like
when
our
back
went
like
v1
GA
right
like
we
didn't
it
didn't
mean
that
somehow
we
could
immediately
have
it
like
as
the
only
form
of
solution
right,
but
over
time
it
has
matured
and
the
community
has
decided
that
they
liked
it
enough
to
include
that
in
their
manifest
right,
I,
don't
I,
don't
think
PSP
ever
got
anywhere
near
that
level
of
like
critical
mass
to
cause
sort
of
a
pressure
on
like
people
who
develop
helm.
Charts
to
like
actually
worry
about
that.
B
A
The
back
as
you're
walking
there
so
just
to
give
you
everyone
in
context
right.
We
had
someone
from
Twitter
come
in
on
our
one
of
our
weekly
meetings,
and
that
was
probably
one
of
the
first
time
we've
had
like
concrete
feedback
from
someone
running
like
a
lot
of
pods
in
like
big
production
clusters
for
how
they
use
PSP,
and
if
you
do
that,
please
tell
us
how
you
do
it
and
what
works.
A
And
what
doesn't
because,
like
it's
very
hard
for
us
to
make
like
forward
movement
and
this,
but
like
just
looking
inwardly,
right
like
like
Google
VMware,
Red
Hat,
like
we're
very
big
corporations
with
a
very
big
IT
budgets,
and
we
can
basically
kind
of
do
whatever.
But
that
doesn't
necessarily
scale
to
everyone
else.
I
So
we
do
run
PSPs
in
our
clusters,
the
general
thing
for
cube
system.
We
have
a
privileged
one,
because
you
need
it
and
for
everything
else
for
system
authenticated
groups,
we
have
a
restricted
policy,
which
is
for
every
workload
out
there.
Now
I
share
the
same
problem
pain
that
he
shared
about
like
help
charts,
not
shipping
PSPs
with
them
by
default.
But
then
there
is
also
another
way
of
looking
at
it
like
not.
I
Everyone
who
is
installing
charts
on
the
cluster
has
has
permissions
to
install
PSP,
and
you
definitely
need
a
cluster
role
to
be
created
to
use
the
PSP.
So
that's
another
problem
we
have
here
and
since
we
allow
it
like,
we
allow
the
system
authenticated
like
since
it's
called
restricted
and
then
sometimes
we
create
a
PSP
which
is
catered
to
that
particular
workload.
But
then,
since
this
since
to
PSPs,
are
now
applying
to
that
particular
workload,
this
alphabetic
color
thing
comes
into
picture
and
then
yeah
it
works
very
weird.
Sometimes
it
picks
up.
I
Sometimes
it
doesn't
because
your
API
server
is
still
reconciling
that
it.
You
have
felt
the
PSP,
but
meanwhile
the
pod
has
already
is
already
coming
up.
It
picks
up
the
restricted
one
and
not
the
one
that
is.
It
was
catered
to
so
yeah.
There's
always
you
have
to
let
go
and
check,
go
back
and
check
it,
whether
it
is
it
aspect
up
the
PSP,
it
was
tailor-made
or
it
has
picked
up
the
restricted
one.
So
yeah
you
have
these
folders
as
well.
I.
E
What
is
the
maximum
privilege
that
I'm
willing
to
give
them
on
those
pods,
and
so
we
can
kind
of
think
of
that,
as
like
pod
security
policy,
sort
of
defines
the
upper
bound,
but
the
pod
security
context
is
what
should
actually
be
saying
what
security
the
pod
is
running
with
and
I.
Think
the
the
API
slide
kind
of
touched
on
this
there's
a
lot
of
there's
some
debate
around
mutating
pod
security
policies
and
whether
mutation
on
these
policies
is
actually
something
that
we
should
have
at
all.
J
Yes,
sir
I
guess
maybe
just
I
do
have
another
question,
but
I
just
want
to
say
so.
Do
you
think
it'd
be
fair
to
say
they?
You
could
think
of
like
the
pod
spec,
including
the
security
context
as
like
that's
the
key
and
then
the
PSP
is
like
the
lock
that
that
yeah,
if
the
key
don't
fit
the
lock,
then
they
won't.
They
won't
turn.
E
Like
you
could
say
that
the
security
context
is
the
enforcement
point
of
the
it's
kind
of
like
the
security
context,
is
actually
the
policy
for
the
run
time,
the
actual
running
plod.
That's
like
your
data
plane
policy
almost
and
then
the
pod
security
policy
is
all
kind
of
like
a
metabolic,
but
that
probably
just
is
more
confusing.
J
That's
might
be
de
metaphor,
so
yeah
the
question
I
had
was
about
I've.
Actually,
you
I
used
to
work
at
a
company
where
we
did,
we
use
PSPs
really
heavily.
We
actually
ran
a
cluster
that
was
a
completely
untrusted
workloads
where
people
could
schedule
any
docker
container.
They
like
and
run
it
and
the
because
of
things
that
I
had
no
control
over.
Those
pods
would
had
to
run
this
privilege
because
they
were
running
darker
and
darker.
J
So,
as
you
can
imagine,
it
was
pretty
nightmarish
from
the
security
context.
So
we
tried
to
do
everything
we
could
around
about
you
know.
Obviously
we
tried
pairs
pieces
like
as
well,
and
so
I
was
pretty
familiar
with
them
and
then
I
moved
to
a
new
job
and
in
my
new
job,
I
am
releasing
an
ingress
controller
and
we
recently
had
an
issue
where
someone
was
like
hey.
J
A
Do
it
so
and
and
I
promised?
The
second
question
we
were
asked
was
not
like
a
plant
because
it
sounds
almost
exactly
like
what
the
slide
is
suggesting,
which
is
basically
that,
if
you
from
what
we
gather
from
the
conversation
of
the
folks
from
Twitter
and
just
in
general
of
how
we
think
about
most
of
these,
we
could
probably
define
three
buckets
for
workloads
on
a
cluster
and
cover
most
of
the
common
use
cases.
So
the
obvious
one
is
privileged
right.
A
You
just
your
route
and
do
whatever
you
want
right
and
then
there's
the
restricted
state,
which
is
basically
what
every
like
security
person
wants.
You
to
do,
which
is
you're
not
running
his
route.
You're
not
running
in
the
privileged
container,
you've
dropped
all
caps.
You
only
have
a
small
select
of
volumes
that
you
can
mount
like:
no
host
pad
no
host
network,
none
of
that
all
right
at
the.
A
Yeah
all
the
things
right,
like
your
your
IT
admin,
is
very
happy
because
the
worst
you
can
do
is
destroy
yourself
and
then
there's
sort
of
default
which
is
sort
of
more
of
its
similar
to
restrictive,
but
basically
not
necessarily
like
not
as
tight
and
more
based
on
where
you
said.
You
would
framed
it
as.
A
E
So
this
is
like
the
absolute
bare
minimum
pod
you
could
spell
it
has
the
pod
has
a
name.
It
has
one
container.
The
container
has
name,
and
it
has
an
image
like
this
is
the
minimum
you
can
specify.
The
goal
of
the
default
profile
is
that
you
can
do
this.
The
default
profile
will
allow
this
pod.
If
you
try
and
escalate
privileges
above
what
this
pot
is
allowed
to
do,
then
it
will
get
denied,
and
so
ideally,
we
just
have
the
privilege
and
restricted
buckets,
but
to
actually
kind
of
cover.
E
A
It's
interesting
to
see
that
you
know
you
have
this
relatively
flexible
policy,
but
the
reason
that
the
Twitter
folks
decided
not
to
go
crazy
with
it
is
they
found
the
management
of
the
policies
to
be
too
difficult.
So
for
them
it
was
just
easier
to
have
like
a
contract
with
the
developers
that
they
won't
break
the
cluster
than
to
try
to
come
up
with
bespoke
policies,
but
her
workload
and
I
think
that's
it's
a
very
interesting
point
right.
E
Going
back
to
your
question
of
what
do
we
recommend
for
if
you're
deploying
a
thing,
how
do
you
include
a
policy
with
it?
I
would
say.
Ideally
you
shouldn't
have
to
because
it
should
fall
into
one
of
these
buckets,
and
we
can
say
you
know.
As
the
cluster
administrator,
you
found
these
buckets
in
the
correct
way.
J
I
was
actually
looking
to
add
was
to
be
like
you
know,
for
me
to
be
able
to
use
use
the
pod
security
policy
as
de
facto
documentation
of
the
permissions
that
we
know,
like
the
you
know,
least,
privileges,
that
we
are
confident
that
the
app
will
actually
need,
and
so
to
say
you
know,
maybe,
if
you're
privileged,
if
you're
restricted
thing
doesn't
look
kind
of
like
this,
then
it
may
not
work
like
or
something
like
that.
I
don't
know.
J
E
Yeah
yeah
and
we've
we've
talked
about.
We
have
a
few
ideas
which
maybe
we'll
go
into
in
a
little
bit
around
what
to
do
with
these
three
buckets.
One
of
the
ideas
is
just
to
kind
of
publish
this
as
official
kubernetes
documentation
that
we
think
these
are
the
buckets,
and
these
are
the
permissions
we
think
should
go
in
each
one
and
then,
if
we
had
that,
then
an
app
could
publish
as
part
of
its
documentation.
We
run
in
the
restricted
bucket,
or
we
run
in
the
default
bucket.
B
That
has
a
nice
property
in
that
it's
we
tend
to.
We
have
added
stuff
to
security
context
over
time,
for
example,
like
windows,
containers,
new
types
of
sandbox
is
new.
Like
new
additions,
no
new
prigs.
We
need
to
be
able
to
keep
I
guess
each
of
those
buckets
just
like
an
ideal
and
adding
more
restrictions
to
a
bucket
means
that
we
could
potentially
break
applications
so,
but
potentially
by
moving
this
into
documentation
and
having
users
carried
it
to
their
needs.
We
could
avoid
that
problem.
Yeah.
E
Privilege
should
never
change,
you
can
always
do
everything
yeah
restricted.
We
expect
to
change
over
time,
and
so
that
would
probably
need
to
be
versioned.
So
this
is
the
restricted
profile.
As
of
this
kubernetes
version,
as
we
add
features
that
kind
of
further
protect
pods,
for
example,
stacking
Linux
security
modules
is
coming,
so
you
can
attach
maybe
someday
you'll
be
able
to
attach
an
app
Armour
profile
in
your
container
that
layers
on
top
of
the
default
system,
app
armor,
profiler
layer,
SELinux
and
the
app
armor
together.
E
So
that's
an
example
of
something
that
might
come:
user
namespaces
is
another
one,
and
so,
as
we
roll
those
things
out,
the
best
practices
are
going
to
change,
and
so
we
would
want
to
be
able
to
say,
like
the
next
restricted
version
default
may
or
may
not
need
to
be.
Versioned
I
need
to
think
about
that.
A
little
harder.
H
The
only
use
case
I
can
think
of
off.
The
top
of
my
head
is
the
one
where
you
would
want
to
give
access
to
the
host
node
file
system.
That
only
is
read-only
for
like
virus
scanning
are
other
things
that
check
the
compliance
of
those
system.
But
you
don't
want
to
give
that
particular
pod
access
to
modify
those
files
so.
E
Storage
there's
now
a
local
persistent
volume
which
is
sort
of
the
administrator
defined
host
path,
volume,
and
so
a
privileged
user
can
say.
I'm
gonna
define
this
local
volume
or
this
local
view
of
the
file
system
and
then
make
that
available
to
less
privileged
users
through
a
persistent
volume
claim
to
use
in
a
pod.
I,
don't
know
offhand
if
you
can
say
that
this
local
volume
is
read-only,
but
that
might
be
an
interesting
way
to
tackle
that
problem.
You
yeah
I,
guess
you
can
do
that
in
PSP
today,
throughly
read-only
host
mounts.
H
A
So
we've
sort
of
been
discussing
this
a
little
bit
right.
So
how
do
we?
How
do
we
go
from
today
to
where
we
want
to
be
okay,
so
sort
of
the
obvious
thing
would
be
fix,
PSPs
right,
it's
not
necessarily
clear
what
that
means,
but
you
know
it
sort
of
has
to
have
some
vague
concept
of
being
on
by
default.
A
A
Don't
think
necessarily
like
the
sick
can
answer
this
question
by
itself,
because
it's
more
about
sort
of
like
how
people
imagine
using
the
platform,
all
right
like
I,
don't
like
I
I
as
a
user
of
the
platform,
would
kind
of
be
bothered
if,
like
our
back,
was
like
not
part
of
core
cube
just
because
I'm
so
used
to
using
it.
Okay,
one
of
the
suggestions
to
sort
of
take
PSPs
back
to
its
roots
was
to
convert
it
into
a
web
hook
that
was
actually
backed
by
sec
s
so
like
open,
show
security
context.
A
Constraints
can
still
do
basically
everything
that
PS
piece
can
do.
So,
if
you
guys
are
familiar
with
the
history
of
our
back,
it
started
out
in
open
shipped
as
authorization
policy.
It
was
up
streamed
as
the
are
back
api
and
then
once
we
had
gotten
to
the
point
that
our
back
was
sort
of
done
in
open
shift,
we
built
controllers
to
basically
take
the
authorization
policy
data
alive,
converted
into
our
back
and
keep
them
in
sync
and
then
a
release
later
we
flipped
it
and
made
our
back
the
source
of
truth.
A
Instead
of
authorization
policy,
we
had
a
proof
of
concept
of
this:
an
open
ship
to
do
the
same
thing
that
would
sort
of
make
things
better
because
sec
s
have
worked
a
little
bit
better
than
PSBs
an
open
shift
for
a
few
years,
but
I'm
not
sure
if
that
necessarily
gets
us
to
an
end,
good
state
that
we
are
happy
with.
Those
are
just
sort
of
suggestions,
and
I
think
one
of
those
sort
of
suggestions
is
to
use
OPA
so
I'll.
Let
Tim
talk
about
that.
E
Yes,
this
is
just
to
kind
of
frame.
This
conversation.
This
is
one
of
the
I
would
say
it's
one
of
the
leading
proposals
for
the
future
of
POD
security
policy
would
be
to
basically
say
we're
going
to
deprecated
pod
security
policy
and
we're
gonna
build
a
really
good
migration
path
to
the
gatekeeper
project
and
sort
of
encourage
that
as
the
de
facto
standard
for
limiting
pod
permissions.
And
of
course,
you
can
run
any
admission
policy
font,
but
this
would
be
sort
of
the
kind
of
the
standard
direction
that
we
point.
E
People
in
so
that's
just
kind
of
to
frame
this
discussion.
Now,
let's
talk
a
bit
more
about
what
OPA
and
gatekeeper
are
before
we
go
into
that.
Can
I
have
a
show
of
hands
who
has
heard
of
OPA
or
open
alright
Lucy?
Yes,
who
has
actually
used
OPA
all
right
and
how
about
gates
/,
who
has
heard
of
gatekeeper,
pretty
good
and
who
has
used
gatekeeper?
E
Nobody,
okay,
it's
a
new
project.
So
so
what
is
it
so?
This
is
rego.
This
is
I
just
pulled
this
out
of
one
of
the
gatekeeper
templates.
It's
cut
off
at
the
bottom
because
it
didn't
fit
on
the
slide.
I.
Don't
actually
actually
expect
you
to
read
this,
but
the
point
is:
there's
a
lot
of
work
to
express
a
fairly
simple
policy
that
says
a
container
must
run
as
a
user.
You
can
probably
do
this
in
fewer
lines
of
code
if
you're
just
writing
a
straight-up
OPA
policy.
E
E
E
E
E
You
can
also
apply
it
to
your
to
your
code
in
your
CI,
CD
flow
or
anywhere
else,
and
actually,
if
you
kind
of
by
similar
logic,
you
don't
need
to
just
use
this
in
the
context
of
kubernetes.
You
can
then
have
consistent
policy
not
only
in
kubernetes,
but
also
for
your
declarative
infrastructure
and
your
even
your
data
plane
policies
as
well
so
kind
of
unifying
all
of
the
policy
in
one
way
that
can
easily
be
audited
and
understood
together.
E
E
We
have
validating
admission
control
context,
aware
referential
policies
which
I
think
means
that
constraints
can
reference
objects
that
you're
not
just
applying
the
constraint
to
so,
for
instance,
you
might
want
to
say
check
if
a
namespace
has
a
lit
up,
odd
x'
namespace
has
a
label,
and
you
can't
just
do
that
if
you're
only
looking
at
the
pot,
you
have
to
also
say
well,
this
pod
use
references
this
namespace.
Let
me
go
look
up
that
namespace
and
check
the
label
on
that
namespace.
K
Yes,
my
name
is
Mack
Smith
I'm,
one
of
the
maintainer,
so
that
gatekeeper
project
along
with
Rita
I
am
Rita
and
yeah
I.
Think
one
of
the
uses
for
audit
that
I
heard
from
a
question
here,
someone
was
mentioning
they
had.
There
is
there's
some
almost
like
a
race
condition
with
PSP
where
a
pod
got
started,
but
under
what
auspices
did
it
get
approve
right?
The
old
PSP,
the
new
PSP
right
and
because
not
you
know
not
only
as
kubernetes
like
an
eventually
consistent
kind
of
model,
but
also
your
policies
change
over
time.
K
E
And
so
the
latest
update
project
we
now
have
dry
run
so
apply
it
to
manifest
before
they're
actually
applied
names
based
selectors.
Let
you
say
I
want
to
apply
this
constraint
to
this
set
of
namespaces
there's
a
policy
library.
The
eventual
vision
is
to
have
a
whole
policy
ecosystem
where,
hopefully,
you
never
have
to
touch
rego.
E
Someone
else
has
already
had
the
same
problem
that
you're
trying
to
solve
and
they've
already
written
a
constraint
template
for
it,
and
so
you
can
just
you
know,
maybe
even
as
a
Helmut
art
you
install
this,
this
constraint,
template
and
then
parameters
that
you
need
and
multi-source
constraint
templates.
Let
you
break
out
the
rego
source
from
the
template.
I
think.
K
So
so
this
is
about
sort
of
code,
reuse
at
the
the
Reagan
level
right
so
there's
already
a
lot.
Opa
has
some
regular
libraries
for
some
common
tasks.
As
more
people
develop
constraint
templates,
we
expect
that
there
will
be
more
patterns
that
happen.
You
know
like
assuming
a
value
is
some
default
value
if
it
doesn't
exist
that
kind
of
thing
so
multi-source
constraint
templates.
Essentially,
you
can
have
all
of
your
regular
brer
ease,
embedded
in
the
constraint
itself,
so
that
you
could
share
code
without
copying
and
pasting.
E
G
E
There's
open
proposals
for
adding
mutation,
so
not
just
validation
but
being
able
to
if
we
actually
want
to
get
to
feature
parity
with
pod
security
policy
which,
by
the
way,
I'm
not
necessarily
sure
that
that
should
be
the
like
the
goal.
But
if
we
want
to
do
get
to
feature
parity
with
pod
security
policy,
we
need
mutation
there
I.
K
A
external
data:
you
know
a
common
pattern
that
people
are
wondering
is
like
I.
Have
an
LDAP
database
right
like
I,
want
to
verify
that?
Not
only
am
I
referencing
a
user
like
thing,
but
it's
actually
a
user
at
my
company
right.
So
when
you
have
that
kind
of
external
system,
how
can
we
write
policies
that
reference
that,
but
in
a
performant
way
right?
So
maybe
a
caching
mechanism,
I,
don't
know
right.
E
And
then
yeah
more
more
production,
izing
features
and
I
want
to
make
a
comment
on
this
last
one.
So
right
now,
a
common
way
of
matching
or
applying
policy
or
constraints
to
specific
objects
is
by
matching
on
labels,
whether
those
are
labels
on
the
resource
itself
or
labels
on
the
namespace
that
that
resource
is
running
in
and
so
an
idea
that
I've
kind
of
floated
to
a
few
people
is.
Maybe
this
is
the
one
place
where
it
really
makes
sense
to
build.
E
Policy
into
kubernetes
is
to
have
authorization
on
labels,
and
then
you
can
use
those
authorized
labels
to
control
the
authorization
of
all
the
policies
that
apply
based
on
those
labels.
So
that's
an
open
question
something
yeah
discuss
later
so
maybe
before
we
move
on,
are
there
any
questions
on
gatekeeper
or
policy
in
general,
ESB.
E
In
case
this
wasn't
made
clear
earlier:
sig
auth
doesn't
own
or
even
work
on
the
gatekeeper
project
or
OPA,
so
you
might
be
wondering
kind
of
like.
Why
are
we
talking
about
this
so
much
in
sig
auth?
And
it's
because
we're
exploring
what
the
future
of
plod
security
policies
are-
and
this
is,
as
I
mentioned
earlier,
kind
of
one
of
the
leading
contenders.
E
E
Yeah
so
HOD
security
policy
today
has
the
ability
to
set
defaults
on
fields,
so
you
can
say
if
if
no
user
is
provided,
then
this
pod
should
run
as
this
user
by
default.
For
instance,
there's
two
ways
you
can
use
that
today,
one
is
to
say:
well,
you
run
with
higher
privileges,
but
I'm
going
to
encourage
you
to
run
with
these
best
practices.
Privileges,
I
think
the
more
compelling
use
case
for
mutation
in
pod
security
policy
is,
if
I
place
a
restriction.
That's
not
default,
not
the
pod
default,
one
on
you.
E
So,
for
instance,
if
I
want
to
say
you
have
to
enable
the
docker
default
second
profile,
then
all
of
your
pods
would
break
and
you
have
to
go
and
change
every
single
pod
template
to
say
add
in
the
docker
default
second
profile,
but
with
mutation
you
can
say
you
have
to
run
with
this
and
also
I'm
going
to
default
it
to
that.
So
you
don't
have
to
worry
about
changing
every
pod.
A
Something
else,
and
if
that
wasn't
okay,
then
you
get
an
error,
a
even
much
more
trivial,
a
much
more
simpler
case
is
it's
it's
nice
to
know
what
PSP
your
pot
is
running
at
and
it
is
it
does
it
annotate
or
label
I
can't
remember,
but
it
mutates
the
pod
to
say
you
ran
as
this
PSP
right
and
that's
really
nice,
just
in
the
sense
of.
If
you
look
at
all
the
admission
controllers
we
have
today,
they
don't
necessarily
record
what
they
did
and
why
they
did
it.
E
E
Some
people
have
been
concerned
that
we've
said
we're
going
to
get
rid
of
pod
security
policy,
one,
that's
not
a
final
decision
and
two
we
won't
get
rid
of
pod
security
policy
until
we
have
a
really
strong
alternative
and
a
good
migration
path
and
tooling
to
that
policy,
and
then
even
then
it
will
still
be
a
gradual
deprecation
policy
or
process
over
I.
Don't
know,
probably
around.
A
A
year
yeah
so
I
mean
if
we
wanted
to
put
like
some
numbers
on
it.
Let's
pretend
and
1/18
the
entire
sig
that
nothing,
but
this
and
we
somehow
managed
to
do
all
of
the
work
in
one
release.
That
would
mean
we
deprecate
PSPs
and
118
and
then
at
a
bare
minimum,
probably
like
121.
We
removed
them
right,
so
that
is
like
it
would
be.
Insanity
there's
no.
E
B
B
Hopefully
everybody
so
I
service
accounts
since
before
when
Neto,
they
have
a
feature
where
we
have
a
controller
that
generates
token
shoves,
that
in
a
secret,
along
with
the
see
a
sort
of
the
cluster,
usually,
but
not
always-
and
we
just
plumbed
that
down
to
every
single
pod
in
the
client
levers
for
no
in
in
the
Clank
levers
for
Clank
go
and
actually
most
others.
There's
a
zero
config
client
functionality
called
in
cluster
config
I
call
that
function.
You
get
a
cube
client.
B
Delete
a
delete
the
token
secret
make
sure
that
the
that
the
token
controller
regenerates
it
to
a
rolling
update
of
all
your
pods
try
to
make
sure
that
all
these
things
line
up,
I
think
there's
like
in
somewhere
in
the
documentation
site,
even
documentation.
It's
an
issue
somewhere,
there's
an
eight
step
process
on
how
to
actually
rotate
service
account
that
circuit
surface
got
sign
keys
and
a
third
thing
is
on
this
list.
Is
there
was
no
audience
binding,
so
we
started.
We
originally
intended
these
tokens
to
be
used
only
against
the
Grenadiers
api
server.
B
That
was
the
whole
reason
for
adding
them.
We
never
documented
that
they
were
that
they
were
of
any
structure.
However,
they
are
shots.
So
if
you
want,
if
you
wanted
to,
you,
could
look
into
them
and
see
what
service
kind
it
is
da
legit
than
yourself
using
the
signing
key
or
the
verification
key
of
the
surface
counter
issuer
and
that's
what
people
did
so
they
took
that
token
and
they
started
handing
it
to
voltar
and
other
things
to
build
to
build
cool
features.
G
A
It's
like
our
third
bullet.
The
performance
thing
is
anyone
here
familiar
with
the
concept
of
chunking,
as
it
applies
to
the
kubernetes
api.
It
is
effectively
you
can
do
a
list
of
some
resource
and
you
can
ask
for
it
to
be
returned
in
some
chunks
instead
of
the
entire
list,
as
once
so
clayton
added
this
feature,
because
an
open
shift,
we
had
so
many
secrets
from
service
accounts
that
if
you
did
a
list
of
all
secrets
across
the
cluster,
you
basically
crashed
density.
A
So
when
you
get
back
like
5
gigabytes
of
secrets
data,
you
realize
it
doesn't
work
and
as
a
band
age,
we
said
all
right
well
chunk
it
so
at
least
it
works,
but
in
a
future
that,
hopefully
not
too
far,
we
won't
need
to
worry
about
that
because
we
won't
be
storing
them
in
density.
To
begin
with,
yeah.
B
So
what
did
we
do
about
it?
We
created
a
new
type
of
service
count
again.
We
don't
really
know
what
to
call
it.
Some
people
call
it
the
bound
service
account
again.
I
wanted
to
just
call
it
a
service
count
again,
but
we
haven't
migrated
everything
over
yet
the
improvements
we
made
are
we
they,
it
has
its
own
volume
projection
type.
So
it's
not
backed
by
a
secret
which
some
people
have
rightfully
criticized
is
as
not
being
a
very
secret
kubernetes
secrets.
B
There's
a
flexible
verification
of
these
tokens
using
the
token
review
API
so
like
we
mentioned
earlier,
there's
audience
binding.
So
you
could
get
a
token
where
that's
bound
to
the
audience
of
the
vault
or
the
sto
Citadel
CA
component,
and
when
vaulter
sto
receives
that
token,
they
can
issue
a
token
review.
I
specified
what
I
didn't
say,
identify
us
and
get
back
an
authenticated
user
info.
B
There
there's
also
I,
don't
know
if
we've
actually
added
this
to
the
cap
yet,
but
I
think
we
are
going
to
document
that
these
are
shots.
So
if,
in
some
situations,
the
token
review
is
not
compatible
with
how
these
tokens
need
to
be
authenticated,
we're
actually
gonna
document
that
these
are
jots.
Were
we
just
merged
a
cap
to
expose
issuer
discovery.
Information
about
these
tokens
that
allow
non-interactive,
authentic,
non
interactive,
token
validation,
again
they're,
never
stored
in
at
CD,
and
so
one
thing
that
makes
secrets
not
very
secret
is
that
they
are
world
readable.
B
So
we
fixed
that
which
has
caused
a
number
of
issues
that
I
have
a
slide
on
later.
The
other
thing
is
secrets:
were
our
support
injection
into
environment
variables,
and
if
you,
that
is
not
generally
a
very
good
idea,
because
environment
variables
are
broadly
readable
by
other
processes
on
the
same
machine,
so
we
turned
off
that
feature.
So
there's
a
chunk
of
like
my
new
breaking
changes
that
has
made
this
new
awesome
service
account
took
in
extremely
difficult
to
roll
out,
so
we
have
not.
B
We
have
a
novel
feature
and
if
you
turn
it
on
your
close,
probably
breaks,
but
we
are
trying
to
figure
out
what's
going
to
we're
just
going
to
take
to
roll
this
out,
I
think
there's
potentially
features
that
we
could
add
to
kubernetes
such
as
volume
ownership.
So,
instead
of
right
now,
all
those
all
the
projected
files
from
projected
volumes
are
owned
by
the
root
user.
B
I
think
there's
potentially
a
way
that
we
could
shown
those
to
the
user
of
the
of
the
container,
but
that
actually
requires
a
substantial
refactoring
of
how
about
cubelets
manage
volumes,
because
volumes
are
currently
shared
between
all
containers
in
a
pod
and
containers
can
sub
can
run
as
different
users.
So
that
was
one
of
the
issues.
The
other
issue
is
that
all
client
libraries
read
the
token
once
and
never
again,
and
these
tokens
now
expire.
B
A
So
now
I
can't
remember
the
exact
specifics
of
what
Jordan
said,
but
we
could
much
you
could
in
theory,
have
metrics
that
are
based
on
if
you're,
if
you
have
a
service
account
token,
that
is
one
of
these
style
that's
being
used
for
longer
than
an
hour
by
a
pod,
because
that
innately
tells
you
that
that
pod
is
not
reloading
tokens
right.
So
you
could
assign
a
lifetime
to
these
tokens
at
a
significantly
greater.
Like
you
know,
you
can
make
it
10
years
or
whatever,
so
it's
never
going
to
expire
during
the
pods
lifetime.
A
B
Yeah
and
I
think
there
is
a
another
approach
which
is
to
what
what
is
that?
Oh,
okay,
so
I
I
think
that
there's
another
approach
to
this.
There
are
really
great
improvements
that
these
tokens
make,
but
they're
not
useful.
If
we
can't
roll
them
out
that
it
is
put
a
potential
solution
that
we
can,
we
concede
on
some
of
the
hard
lines
that
we
were
trying
to
make
take
on
these
new
tokens.
So
this
is
kind
of
a
work
in
progress
right
now
and
we
don't
have
good
answers
yet
question
yeah.
K
B
Oh
sorry,
what
secret
suicide
driver,
so
there
I
think
there's
a
really
nifty
integration.
We
say
it
was
something
like
that
where,
as
a
secret
driver
such
as
the
one
that
certain
manager
uses
or
the
day
slabs
one
could
could
use
a
service
account
token
to
gain
access
to
a
system
like
vault
so
or
request
aid
certificate
from
the
kubernetes
certificates
API.
So
we
want
to
build
use
these
tokens
as
a
way
of
building
integrations
with
systems
that
are
better
at
handling
secrets
and
then
kubernetes
is
yeah.
A
I
think
we
want
to
be
careful
not
to
reinvent
Walt,
directly
embedded
inside
of
kubernetes.
We
want
to
instead
make
the
path
of
using
vault,
very
clear
and
very
sort
of
supported,
like
I
know
like
when
you
start
with
vault.
It
would
like
to
use
a
service
account
token
as
like
the
foundation
of
it,
and
it's
like
you
know
whether
these
long-lived
hard
to
revoke
tokens,
and
it's
not
what
we
want.
That's
it
there's
a
question
behind
you.
Michael.
B
L
B
So
right
now
that
lifetime
is
requested
as
part
of
the
pod
spec.
There
is
a
like
a
soft
max
that
can
be
set
on
the
API
server,
such
that,
if
you've,
a
user
requests
more
than
what
an
operator
would
allow
that
the
tgl
gets
pushed
down.
You
could
conceivably
set
that
up
to
be
a
year
or
something
and
kind
of
maintain
the
old
flows
of
create
a
service
create
a
service
account,
wait
for
the
spirit
to
be
created,
download
that
secret.
Your
jenkins
script.
L
I
mean
in
this
case
it's
like
breezing
as
you're
DevOps,
and
it
has
a
service
connection
in
that
given
project
so
as
part
of
the
pipeline
when
it
goes
to
a
deploy-
or
you
know,
query
using
like
cube,
cube
cuddle,
it
uses
the
service
connection,
which
was
based
on
a
static
secret
that
was
bound
to
that
connection,
so
I
think
long
term.
We
would
rather
have
you
know
some
kind
of
trust
established.
L
B
M
B
B
A
E
B
E
Be
the
one
thing
to
add
is
if,
if
you
have
a
privileged
pod
or
any
sort
of
attacker
who's
managed
to
escalate
to
running
as
root
on
the
node,
they
have
access
to
the
union
of
all
of
the
service
accounts
and,
by
extension,
all
of
the
permissions
of
all
of
the
service
accounts
running
on
the
node.
So
that's
everything
running
in
the
pod.
That's
the
cubelet
I
need
daemon.
Sets
that
you
run
that's
all
part
of
the
nodes
set
of
permissions.
A
But
like
if
you
were
running
something
like
cert
Manager
or
anything
that
can
list
all
secrets
right,
you
could
list
it.
If
you
got
access
that
you
can
list
all
secrets
that
allows
you
to
list
the
secrets
for
all
of
the
other
service
accounts
in
the
entire
cluster
and
if
any
one
of
them
is
given
cluster
admin.
What
you've
won
and.
B
B
The
cubelet
is
also
responsible
for
periodically
reissuing
that
token
or
making
sure
that
it's
up
to
date.
However,
this
is
all
exposed
via
a
volume
projection,
which
is
just
a
volume
type.
So
really
all
you
have
to
think
about
is
reading
that
token
from
disk
and
sending
it
to
whoever
once
to
know
who
you
are
I.
L
A
Yeah
so
they're
fully
ephemeral,
they're
signed
or
they're
created
on
the
fly.
When
you
do
a
token
request,
if
you
were
to
do
it
manually,
the
cubelet
is
doing
it
on
your
behalf
and
based
on
the
metadata
contained
within
them.
They
can
be
bound
to
other
objects
like
pods
as
live
as
we
mentioned,
and
sort
of
revoking
them
can
be
broken.
The
other
objects,
so
you
don't
actually
have
to
store
them
anymore,
and
ideally
they
last
for
like
an
hour,
so
you
don't
need
to
rock
them
at.
B
All
so
a
week
that
we
create
them
in
the
API
server
and
we
forget
about
them
and
we
can
I
Rivera
fie
them
by
using
the
signature
of
the
token
so
that
each
token
has
a
payload
which
says
it's
this
pod.
It's
a
service
count
and
then
there's
a
signature
associated
with
the
token
issuers
signing
key
so
that.
L
J
J
F
D
B
B
Incompatible
with
the
old
secret
version
of
service,
Kentuckians
and
I-
guess
pretty
one
eleven,
that's
not
really
too
big
of
an
issue
anymore,
because
we're
not
running
those
big
version
skews.
We
don't
support
those
big
version
skis,
but
we
are
yeah.
We
have
some
stuff
to
work
through
before
we
turned
on
and
as.
A
A
question
of
trivia:
can
anyone
tell
me
why
the
API
server
needs
a
new
flag
for
this?
You
know,
I
would
see
that
you
don't
count.
Why
mo,
because
traditionally,
these
secret
based
service
accounts,
those
were
managed
by
the
controller
manager,
so
the
signing
key
was
only
needed
on
the
controller
manager.
Now
that
you
have
the
token
request,
API
the
signing
key
or
a
signing
key
has
to
be
present
with
the
API
server.
So
there's
another
one.
Yes,.
B
H
B
Currently,
the
authentication
plugins
stack,
so
this
one
is
specifically
for
in
cluster
services.
We,
if
we
see
a
job
that
has
a
different
issuer
like
accounts.google.com.
We
won't
actually
enter
this
authorization,
authorization,
authentication
plugin.
So
we
checked
that
issuer
URL
see
that
it's,
they
sure
galle
matches
our
token
issuer
and
then
enter
that
so
I,
don't
think
that
they
are
would
conflict,
but
I
would
not
recommend
using
this
for
more
than
just
a
just
service
identity
within
the
cluster.
Although
many
people
are
so.
D
B
And
there
are
things
that
are
unsolved,
even
with
awesome
tokens,
so
there
forwardable
you
send
them
in
a
bearer,
ization
header.
That
means
that
they
can
be
replayed.
This
is
mitigated
by
that
audience
field
that
we
added.
However,
if
you
have
a
micro
service
architecture,
you
may
be
talking
to
10
or
hundred
different
services
and
managing
all
tokens
with
least
audience
scope
is
a
significant
hassle.
B
B
While
I
see
these
tokens
as
a
great
way
to
bootstrap
higher-level
identity
systems
such
as
like
the
day
slabs
example
and
the
as
the
secret
driver
example
in
the
cert
manager
example,
I
think
that
the
direction
force
server-to-server
authentication
is
in
mutual
TLS.
So
we
want
to
make
sure
we
want
to
make
sure
that
we
can
support
provisioning
of
higher-level
identity
systems.
I
think
that's
where
these
tokens
are
valuable.
A
C
A
C
J
K
F
B
Have
I
think
there's
an
issue
about
this
too.
I
setting
up
like
I
redid
it
api's
and
web
validating
your
mission
web
hooks
is
way
too
hard.
We
should
hat.
We
should
be
able
to
provision
certificates
for
a
server
and
client.
Tell
us
to
pods
is
my
opinion
and
I
think
it
would
streamline
and
make
a
lot
make
admission.
Web
hook,
configurations
portable
to
be
able
to
say,
uses
a
clusters
root,
CA,
don't
embed
that
giant
per
cluster
assert
in
there
and
automatically
provision
a
serving
certificate
for
a
web
hook.
We
want
to.