►
From YouTube: Lightning Talk: Namespaces-as-a-Service with HNC & Kyverno! - Jim Bugwadia, Nirmata & Adrian Ludwin
Description
Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon North America 2021 in Los Angeles, CA from October 12-15. Learn more at https://kubecon.io The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
Lightning Talk: Namespaces-as-a-Service with HNC and Kyverno! - Jim Bugwadia, Nirmata & Adrian Ludwin, Google
Kubernetes namespaces provide a strong security boundary and allow sharing cluster resources to reduce costs and increase efficiencies. However, enabling secure self-service namespaces is complex. In this session, Jim and Adrian from the Kubernetes Multi-Tenancy Working Group will demonstrate how the Hierarchical Namespace Controller (HNC) and Kyverno can be used together to enable “namespaces-as-a-service” for enterprise teams. First, Jim will show Kyverno how it can automate fine-grained permission management, enforce security, and generate default configurations. Next, Adrian will discuss how HNC makes it easy for developers to manage additional sub-namespaces without requiring cluster-admin privileges. They will then show a live demonstration of using the two CNCF projects together to enable self-service for namespaces without compromising security.
A
Hey
everyone:
this
is
jim
beguardia
from
nermata,
and
I'm
here
with
adrian
ludman
from
google
and
we're
going
to
talk
about
namespaces
as
a
service
using
hnc
and
kiverno,
so
in
kubernetes
namespaces
as
a
are
a
fundamental
building
block
for
segmentation,
isolation
and
a
number
of
other
kubernetes
resources,
such
as
roles
or
role,
bindings
secrets
quotas.
All
of
these
also
build
on
top
of
name
spaces
when
kubernetes
is
used
within
an
organization,
and
every
organization
of
course,
is
looking
to
deliver
value
faster
to
their
customers.
A
A
So
there
are
two
common
ways
that
multi-tenancy
is
typically
delivered
within
organizations
either
using
clusters
as
a
service
where
entire
clusters
are
created
for
application
or
protein
or
using
namespaces
as
a
service
where
a
shared
cluster
is
used
and
different
teams.
Different
apps
can
leverage
namespaces,
so
each
model
has
different
pros
and
cons.
Namespaces
as
a
service
is
slightly
less
flexible
because
you
know
you
cannot
have
cluster-wide
resources
per
tenant,
but
there's
a
lot
of
value
in
utilizing
namespaces
as
a
service
for
agility
for
increased
efficiencies.
B
So
I'm
going
to
talk
a
little
bit
about
hnc
itself,
so,
as
the
name
implies,
what
we're
doing
is
we're
taking
existing
kubernetes
namespaces
and
making
them
hierarchical.
Now.
Why
would
you
want
to
do
this?
Namespaces,
as
jim
said,
are
fundamental
to
a
lot
of
different
areas,
but
they
are
also
cluster
level
resources
and
by
default
are
completely
independent
from
each
other.
B
This
does
not
make
them
very
useful
within
any
kind
of
level
of
tenancy,
because
you
need
cluster
level
permissions
to
modify
them
and
it's
hard
to
apply
policies
across
across
a
set
of
namespaces.
So
with
hierarchical
namespaces
you
can
arrange
them
into
a
hierarchy
with
an
arbitrary
depth
and
you
could
modify
that
that
hierarchy
over
time
with
enough
permissions.
B
What
this
allows
you
to
do
is
it
allows
you
to
propagate
policies
from
parents
to
children
and
also
it
lets
you
do
some
neat
things
with
applying
policies
such
as
network
policy
across
a
group
of
related
name
spaces
as
well,
and
there's
a
bunch
of
other
talks
online
that
you
can
find
about
this.
Another
thing
that
lets
you
do
is
self-service,
namespace
creation.
So
typically,
you
need
cluster
level.
B
So
why
would
you
use
this?
Well,
it's
great
for
really
fine-grained
namespaces.
If
you
just
gave
every
tenant
to
one
namespace
and
said
well,
okay,
here's
your
playground!
You
can
do
everything
in
there
that
can
work,
but
it
doesn't
allow
you
to
differentiate
between
different
security
policies
that
might
be
applied
to
different
workloads
that
are
run
by
that
one
tenant
and
so
with
hsc.
You
can
write
composable
multi-name
space
policies
where
you
need
and
also
apply
workload,
specific
policies
where
those
are
required
as
well,
and
also
it's
useful
for
cell
service
name
spaces.
B
B
A
So,
very
briefly,
caverno
is
a
policy
engine
designed
for
kubernetes
where
policies
are
just
modeled
as
kubernetes
resources
itself.
There's
no
new
language
to
learn.
So
you
can
use
familiar
yaml,
syntax,
very
similar
to
customizers
overlay
patterns,
which
you
can
use
to
define
your
policies
itself
and
with
caverno
policies
you
can
validate
configurations.
You
can
also
mutate
existing
configurations
and
generate
new
resources,
as
required
based
on
different
triggers.
A
So
let
me
switch
to
my
console
and
what
I
have
here
is
agency
and
group
config
and
and
given
our
already
installed,
and
if
I
look
at
the
hnc
setup,
I'm
going
to
use
the
hns
command
line
plugin
and
describe
the
configuration
I
already
have
it
set
up
to
propagate
different
resources
like
network
policies,
role,
bindings
and
roles.
So
the
first
thing
I'm
going
to
do
and
just
to
further
you
know
kind
of
explain
the
setup.
I
have
I've
created
a
couple
of
custom
roles.
A
A
As
a
user,
one
of
the
namespace
admin
users,
nancy
and
kivarno
is
going
to
block
that
and
say
that
the
namespace
needs
to
have
a
label
which
designates
what
kind
of
resource
quota
it
requires
so
to
go
ahead
and
create
this.
I'm
going
to
now
use
a
yaml.
I
already
have
with
the
necessary
label
and
in
fact
what
I
should
do
is
I'm
going
to
create
this
as
the
as
the
right
user,
so
I'll
delete
that
namespace,
which
I
created
as
an
admin
and
we'll
go
ahead
and
create
it
again
as
the
user
nancy.
A
Okay,
so
now
that
the
namespace
is
created
as
this
user,
if
we
go
ahead
and
describe
the
namespace,
what
we
should
see
is
that
the
properties
for
that
namespace,
so
we
created
test,
so
it
already
has
the
resource
quotas.
It
has,
you
know
other,
like
the
limit
range
configured
and
it
should
also
have
if
we
do
a
get.
A
A
So
now
let's
go
ahead
and
create
a
sub
namespace
using
hnc,
so
I'll
use
the
hns
plugin,
and
here
I'm
gonna
to
for
that
user,
I'm
going
to
create
another
namespace
called
test2
under
test,
and
we'll
also
do
this
as
the
namespace
admin
user
nancy,
and
so
this
creates
the
name,
the
sub
name
space
and
just
to
see
how
that's
set
up.
If
we
look
at
that
as
nancy,
we
should
be
able
to
see
the
tree,
and
we
should
also
again
just
to
verify
if
we
try
it
as
the
other
user.
A
We're
not
able
to
see
that,
and
if
I
do
a
describe
on
this
on
test2,
which
is
the
other
namespace.
I
also
see
that
the
right
resources
are
propagated.
So
this
is
just
a
really
quick
demo,
which
shows
how
the
two
tools
again
can
work
together
to
solve.
Some
of
the
main
problems
for
namespaces
as
a
service.
A
So
just
to
summarize,
multi-tenancy
is
essential
for
most
organizations
for
community
success
and
namespaces
as
a
service
is
a
handy
way
of
providing
multi-tenancy
for
a
large
segment
of
applications
and
hnc
and
kiverno
can
work
together
to
automate
some
of
the
key
concerns
for
namespaces
as
a
service.
So
please
reach
out.
If
you
have
more
questions,
we
are
on
the
multi-tenancy
slack
channel
on
the
kubernetes
slack,
and
I
also
have
some
we
have
links
here
for
the
repos
for
hnc,
as
well
as
kiberno.