►
From YouTube: Deep Dive: Kubernetes WG for Multitenancy - Sanjeev Rampal, Cisco & Ryan Bezdicek, Cray, Inc.
Description
Join us for Kubernetes Forums Seoul, Sydney, Bengaluru and Delhi - learn more at kubecon.io
Don't miss KubeCon + CloudNativeCon 2020 events in Amsterdam March 30 - April 2, Shanghai July 28-30 and Boston November 17-20! Learn more at kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects
Deep Dive: Kubernetes WG for Multitenancy - Sanjeev Rampal, Cisco & Ryan Bezdicek, Cray, Inc.
The deep dive will be an interactive session to discuss the status of multitenancy in kubernetes, run unconference style, with attendees proposing topics of conversation and participating in a group conversation about the most popular topics. We will discuss the on-going work the multitenancy working group is working on and more future focused issues around the various SIGs that have a vested interest in multitenancy.
https://sched.co/MPjr
A
A
What
we
were
thinking
of
doing
was,
we
have
some
slides,
but
I've
got
a
bigger
slide
deck
in
the
conference
agenda,
which
you
can
look
at
later
and
contact
us.
So
we
won't
go
over
all
of
those
slides,
but
does
the
audience
have
a
preference
on
how
much
slide
versus
demo
versus
interactive
discussion?
We
can
make
it
anyway,
yeah.
B
So
I
guess
first
friend
who
came
to
the
intro
yesterday,
anyone
awesome
and
who's
been
to
a
working
group
meeting
before
for
multi-agency
awesome
and
who
knows
nothing
about
multi-tenancy
at
all.
Okay,
awesome!
So
then
I
guess
it's
up
to
you.
We
can
do
slides,
that's
more
kind
of
deeper
level
than
in
the
intro.
We
have
a
demo
that
we
will
give
as
well,
or
we
can
kind
of
have
discussion
of
multi-tenancy
and
kubernetes
what
people
want,
what
people
need,
what
people
have
etc,
and
you
want
to
have
suggestions,
let's
raise
your
hands.
B
Yes,
yes
of
the
panel
yeah,
that's
more
for
kind
of
the
panel
discussing
how
we
are
implementing
multi-tenancy
within
our
companies,
and
so
that's
kind
of
we'll
get
into
that.
This
was
so.
This
was
originally
meant,
for
we
did
I
mean
up
in
the
Seattle
Cube
con
and
a
lot
of
people
liked
it,
and
so
we
had
a
very
interactive
people
discussing.
A
B
All
right
so
yeah
I
guess
we'll
just
do
a
few
slides
and
then
this
is
a
much
bigger
deck
that
you
can
look
on
afterwards.
We
also
have
a
lot
of
recordings
on
the
YouTube
channel
that
we've
done
so.
Most
of
this
is
kind
of
recap
that
we've
done
already
in
the
community,
and
then
we
will
go
through
a
quick
demo
and
then
we'll
do
will
save
about
half
the
time
for
Q&A.
B
Is
you
know
what
is
a
tenant?
It
means
a
lot
of
things
to
a
lot
of
people.
I,
don't
think
I've
heard
two
people
say
the
same
thing.
So
the
way
we
have
decided
is
we
have
to
kind
of
we
separate
a
tenant
in
our
working
group
of
a
soft
multi-tenancy
and
the
hard
multi-tenancy
hard
is
kind
of
you
know
self-explanatory.
You
don't
trust
anyone.
Soft
is
more
you're
trying
to
segregate
your
kubernetes
cluster
for
workloads
that
you
don't
really
trust
but
they're
kind
of
within
your
organization.
B
So
you
know
that
they're
probably
not
going
to
do
bad
things,
but
you're,
really
looking
for
kind
of
the
noisy
neighbor
situations
or
separating
like
development
groups,
etc,
etc,
and
so
that's
kind
of
what
we
call
a
tenant
so
and
most
of
the
work
we've
been
doing
is
on
the
soft
multi-tenancy
side
to
begin
with,
because,
as
you
can
imagine,
hard
multi-tenancy
is
hard
and
as
we've
discussed,
so
this
is
an
intro.
So
a
lot
of
you
kind
of
know
this
already,
but
we
don't
I
guess
from
a
hard
multi-tenant
perspective.
B
B
A
Group
is
one
set
of
efforts,
is
different,
architectures
for
multi
tendency,
and
we
want
to
let
the
community
develop
each
of
those
architectures.
So
we
are
not
yet
narrowing
it
down
to.
It
must
be
this
approach,
then,
within
those
architectures
we
have
individual
tracks,
okay,
so
these
are
four
ways
of
looking
at
possible
architectures
for
multi-tenancy
in
kubernetes.
Of
course
you
can
have
hybrids
and
so
on,
but
this
is
a
reasonable
way
to
look
at
four
categories.
A
The
first
category
is
running
multiple
kubernetes
clusters
on
top
of
NIS
right,
so
this
could
be
vSphere,
as
shown
in
this
slide,
but
it
could
be
OpenStack
as
well,
and
this
is
what
a
lot
of
customers
users
tend
to
start
off
with
I
already
have
an
I
as
I
can
create
one
cluster
pertinent
using
my
eyes
boundaries.
Let's
call
that
option
a
that's
one,
category
of
architectural
approach
for
kubernetes
multi-tenancy
option.
A
B
is
a
single
kubernetes
cluster,
but
an
actual
construct
called
a
tenant
for
multiple
tenants
within
the
same
kubernetes
cluster,
okay
and
in
option
B.
We
introduced
some
new
constructs
like
an
explicit
queue,
bananas,
resource
called
tenant
and
some
templating
objects
and
under
those
objects
under
those
new
objects.
We
combined
both
existing
resources
like
namespaces,
as
well
as
some
new
cubanelles
resources,
which
the
community
fields
are
appropriate
for
multi-tenancy.
So
that's
option
B
and
we'll
do
a
little
bit
more
discussion
on
that,
and
also
we'll
do
a
demo
on
that.
A
This
is
also
similar
to
what
a
lot
of
vendors
do
as
ad
hoc
solutions
for
multi-tenancy
today
right.
So
one
of
the
work,
the
goals
of
this
working
group
is,
there
are
lots
of
bits
and
pieces
in
communities
today
for
doing
multi-tenancy
and
namespaces
our
back
porch
security
policies,
network
policies,
but
still
there
is
no
official
direction
from
the
community
from
CNC
or
given
a
disc
immunity.
Does
community
support
multi-tenancy
yeah
kind
of,
but
you
have
to
kind
of
build
it
yourself.
A
So
one
of
the
goals
of
this
working
group,
and
we
would
invite
your
suggestions
for
additional
goals,
but
one
of
the
goals
is
well.
Let's
see
what
kind
of
reference
architecture
can
be
done
so
that
everybody
can
agree
on
a
standard
way
of
doing
any
of
these
architectures
right.
So
that's
option,
B
option.
C
is
a
proposal.
We
recently
got
from
Alibaba
cloud
that
way
they
brought
it
to
the
working
group
and
they
said
well.
Why
don't?
A
So
if,
if
every
tenant
wants
to
get
their
own
full
kubernetes
cluster,
but
you
don't
want
to
run
it
on
an
is
right,
you
want
to
have
the
whole
solution
be
more
cloud
native.
There
is
something
like
option
C,
so
the
community
wants
to
see
that
work
develop.
So
we
will
have
more
discussions
on
option
C
in
future
meetings
of
the
working
group
option.
D
is
sort
of
a
theoretical
possibility.
A
Right
now,
which
is
rewrite
core
kubernetes
to
introduce
the
concept
of
a
tenant
right
into
code
cabinet
is
okay,
so,
where,
as
option
B
was
sort
of
adding
new
custom
resources
on
top
of
existing
communities.
Option
D
is
going
to
the
kora
Cork
of
you.
Given
it
is
groups
and
saying
we
need
to
embed
the
concept
of
a
tenant
right
into
the
Kuban.
It
is
API,
so
just
like
OpenStack
right
in
OpenStack,
every
API
call
to
Nova
Neutron
has
a
tenant
ID
in
there
right.
A
You
are
actually
making
calls
through
in
the
context
of
a
tenant.
That's
the
first-class
citizenship
right
in
OpenStack
of
tenants.
Kubernetes
was
never
designed
to
have
tenancy
as
a
first-class
resource
right
so
option.
D
would
be
going
back
and
adding
tendency
as
a
first-class
resource
into
cribben.
It
is
so
you
can
imagine
that
that
will
require
major
surgery
to
cribben.
It
is
and
that's
why
that
is
for
now
a
theoretical
possibility,
if
there's
sufficient
interest
in
the
community,
hopefully
that
can
be
developed
further.
A
So
at
this
point
the
working
group
is
saying
these
are
the
categories
of
solutions
and
we're
not
eliminating
any
of
these
at
this
point,
because
each
have
value,
but
then,
wherever
we
find
contributors
willing
to
spend
more
time
and
resources
that
track
gets
more
development.
So
right
now
we're
developing
the
option.
B
track
a
little
bit
more
ok
and
then,
hopefully,
we'll
see
option
C
develop
more
as
we
get
contribution
from
Alibaba
others.
Yeah.
A
A
C
A
Can
I
believe
and
let's
continue
further,
but
I
believe
that
particular
requirement
can
actually
be
bet
by
all
of
these
architectures
but
feel
free
to
discuss
if
you
feel
it
doesn't
match
your
expectations.
So
let's
keep
going
so
we're
gonna
skip
over
some
of
these
slides
because
we
want
to
have
more
time
for
Q&A.
So
there's
more
details
on
comparison
of
these
architectures,
which
you
can
look
at
later,
I'm
also
going
to
skip
over
this
slide,
because
this
says
well,
if,
if
somebody
says
I
have
to
do
a
multi-tenancy
solution
today,
what
do
I
do?
A
Well,
you
can
do
a
hybrid
solution
as
well.
You
can
combine
options
a
and
B,
or
you
can
say
well
for
those
can
cuss
those
applications
that
really
need
privileged
containers.
I
want
to
use
dedicated
clusters,
but
on
the
same
infrastructure,
I
can
have
shared
and
dedicated
clusters
and
for
those
applications
where
soft
sharing
is
possible.
In
that
same
infrastructure,
I
can
have
shared
clusters
but
again
I'll
for
keeping
your
the
discussion
going.
I'll,
let
you
all
look
at
it
later.
This
is
a
little
bit
more
detail.
Ryan,
you
want
to
add
to
it.
B
This
is
really
the
option
B
that
we've
been
implementing
and
I
guess
it's
kind
of
to
go
back
to
some
of
your
questions,
for
so
all
of
this
is
running
in
the
same
these
questions,
right
and
so,
and
what
we're
doing
is,
as
sandy
mentioned,
is
we're
really
kind
of
putting
the
tools
together
to
build
multi-tenancy
within
it.
But
the
tools
are
the
native
kubernetes
tools,
so
network
policies
and
OPA
and
those
sorts
of
things.
So
if
you
do
need
inter
tenant
communication,
that's
not
prevented
here.
B
It's
just
a
matter
of
your
I
guess,
implementation
of
it,
and
so
this
kind
of
describes
how
a
kubernetes
cluster
would
work
in
you
know
the
the
option
B
that
we
are
building
tenants
can
span
multiple
worker
nodes.
You
know
you
could
always
use
you
know,
affinity
and
Anthony,
etc
to
segregate
things
as
you
need,
but
it
just
kind
of
sees
how
attend
it
looks
kind
of
at
a
higher
level.
Yeah.
A
D
B
Okay,
so
the
quick
recap
of
the
two
questions,
one:
what
about
cluster
scoped?
You
know
resources
I,
guess
in
Justin.
To
is
why
not
just
skip
to
option
D
because
of
these
issues
all
right.
What
was
that
yeah
how's
it
well
I
mean
the
difference
is
right:
option
D
requires
significant
changes
to
API
machinery,
the
cubelet,
etc,
etc,
etc,
and
so
you
know
who's
gonna
fund
that
it's
really
the
question.
So
that's
and
that's
it
right.
We
don't
want
to
try
to
solve
everything
today.
We
want
to
provide
solutions
in
the
short
term.
B
Well,
we
can
tackle
those
because
they
are
big
undertakings
and
you
know
we
also
need
I,
guess
the
community
involvement
to
say
that's
what
we
want.
So
there's
a
lot
of
people
that
don't
think
option
D
should
be
part
of
core
kubernetes,
and
so
it's
it's
really
up
to
the
community
to
say
yeah.
We
think
that
it
should
be
there
and
so
option.
B
is
kind
of
our
compromise
too.
Until
we
can
gather
the
you
know,
the
requirements
and
the
I
guess
the
the
interest
from
the
community
to
actually
implement
it.
B
So
that's
kind
of
the
reason
why
you
not
go
to
option
D
and
the
first
question.
You
know
cluster
yeah.
We
haven't
resolved
that.
That's
really
the
answer
right.
So
that's
that's
most
of
the
discussions.
If
you
go
back
to
the
last
few
weeks
of
our
of
our
working
group
meetings,
we've
been
discussing
that,
how
do
we
solve
you?
Know,
cluster
scoped,
resources
and
kind
of
the
answer
so
far
has
been.
You
know
it's
really
hard
and
even
you
know
the
Alibaba
solution.
A
My
initial
thought
is
that
in
option,
B
tenants
will
never
get
any
cluster
scope
resources
at
all.
It's
a
restrictive
model.
You
can
only
get
namespaced
resources
in
option
B
and
even
you
cannot
necessarily
get
all
name:
split
resources.
Okay,
it's
a
depending
on
how
conservative
you
want
to
create
the
security
profile.
So
we
also
have
the
notion
of
well
having
a
few
reference
security
profiles
and
if
you
want
one
particular
reference
profile
in
which
a
tenant
only
gets
namespace
resources
and
doesn't
even
get.
A
For
example,
network
policy
names
place
resources
because
there's
a
chance
that
a
malicious
tenant
or
a
in
we're
you
know
by
mistake:
they
can
actually
write
network
policies
that
break
the
namespace
boundaries,
so
you
do
not
want
to
give
in
so.
Yes,
all
of
those
are
valid
points.
They
come
into
the
precise
documentation
of
the
security
profiles.
So
let's
keep.
Let's
keep
that
discussion
going.
A
So
this
is
a
quick
are
now
talking
about
the
specific
demo
that
we're
gonna
briefly
show
you,
although
these
personas
kind
of
applied
to
all
these
models.
Really.
So,
let's
think
of
it
in
this
manner
that
there
is
a
cluster
admin
there
is,
there
is
X
number
of
tenant
admins
and
then
there
are
tenant
users
right.
So
again
we
want
to
make
sure
that
you
as
users,
think
this
is
these
are
adequate
workflows
or
if
you
have
ideas
for
other
workflows
that
the
community
should
support,
then
please
bring
them
to
us.
A
So
in
this
in
this
workflow
a
kubernetes
cluster
admin
provisions,
the
cluster
for
the
first
time
with
one
of
n
recommended
security
profiles
right
so
the
you,
the
cluster,
needs
to
have
baseline
security
in
order
to
even
support
multi-tenancy.
So
a
baseline
security
profile
may
say
you
must
have
prod
security
policies
enabled
you
must
have
our
back
enabled.
You
must
have
you
know
at
CD
secrets,
encryption
enabled.
Otherwise
this
cluster
doesn't
even
qualify
for
multi-tenancy
right,
so
the
cluster
admin
set
that
up
and
then
the
cluster
admin
also
provisions
complied
objects.
A
So
we've
we've
considered
that
there
would
be
tenant,
template
objects
and
namespace
template
objects
in
the
demo
will
show
namespace
template
objects,
and
these
are
the
templates
that
the
cluster
admin
says
should
be.
These
are
curated
templates,
which
they
want
all
users
and
all
tenants
to
use
once
the
cluster
has.
Admin
has
done
that
any
user
can
self-service,
create
tenant
okay,
so
we
do
not
want
to
have
a
process
where
you
have
to
open
a
ticket
in
order
to
create
a
tenant.
A
A
So
this
user,
referring
to
the
tenants,
creates
the
tenant
templates,
creates
the
tenant
object
and
also
identifies
the
admins
and
access
controls
for
that
tenant
object
right,
so
one
so
the
model
we
are
thinking
of
right
now
is
anybody
can
create
tenants,
but
once
a
tenant
is
created
during
the
creation
of
tenant,
you
decide
who
has
subsequent
crud
permissions
on
that
tenant
right.
So
we
use
named
are
back
policies
in
the
prototype.
There
could
be
other
ways
of
using
OPA
and
so
on
for
doing
it
right.
A
So
hopefully
this
will
be
even
more
clear
in
the
demo
and
then
finally,
you
know
here
are
the
reference
profiles.
We
are
working
towards
again.
We
would
love
your
input
on
whether
these
make
sense,
but
the
first
profile
is
essentially
mostly
leveraging
functionality
that
already
exists
in
communities
right
and
in
the
second
profile
which
we
want
to
track
upcoming
functionalities
such
as
new
runtimes,
like
cryo,
and
so
on
and
dynamic
policy
engines
like
OPA,
and
that
would
be
another
reference
policy
that
security
profile
that
we
would
collectively
produce
as
a
reference
in
the
working
group.
A
With
that,
let
me
just
switch
to
the
demo
and
then
we'll
have
open
Q&A
after
that
there's
more
slides
here
in
the
deck
which
I
would
encourage
you
to
look
at
later.
But
these
describe
some
more
about
the
architecture,
the
sample
ten
in
specifications
and
so
on.
Okay-
and
we
also
have
some
information
on
the
kinds
of
topics
that
the
working
group
is
currently
working
on,
and
we
would
love
your
input,
contribution,
suggestions
and
so
on.
A
A
A
A
A
A
Okay,
so
let
me
just
run
it
and
explain
it
along
the
way.
So
the
first
thing
is
I've
already
installed
the
cluster.
As
I
said,
the
cluster
admin
needs
to
create
the
cluster
with
a
default
security
profile
already
right.
So
the
first
thing
we
notice
is
that
this
cluster
has
new
API
resources
in
this.
In
this
POC
we've
got
namespace
templates
and
knee
and
tenant's
the
last
two.
When
we
do
the
API
resources
right,
so
the
cluster
admin
would
pre,
create
these
additional
objects
and
also
pre
configure
the
recommended
security
profile
right.
A
We
in
this
cluster
is
using
a
security
profile
similar
to
the
profile
a
we
showed
earlier,
so
we've
got
pod
security
policies
enable
for
example,
pod
security
policies
enabled
one
for
privileged
tenants
and
restricted
tenants
very
similar
to
the
documentation
already
there
in
the
Kuban
ideas.
Documents
about
you
know
privileged
part
security
profiles
and
restricted
pod
security
profiles.
A
A
A
In
this
case,
we
are
saying
we're
creating
a
template
which
says
all
namespaces
belonging
to
tenants
with
this
profile
with
this
template
should
use
this
pod
security
policy
right
so
the
same,
restricted,
pod
security
policy
we
showed
earlier-
and
we
say
that
this
is
the
the
subjects
are
going
to
be.
The
service
accounts,
so
all
service
accounts
in
the
namespace
that
you,
this
template
will
will
automatically
use
this
pod
security
policy.
We
could
also
have
added
a
network
policy.
A
A
So
so
that
was
a
look
at
the
namespace
template.
So
now
the
cluster
admin
decides
to
instantiate
the
namespace
template.
So
it's
created
this
template
called
restricted
and
there
it
is
the
next
thing
we
now
now
we
are
looking
at
the
role
of
any
tenant
user
right,
so
so
a
tenant,
a
tenant
admin
or
really
any
authenticated
user.
We
could
refine
this
further.
We
could
have
restricted
users
who
you
know
subset
of
users
that
can
only
create
tenants
and
so
on.
But
essentially
this
is
a
self-service
model.
A
So
they're
gonna
use
this
kind
of
a
manifest
to
say.
Okay,
I
want
to
create
turning
a
with
two
namespaces
ns1
ns2.
Both
of
these
are
going
to
use
the
namespace
template
restricted
and
the
admins
of
this
tenant
are
going
to
be
everybody
that
belongs
to
the
rback
group.
Can
it
a
admins
right
so
I
did
not
need
to.
This
is
a
self-service
model.
I
am
creating
a
tenant
and
pre,
specifying
the
admins
right,
but
I'm
I'm,
using
the
infrastructure
definition
that
the
cluster
admin
has
enforced
right.
A
Okay!
So
now
look
at
the
namespaces
here
right.
So
we
said
that
in
the
template
for
this
in
the
specification
for
this
tenant,
we
said
we
want
to
name
spaces
with
templates
matching
this
particular
pre
created
tenant,
and
so
we
actually
created
two
namespaces
but
we've
in
the
current
prototype.
We
prepend
the
tenant
name
to
the
namespace
name
in
order
to
make
it
unique
so
that
you
know
any
a
bunch
of
tenants
can
create
their
own
namespaces,
but
we
don't
want
to
have
clashing
namespace
names.
A
A
So
so
now
the
tenant
is
created-
and
we
are
just
trying
to
you-
know
see
whether
this
is
actually
a
sandbox
tenant
right.
So
we
tried
to
create
a
privileged
container
in
the
in
the
tenant
and,
if
you
recall,
the
template
had
the
restricted
port
security
policy,
so
the
tenant
could
not
create
a
deployment
which
had
a
container
that
needed
to
run
his
route,
because
what
we
are
recommending
initially
is
a
completely
sandbox
policy,
no
privileged
containers,
no
running
as
root,
and
so
on
it
so
happens.
A
We've
also
created
a
privileged
tenant
here,
just
to
as
an
illustration,
and
it
so
happens
that
that
privileged
tenant
can
in
in
fact
create
privileged
containers.
Normally,
we
would
not
recommend
mixing
privileged
tenants
and
non-privileged
tenants
in
the
same
cluster.
That's
when
you
would
have
the
hybrid
solution
of
option
a
and
B,
where
you
would
give
give
those
containers
their
own
dedicated
cluster
right.
A
So
so
that's
it.
That
was
a
kind
of
a
quick
demo.
Hopefully
y'all
get
off
got
a
feel
for
this
prototype.
This
is
just
capturing
some
ideas
that
the
group
has
been
throwing
around
for
option
B.
As
we
said
earlier,
we're
going
to
continue
encouraging
collaboratively
the
development
of
all
of
these
options,
and
we
would
really
love
lots
of
user
input
on
areas
that
we
should
be
focusing
on.
What
helps
you
as
a
cluster
admin?
How
do
you?
A
B
E
Mean
I
love
your
multi-tenancy
ideas,
but
I
think
that
to
you
I
mean
you
definitely
live
in
right
now.
The
end
end-user,
who
will
be
my
uber
off,
will
be
and
as
a
even
tenant
user
and
I
feel
that
I
was
thinking
as
a
tenant.
User
I
probably
want
to,
let's
say,
create
ingress,
create
volume
and
I,
don't
want
to
specify
any
classes
and
I
not
sure
how
it
fits
in
your
multi-tenancy
model.
Where
don't
a
will
have
one
default,
ingress
default,
storage
quality
for
something,
and
then
we
will
have
different
default
storage
class.
A
I
have
some
thoughts
on
it
right
so
well.
Firstly,
we
mentioned
that
we
have
pre
created
templates
right,
so
you
would
pre
create
templates
and
then,
additionally,
you
would
be
able
to
either
via
our
back
or
things
like
oppa
decide
that
tenènte
only
gets
to
use
template
one
two
and
three
and
ten
and
B
gets
to
use
templates
four
five
and
six,
so
you
can
have
things
like
okay
tenant.
A
can
only
pick
from
these
templates,
and
can
it
be,
can
only
pick
from
those
templates
as
we
develop
it
further.
B
F
A
A
Yeah,
yes
exactly
so
we
used
our
back
on
named
resources,
so
what
happens
is
initially
every
cluster
user
has
create
permission
for
tenants,
but
not
update
or
delete
permissions.
So
anybody
can
kick
off
the
creation,
but
as
part
of
the
creation,
you
specify
the
list
of
admins
that
can
do
subsequent
operations.
Those
additional
users
will
be
able
to
do
updates
and
deletes
so
I
can
create
tenant
a
and
say
only
users,
one
two
and
three
can
delete
tenday
or
modify
it.
Somebody
else
can
create
tenant,
B
I
wouldn't
be
able
to
delete
that
and
B.
A
B
I
also
add
to
that
so
yeah.
So
if
you
go
back
to
or
one
of
our
slides,
we
had
the
different
personas.
So
in
your
question
is
how
do
you
delete
a
specific
namespace?
Not
the
whole
tenant
is
my
understanding
right,
yeah,
so
so
yeah
in
that
situation,
you
basically
need
to
be
basically
that
tenant
admin
level
and
then
you
can
modify
the
tenant
to
delete
a
namespace.
B
So
because
you
provide
you
provide
the
namespaces
you
want
added,
and
so
that's
that's
how
that's
handled,
but
at
the
end
of
the
day
again
it
comes
on
the
our
back
right,
but
from
deleting
and
creating
namespaces
within
a
tenant.
It
comes
down
to
that
tenant.
You
know:
tenant
admin,
Iraq
roll,
so
answer
your
question.
B
A
Let's
continue,
we
really
would
love
to
have
a
lot
more
user
input,
because
you
can
completely
shape
how
this
work
goes.
We're
still
in
a
very
very
early
stage,
and
you
know
we
welcome
all
feedback.
As
saying
hey,
you
know
the
existing
Cuban
and
is
constructor
enough.
I
just
want
reference
profiles
or
no,
they
are
not
enough.
I
want
these
kinds
of
CDs.
However,
you
feel
would
be
most
useful.
That's
how
we
can
take
this
forward.
G
H
A
Yeah,
so
so,
using
you
know
things
like
no
taints
and
having
policies
that
say
that
let's
say
it
could
be
like
this
namespace
in
this
tenant
is
exclusively
using
these
two
nodes.
Maybe
you
have
some
privileged
containers
in
that
in
just
in
those
two
namespaces,
and
you
need
to
allow
that.
So
that
is
certainly
possible
again.
It
is
setting
up
the
templates
and
the
security
profiles
which
is
giving
the
instrumentation
you
can
set
up
the
profiles
to
do
that.
I
So
hi
I,
like
the
idea
of
Plan
B,
actually
and
the
reason
we
have
been
discussing
internally
a
lot
about
about
this
problem.
So
simply
what
we
had.
We
had
this
missing
juror
article,
you
know
second
level
from
having
namespace
at
top
of
it
and
how
I
can
deal
with
quote
and
resources.
Yes
in
an
automation
way,
so
I
don't
want.
Every
customer
will
contact
the
cluster
admin
and
asking
create
a
namespace
for
me.
Yeah.
A
I
H
I
Which
is
excellent,
that
is
definitely.
This
is
what
we
are
looking
for
and
I'm
happy
to
start,
seeing
that
it's
coming,
what
about
the
quota
resources
so
I
know
that
we
can
set
it
at
the
level
of
the
project
or
the
tenant.
Does
that
in
fact
impact
the
namespace
itself
in
a
way
that,
when
I'm
giving
them
six,
let's
say
CPU
and
X
number
of
gigabyte
of
memory?
Can
they
still
the
admin
of
the
tenant
really
distribute
is
between
the
namespaces
underneath?
Thank
you.
Yeah.
B
So
I
mean
right
now
we
can't
at
the
tenant
level,
so
you
can
set
it,
but
it
would
basically
have
to
duplicate
for
the
tenant.
Yeah
are
through
the
namespace.
So
that's
something
we've
actually
discussed
quite
a
lot
of
that's
the
number
one
ask
really
of
other
people.
Is
we
don't
really
care
about
multi-tenancy?
We
just
want
to
do
basically
resource
quotas
for
multiple
namespaces,
so
that
you
know
you
know,
test
and
prod
know
we're
intestine
staging.
B
You
can
run
in
the
same
cetera,
so
yeah
we're
talking
about
it
and
we're
looking
at
those
implementations,
but
right
now
it's
basically
you
have
to
set
it
still
at
the
namespace
level,
within
your
your
tenant
and
so
yeah.
We
haven't
really
figured
out
the
details
of
how
you
could
do
that
at
tenant
creation.
How
a
cluster
admin
can
kind
of
provide
that
and
that's
kind
of
what
the
next
steps
were
or
give
me
a
name
to,
as
now
that
we
have
kind
of
a
POC,
we
can
take
that
a
little
further.
So
that's.
A
H
I
A
Absolutely
the
goal
and
it
and
the
quota
would
be
not
tied
to
a
particular
namespace.
It
is
across
all
the
namespaces
within
that
tenant.
So
the
thought
is
to
develop
a
new
admission
controller
which
tracks
the
usage
across
those
namespaces.
So
it
doesn't
matter
if
you
the
namespace
themselves,
doesn't
we
don't
match
it
against
the
quota?
We
aggregate
the
usage
across
all
the
tenants
and
that's
so
the
the
task.
There
is
to
actually
write
some
an
admission
controller
which,
right
now
it
says,
a
task
on
the
roadmap.
J
I
work
at
Lloyds,
Banking
Group
right
now,
IBM
are
creating
a
cubanelles
cluster
for
a
lot,
a
lot
at
the
bank
using
IBM
cloud
private
and
that's
the
problem
that
they've
been
discussing
for
quite
some
time.
Let's
just
try
to
do
that
and
what
they've
come
up
with
is
dev
tests
and
pre,
prod
namespaces
and
then
within
that
they're
controlling
the
resources
from
that.
So
you
don't
actually
get
access
to
control
the
tenant
level.
So
it's
just
namespace
level
that
we
can't
control.
We
can't
control
anything
within
the
cluster.
A
Yeah,
so
that
would
address
that
as
well
again,
we
find
that
many
cluster
admins
have
done
their
own
custom
solutions,
so
we
would
love
to
just
take
whatever
is
out
there
and
just
kind
of
having
a
common
reference,
because
everybody
has
the
same
problem.
It's
just
that
they're
either
doing
some
custom
automation
and
we
in
the
working
group
we
can
say
well,
whatever
helps
the
community.
If
the
community
says
I
already
have
this
solution,
it
works
for
everybody.
We
just
standardize
that
right,
so
we
just
qualify
that
and
so
on.
So
yeah.
A
K
I'm
not
talking
about
denial
of
service
I'm,
talking
more
about
privilege,
escalation
and
compromising
the
cluster.
So
at
the
moment
the
API
server
handles
authorization
and
authentication,
and
once
you
get
access
to
the
API
server,
you
have
access
to
the
entire
cluster.
Yes,
so
there's
no
there's
no
authentication
or
authorization
beyond
the
API
server.
So.
A
A
L
A
L
A
With
with
option
B,
there
is
no
tenant
identification
in
the
API
calls.
That
would
be
something
like
option:
D,
where
that
there's
a
tenant,
ID
embedded
in
every
API
call.
That
requires
a
lot
more
work
but
option
B
the
tenant
ID
is
derived
I
mean
this
is
just
like
you
know:
kubernetes
doesn't
have
user
IDs.
You
right,
you
don't
even
have
the
concept
of
users
to
begin
with,
so
the
API
calls.
So
the
option
B
follows
that
kind
of
model.
A
M
So
basically
are
very
much
like
the
idea
of
having
something
like
namespace
templates
and
my
University.
We
are
in
a
scenario
where
we
drive
the
author
author
vacation
through
an
external
system,
so
we
are
basically
running
a
github
instance
if
we
want
to
automatically
create
tenants
based
on
changes
at
these
external
system-
and
this
is
quite
difficult
for
us,
because
now
we
have
these
idea
of
templates
and
we
want
to
dynamically,
create
these
templates
based
on
changes
in
gitlab.
So
any
thoughts
on
this
or
coupling.
M
M
A
A
B
B
B
L
L
N
A
So
so
we
look
forward
to
see
how
model
C
develops
over
the
next
few
months.
So
that's
why
we
say
we
are
keeping
all
these
tracks
open
right,
nothing
is
eliminated.
At
this
point,
we
make
progress
on
whichever
track
we
find
more
community
contribution
and
again
I
want
to
keep
reinforcing.
This
is
at
a
stage
where
all
of
you
can
make
a
major
difference,
bring
all
your
requirements,
suggestions,
criticisms
and,
let's
figure.
B
It
out
together,
so
we
are
like
way
past
time,
so
we'll
close
and
we
can
come
up
after
4
questions,
but
again
we've
been
discussing.
Also,
we
understand
that
Europe
is
not
really
well
suited
for
our
current
time
slot
that
we
meet
bi-weekly,
so
I
think
we're
gonna
set
on
a
poll
to
see
you
know
who,
from
around
the
world
really
wants
to
show
up,
and
so
we
might
be
changing
our
time
to
accommodate
so
I
guess
look
out
for
that.
Thank
you.