►
From YouTube: Sig-Auth Bi-Weekly Meeting for 20230802
Description
Sig-Auth Bi-Weekly Meeting for 20230802
A
B
Sure
it's
basically
okay
background
is
currently
it's
only
possible
to
use
this
bi-directional
propagation.
If
the
container
that
has
this
production
non
communication
volume
amount
is
privileged
when
in
actuality
the
privileged
container
is
not
required,
just
the
Swiss
admin
capability
would
be
enough
to
to
do
all
the
necessary
or
to
propagate
all
the
necessary
information.
B
And
the
topic
it's
put
up
is
basically
wood.
Changing
this
requirement
so
would
change
the
validation
to
allow
bilometer,
more
propagation
or
unprinted,
containers
that
have
this
applicability
change
anything
or
existing
users,
so
it
just
was
a
request
from
six
storage
and
Link
the
specific
command
that
requested
requested.
This.
C
Yeah
I
think
so.
For
me,
the
high
level
concern
was
just
how
like
how
are
people
using
this
today
and
like
what
are
the
assumptions
and
supportive
behaviors
they're
assuming
out
of
the
system,
the
strictness
of
the
validation
today
and
sort
of
the
very
precise
level
of
access
you
need
and
like
high
level
access.
B
To
be
perfectly
honest,
this
PR
wouldn't
be
a
perfect
solution
because,
for
example,
app
armor
needs
to
be
set
to
unconfined
anyway
for
privileged
containers.
It's
automatically
set
to
unconfined.
But
if
it's
a
system
capability
with
a
non-unfined
airport
profile,
then
it's
still
like
blocked
by
the
amount
unmount
binaries
do
not
have
the
required
permission
still.
D
Just
so
long
to
be
clear
that
I'm
understanding
the
level
of
conversation
we're
having
this
change
would
make
it
so
that
the
pot
itself
wouldn't
have
to
be
labeled
privileged,
but
the
actual
pod
security
admission
level
would
still
have
to
be
privileged
because
we
don't
allow
CIS
admin
capability
on
Baseline
pods.
Is
that
correct?
So
we're
talking
about
like
I,
already
have
the
ability
to
have
privilege
pause
in
this
namespace,
but
this
actual
pod
doesn't
need
to
be
privileged,
so
it
is
better
than
than
if
it
was
privileged.
Is
that
correct?
B
A
There
are
I
guess
trivial
escalations
with
privilege
that
may
be
less
trivial
with
this
admin,
but
I
would
not
draw
a
huge
distinction
between
the
two.
As
far
as
isolation
goes,
I
think,
with
you
know,
privilege
you
can
mount
Dev
SDA
to
get
to
the
host
file
system.
Maybe
you
can't
do
that
with
sysadmin,
but
you
can
do
all
sorts
of
Nefarious
things.
D
F
D
B
A
C
C
Making
sure
that
there
isn't
like
a
person
that
has
like
something
that
works
today,
and
then
we
suddenly
break
them
without
them.
Knowing
okay
like
like
this
will
just
happen
right
transparently,
right,
we
will
relax
validations
and
previous
things
that
were
not
possible
will
become
possible
without,
like
there's,
no
PSA
version
bump
or
anything
right
like
there's.
Nothing
like.
C
I
I
understand
I'm,
saying
that
the
that
event
at
least
makes
it
clear
that
something
changed,
whether
you
understand
the
change
or
not.
At
least
you
know,
there
is
a
change
right
here.
It
would
be
transparent.
I
just
want
to
make
sure
mostly
out
of
just
caution
like
I
I.
Don't
personally
have
anything
that's
going
to
get
messed
up
by
this
I.
Just
I,
just
don't
know
what
crazy
thing
people
have
done
with
this
thing.
So.
G
C
B
G
Yeah
this
is
maybe
a
little
bit
of
a
tangent,
but
when
we're
documenting
this
or
talking
about
this
feature
and
kind
of
like
just
in
general,
I
feel
like
we
needed
a
different
way
of
distinguishing
or
referring
to
privileged
containers
like
privileged
equals.
True
on
the
container
means
something
different
than
like
privileged
container
in
the
general
sense.
E
E
I've
been
watching
the
issues
from
the
security
audit
get
opened
and
trying
to
Route
those
to
relevant
cigs,
and
there
were
a
couple
that
seemed
like
they
belonged
to
us
too.
Evaluate
and
reply
to
I
will
say
the
most
recent
security
audit
had
a
higher
signal
to
noise
ratio
than
usual.
They
found
actually
several
pretty
significant
issues,
which
was
great
and
I
think
the
ones
that
were
like
specific
and
actionable
have
been
fixed
already.
E
There
were
several
recommendations
made
that
sort
of
fall
into
the
a
category
of
like
architectural
critique,
I
guess
rather
than
saying
like
this
is
a
bug
and
it
causes
this
vulnerability.
It
was
more
of
saying
this
design
is
difficult
to
understand,
or
you
know,
has
this
characteristic
in
practice,
and
so
I
wanted
to
surface
these,
and
maybe
talk
through
these
two
in
particular
and
sort
of
come
up
with
like
it's
our
response.
E
So
the
first
one
talking
about
additive
access
controls,
and
so
this
is
talking
about
how
the
chain
of
authorizers
works
together,
and
so
the
authorizers
are
intended
to
be
composable,
where
you've
got
a
list
of
them
and
if
any
of
the
authorizers
you've
set
up,
allow
the
request,
then
the
request
is
allowed
and
by
default,
if
an
authorizer
doesn't
allow
a
request,
it
just
sort
of
passes
on
control
to
the
rest
of
the
things
in
the
chain.
That
was
the
original
design.
E
A
few
years
ago,
we
added
the
ability
for
authorizers
to
hard
deny
a
request
and
short
circuit
continuing
down
the
author
authorizer
chain,
so
that
was
added
to
the
authorizer
interface.
The
only
authorizer
implementation
that
makes
use
of
that
denied
capability
is
the
web
hook.
One,
the
the
built-in
authorizers
are
back
and
node
and
ABAC,
and
everything
continue
to
just
say:
I,
don't
know
continue
on
if,
if
they
don't
have
a
rule
allowing
something
so
the
only
authorizer
implementation
that
will
hard
deny
in
short
circuit
is
the
web
hook.
E
D
E
H
C
I
think
a
similar
related
point
there
is
that
deny
requires
you
to
think
of
ordering
in
a
very
like
precise
way
and
today,
especially
since
we
don't
have
the
multiple
like
authorizations
authorization
web
hooks
cap.
Yet
the
ordering
is
just
basically
that
list
of
authorizers
and
as
Jordan
mentioned
only
the
web
hook,
one
can
deny
select.
Your
denial
point
is
very
specific
and
that's
like
the
only
place
it
exists.
D
C
G
A
E
One
of
the
use
cases
was
like
a
pretty
a
pretty
targeted,
webhook
authorizer
at
the
beginning
of
the
chain,
which
you
expected
to
like
short
circuit
and
deny
like
particular
things
that
was
very
scoped
and
sort
of
happened
before
the
rest
of
the
chain
and
then
the
rest
of
the
authorizers,
node
and
rbac,
and
maybe
some
external
I
am
authorizer
type
thing
just
sort
of
working
as
they
do
today,
where
it's.
If
any,
allow
you're
allowed.
E
E
F
I
mean
so
we
know
that
nodes
should
only
be
acquiring
their
permissions,
ideally
via
the
node
authorizer,
so
it
would
be
possible
to
give
the
node
authorizer
some
sort
of
Turbo
deny
that
is
like,
and
it's
like
an
internal
thing.
It's
not
done
via
web
hook.
So
it's
not
like
necessarily
service
to
users
that
they
would
have
access
to
a
turbo
deny
from
the
node
authorizer.
G
E
There's
ways
to
mix
it
right,
like
you
pick
up
the
node
credentials
and
you
get
all
your
right
permissions
via
that,
so
you're
bounded
and
protected,
and
then
you
have
some
Central
config
map
that
has
stuff-
and
you
say,
like
any
node
can
read
this:
there's
nothing
confidential
in
it.
You
can
read
it
so
they're,
counting
on
like
reading
this
sort
of
public
can
big
map
from
an
R
background,
but
then,
like
all
the
transitive
pod
and
secret
and
config
map
and
read,
write
permissions
they're
expecting
to
get
via
the
node
relationships.
F
C
H
C
I
answered
this
specific
use
case
pretty
well,
because
I
remembered
this
from
openshift
online,
where
we
didn't
we,
let
people
use
a
single
namespace
and
they
were
allowed
to
do
whatever
they
wanted
within
a
tight
Circle
in
that
namespace.
But
one
of
the
things
they
weren't
allowed
to
do
or
was
to
Grant
a
different
user
of
that
multi-tenant
cluster
access
to
their
own
namespace
in
any
way
or
they
weren't
allowed
to
share
name
sources.
C
C
Yeah,
it
prevented
you
from
making
the
role
binding
in
the
first
place
and
thus
expanding
the
axis.
What
this
person,
I
think
is
basically
saying
is
say:
I
have
a
policy
like
a
in
the
general
sense
at
the
global
level
that
says
that
thou
shalt
not
do
these
things
in
these
environments.
Right,
like
you,
know
like,
for
example,
in
the
Azure
environments,
I
have
access
to
as
a
Microsoft
employee
I
am
not
allowed
to
expose
those
VMS
to
the
internet.
C
I
can
go,
try
really
hard
I'm,
like
full
admin
in
my
little
my
little
tenant,
but
the
Microsoft
policy
well
above
my
layer,
just
physically
prevents
me
from
doing
that.
Even
though
I'm
effectively
an
admin
in
my
little
box
right,
I
think
that's
what
they're.
Basically
talking
about
that
style
of
use
case
of
there's
certain
things
that
are
just
foundationally
disallowed,
because
they're,
inherently
bad,
but
the
people
are
operating
or
using
the
environment,
might
have
significant
access
to
it
because
of
their
job,
but
that
doesn't
mean
they
can
violate
the
policy
of
the
company.
A
E
E
E
It
basically
makes
it
impossible
to
create
authorization
for
someone
like
it.
If
I
have
a
web
Hook
and
the
node
authorizer
and
rbac
like
it,
I,
don't
think
we
would
ever
make
it
so
that
you
have
to
create
an
R
back
Rule
and
you
have
to
go
to
whatever's
back
in
your
web
hook
and
get
them
to
allow
something.
C
E
A
A
A
D
So
I
think,
where
it
gets
really
tricky,
is,
is
I
suspect
we
are
going
to
have
a
hierarchy
right
where
we
say
you
know
what
you
can't.
You
can't
ban
a
read
of
this
namespace
stop
being
cluster
admin
from
reading
the
thing
in
your
name
space,
that's
not
a
thing
we're
going
to
allow
and
that
gets
you
into
the
realm
of
well
now,
I
have
an
ordering.
This
allow
is
more
important
than
that
deny
which
is
more
important
than
other
allow,
which
gets
really
hairy
to
understand.
Yeah.
E
I
mean
talk
about
breaking
expectations
like
today.
We
don't
have
deny
rules,
so
we
say
it's
allow
only
and
if
you,
if
you
allow
it
in
our
back,
like
my
allow
isn't
going
to
interfere
with
your
allowance,
it's
additive
as
soon
as
you
say,
here's
a
deny
rule
if
I
created
an
eye
Rule
and
someone
gets
to
do
the
API
request
anyway,
it's
like
you,
you
lied
to
me
now
now
it's
a
security
bug.
D
F
D
We
were
to
allow
deny
rules
to
be
written
at
a
at
a
level
that
a
namespace
admin
or
a
cluster
admin
can
use.
I
would
expect
those
sorts
of
policies
to
proliferate,
while
the
ones
that
we,
as
the
people
who
run
the
Clusters
really
care
about,
are
the
webhook
ones.
I
wouldn't
expect
those
to
remain
in
the
majority.
Just
because
we're
going
to
have
what
order
of
five
rules
or
something,
and
we
will
see
dozens
per
cluster
once
we
turn
this
on
foreign.
E
Just
to
round
it
up
and
then
I'll
try
to
summarize
this
one,
the
last
one
was
consider
embedding
authentication
metadata
to
authorization
modes
enabling
increase
or
decrease
access
based
on
the
context
of
the
user.
So
all
the
information
from
the
authentication
layer
is
available
to
external
or
to
authenticators
are
back
in
node.
Don't
make
use
of
it
today,
but
webhooks
certainly
could.
C
C
E
E
The
so,
for
the
token
like
oidc
Authentication
today,
it's
a
pretty
simplistic
extraction
of
username
and
group
claims,
but
the
work
that's
in
progress
is
would
allow
you
to
add
another
extra
bit.
That
says
this
was
my.
You
know
this
was
a
token
authenticator
or
polls
from
some
other
claim
in
some
other
way.
So
you
could
populate
stuff
into
the
extra
information
in
the
user
info.
C
Yeah
so
like
one
of
the
obvious
things
is,
you
could
put
like
the
issuer
in
like
the
extra
field,
and
then
you
could
have
an
authorizer
that
looks
for
that
issuer
to
know.
Okay,
these
are
the
identities
coming
from
the
IDP
that
I
trust.
That
means
I
know.
I
can
go
look
up
the
user
in
some
database
I
can
do
some
extra
validations
and
you
you
can
tightly
couple
it
if
you
want
to.
A
A
C
I
mean
I
I.
Think
we,
if
we
wanted
to,
we
could
generically
on
all
authenticators
using
one
of
the
an
extra
key,
that's
scoped
to
the
kubernetes.
I
o
namespace
right.
We
could
include
stuff
like
oh,
was
this
the
like
assert-based,
auth
or
oidc
token
auth
or
whatever
we
can
include
some
generic
ones.
If
we
felt
like
that
was
a
thing
that
you
were
supposed
to
be
able
to
validate
against
always.
A
C
E
C
As
just
aside
once,
we
kind
of
resolve
these
it'd
be
nice
to
actually
close
them,
because
I
feel
like
there's
a
bunch
of
open
stuff
from
like
I.
Don't
know
how,
many
years
ago,
from
the
older
audits
that,
like
I,
don't
think
we're
ever
going
to
address
for
similar
reasons,
it's
not
really
great
to
have
it
just
sitting
around
and
Tim
I
see
your
hand
up.
Did
you
want
to
go.
G
C
But
like
with
admission
like,
let's
ignoring
the
read
issue
altogether
for
a
second
like
admission
on
rights,
even
with
the
sell
admission
policy
stuff
doesn't
prevent
like
a
cluster
admin
from
just
deleting
the
policy
right
and
then
doing
whatever
right.
So
you
can't
use
it
for
like
an
organizational
level
in
force
policy
right.
C
E
E
And
so
you
end
up
some
policies
to
accomplish
what
you
want
have
to
be
sort
of
split
between
authorization
and
admission
layers.
The
node
authorizer
and
the
Restriction
admission
is
a
good
example,
and
so
I'm
not
actually
really
sure
what
this
is
asking
for.
It's
kind
of
pointing
out
this
difficulty
object
validation
formats
within
rbac
policies
for
objects.
So
it's
is
wanting
our
back
authorization
to
apply
to
object
contents,
which.
D
Tim,
so
is
that
actually,
though,
a
desire
for
implementation
or
a
desire
for
cluster
admin
expression,
so
I
can
definitely
look
and
say:
I,
don't
have
appetite
for
changing
the
actual
authorization
mechanisms
themselves,
but
to
say
I
want
to
have
a
way
to
express
an
intent
that
spans
both
authorization
and
admission
I.
Don't
see
that
as
immediately
bad.
A
Yeah
I
was
going
to
say
something
similar.
It's
like
what
this
could
be
modeled,
as
in
our
back
policy
or
I,
guess
a
binding
to
a
policy
that
carries
an
obligation
that
can
be
fulfilled
by
an
admission
controller
or
something
else.
So
the
obligation
would
be
you
or
I
guess
you
have
update,
but
it
needs
to
validate,
go
through
this
admission,
validation
and
then
you
can
remove
the
obligation
and
then
the
access
is
approved
or
I.
Guess
for
a
read
it
might
be.
E
I
without
but
yes,
you
could
write
an
admission
Plug-In
or
you
could
write
a
cell
admission
check
that
made
an
authorization
call
which
you
could
then
authorize
with
our
back
objects.
But
that
doesn't
seem
to
address
the
fundamental
issue
that
you
still
have
to
have
an
admission
piece
and
an
authorization
piece.
E
D
You
just
saying
you
fear
a
case
where
a
policy
is
written
that
requires
both
authorization
and
admission
and
someone
has
disabled
the
admission,
because
otherwise
I'm
really
I'm
not
seeing
the
difficulty
right
like
we
can
write
the
admission.
We
know
how
to
do
that.
We
can
write
the
authorizer.
We
know
how
to
do
that
and
you
pass
the
authorizer
and
then
tighter
enforcement
happens
at
admission
time.
We
do
this
already
for
rights.
E
D
C
B
C
I'll
go
like
and
I
see,
Tim
mentioned
it
in
the
chat
too.
To
me,
the
closest
distinction
I
can
think
of
for
this
particular
issue
is
the
fine
grade.
Fine
grained
autism
cap
that
Daniel
was
working
on
which
basically
made
the
authorization
checks
at
the
field
level
like
an
ambient
capability
of
the
system.
C
E
Mean
the
example
the
example
Gap
they
give
here
is
you're
not
authorized
to
fetch
a
secret
directly,
but
you
are
authorized
to
write
a
pod
which
can
run
a
container
and
mounts
a
secret
which
you
can
read
inside
the
container
like
none
of
the
fine
Grand
authorization
stuff
or
the
validating
cell
admission.
Making
authorization
calls
none
of
that
addresses
something
that
says.
Oh,
you
can't
read
a
secret.
Therefore
you
can't
do
anything
that
could
possibly
let
you
worm
your
way
around
to
reading
a
secret
like
that.
Doesn't
help
that
example,
at
all.
C
G
This
is
why,
for
admission
stuff,
like
we've
always
said,
tie
it
to
the
namespace:
don't
try
and
subdivide
authorization
within
the
namespace
and
I
worried
that
if
we
tried
to
solve
something
like
this
in
the
authorization
layer,
we'd
run
into
those
same
problems
of
like
we
don't
have
a
good
way
of
delegating
authorization
to
controllers,
and
you
know
making
a
replica
set
or
something
is
different
from
creating
a
pod
it
comes
down
to
like.
We
need
to
tie
it
to
the
namespace
at
the
admission
level.
F
E
So
it
authorization
runs
at
the
runs
on
all
requests
that
hit
the
cube,
API
server,
even
ones
that
then
get
proxied
on
to
aggregated
servers.
So
authorization
happens
for
every
every
request
that
comes
to
the
API
server.
Admission
only
happens
for
write,
requests,
sure
but
write
requests
which
are
handled
by
that
server
and
they're
not
proxied
on.
So,
if
you
have
an
aggregated
server,
qbi
Server
doesn't
run
admission
on
those.
It's
counting
on
the
back
server
to
run
those.
E
A
F
C
C
So
there's
no
way
for
admission
to
tell
you
yeah,
you
can
do
this
thing
and
I
think
that's
one
of
my
biggest
complaints
about
admission
is
in
order
to
get
there
first,
you
must
allow
from
authorization
and
then
deny
admission
right.
So
first,
you
must
over
Grant
access
and
then
restrict
it
down
based
on
right
like
so,
you
can
create
pods,
but
not
privileged
pods,
like
the
way
that's
expressed
in
the
system.
Is
you
can
create
pods
and
then
I
make
sure
that
you
don't
do
anything
naughty
with
your
pods
right?
E
I'm,
not
sure
I
think
that's
really
a
valid
like
if
you're
giving
people
the
ability
to
execute
stuff
in
the
namespace
like
don't
give
people
the
ability
to
execute
stuff
in
a
namespace
who
you
don't
trust
with
the
stuff
in
that
namespace,
like
execution,
permissions
are
high.
Permissions
relative
to
the
API
read
access
to
the
API
object
is
not
name
skates.
That's
what
I'm
saying.
H
G
E
Okay,
I'll
try
to
summarize
some
of
the
discussion.
I
I
find
these
sort
of
architectural
critiques
difficult
to
know
how
to
respond
to
when,
in
some
ways
they
boil
down
to
like
I
wish
we'd
done
things
differently,
maybe
in
a
fundamental
way,
like
I'm,
not
sure
how
to
get
from
where
we
are
to
a
place.
That
makes
it
much
better.
E
Or
or
yeah,
or
in
a
way
like
would
another
layer
or
a
another
way
of
doing
things
that
keeps
everything
that
currently
Works
working
like?
Would
that
actually
help
this,
or
would
it
just
be
more
confusing
or
more
error
prone,
because
now
there's
another
way
that
sort
of
makes
you
think
that
it
can
restrict
things,
but
actually
it's
back
risk
compatible.
So
the
defaults
are
not
going
to
break
the
things
they're
currently
complaining
about
you
having
access
to
so.
C
So
now
what
I'm
imagining
is
the
kubernetes
book?
Is
this
thick
and
then
the
kubernetes?
The
good
parts
is
like
this,
dick
that's
what
I'm
imagining
right!
Now
we
got
three
minutes
we
can.
We
can
maybe
start
talking
about
that
last
one
real
fast
and
then
maybe
continue
next
time.
That
way,
it's
on
folks's
radar
to
think
about
for
two
weeks
and
complain
at
me
at
actually
I.
Don't
I,
don't
have
your
screen
share
up
in
my
do
you
have
it
open.
H
C
H
Think
yeah
this
this
cap
is
very,
very
briefly
put
together
itself
to
me,
so
I
do
apologize
for
basically
knocking
out
to
be
pulled
out.
The
the
general
use
case
that
we
had
here
is
needing
to
be
able
to
verify
basically
given
a
token,
like
a
projector
sales,
count
token,
with
a
specific
audience
being
able
to
verify
the
requester
of
that
token
so
like
which
you
know
specifically
requested
it,
and
the
reason
for
that
is.
H
We
have
trust
anchored
in
the
identity
by
the
cubelet's
identity
that
maybe
TPM
backed
or
something
like
that
and
being
able
to
do
that.
Cross-Referencing
from
the
requester
prevents
things
like
replay
attacks
outside
of
that
host,
so
being
able
to
take
the
projector
token
from
one
host,
move
it
to
another
and
Replay
that
so
as
it
stands,
the
current
solutions
that
we
have
without
this
change
would
be
to
do
like
a
get
Hobbs
in
the
node
name
and
then
do
some
constructions
in
there.
H
But
as
chatting
with
your
channel
as
well,
we
we're
talking
about
the
idea
of
embedding
a
username,
a
username
into
JWT.
That
happens
return
token
from
the
CPL,
which
also
goes
on,
and
it's
not
mentioned
to
talk
about
the
idea
of
embedding
the
uid
of
the
requester.
What
sorry
the
uid
over
the
token
correctness
into
those
tokens,
so
that
in
the
audit
log
we're
able
to
actually
record
that
as
well.
H
That
is
actually
in
order
to
supplement
the
fact
that
embedding
groups
into
the
token
would
cause
that
to
grow
quite
a
lot.
And
this
way
we
actually
still
get
that
you
know
full
traceability
through.
So
they
kind
of
two
separate
features
but
relating
because
the
uid
is
there
to
supplement
the
lack
of
embedding
groups
or
extra
user
info
into
those
tokens.
C
C
If
you
look
at
it
like
just
decode
it
right,
you
can
see
now
it
has
a
jti
client,
which
is
just
a
good
and
it
shows
who
the
user
was.
That
requested
this
token
originally,
which
in
case
was
the
cluster
admin
and
then,
when
I
try
to
use
the
who
am
I
API.
With
that
token,
you
can
see
what
that
looks
like
if
you
scroll
down
it'll,
have
some
extra
claims.
C
A
A
C
A
C
H
C
A
C
A
A
C
A
C
C
If
we
want
it
and
then
but
yeah
so
we're
way
over,
we
can
sort
of
continue
this,
maybe
next
time
but
yeah.
So
if
folks
have
like
specific
thoughts
and
feedback
games,
if
you
have
time
to
like
complete
your
needs
and
use
cases
into
the
cap,
then
you
know
we
have
some
good
understanding
of
like
where
everybody
stands,
but.