►
From YouTube: Kubernetes SIG Auth 20180418
Description
Kubernetes Auth Special-Interest-Group (SIG) Meeting 20180418
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
B
C
B
A
B
If
tests
are
green
they're
going
to
let
code
freeze
be
shorter,
so
they
are
pushing
sig
releases,
pushing
on
tests
that
are
failing
blocking
and
trying
to
get
things
to
fix
those
up
to
minimize
the
amount
of
time
that
wearing
good
freeze
sick
office
doesn't
have
any
failing
tests
that
I'm
aware
of
we
weren't
in
the
list.
The
initial
list
that
got
sent
out.
But
if
you
do
see
those
any
show
up
for
sec
off,
please
jump
on
those
or
route
them
to
the
right
people.
So
we
can
not
block
the
released
ring
all
right.
B
B
E
Hi
everyone
can
you
see
my
screen
yeah
thanks.
Okay,
let
me
describe
what
the
scurbs
profile.
Yes,
so
first,
the
secure
file
is
designed
to
solve
basically
two
major
problems.
The
first
one
is
the
difficulty
managing
a
cone,
a.
F
E
A
cluster
to
be
secure,
including
setting
up
the
command
line
flag
correctly.
It
also
requires
class,
adding
a
certain
level
of
knowledge
about
the
security
and
currently
there's
no
way
to
automatically
provision
namespaces
with
the
objects
when
you
need
when
a
new
name
space
is
created
so
in
the
world,
people
are
doing
at
your
efforts
building
in
solutions,
but
because
lack
of
the
common
standard
solutions.
So
these
efforts
are
very
difficult
to
be
reused
or
shared
across
the
community.
E
F
E
Cluster
just
specify
a
name
of
security
profile
which
includes
a
bunch
of
settings
to
make
sure
the
cluster
is
created
and
meet
the
certain
security
requirements.
Specifically
you
the
scenario
and
this
solution
also
works
with
complicated
code
systems,
where
the
all
the
configurations
are
expressed
in
llamó
files
and
committing
to
code.
The
repo
skill
profiles
can
also
be
integrated
into
the
clerical
and
goes
through
the
CIC
pipeline
on
the
color
configure
system
you
use.
E
So
what
is
it
basically
I?
A
micro
system
defines
a
cure,
created
settings
of
a
cluster
on
including
a
post
wrapping
concretions
like
kimono
flags
and
cluster
scope.
Objects
were
done
for
the
prosecute
policy,
and
also
the
policy
objects
to
be
Populi
to
namespaces,
including
our
names
network
policy
and
basically
simplify
the
cluster.
At
an
initial
situation.
You
just
select
a
security
profile
name
without
knowing
a
lot
of
details
and
the
security
profile
itself
will
be
highly
portable
and
customizable
also
can
be
extended.
E
So
it's
also
well
versioned
to
allow
CMAs
great
and
the
the
future
won't
need
any
change
on
the
coronaries.
We
are
also
thinking
of
contribute
to
the
kinetic
conformance
test
to
to
help
providing
a
tool,
a
very
deprotonate
class
that
has
messed
the
security
requirements.
E
So
in
general
it
includes
like
three
parts:
the
first
driving
two
rules
which
define
come
on
blacks,
so
the
deployed
tool
like
class,
API
or
hue
diem
will
take
care
of
that
and
classical
policy
objects
is
defined
and
that
can
be
simply
created
into
the
cluster
using
avocado
or
add-on
manager
and
the
namespace
scoped
across
the
objects
which
is
populated
to
a
namespace
when
s
gets
created
automatically.
So
we
need
additional
are
contours
to
help
populate
these
objects.
E
So
it's
not
something
we
are
not
give
up
something
new
features,
we're
not
defining
new
policies
and
we
don't
make
anything
to
put
kaku
Nettie's
and
the
security
profile
is
designed
for
the
common
generic
use
case.
So
we
don't
cover
the
particular
use
case
like
specified
resource
quota
or
cost
RORO,
bindings
particular
to
our
user
environment,
and
it's
not
a
temporary
system.
The
talent
to
template
rendering
a
string
substitution,
it's
not
a
policy
engine,
so
this
is
an
example
of
secure
profile.
So
you
give
fine.
E
So
on
the
left
bottom,
we
can
find
skill
profile,
which
has
one
random
rules
and
it's
reference:
a
name,
speed,
template
and
in
the
names
of
templates,
we
defined
the
never
pass
a
and
I
row
on
row
bindings
using
a
high
school
policy,
and
these
projects
will
be
automatically
populating
to
a
namespace
when
it's
gets
created
and
on
left
side
is
parce
que.
Pase
is
basically
our
classes
called
policy.
It
will
be
automatic
installed
when,
together
with
a
security
profile
on
cluster
level
and
can
be
used
by
any
name
choice
later.
E
E
So
we
expect
the
cluster
lifecycle
manager
to
respect
these
settings
and
override
their
own
settings,
and
these
setting
the
only
enforced
during
the
COS
prescribing
so
because,
when
a
class
is
running,
is
difficult
to
monitor
or
inspect
as
these
settings
from
a
control
running
center
cluster,
it's
possible.
We
can
install
multiple
security
profiles
into
a
cluster,
but
we
only
allow
one
secure
profile
to
be
enforced
at
a
time.
So
we
introduced
concept
of
a
security
profile
selector,
which
is
a
custom
resource.
E
It
only
stacks
the
name
or
the
skill
profile,
and
the
running
controllers
will
basically
aware
of
which
secure
profile
is,
if
is
effective
and
enforced
at,
and
there
will
be
a
status
for
each
of
the
guild
profile
and
the
state
who
reflects
the
rules,
whether
that
going
to
be
enforced
or
not
or
still
in
progress,
and
any
errors
happens
during
the
enforcement.
So
the
left
bottom
there's
a
sample
of
a
security
profile
select
is
very
simple.
It
has
a
predefined
name
current
and
the
controller
will
only
watch
the
current
security
profile
selector.
E
E
Even
basically,
you
label
a
secure
file
with
a
special
label
and
the
Infosys
will
validate
the
system
and
put
the
details
into
a
status
of
the
secure
file
to
reflect
what
you're
going
to
change
in
the
system,
but
actually
without
doing
anything
to
a
system,
so
that
helps
trust
admin
to
get
a
basic
idea
when
they
are
one
they
want
to
use
the
Skip
profile
before
the
real
scene
happens.
So
between
switch.
Are
they
linked
up
in
chasm?
E
The
object
created
dynamically
by
the
old,
secure
profile,
well
labeled,
and
they
are
going
to
the
update
yet
a
new
skill
profile
or
they
are
going
to
be
removed
if
they
are
no
longer
needed
by
the
new
skill
profile.
I.
E
About
names
with
populations,
so
we
won't
allow
a
self-service,
namespace
creation
in
certain
multi-tenancy
scenarios,
for
example,
assess
specific
tenancy
scenario.
So
people
can
directly
use
cognate
API
to
create
names
places
and
the
party
objects
defined
in
the
secure
profile
will
be
automatically
provision
in
the
namespace
when
I
created.
E
The
security
profile
is
going
to
provide
a
secure
base
line
and
additional
tools
can
run.
On
top
of
that.
We
also
allow
the
heterogeneous
links
business
by
using
namespace
selector
england
names
with
template.
So
basically
we
are
able
to
provision
different
places
in
different
namespaces,
so
it's
possibly
as
a
one
risk
condition
when
the
namespace
gets
created,
but
before
the
policy
objects
are
populated,
so
it's
possible,
a
privileged
user
can
still
access.
E
F
E
Higher
namespace
before
his
guests
populated,
but
the
initial
doesn't
block
access.
It
only
hides
an
object.
Well,
we
are
still
thinking
we
are
also
thinking
of
using
a
dating
a
dimension
during
a
name
is
with
initialization.
It
only
allow
the
ylist
trust
controllers
to
target
objects
but
block
other
users
from
accessing
that
which
may
be
better
as
secure
than
initials.
E
So,
regarding
customization
extending
so
there's
a
few
scenarios,
the
custom
may
need
extend
our
customize
a
secure
profile
for
a
specific
reason:
are
they
they
want
to
change
some
rules?
Then
they
are.
They
are
either
copied
from
existing
secure
profile
and
create
new
custom
resource
name.
It.
Author
rules
and
youth
groups.
If
you
apply
are
to
update
the
skipper
fast
vector
to
use
their
own
skill
profile,
they
can
also
introduce
the
custom
rules
with
their
own
custom
enforcement
logic.
E
So
they
have
to
deploy
the
controller
to
enforce
the
rule
and
I
as
the
same
way
about
the
copy
from
existing
script,
without
adding
the
new
rules
and
apply
that
they
are
also
possible
to
replace
the
stock
in
enforcement
logic
with
exact
rules,
they
basically
employ
their
own
controllers
and
hungy
boiler
started
to
us
for
the
enforcement
logic
about
versioning.
The
security
is
proposed
to
be
maintained
by
the
community,
so
people
can
create
the
reasonable
security
security
profiles
reflect
the
common
use
case
that
people
can
directly
use
in
most
situations.
E
Introducing
a
native
volume
schema
that
helps
people
to
upgrade
the
secure
profile
seamlessly
across
different
volume.
Canaries.
The
voting
schema
includes
three
parts.
The
first
part
are.
The
name
also
includes
a
major
version
which
reflects
the
pagina
scenarios,
the
secure
profile
to
cover,
and
the
minor
version
indicates
the
definition
rules
and
pass
objects.
So
if
anything
changed
there,
the
minor
body
will
be
bumped
in
the.
F
G
E
Pump
this
number,
so
how
do
we
know
the
compatibility
between
the
secure
profile
with
khun
a
virgin's?
We
introduced
a
version
matrix
to
be
maintained
in
sauce
repo
on
the
script
files.
The
version
matrix
is
a
table
which
maintains
three
essential
columns
and
can
be
more
cons,
but
mostly
you
are
most
important.
It
Maps.
The
security
profile
includes
a
version,
the
full
version
to
a
net,
his
version
so
and.
E
Column,
which
indicated
a
secret
profile
should
be
deprecated
and
if
we're
secure
of
profile
can
run
on
multiple
coordinated
versions.
So
there
will
be
multiple
rows
to
to
indicate
the
mapping
so,
for
example,
the
default
1.0
gosiwon.
It
runs
for
Communities
1.9.
Also
one
point,
and
also
there
were
two
rows
to
India
dots,
so
the
the
deployment
will
be
able
to
figure
out
with
current
community's
version
when
she
secured
profile
should
be
are
slept
and
will
be
able
to
use
and
about.
E
The
application
arm
is
very
important
if
a
improv
design
or
incomplete
rules
on
in
published
skill
profile
that
may
introduce
some
security
concerns
of
vulnerability
in
the
system.
So
in
that
case
the
security
profile
should
be
deprecated
immediately
and
when
insecure
profile
deprecated,
we
should
explicitly
marketing
the
version
matrix
and
the
the
tools
or
cluster
laughs
amendment.
Will
optionally
optionally
have
the
capability
to
detect
the
duplication
from
the
volume
matrix
and
reminder
the
class
aiming
to.
Of
course
you
prefer
as
soon
as
possible.
E
We
are
thinking
of
adding
components
test
to
bear
it
if
connect
lustre
satisfies
the
security
requirements
when
a
secure
profile
is
in
deployed.
But
this
is
not
the
details
are
not
covered
here.
It
will
be
a
separate
plan
so
for
configured
Co
system
so
for
foremost
configured
school
system.
They
use
a
single
source
of
truth
in
report,
which
has
a
burden
control
to
maintain
all
the
manifests
and
policy
objects
defined
for
a
cluster.
E
Basically,
the
school
profile
can
extract
into
these
repositories
and
we'll
also
introduce
a
help
COI
to
validate
in
the
repository.
If
the
current
object
settings
on
needs
the
security
requirements,
it
can
be,
if
I
don't
know,
I
can
check
a
new
name
namespace,
whether
they
are
already
being
appropriate
name
spaces
in
the
coded
repo
compared
to
the
secure
profile.
That
will
be
really
helpful
for
the
cross
editing
to
be
aware
of
all
the
settings
where
they
are
very
done
not
before
everything
pushed
to
the
cluster.
E
So
here
are
the
links.
If
you
are
interested,
there's
links
to
the
detailed
machining,
the
design,
talk
and
separate
event,
log
for
competence
as
Co
system,
and
we
are
working
on
the
prototype
and
Mo
that
will
come
out
soon
and
there's
a
reference
about
background
regarding
attend,
say
and
possibility
mechanisms
kind
of
stuff.
So
that's
all
any
questions.
H
So
you
talked
about
enforcers.
Can
you
describe
like
whether
they're
like
active
or
one-time?
Only
so,
for
example,
you
talked
about
bootstrapping
one
of
the
cream,
this
policy
and
it
sounds
like
the
enforcer.
The
area
is
something
related
to
bringing
up
the
cluster
and
it
probably
only
runs
once-
and
maybe
that's
also
true
for
the
cluster
level
policy,
because
it's
kind
of
like
you
just
cute
control,
applied
and
cluster
level
policy,
linear
least
all
the
security
profile.
H
E
For
both
trapping
rules,
yes,
it's
only
one
time
enforcement,
because
when
a
class
is
ready,
it's
impossible
to
inspect
these
command
line
flags
for
an
entire
cluster.
So
it's
one
time
enforcement
and
for
the
rest
of
the
posse
obvious
in
the
cluster.
The
enforcers
is
continuously
watching
the
namespace
crochet
and
also
the
security
profile
changes.
If
the
change
happens,
it
will
automatically
enforce
the
policy.
Obviously,
two
namespaces
when,
as
your
profile
is
switched,
it
will
basically
updated
of
policy
objects
automatically
across
all
the
namespaces
matching.
The
name
selector.
H
Okay,
so
the
triggers
for
it
at
doing
something
actively
are
either
creating
a
namespace
when
you
have
these
namespace
objects
that
get
automatically
populated
or
switching
to
a
new
security
profile.
Those
those
are
like,
basically,
the
two
triggers
for
some
active
enforcement
is
that
right?
Yes,
okay,
thanks.
A
This
so
that
was
a
lot
it
does
seem
like.
There
are
about
four
or
five
different
concepts
and
proposals
within
this
one
thing.
So
there's
conversations
about
installers
having
to
start
understanding
new
configuration,
like
api's
controllers,
that
you
would
deploy.
That
would
allow
you
to
use
template
types,
and
then
there
was
some
stuff
about
conformance,
and
it
does
it
am.
I
just
does
this
seem
like
these
should
be
all
could
be
very
different
proposals
and
shouldn't
all
be
linked
so
so
tightly.
E
Sex
l.a,
in
my
opinion,
so
secure
profile
is
the
the
position
of
secure
profile,
is
going
to
define
a
a
base
baseline
or
say,
are
a
commonly
used
or
standardized
us
settings
for
the
rest
of
stuff.
So
we're
secure
profile
is
easier
to
introduce.
The
conformance
test
which
can
validate
say
of
this
cluster
is
actually
meet
this
security
file
and
additional
tools.
Art
was
like
the
closet
deployment
tools,
which
also
have
all
say,
a
base
level
of
rules
also
either
instructions
which
can
deploy
as
a
consular
income
in
a
way
comfort
comply.
A
To
the
secure
profile,
but
well
what
if
I
have
an
installer
that
is
using
something
like
terraformer
ansible
and
can't
parse
that,
like
there,
there
seems
to
be
if
it,
but
if
the,
if
this
entire
proposal
is
dependent
on
every
installer
being
able
to
take
this
as
input
to
create
a
controller
cluster,
that
alone
seems
like
a
very
large
proposal.
Well,.
B
F
B
Gathered
together
to
say,
for
this
policy
to
be
effective,
you
actually
do
have
to
start
your
API
server
with
the
slag
and
your
cubelet
with
this
flag.
Whether
in
your
particular
use
case,
your
installer
is
going
to
do
that
automatically
or
whether
you're
going
to
be
sort
of
copying
the
flags
into
your
terraform
setup
I,
like
the
the
way
that
it
gathers
all
three
of
those
levels
together,
it
would
be
nice
to
be
able
to
seed
the
MIT,
the
artifacts
be
useable
individually,
so
the
cluster
policy
and
the
namespace
policy.
B
E
I
E
B
H
Want
to
make
a
couple
comments,
as
I've
talked
to
you
sweetie
about
this,
and
so
I
want
to
respond
to
kind
of
a
couple
things
that
Eric
said
so
and
and
also
so
I
think
I
definitely
agree
that
it's
important,
that
these
pieces
be
usable
independently,
I
mean
I,
think
there's
different
levels
to
which
you
can
use
it.
One
is
you
can
just
look
at
the
definition.
H
I
mean
like
yeast,
we
said
part
of
the
idea
is
to
have
these
a
community
curated
small
set
of
standard
profiles,
and
if
you
want
to
just
look
at
those
and
copy
them
and
paste
them
into
whatever
system
you're
using
for
operations
just
having
those
standard
definitions
of
what
is
a
you
know,
what
is
a
secure
cluster
or
what
is
a
cluster
that
has
most
strong,
multi-tenancy
isolation.
Things
like
that!
That's
useful!
H
H
This
word
enforcers
because
I
think
it
gives
the
wrong
impression
and
like
that,
there's
some
complicated,
active
reconciliation
going
on
here,
but,
like
whatever
is
reading,
these
policies,
like
is,
should
be
pluggable.
So,
for
example,
if
you
want
to
use
the
cluster
API
to
bring
up
your
cluster,
then
you
know
if
it.
If
it
understands
security
profiles,
that's
fine,
even
if
we
don't
have
like
an
adapter
for
terraform
yet
and
then
later
you
know,
somebody
writes
something
for
for
terraform
that
understands
security
profiles.
H
H
Absolutely
I
mean,
like
I,
think
that
that
second
slide
use
we
had
is
really
great,
like
the
12
screenshots
from
the
web,
where
it's
like.
That's
what
people
are
doing
today,
Google,
how
do
I
set
up
a
secure
cluster
and
they
get
these
twelve
different
blog
posts
and
have
to
figure
out
like
what
to
do
so.
I
think
just
the
just
having
these
definitions,
even
without
the
enforcement
mechanism,
although
I
think
the
enforcement
stuff
is
important,
but
even
just
having
the
definitions
is
like
you
said,
as
as
code
is
import
pieces,
I.
G
Like
I
think,
a
lot
of
it
installers
end
up
with
their
own
opinionated
profile
of
security
feature.
So
if
you're,
something
like
cops,
you
sort
of
make
some
choices
about
which
features
and
how
you're
going
to
set
things
up,
and
that
ends
up
not
appropriate
for
every
use
case.
So
having
these
profiles
as
code,
where
you
can
bring
in
into
your
installer
and
have
your
installer
support,
more
news
cases
and
just
be
able
to
talk
about
these
profiles
across
multiple
installers
feels
like
a
big
deal
to
me,.
C
The
current
document
states
that
we
will
add
a
name
space
field
to
the
current
configuration
and
figure
out
hard
code,
a
rule
that
allows
access
to
a
config
map
in
the
public
cube
public
namespace,
which
is
used
elsewhere,
but
not
necessarily
in
this
way
and
with
the
eventual
goal
to
support
cross
namespace
config
map
references
and
to
figure
out
the
actual
story.
For
that.
So
that's
a
little
bit
of
a
cop-out,
I.
C
The
the
DPR
the
design
proposal
needs
1lg
TM
from
Sagat
to
merge
that
config
mat
piece
is
a
little
weak,
I
think
the
rest
of
the
design
dock
is
pretty
solid
but
feel
free
to
review
and
told
me
if
I
got
anything
wrong
so
yeah.
That's
the
status
update,
I'll,
probably
poke
somebody
this
week
to
figure
out
how
to
proceed.
C
B
Tighter
more
enforced
world,
but
if
you're
interested
in
that,
you
can
find
the
links
in
the
previous
minutes.
Okay.
Well,
let's
get
to
the
discussion
last
time
we
mentioned
the
governor's
proposal
versus
Agathe,
so
this
is
just
a
recap.
This
is
describing
how
we
want
to
run
the
cig.
A
lot
of
that
has
been
sort
of
ad
hoc
or
tribal
knowledge
or
yeah,
just
whatever
happened,
happened
and
there's
an
effort
to
kind
of
make
those
more
well-defined
so
defining
roles
and
defining
how
we
run
things.
B
So
the
RFC
was
open,
then,
once
actually
I,
don't
think
any
comments,
but
we
said
we
would
talk
about
it
this
week,
so
that
is
what
we're
going
to
do
now,
so
just
to
give
an
overview.
This
follows
the
short
form
template
that
the
steering
committee
came
up
with
fairly
closely.
We
tweaked
a
few
things
but
and
I
think
Tim
give
a
link
to
the
short
form,
so
you
can
see
the
diff,
but,
generally
speaking,
there
are
kind
of
three
leadership
roles
chairs
who
help
run
processes,
meetings,
cross
ties,
interface
with
product
management,
sig
release.
B
Technical
leads,
which
help
drive
technical
priorities,
make
technical
decisions,
serve
as
an
escalation
path
for
things
within
sub
projects
of
the
sig
and
kind
of
ensure
a
consistent
and
coherent
approach
across
the
sub
projects
and
among
other
SIG's
for
technical
issues
and
then
sub
project
owners
and
many
of
the
sub
project
owners
will
also
be
technical
leads.
But,
depending
on
how
many
sub
projects,
we
have
it's
possible
that
there
will
be
people
leading
sub
projects
that
are
not
up
at
the
technical
lead
level,
just
to
kind
of
keep
a
reasonable
number
of
people.
B
Cooks
in
the
kitchen
people
drive
in
the
ship,
but
so
this
this
kind
of
lays
out
what
the
scope
and
responsibilities
and
expectations
are,
where
the
responsibilities
lie.
What's
involved
in
each
of
these
and
roughly
kind
of,
but
the
number
expected
at
each
level,
so
I
think
we
call
out
three
three
chairs
three
two
Tech
leads
and
then
for
a
given
some
project,
one
two,
three
people
kind
of
driving
that
being
responsible
for
it.
D
Hey
so
I
briefly
just
took
a
look
at
this
and
I
was
I
thought
it
was
interesting.
So
one
of
the
things
the
differences
I
noted
was
like
in
the
in
the
steering
committee
version.
It's
kind
of
like
tech.
Lead
was
almost
like
just
crud
on
sub-project
and
that
so
it
was
like
optional
I'm.
Just
curious
about
to
thank
anybody.
So
it
seems
like
we're.
Gonna
take
a
more
tech.
D
Lead
is
still
more
of
a
thing
because
it
sort
of
seemed
like
the
steering
committee
was
like
mostly
doing
away
with
tech
leads
and
making
kind
of
sub
project
leads.
The
thing
was
some
organization
at
the
channel
level.
Did
we?
We
think
that
the
the
tech
lead
kind
of
more
like
it
is
now
it's.
It
looks
like
we're.
Gonna
keep
that
structure
or.
B
So
I
will
attempt
to
summarize
and
then
Tim
and
Eric
can
time
in
as
well.
The
thought
was
we.
We
don't
know
what
some
projects
are.
What's
gonna
happen
with
some
projects
like
if
we
end
up
having
ten
or
fifteen
or
twenty
sub
projects
taking
the
union
of
all
some
project
owners
as
the
body
that
makes
technical
decisions,
that
technical
decisions,
kind
of
get
escalated
to
seemed
like
it
could
become
unmanageable.
Yes,.
B
The
what
we
are
expecting
to
happen
short
term,
at
least,
is
that
a
lot
of
the
people
driving
some
projects
are
the
same.
People
who
are
going
to
be
tech
leads,
but
we
kind
of
wanted
to
think
through,
like
what
the
differences
between
those
two
roles
would
be,
so
that
if
we
got
to
the
point
where
we
have
so
many
sub
projects
and
sub
project
owners,
we
do
want
to
start
trimming
down
that
group.
We
aren't
trying
to
come
up
with
the
coming
up.
B
We
come
up
with
the
role
then
like
if
we
recognize
like
these
are
two
different
responsibilities:
kind
of
holistic
overview
of
the
area
versus
you
know
managing
roadmap
for
a
particular
sub
project.
They
are
different
roles.
I
expect
a
lot
of
them
to
be
shared
by
the
same
people
initially
and
maybe
even
for
a
while,
but
we
wanted
to
recognize
that
they
are
distinct
out
of
the
gate.
J
Jordan
hi,
this
is
Dan
Shaw
from
the
proposed
safe
working
group
of
the
CF,
we're
actually
hi
we're
actually
looking
at
you
know
using
we're
tasked
with
bringing
our
own
governance
and
since
the
kubernetes
governance
is
so
well
defined,
we're
actually
as
well,
and
so
you
know
happy
to
take
the
discussion
offline.
If
there's
there's
other
items
that
we
need
to
get
to,
but
I
was
just
curious.
B
So
that
we
were,
we
were
hoping
to
have
a
doc
out,
purview,
I
think
there's
actually
a
Google
Doc
that
is
shared
with
everyone,
but
we
hadn't
made
it
into
a
pull
request.
Yet
where
we
are
kind
of
taking
all
the
various
areas
that
the
sig
is
working
on
and
organizing
them
and
figuring
out
who
who
has
been
driving
those
who
has
kind
of
a
vision
roadmap
in
their
head?
And
so,
if
I
can,
did
you
link
to
the
sub-projects
doc
or
Eric.
K
B
Dancer
this
is
the
this
was
kind
of
our
working
dock
for
the
various
areas.
So
we
had
one
around
policy
management
and
one
around
audit
work,
one
around
node
isolation,
encryption
stuff.
There
are
a
couple
kind
of
slushy
ones
like
documentation
and
security,
conformance,
authenticators
and
authorizers,
so
those
were
kind
of
big
buckets
that
have
kind
of
distinct
concerns
and
distinct
roadmaps
and
obviously,
there's
there's
overlap
and
it's
useful
for
one
area
to
be
informed
by
another,
but
that
is
kind
of
the
level
of
granularity.
B
We
were
looking
at
for
some
projects
exist
and
so
like
for
the
safe
working
group,
something
like
that,
like
the
extent
of
which
sig
off
would
interact
with
that
would
probably
be
related
to
some
of
the
security
conformance.
It's
a
project
same
for
the
the
security
profile
stuff
like
that
would
be
a
good
integration
point
to
coordinate
those.
So
great
thanks,
Richard,
hey.
I
B
D
Think
you
mostly
covered
everything
I
think
the
piece
that's
missing
from
this
right
now
is
kind
of
the
definition
of
sub
projects
and
the
scoping
of
those
which
is
what
we
were
working
on
and
and
didn't
really
get
out
in
time.
For
this
meeting,
I'm
not
sure
I
haven't
kind
of
seen
what
all
of
the
other
SIG's
are
doing,
but
there's
sort
of
two
different
approaches.
We
could
take
two
sub
projects.
D
One
would
be
like
every
little
contained
chunk
of
code,
in
which
case
you
know
in
the
authorizers
we
might
break
out
every
or
plug-in
as
the
sub-project
but
we've
elected
to
take
sort
of
a
higher
level
like
area
driven
approach,
and
so
we
have
lumped
all
of
the
authorizers
into
a
single
sub
project
and
being
we're
being
a
little
more
conservative
about
how
we
define
sub
projects.
But
you
know,
if
any
of
those
areas
end
up
growing
into
a
larger
effort,
then
they
could
be
broken
out.
B
H
B
I
B
And
so
we
try
to
try
to
recognize
that
that
distinction
exists
and
kind
of
set
expectations
for
like,
if
you're
being
actively
develops,
you're
going
to
be
identifying
what
progress
you're
gonna
make
in
each
release,
if
you're
more
in
maintenance
mode,
then
you're
watching
your
tests
and
making
sure
that
you
keep
your
thing
working
reacting
to
new
features.
But
you
know
you
don't
need
a
roadmap
doc.
Every
every
release,
I.
B
Yeah
and
so
in
addition
to
those
three
leadership
roles,
chair
tech,
lead
and
sobriety,
sub
project
owner,
there's
also
like
a
more
a
better
defined
notion
of
a
member.
So
the
idea
is
that
SIG's
are
self-governing
and
they're.
This
kind
of
makes
explicit
what
happens
when
there's
disagreement
or
how
you
handle
disagreement
instead
of
just
looking
at
each
other
and
going
well,
we've
always
agreed
up
until
now.
I,
don't
know
what
to
do
this.
B
You
know
this
calls
out
for
someone,
but
some
of
the
leadership
positions
like
this
should
be
supported
by
a
majority
of
members,
and
we
can
do
it
by
lazy
consensus
and
that
works.
You
know
99%
of
the
time,
but
if
there's
disagreement
like
we
need
to
know
what
we
should
do,
and
so
part
of
that
is
actually
identifying.
Who
are
the
members
of
stick
off,
and
this
is
again
taken
from.
B
Taken
from
what
came
from
the
steering
committee,
but
the
idea
is
that
the
people
who
are
contributing
to
the
areas,
people
who
are
doing
work,
who
are
adding
value
who
are
stakeholders,
have
have
ownership
of
the
sig
and
so
for
kubernetes
that
manifests
in
being
a
reviewer
being
an
approver
contributing
pull
requests.
You
know
adding
adding
documentation,
writing
documentation,
fixing
bugs
fixing
flaky
tests,
helping
helping
in
the
area,
and
so
that
currently
manifests
with
like
owners
files
and
it's
possible.
B
We
will
need
to
add
new
ways
to
track
some
of
the
other
artifacts
like
documentation
and
contributing
on
designs
and
things,
but
that
that
is
part
of
this
as
well,
so
that
if
the
need
for
a
vote
comes
up-
and
hopefully
it
won't
often
I
mean
it.
This
is
a
good
group
to
work
with.
We,
we
talk
to
things
and
try
to
solve
problems
in
a
agreeable
reasonable
way.
But
if
the
need
for
votes
arises,
this
you
know
kind
of
lays
out
how
how
we
would
figure
out
who
is
is
a
member
of
the
sig.
D
B
So
this
is
kind
of
the
first
step
to
like
the
governor's
step.
The
second
step
is
going
to
be
identifying
the
sub
projects
and
the
the
people
who
are
currently
running
them
and
in
this
bootstrapping
step,
a
lot
of
us
is
really
just
describing
the
current
state
like
what
what
are
we
doing
and
who
is
doing
it,
and
so
getting
that
written
down
is
gonna,
be
helpful
in
a
lot
of
ways.
B
You
know
it
tells
us
who
to
go
to
to
ask
questions
and
it
those
people
who
are
interested
in
communicating
who
to
who
to
talk
to,
and
if
someone
is
seen
as
being
responsible
for
some
project,
and
they
don't
think
they
are
well
it'll-
be
really
clear
because
we
put
your
name
by
something
and
you
don't
think
you're
responsible
for
it,
and
that
means
we
need
to
find
someone
else
to
be
responsible
for
it.
So
it's
just
going
to
be
good
to
get
this
this
stuff,
written
down
and
and
ironed
out.
C
B
B
All
right,
Tim,
you
got
five
minutes.
If
you
want
to
talk
about
the
level
thing
yeah.
D
I
I
don't
know
that
we're
gonna
solve
this
in
the
next
five
minutes
or
even
I
just
wanted
to
kind
of
highlight
that
I
see
this
as
a
kind
of
a
growing
area
of
concern.
There's
a
lot
of
these
sort
of
nodes,
scoped
plugins
that
are
popping
up
and
as
we
kind
of
focus
on
scoping
down
what
the
cubelet
can
do,
the
more
plugins
that
are
getting
added
on
the
nude
that
you
know
do
things
like
manipulate
the
node
spec
and
pull
secrets
and
whatnot.
D
Those
are
more
ways
that
you
know
you
can
kind
of
just
bypass
all
the
new
authorization,
that's
kind
of
one
piece
of
it
that
Mike
responded
to
below,
but
then
there's
just
the
kind
of
more
general
problem
of
you
know:
I
want
to
deploy
a
demon
set.
It
needs,
like
you,
know,
mutual
TOS
or
something
like
that
to
some.
D
You
know,
centralized
master
component,
not
master
in
the
community
sense,
but
you
know,
for
instance,
I
just
had
a
conversation,
the
other
day
about
device
metrics,
where
they're
thinking
about
how
to
expose
extended
metrics
for
device
plug-ins.
They
want
to
have
a
way
of
you
know.
Probably
a
pull
approach,
so
you
have
some
sort
of
centralized,
maybe
Prometheus
component,
that
is
scraping
all
of
the
device
plug
in
metric
endpoints.
And
how
can
we
do
that
in
a
way
where
you
can't
spoof,
metrics
of
other
plugins
or,
if
you're
running
in
the
cluster?
D
As
you
know,
a
multi-tenant
service,
you
can't
use
those
metrics
to
you,
know,
scrape
metadata
about
other
workloads
in
the
cluster
and
so
I'm
concerned
that
each
plug-in
is
kind
of
doing
this
in
a
diff
in
somewhat
incomplete
way.
I
think,
in
the
general
case,
we've
sort
of
said,
you
know,
use
some
kind
of
additional
component
on
top
of
kubernetes
to
see
you
know
secure
service
to
service
communication,
but
I'm
worried
that
four
core
components
are
things
that
are
we're
expecting
to
be
installed
on
a
lot
of
clusters
without
those
service
matches.
D
C
Dj
and
I
have
talked
about
this
a
couple
of
times
and
I
think
that
it
is
easy
or
to
do
for
kubernetes
objects
in
core,
and
it's
going
to
be
very
difficult
to
solve
for
C,
RDS
and
aggregated
api's.
I
think
it
would
be
good
to
start
with
a
list
of
questions.
You
would
want
to
ask
the
authorizer
a
couple.
Strong
men
that
we've
come
up
with
is
some
sort
of
a
back
or
potentially
taking
a
the
intersection
between
the
node
authorizer
and
in
our
back
rule.
C
F
L
Yeah
I
think
there's
a
gradient
of
solutions
from
like
full-fledged
a
back
with
a
OPA
style,
evaluative
policy
that
gets
everything
versus
a
just
like
simple
bespoke,
node
authorizer,
like
what
we
have
today
and
me
and
Mike
were
talking
about
like
where
what
would
actually
be
useful
to
users
like
is
there?
Is
there
some
general
concept
of
link
to
this
node
that
we
could
expose
either
through
our
backward
through
something
else.
L
B
B
B
B
Well,
that
is
all
for
today
we
will
send
out
the
probably
start,
the
lazy
consensus,
calling
the
governor's
proposal
and
then
send
out
the
announcement
of
the
sub-project
PR
that
enumerates
the
ones
we've
gathered
so
far
and
the
the
people
we
have
identified
so
far
and
probably
considered
that
the
nomination
to
be
a
project
owner
and
people
can
accept
or
decline.
I
guess
if
they
want
to
comment
on
the
PR,
but
yeah
go
from
there
thanks.
Everyone.