►
From YouTube: Kubernetes SIG Auth 20180822
Description
Kubernetes Auth Special-Interest-Group (SIG) Meeting 20180822
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
A
That
means
that,
at
that
point,
only
things
specifically
targeted
at
112
will
be
allowed
to
merge,
and
that
will
continue
for
another
week
until
code
freeze,
which
is
scheduled
for
September
4th,
at
which
point
only
bug,
fixes
and
release
blockers
bug,
fixes
that
are
release
blockers
will
be
allowed
to
merge.
So,
let's
get
reviews
wrapped
up.
A
The
second
announcement
is
that
the
pull
request
in
numerating,
sub-projects
or
Zig
off
got
opened
against
the
community
repo
thanks
Mike
for
opening
that
that's
in
progress
there's
a
little
bit
of
cleanup.
We
need
to
do
to
kind
of
tie
together
owners
files
and
things
for
components
that
are
spread
across
a
few
different
packages,
so
we're
still
working
on
that,
as
we
have
time,
probably
after
code
freeze.
A
But
if
you
want
to
take
a
look
at
the
projects
that
are
called
out
there
and
any
feedback
is
welcome
on
that.
I
saw
a
few
requests
come
in
for
the
agenda
doc.
That
doc
is
actually
shared
with
the
kubernetes
dev
mailing
list
and
the
committee's
sega's
mailing
lists.
So
if
you
are
on
either
of
those,
you
should
have
access
to
that
so
and
both
of
those
should
be
able
to
be
joined
without
any
approval.
Anyone
can
join
those
yep,
so
join
kubernetes,
dev
and/or
communities
take
off
all
right.
A
B
It's
great
wilford's
trying
to
join.
He
was
having
some
trouble.
I'll
try
and
help
him
out.
Do
we
want
to
just
go
to
the
next
thing?
I'm
gonna
come
back
to
this.
One
sure
sure.
A
A
C
So
so
we
have
a
working
group
that
has
been
meeting
since
it,
so
you
can
see
that
we
are
not.
We
have
a
proposal
to
be
a
CNC
F
working
group,
but
we
are
not
currently
we
you
could
find
us
at.
You
know
seeing
security,
slash,
safe.
We
gravity',
we
grew
out
of
a
number
of
us
who
were
working
on
specific
software
to
do
security
and
policy
for
five
native
applications
or
deployments
and
turns
out
that
you
can't
do
security
in
isolation.
C
We've
worked
really
hard
on
this
objective,
which
is
really
trying
to
illustrate
or
articulate
this
cross-cutting
concern
of
security
to
have
a
cloud
native
deployment
that
is
secure.
You
need
to
consider
a
number
of
things,
and
so
we're
specifically
the
looking
at
secure
access
policy
and
safety,
which
is
a
safety,
is
a
really
broad
word,
but
we
feel
that
it
is
bracketed
by
saying
this
is
a
concern
we're
looking
at
the
concerns
for
operators,
administrators
developers
and
end-users
across
the
cloud
native
ecosystem.
C
So
somebody
is
trying
to
do
something
five
native,
and
that
has
these
concerns.
Then
that's
in
the
domain
of
our
group.
It's
not
all
security
things.
It's
not
all
policy
things,
it's
not
all
safety
things,
but
particularly
where
the
lack
of
where
you
need
to
solve
problems
in
order
to
move
forward
in
a
cloud
native
way
right.
C
And
ideally
you
know
you
all
are
focused
on
kubernetes
off
concerns
and
then,
where
we
can
feed
you
information
about,
maybe
what
we're
discovering
from
users
of
kubernetes
or
where
people
might
be.
You
know
having
interoperability
challenges
with
kubernetes,
or
you
know
you
know,
validate
that
these
problems
are
being
solved.
You
know
across
different
technologies
and
then,
if
you
have
particular
concerns
to
bringing
to
us-
and
you
know-
and
we
could
collaborate
potentially
at
least
we'd-
be
interesting-
collaborating
on
specific
challenges.
C
So
so
we've
committed
to
delivering
a
couple
of
white
papers,
something
we
call
the
key
elements
of
the
trust
system
which
is
like
one
of
them.
How
do
we
think
about
something
being
worthy,
because
there
are
a
lot
of
people
who
are
newcomers
to
this
space
who
are
coming
from
on-premise
systems
and
the
traditional
way
of
securing
on-premise
systems?
C
If
people
are
interested
in
these
specific
use,
cases
we'll
be
publishing
those
artifacts
regularly,
so
we
can
refer
back
to
them
and
so
that
other
people
can
use
them
if
they
searches
and
then
there's
a
bunch
of
the
policy.
Folks
are
working
on
container
policy,
interface,
implementations
and
we've
volunteered
to
provide
feedback
to
the
TOC
on
anything.
That's
you
know
kind
of
related
to
the
expertise
of
our
members
and
to
our
mission
here
and,
and
then
you.
C
A
C
The
conversation
is,
there's
different
kinds
of
authorization
and
authentication.
You
have
like
service
identities,
there
are
work
load
identities,
there
are
end-user
identities
and,
depending
on
what
kind
of
identity
and
what
types
of
authorization
you're
talking
about
that
leads.
Us
down
a
different
path.
Of
course,
all
of
these
things
should
work
together,
but
understanding
what
layer
of
the
stack
is
working
on
and
what
problem
you're,
actually
solving
kind
of
helps,
focus
those
conversations
and
right
now
that
we
don't
have
good,
clearly
defined
categories.
E
F
F
F
What
kind
of
input
coming
from
the
broader
ecosystem
on
ways
that
you
know
within
the
kubernetes
ecosystem?
We
can
provide
some
features
where
there
is
shortcoming
or
figure
out
ways
to
better
integrate
with
the
rest
of
the
ecosystem.
I
think
that
would
be
really
valuable
and
then
I
was
also
going
to
just
propose
that
we
we
can
figure
this
out
offline,
but
I
have
some
sort
of
kind
of
regular
sync
up
I'd
be
happy
to
volunteer
to
be
the
sig
off
ambassador
to
save,
for
or
you
know,
it's
opened.
C
Maybe
we
can
propose
a
format
for
it
but
like
to
have
like
a
subgroup
that
includes
folks
from
both
groups
that
works
through
a
particular
open
question
right
and
then
we
could
come
up
with
a
statement
or
guidance
or
something
right.
That
is,
it
isn't
a
combined
output
right
and
we
can
present
it
to
both
groups.
C
A
Think
it's
definitely
interesting.
I
did
especially
for
something
that
is
trying
to
identify
things
that
apply
across
a
broad
scope,
having
having
a
way
to
kind
of
contact,
people
who
are
interested
in
this
area
in
all
of
these
different
projects
and
say:
hey,
the
question
came
up
about
this
thing.
How
do
you
do
it?
Have
you
ever
thought
about
this?
Does
this
apply
to
you?
If
it
does?
How
have
you
solved
that?
A
C
C
One
of
our
ideas
is
to
just
kind
of
sweep
through
all
the
projects,
and
you
know
maybe
roughly
categorize
them
into
you
know
what
kinds
of
concerns
that,
like
you
know,
these
ones
have
a
policy
implementation.
These
ones
are
a
policy
solution.
These
ones,
you
know,
are
like
just
kind
of
put
them
into
some
set
of
categories
and
then
reach
out
to
each
a
lot
of
them.
C
C
There
are
many
experts
who
pretty
much
have
an
answer
that
everybody
would
agree
to.
But
if
you
don't
have
that
answer
easily
available
to
you,
then
you've
got
to
go
down
a
rat
hole
which
may
get
you
attached
to
a
solution
which
isn't
quite
as
good,
right
and
and
we're
just
seeing
this
happen
repeatedly
as
people.
You
know
move
to
the
cloud
right
that
the
gaps
in
knowledge
either
just
slow
them
down,
or
can
you
know
kind
of
create
divisions
where
there?
C
If
there
was
more
knowledge
about
what
was
going
on,
then
there
wouldn't
be
conflict,
and
maybe
there
are
some
actual
conflicts
but
like
so
at
the
beginning,
for
example,
we
had
a
big
division
of
our
back
versus
a
back
right
and
through
a
lot
of
the
presentations.
It's
sort
of
clear,
like
I,
think
it's
become
clear,
and
you
know
we've
done
some
writing
about
this,
but
we
haven't
like
really
finalized
it
that
actually
there
are
use
cases
that
are
appropriate
for
a
back.
C
Often,
a
back
is
layered
on
top
of
our
backs,
so
it's
not
an
either/or
in
almost
every
case
and
to
be
actually
articulate.
These
are
the
specific
use
cases
where
a
back
is
high
value.
You
know
generally
recommended
to
be
on
top
of
in
our
back
system
or
whatever
the
right
answer.
Is
there
and
like
hash
it
out,
make
it
clear
so
that
we
don't
have
arbitrary
and
you
know,
divisions
in
the
community
and
if
we
can
get
aligned
on
those
things.
I
think
that
would
just
streamline
our
work.
B
There
I'm
curious,
if
you
think
the
very
broad
scope
here
is
a
temporary
thing
or
a
permanent
thing,
so
it
sounded
like
like
I
could
envision
it
being
a
all
like
we're
figuring
out
where
we're
going
to
focus
and
then
we're
gonna
like
laser
focus
on
these
things.
We're
gonna
stack,
rank
and
prioritize,
and
just
do
these
small
things
or
like
I,
also
heard
you
mention
like
a
clearinghouse,
if
you
think
you're
going
to
stay
like
that,
broad
scope
is
actually
intentional
and
you're
gonna.
Keep
that
broad
scope
like
indefinitely
well.
C
I
think
that
the
I
think
the
broad
scope
is
intentional
right
and
what
we
and
our
approach
is
to
to
chart
out
what
are
the
categories
within
that
broad
scope
and
look
at
what
are
the
actual
problems
that
operators
administrators
developers
are
having
creating
cloud
native
systems
right
in
these
cats,
like
our
people?
Is
it
that
this
one
category
is
all
doing
things
in
different
ways
in
confusing
everybody
right
or
is
it
that
these
two
categories?
C
So
that's
you
know.
That's
part
of
the
key
elements
of
trustworthy
system
like
can
we
just
bucket
these
security
concerns
so
that
we
we
can
just
you
know
we
can
be
clear
without
what
we're
talking
about
when
we
have
a
problem
and
then
you
know-
and
you
know,
produce
these
white
papers
that
can
kind
of
streamline
the
efforts
of
the
different,
odd
native
projects.
A
Yeah
I
think
there's
value
and
kind
of
identifying
or
summarizing
the
different
approaches
take
my
different
projects,
just
so
that,
if
you're
here
coming
to
this
area
for
a
new
project
or
trying
to
add
something
to
an
existing
project,
you
don't
have
to
go,
become
an
expert
and
the
other
50
CNCs
projects
to
kind
of
figure
out
what
what
people
are
doing
so
being
able
to
summarize
and
say
this.
This
is
work
well,
this
doesn't
work
well,
but
the
things
useful
thing.
C
Is
like
we
like,
the
people
who
started
this
group
actually
like
most
of
us,
actually
have
a
problem
we
would
like
to
solve,
but
we
can't
solve
it
without
other
people,
and
you
know
like,
for
example,
I
worked
at
Google.
In
my
you
know,
one
of
my
sub
teams
works
closely
with
OPA
and
implements
actually
based
access
control
for
firebase.
You
know,
then,
there's
you
know.
I
am
an
role
based
access
control.
In
there
you
know.
C
I
talked
to
JJ,
because
I'd
met
him
city,
history
of
community,
and
he
was
like
well,
you
can't
like.
Why
are
you
promoting
a
policy
language?
That's
they're
not
going
to
make
that's
not
going
to
create
a
secure
architecture
and
I
was
like
well,
of
course
it's
not
gonna,
create
I'm
I'm,
never
saying
that
policy
languages
Nessus
by
in
and
of
itself
going
to
create
a
secure
architecture,
and
so
it's
in
order
for
that
project
to
be
successful.
C
You
know
and
to
do
that
like
people
have
to
be
making
the
same
assumptions
and
it's
sort
of
a
way
to
pull
that
out
and
agree
on
it
with
each
other,
because
a
lot
of
us
end
up
having
to
do
like
in
order
to
figure
out
how
to
make
ourself
interoperable.
It's
like
pairwise
with
a
whole
bunch
of
different
or
open-source
projects,
and
so
a
number
of
us
were
finding
us
finding
having
to
do
these
pairwise.
You
know
Interop
discussions
and
we
were
like
well.
Okay,
just
all
talk
together.
We
can
streamline
this
bit.
A
B
A
C
And
I
think
that
you
know
Tim
Murphy
any
of
you
would
feel
comfortable
saying
like
yes,
we
believe
this
proposal
is,
you
know
consistent
with
having
a
sig
off
kubernetes.
You
know,
like
you
know,
to
whatever
extent
people
in
the
group
would
feel
comfortable
chiming
in
to
to
mention
how
we
think
that
our
or
different
different
groups
are.
A
A
Broad
scope,
combined
with
like
sort
of
not
advisory
like
more
informational
output,
is
interesting,
ronger
coming
out
of
a
working
group,
but
at
the
same
time,
like
you
said
at
the
beginning,
this
area
is
very
difficult
to
going
to
be
prescriptive.
In
once
we
get
down
to
actual
implementations
well.
D
Jordan,
you
know
we
brought
in
either
Sedan
Shaw
sorry
most
I
was
double-booked,
came
in
a
little
bit
late,
so
we
have
Erica
who's.
Also
in
the
policy
working
group
policy,
de
kubernetes
policy
working
group
was
going
to
form
a
CNC
F
level
policy
working
group
and
we
decided
to
merge
our
our
efforts
together
and
the
delta
between
you
know
how
the
the
kubernetes
policy
working
group
is
operating
in
an
ongoing
fashion
versus
what
we're
doing
at
the
CN
CF
is
pretty
different.
D
Now
they're,
you
know,
looking
at
the
pr
is
looking
at,
you
know
in
in
the
the
kubernetes
working
groups,
it's
it's
all
concrete
delivery
and
tracking
towards
landing
stuff,
which
is
fantastic,
and
you
know
in
in
safe.
We
are
you're
looking
at
the
the
cross-cutting
concerns
and
how
you
know
things
come
together
at
the
edges
and
and
then
sort
of
you
know
stepping
back
from
that.
How
that
all
you
know
comes
together
as
a
coherent
picture,
so
out
of
necessity,
we
have
to
take.
You
know
ten
steps
back
to
really.
A
Yeah
I'm
not
saying
it
doesn't
make
sense
I
just
it's
hard
to
evaluate
kind
of
like
the
question
about
whether
this
kind
of
broad
scope
is
a
short-term
or
long-term
thing
like
envisioning.
What
this
working
group
will
look
like
kind
of
once,
some
of
the
big
10,000
foot
view
use
cases
are
identified
and
kind
of
agree
on
terminology
and
yeah.
A
D
A
D
First
working
group-
that's
landing
post,
the
initial
batch
I
guess
the
ad
that
the
serverless
working
group
that
you
know
was
kind
of
boot,
strapped
in
after
the
the
CI,
CD
and
storage.
But
you
know
in
the
definition
of
you
know
what
the
CN
CF
expects
is
a
working
group.
We
are
the
first
ones
to
go
through
the
process
of
you
know,
defining
that
and
working
out
the
kinks
of
that
system.
So
you
know
the
honest
reality
is
you
know,
CN
CF
doesn't
even
know
yep.
C
A
A
G
So
this
is
about
pull
requests
to
modify
the
image
review,
web
book
interface
and
I.
Think
Jordan
and
Tim
are
currently
as
Rubeus
on
here.
So
the
background
here
is
that
we're
using
it
for
doing
authorization
based
on
policies
for
the
operation,
and
at
the
moment
it
can
only
basically
say:
yes,
it's
allowed
or
no
it's
not
allowed
and
here's
the
string.
G
Admission
controller
actually
already
does
create
annotations
that
signal
that
there
was
a
fail
open
because
the
Viper
couldn't
be
reached
at
the
court
appointment
time.
So
the
web
hook
is
already
a
pull.
Request.
Fully
introduces
the
possibility
for
the
image
review
web
back-end
to
send
back
set
of
annotations
that
the
plugin
will
then
add
to
the
thoughts
back
so
that
you
can
signal
things
like
hey.
There
should
be
reviewed
for
one
waste
or
another.
A
A
That
raises
those
questions
about
who
can
change
these
annotations?
What
happens
if
the
flag,
the
annotation
flag,
that
says
this
needs
review,
gets
erased
like
today?
We
don't
have
that
issue
because
we're
not
using
annotations
for
that,
but
as
soon
as
you
start
using
them
for
that,
you
have
to
consider
like
chain
of
trust
as
far
as
anything
downstream
that
could
modify
the
annotation.
So
that
seems
a
little
suspect
so.
G
It
just
just
to
be
very
clear:
I,
don't
think
this
is
a
method
for
declaring
something
like
the
restart
there's
two
purposes
here.
One
is
to
put
something
in
the
audit
lock
just
so
that
it's
like
query
bubble
later.
The
second
one
is
just
to
have
like
an
informational
record
like
in
the
end.
What
you
want
to
do
is,
and
that's
something
we're
also
working
to
do,
a
regular
audit
of
everything
that
is,
or
was
deployed
and
half
a
separate
system
that
gives
a
clear
order
right.
G
So
this
is
more
as
an
intermediate
system
where
you
say:
okay,
it's
not
something
you
can
rely
on
like
the
existence
or
nonexistence.
The
annotations
shouldn't
make
you
feel
safe
or
less
safe,
and
that
actually
is
the
same,
would
be
feel
open
at
the
moment,
but
it
could
be
removed.
It's
not
an
good
signal,
I
think
at
the
moment
for
the
operator
to
assure
that.
A
G
The
communication
here
is
would
be
that,
yes,
these
annotations
are
not
protected
against
modification.
So
therefore,
they
should
not
be
relied
on
as
clear
signals
or
they
should
not
be
relied
on
as
or
the
absence
of
an
annotation
should
not
be
relied
on
as
a
guarantee
of
any
security
problem,
and
that,
as
I
said,
that
is
the
same
as
currently
was
fellowman,
where
it's
actually
not
properly
communicated.
F
F
I
think
addresses
the
first
use
case
of
just
kind
of
you
know
surfacing
this
information
in
the
audit
log.
It
doesn't
really
address
the
use
case
of
grabbing
everything
in
the
cluster
and
seeing
what
needs
to
be
audited
at
a
later
date.
Although
you
could
hopefully
pull
that
out
of
the
audit
log
itself
yeah,
it
does
make
me
nervous
kind
of
checking
in
an
annotation
into
the
API
right
now,
because
we
are
sort
of
very
anti
annotation
at
the
moment
for
official
api's
and
having
this
actually
checked
in
makes
it
an
official
API.
G
So
yeah
I'm
happy
to
do
is
just
move
this
to
the
audit
log
I.
Think
for
for
most
of
what
we
want
to
do,
that's
actually
quite
quite
sufficient,
because
that
leaves
a
record
somewhere
and
I.
Think
that's
the
first
thing
that
that
we
will
achieve
and
for
the
second
portion.
Maybe
a
label
is
the
better
one,
because
that
then
actually
makes
the
selection.
A
H
G
A
G
Okay
sounds
good:
okay,
maybe
was
later
so
Tim
and
George
still
do
you
write
reviews
for
this
yeah,
okay,
so
I'm
good,
and
so
the
big
goal
on
my
side
ideally
would
be
to
get
this
into
this
release
or
I'll.
Try
to
like
make
the
changes,
ASAP
and
then
opinion.
A
F
F
There
was
an
issue
with
now
we're
kind
of
exposing
these
types.
The
events
and
policy
types
which
aren't
technically
rest
types
or
serve
types
within
the
schemes
to
Stefan
was
recommending.
We
break
because
this
is
served.
I
break
this
out
new
zone
API,
so
I
just
broke
it
out
and
do
a
separate
API
called
audit
configuration.
Ok.
A
F
Hopefully
that
works
out
for
everyone.
It
is
kind
of
an
interesting
question
right
there
as
far
as
having
an
API
where
you
may
want
the
known
type
in
the
scheme,
so
you
can
encode
and
decode
it
like
maybe
you're
taking
it
from
command
line
flags
or
whatever,
but
you
may
not
necessarily
be
serving
those
types.
A
F
A
F
You
know
more
confident
as
we
go
J
with
the
advanced
auditing
stuff.
We
are
completely
out
of
the
way
that
I
think
may
be
a
good
thing,
but
yeah.
We
need
to
adapt
our
merge
first
and
then
the
other
PR
is
kind
of
hinging
on
what
happens
in
this
one.
The
other
viewers
just
got
the
implementation
as
far
as.