►
From YouTube: sig-auth bi-weekly meeting 20210225
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
I
thought
it
might
be
useful
to
briefly
go
over
the
summary
of
the
goals
and
requirements
that
we
talked
about
last
time
and
just
make
sure
everyone's
on
the
same
page
and
then
pivot
to
talking
about
the
actual
implementations
and
proposals
which
will
take
up
the
bulk
of
the
time.
So
let
me
share
my.
A
A
A
A
Not
okay,
so
I
think
I
shared
out
this
document.
Let
me
make
it
bigger
how's
that.
A
I
shared
out
this
document
about
a
week
ago,
hopefully
had
a
chance
to
see
it,
but
this
is
just
my
best
effort
to
kind
of
capture
and
summarize
all
the
different
pieces
that
we
talked
about
so
as
a
high
level
objective.
I
think
we
all
agree
that
the
goal
is
to
replace
pod
security
policy
without
compromising
the
ability
to
limit
privilege
escalation
out
of
the
box.
A
A
Built-In
entry
controller,
as
opposed
to
a
web
hook
out
of
tree,
although
I
am
not
ruling
out
the
option
to
have
a
web
hook
as
either
something
that
exit
can
coexist
alongside
the
entry
one
or
as
a
way
to
prototype.
That's
beside
the
point
we
at
least
need
to.
I
think
we
had
consensus
on
this.
A
We
need
to
have
a
path
to
a
solution
for
windows,
even
if
it's
not
addressing
windows
on
in
the
initial
release-
and
I
list
it
down
in
the
contentious-
isn't
quite
the
right
word
but
lacking
consensus
requirements
is
that
it
supports
windows
in
the
initial
release
must
handle
api
evolution
across
versions.
A
A
Yeah,
both
the
pod
api
or
kind
of
the
features
that
it
covers,
and
also
whatever
api
or
user,
inter
maybe
user
interface,
would
be
a
better
way
of
describing
it.
However,
we
surface
the
feature
to
the
user.
It
needs.
B
A
A
B
C
I
I
kind
of
read
this
as
being
sort
of
your
baby,
jordan,
about
how
the
psp
api
sort
of
diverged
like
a
river
delta
and
then
like.
C
I,
I
understood
this
to
be
that
that
you
and
several
other
folks
wanted
to
have
a
way
to
prevent
the
replacement
api
from
from
sort
of
going
to
seed
the
way
that
psp
did
and
then
and
then
I
counter
argued
that
as
long
as
the
pod
api
goes
to
seed
any
other
api
that
tries
to
enforce
things
about,
it
would
would
have
that
same
sort
of
challenge
and
I
think
that's
how
it
ended
up
in
the
like
contentious
requirements.
Section
like
I
agree
with
that
in
principle,
but
I
worry
that
there's
nothing.
B
So
I'm,
if
we're
looking
at
the
requirements
before
we
look
at
particular
proposals
for
implementation,
I
missed
the
pun.
What
was
the
pun?
Please
tell
me.
B
Oh
okay,
let
me
forbid,
I
miss
a
pun.
If,
if
the
thing
we're
wanting
to
protect
is
the
pod
api,
then
we
need
to
be
able
to
like
have
some
approach
to
handling
pod
api
evolution.
If
the
solution
to
that
is
exposed
as
an
api,
then
yes,
that
needs
to
be
able
to
evolve
as
well.
If
it's
not
exposed
as
an
api
but
is
sort
of
fixed
policies
more
like
tim's
proposal,
then
we
need
to
have
a
way
to
handle
compatibility,
versioning
evolution
there,
but.
E
A
Yeah,
I
think
yeah
the
pod,
not
just
the
api,
but
the
features
themselves.
You
know
what
a
pod
is.
We
expect
that
to
continue
to
evolve
and
whatever
solution
we
have
means
to
be
prepared
to
deal
with
that
evolution
and
not
gonna
fall
apart.
The
first
time
a
new
feature
is
added.
B
Yeah,
I
I
think
if
we
frame
the
windows,
the
future
windows
support
in
terms
of
being
responsive
to
pod
api
evolution,
then
that
becomes
a
lot
simpler
like
I
could
imagine
things
that
windows
would
do
in
the
future.
That
would
require
a
lot
of
configurability
that
I
don't
know
that
we
would
want
to
support.
B
But
if
there's
a
field
that
windows
adds
to
the
pod
api,
like
the
one
that's
being
proposed
now,
like
the
host
process
field,
like
folding
in
a
position
about
that
field
into
future
versions
of
this
policy
makes
a
lot
of
sense.
A
Ground,
I
think
I
agree
with
you.
I
still
like
keeping
windows
out
as
a
separate
requirement
just
to
be
explicit
about
it.
C
C
A
The
last
one.
I
marked
this
as
fuzzy
because
it's
hard
to
specify
it
as
a
requirement,
but
we
want
it
to
be
easy
to
use.
I
think
we
all
agree.
Pod
security
policy
is
not
easy
to
use,
but
beyond
that,
this
is
where
the
the
kind
of
like
red,
yellow,
green
policy
tier
idea
comes
from
or
ties
in
of
you,
you
don't
necessarily.
A
I
think
we
don't
want
you
to
need
to
understand
the
ins
and
outs
of
like
what
the
no
new
pribs
flag
is
and
what
the
different
capabilities
expose
in
terms
of
attack
surface
that
you
know
we
can.
We
can
have
the
debate
about
whether
we
should
surface
those
options
at
all,
but
whether
or
not
those
controls
are
surfaced.
A
A
A
My
glasses
is
further
down.
Okay,
extensibility!
You
know
at
the
at
the
very
base
level,
you
kind
of
no
matter
what
we
just
what
we
land
on.
You
can
always
run
a
second
admission
controller
as
a
web
hook
that
will
cover
or
layer
on
additional
constraints.
On
top
of
this,
so
that's
kind
of
like
the
base
level
of
extensibility
or
composability.
A
A
A
I
I
guess
this
is
just
kind
of
getting
at
the
the
key
difference
between
the
two
proposals.
We
were
talking
about
and
providing
an
easy
migration
path
from
pod
security
policy.
In
other
words,
how
how
much
do
we
want
to
deviate
from
the
existing
thing.
A
Nice
to
have,
I
had
put
dry
run
policy
changes,
but
there
was
some
discussion
around
whether
this
is
a
requirement,
given
that
we
want
it
to
be
safe
to
enable
on
upgraded
clusters,
so
we
can
bump
it
up
there.
Audit
only
mode
sort
of
different
from
dry
running
policy
changes
dry
run
is
around
at
least
the
way
I
understood
it.
When
I
wrote
it
is.
C
A
A
A
And
enforcement
on
pod
controller
resources,
so,
in
other
words,
can
I
check
my
policy
against
replica
sets
and
deployments,
and
things
like
that,
and
then
I
think
there
are
a
couple
open
questions.
The
first
one
is
around:
where
kind
of
this
idea
of
what's
the
philosophy
of
the
policy,
how
do
we
decide
what
controls
get
in
there
and
not
what
fields
are
enforced
and
what
aren't
a
couple
examples
that
were
given
were
local
denial
of
service,
mitigations,
host
ports
and
readiness
and
liveness
probes?
A
What
do
we
want
to
do
about
ephemeral
containers?
We?
This
came
up
in
the
last
sig
off
how
we're
going
to
handle
those
and
yeah
what
we
want
to
do
with
runtime
policy,
which
relates
also
to
punching
holes
in
the
policy
and
extensibility.
F
F
B
B
C
Yeah
yeah,
I'm
personally
not
not
wedded
to
dry,
run
or
audit
mode,
but
I
don't
see
any
way
to
make
it
safe
in
upgraded
clusters
without
at
least
one
of
those,
and
that's
getting
exactly
to
your
point,
john
of
like.
If
you
don't
know,
what's
going
to
happen
until
you
make
it
into
a
stick,
then
you're
going
to
get
beaten
by
your
own
stick
and
then
you'll
be
sad.
E
Hey,
thank
you
folks.
My
name
is
arvind.
I
work
at
red
hat
and
I'm
representing
windows
here,
so
my
only
request
would
be.
I
understand
it's
capable
it's
hard
to
support
windows
from
the
get
go,
but
could
we
add
some
sort
of
requirement
that
sort
of
that
states
that
at
least
windows
will
not
be
broken
as
as
part
of
this.
E
G
A
B
H
So
yeah,
that's
really
sorry
go
ahead.
People
I
was
gonna,
say
going
back
to
runtime
classes.
Do
we
think
that
a
solution
that
doesn't
coexist
nicely
with
runtime
classes
is
going
to
be
one
that
we
want
to
go
with?
H
C
I
feel
like
that
could
actually
work
fine
either
way.
You
know
suppose
you
have
a
cluster
that
supports
both
the
normal
linux
c
groups
and
namespaces
runtime,
and
also
some
some
more
advanced
runtime
like
containers
or
or
g
visor.
Maybe
you
do
have
a
maybe
you
do
have
a
use
case
where
you
would
be
okay
with
having
pods,
with
both
runtime
classes
in
in
the
same
namespace.
C
But
if
you
don't,
if
you
want
to
say
within
this
namespace,
you
must
be
using
g,
visor
or
or
whatever.
That
could
be
something
that
this
that
this
sort
of
policy
framework
would
enforce
on.
If
this
policy
framework
were
configurable
or
if
this
policy
framework
were
focused
on
like
the
the
more
standard
container
runtimes,
then
that
would
be
a
really
simple
web
hook
for
somebody
to
write
and
so
like.
I
I
don't
feel
like
it
is
automatically
necessary
that
this
do
enforce
on
runtime
class.
H
To
be
clear,
I'm
less
worried
about
it
being
able
to
enforce
on
runtime
classes
and
more
concerned
about
being
able
to
write
something
that
enforces
on
runtime
classes.
That
can
co-exist
with
what
we
have,
and
I
think
I
do
see
the
ability
to
have
pods
for
multiple
runtime
classes
in
the
same
namespace
as
a
useful
feature.
When
you
think
about
trying
to
do
things
like
quoting
them
and
network
policy,
these
things
may
be
related
and
you
just
want
to
run
them
with
different
runtime
classes.
H
I
think
I'd,
I
think
our
story
would
be
a
lot
stronger
if
we
have
some
way
to
coexist
in
the
same
name
space
with
them.
I
think
that
if
we
design
it
that
way
to
begin
with,
it
may
not
be
too
difficult.
If
we
don't
try
to
expand
it
and
say
I
want
to
configure
and
force
on
all
these
and
just
say
if
you
want
to
do
something
we'll,
let
you
and
stay
out
of
your.
G
A
I
think
I
agree
with
you.
I
do
worry
a
little
bit
about
this.
You
know
if
we
say,
okay,
you
can
configure
based
on
runtime
classes.
I
worry
a
little
about
that
kind
of
expanding
into
okay,
we're
also
going
to
let
you
configure
based
on
this
other
field,
and
this
other
field
and.
H
Yeah
I
I
can.
I
can
get
that.
I
guess
what
I
would
say
is:
runtime
classes
exist
today
and
it
it's
not
like
a
theoretical
thing.
C
That
has
like
absolutely
minimal
configurability
like
the
bare
minimum
pod
security,
then
that
doesn't
support
the
use
case
of
having
mixed
runtime
classes
enforced
within
a
namespace
because
to
make
meaningful
use
of
some
other
runtime
class.
You
would
probably
want
to
not
have
opinions
about
a
lot
of
the
features
that
don't
mix
a
lot
of
the
pods
back
fields
that
don't
make
sense
under
those
those
alternate
runtime
classes.
But
I
guess
I
would
also
say
that
if
we
adopted
something,
that's
that
simple.
C
C
But
then,
if
it
was
something
more
like
the
the
sort
of
psp
replacement
proposal,
you
could
have
two
policies
bound
into
your
namespace
one.
That
has
no
opinion
about
any
pod
fields
at
all,
except
for
runtime
class
and
insists
that
runtime
class
b
say
g
visor,
just
for
example,
and
another
one
that
has
you
know
relatively
restricted
settings
for
most
fields
and
doesn't
care
about
runtime
class
and
we
wouldn't
have
to
ship
pre-canned
policies
that
touched
runtime
class
at
all.
B
I
I
made
the
mistake
of
trying
to
put
together
a
thought
and
then
take
notes.
At
the
same
time,
this
this
is
not
going
to
go
well.
I
I
left
some
comments
on
tim's
bare
minimum
proposal.
B
I
think
all
of
those
use
cases
are
somewhat
niche
but
legitimate
and
like
real
existing
use
cases
and
from
a
complexity
perspective
on
the
solution,
we
provide
it's
very
simple.
It's
like
an
enumerated
list
like
if
it's
this
user
or
this
namespace
or
this
runtime
class,
assume
that
there's
some
other
mechanism
in
place
doing
enforcement,
but
it
would
allow
that
coexistence.
B
D
Sorry
turning
this
up,
I
mean,
I
think,
when
we're
talking
about
complexity,
I
think
it's
important
to
consider
complexity,
for
whom,
though,
are
we
talking
about
complexity?
For
us
as
maintainers?
D
I
think
that
our
proposal
was
trying
to
address
was
from
end
users,
who
actually
don't
want
to
put
a
whole
lot
of
thought
into
it,
but
who
want
to
put
something
on
it
and
want
to
be
told
what
to
do
you
know
and
and
saying
that
not
giving
them
options
if
I
interpreted
that
correctly
leads
to
less
complexity
or
more
simplicity
for
them.
I
think
they're
asking
for
a
different
kind
of
simplicity
than
that
they're
asking
for.
Please
don't
make
me
think,
please
hand
me
this
thing.
G
G
I
I
talk
to
a
a
number
of
customers
who
who
need
more
than
that,
and
so,
if
I
think
about
what
ian
just
said,
I
I
mean
I
yes,
there
are
challenges
with
what's
available
today
and
and
how
to
you
know,
make
it
work
consistently
and
expect
it
and
there's
a
lot
to
understand
and-
and
so
I
think,
ian's
right.
If
I'm
understanding
that
you
know
simplicity
for
the
end
user
is
a
goal,
I'd
agree,
but
it
doesn't
mean
they
don't
want
these
other
use
cases
addressed.
G
A
G
So
I'll
defer
to
david
on
the
runtime
classes,
but
I
I
guess
for
example,
concretely
right.
I
I
absolutely
talk
to
customers
who
want
different
privilege,
different
privileges
applied
to
different
pods
in
the
same
name,
space
for
example,
and
also
by
user.
So
those
are
the
two
that
I
absolutely
do
run
into.
David
could
probably
be
clearer
on
the
runtime
example
than
I
can.
H
Yeah
runtime
classes,
I
see
as
something
that
is
now
being
leveraged
more
often
than
it
was
before
and
how
you
enforce
on
it.
It
brings
in
a
whole
new,
it's
basically
impractical,
to
build
an
api,
that's
going
to
be
configurable
for
different
runtime
classes,
and
I
think
we
just
have
to
figure
out
how
to
live
in
a
world
that
has
that
can
delegate
that
authority
to
some
a
different
admission
plug
in
something
like
don't
mess
with
these
runtime
classes.
C
To
the
question
of
simpler
for
who,
because
like
a
lot
of
these
concerns,
are
are
saying
we're
going
to
have
to
have
something
that
is
enforcing
policy
besides
this.
But
we
want
to
use
this
for
some
aspects
of
policy
and
we
want
to
use
that
other
tool
for
other
aspects
of
policy
and
like
I
want
to
discourage
that,
like,
even
even
though
it's
possible
to
have
two
different,
two
different
admission
controllers
enforcing
opinions
about
the
same
fields.
It.
C
H
Can
imagine
an
api
that
says
I
want
all
pods
here
to
be
roughly
equivalent
to.
I
don't
know
one
of
the
things
in
tim's
document
about
with
the
four
classes
of
pods
or
whatever
it
was
he
had,
and
if
you
do
that
in
a
unified
way,
then
the
user
doesn't
have
to
think
about
anything
beyond
like
okay.
I
want
this
to
be
the
equivalent
to
safe
or
default
and
any
admission
plug-in
could
honor
that
right
and
so
from
a
user
experience.
It's
very
easy.
H
You
say
I
want
this
namespace
to
be
safe
or
green
or
yellow
or
whatever,
whatever
you
described
it,
and
then
the
individual
admission
plugins
could
enforce
that
on
particular
runtime
classes,
like
that's
just
like
a
if
I
were
doing
it
in
the
next
10
minutes.
What
could
I
do
sort
of
thing?
So
I
don't
think
it
necessarily
makes
it
more
complicated
for
an
end
user.
A
A
You
need
to
configure
the
cri
runtime
on
the
nodes
themselves,
so
this
is
already
like
a
fairly
advanced
administrator
or
provider.
That's
providing
the
runtime
class
in
the
first
place,
and
so
when
it
comes
to
setting
up
a
policy
enforcement
mechanism
on
that
runtime
class,
I
see
that
as
something
that
could
definitely
be
a
part
of
that
runtime
class
setup
and
then
kind
of
servicing
that
to
the
end
user.
H
But
for
the
purpose
of
this
meeting,
I
just
want
to
get
to
the
point
of
trying
to
agree
that
it
is
a
situation
that
we
want
to
explicitly
handle
or
explicitly
not
handle
in
some
graceful
way.
It's
just
that.
It's
it's
a
considered
design
criteria,
not
an
accident
of
whatever
we
create.
B
B
One
of
the
things
that
we've
seen
be
confusing
to
users
is
having
multiple
pod
security
policies
apply
and
not
being
sure
which
one
was
going
to
be
effective
and
so
solutions
or
proposals
that
talk
about
like
binding,
multiple
policies
into
a
namespace
and
like
letting
like
the
pot
is
going
to
be
handled
by
one
of
them.
I
I
worry
that
that's
re-treading
the
steps
that
we've
already
taken
with
psp.
B
Yeah
actually
yeah
like
I,
I
regularly
answer
questions
about
like
I,
I
found
a
restricted
policy
in,
but
this
privileged
one
was
also
connected
to
the
namespace,
and
I
like
I,
I
bound
the
restricted
one.
Why
did
my
privileged
pod
get
allowed-
and
I
know
part
of
that
is
due
to
the
current
authorization
binding
mechanism,
which
is
really
problematic,
but
I
expect
that
confusion
like
I,
I
connected
policy
x
to
my
name,
space
and
policy
x
is
not
being
affected.
Why?
Because.
C
B
It
also
just
practically
like
for
dry
run
purposes
when
multiple
policies
can
interact.
It's
harder
to
reason
about,
like
one
change
in
isolation,
that's
sort
of
getting
into
implementation,
but
I'm
thinking
in
terms
of
like
auditing
and
dry
run,
and
when
you
have
multiple
things.
Interacting
your
options
are
more
limited
in
terms
of
like
how
to
safely
be
sure
that,
like
a
particular
change
is
going
to
do
what
you
want
when
it
sort
of
depends
on
the
full
cluster
state.
A
I
think
we
can
start
getting
into
implementation.
G
Yeah,
just
just
a
quick
question:
if
you
don't
mind,
so
I
guess
I'm
wondering
whether
we
can
address.
I
don't
disagree.
Jordan.
I've
talked
to
customers
too
users
too,
who
who
you
know
it's
complex
to
figure
out
which
psp
got
applied
and
why-
and
I'm
just
want
to
be
sure
that
I'm
just
not
convinced
yet
that
we
can't
address
that
complexity
without
you
know
that
that
we
have
to
drop
some
of
the
use
cases
we've
been
talking
about
in
order
to
address
that
complexity.
I
I
So
I
guess
in
my
head
I
see
user
name,
space
and
runtime
class
as
an
important
or
a
series
of
important
dimensions,
but
do
we
feel
that
a
built-in
solution
must
handle
them
perfectly,
or
can
we
just
provide
a
way
to
say
the
built-in
solution
can
be
turned
off
at
that
particular
dimension,
and
you
may
then
use
whatever
solution.
You
want
to
give
you
more
robust
control
at
that
dimension.
I
I
know,
I
I
think
it's
too
late
not
to
have
mixtures,
because
you
can
have
as
many
admission
web
hooks
as
you
want
and
you
get
to
decide
what
crazy
is
going
to
happen
on
your
cluster.
So
I
think
that
ship
is
kind
of
sailed
already.
So,
in
that
same
regard,
could
we
could
we
get
to
a
point
where
we
say
okay,
this
built-in
solution?
This
is
as
far
as
it
goes.
I
We
want
to
make
it
easy
for
you
to
layer
on
your
external
solution.
It
would
be
super
awesome
if
your
external
solution
handed
handled
runtime
class,
because
we
do
nothing
if
you're
on
time
classes,
not
if
it's
set
to
anything.
We
can't
do
anything
for
you,
because
we
don't
know
what
it
means,
but
it
would
be
super
awesome
if
the
gvisor
runtime
class
could
also
honor
the
same
label
or
whatever,
as
the
policy
enforcer
and
do
something
good
with
it.
We
just
can't
enforce
anything
because
we
don't
know
what
it
means.
A
I
I
I
You
could
you
could
frame
it
that
way
too.
I
I
was
more
saying
that
since
we
don't
have
any
idea
what
the
runtime
classes
properties
are,
I
don't
know
what
we
should
do
and
maybe
we
should
so
either.
You
could
either
assume
you
should
do
exactly
the
same
thing
or
you
should
assume
you
should
do
nothing.
I
guess
either
one
is
fine,
I
don't
know
yeah
and
going.
B
Back
to
what
kristen
said,
I
I
think
I
would,
or
I
think
I
would
probably
agree
that
those
use
cases
aren't
niche
but
they're
not
standard.
Maybe
that's
a
better
way
of
saying
that,
like
to
be
able
to
support
sort
of
the
range
of
things
a
person
could
want
to
do
in
response
to
a
custom,
user
or
thing
as
a
person
could
want
to
do
in
response
to
a
custom,
runtime
class.
I
think
we
would
approach
like
oppa
or
rigo
in
terms
of.
B
G
B
H
I
think
if
you
carefully
construct
the
initial
api
and-
and
you
know
imagine
just
something
at
like
a
namespace
level,
are
you
gonna
demo
something
here
jordan
in,
like
the
last
10
minutes.
H
But
like
if
you
decide
at
a
namespace
level
like
I
want
this
namespace
to
be
green,
having
that
description
and
then
having
a
way
to
say
on
a
runtime
class,
don't
pay
attention
to
this
then,
like
a
simple
implementation.
Could
sim
could
just
be
that
everything
that
wants
to
honors
the
greenness
of
that
namespace,
whatever
it
means
for
a
particular
runtime
class,
something
different
for
kata
than
it
is
for
g
visor
versus
windows?
H
And
yet
you
have
an
api
that
fulfills
that
intent
on
all
these
different
platforms,
so
that
the
end
user
is
not
faced
with
some
complicated
piece
of
configuration
but
says
I
want
to
be
green
or
I
want
to
be
yellow
and
the
details
are
handled
by
independent
people.
Writing
admission,
plugins
that
honor
those
common
pieces.
I
I
Because
I
guess
I
I
guess
what
I
want
to
know
is
if
I
am
a
user
and
I
have
a
green
name
space
or
I
make
a
green
name
space
and
and
I'm
going
to
do
stuff
in
it,
and
it's
going
to
have
like
g
visor
containers
in
it.
How
do
I
know
that
the
runtime
class
will
do
something
reasonable
like
like
do?
Am
I
just
going
to
wait
long
enough
for
this
to
be
well
supported?
Kind
of
like
our
back
eventually
became
well
supported
across
environments,
and
then
I
just
didn't
worry
about
it
anymore.
H
I
can
imagine
multiple
paths
from
here
to
there,
but
right
now
I
would
let's
see
off
the
top
of
my
head.
I'd
say
that
if
I
knew
I
didn't
have
anything,
a
cluster
admin
would
enforce
something
and
and
yeah.
I
would
say
that,
like
a
year
after
it
gets
introduced,
support
will
probably
be
pretty
decent
sort
of
like
our
back.
A
And
in
the
interim
you
can
just
not
punch
that
hole
for
it,
so
you
know,
while
you're
waiting
for
the
custom
g
visor
support,
you
can
always
just
say
you
know,
I
still
want
to
apply
the
restricted
profile
for
you,
guys
or
pods,
even
though
it's
probably
safe
for
them
to
run
with
higher
privileges.
I
C
And
so
that's
that's
where
allowing
them
to
configure
things
themselves,
but
us
shipping,
some
versioned
options
helps,
but
that
kind
of
ui
of
like
this
is
green.
As
of
1.24.
This
is
green,
as
of
1.25
is
not
really
crisp
enough
for
the
kind
of
of
third-party
intent
based
uptake
that
that
you're,
imagining
david.
H
B
I
I
left
similar
comments
on
tim's
bare
minimum
proposal.
I
think
he
had
proposed
a
single
level
or
either
two
levels
like
privileged
or
baseline
and
proposed
no
versioning.
I
think
that
representing
all
three
levels
of
pod
security
standards
is
useful
and
I
think
that
being
able
to
express
version
intent
is
also
useful.
So
tabitha,
you
just
called
out
like
exactly
the
two
classes
of
users,
like
some
users
say
like
I
want
to
be
green,
whatever
green
means-
and
I
would
rather
this
thing
be
broken.
B
Right
right,
like
cube,
added
a
new
thing
and
they
realized
something
was
a
gap
and
they
closed
the
gap,
and
I
would
rather
have
the
gap
closed.
You
know
I
run
my
stuff
in
ci
or
whatever
and
then
there's
the
other
class
of
user,
which
is
like
I'm
upgrading
and
don't
you
dare
break
me
like
audit
or
let
me
audit
at
that
level.
That's
fine,
but
this
is
my
only
cluster.
It's
my
only
production
cluster
and.
C
B
I
I
I
think
it's
actually
better
to
give
that
power
to
the
users,
and
I
I
forget
who
asked
if
I
was
gonna
demo.
B
I
actually
was
playing
around
with
like
different
ways
to
maybe
express
this,
and
I
liked
the
thing
that
tim
proposed,
which
was
labeling
namespaces,
because
it's
very
cube-like
you
can
use
label
selectors
to
query
namespaces
and
say,
like
show
me
namespaces
that
are
enforcing
or
aren't
enforcing
or
enforcing
at
some
level
or
not,
if
we
add
a
version
dimension,
so
you
can
say
I
want
to
be
restricted
as
of
one
seven
or
restricted
latest
like
you
can
you
can
express
both
of
those?
B
If,
if
that
is
independent
of
like
what
we're
enforcing
or
auditing
or
warning
about,
then
you
can
do
things
like
say.
I
want
to
be
restricted
as
of
170,
and
I
want
to
audit
at
restricted
latest
that
I
don't
think
we
have
to
go
all
the
way
to
an
exposed
api
surface,
to
get
those
properties
of
like
being
able
to
express
that
intent.
I
don't
think
we
have
to
increase
the
number
of
buckets.
I
think
it's
really
just
asking
the
user
like
okay,
you
want
to
be
in
this
bucket.
B
A
It's
also
a
small
enough
api
surface
area
that
like
if
I
wanted
to
basically
re-implement
this
in
opa
rigo,
with
a
little
bit
of
like
custom
sauce
on
top.
I
have
the
tools
to
do
that.
A
I
think
there's
kind
of
one.
You
know
something
getting
into
the
implementation
details
that
needs
more
discussion
is,
like
we
add
a
new
field,
we
add
an
option
to
a
field.
How
what
happens
for
the
older
profiles
like?
How
exactly
do
we
deal
with
those?
I
think
jordan,
and
I
talked
about
that
a
little
bit.
I
don't
know
we
need
to
go
into
the
details.
A
A
A
B
The
concepts
of
like
punching
a
hole
like
dimensions
to
punch,
a
hole
and
an
external
engine
sort
of
taking
the
ex
the
user
intent
expressed
in
each
of
these
proposals,
psp
plus,
plus,
or
bare
minimum
security
policy
like
how
would
an
external
implementer?
D
B
B
B
Yeah
I'd
be
happy
to,
I
also
think
better
in
code
sometimes
so
I
actually
implemented
like
a
quick
and
dirty
version
of
that
just
to
play
with
and
kind
of
see
how
it
worked.
So
I'd
be
happy
to
demo
that
next
time,
if,
if
we
want
to
kind
of
look
at
the
user
experience
side
of
it
and
think
about
those
two
like,
how
would
you
punch
a
hole
or
how
would
an
external
engineer.
A
All
right:
well,
thanks
everyone,
if,
if
you
have
any
other
thoughts
or
ideas,
feel
free
to
use
the
mailing
list
or
the
slack
channel.
Otherwise,
I
look
forward
to
continuing
the
conversation
in
two
weeks.
Everybody.