►
From YouTube: Kubernetes SIG Auth 2019-10-30
Description
Kubernetes Auth Special-Interest-Group (SIG) Meeting
Meeting Notes/Agenda: https://docs.google.com/document/d/1woLGRoONE3EBVx-wTb4pvp4CI7tmLZ6lS26VTbosLKM/preview
Find out more about SIG Auth here: https://github.com/kubernetes/community/tree/master/sig-auth
A
All
right,
good,
all
right,
thanks,
sorry
about
the
delay
room.
All
right
today
is
October
30th!
Welcome
to
bi-weekly
sig
off
pretty
sparse
agenda.
Today
it
looks
like
discussion
of
POD
security
policies.
The
only
thing
on
there,
hey,
we'll
call
out
that
we
have
a
little
more
than
two
weeks
coming
before
code
fees
for
117
I.
Believe
that's
November
15th.
A
B
A
Last
time
we
discussed
pot
security
policy
in
cig
off.
We
talked
a
bit
about
the
future
of
POD
security
policy
and
this
sort
of
periodically
people
ask
when
it's
going
to
go
to
GA
and
the
sort
of
stock
answer
that
we've
had
for
a
while.
Now
is
that
we're
unhappy
with
the
current
design
of
POD
security
policy
and
don't
want
it
to
go
to
GA
in
its
current
form
and
then
there's
this
kind
of
open
question
of
whether
hot
security
policy
should
be
built
into
a
community's
core
at
all
or
if
we
should
depend
on.
A
A
The
the
direction
that
both
of
the
examples
and
those
two
projects
have
gone
is
to
have
separate
constraints
or
policies
for
every
dimension
of
the
plat
security
policy
object
and
personally
has
some
concerns
about
what
that
would
actually
look
like
in
a
production
environment.
I
think
you
would
end
up
with
a
lot
of
different
constraints,
especially
as
you
have
different
applications
wanting
to
request
exceptions
or
things
like
that,
and
so
I'm
worried
that
the
one
constraint
per
field
model
will
quickly
get
super
complicated.
A
A
C
C
This
a
little
bit
better
yeah,
so
one
of
the
problems
we've
run
into
a
Twitter
with
kind
of
production.
Izing
kubernetes
at
scale
is
that
the
as
we've
tried
to
make
custom
PS
PS,
for
example,
we
basically
from
an
operational
perspective,
have
had
to
drop
back
down
to
just
having
you
know
three
or
four
different,
PS,
PS
and
and
bucketing
people.
While
we
like
the
idea
of
having
it
all
faceted
and
being
able
to
customize
it
for
every
single
workload
realistically
having
5,000
or
10,000
different
policies
is
operationally
impossible.
C
So
I
think
the
bigger
thing
we
keep
running
into
with
PS
PS
is
actually
how
do
we
pilot
and
canary
changes
to
them
and
we're
a
lot
changes
to
those
across?
You
know
large
numbers
of
jobs,
so
I
think
making
it
more
granular
actually
is
going
in
the
wrong
direction.
For
us,
we
decided
from
a
security
perspective.
It
was
easier
to
say
you
know.
80%
of
our
jobs
fall
into
this
wonderful
kit.
C
D
That
actually
mirrors
a
lot
of
feedback.
We've
gotten
security
context
constraints
over
the
years,
which
is
this.
The
problem
is,
is
the
moment
you
start
cutting
into
permissions
that
are
actually
fairly
broad,
like
you
know,
privileged
or
net
admin
cabinet
admin
or
host
mount
with
control
over
the
selinux
label.
You
basically
turned
off
all
security
anyway,
and
so
that
that
last
20%
or
5%,
depending
on
where
its
spectrum
lies,
is
basically
just
only
run
that
for
validated
trusted
software
that's
been
audited
because
everything
like
it's
it's
almost
impossible
to
constrain.
D
B
C
C
But
from
that
perspective,
the
first
one
is
a
unprivileged
container
that
has
very
limited
rights
to
it.
Has
access
only
to
a
very
small
number
of
things
you
know
has
to
they
all
run?
Is
they
all
run
in
their
own
namespaces
and
they
all
run
as
dedicated
users
and
and
all
of
that
fun
stuff,
and
that's
what
we
sort
of
using
our
back
dump
everybody
into
by
default,
the
other
as
a
previous
person
who's
talking,
who,
whose
name
I
missed,
is
basically
the
privileged
and
sort
of
audited
workloads.
C
C
Network
captures
for
you,
those
are
all
audited
workloads,
and
so
it's
an
agreement
between
the
security
team
and
our
compute
platform
team
that
we
go
through
and
we
audit
those
we
look
at
their
design.
You
know
make
sure
we
keep
sort
of
the
blast
radius
to
a
minimum,
and
then
they,
then
we
use
our
back
to
control,
who
can
have
access
to
that
and
that's
actually
solved
like
80
to
90
percent,
almost
99%
of
all
of
the
workloads.
C
So
that's
how
we've
approached
it.
We'd
started
off
with
I
think
we
really
had
almost
a
dozen
different
PSPs
and
we
just
found
that,
like
the
overhead
of
managing,
very
small
differences
and
therefore
very
small
reductions
in
risk,
just
was
not
worth
it
and
you
know
again
things
like
cap
sysadmin
like
there's
just
like
this
gigantic
hole
that
you
can
drive
everything
through.
So
the
minute.
You
need
one
little
thing
in
that
right
and
they're.
C
C
D
Was
gonna
add
the
things
I've
seen
so
like
privileged
is
the
ultimate
some
people
have
tried
to
do
like
host
network.
Only
the
problem
is
is,
if
you
have
post
network,
you
usually
need
cap
net
admin
and
cat
net.
A
diamond
is
as
far
as
we're
concerned
from
like
a
Red
Hat
perspective
is
effectively
route,
even
if
it's
not
an
obvious
path
in
most
cases
and
then
host
path
like
the
things
that
have
high
cardinality
like
the
host
path
allow
and
the
things
like.
D
If
you
wanted
to
grant
specific
selinux
policies,
those
quickly
get
someone
out
of
hand.
Those
are
those
might
actually
be
better
served
by
a
different
solution
separated
from
SCC
today-
and
maybe
that's
part
of
like
IRB's.
Are
you
through
PSP
and
I?
Think,
like
that's,
that's
also
come
up
a
lot,
the
the
the
other
one
I'd
say
is
them.
We
have
two
sets
of
customers
and
auditors,
one
who
believe
like
the
most
restrictive,
which
is
non-root
user
and
then
some
allow
route
in
a
container
with
proper
selinux
labels.
There.
D
You
know
the
difference
between
99%,
safe
and
100%
safe.
That
one,
though,
like
I,
think
what
we've
seen
a
lot
of
is
people
don't
know
how
to
judge
the
difference
in
those
Without,
Really,
good
descriptions
and
so
having
like
two
or
three
good
descriptions
on
like
standard
like
I.
Think
some
of
this
is
like
the
tribal
knowledge
of
what
you
need
to
audit
within
kubernetes
within
this
with
MPSP
tied
to
those
attributes,
even
just
the
list
of
like,
if
you
think
about
this
profile
with
this
level
of
security,
here's
the
things
you
have
to
audit.
D
A
Yeah
I
agree
with
that.
First
off,
I
would
say
Chris
thanks
for
joining
us.
Your
user
perspective
is
super
valuable
and
that's
often
missing
from
these
meetings.
So
this
is
really
great.
Also
this
one
of
this
sort
of
the
lines
with
an
idea
I've
been
kicking
around
for
a
while
of
sort
of
three
policy
buckets
one
is
privileged.
A
Maybe
I
think
the
restricted
and
default
ones
need
to
be
versioned
because,
as
we
add
more
ways
to
further
restrict
or
further
privileged
containers,
then
those
need
to
kind
of
stay
aligned
with
that,
but
yeah.
So
I
I
do
like
the
idea
of
communities
at
least
putting
out
a
recommendation
for
hey.
These
are
the
policies
that
are.
These
are
the
things
that
we
think
need
to
be
restricted
and
audited,
and
then
there's
some
question
as
like.
Well,
do
we
build
that
in
to
our
communities?
B
C
The
choice
that
most
people
are
going
to
make
is
none
of
the
above
and
therefore
I.
Think
if
we
can
offer
a
default,
that
means
80%
and
makes
things
80%
better
and
we
leave
it
open
for
organizations
you
neither
have
the
skills
or
the
desires
or
the
requirements
to
to
have,
let's
say
more
trustworthy,
behavior.
C
That's
where
I
would
like
to
see
sort
of
the
third
party
innovation
go
on
right,
there's
been
ideas,
we've
explored
about
swing.
How
do
you
Auto
generate
a
policy
for
someone
based
on
their
runtime
behavior
right
and
you
sure,
tighten
it
down
and
do
things
like
that?
That
might
be
something
that
some
of
the
scale
of
Twitter
could
do.
It
is
not
something
this
scale
of
someone
who
is
just
running
a
single
kubernetes
cluster
in
you
know,
with
20
nodes
is
gonna
ever
be
interested
in,
even
if
we
open-source
the
tooling.
E
F
E
I'm,
sorry,
I
guess
the
difference
is:
is
this
a
recommendation
of
the
things
you
want
to
stamp
out
for
people
to
go
and
build
gatekeeper
or
SEC
policies
with,
or
is
this
going
to
I
guess?
Do
we
have
in
express
goal
to
reintegrate
this
that
the
second
seems
hard
I?
Think
that
there's
going
to
be
a
nuanced
feature,
as
people
pointed
out,
different
organizations
have
different
personalities.
You
know
all
set
of
personalities,
but
I
varies
by
company.
You.
D
Know
what's
interesting,
Mike
and
I.
Think
this
like
is
kind
of
getting
at
the
heart
of
it
is
like
we
sew.
Psp
in
some
respects,
is
based
on
assumptions
made
during
SCC,
which
was
designed
before
cubelet
ga1.
Oh
I.
Think,
like
you
know,
just
even
like
this
discussion.
If
we
step
back
and
look
at
what
we're
talking
about
in
the
point
about
run
time
classes
there's
a
set
of
objective
container
truths
on
the
API
they're
like
this
is
either
safe
or
not
safe
and
there's
a
bunch
of
blurry
lines
for
policy
I
mean.
D
Maybe
what
we're
really
trying
to
maybe
say
is
that
there
should
be
one
or
two
recommended
levels
that
we
actually
either
hard
code
or
hard
codes,
just
a
an
arbitrary
statement,
but
like
an
omission
plug-in
that
said,
you're
in
the
unsecured
or
secure
or
privileged
or
not
privileged
or
confined
or
not
confined.
That
would
probably
be
more
useful
than
the
general-purpose
PSP
and
then
there's
a
number
of
other
elements
that
should
be
able
to
orthogonal
e
work
with
that
and
I
think
that's
kind.
What
you're
getting
at
a
little
bit
but
yeah
I
think
that.
E
Maybe
Twitter
doesn't
run
anything
that
needs
a
raw
socket,
but
some
people
do
and
in
a
situation
where
you
give
a
pod
raw
socket,
you
might
not
want
another
node
to
go
scheduled
or
another
pod
psycho
special
with
it,
depending
on
what
that
pod
is
handling
or
same
with
network
admin.
There's
I
think
a
a
lot
of
complexity
comes
out
of
examining
how
these
policies
will
be
used
in
every
company's
use
case.
So
I
just
want
to
make
sure
that
we
don't
lose
flexibility
by
cutting
down
on
the
number
of
constraints
or.
D
Host
volume
is
a
great
example
of
host.
Volume
is
a
gap
that
we
put
in
PSP.
That's
really
in
a
sense
trying
to
work
around
the
absence
of
CSI
local
volumes,
which
is
a
CSI
local
volume
should
be
able
to
handle
every
host
path
in
a
more
controlled
and
inflexible
manner,
barring
the
ability
to
control
who
can
use,
which
CSI
plugins
I
guess
like
another
question
I
would
have.
Maybe
is
one
of
the
advantages
of
PSPs
designed
today,
as
it
does.
Let
you
mutate
at
the
fundamental
level
to
make
your
workload
work.
D
If
we
didn't
get
even
slightly
more
opinionated,
we
still
needed
to
be
flexible.
Would
we
put
like
the
profiles
in
conformance
and
I
could
go
both
ways?
I
feel
like
it's
hard
to
introduce
these
like
we've
struggled
PSP
was
bringing
it
to
GA
means,
probably
turning
something
on
by
default,
which
breaks
people.
D
If
we
put
something
in
conformance
and
it's
you
know,
secured
and
unsecured
we
will
get
into
as
with
Tim,
as
you
point
out
with
like
versioning.
As
we
add
new
capabilities,
we
will
have
to
version
that
definition
and
we
will
have
to
have
even
more
of
those.
This
is
secure
or
not.
Secure,
I
think,
like
the
benefit,
the
net
benefit
of
having
looking
out-of-the-box
or
recommended
profile
is
clear
to
everybody.
It's.
D
A
Yeah
I
agree
that
I
also
don't
think
that
we
should
be
trying
to
solve
the
100%
use
case
here.
I
think
that's
where
these
outside
projects
really
shine
and
anything
that
we're
talking
about
kind
of
you
know,
even
if
it's
on
the
level
of
documentation
or
endorsement
or
something
I,
think
we
should
be
focusing
on
kind
of
that.
I
don't
know,
90%
use
case
of
sort
of
privileged
and
unprivileged,
maybe
to
nail
down
what
that
looks.
Like
yeah,
I,
don't
know
if
there's
privileged
and
unprivileged
or
privilege
and
default
and
restricted
or
yeah.
D
D
Data
we
have
today
from
like
open
shifts
like
over
the
last
six
years
or
so.
I
can
probably
say
that
the
the
three
classes
I've
seen,
are
more
restricted
where
you
can't
run
as
root
in
a
container,
and
you
have
an
actual
app
armor
or
sq
Linux
profile.
That's
unique
to
you,
that's
the
full
restrictor!
You
can't
use
any
of
the
host
level
things
and
then
there's
I
think
the
biggest
bulk
is
the
middle,
which
is
then
you
have
to
ear
that.
But
you
run
as
route,
but
you
can
run
zero
in
the
container.
A
Also
Mike,
thanks
for
mentioning
runtime
class
I,
think
specifically
around
the
sandbox
runtimes,
so
kind
of
containers,
G
visor.
That
gets
a
bit
more
interesting
because
suddenly
the
privileged
privileged
containers
become
you.
You
can
run
with
those
things
set
on
the
pod,
but
you're
still
effectively
C
unboxed
from
the
host,
so
yeah
I'm
not
sure
exactly
what
that
would
look
like
from
a
policy
perspective.
E
A
E
A
A
B
Yeah
I
think
this
discussion
is
super
helpful,
I
think,
like
everyone
else,
I
were
looking
to
see
like
what
is
the
current
use
cases
and
I.
Think
having
these
three
buckets,
well-defined
would
definitely
be
a
good
guidance
for
people
and
I
think
whether
it's
like
PSPs
or
alternatives,
those
are
kind
of
describing
the,
how
and
I
think
as
a
community.
B
B
F
E
F
F
E
F
E
F
F
E
A
Going
back
to
your
question,
Mike
of
whether
we
would
delete
cloud
security
policy,
the
indefinite
future
of
con
security
policy
shouldn't
be
that
it's
stays
as
as
in
beta
I
think
we
need
to
either
come
up
with
a
plan
to
put
it
to
GA
or
come
up
with
an
alternative
and
set
a
deprecation
plan
for
it.
So
yeah
I
think
the
eventual
goal.
A
I
I,
don't
think
that
it
should
go
to
GA
as
is,
and
so
I
would
say
that
I
I
would
like
to
see
it
eventually
get
deleted
and
maybe
there's
some
room
for
a
simplified
version.
That's
built
into
core
sort
of
has
to
be
discussed
earlier,
but
I
could
also
equally
get
on
board
with
that
simplified
piece
being
out
of
court.
A
E
You
can't
assign
this
one
to
me
so
in
certain
situations,
we've
seen
that
the
LRU
cache
is
used
by
the
token
cache
and
the
author
authorizing
webhook
cache
when
the
access
just
becomes
like
a
scan
of
the
keys
larger
than
how
those
are
configured
they
just
fall
over
so
I
I
think
we
pick
some
arbitrary
sizes
for
those
caches
a
long
time
ago
and
I
think
we
arbitrarily
picked
that
they
should
be
LRU
caches.
So
I
think
we
need
to
reevaluate
some
of
those
decisions,
but
I'm
gonna
work
on
this,
hopefully
get
something
into
117.
A
E
E
F
F
F
Could
be
sufficient
if
I
well
defined
what
all
these
cases
are
so
I
think
Mike's
use
cases,
especially
for,
like
the
certificate
app
reader
to
only
prove
certificates
that
were
made
by
an
authentication
source
that
wasn't
a
certificate
would
be
useful,
yeah
I
think
user
info
could
could
be
sufficient,
but
I
think
not
all
the
implications
both
like
what
I
think
Jordan
said
in
this.
If
it's
a
subject,
access
review
or
something
what
what
are
we
populate
there
now
consumes
that
in
fact,
I
don't
know
that
that's
all
been
answered,
yeah
I
could
see.
A
F
F
F
That
would
be
really
I'll
say,
like
you
said,
the
certificate
controller
I,
also
just
sort
of
thinking
about
aggregate
API
server,
those
backends
that
might
like
information
about
how
this
user
is
authorized,
that
that
might
be
a
so
I
think
I
think
we're
using
this
go
color
before
centers.
This
point
so.
E
E
F
I'm
in
favor
of
an
audit
entry
or
I
find
that
reason
why
I
don't
know
the
exact,
including,
but
that's
very
reasonable
thing
to
do
for
audits.
What
about
the
second
one,
encoding
extra
I
think
Jordan
I
honestly.
Both
have
some
regrets
about
what
we
did
to
certificates
in
making
groups.
I
can
probably
make
peace
with
it
and
say
sure:
let's
meet
another
field
but
I.