►
From YouTube: Kubernetes SIG Auth 20180208
Description
Kubernetes Auth Special-Interest-Group (SIG) Meeting 20180208
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
That's
I,
think
that
said,
maybe
3
3
p.m.
meetings
really
something
like
that
and
yeah
just
being
the
go-between
between
those
groups,
so
Thank
You
CJ,
for
stepping.
Let's
to
do
that
again.
The
the
PM
meetings
are
open
anyone's
welcome
to
attempt
this,
but
this
is
just
to
make
sure
someone
is
on
point
to
to
be
communicating
between
those
groups.
A
So
that
was
all
I
had
for
that.
The
next
thing
on
the
agenda,
pravin,
is
on
the
the
call
you
may
have
seen
some
of
those
emails
to
the
group
he's
going
to
be
spearheading
a
security
benchmark,
so
I
wanted
to
turn
it
over
to
green.
If
you
want
to
share
your
screen
or
just
talk,
sure,
give
an
overview.
Thank.
B
Children,
yep,
hey
guys,
thanks
for
having
me
here
so
I
was
I'm
the
author
for
CIS
to
talk
a
benchmark
and
a
couple
of
other
benchmarks,
and
when
I
was
talking
a
lot
of
customers,
they
found
that
yeah.
We
don't
use
docker
in
isolation
right.
We
have
some
kind
of
orchestration
in
place,
they
say,
for
example,
docker
so
a
Mourdock
our
kubernetes,
so
it
would
be
good
to
have
a
security
benchmark
around
that.
So
so
this
is
the
idea.
B
So
basically
we
should
have
security
benchmark,
which
talks
about
various
covenant
is
configuration
that
would
have
the
custom
was
to
have
secure
deployments
of
communities.
So
just
to
give
you
a
brief
about,
CI
is
French
marks
and
what
is
the
project
about
and
what
are
some
typical
timelines,
so
yeah,
so
the
C
is
equal
to
benchmark
program,
provides
well-defined,
unbiased
and
consensus
based
industry,
best
practices
to
help
organizations
assess
and
improve
their
security.
B
The
it
is
recognized
as
a
trusted
and
independent
authority
that
facilitates
the
collaboration
of
public
and
private
industry
experts
to
achieve
consensus
on
practical
and
actionable
solutions.
So
because
of
this
reputation,
this
benchmarks
recommended,
as
industry,
accepted
system
finding
standards
and
are
used
by
organizations
in
meeting
various
compounds
to
comment
such
as
PCI
HIPAA.
So
basically,
each
of
the
benchmark
curve
undergoes
two
phases
of
consistence
review.
During
the
first
phase,
the
subject
matter,
experts
convened
to
discuss,
create
and
test
the
working
drafts
of
the
benchmark.
B
The
second
phase
begins
after
the
benchmark
has
been
during
this
phase.
What
we
do
is
that
we
incorporate
we,
we
look
at
the
feedback
from
internet
community
and
try
to
incorporate
the
feedback
in
future
versions
of
the
benchmarks.
So
what
I
will
do
right
now
is
that
shimmer
screen
and
I'll
show
you
what
I've
been
working
on
so
I've
just
developed
a
skeleton.
B
Okay,
so
I've
already
sent
you
that
info
like
how
to
join
that
so
once
to
join
the
project
once
you
sign
up
here,
send
me
your
email,
ids
and
I
can
get
them
approved
for
contributor
or
author.
So
once
you
do
that
you
could
join
the
cs
community
of
your
choice.
So
here
here
what
we
are
talking
about:
acs
kubernetes
benchmark.
So
let's
just
click
here.
B
B
Basically,
basically,
you
have
defense
sessions
in
the
benchmarks,
if
example
API
server,
NEPA
cell
Vascular
controller
manager,
cubelet
proxy
node
spots,
it's
continuous.
So
these
are
just
the
skeleton
that
I
have
buried
so
far
and
inside
each
of
the
sections
you
will
have
various
recommendations
so,
for
example,
for
API
server
do
not
allow
privilege
container.
So
this
becomes
a
title
of
the
benchmark.
This
becomes
the
title
of
the
rule
and
it
automatically
gives
the
section
ID.
Then
you
write
a
bit
of
description
about
it,
rational.
Why?
B
Why,
at
all
we
are
recommending
this
check
and
then
applicable
profiles,
and
how
do
you?
How
do
you
do
this?
So
let
me
show
you
how
it
is
written,
how
how
I
wrote
it
for
docker.
So
maybe
you
get
an
idea
of
what
we
are
talking
about
here,
so
yeah.
So
basically,
this
is
the
CIF
site.
Where
everything
happens,
so
you
can.
You
can
raise
tickets.
If
you
have
an
issue,
so
then
come
down
to
tickets-
and
you
can
add-
and
you
pick
it
right
from
here-
then
you
can
have
some
open
discussions.
B
You
can
have
some
discussions
over
here,
like
you
go
to
discussion
and
you
can
have
just
a
discussion
like
how
do
you
have
it
on
github
for
a
feature
or
for
a
recommendation?
One
cool
idea
here
is
that
under
each
of
the
recommendation
section
you
have
something
like
add
new
and
proposed
new.
Add
new
can
be
done
only
by
authors,
where
they
can
add
new
guidelines
and
contributors
can
only
provide
comments
on
that
propose
new
is
the
button
which
is
open
to
everyone
in
the
community.
B
So
if
somebody
feels
like
that
they
have
a
recommendation,
just
go
to
propose
new
and
over
here
they
can
provide
title
the
scoring
standard,
the
description,
the
rationale,
the
audit
procedure,
that
how
do
you,
auditor,
setting
the
remediation
negative
Empire,
the
default
value
and
their
references
and
just
say,
add
so
once
they
do
that
it
goes
to
the
authors
and
they
can
review
the
recommendation
and
they
can
already
merge
it
with
the
benchmark.
So
it's
very
much
like
a
or
get
a
pull
request.
So
it's
easy
to
contribute
for
anyone,
but
yeah.
A
B
Doesn't
have
those
recommendations,
yeah
you're
right
so
usually
with
the
vendors,
the
adventure
of,
let
me
show
you
the
doctor
benchmark.
So
if
we
Philip
Drucker
benchmark
they,
they
don't
have
all
the
security
combinations
at
one
place
and
it
is
not.
It
is
not
in
this
format
like
they
don't
have
the
audit
settings,
they
don't
have
the
remediation
steps.
So
what
this
benchmark
really
provides
is
the
example.
Let
me
open
the
container
run
time.
So
if
you
see
that
under
container
run
time,
we
have
bunch
of
recommendations
here,
for
example,
let
me
go
to
you.
B
Let
me
go
to
say,
for
example,
do
not
host
do
not
share
house
UTS
namespace.
Now,
if
you
see
darker
documentation,
don't
have
this,
so
they
do
not
have
a
crystal
clear
or
a
very
crisp
guidelines
saying
that
do
not
share
host
UTS
namespace,
and
then
they
don't
have
rationale
there
and
the
most
important
thing.
They
don't
have
this
audit
procedure.
B
So
in
the
benchmark
we
write
recommendation,
which
must
have
audit
procedures
right
that
that's
what
provides
scalability
the
benchmark
that
you
can
not
only
talk
about
the
settings,
but
you
can
actually
audit
further
that
setting
it
is
in
place
or
not
so
the
benchmark
provides
the
audit
procedures
and
it
also
provides
the
remediation
procedure
and
it
has
the
default
value
like
by
default.
Your
CPA
are
not
secure
and
then
your
references.
So
if
you
see
each
of
the
item
is
very
much
complete
and
the
vendor
documentation
doesn't
provide
that.
B
Yeah,
so
basically,
what
vendors
do
that
that
they
don't
have
all
these
security
recommendations
in
one
place,
so
they
have
like
multiple
documents:
multiple
white
papers,
then
your
best
practice
documents,
but
they
don't
have
something
in
this
format,
but
yeah.
There
are
certain
vendors,
for
example,
if
you
look
at
VMware,
it
has
a
vSphere
hardening
guide,
so
vSphere
hardening
guide
is
pretty
much
in
this
benchmark
format,
whether
it
talks
about
vulnerability.
He
talks
about
the
audit
procedure,
elimination
procedures,
so
it's
really
up
to
the
vendor
documentation.
B
A
So
yeah,
so
if
people
are
interested
in
in
jumping
in
with
suggestions,
I
I
do
think
we
part
of
what
we
are
working
on
is
getting
hardening
guides
set
up
for
kubernetes,
and
so
I
want
to
not
duplicate
efforts.
So
if
we,
if
we
figure
out
how
to
take
information
from
one
and
fold
it
into
the
other
or
monitor,
suggestions
to
one
I,
just
I,
just
don't
want
to
people
to
have
to
duplicate
work,
and
so.
A
B
A
These
are
the
api's
that
allow
delegating
authorization
and
token
authentication
checks.
So
the
subject:
access
review
and
the
token
review
api's.
This
is
what
are
used
by
the
webhooks
to
externalize
authorization
and
authentication
and
what
is
also
used
by
the
cubelet
to
delegate
authorization
and
authentication
to
the
api
server.
A
Those
api's
are
going
to
be
one
four
one
six
and
that
will
let
us
promote
the
features
that
build
on
those
api
is
too
stable,
probably
in
the
one
seven
timeframe.
So
just
wanted
to
make
people
aware
of
that,
because
those
are
not
persisted.
Api's
they're,
just
api's
that
are
used
to
query
the
API
server.
There's
no
data
migration
will
will
leave
the
v1
beta-1
api's
in
place,
probably
indefinitely,
since
it
doesn't
really
cost
us
anything.
The
shape
of
the
API
didn't
change
between
v1
beta
1
and
V
1.
A
So
this
is
more
a
positioning
positioning,
the
things
that
build
on
them
to
be
able
to
be
stable
and
then
the
last
thing
that
I
had
I'm
working
on
Auto
reconciliation
of
the
bootstrap
rolls
and
roll
bindings.
So
when
you,
when
you
start
up
an
API
server,
there's
a
set
of
fundamental
roles
that
are
needed
to
allow
parts
of
the
API
server
to
make
API
calls,
and
some
of
the
controllers
and
cubelets
to
make
API
calls.
So
those
roles
are
predefined.
A
A
What
permissions?
Those
rolls
contain
changes
over
time
right,
a
new
resource
gets
added,
and
so
the
bootstrap
roll
gets
updated
to
include
that
new
resource,
and
so
we
need
a
process
for
ensuring
that
the
bootstrap
rolls
have
that
minimal
set
the
minimum
required
set
of
permissions,
and
so
what
we
are
doing
to
ensure
that
is
initially
on
startup.
A
The
API
server
will
look
at
the
bootstrap
rules
that
expects
look
at
any
bootstrap
rules
that
are
already
in
SED
and
add
any
missing
permissions
to
those
roles.
So
it's
not
going
to
remove
permissions.
This
lets
us
stay
backwards
compatible.
If
we
tighten
roles
at
some
point,
Auto
reconciliation
will
not
remove
permissions
during
an
upgrade.
An
admin
would
need
to
go.
Do
that
themselves
once
all
of
their
H,
a
masters
have
been
upgraded
and
everything
using
those
old
roles
had
been
updated,
but
this
lets
us
do
upgrades
without.
A
Requiring
users
to
do
like
a
manual
step
like
update
one
master
and
then
run
a
migration
and
then
bring
up
your
controllers.
It
just
lets:
let's
abuse
our
paroles
be
self
maintained,
and
so
this
is
a.
This
is
a
closed
set
of
roles.
This
is
basically
the
roles
for
the
master,
the
nodes
and
the
controllers,
so
user
roles
that
they've
defined
themselves
wouldn't
be
touched,
and
there
is
a
there
is
a
way
for
them
to
mark
a
role
to
exclude
it
from
this.
A
If,
if
they
want
to
manage
it
themselves,
so
there's
an
opt-out,
it'll
probably
be
with
an
annotation.
If
you
annotate
a
role
and
tell
us
to
leave
it
alone,
we
will,
but
by
default
we
keep
the
system
working.
So
I'd
seen
a
couple
questions
in
the
flacc
channel
about
that.
If
some
of
the
roles
that
had
showed
up
in
1-5
would
be
would
be
updated,
one
specifically
I
think
was
missing
an
ingress
permission.
A
A
C
A
B
A
The
rule
of
thumb
is
whoever
creates
the
user
and
the
credential
is
responsible
for
giving
permission
to
that
user
or
credential,
and
so,
if
the
cube
of
scripts
are
setting
up
token
files,
for
you
know
bootstrap
users
or
users
or
admin
users,
then
the
cube
up
scripts
need
to
ensure
permissions,
and
so
I
think
I
saw
Mike,
adding
a
binding
for
the
bootstrapper
user.
That
cube
up
is,
is
setting
up
and
so.
B
A
Cubelet
this
is
this
is
what
we've
talked
about,
where
you're
switching
from
an
old
policy
system
like
a
back
to
our
back
and
so
I
think
what
we
have
to
do
there.
If
you
want
your
old
users
to
continue
working,
you
keep
your
old
policy
system
in
place
in
parallel,
and
so
that
looks
like
running
our
back
combined
with
your
old,
a
back
policy.
I
I,
don't
think
we
can
migrate
that
automatically
because
they
could
have
added
other
policy
grants
into
the
write-back
file.
A
C
C
I
yeah
I
was
hoping
to
be
able
to
let
you
cut
off
your
a
back
policy
before
you
had
upgraded
all
of
your
notes.
Maybe
that's
a
pipe
dream,
but
so
again,
Cuba.
A
Is
can
give
permission
to
a
user
named
cubelet
if
it
wants
to
what
once
you
start
giving
permissions
to
non
system
users,
it's
really
up
to
the
deployment
to
know.
Is
this
a
safe?
Is
this
a
safe
username
to
get
permissions
to,
and
so
once
you
get
to
the
edges
like
the
actual
deployment
mechanism,
whether
it's
Cuba
or
cube,
Adam
they're,
the
ones
who
set
up
off
and
know
who
the
users
are,
and
they
know
who
it's
safe
to
give
permissions
to
so
yeah.
The
other.
A
B
D
A
Yeah
I
think
maybe
doing
it
in
the
thread
would
be
better
I
think
that's
likely
have
a
broader
audience.
The
climax
is
the
implied
permissions,
not
being
a
thing
now
and
I.
Don't
know
that
I
I
think
there
are
two
views
to
it.
It's
not
a
clear
when
whether
it
makes
the
system
better
or
worse
or
easier,
to
understand
or
harder
to
understand,
fine.
D
A
D
B
Funding
Jordan
is
that
if
there
are
any
existing
security
recommendation
that
you
would
want
me
to
start
with
in
the
benchmark,
I
can
take
a
look
at
that
and
then
probably
can
get
started,
but
I
have
added
a
few.
A
skeleton
rules
like
I
have
17
recommendations
out
there,
which
I
have
found
from
covenant
is
different
documents
and
references.
Okay,.