►
From YouTube: SIG-AUTH Bi-Weekly Meeting for 20220608
Description
SIG-AUTH Bi-Weekly Meeting for 20220608
A
All
right,
hello,
everyone
welcome
to
the
june
8th
2022
meeting
of
sig
auth.
Can
everybody
see
my
screen
and
hear
me.
A
Awesome
so
let's
get
started,
looks
like
we
can
hop
right
to
discussion
topics.
So
the
first
thing
on
the
agenda
is.
C
I
am
happy
to
introduce
the
topic
so
yeah.
This
was
from
a
mailing
list,
email
if
you
saw
that
so
actually
let
let
me
grab
a
link
to
the
qsp
migration
box.
C
So
this
is
a
guide
that
I
wrote
up
for.
Oh
yeah
thanks.
This
is
a
guide
that
I
wrote
up
for
migrating
from
pod
security
policies
to.
C
C
You
might
have
pods
straight
up
break
if
they're,
depending
on
those
default
values
being
set,
and
we
don't
have
a
good
way
of
detecting
this.
If
you
scroll
down
to,
let's
see,
eliminate
purely
mutating
fields,
2a,
it's
pretty
manual
process
that
basically
comes
down
to
look
at
your
pod
templates.
Look
at
your
pods
see
if
anything
changed
if
it
did,
go
and
fix
it,
and
so
something
that
sam
and
I
have
been
talking
about-
is
a
way
of
automating
this.
C
C
So
sam
ran
with
this
and
wrote
up
a
great
little
tool
to
help
automate
a
lot
of
this
with
that
sam.
Are
you
up
for
the
demo
or
do
you
want
me
to.
A
Yeah,
let
me
share
post
with
you
yeah,
I
think
the
other
okay.
You
should
be
able
to
present.
If
you
would
like
to
do
a
demo.
D
There
you
go
so
the
there's
two
parts
to
the
two
really
one
is
detecting
whether
your
psp
is
mutating,
which
is
something
you
should
fix,
and
the
other
is.
How
do
we
get?
D
How
do
we
recommend
a
suggested
port
security
profile,
pulse
security
standard
for
for
each
namespace,
because
the
users
also
need
to
decide
which
I'm
am.
I
gonna
apply
baseline,
restricted
or
privileges
to
all
my
namespaces,
so
the
two
actually
goes
to
all
namespaces
checks
at
the
running
pods
and
sees
what
is
the
most
secure
profile
that
I
could
apply
to
the
namespace
based
on
the
running
pods.
So
that's
the
other
part.
That's
that's
that
to
help
make
it
easier
to
migrate
off
of
psp,
so
yeah
I
can.
D
D
So
this
is
the
php
profile
that
I'm
using
for
this
demo.
Actually,
can
you
see
my
here?
You
can
see
my
screen.
It
should
be
working.
You
know.
Yeah,
you
see.
My
terminal
right
is
that
right.
D
Okay,
perfect,
so
this
is
the
this
is
the
port
security
profile,
it's
fairly
standard
and
basically
everything,
but
the
only
thing,
that's
really
that
you
should
pay
attention
to
is
the
default,
add
capabilities,
because
this
attribute
will
add
the
security
context
to
a
pod
if
it's
not
ad,
yet
so
that's
why
it's
a
mutating
attribute
of
the
psp.
D
D
Great
yeah,
it's
already
running
because
already
they
make
and
then
next
we're
gonna
run
the
psp
migrator
to
very
few
commands.
But
I
think
that
the
the
key
ones
we're
going
to
use
for
now
is
this
mutating
parts
to
get
a
list
of
all
the
pots
in
your
cluster
and
for
namespace
and
then
there's
an
attribute
called
mutated
and
the
reason
it's
mutated
is
because
of
default.
Ad
capabilities.
D
D
Actually,
for
for
the
other
command
that
that
we
have
right
now
in
psp,
migrate
is
my
grade
and
that
will
go
through
all
your
name
spaces,
but
it
will
also
check
if
there's
a
mutating
pot
and
if
there
is
it,
tells
you
to
first
fix
that
because
there's
a
risk
that
you're,
if
you
don't
fix
that
that
that
the
security
attributes
that
you
were
expecting
on
your
pot
suddenly
are
gone
after
you
move
to
psa.
So
that's
why
the
mutating
piece
is
critical
to
be
fixed
first
now:
it's
it
it
it
went.
D
D
There's
a
comment
as
well
to
to
get
more
details
of
how
it
is
being
mutated,
which
will
allow
you
to
get
the
right
information,
and
that
will
show
us
that
it
is
the
default
ad
capabilities,
and
this
is
I
I
got
to
find
a
way
how
to
make
this
more
user
friendly.
But
this
is
showing
the
pot
has
a
nil
slice
and
then
the
the
the
parent
deployment
spec
has
a
view
on
security
context.
That's
a
dip!
That's
how
we
do
the
naive
detection.
D
Actually
that's
one
of
the
feedback
points
that
I
think
going
forward.
I
would
like
someone
to
review
whether
there
are
x
cases
that
this
won't
catch.
It's
yeah
yeah.
D
D
And
I
see
it's
mutating
it's
false,
and
now
the
migration
should
actually
be
able
to
continue
because
there's
no
more
mutating
parts
in
the
cluster
and
then
what
you
see
now
is
it's
going
to
check
the
parts
in
the
in
the
main
space
default
and
it's
going
to
suggest
a
a
port
security
standard
and
the
way
it
does
it
is.
It
actually
goes
to
all
the
parts
it
first
tries
baseline
if
baseline
works,
then,
if
baseline
would
work
for
all
the
pods,
it
actually
starts
with
restricted
it.
D
If
restricted
works
through
the
spot,
it
will
recommend
restricted,
then
goes
to
baseline
and
then
goes
to
preference
and
then
the
question
the
user
gets
is.
What
do
you
want
to
do?
Do
you
want
to
enforce
it
or
just
put
it
in
audit
mode,
I'm
going
to
put
in
force
and
then
it
will
apply
the
the
label
on
the
namespace
and
you
can
verify
there
that
it
does
add
the
labels
and
that
should
have
you
ready
for
disabling
psp.
So
the
end
goal
of
this
is
after
they
run
to
this
2.
D
The
end
user
should
be
able
to
disable
psp
and
fully
move
away
from
it.
The
migrate
command
will
actually
go
through
every
single
namespace.
It
is
a
loop
over
every
single
link
is
in
the
cluster
and
will
try
to
apply
a
part
security
standard
on
every
single
mainstreet
yeah.
Any
questions
is
this.
This
is
this
is
all
I
have
for
the
demo.
A
So
I
guess
there
are
some
trivial
psps
that
can
be
migrated
is
what
classes
of
psps
are
challenging.
Is
it
only
these
psps
with
defaulting
or
other
others
classes
as
well?
C
Okay,
one
of
the
one
of
the
challenging
things
here
is
that
a
lot
of
the
pots
there's
not
a
clean
separation
of
defaulting
and
validating
fields
in
pod
security
policy.
So,
like
you
know,
in
the
case
of
default
ad
capabilities,
that's
clearly
a
mutating
one,
but
actually
required.
C
D
A
So
that's
the
other
yeah.
I
totally.
I
totally
see
the
value
for
kind
of
like
the
trivial
stuff
where,
like
a
human,
it
would
take
a
very
long
time
for
them
to
figure
out
what
profile
is
required.
That
seems
very
valuable
yeah.
I
guess
there.
I
was
mostly
interested
in
like
situations
where
the
the
administrator
would
have
to
think
a
little
bit
more
like
the
situations
where
we
don't
get.
The
audit
enforced,
prompt,
yeah.
D
Yeah,
I
think
that
the
way
I
would
put
it
that's
a
very
actually
I
didn't
the
audience-
would
be
the
not
the
super
sophisticated
users,
the
super
sophisticated
users-
I
don't
think
would
be
using
this
too.
They
would
be
very.
They
will
be
very
much
doing
this
in
their
own
way,
but
this
is
more
for
that,
I
would
say
the
80
user
base
that
doesn't
that
doesn't
use
opa
that
doesn't
use
all
the
advanced
there's
no
kubernetes
as
well.
They
want
to
yeah.
A
Yeah,
I
would
say
if
a
user
is
already
using
psp
they're,
probably
fairly
far
along,
but
I
actually
don't
know.
D
Yeah,
we,
I
think
we,
I
think,
someone
on
the
google
side
did
they
check
and
we
have
many
users
that
have
enabled
psp
but
they're
not
really
using
it
as
well
so
yeah,
I
think
yeah
but
you're
you're
right,
like
I
think
in
general
people
that
use
psp.
They
I
mean
it's,
not
it's
not
an
easy
feature,
so
you
have
to
you
need
to
get
it
working.
It's
not
that
easy.
So
yeah.
C
So
I
guess
the
question
for
sigoth
community
is
does
does
this
seem
useful
and
does
this
seem
like
something
that
we
would
want
to
endorse
as
a
kubernetes
sigs
repo,
like
one
important
note
about
this,
is
it's
sort
of
a
limited
lifetime,
limited
lifespan
like
it's,
not
something
that
we
would
be
committing
to
maintaining
indefinitely?
C
Probably
once
I
think
once
124
drops
out
of
support
window
or
something
like
that,
we
could
probably
archive
it.
A
Yeah,
I'm
pro
adding
this
as
a
sub
project.
This
is
this
seems
like
very
similar
to
what
we
did
for
the
client
go
context:
migration,
tooling,.
B
I
think
it's
a
good
idea
also.
Definitely
we
should
add,
like
a
warning
to
when
this
is
going
to
be
deprecated
after
which
release.
I
think
it'd
be
good
to
signal
that
when
it's,
you
know
added
to
the
repo
added
to
the
org.
D
I
think
I
think
yeah
I
think
we
should
put
some
like
this
is
for
I
don't
I
think
mikey
brought
up
like
is
this
gonna?
We
we
should
have
some
language
like
this,
might
not
fit
all
cases
or
something
along
the
lines
like
I.
I
do
believe
that
this
is
gonna
be
for
majority,
but
it's
not
necessarily
gonna
be
for
every
single
user.
This
is
gonna
work.
Fine,
like
I.
I
think
that
will
be
very
hard
to
write
it
to
like
that
so
yeah.
D
I
think
I
think
what
would
be
it
so
I've
only
tested
it
on
gke,
because
that's
what
I
have
around.
What
I
think
would
be
helpful
is
what
other
distros
have
psp
heavily
enabled,
and
how
do
we
test
it
on
there
and
if
there
are
other
quirks
that
might
be
different
in
the
way
psp
is
handled
or
if,
if
it
test
is
only
on
gk,
should
it
be
enough?
I
I
I
I
don't
know
the
answer
to
that.
C
C
C
Just
going
back
to,
I
can't
remember
who
brought
up
the
brought
up
the
point
of
it
being
production
ready,
but
I
think
two
recommendations
I
have
there.
One
is
to
make
sure
we
document
the
limitations
of
this
so
like,
for
instance,
the
detecting
of
mutation
is
heuristic.
C
So
there
are
some
kind
of
like
edge
cases
that
would
be
good
to
document
and
then
also
when
it
comes
to
the
actual
tool
running.
I
think
airing
on
the
side
of
caution
and
being
a
little
verbose
about
warnings
and
and
just
kind
of
failing
and
refusing
to
apply
the
mutations
to
the
cluster
when
it
gets
risky.
A
C
So
I
guess
in
conclusion,
mike
and
rita,
if
you
wouldn't
mind,
adding
a
plus
one
to
that
issue,
to
create
the
repo
that
would
be
helpful.
C
A
C
B
A
Okay,
if
you
present
okay,
I'll
take
notes
or
you
can
take.
A
Okay,
go
for
it.
Thank
you.
A
B
Okay,
so
I
think
first
one
was
your
questions
around
like:
where
did
it
go
the
uid
one?
Did
I
close
that
or.
A
Yeah,
so
what
I
usually
see-
and
maybe
other
people
can
weigh
in
is
like
first
up
stuff,
like
request
id
like
audit
id,
we
pass
those
in
side
channels
like
in
request,
headers
and
generally
don't
embed
them
in
the
request
objects.
I
I
think
it
is
less
important
here
than
in
like
a
kubernetes
api,
because
this
is
not
a
declarative
api
but
yeah
so
go
ahead.
What
are
your
thoughts
on
this.
F
No,
I
I
was
just
gonna
say,
like
I
think,
the
reason
we
added
it
here,
so
we
also
had
a
previous
gap
that
got
merged
as
part
of
the
enhancement
for
124.,
so
we
did
add
uid
as
part
of
proto
there.
The
only
thing
was,
maybe
when
we
provide
a
reference
implementation
users
can
access
this
uid
by
just
calling
get
uid
function
rather
than
having
to
go
through
the
proto
metadata
and
then
parse
through
the
different
headers
that
are
available
there.
A
If
this
api
accepted
access
tokens,
if
you
put
that
in
the
request
body,
which
you
totally
could
you'd
have
to
put
it
in
all
request
bodies,
it's
not
like
a
you
know
in
aspect
or
like
a
horizontal
aspect
of
the
api,
but
I
don't
really
care
that
much.
A
If
there
is
a
preference
to
do
this
here,
I
I
think
both
are
fairly
easy
to
access
so,
but
if
there's
a
preference
to
do
this
here,
I
like
won't
block
the
pr
on
this.
A
I
will
let
you
say
yes
or
no
and
then
resolve
the
comment
and
yeah.
I
defer
to
you.
B
Okay,
cool!
Well,
let
us
discuss
with
other
folks
as
well.
I
we
don't
want
to
just
make
this
decision
here.
Thank
you
and
I
think
the
next
one
is
this
yeah
and
ishmael
is.
F
Yeah,
so
for
the
magic
number
I
think
the
default
one
today
is
just
the
gate:
s
zero
and
then
for
this
one
we
are
added.
I
think,
like
so
more
proposed,
adding
e
k.
It
is
zero,
but
I
was
just
wondering
in
addition
to
this.
Do
you
think
there
might
be
conflict?
Because
you
said.
A
So
I
think
I
would
be
worried
about
this,
so
the
the
serializers
that
we
have
will,
what's
it
called.
We
have
this
thing
called
a
recognizer
which,
like
first
decodes
in
json,
then
decodes
in
proto
or
something
I
would
be
worried
about.
A
Recognizer
being
able
to
interpret
that
as
something
I
think,
it's
probably
fine,
but
maybe
yeah.
I
think
the
one
thing
that
would
be
weird
is
if
somehow
e
was
the
exact
tag
for
like
a
proto
byte
array
or
the
beginning
of
a
proto
message.
F
G
A
It's
but
it's
ended
with
the
type
I
think
so
it
would
be.
Tag
number
ended
for
the
lower
six
bits
and
then
the
type
is
the
top.
I
can't
remember.
A
I
think
e
is
the
only
thing
that
matters
and
it
is,
is
it
valid
base64?
No
because
of
the
zero.
A
I
let
me
check
the
let
me
check
e.
I
can
check
that
offline
and,
if
that
doesn't
deserialize
as
a
proto,
then
I
think
we're
fine.
A
So,
okay
yeah.
That
would
be
weird
in
a
situation
that
that
could
be
confusing
in
some
situations,
especially
around
like
removing
or
adding
encryption.
A
So
to
like
an
existing
object,
type
or
something.
F
A
I'll
double
check
this
one
offline,
but
I
think
both
of
these
are
super
minor
is
that
are,
were
those
the
only
ones
that
are
still
open.
B
A
Okay,
cool,
then
those
last
two
are
fairly
simple,
I'll.
Take
I'll
tackle
the
second
one.
If
you
tackle
the
first
one
and
come
up
with
a
recommendation
and.
A
Okay,
first
issue:
uid.
A
Second
issue:
magic
number,
mike
denise,
you
follow
up
awesome
other
than
that.
A
All
right
trust
anchor
sets
to
here.
A
All
right,
do
you
want
me
to
share
then.
G
G
G
G
Personally,
I
kind
of
lean
away
from
this
because
it's
like
we're
just
making
up
a
standard
here
so,
like
users,
are
going
to
have
to
write
some
custom
code
to
load
a
crl
or
no
csp,
url
and
wire
it
into
their
tls
library.
And
if
we're
having.
G
Code
that
extracts
this
information
from
the
root
certificate
as
index
509
extension,
but.
A
There
are
aren't
there
already
standard
extensions
for
crl's
serial
urls
to
serials
in.
A
I
think
to
an
ocsp
right:
I
thought
they
had
it
for
serials
too.
Okay
in,
like
us,
embedded
in
a
ca.
G
A
But
there
are
standard
ways
to
distribute
like
the
location
of
acrl
in
aca,
see
our
distribution
point.
A
So
my
preference
for
both
crl
and
ocsp
is
if
there
are
x,
509
extensions
that
we
can
add
to
the
ca
x49
certificate.
Then
we
should
add
those
there
versus.
A
Adding
the
fields
adding
crls
directly
in
trusting
for
set.
G
Yeah,
I
definitely
so
if
we
do
have
some
revocation
functionality
interesting
percent,
it
should
not
be
a
crl
directly.
I
think,
because
those
can
get
arbitrarily
large
and
I
think
in
cuba,
in
a
kubernetes
deployment
right,
they
would
get
arbitrarily
large
because
probably
each
pod
you're
using
has
an
independent
key
and
certificate
and
whatever
compromise
leads
you
to
revoke
the
certificates,
would
lead
you
to
a
lot
of
certificates.
G
Opinions
mo
obviously,
but
is
there
someone
on
the
call.
H
Okay,
I
guess
I'll
just
chime
in
and
say
my
understanding
is
that
the
crl
distribution
point
is
something
that
you
put
in
the
certificate.
So
when
you
show
up
with
a
certificate
the
entity
authorizing
that
goes
somewhere
else
to
go
see
if
your
certificate
has
been
revoked,
so
you're
kind
of
just
pushing
the
problem
off
to
somewhere
else
to
say
there
will
be
a
crl
server
somewhere.
A
A
G
There's
so
also
some
two
related
feedback
that
we
should
take
aspects
of
this
to
sig
architecture.
One
is
we
decided
hey,
we
should
have
a
sort
of
canonical
mapping
convention
between
the
url
based
signer
name
and
the
kubernetes
resource
name
for
a
trust.
Anchor
sets
object
and
that's
like
the
first
time.
We
have
something
like
that,
so
we
should
ask
cig
architecture
about
it.
E
G
G
So
but
like
a
signer
name
is
not
a
valid
kubernetes
resource
name.
Slashes
are
not
allowed
and
well
slashes
are
the
problem.
Dots
are
allowed,
but
not
slashes.
So
I
came
up
with
a
sort
of
escape
convention
that
sort
of
one-to-one
maps
between
signer
names
and
resource
names,
but
it's
ugly,
but
I
can't
think
of
a
better
one.
A
Config
is
a
cop-out
I
like
to
endpoint
sets.
We
have
plural
resource
names,
all
right,
sorry,
trusting
yourself
for
all
resource
names,
trusting.
G
A
Anchor
bundle
that's
the
same
as
config.
No,
it
isn't.
Config
is
a
catch-all
for
everything.
Bundle
has
relevance
within
this
usage,
which
is
a
certificate
bundle
all
right.
Cluster
trust
anchor.
G
E
All
yeah,
I
guess
so
I
mean
the
other
alternative
is
having
like
you
know,
trust
anchor
set
as
the
resource
and
whatever
consumes
it.
You
can
provide
a
list
of
references
to
yeah,
so
that
was
actually
one.
G
Of
sf
tim's-
and
I
don't
know
if
he's
on
the
call
or
not-
but
it
was
one
of
his
recommendations
for
exploring,
is
hey,
have
the
speeds
trust
anchor
set,
singular,
have
it
store
a
single
set
and
then
use
label
selectors
to
do
the
association
between
signers
and
trust
anchor
set
objects.
G
I
think
that
is
elegant,
but
not
necessarily
workable
in
this
case,
because
we
want
to
be
able
to
easily
lock
down
like
a
given.
Signers
controller
should
only
be
able
to
update
the
trust,
anchor
set
objects
that
are
related
to
that
signer
and
the
only
hook
our
back
gives
us
to
do.
That
is
names.
You
can't
use
label
selectors
in
our
back,
so
you
have
to
have
it
defined
like
given
the
signer.
You
have
to
know
the
fixed
set
of
trust.
Anchor
set,
singular
objects
that
you
want
to
use
the
names.
A
G
Trust
anchor
config
or
something
like
that.
We
just
deploy
that
object
out
of
band
into
the
cluster
using
our
existing
deployment
machinery
and
then
the
controller
kind
of
takes
over
it
and.
A
Yeah
I
mean
so.
We
solved
this
with
the
certificates
api,
using
the
admission
control
and
doing
extra
checks
there.
A
A
I
would
say,
maybe
remove
maybe
add
a
signer
field
explicitly
and
we'll
check
an
additional
our
back
permission
during
admission.
G
A
So
what
is
the
point
of
having
a
signer
name?
Is
the
only
point
of
having
a
signer
name
somehow
in
this
object,
so
that
signers
can
update
their
own
trust
anchor
sets,
and
so
that.
G
A
A
G
G
I
don't
really
care
one
way
or
another.
I
think
if
you're
like
handling
certificates,
you're
more
likely
to
already
have
the
certificate
in
pim
format,.
A
Putting
too
much
thought
into
it,
so
the
only
value
of
having
pem
for
the
certificates
api
is
that
we
can
encode
extra
blocks
and
extra
info
in
the
csr
in
the
csrs
as
they
exist
in
the
kubernetes
avi.
Otherwise,
I
would
say
der
would
be
better
if
we
were
constrained
to
only
one,
because
it
is
the
canonical
representation.
So
I'd
have
a
byte
where
by
byte
field,
would
just
encoded.
A
A
G
A
Yeah,
I
mean
so
like
what
what
do
things
normally
do
when
they
see
non-pin
blocks
or
comments
in
lists
of
pen
blocks,
they
usually
skip
them
right.
G
A
I
don't
yeah,
I
don't
know
how
to
do
that.
So
what
do
you
think
to
hear?
Do
you
think
there's?
It
seems
like
there's
still
a
fair
amount,
that's
open,
but
I
think
we
could
get
the
reviews
done
mo
mo
gets
back
monday.
G
A
A
Let's,
let's
evaluate
and
then
know
by
monday,
whether
we
think
we
can
get
this
done,
okay
and
then
by
then
mo
will
be
back
and
maybe
we
can
grab
him
and
maybe
anybody
else
who
is
interested
in
commenting
on
the
cap.
B
Yeah
and
may
I
request
that
the
cap
owner
drives
this,
so
that
said,
leads
can
help
with
adding
tracking
the
cap.