►
From YouTube: SIG Auth Bi-Weekly Meeting 20200805
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
Hi
everyone
today
is
the
august
5th
2020
bi-weekly
meeting
of
sig
auth.
It
looks
like
we
have
kind
of
a
light
agenda.
Can
everybody
see
my
screen.
A
B
Yeah,
so
this
has
come
up
a
handful
of
times
over
the
last
few
years,
the
idea
of
building
a
label
policy
into
kubernetes
there's
even
a
proposal
that
got
merged
into
the
old
community
proposals
folder.
B
So
the
other.
I
guess
that's
one
one
piece
of
context
on
this.
The
other
piece
of
context
is
that,
more
recently,
we've
been
talking
about
pushing
a
lot
of
policy
out
to
web
hooks.
So
things
like
scheduling
policy,
we
were
decided
that
we
didn't
really
want
to
build
that
in
as
a
core
feature
of
kubernetes,
and
we've
also
been
talking
about
the
future
of
pod
security
policy
and
maybe
moving
that
out
to
a
web
hook.
B
But
I
actually
think-
and
I
just
kind
of
wanted
to
float
this
idea
here-
this
isn't
this
isn't
at
the
kept
stage
or
anything
like
that,
but
I
think
that
label
policy
might
be
one
of
the
few
places
where
it
really
makes
sense
to
build
the
policy
controls
into
core
kubernetes,
and
the
main
reason
for
that
is
that
labels
are
a
really
useful
way
of
keying
other
policy
decisions.
B
So
if
you
want
to
create
a
policy
that
doesn't
apply
only
at
the
namespace
level
or,
for
instance,
policies
on
cluster
scoped
objects,
then
labels
are
a
useful
way
of
doing
that.
But
you
can't
really.
You
can't
depend
on
labels
for
policy
enforcement
unless
you
have
some
way
of
protecting
those
labels
themselves,
and
so
this
is
one
area
where,
if
we
had
some
sort
of
built-in
mechanism
for
protecting
or
restricting
label
access
or
even
requiring
certain
labels,
then
we
might
be
able
to
better
better
apply
policies
outside
of
just
labels.
B
Another
reason
that
I
think
label
policy
makes
sense
to
build
in
is
that
essentially,
every
object
has
labels
on
them,
so
this
isn't
something
specific
to
one
resource
type.
This
is
something
that
would
be
universal
across
all
resources
and
for
something
like
a
gatekeeper.
This
is
a
common.
B
So
that's
another
reason
for
label
policy.
The
last
one
is
sort
of
an
idea-
that's
still
baking,
but
I've
kicked
around
some
ideas
with
a
few
folks
around
having
some
sort
of
label
delegation
mechanism.
B
So
we
have
this
problem
where,
if
I
want
to
say
that
tim
isn't
allowed
to
create
this
label
on
this
on
pods,
then
the
problem
is
that
I'm
actually
going
to
create
deployment,
and
then
the
deployment
controller
creates
the
replica
set
and
the
replica
set
controller
creates
the
pod,
and
so
there's
this
idea.
We've
kind
of
talked
about
a
little
bit
around
some
way
of
sort
of
chaining
the
labels
down,
so
that
a
controller
can
delegate
that
label
decision
to
the
owning
object.
B
Yeah
I
do.
I
do
have
a
doc
that
kind
of
goes
into
that
proposal.
A
little
more
I've
been
talking
with
gurleen,
I
don't
know
she's
on
the
call,
but
she's
kind
of
working
on
putting
together
a
more
detailed
proposal
around
this,
but
I
did
want
to.
I
did
want
to
kind
of
float
this
idea
and
see
what
see
what
folks
think
about
it.
C
B
That's
a
bit
more
detailed
than
I've
gotten
I
haven't.
I
don't
have
a
clear
picture
of
what
the
shape
of
this
policy
should
look
like
like.
Do
we
want
to
have
label
defaulting?
Do
we
want
to
have
required
labels?
I
think
restricted
labels
is
sort
of
the
minimum
of
what
I'd
be
looking
for.
A
Yeah,
so
I
think
that
kind
of
a
label
inheritance
would
be
generally
useful,
something
like
if
a
label
grants
permission.
A
Or
I
guess
d,
do
you,
I
guess,
do
you
see
these
labels
being
used
to
grant
more
privilege
or
allow
access
to
functionality,
or
do
you
think
they
would
generally
restrict
access
to
functionality,
or
do
you
think
both.
B
I
think
it
could
be
both.
It
would
depend
on
how
the
policy
is
set
up,
but
I
think,
with
the
restricted
labels,
the
the
kind
of
easiest
way
of
thinking
about
that
would
be
in
terms
of
granting
privilege.
B
So
maybe
I
have
a
policy
that
says
you
can't
run
privileged
pods
unless
they
have
the
label
privileged
on
them
and
then
have
some
other
mechanism
that
limits
access
to
the
privileged
label.
A
Yeah,
the
reason
why
I
ask
is,
if
they
restrict
permission
we
care
about
them
not
being
removed
in
sub
trees
and
if
they
grant
permission
we
care
about
them,
not
being
added
suffered
by
some
trusted
subject.
A
Is
it
could
all
policies
that
grant
permission
be
modeled
as
like
complement
policies
that
restrict
permission,
because
I
think
that
would
simplify
the
the
model
a
little
bit.
If
we
could
say
these
only
ever
restrict.
A
Yeah,
I
guess
what
I'm
trying
to
reason
about
what
this
policy
needs
to
control.
If
I'm
like
thinking
in
terms
of
like
a
se
linux
label,
I
want
that
label
to
be
propagated
to
if
I
label
a
process.
I
want
that
label
to
be
propagated
to
files
or
network
packets,
and
I
it
seems
like
that,
would
be
useful
from
maybe
label
a
namespace
propagate
that
to
objects.
A
I
get
a
little
fuzzy
on
how
we
propagate
that
from
objects
within
the
namespace
like
a
replica
set
to
pods,
because
those
aren't,
I
guess
I'm
not.
I
don't
think
of
that
about
that
sort
of
hierarchy,
but
I
think
what
the
outcome
is.
Is
you
start
to
kind
of
build
a
flexible
scope
to
apply
policy
that
isn't
attached
to
our
two-level
resource
hierarchy
that
we
have
right
now,
so.
C
I
was
going
to
say
we
have
examples
of
labels,
we
use
on
name
spaces
in
openshift
to
control
the
range
of
valid
uids
for
a
pod,
and
it's
not
that
they
so
much
restrict,
as
they
are
different
right.
You
have
problems
if
someone
can
say
like
no,
I
want
to
be
between
you
and
one
and
ten
right,
like
that's
bad,
in
the
same
sense
as
being
able
to
remove
the
restriction
for
you,
it's
at
all,
and
it's
not
a
complimentary
choice.
Right.
It's
a
range.
A
Right
that
that
makes
sense
that
makes
sense
too.
A
I
guess
the
traditional
example
is
top
secret,
confidential
and
unconfidential,
where
you
don't
want
somebody
acting
in
a
confidential
context,
to
write
an
object
in
the
unconfidential
context,
but
they
are
able
to
write
in
a
higher
security
context
like
top
secret.
A
So
if
we
don't
have
that
like
single
category
of
control
with
labels,
I
I
also
on
the
topic
of
delegation,
I'm
not
sure
if
I'm
not
sure,
if
I
I,
I
think
it
potentially
helps,
and
I
think
that
the
use
use
cases
for
something
like
this
outside
of
delegation
are
are
enough
to
justify
it.
But
I
don't-
maybe
I
don't
understand
can.
A
Can
you
explain,
maybe
in
a
little
bit
more
depth
of
how
you
would
see
this
used
to
implement
user
delegating
permission
to
a
controller
or
something.
B
Sure
so
one
idea
we've
talked
about
is
suppose
we
have
some
way
of
granting
permission.
B
So
this
would
be
something
that
would
happen
based
on
the
user
info
on
a
mutating
request.
The
controller
would
check
you,
know,
you're,
trying
to
add
or
change
this
label.
B
Do
you
have
permission
to
use
this
label,
and
so
that
would
be
on
the
initial
object,
so
say:
creating,
let's
just
go
with
replica
set,
because
it's
only
one
level,
so
I
create
a
replica
set.
The
controller
checks.
Do
I
have
permission
to
use
the
restricted
labels
on
that
replica
set
then,
when
the
replica
set
creates
the
pod,
it
sets
the
the
controller
owner
reference
which
there
can
only
be
one
of
on
the
pod.
B
B
B
A
B
Well,
the
auto
scaler
wouldn't
change
the
labels,
it
just
changes.
The.
B
B
Your
that
essentially
gets
permission
to
permission
to
run
arbitrary
code
under
this
restrictive
label.
A
C
C
Labels
aren't
known
during
authorization
time,
so
I
wrote
an
authorizer
long
ago
that
was
they
used
label
selected
policy
in
addition
to
other
back
resources,
but
the
only
way
to
make
it
work
was
to
wire
through
to
admission
as
well
and
that
required
extending
admission
to
gets
because
you
end
up
having
to
filter
the
results
that
you
got
right
because
you
don't
actually
know
the
labels
or
you're
doing
get
you
don't
know
a
label
until
you've
actually
got
the
object
and
there's
no
spot
to
intercept
that.
C
B
A
I
think
it's
convenient
that
you
only
have
to
force
this
in
mutating
requests,
which
kind
of
lends
itself
to
admission.
C
C
So
if
I
understood
it,
I
think
micah's
question
was
about
whether
he'd
be
able
to
use
this
to
inform
authorization
choices
as
opposed
to
just
controller
choices
right
like
if,
if
I
so
you're
saying,
yeah
labels
aren't
present
for
a
get.
But
if
I
don't,
if
I
try
to
get
pods
with
a
specific
label
set,
aren't
those
that
that
isn't
aren't
labels
at
that
point
known
or
is
that
not
known
to
authorizer.
C
A
Just
curious,
if
I'm
kind
of
reading
yours
and
tim's
mind
a
little
bit
the
ultimate
objective
of
having
labels
that
are
inherited
through
the
system
that
you
have
some
guarantees
around,
how
that
inheritance
happens.
A
Ultimately
that
produces
labels
on
objects
that
can
be
used
as
a
policy
attachment
point
tim
mentioned
earlier,
that,
like
the
gatekeeper
thing,
would
would
be
useful.
A
gatekeeper
policy
would
be
useful
apply
on
labels.
One
other
example
is
arvak,
as
you
mentioned.
D
C
B
No
go
ahead.
Cj.
D
I
was
just
gonna
say:
is
there
a
reason
why
we
want
to
tie
this
back
to
a
user
and
we
couldn't
instead
tie
it
to
a
namespace?
And
you
know
one
of
the
lessons
from
psp
was
that
it
was
super
hard
to
try
to
do
this
level
of
policy
tracing
back
to
the
creating
user.
D
And
you
know
I
don't
know-
maybe
we're
there
with
owner
ref
today
and
we
weren't
there
before,
but
is
it
just
that
name
spaces?
Aren't
that
it's
still
too
hard
to
do
stuff
across
multiple
namespaces
that
you,
you
have
users
that
want
to
carve
up
name
spaces
in
this
way.
B
B
I
think
the
bigger
win
is
the
ability
to
apply
it
to
cluster
scoped
objects,
which
we
don't
have
a
good
solution
for
today
we
don't
have,
I
don't
think,
there's
a
lot
of
policy
that
needs
to
be
applied
to
cluster
scoped
objects,
so
we've
sort
of
avoided
it.
B
D
Like
certain
admins
are
able
to
change,
I
don't
know
a
persistent
volume
in
one
way,
but
you
really
only
want
other
admins
to
be
able
to
label
a
persistent
volume.
Certainly.
A
I
mean
we
just
did
this
for
certificate
signing
requests
in
a
kind
of
built-in
ad
hoc
way,
where
specific
signers
have
authorization
to
assign
specific
csrs.
A
B
I
feel
like
there's,
probably
some
use
cases
around
crds
permission
to
manage
certain
crds
and
maybe
apply
some
policy
to
what
the
requirements
around
this
are
it's
a
it's
a
little
hard
to
kind
of
separate
this
from
policy
enforcement
and
authorization,
because,
if
we're
talking
about
authorization
like
who
has
permission
to
administer
the
or
manage
some
set
of
crds
or
some
set
of
cluster
scoped
objects,
then
you
can
just
have
explicit
rbac
rules
that
list
out
all
the
things
they're
allowed
to
work
on.
B
A
There
yeah,
I
think
in
general,
it
seems
sound.
We
already
have
a
proposal
merged
for
it.
I
have
not
looked
at
that
proposal
in
four
years,
but
I
think
what
I
would
be
looking
for.
If
I
were
to
review
another
one,
would
be
a
pretty
clear
inheritance
model.
A
I
think
owner
ref
is
one
example,
but
I'm
not
sure
how
that
works.
For
like
config
maps,
I
guess
it
could
work
for
config
maps.
I
have
would
have
questions
on
whether
it
follows
a
kind
of
namespace
hierarchy
if
labels
are
propagated
from
a
namespace
restricted
labels
are
propagated
from
a
namespace
and
the
owner.
A
Ref
I'd
want
to
understand
like
what
the
the
special
super
user
authorization
model
looks
like
for
either
removing
labels
at
a
specific
point
or
adding
labels
at
a
specific
point,
and
I'd
want
to
understand
how
this
would
be
used
in
policy.
A
So
what
what
the
user
story
would
be
for
our
back
gatekeeper
network
policy.
B
Those
are
all
good
questions.
Would
you
mind
adding
them
to
the
notes?
I
am
currently
logged
out
of
my
account
and
don't
have
access
to
the
agenda.
B
B
B
And
yeah
also
thinking
a
bit
about
as
david
put
it
the
bounds
of
the
proposal
when
it
comes
to
the
the
policy.
It's
not
so
much
the
delegation
piece
but
like
what
policy
is
actually
implied.
There's
some
questions
around
whether
it
would
be
mutating
or
just
validating
so
like
do.
We
want
any
sort
of
defaulting
or
required
labels,
or
is
it
just
restrictions
on
use?
B
E
E
E
E
How
do
I
know
who
has
access
to
what
and
why
was
it
allowed
to
do
that
thing
and
hopefully,
like
not
build
a
system
where
the
answer
is
so
impenetrable
that
it's
like
really
hard
to
figure
that
out.
E
B
I
agree
with
that.
Also.
You
reminded
me
of
one
of
the
use
cases
for
subdividing
namespaces,
which
is
maybe
I
want
to
enforce
this
policy
on
a
namespace,
but
then
some
controller
ends
up
getting
this
deployed
in
the
namespace.
That
needs
an
exception,
so
it
it
has
a
legitimate
use
case
for
violating
that
policy.
B
Maybe
they
go,
the
operators
go
through
the
appropriate
channels
to
get
approval
for
an
exception,
but
they
don't
necessarily
want
to
just
grant
a
blanket
exception
to
the
namespace
and
they
don't
want
to
require
that
the
controller
be
moved
into
a
separate
namespace
and
then
need
to
deal
with
cross
namespace
issues,
and
so
it
would
be
nice
to
be
able
to
put
say:
okay,
we're
gonna,
put
this
exception
label
on
this
object
that
ops
it
out
of
this
policy
enforcement.
C
I'm
still
probably
minus
one
on
trying
to
subdivide
namespaces.
In
that
way,
I
think
namespace
subdivision
has
proven
to
be
difficult
to
get
right
and
to
explain
to
anyone
in
a
usable
way
when
we've
tried
to
do
in
the
past
right,
you
think
about,
like
the
I
want
to
have
rules
around
who
can
mount,
which
secret
it
was
really
difficult
to
explain.
We've
ended
up
removing
the.
D
Feature
tim:
do
you
have
any
ideas
on
like
a
concrete
example
of
what
sort
of
operator
might
want
in
that
situation
just
to
make
it.
D
B
Yeah,
I
I
think
I'll
have
to
think
of
that
a
little
more.
It's
definitely
come
up
before,
but
it's
not
throwing
me
right
now.
B
One
thing
on
subdividing
namespaces,
maybe
the
hierarchical
namespace
controller
that
the
multi-tenancy
group
is
working
on-
will
address
some
of
those
use
cases,
but
I've
definitely
also
kind
of
blanking.
On
the
examples
right
now,
I've
I've
talked
to
teams
before
that
were
asking
you
know:
what's
the
what's
the
right
way
of
granting
elevated
permissions
to
this
thing
in
this
name,
space
and
my
sort
of
default
answer
well,
was
well
just
put
it
in
a
different
name
space.
Why
does
it
need
to
be
in
the
same
name,
space
and.
B
B
But
yeah
there
were
some
issues
with
like
well
what
if
this
thing
wants
to
manage
a
secret?
Yes,
you
can
kind
of
grant
the
rbac
permissions
to
manage
the
secret
and.
D
B
F
A
Awesome
that
was
a
very
interesting
discussion.
Thank
you.
Tim
shihong
found
service
account
token
volume
beta.
A
All
right
cool:
do
you
want
to
give
a
summary
of
what
you're
changing.
F
So
so,
basically,
we
try
to
graduate
this
feature
to
ga
to
beta
and
which
means
the
this
will
be.
This
feature
will
be
turned
on
by
default,
and
so
the
old
service
account
admission
controller.
Will
the
other
one
will
inject
the
the
security
based
service
can
open
into
a
pod.
F
F
So
so
there
are
so
in
this
update.
It
lists
some
migration
fractions
that
we
already
we
have
already
solved
in
the
notes
and
also
the
the
biggest
challenge
is,
but
for
the
existing
workloads
are
using.
The
oldest
secret
is
the
tokens
which
will
not
expire
with
this
new
one,
the
the
token,
by
default,
the
the
expiration
it's
16
minutes.
A
A
Would
we
turn
this
on
was
worn
after
or
would
we
say
to
turn
on
worn
after
in
a
release
note
or
something?
A
F
F
Yeah,
you
definitely
need
to
like
put
this
into
the
into
a
release.
Note
right,
the
I
I
think
I'll
bring
this
up
in
this
meeting
is
to
reason,
because
there
are.
This
is
a
big
change.
I
just
want
to
know
like.
Are
there
any
concerns
from
people
that,
with
this
feature,
turn
down
idea
for
it?.
A
Yeah,
I
think
this
is
one
of
the
scariest
things
we've
turned
on.
Probably
as
far
as
making
people
upset
jordan,
it
looks
like
you
reviewed
the
cup
already
yeah.
B
I
am
not
sure
what
we
want
to
do
about
the
born
after
aspect,
whether
we
want
to
default
it
on
or
off.
B
B
F
With
the
so
when
we
record
center
and
request
projection
into
ga,
those
facts
will
be
required
right.
We
just
allow
the
clusters,
with
with
the
token
request
and
token
request,
project
enabled
to
switch
over.
C
C
My
changes
aren't
gonna,
be
easy,
no
matter
what
we
do,
choosing
a
value
at
least
lets
me
know
that
I
failed.
B
The
worn
the
ability
to
warn
to
configure
the
api
server
to
warn
on
bound
token
expiration
is
in
119.
C
B
I
I'm
mostly
wondering
what
components
like
cube
atom
will
do,
so
they
are
an
installer,
but
they
don't
actually
have
knowledge
of
the
particular
workloads
running
in
their
cluster,
so
they're
an
installer
yeah
without
knowledge
of
the
particular
characteristics
of
the
deployment.
B
What's
on
top
of
the
deployment,
so
would
they
probably
opt
in
by
default
to
the
extended
expiration
and
describe
to
their
users
like
if
you
want
shorter,
here's,
how
you
can
get
shorter
and
in
the
meantime
like
this,
is
the
release
to
be
monitoring
your
workloads
for
these
metrics
and,
if
that's,
the
sort
of
thing
that
cube
adam
would
do.
Is
that
the
sort
of
thing
that
we
should
just
make
the
api
server
do
by
default?.
B
Like
have
a
enable
it
but
opt
in
to
the
enable
it,
but
with
the
extended
token
expiration
for
some
number
of
releases
and
say
like
this
is
on
by
default.
Now
it
won't
mess
up
your
workloads.
They'll
have
a
token
that's
good
for
a
year.
If
you
want
to
override
it,
here's
how
you
override
it
and
x
releases
down
the
road.
So
if
it
goes
to
beta
now,
and
then
we
get
x
releases
of
experience
with
it,
then
here's
when
we
plan
to
change
that
default
to
be
short,
lived.
B
That's
that's
one
possibility.
It
starts
getting
the
better
security
properties
without
breaking
workloads
and
automatically
gives
admins
the
monitoring
that
they
need.
B
A
Think
that
sounds
reasonable
to
me
and
in
that
phase,
where
we
are
defaulting
to
enabled
just
have
a
action
required
release,
note
every
release
and
be
noisy
about
it.
A
But
yeah,
even
more
and
after
assuming
we
haven't
subtly
broken
compatibility
in
some
way,
which
I
don't
think
we
have
at
this
point.
That's
that
is
an
improvement
from
what
we
currently
do
with
secrets.
B
I
think
we
leave
it
running
until
the
api
and
the
admission
injected
tokens
rga
and
then
we
we
can
start
thinking
about
how
we
want
to
phase
it
out.
But
I
see
that
as
a
separate,
separate
thing.
There
are
people
who
are
manually
creating
tokens.
B
So
if
you
create
a
secret
that
has
the
annotations
that
indicates
and
the
type
that
indicates
you
want
a
token.
The
token
controller
could
use
the
bound
token
api
to
mint
that
token
and
bind
it
to
that
secret
so
that
that
was
one
of
the
reasons
we
allowed
secrets
as
a
bound
object
in
addition
to
pods.
So
I
would
probably
think
about
like
the
time
frame
in
which
we
would
want
to
do
that
and
and
start
considering
how
to
do
that.
B
The
thing
that
worries
me,
the
most
is
that
there
are
people
who
are
not
actually
creating
secrets
with
the
annotations
to
indicate
they
want
a
token
they're,
just
waiting
for
a
secret
to
show
up.
We
don't
have
visibility
to
that
usage
and
I'm
pretty
confident
that
that
using
exists
where
someone
creates
a
service
account,
and
then
they
just
watch
for
secrets
to
wait
for
the
automatically
created
one
yep,
so
that
that
is
the
thing
that
I
think
we
need
to
be
the
loudest
about.
B
B
So
if
that's
what
we
want
them
to
do
long
term,
it
might
be
better
to
wait
until
that
down
token
api
is
ga,
and
then
we
can
tell
them
like
unconditionally
do
it
this
way,
it's
a
better
api
for
them
because
they
can
do
it
synchronously.
Instead
of
this,
like
weird
make
a
secret
with
annotation
and
then
wait
so
maybe
wait
till
the
token
api
is
ga
tell
them
to
switch
to
that,
and
then
some
number
of
releases
later
stop
the
automatic
secret
creation
and
only
satisfy
explicitly
created
secrets.
A
A
Jihan,
did
you
have
anything
else
you
wanted
to
bring
up
all
right.
Any
other
asks
from
I'm
sick.
F
I
think
the
plan
theater
sounds
pretty
reasonable,
enable
the
raptor.
A
A
Awesome
did
anybody
else
have
anything
we
have
five
minutes.