►
From YouTube: Kubernetes SIG Auth 20181003
Description
Kubernetes Auth Special-Interest-Group (SIG) Meeting 20181003
Meeting Notes/Agenda: https://docs.google.com/document/d/1woLGRoONE3EBVx-wTb4pvp4CI7tmLZ6lS26VTbosLKM/view#
Find out more about SIG Auth here: https://github.com/kubernetes/community/tree/master/sig-auth
A
C
Right,
so
this
is
just
a
heads
up
that
the
steering
committee
kind
of
delegated
to
the
product
security
team.
This
is
the
group
that
handles
vulnerability,
reports,
security
issues
with
Q
to
figure
out
how
to
go
about
getting
a
third
party
security
audit,
and
so
there
was
announced
meant
for
people
who
were
interested
in
participating
and
few
people
jumped
in,
and
so
there's
been
a
team
of
three
people
selected
to
kind
of
interact
with
a
party
vendor
to
do
an
audit.
C
So
this
is
going
to
be
evaluating
different
vendors
and
then
interacting
with
them
as
the
ones
selected
to
to
perform
an
audit.
So
there's
a
link
to
the
issue
tracking
this
and
I
think
this
will
probably
be
structured
as
like
a
working
group
type
of
thing
within
sig
off.
So,
if
you're
interested
to
follow
that
and
keep
an
eye
out
for
future
developments,
but
I'm
excited
about
that
getting
getting
another
set
of
eyes
on
things,
external
evaluation,
I
think
will
be
helpful.
C
Some
of
you
know
this
already,
but
I've
actually
joined
the
kubernetes
team
at
Google,
and
so
that
puts
us
in
the
undesirable
position
of
all
three
chairs
for
this
thing
being
from
the
same
company,
so
to
fix
that
a
little
bit
I'm
actually
going
to
be
stepping
down
from
the
chair
role
and
proposed
that
no
Khanh
be
my
advertisement,
so
Moe
is
from
Red.
Hat
has
been
working.
One
community
is
an
open
shift
for
a
couple
years,
really
familiar
with
the
OAuth
authorization
stack
and
anyway.
C
B
C
The
data
annual
and
like,
like
I,
mentioned
I'm
a
lot
of
what
I'm
due
to
day
to
day,
will
still
be
similar.
So
this
is
I,
see
this
more
of
an
opportunity
to
kind
of
get
more
people
involved
in
helping
run
the
sig
and
yeah
more
voices
kind
of
spread
some
of
the
work
out
and
make
sure
we
continue
to
have
representatives
from
different
areas
of
the
project.
D
D
E
I
am
I
kind
of
moved
to
move
this
one
up
as
an
announcement
looks
like
it's
not
yet
refreshed
so
yeah
I
am
I.
I
wanted
to
take
this
opportunity
to
introduce
myself.
I
will
be
the
113
release
lead
for
Cuban
ADIZ
and
which
started
apparent,
which
started
on
October
1st,
which
is
this
Monday,
and
it
goes.
The
release
itself
goes
until
the
first
week
of
December.
E
If
in
Cuban
it
is
there,
I
sent
out
a
kickoff
email
which
outlines
the
schedule
and
a
few
process
changes
and
the
time
constraint
that
this
release
is
under
it's
one
of
the
shortest
releases.
It's
about
just
10
weeks
gave
me
an
account
that
you
cube
cons
and
Thanksgiving
and
then
the
last
two
weeks
of
December.
E
We
are
aiming
to
get
the
release
out
the
first
week
of
December
before
we
go
to
Cuba
on
Seattle,
so
that
said,
I
wanted
to
just
meet
with
all
the
SIG's
and
highlight
a
little
bit
about
the
future,
slash
the
enhancement
load
that
you
guys
will
be
taking
up
for
this
release.
We
are
not
formalizing
it,
but
the
release
team
is
kind
of
looking
at
this
release.
More
like
a
stability
release
in
the
sense
we
wanted,
we
wanted
to
encourage
sakes
and
Enhancement
owners
to
work
more
on
stability.
E
Related
bug,
fixes
slash
features
rather
than
taking
on
anything,
that's
sizable
and
risky
in
this
in
this
113
timeframe,
so
the
step
stability
enhancements.
We
are
looking
at
landing
anything
that
got
deferred
from
the
last
few
milestones.
Slash
any
bug
fixes
that
you
might
want
to
get
out
or
just
coverage
and
more
our
improving
the
test
cases
itself.
So
that
will
start
the
formal,
a
collection
of
all
the
features
starting
next
Monday
October,
II
and
you'll
hear
more
from
our
features
lead
around
this,
but
I
just
wanted
to
meet
with
ahead
of
time.
E
Teachers
drive
home
the
stack
if
you
could,
if
you
could
all
keep
that
in
mind,
while
planning
your
113
feature,
load
that'll
be
awesome,
and
we
also
will
be
working
closely
with
thick
Ark
this
time
so
that
they
can
wet
the
feature
list
to
make
sure
that
we
can
kind
of
have
an
idea
of
the
stability
release
going
forward.
Maybe
if
it
will
stand
for
the
future
years
as
well,
so
yeah,
that's
a
heads
up.
So
if
you
have
any
questions
more
than
happy
to
answer.
E
If
not,
I
have
listed
three
features
that
are
currently
in
130
from
SiC
earth
and
they
are
all
ones
that
were
differed
from
one
twill.
My
ask
is,
if
the
future
owners,
if
it
could
go
into
the
issues
and
then
indicate
what
is
it
that's
pending
for
this
to
come
in
to
130
that'll,
be
great?
Is
it
co,
pending
code
code
fixes
or
dogs
or
tests?
That
will
be
really
helpful
for
us
to
understand
the
level
of
confidence
for
each
of
these
creatures.
B
B
E
Think
that's
a
completely
up
to
the
sake
and
I
think
leads,
and
owners
to
I
mean
identify
when
something
is
ready
for
beta
to
GA.
From
the
releasing
point
of
me
before
test
coverage
consistently
passing
tests,
the
gut
level
of
confidence
in
the
future
going
to
be
Dungy,
especially
where
we,
where
we
expect
the
quality,
needs
to
be
quite
high
and
also
the
documentation.
I
guess.
D
E
D
D
E
Again,
Jordan,
you
can
correct
me
because
in
case
I
miss
coding
something,
but
in
general
we
track
it.
You
track
it
for
a
milestone
if
it's
graduating,
if
it's
going
to
change
from
beetle
able
to
you
know,
GA
indicates
if
not.
If
it's
going
to
stay
in
beta
and
you're
doing
some
more
enhancements,
I,
don't
I
mean
we
don't
we
don't
like
track?
We
practically
ours,
as
are
the
bug
fixes
as
113,
but
not
the
feature
itself
remains
in
the
previous
milestone.
Thank.
E
C
It
either
stays
there
or
it
gets
put
into
like
a
upcoming
release
like
future
milestone.
Yeah.
The
key
is
that
we
want
to
be
able
to
look
at
features
in
the
current
milestone
and
understand,
like
what's
gonna
hit,
release
notes
what
needs
Docs,
what
needs
to
have
something
done
to
it
by
the
end
of
the
current
milestone.
So
it's
it's
not
a
great
state
machine
Mike
because,
like
in
a
milestone,
it
might
go
to
like
future
for
a
release
that
I
might
come
back
and
stage
is
being
looked
on,
not
great
right.
C
E
Then
I
subtract
a
label
on
these.
Each
of
these
feature
issues
that
one
would
get
removed
if
this
is
not
being
tracked
actively
like
a
feature
graduating,
but
we
also
have
a
bug
triage
lead
who
will
look
into
PR
some
issues
separately
that
are
yeah,
so
we
kind
of
catch
any
word
that
goes
on,
but
yeah.
It's
not
like
perfect
state
machine.
At
this
point.
B
B
All
right,
let's
move
on
to
our
next
topic.
Patrick,
are
you
on
the
call
yeah?
Obviously,
we've
been
going
doing
up
the
dynamic
got
an
API
for
the
recent
film
we
see,
Daniel
come
as
a
pair
of
your
kind
of
future
changed
things.
I
was
having
a
meeting
over
that,
resulting
in
possibly
skipping
down
policy,
I'm,
good,
I've
kind
of
done
that
work
now
and
now,
I'm
wondering
if
we
can
maybe
sold
out
versioning
as
opposed
to
skipping
down
what
we
currently
have
and
that's
where
the
discussions
are
today.
B
Just
to
kind
of
provide
a
bit
more
context
for
folks
who
haven't
been
following
this:
we
I
guess
so.
The
dynamic
audit
cap
originally
did
not
have
policy
in
there
and
the
idea
was
to
use
the
just
use
the
statically
defined
cluster
audit
policy
for
all
dynamic
backends,
and
then
we
and
then
patch
followed
up
with
a
update
to
the
cap,
which
involved
incorporating
in
the
basically
doing
a
policy
/
back-end
that
used
the
same
API
as
the
statically
defined
policy.
B
Daniel
Smith
of
API
machinery
had
some
issues
with
the
with
the
way
that
we
did
the
policy
API
and
concerns
about
that,
and
we
had
a
discussion
on
that
and
in
order
to
unblock
unblock
progress
on
the
dynamic
audit
API,
we
decided
to
scope
the
dynamic
audit
api's
policy
down
to
just
a
single
top-level
action.
That
applies
to
every
request.
So,
instead
of
having
all
these
complex
rules
to
decide,
you
know
this
request.
It's
going
to
be
at
the
request
level
or
the
response
level
or
the
metadata
level.
B
You
just
set
one
value
for
all
requests
and
then
the
idea
is
that
the
any
further
filtering
on
that
would
be
delegated
to
the
back-end
itself
and
the
back-end
could
be
a
proxy
which
does
the
filtering
and
then
pushes
off
to
the
final
destination,
and
so
that's
kind
of
that
brings
us
up
to
where
we
are
today
and
then
in
Patrick.
If
I'm
understanding
correctly,
you
are
concerned
about
this
direction
and
worried
that
it
affects
the
usability
too
much.
Is
that
correct
yeah?
It's
a
couple
things
as
we
started
talking
about
it
internally.
B
One
was
kind
of
usability
and
I
mean
maybe
I'm
cheating,
but
on
that
issue,
but
the
other
ones.
Definitely,
as
we
plan
areas
of
okay
sue,
maybe
we
want
to
do
a
V
to
the
policy
API,
which
is
kind
of
what
Daniel
is
asking
for,
maybe
that's
tolls.
Maybe
that
never
happens
now.
We've
kind
of
limited
our
path
to
GA
in
regard.
B
F
B
C
Yeah
I
kind
of
agree
about
like
coherence
between
the
file
based
config
and
dynamic
config,
the
issue
with
versioning
when
you're
doing
a
file
based
API,
you
don't
have
to
worry
about
round-tripping.
So
it's
pure
consumption
like
it's,
read
this
file
and
then
act
on
it.
You
don't
ever
have
to
worry
about
having
to
translate
that
v1
policy
into
a
v2
policy
for
someone
else
to
consume
and
when
you're
doing
rest
api's.
You
do
have
to
worry
about
that.
C
So
if
we
commit
to
this
being
a
REST
API
and
we
let
people
submit
and
persist,
is
B
1
or
B
1
beta
or
whatever
the
level
we
start
the
REST
API.
Yet
let
them
persist
policy
objects
in
that
format
and
then
later
want
to
kind
of
radically
change
it
and
transform
it
and
I
make
it
resemble,
make
it
something
that
doesn't
resemble
v1
at
all.
C
That's
that's
very
difficult
to
do
when
it
when
it's
a
served
API,
because
you
have
clients
requesting
the
same
objects
at
different
versions,
so
that
that's
why
it's
versioning
isn't
a
magic
bullet
for
the
served
persisted
objects.
It
helps
a
lot
for
the
file
age,
guys
like
you,
could
come
up
with
something
completely
different
for
the
file
based
API
ability
to
and
and
consume
both
of
those
anyway
I
guess.
C
Versioning
we
can
let
you
make
some
types
of
changes:
I,
don't
think
it
can.
Let
you
make
ones
as
drastic
as
what
Daniel
was
describing,
but
you
you
can't
transform
the
current
format.
That's
used
in
the
file
config
to
something
like
what
he
was
describing,
where
it's
not
a
list
of
sort
of
progressive
filtering
rules.
Okay,.
C
You
we
can't
remove
the
one
until
v2
is
out,
because
you
can't
duplicate
just
be
one
stable
object
API
until
the
replacement
is
that
is
at
least
as
stable
as
ready,
and
the
v1
and
v2
policy
objects
are
in
the
same
namespace.
So
if
you
created
a
one
policy
object
that
has
to
be
able
to
be
translated
into
a
bTW
policy
object.
B
B
C
Remove
things
and
gonna
you
can
remove
things,
but
it
you
have
to
take
a
long
time
so
have
to
go
from
like
b1
deprecated
in
v1,
round-tripping
to
B
2,
and
then
once
you
go
from
v2
to
v3,
you
can
work
with
it
because
it
was
deprecated
at
the
stake
with
me.
It's
a
long
process
and
it's
mostly
hypothetical
at
this
point.
Yeah.
C
B
B
C
C
B
C
So
I'd
be
curious
to
maybe
hear
from
it's
good
to
know
that
you
guys
haven't
encountered
it.
If
there
are
other
people
who
have
experience
with
you
all
that
stuff,
that
might
be
something
to
kind
of
put
out
a
call
for
and
say
how
are
people
using
the
current
cloud-based
thing
like?
Would
it
be
valuable
to
be
able
to
define.
B
C
So
for
action,
items
I
think
it
probably
worth
while
the
clothes
Lucas
Daniel
asked
about
like
starting
with
what
we
have
and
considering
whether
like
getting
concrete
descriptions
of
the
use
cases.
He
is
concerned
about
that.
This
doesn't
work
well
with
and
if
there's
ways
that
the
current
approach
could
be
extended
to
work
with
these
use
cases
if
they
became
important.
C
B
B
In
terms
of
just
kind
of
making
progress
here,
you
know
I
think
that
the
the
approach
that
we
sort
of
ended
up
with
at
the
end
of
the
last
meeting
of
just
kind
of
having
the
top-level
API
I
think
that
that
is
compatible
with
any
of
the
directions
forward.
That
we
go,
including
you
know,
taking
the
whole
static
policy
format.
B
So
so
my
recommendation
is
to
basically
proceed
with
that
in
terms
of
implementation
and
then,
in
parallel,
we'll
kind
of
continue
these
conversations
about
what
the
right
API
is
and
and
go
from
there
that
make
sense.
Oh
yeah
I've
got
that
we're
pretty
much
done
and
you
have
your
feedback
on
the
cab
just
make
sure
inline
all
there
and
as
long
as
we're
I
guess.
Okay
with
you
know,
mutate
that
as
we
get
a
beta
nga
everybody's
kind
of
comfortable,
that
concepts
said
super
yeah.
C
Definitely
like
additional
things
going
from
alpha
beta
beta
are
very
easy.
Changes
require
consideration
if
you
change
it
in
incompatible
ways
that
can
mean
that
people
have
to
delete
all
their
alpha
data
before
they
upgrade.
Upgrading
with
alpha
is
like
you.
Do
it
at
your
own
risk.
If
you
use
a
novel
feature
so
requiring
people
to
drop
their
alpha,
data
is
always
on
the
table,
but
if
we
can't
avoid
it,
we'd
like
to
yeah
sure.
B
B
F
They
can't
make
events
by
the
default
policy
and
that
the
lack
of
inclusion
in
that
and
the
default
policy
for
evidence
I,
think
you
know
dates
back
to
you.
No
authorization
policy
before
it
was
even
our
back
and
cubed,
so
I
just
wanted
to
kind
of
get
people's
feelings
for
like
pros
or
cons
of.
Having
that
permission
and
like
the
editor
and
admin
roles,
I
kind
of
laid
out
some
of
my
thoughts
related
to
it
like
how
you
could
use
it
and
how
it
could
possibly
be
abused.
C
A
C
Like
an
observable
claims,
they
have
just
enough
programmatically
recognizable
things
and
then
to
ensure
that
people
have
used
them
for
like
sending
messages
from
one
component
to
another.
I,
don't
know
this
I
think
anyone
who's
using
messages,
their
events
and
for
highly
privileged
things
is
kind
of
crazy,
especially
considering
that
every
component
in
the
system
is
given
event
by
permissions.
Basically,
every
controller,
every
component,
just
not
like
human
users,
so
it's
not
like
it's
a
tightly
held
religious
thing,
it'd,
probably
be
worth
like
asking
kind
of
the
user
base
in
some
way
we're
considering
this.
C
C
C
D
D
E
C
F
D
B
C
D
A
C
B
C
That
kind
of
that
kind
of
question
used
to
go
to
kubernetes
users.
I
would
see
questions
about
usage
patterns
every
once
in
a
while
I
think
that
may
be
moved
to
the
discussion
board.
So
I
don't
know.
Maybe
maybe
asking
a
few
places
going
to
pointing
to
the
issue
for
to
unify
the
conversation.
I'm
not
opposed
to
you.
B
F
B
C
C
B
This
is
more
of
a
heads
up
for
kind
of
coming
up.
I
would
like
to
deserve
some
time
to
discuss
sort
of
2019,
broader
directions
and
planning
and
there's
some
kind
of
central
themes
of
the
project
that
I
want
to
talk
about
a
bit.
How
we
can
how
we
can
better
support
some
things
like
sustainability
and
reliability,
and
so
maybe
you
just
kind
of
start
thinking
about
some
of
those
things
and
what
we
can
do
as
a
stake.
And
then
we
can
sort
of
discuss
that
more
in
two
to
four
weeks.
Maybe.