►
From YouTube: SIG-Auth Bi-Weekly Meeting for 20220302
Description
SIG-Auth Bi-Weekly Meeting for 20220302
A
All
right,
hey
everyone.
This
is
the
cigar
meeting
to
march
2nd
22..
We
have
a
pretty
light
agenda
today,
so
we
can
get
started
so
the
first
one,
let's
see,
I
think
in
this
year
on
the
call
with
me.
So
this
was
a
conversation
that
finished
myself,
rita
and
some
others
were
having
yesterday,
and
why
did
I
bring
it
up
again,
dude
this
larger
group
just
to
confirm
so
like
two?
A
You
know
building
a
new
format
and
the
overall
question
is,
I
think
we
would
like
to
encode
within
that
format.
What
encryption
is
being
used
just
so
it's
clear
and
explicit
how
the
system
was
set
up,
but
we
did
not
want
to
expose
any
configuration.
Instead,
we
would
use
aes
gcm,
and
that
would
just
be
how
the
system
works
and
expanded
the
configuration
and
other
things
later,
truly
necessary.
B
Even
if
it
was
just
like
a
name
field
for
now
or
something
that
is
like
equal
to
what
the
current
prefix
is,
that
would
allow
us
to
make
changes
more
easily
in
the
future.
I
don't
even
know.
If
so
I
guess
we
have
to
decide
whether
it
is
easier
to
do
two
things
at
once,
or
whether
it's
kind
of
the
same
amount
of
work,
and
if
it's
the
same
amount
of
work,
then
we
can
just.
We
don't
really
need
to
bundle
these
things
up
either.
A
A
So
I
right
now
we're
thinking
about
this
all
as
just
a
large
effort
to
just
basically
fix
the
problems
within
kms,
but
I
from
here
for
this
particular
thing.
I
just
wanted
to
make
sure
that
there
wasn't
some
actual
use
case
where
ascbc
was
preferred
and
someone
would
actually
ask
for
that
as
a
choice.
A
B
B
Well,
so
I
would
just
say:
don't
yeah
I
I
don't
want
to
like
over
complicate
it
if
we
can
make
the
incremental
progress
kind
of
like
we're
doing
for
the
ca
search
stuff.
So
this
seems
like
an
incremental
product
for
us.
We're
gonna
have
to
have
like
a
perfect
vision
for
the
future
before
we
get
started
so.
A
Yeah,
no,
I
mean
I'm
making
some
decent
progress
because,
like
anish,
myself,
rita
and
a
few
other
folks
meet
every
week,
just
kind
of
talk
and
just
kind
of
force,
just
a
meeting
forces
us
to
think
about
this
and
actually
try
to
do
something
instead
of
hand
waving
it.
So
that
that's
that's
helpful,
so
yeah.
I
think
we're
not
too
far
off
from
having
some
something
to
bring
back
to
this
group
and
get
feedback
and
see
what
folks
think.
B
A
Okay,
I
I
missed
the
last
cigar
meeting
did
by
any
chance
was
revocation
brought
up.
I
think
I
saw
you
mike
about.
I
would
like
a
web
book
like.
I
would
like
to
be
able
to
plumb
this
data
through
a
network
request,
which
is,
I
think,
totally
reasonable.
I
I
would
also
like
to
be
able
to
crl,
while
I'm
at
it.
A
A
C
Yeah,
so
this
was
just
I
just
wanted
to
bring
this
up
for
discussion
like
I
don't
have
it
kept.
I
literally
did
this
in
like
an
hour
yesterday
and
an
hour
today
to
just
like
play
with
this
idea,
but
yeah.
If
you
can
you
reload
that
page,
because
I
I
fixed
the
tabs
to
spaces
thing
for
that.
That
are
back
example.
The
the
basic
idea
here
is
that
there's
a
rvec
is
great,
but
there's
a
lot
of
things.
C
Like
pod,
update
or
node
update,
like
node,
patch
or
no
or
pod,
delete
right
and
the
the
agents
typically
only
need
access
to
like
the
node
object
that
they
run
on
or
a
shadow
object
like
the
csi
object,
but
not
a
one
injury
right,
and
so
I
like.
I
want
to
be
able
to
express
okay,
I
want
the
service
account
to
only
modify
itself
or
the
the
stuff,
the
node,
that
it
runs
on,
or
some
shadow
crd
of
the
the
node
that
it
runs
on
or
or
something
like
that.
C
C
So
this
way
you
can
see.
Okay,
if
it
again,
this
condition
is
dependent
on
there
being
a
node
name
in
the
in
the
user
extra
info,
but
that
would
allow
a
service
account
to
only
modify
or
patch
the
node
that
it
runs
on
and
this
so
this
kind
of
adds
a
back
to
our
back,
but
I
I
I
haven't
compiled
this.
I
haven't
like
tested
this.
C
This
is
more
just
like
a
an
example
that
I
just
wanted
to
try
and
see
if
I
could
play
around
with
in
the
last
like
12
hours,
so
I
I
kind
of
wanted
to
get
any
early
feedback
and
see
if
people
think
like
this
is
something
like
this
is
the
need
that
we
have,
because
I
I
feel
like
it
is.
I
feel,
like
I
see
this
problem
all
the
time
and
there's
not
a
great
answer
to
it,
but
I
I'd
love
to
hear
yeah
feedback
or
something
from
anyone
else.
C
A
C
Checked
the
agenda
before
lunch,
and
I
don't
think
this
was
on
it.
I
came
back
after
lunch,
and-
and
here
it
is,
I
have
I
have
some
very
raw
thoughts,
but
like
nothing,
I
wouldn't
want
to
be
able
to
to
think
about
and
come
back
with,
more
perhaps
sure
or
different
ones,
but
you
know
one
thought
that
occurs
to
me
is:
if
we
want
such
a
different
kind
of
of
authorizer,
why
marry
it
to
too
far
back
right,
like
this
is
notionally
different?
C
Would
it
actually
even
be
simpler
to
do
as
a
as
a
new
kind
of
authorizer?
Other
thoughts
would
be
things
like
a
not
equals
comparison
is,
is
something
that
worries
me
because
you
know
in
the
early
days
of
our
back,
there
were
a
lot
of
requests
for
for
that
feature
or
star
minus
as
as
something
they
wanted,
and
then
we
added
more
resources
and
if
we
had
had
that
they
would
have
broken.
A
C
I
guess,
while
we're
waiting
for
tim,
I
also
do
have
another
sort
of
mechanical
question
of
what
you
would
expect
this
to
do
on
creates.
I
often
see
cases
where
people
want
if
they
want
control
by
a
particular
name.
They
almost
always
also
want
control
on
creates
and
that
information
is
not
available
to
the
authorizer.
A
C
A
D
C
Other
people's
thoughts
but
sure
so
not
having
this
power
on
create.
I
I
would
say
that
this
looks
as
though
it
is
most
likely
going
to
be
used
for
someone
can
control
this
particular
instance
of
this
particular
thing,
but
I
don't
want
to
enumerate
every
single
one
of
them
independently,
and
I
would
expect
that
create
would
be
an
important
part
of
of
the
full
use
case,
but
I
I
I
didn't
even
click
to
see
if
there
was
a
full
use
case
listed
in
the
the
diff
yeah.
There's
no
use
case.
C
This
is
mostly
just
I
hadn't.
I
haven't
even
had
time
to
really
write
this
up.
I
can,
I
can
put
something
together
for
next
time,
but
mostly
just
kind
of
wanted
to
see
it.
I
know
that
this
has
been
a
problem
discussing
with
some
folks
and
kind
of
wanted
to
see
if
there
was
any
yeah
what
the
thinking
was.
So
this
is
helpful.
C
A
A
Yeah,
that's
right.
Service
account
does
extra
for
the
bound
fanciness
stuff,
but
yeah
other
than
that,
though,
like
for
a
for
for
humanish
actors,
I
guess
maybe
this
is.
Maybe
this
is
less
relevant
to
some
of
the
chapters.
It's
usually
a
token
book
yeah.
I
I
guess
my
question's
sort
of
still
the
same.
C
Why
not
well
web
hook?
Authorizer
sorry,
I
thought
you
said
webhook
admission.
Yes,
webhook
authorizer,
yes
yeah,
but
that's
that's.
I
think
that
the
my
initial
thinking
has
been
like
our
back
for
better
for.
Worse
is
what
everyone
thinks
of
when
they
think
of
coup.
It's
not
just
think
of,
but
used
for
kubernetes
authorization
so
requiring
a
webhook
authorizer
is
a
pretty
heavy
lift
for
a
lot
of
a
lot
of
a
lot
of
you
just
users
and
then
also
how
do
you
exp?
C
B
C
D
Yeah
my
my
view
on
a
like
potential
killer.
App
is
the
the
thing
that
I
think
tim
was
trying
to
say
and
number
two.
The
node
scope
demon
sets
which
is
like
there's
all
these
agents
running
around
that
want
to
run
something
on
a
node
and
want
to
update
something
on
a
node
and
the
way
you
do
that
today
is
you
give
yourself
permission
to
update
all
nodes.
D
Potentially-
and
I
think
there's
like
avenues
where,
if
this
really
caught
on
and
people
were
like-
oh
I
now-
I
want
to
be
able
to
mess
with
secrets
that
are
bound
to
this
node.
You
could,
you
know
populate
resource.
You
could
populate
the
available
conditions
on
a
resource
to
include
like
contents
of
the
node
graph.
C
C
Okay-
and
I
I
don't
know
that
I
think
the
goal
is
not
to
solve
every
case.
Probably
with
this.
I
think
it's
just
to
try
to
make
some
things
better,
which
certain
things
are
are
not
great,
like,
I
think,
there's
just
big
avenues.
I
see
big
avenues
for
lots
of
daemons
to
run
amok
with
too
many
permissions
that
are
cluster
scoped
and
easily.
Like
cross
note,
boundaries.
C
That
possible,
oh
yeah,
like
that,
I'm
not
saying
it
would
have
no
so
like
that
that
wouldn't
have
the
full
node
graph,
so
that
would
it
would
be
mostly
request
based.
So
what's
in
the
request
and
what's
in
the
identity
of
the
caller
so
and
by
the
request,
I
mean
like
the
things
that
are
accessible
to
the
authorizer,
so
you
know
api
schema
or
api.
Excuse
me,
api
version,
resource
type.
A
I
think
what
you're
saying,
though,
is
that
this
does
not
have
the
capabilities
of,
like
the
note,
authorized
or
plus
noted
right.
Those
things,
of
course,
both
a
very
specific
work,
authorization
level
semantic
using
the
graph,
and
then
they
certainly
extend
that,
with
updates
to
be
very
specific
on
objects.
A
With
the
admission
bit,
I
was
going
to
take
a
second
and
just
try
to
read
what
tim
wrote
in
chat,
which
was
first
thing
he
said
is
this
has
definitely
come
up
before
two
common
use
cases
I've
heard
of
are
granting
access
in
specific
time,
windows
or
granting
access.
If
the
request
is
coming
from
certain
ip
ranges,
the
clo
and
so
the
second
item
he
said
the
closed
cap
I
linked.
I
do
think
something
like
this
is
interesting
for
bounding
requests
to
a
specific
node
and
then
another
thought.
A
A
Okay,
I
I
don't
think
anyone
has
written
up
the
doc
or
kept
or
anything,
but
I
had
spoken
to
some
folks
about
the
the
issue
about
being
able
to
specify
more
than
one
web
hook,
authorizer
to
the
api
server
and
then
one
of
the
things
you
guys
like.
Are
you
asking
what
cell
is
yeah
common
expression,
language?
A
C
B
D
A
Yeah,
I
think
what
mike
is
trying
to
say
is
today
by
the
virtue
of
a
pod,
referencing
a
secret
and
then
being
scheduled
on
a
node.
The
node
authorizer
and
admission
plugins
together
allowed
that
partic
that
node
at
that
time
to
access
the
secret
so
that
it
can
mount
it
as
a
volume
within
the
pods
file
system.
A
Mike
is
saying:
wouldn't
it
be
great
if,
instead
of
that,
being
all
hard-coded
into
kubernetes,
if
there
was
a
way
to
express
this
within
the
api,
and
then
you
know
as
long
as
you
have
the
right,
you
know
validation,
checks
and
authorization
checks
of
the
various
places.
You
could
then
allow
arbitrary
extensions
of
this
type,
so
I
have
a
custom
resource
that
can
be
referenced
somehow
by
a
pod
and
thus,
by
that
pod
being
scheduled
on
a
particular
node.
A
B
A
D
C
C
C
C
If
people
wanted
to
use
it,
they
had
to
understand
a
new
field
on
a
type
that
they
weren't
expecting
changes
on
and
that
particular
one
ended
up
being
self,
not
self
mutating
but
mutating
well,
yeah
self
mutating
right.
You
describe
what
you
want
to
aggregate
and
it
almost
became
like
a
secondary
spec
and
status,
and
so
people
started
getting
modifications
to
to
resources.
They
didn't
expect
things
they.
C
A
Well,
they
are
it's
totally
there's
totally.
Definitely
I
mean
I'm
not
even
saying
anything
about
openshift
I've
seen
plenty
of
people
use
the
r
back
data
and
it's
expected
to
mean
a
thing
and
they
use
the
standard,
go
partials
and
stuff.
So
they'll
just
drop
these
new
random
condition
fields
and
have
no
idea
that
the
meaning
of
the
rvac
is
not
yes,.
C
B
C
D
C
A
Even
that
being
a
separate
object,
I
think
would
be
preferable
because
then
it
would
be
very
clear
that
this
new
binding
thing
is
conditional
instead
of
always,
and
that
would
also
prevent
the
whole,
like
you
interpret
it
wrong,
because
there's
no
way
you're
randomly
going
to
read
a
resource
that
you
have
no
idea
exists,
and
then
you
know
we
at
least
still
have
that
level
of
control
of
the
idea
of
what
permission
you
got
was
still
just
easily
correctly
expressed
by
a
cholesterol.
I
don't
know
if
it
is
or
not.
A
A
C
Yeah
no,
this
is
really
helpful.
I
think
I
I
had
some
thoughts
around
this
and
I
just
kind
of
wanted
to
I've
been
around
for
a
while,
but
I
just
wanted
to
hear
what
other
folks
thought
and
what
other
folks
were
thinking
about
direction
on
this.
So
so
it
sounds
like
you're,
a
secondary
type,
a
class
like
a
a
conditional
cluster
role
and
condition
or
set
of
types,
roll
roll,
binding
cluster
role,
cluster
role
bindings
with
the
same
almost
the
same
set
of
types,
but
with
these
conditions,
so
there's
not
confusion
about.
C
C
A
C
A
Yes,
good
switched
over
to
windows,
the
yeah,
so
the
approved
cap
and
the
thing
that's
implemented
in
alpha
is
for
crd
validation,
but
I
think
it
was
called
out
and
that
kept
as
a
possible
future
extension
to
add
kind
of
validating
and
even
mutating
admission
control.
Based
on
that,
I
think
there
might
be
a
draft
cap
shared
at
my
google
doc.
I
can
see
if
I
can
find
that
afterwards
and
send
it
your
way.
A
Yeah
I
mean
I
I'm
relatively
like
positive
on
this
stuff,
just
because
I
find
it,
it
is
a
hard
sell
to
say
that
hey,
if
you
want
to
validate
this
field
to
like
be
within
like
this
starts
with
x,
go
write
an
entire
website
to
do
that,
instead
of
like
two
lines
of
sale
or
actually,
I
think
it's
one
line
to
sell
so
or
at
least
the
simple
stuff
it's.
It
makes
a
lot
more
sense
to
just
encode
it
within
the
crd.
A
A
I
think
it
would
be
helpful
to
collect
a
list
of
use
cases
for
this,
because,
right
now
it
sounds
like
the
strongest
use
case.
We
have
is
node
scoped
authorization
and
if
that's
really
the
like
primary
use
case
for
this,
it
might
be
worth
considering
open
reopening
something
like
that
that
node
scoped.
A
B
C
A
B
B
So,
instead
of
hard
coding
how
we
extract
the
edges
to
the
node,
we
could
allow
that
extraction
to
be
programmed
dynamically
using
cell.
So
you
could
still
query
the
node
graph,
but
it
could
require
it
for
something
like
a
crd
instead
of
the
ac
grid.
Is
that
what
you
were
thinking
or
were
you
thinking?
Is
that
how
you
interpreted
what
it
said?
B
B
C
Yeah,
I'm
just
trying
to
think
of:
what's
the
user
gonna,
how
does
how
does
the
user,
interacting
with
the
api
reason
about
what
permissions
a
thing
has
so
like?
How
do
they
define
and
reason
about
that?
Like?
Do
they
say,
here's
my
yaml,
I'm
going
to
apply
it
like
just
like
they
do
our
back.
This
is
just
another
api
like
that
that
we're
talking
about
node
authorizer,
isn't
doesn't
have
an
api.
B
C
B
It
would
be
a
so
there
would
be
like
there
would
need
to
be
a
new
api
introduced
to
to
configure
that,
and
it
would
like
take
as
input
like
your
conditions,
but
the
conditions
would
be
used
there.
Maybe
it
wouldn't
even
be
a
condition
at
that
point.
It
would
take
in
cell,
like
the
validation
apis
do
and
the
cell
would
output
edges
and
vertices,
and
that's
what
the
node
authorizer
would
run
to
maintain
the
graph.
B
A
A
A
C
C
A
I
I
guess,
I'm
I'm
a
little
less
happy
about
the
idea
of
even
trying
to
pursue
temporal
stuff
because,
like
as
a
for
example,
if
if
I
can
right
now,
temporarily
do
a
thing
I
can
but-
and
let's
just
say,
I
have
like
admin
level
access
temporarily
to
a
namespace
right.
I
can
at
that
instant,
create
a
service
account
granted
admin
access
to
that
name.
A
No,
no,
I
understand
that
this
comes
as
a
request
that,
like
I
just
want
my
my
employees
to
only
be
doing
things
during
like
work
hours
and
it's
like
okay,
but
like
it's
going
to
be
best
effort
like
it's
not
actually
a
security
thing.
It's
mostly
just
like
preventing
accidents,
not
really
preventing
a
bad
actor
from
being
bad.
E
You
don't
even
need
like
custom
authenticators,
for
that
I
mean
that
their
entire
engines,
that
will
do
this
sort
of
temporal.
You
know
provision
the
user
into
a
group
when
they're
authorized
deprovision
them.
When
they're
done,
I
mean
it's
the
entire
privileged
access
model
system
that
most
enterprises
end
up
having
I,
I
don't
know
that
I
don't
even
know
that
that
to
most
point
that's
even
a
problem
that
could
be
effectively
solved
from
inside
of
kubernetes
yeah.
A
I
mean
if
you
had
a
simplistic
system
that
was
just
adding
and
removing
you
from
groups
that
gave
you
permissions
and
far
back
was
just
bound
to
those.
Well,
nothing
prevents
you
from
abusing
the
rights
at
the
time
that
you
had
them
and
pushing
them
into
a
different
actor
right,
because
our
back
itself
has
no
concept
of
time,
it's
just
in
the
sense
of
other
than
the
now.
If
you
are
allowed
to
do
this
thing
now-
and
you
know
that
happens
to
be,
it
happens
to
be
run
during
an
our
back
escalation
check.
A
A
A
Certainly
any
of
the
admission
stuff
is
already
available
right.
You
know
to
any
admission
web
hook
as
long
as
it's
basically
in
the
user
info
somewhere
or
admission
can
have
basically
everything.
So
it's
really
their
subject.
Access
review
bit,
but
I
neither
token
review
or
subject
access
review
in
their
response
include
anything
about
a
temporal
thing.
D
Yeah,
like
a
quick
knee-jerk
response
to
that
is,
you
could
just
return
a
condition.
You
could
extend
the
subject,
access
review
status
to
include
a
condition
or
you
could
just
say
no
for
anything
that
has
a
condition
that
you
can't
know
the
condition
kind
of
pushes
off
the
burden
to
say
hey
if
you
know
how
to
evaluate-
and
you
want
to
know
like
if
this
is
a
temporal
thing
or
if
this
is
a
request
characteristic
thing.
D
B
D
Yeah
for
sure
I
think
we
would
still
do
the
caching.
It
would
be
like
you're
getting
a
the
attributes.
You're
allowed
to
access
are,
you
know,
guaranteed
to
be
no
more
than
three
minutes
out
of
date
or
whatever,
but
like
you're,
not
necessarily
that's,
probably
too
long,
but
it
would
probably
be
the
same
caveats
as
the
note
authorizer,
but
it
would
just
be
like
you'd
be
presenting
the
node
graph
to
be
queryable
right.
Is
that
what
you're
talking
about
mike.
B
Today
we
could
build,
we
could
continue
to
build
yeah,
so
it
the
the
graph
access
could
still
be
cached
like
it
is
today,
but
I
think
it's
more
for,
like
especially
for
things
that
are
doing
delegated
authorization
yeah.
I
think
we're
talking
about
maybe
two
different,
we're
flipping
between
subjects
which
might
make
this
conversation
confusing.
D
I
think
the
caching
and
subject
access
review
questions
are
also
different,
because
caching
is
just
like
all
right.
If
we
evaluated
a
condition-
and
it
answered
true
five
minutes
ago-
is
that
okay
for
us
to
just
assume
still
holds
or
do
we
need
to
be
smarter
about
what
the
conditions
are
and
like
never
cache
a
temporal
condition.
A
We're
good
at
on-the-fly
discussions,
michael
apparently
thank
you,
yeah!
Let's,
let's
continue
this
next
time.
I
think
I
think,
there's
a
lot
of
interest.
You
know
yeah.
I.
I
suspect
that
when
there's
lots
of
interest,
I
think
folks
can
get
something
done
here.
So,
let's,
let's
keep
talking
yeah,
we'll
see
everyone
next
week
or
not
next
week
to
each
minute.