►
From YouTube: Kubernetes SIG Auth 20180221
Description
Kubernetes Auth Special-Interest-Group (SIG) Meeting 20180221
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
B
C
So
this
is
the
implied
list
in
my
series
that
changes
I
want
to
get
into
110.
So
far
it
has
not
been
reviewed
I.
C
E
D
Yes,
just
rounding
out
the
documentation
for
that
game
is
powered
OPR
that
we
committed.
So
if
anyone
has
any
comments
on
what
the
top
needs
to
change,
how
it
needs
to
change
where
it
needs
to
live,
take
a
look
at
that
PR
and
associated
issue
post
your
comments
there
we'll
try
and
get
it
in
in
quantity.
D
B
So
these
are,
these
are
the
open
issues.
Here
we
talked
about
the
token
Authenticator
there's
a
couple
audit
a
PR
is
open.
Actually,
I
did
want
to
call
out
that
one
of
the
one
of
the
open
issues
is
to
move
advanced
auditing
to
GA
in
110,
I,
don't
know
if
Mick
or
Stefan
or
on
the
call,
but
I
do
think.
We
should
consider
plunging
GA
on
audit
out
a
release,
since
it
seems
like
there's
still
some
API
level
concerns
with
auditing
there.
Any
thoughts
on
that.
B
B
B
G
G
A
It
seems
to
me
and
if
I'm
too
far
off,
let
me
know,
but
it
seems
to
me
that
the
goal
is
to
sort
of
define
some
sort
of
API
that
looks
kind
of
like
a
pod,
but
is
more
for
very
isolated
workloads
that
we
were
basically
describing
as
a
sandbox
that
it
be
some
sort
of
isolated
version
of
a
pod
where
all
the
security
defaults
are
set
up
in
such
a
way
that
they're
extremely
restricted,
rather
than
being
sort
of
opened
by
default
and
restricted
in
them
later.
Is
that
a
fair?
So
let.
B
Think
one
of
the
one
of
the
key
differences
I
say
with
Linux
container
isolation
and
the
sandbox
is
in
general.
The
way
to
further
isolate
Linux
containers
is
like
I'm
scoping
down
the
capabilities,
and
this
is
something
that
requires
a
certain
amount
of
expertise
in
Linux
technologies
and
also
is
very
workload
specific
and
not
portable
between
different
workloads,
and
so
that
the
investment
that
you
have
to
put
into
kind
of
hardening
those
containers
doesn't
doesn't
scale
to
all
of
your
workloads.
B
B
If
we
employ
sandboxes
at
the
pod
lair,
so
you
know
kind
of
just
add
a
sandbox
bit
on
the
pots
back,
for
example,
then
that's
much
more
consistent
with
the
current
kubernetes
resource
sharing
and
pod
models
and
would
be
much
simpler
to
implement.
But
if
we
do
decide
that
we
need
that
container
level
isolation,
then
we
need
to
explore
some
new
options,
and
so
actually
that
gets
to
the
other
piece
of
your
question,
which
was,
if
we're
whether
it's
introducing
a
new
concept.
B
If,
if
we
implement
sandbox,
is
at
the
pod
layer,
I
don't
think
we
need
to
introduce
a
kind
of
a
new
abstraction
I
think
it's
just
a
setting
on
a
pod.
Basically,
whereas
if
we
want
that
subpod
isolation,
then
we
might
introduce
a
new
sandbox
layer
between
the
pod
in
the
container
or
something
like
that.
H
What
would
the
I
guess
I?
Don't
understand
what
the
really
compelling
reason
to
look
either
sub
pod
or
containers
would
be
versus
the
sandbox
in
full
pod,
but
I
say
that,
from
a
position
of
trying
to
help,
my
current
developers
make
good
choices.
Around
q,
like
another
layer
of
abstraction
or
another
kind
of
little
security
box,
I
have
to
go
on
drawing
diagrams
from
people.
It's
probably
gonna
lead
to
less
secure
usages,
rather
than
more
so
I
don't
understand
the
motivations.
B
Yeah
so
again,
that's
kind
of
getting
it.
You
know
why
we
really
strongly
would
prefer
to
keep
it
at
the
pod
layer
instead
of
introducing
this
new
kind
of
abstraction,
new
complexity
and
whatnot.
But
the
reason
we're
even
talking
about
this
I
think
there
are
two
big
use
cases
or
like
buckets
that
a
lot
of
the
use
cases
fall
into
one
is
where
you
want
to
run
a
sidecar
that
has
higher
privileges
or
trusts
or
a
different
identity
from
other
containers
in
the
pod.
B
So
one
example
might
be
you're
running
a
web
server,
and
then
you
have
a
sidecar
that,
let's
say,
pushes
metrics
from
the
server
to
your
internal
monitoring
infrastructure
and
that
needs
that
needs
authorization
to
talk
to
that
monitoring
infrastructure.
But
you
don't
want
a
vulnerability
in
the
web
server
to
expose
that,
and
so
there
you
might
want
to
isolate
that
sidecar
from
the
web
server
or
any
kind
of
like
situation
where
the
sidecar
needs
privileged
hosts
s,
access
for
a
proxy
or
something
like
that
device
management.
I
would.
B
Yeah
I'm
hesitant
to
include
that
use
case.
It's
definitely
something
that
we've
talked
a
lot
about.
My
concern
is
that
every
example
of
that
I've
seen
that
third-party
sidecar
still
needs
to
be
able
to
access
the
main
workload.
So
an
example
might
be.
You
have
a
monitoring
solution,
that's
deployed
as
a
sidecar
that
monitoring
container
is
going
to
need
fairly
high
level
of
visibility
into
your
main
container,
and
it's
going
to
be
hard
to
sandbox.
B
That
another
example
is
the
the
sto
proxy,
where
it's
a
little
easier
to
sandbox,
but
you're
terminating
your
TLS
in
the
sto
proxy,
which
means
it
has
access
to
all
of
the
web
traffic
going
into
that
supported
container
and
the
kind
of
question
the
like
how
much
security
you're
really
gettin
by
sandbox.
In
that.
B
That's
the
another
example
of
this
is
like
a
software-as-a-service
SAS
provider,
where
you
have
you're
running
some
kind
of
untrusted
user
code
in
one
container,
and
you
have
your
sort
of
like
trusted.
First
party
sidecars
that
either
manage
that
user
container
or
potentially
expose
some
services
to
it
within
the
same
network.
Namespace.
B
But
the
suggestion
I
got
for
how
to
make
this
decision
on
how
to
move
forward
on
this
is
to
enumerate
all
of
the
really
specific
examples
that
we
can
come
up
with
for
needing
this
and
then
to
examine
what
the
alternative
solutions
are.
So,
basically,
if
we
went
with,
if
we
move
forward
with
pod
level
isolation,
what
does
that
mean
for
these
use
cases?
Are
there
alternative
solutions,
and
so
I
will
be
sharing
out
a
document
soon,
and
if
anyone
has
other
examples
of
these
cases,
I'd
really
appreciate
input.
There.
J
E
So
we've
had
some
discussions
at
some
of
House
staff
meetings
about
potentially
doing
a
Corinth
bug
bounty
program.
The
idea
would
be
to
have
a
bug
on
a
fork
or
with
some
additional
suggested
security
best
practices
like
if
you
and
it
puts
the
kriti
policy
properly
and
all
those
kinds
of
things.
The
idea
is
really
to
attract
additional
security,
researchers
and
and
kind
of
get
people
excited
about
the
security
of
Corgan
ace.
So
I
think
I
said
this.
E
E
Great
yeah
thanks,
so
you
know
in
general.
Is
this
something
that
we'd
like
to
pursue?
And
one
thing
in
particular
that
to
keep
in
mind
is
that
were
we're?
Definitely
gonna
see
an
uptick
in
the
reports
of
vulnerabilities
to
the
team
and
is
that
something
that
we're
willing
to
address
in
the
next
couple
of
months.
H
E
I
mean
to
take
step,
backs,
I
didn't
give
any
any
of
you.
The
idea
would
be
to
have
e
the
pros.
Lawyers
have
a
third
party
platform.
E
E
Do
we
think
that
the
scope
is
gonna
be
well
enough
to
find
and
that
the
bugs
are
gonna,
be
repeatable
across
across
different
platforms
and
different
builds,
and
then
to
what
to
what
brought
I
think
Robert
was
just
saying
like
do
we
know
that
we
can
actually
handle
the
bugs
that
come
in
that
are
legitimate
like?
Are
we
willing
to
actually
jump
on
these?
Presumably
an
influx
of
p0
s
and
P
ones
coming
in
I.
K
H
H
Last
time,
I
looked,
there
were
only
a
handful
of
people
doing
vulnerability
management
for
kube,
which
is
fine
and
in
many
ways
good,
but
you
run
into
problems
of
running
around
then
chasing
development
leads
and
people
in
the
various
stakes
and
other
areas
to
actually
come
and
have
a
look
at
these
bugs.
So
it
it's
wider
than
just
the
immediate
security
community.
I
mean
you
mentioned
money
and
things
it's
not.
Ibm
is
Phillip.
H
But
the,
but
the
point
I'm
me
and
during
towards
is
that
this
needs
to
be
a
wider
conversation
with
the
various
tech
leads
and
things,
because
a
lot
of
stuff
is
going
to
land
on
their
desk,
which
it
happens
infrequently
but
will
probably
ramp
up
and
will
include
things
that
the
security
team
thought
was
a
problem
that
turned
out
to
not
be-
and
you
know
that
raises
frustration
which
increases
the
degree
of
friction
that
you
have
between
a
security
team
and
normal
developers
and
all
that
fun
stuff.
It
quickly
becomes
a
difficult
thing
to
manage.
K
The
difference,
though,
is
that,
like
our
security
team,
is
people
who
contribute
to
kubernetes
so
like
a
lot
of
the
times
like
we
actually
know
if
it's
like
a
real
bugger
or
not
I,
don't
know
I
just
feel
like,
like
there's
a
lot
of
context
into
what
it's
happening.
But,
yes,
we
do
have
to
find
the
teams
that
can
go
then
say
fix
the
bug
specifically,
if
it's
not
something
that
we
necessarily
have
like
expertise
in,
but
I
feel
like
it's
more
community
effort
than
like
were
throwing
something
over
a
wall.
K
H
H
You
can't
expel
that
small
handful
of
people
to
understand
everything
well
enough
to
know
whether
or
not
it's
a
genuine
problem
in
all
circumstances,
and
when
you
take
that
same
group
of
people
with
that
same
expectation
and
then
reasonably
quadruple
the
amount
of
reports
that
land
on
their
desk,
then
they
are
necessarily
going
to
have
to
have
more
stuff
off
to
the
developers
and
they
would
do
on
a
day
to
day
basis
and
it's
yeah,
I
I.
Think
everything
in
here
makes
sense.
It's
just
the
way
my
station
needs
to
be
hired
as
well
to.
E
Clarify
where
you're
asking
about
where
are
you
suggesting
that
the
second-level
triage
that's
currently
done
by
the
product
security
team,
either
be
expanded
to
include
other
individuals
or
an
expanded
product
security
team
and
or
are
you
just
kind
of
saying,
hey?
We
need
to
give
all
the
other
six
heads
up.
I
definitely
definitely
agree
on
the
second
one.
I,
don't
personally
have
anything
on
the
first
one
I
know.
H
L
Yeah
I
think
there's
definitely
questions
like
coordinating
this
spike
like
I,
don't
know
somewhere
between,
like
perhaps
Roberts,
has
an
ism
and
just
as
optimism
that
yeah
I
think
I
agree
on
kind
of
like
giving
you
other
cigs
a
heads
up
and
also
like
you
know.
We
need
to
be
careful
about.
You
know
not
putting
and
a
big
announcement
about
this
like
right
before
code
freeze
or
like
in
like
another
like
super
crunch
time
for
the
community
developers
like
right
before
cube
con
or
something
like
that
too.
L
B
Yeah,
when
I
think
our
current
kind
of
triage
process
is,
we've
got
this
product
security
team
and
it's
a
little
bit
of
whoever
responds
first
or
jumps
on
the
issue
first
or
sees
the
issue.
First
becomes
the
owner
and
I
think
it
would
be
worth
setting
up
explicit
kind
of
rotation
or
division
of
labor
there.
B
It's
maybe
more
of
a
discussion
to
have
with
the
product
security
team,
but
just
kind
of
something
that
would
help
to
deal
with
that
spike
and
then
the
other
piece
is
I.
Think
our
our
security
fix
and
release
process
is
getting
better,
but
still
is
not
nearly
as
streamlined
as
it
could
be,
and
we
may
want
to
invest
some
resources
in
making
that
process
a
little
smoother
before
before
we
unleash
the
flood.
K
B
A
I
just
have
a
question
for
the
people
on
the
current
triage
team
about
scope
and
how
we
define
that
today,
a
lot
of
the
sort
of
most
egregious
kind
of
vulnerabilities
or
sort
of
you
know
things
that
we
worry
about
often
come
from,
like
lack
of
configuration
or
setting
it
up
wrong
or
people
enabling
certain
add-ons
and
I
was
wondering
how
do
we
handle
those
type
of
reports
today
versus
you
know,
actual
bugs
and
say
the
TLS
handling
in
the
API
server.
A
K
B
Think
there's
still
some
questions
around
like
plugins,
like
even
if
you're
running
a
compliant
cluster.
If
you're
running
a
you
know
a
third
party
controller
that
has
root
access
to
the
cluster,
then
obviously
you
know
run
into
some
problems
there
who
owns
the
plug-in
so
you're
talking
about
yeah,
so
obviously
plugins
that
are
outside
of
the
kubernetes
org
should
be
out
of
scope.
But
what
about
all
of
the
different
projects
that
are
in
communities
incubator,
which
is
you
know,.
B
M
So
a
child
fight,
we
run
a
number
of
successful
programming
programs
and
what
we've
determined
through
our
like
ecosystem
is
that
anything
third
party
is
definitely
gonna
scope.
Anything
looks
like
alphas
is
gollu
reported
to
whomever
those
developers
were.
We've
had
pretty
great
success
with
that
and
we're
gonna
be
definitely
leveraging
this
reporting
of
vulnerabilities
to
the
kubernetes
platform,
because
we're
anticipating
to
open
up
something
very
similar
to
a
bug,
bounty
program
for
run
time,
container
security
more
to
follow
on
that
I.
Don't
want
to
announce
anything
yet,
but
I'm
really
curious
on
this
I.
E
Think
I
think
to
jump
a
bit
into
scoping
and
all
that
I
mean
it
was
brought
up
a
few
times,
but
it
would
make
a
lot
of
sense
if
we
had
something
programmatic,
that
would
define
scope
or
we
had
a
sample
app
or
that
type
of
thing.
Obviously,
we
want
to
be
independent
of
a
platform,
so
building
a
like
a
honeypot
is
not
really
what
we're
going
for,
but
you
can
imagine
the
Blizzard
config
template
of
some
kind
there's
exactly.
Thank
you.
E
L
So
I
think
we
have
pros,
like
we
have
woods
about
hardening
in
in
that
link
to
kubernetes
hardening
garden
and
next
paragraph
down
that
what
we're
missing
is
like
an
example
app
that
has
like
something
in
different
namespaces
that
have
our
back
guarantees
about
how
those
namespaces
are
separated,
something
that
you
know
certainly,
network
policy
rules
and
some
other
stuff
that
we
could
say
point
to
kind
of
like
a
guarantee.
It
says,
like
hey
security.
Research
has
stopped
this
thing
on
your
laptop.
L
J
The
really
the
only
way
you
can
or
the
best
way
to
scope
it
would
be
to
be
able
to
say
this
affects
like
X
number
of
actual
production
clusters
out
there
and
I
mean
because
even
bad
defaults
could,
if
there's
gray
areas,
but
what
matters
is,
if,
like
the
majority
of
our
carry
you
people
who
are
more
concentrated
on
this,
have
this
issue?
That's
the
real
issue,
which
probably
to
be
able
to
do
that.
It's
hard
to
take
a
lot
of
partnerships.
J
I,
don't
know
something
like
work,
but
I
think
that
would
be
the
ideal
way
to
determine
whether
it
counts
or
not.
B
I'm
concerned
that
kubernetes
is
so
flexible
and
so
pluggable
that
defining
any
sort
of
conformance
on
the
whole,
like
kind
of
a
generic
cluster,
might
be
impossible.
There's
always
you
know
some
way
that
you
could
plug
in
something
with
very
little
secure
or
very
poor
security.
That
would
compromise
the
cluster
and
I'm
wondering
if
it
would
make
sense
to
have
some
basically
scripts
or
configs
or
a
certain,
even
a
certain
number
of
like
commercial
deployments
and
just
define
it.
B
I
recognize
that
that
has
a
lot
of
problems
with
kind
of
being
the
relationship
between
the
open
source,
project
and
kind
of
these
private
deployments,
but
I
guess
what
I'm
saying
is.
If,
if
we
had
a
model
of
saying
like
you
know,
run
the
script
get
cluster.
If
you
can
compromise
that
cluster,
then
it's
in
scope,
so
it
makes
sense.
B
To
give
a
more
concrete
example
of
what
I
was
talking
about,
defining
explicitly
which
CRI
plugins
are
supported
under
the
scope
and
even
if
those,
even
if
bugs
in
those
plugins
are
out
of
scope?
Well,
I,
don't
know!
Maybe
that
answers
my
own
question
of
you
know
if
you
run
a
CRI
plug-in
that
doesn't
implement
any
isolation
of
containers
and
you
escape
container
and
compromised
the
cluster,
then
we
just
say:
that's
that's
a
bug
in
that
plug-in
and
outside
of
the
community
scope.
H
K
Yeah
I
feel
like
like
a
like
actual
container
escape
would
fall
into
out
of
scope,
albeit
a
really
bad
bug.
It
wouldn't
be
in
the
scope
for
our
you
know,
bounty
program.
It
would
be
in
the
scope
for
something
else,
whereas
like
moving
laterally
across
the
kubernetes
namespaces
would
be
in
our
scope.
So
something
like
that,
like
you,
have
to
just
define
it.
O
We
could
also
define
like
multiple
scenarios
for
attacker
capabilities
and
goals
so,
like
another
threat
model,
B
I
have
a
container
escape
and
so
I
own
a
node.
And
what
do
we
think?
What
do
we
think
that
kubernetes
security
model
is,
if
you
own
a
node,
we
think
there
are
things
that
you
can't
can't
still
do.
O
That's
kind
of
a
different
scenario
from
here's,
a
user
credential
that
has
access
to
a
namespace,
try
to
run
code
in
another
namespace
might
be
worth
actually
having
multiple
and
then,
like
someone
said
we
can
start
small
but,
like
I,
think
we
should
try
to
like
pick
little
profiles
like
that,
where
we
have
you
have
this,
do
you
start
with
this
capability?
This
is
your
goal.
If
you
can
do
that,
here's
money
there.
B
And
having
that
more
well-defined
might
be
a
valuable
prerequisite
for
this,
so
kind
of
I'm,
not
sure
who
is
just
speaking,
but
about
like
you
know
what
what
is
the
model
for
a
node
compromise?
What
are
the
expectations?
You
know
if
you
know
container
escapes,
maybe
out
of
scope,
but
what
once
you're
saved?
What
is
within
scope.
G
I
I
did
think
it
was.
This
is
Clayton.
Someone
probably
could
take
that
over
for
me
and
help
drive
it
to
completion,
but
I
do
agree
that
we
want
to
model
specifically
I
feel
like
either.
We
start
here
and
work
backwards
to
the
threat
model,
but
we
shouldn't
go
much
longer
without
having
an
actual
threat
model
reference
in
place,
duplicating
it
every
new
dock.
If
someone
comes
up
with,
unfortunately,.
E
It's
also
a
we
will
have
two
documents
that
would
base
this.
One
is
kind
of
the
existing
best
practices
Docs
securing
the
clusters,
maybe
updating
that
to
what
like
a
soup
lock
down
cluster
would
look
like
in
some
sense
and
the
second.
The
second
thing
would
be
what
you're
describing
that
threat
model
saying
if
you
can
do
X
or
Y
or
Z
that's
worth
about,
that's
it's
worth
of
about.
E
H
H
You
know
of
I,
don't
know,
maybe
a
multi-tenant,
how
you
would
expect
a
good
multi-tenant
service
to
be
deployed
with
with
reasonable
sort
of
workable
business
levels
of
security
assurance
around
isolation.
You
know,
I'm
sure
there
are
probably
parallels
in
queue
way.
You
can
kind
of
go
even
further
to
make
things
more
secure,
but
when
we
send
up
with
an
academically
secure
situation
where
it's
probably
not
terribly
functional,
I
just
want
to
urge
caution
as
again
it's
as
part
of
this
scoping
work.
I
A
Even
for
a
soft
soft
multi-tenancy
cluster,
like
we
still
get
a
lot
of
questions
about,
is
the
namespace,
the
security
boundary
or
what
objects
in
a
namespace
can
escalate
that
we
know
can
escalate
so
I
I
wonder
how
much
we've
worked.
You
might
want
to
do
just
to
start
with
defining
those
security
boundaries,
but
security,
best
practices.
I
Yeah
we,
as
jess
alluded
to
earlier.
We
started
talking
about
this
a
bit
in
sig
off
and
there's
sorry
in
the
multi-tenancy
working
group,
and
we
have
a
couple
of
documents
with
kind
of
ideas
around
that
question,
but
I
definitely
agree.
We
haven't
really
converged
or
come
close
to
converging
on,
like
here
is
a
standard
configuration
that
you
know
we
define
as
secure
but
I
think
that's
kind
of
the
direction
we
were
hoping
to
go
in.
We
have
not
there
so.
B
B
E
B
E
The
other
and
there's
another
question
here
which
is
I
was
originally
thinking.
This
would
be
something
very
cool
to
announce
at
Q
comp,
which
I
know
is
not
that
far
away,
and
that
might
be
too
aggressive,
but
I
get
I.
Think
that
the
pieces
to
get
in
place
are
what
we
just
described.
We
can
also
do
it.
You
can
imagine
doing
it
in
like
after
the
following
code
free,
so
that
would
be
July
with
another
good
kind
of
timeline
to
aim
for
that's
one
that
we
could.
We.
E
E
L
It's
the
it's
the
standard
kind
of
Google
deadline
of
90
days,
I
I,
don't
know,
I,
think
it
kind
of
depends
on
the
bug
like
if
it's
like
a
big
architectural
change.
That's
gonna
be
rough
to
do
in
90
days
in
kubernetes,
but
you
know
if
it's
a
small
fix
and
that's
easily
enough
time
so
I
yeah,
there's
that
so
you
kind
of
sign
up
for
that
that
discloses
your
timeline.
L
There's
also
like
I'm,
not
I'm,
not
sure
how
what
the
kind
of
focus
is
the
father
is
and
I
should
actually
go
talk
to
some
Google
people
about
it
who
run
it.
But
like
is
it
for
a
go
project?
Is
this
like
how
they
seem
value
Oh?
Actually,
so
it
says
it
supports
C
and
C++
good,
so
yeah
I
don't
know.
Maybe
maybe
this
is
not
even
a
good
thing.
We
I
think
we
should
go
talk
to
the
people
on.
E
H
H
Those
guys
are
always
looking
for
new
places
to
apply
that
tech
and
it
may
have
been
fit
into
looking
at
that,
workflow
may
say
into
how
well
ss+
is
working
anyway,
but
yeah
I.
Think
if
there
isn't
anyone
actively
pursuing
this
sort
of
thing
at
the
moment,
then
that
might
be
something
that
could
help
as
well.