►
Description
While Kubernetes has a rich feature-set with RBAC and namespaces, it still falls short in making a multi-tenant solution possible out-of-the-box. How do you protect teams from each other without simply taking all of the control from them? For example, how do you prevent a team from defining an Ingress object that takes the traffic from another? Or how do you prevent teams from creating additional LoadBalancer services? Fortunately, Gatekeeper has come to the rescue! In this talk, we'll talk about admissions controllers and how Gatekeeper can solve these problems. We'll go over the Rego language (which takes some time to wrap your head around) and provide several examples of how Virginia Tech is using Gatekeeper to support multi-tenancy. While policy enforcement sounds scary, it certainly doesn't have to be!
A
Happy
to
be
here
and
looking
forward
to
to
get
in
a
chat
with
with
many
of
you
and
and
whatnot.
So,
as
was
mentioned,
I'm
gonna
be
talking
about
gatekeeper
and
opa,
open
policy
agent,
if
you're
not
familiar
with
it,
and
with
that
I'm
gonna
go
ahead
and
share
my
screen
and
we'll
cut
over
here.
Okay,
so
again,
I'm
at
virginia
tech.
Hopefully
I
don't
don't
know
what
point
it
cut
off.
A
How
do
we
use
computing
and
and
not
and
and
use
them
in
a
way
that
lowers
a
barrier
of
entry
for
others
so,
especially
for
devops-
and
you
know,
there's
just
a
lot
of
tooling
out
there
and
it's
hard
to
keep
up
with
it.
So
how
do
we
make
it
easier
for
people
to
use
and
we'll
we'll
see
examples
of
that
as
we
go
throughout
this?
A
I
am
an
adjunct
faculty
instructor
with
the
the
cs
department
and
I'm
actually
teaching
a
class
this
semester
on
kubernetes,
which
is
pretty
awesome,
so
we've
got
about
60
students,
learning,
kubernetes
and
whatnot.
So
if
anybody's
hiring
or
wants
to
hire
some
students
reach
out
to
me
and
I'll
be
happy
to
put
you
in
contact
with
them.
So
I
don't
know
if
I'm
allowed
to
say
that,
but
whatever
they
can
reach
out
to
you.
A
I
also
am
involved
with
the
community
quite
a
bit
and
family
guy.
Also,
my
five
kiddos
in
case
you're
wondering
this
picture
is
from
dockercon
2019
and
I
did
a
talk
called
container
for
beginners
and
I
just
like
to
have
fun
and
my
my
talk
was
one
of
the
the
higher
rated
ones,
and
so
I
was
invited
to
give
it
again
on
what
they
call
the
replay
day
and
don't
ask
why.
A
If
you
do
want
to
follow
me
on
social
media
or
whatnot,
I'm
mike
cer87,
pretty
much
everywhere.
So
m-I-k-e-s-I-r-87
all
right
enough
about
me.
So
here's
what
we're
going
to
talk
about!
Why
do
we
care
about
gatekeeper
and
opa?
What
what?
Why
did
we
get
interested
in
that
we're
going
to
talk
about
some
of
the
built-in
kubernetes
mechanisms
and
then
where
they
fall
short
and
then
how
gatekeeper
and
opa
kind
of
fill
that
gap?
A
And
then,
finally,
we're
going
to
talk
about
how
we're
applying
it
at
scale
here
at
virginia
tech
for
our
our
platform,
which
which
I'll
talk
about
here
in
just
a
second
okay?
So,
first
off?
Why
do
we
care
about
a
year
and
a
half
actually
is
about
two
years
ago
now
we
internally
had
what
we
called
a
process
improvement
initiative
cycle
going
on,
in
which
really
anybody
could
propose
ideas
for
kind
of
radical
or
new
processes
or
things
that
we
want
to
do
that
would
better
I.t
and
better
the
university.
A
So
I
proposed
this
idea
to
create
an
organizational
unit
that
provides
application,
technology,
infrastructure
and
shared
services
for
all
application
development
teams
in
the
division,
so
the
central
division
of
it
and
then
provide
it
as
a
service
to
all.
So
all
the
colleges
and
departments
and
other
development
teams,
et
cetera
and
the
the
original
goals
was,
we
want
to
be
able
to
leverage
a
single
common
platform
to
run
our
applications.
Those
of
you
that
have
ever
worked
in
a
higher
ed
institution
know
that
things
are
very
wild
west.
A
So
that's
that's
a
lot
of
the
things
that
we're
trying
to
solve.
How
do
we
provide
some
consistency
because
it
helps
recruiting
and
retaining
and
training
and
all
those
big
buzzwords
as
well
too
so
yeah?
So
that's
what
we're
trying
to
work
on
and
in
human
terms,
at
the
end
of
the
day,
it's
just.
We
just
want
to
be
able
to
deliver
faster
and
respond
quicker
without
having
to
train
everybody.
How
to
be
a
cloud
engineer,
and
so
I'll?
A
Let
you
read
the
text
here,
but
that
that's
really
the
end
of
the
at
the
end
of
the
day,
what
we
want
to
do
so
that
we
can
leverage
cloud
without
everybody
having
to
be
a
cloud
engineer.
We
want
everybody
to
be
able
to
use
containers
without
having
to
be
a
kubernetes
expert
or
in
a
swarm
or
any
of
these
other
things.
So
how
do
we
build
a
platform
with
the
right
levels
of
abstractions
to
let
people
move
quickly?
A
Okay-
and
this
final
bullet
point-
is
something
that
we
really
have
been
focusing
a
lot
on.
We
want
to
design
with
multi-tenancy
from
the
start.
We've
had
previous
efforts.
You
know
we
used
docker
enterprise
back
when
it
was
in
a
product
sold
by
docker,
and
it
just
didn't
really
quite
work
in
a
multi-tenant
environment,
and
so
that
that's
something
that
we've
been
really
again
focusing
on.
How
do
we?
How
do
we
run
kubernetes
in
this
case,
in
a
multi-tenant
fashion?
A
A
Okay,
so
we've
got
a
load
balancer,
that's
just
throwing
traffic
into
the
the
cluster,
and
then
we
are
basically
creating
node
poles
we're
using
aws
eks
for
the
control
plane.
But
then
we
have
node
pools
for
each
of
the
different
funding
or
organizational
units
and
then
within
each
of
those
node
pools,
people
can
run
pods
and
we've
got
cross-account
role
assumptions
to
let
them
access
other
aws
resources.
A
However,
they
they,
you
know
whatever,
whatever
resources
they
might
need
at
that
point
too.
So
now
again,
that's
super
high
level,
there's
a
lot
more
behind
the
scenes,
and
one
and
we'll
talk
about
some
of
those
things
of
how
we
provide
isolation
between
the
tenants.
But
for
the
most
part,
the
the
split
nodes
are.
The
split
node
pools
are
mostly
for
cost
accounting,
but
also
for
you
know,
another
security,
isolation
boundary
there
as
well
too.
A
So
when
we
think
about
multi-tenancy,
you
know
every
tenant
needs
to
have
its
own
namespace
and
kubernetes,
and,
and
that
provides
some
barrier
of
isolation
and
we'll
talk
about
where
that
breaks
down.
In
a
few
minutes
and
in
our
case
we're
defining
tenant
really
loosely
so
a
tenant
could
be
an
application,
it
can
be
an
environment
within
an
application.
So,
for
example,
one
of
our
teams
that
has
a
customer
portal,
they
have
production
in
one
tenant
and
then
all
their
feature
branch
development
happening
in
another
tenant.
A
While
other
teams
have
decided
well,
we
want
all
of
our
development
stuff
in
one
tenant
and
all
of
our
staging
and
prod
in
separate
tenants
as
well,
so
we
don't
impose
how
they
use
their
tenants
and
we're
certainly
open
to
letting
them
have
as
many
as
they
want.
Okay,
I
mentioned
already
that
the
node
pools
are
mostly
a
cost
accounting
function,
but
they
also
provide
additional
security
boundary
and
we're
heavily,
and
I
mean
heavily
using
flux
for
all
of
our
get
ops
and
doing
some
pretty
cool
stuff.
A
With
that,
I've
got
other
talks
that
I
can
do
that
are
in
that
space,
but
flux
makes
it
really
easy
to
let
our
tenants
be
able
to
define
the
things
that
they're
doing
okay.
So
when
thinking
about
the
built-in
mechanisms
and
the
the
support
for
for
multi-tenancy
with
kubernetes,
there's
quite
a
bit
there,
but
we'll
see
that
there's
quite
a
bit
lacking
as
well.
A
So
let's
talk
about
what's
there
first,
so
obviously,
kubernetes
has
the
the
concept
of
name
spaces
and
in
case
you're
not
familiar
with
it,
allows
you
to
carve
up
your
your
cluster
into
smaller
virtual
clusters.
Okay,
and
and
so
I
can
define
resources
in
one
name
space
and
then
somebody
that's
in
another
name
space
we
can
make
it
so
that
they
can't
see
those
resources
and
and
again
allows
you
to
isolate
things
and
the
rbac
allows
you
to
con
the
to
control.
Who
can
do
what,
within
the
cluster
in
case
you're,
not
familiar?
A
Okay
and
the
way
that
it
does.
That
is
using
roles
and
role
bindings
and
then
there's
also
roles.
Cluster
roles,
role,
bindings
cluster
role,
bindings,
which
we'll
we'll
talk
about
here
as
well.
So
a
role
simply
think
of
it
as
it's
the
permission
set
okay.
So
it's
the
policies
and
permissions
for
which
you're
you're
able
to
the
operations
for
which
you're
allowed
to
perform
and
on
the
next
side,
we'll
see
an
example,
one
actually
being
defined.
A
The
the
difference
between
a
role
and
a
cholesterol
is
basically
the
scope
for
which
that
thing
is
visible,
so
a
role
is
defined
within
a
namespace,
and
so
only
things
within
that
namespace
can
access
it.
While
a
cluster
role
can
be
defined
at
the
cluster
level
and
then
you
can
use
it
either
within
a
namespace
or
across
the
entire
cluster
and
the
reason
you
might
want
to
use
a
cluster
role
and
scope
it
to
within
a
namespace,
and
we
use
this
exact
use
case
is
a
platform
tenant.
A
We
want
to
make
sure
that
all
of
our
tenants
have
the
same
set
of
permissions
across
the
cluster.
So
we
have
a
cluster
role
that
defines
what
it
means
to
be
a
tenant
okay,
but
then
we
use
role
bindings
to
bind
that
cluster
role,
that
cluster
level
their
cluster
defined
role,
but
bind
them
to
specific
name
spaces.
A
Okay,
so
the
the
role
binding
will
grant
a
subject
the
rights
to
a
specific
name
space,
while
a
cluster
role
binding
will
grant
the
the
access
across
the
entire
cluster.
Okay
and-
and
I
fully
recognize
that
this-
if
this
is
the
first
time
that
you've
heard
this-
it
may
still
be
a
little
confusing,
but
the
first
time
you
you
play
with
it-
it'll
it'll
make
sense,
okay,
so
here's
an
example
of
one
on
the
left.
Here,
I'm
defining
a
cluster
role.
Again,
it's
defined
at
the
cluster
level.
A
I
can
then
use
it
in
any
name
space
or
grant
access
across
the
entire
cluster.
In
this
particular
role,
I'm
naming
podreader
and
it's
going
to
grant
get,
watch
and
list
permissions
to
pods.
Okay,
so
I
can't
create.
I
can't
delete,
I
can't
update,
but
I
can
get
watch
and
list
so
it's
basically
a
read-only
role
here.
Okay,
what
I've
got
here
on
the
right
is
then
a
roll
binding,
that's
going
to
say,
I'm
going
to
associate
this
cluster
role,
so
the
cluster
roll
pod
reader
in
any
that
the
subjects
of
any
user.
A
That's
in
this
group
oidc
platform
example
admins,
so
any
user.
That's
in
that
group
will
have
the
ability
to
get
watch
and
list
pods
within
the
example
app
name
space.
Okay.
So
if
I'm
in
another
namespace
the
default
namespace
or
a
cubesystem
or
you
know
whatever
else,
I
don't
have
permissions
to
do
that
at
least
based
on
these
two
manifest
here.
Okay
now
so
that
the
problem
is,
is
that
well
those
verbs
aren't
descriptive
enough?
Okay,
so
the
policies
limit,
the
actions
you
can
perform,
but
they
just
don't
get
granular
enough.
A
Okay,
get
list
and
watch
okay
that
works,
but
if
I
just
grant
the
access
to
create,
that's
that
can
be
pretty
broad.
You
know
I
can
create
services,
that's
cool,
but
should
I
be
able
to
create
node
port
services
or
load
balancer
services?
Okay,
so
again
going
back
to
our
goals
to
build
a
platform,
we
want
to
control
the
ingress,
and
so
we
don't
want
our
tenants
to
be
able
to
define
load
balancer
services
whenever
they
want.
So
how
do
we
do
that?
We
still
want
them
to
be
able
to
service
to
create.
A
You
know
cluster
ip
services,
but
not
load,
balancer
servers
and
the
our
back
mechanisms.
Just
don't
give
us
that.
Okay
and
the
this
last
point,
the
pod
security
policies
aren't
enough
and
there's
whole
other
discussions
that
go
along
there.
The
psps
are
also
going
away
too,
but
what
specifically
mean
by
this
is
you
know
a
pod
security
policy
may
be
in
place
to
say
a
pod
can't
mount
a
host
volume.
A
Okay,
so
I
don't
want
a
tenant
to
be
able
to
mount
the
entire
host
file
system
into
their
container
and
be
able
to
inspect
things,
but
that
happens
at
a
pod
level.
If
somebody's
defining
a
deployment
the
deployment
will
get
applied
successfully,
but
that
psp
doesn't
get
blocked
or
doesn't
block
that
pod
until
the
deployment
tries
or
technically
the
replica
set
tries
to
create
the
pot
itself.
So
then,
as
a
tenant.
Now
I'm
confused
of
like.
Why
is
my
pod,
not
starting
the
deployment
got
created
successfully?
A
A
Okay,
so
the
way
that
kubernetes
still
supports
this
and
and
and
provides
the
opportunities
to
fix
it
is,
is
through
what
are
called
admission
controllers.
Okay,
so
api
request
process
looks
something
like
this:
a
a
request
comes
into
the
api.
It
the
request
is
authenticated
or
authorized.
Are
you
allowed
to
make
the
change
that
you
want
to
do?
There
can
be
various
mutated
emission
controllers
that
can
look
at
the
object
and
add
annotations
or
labels
or
other
pods,
or
you
know,
side
car
containers.
What
basically
can
mutate
the
object?
Okay,
then
object.
A
A
A
Now,
so
these
emission
controllers,
that's
actually
how
kubernetes
does
its
own
validating
of
things.
The
namespace
exist
controller
is
one
that's
built
in
and
ensures
that
if
I
try
to
define
a
pod
in
a
namespace
that
doesn't
exist
well,
this
controller
says
you're
not
allowed
to
do
that
and
it
stops
the
request.
Okay
and
there's
lots
of
other
ones.
A
In
fact,
as
the
bottom
of
the
slide
here
says,
there's
17
enabled
by
default
on
on
new
clusters
and
that's
constantly
growing
and
changing
as
new
capabilities
and
new
features
are
added
to
kubernetes
itself.
Okay,
what's
cool,
though,
is
that
kubernetes
saw
you
know,
people
may
want
to
put
in
their
own
emission
plug-ins
or
you
know,
want
to
add
their
own
policies
on
what
should
be
allowed.
A
Okay,
so
kubernetes
includes
a
web
hook
mechanism
where
you
can
basically
register
a
web
hook
and
say:
hey
anytime,
a
request
gets
created,
notify
this
service
in
this
service.
We'll
then
look
at
the
request
and
decide
should
that
be
accepted
or
not,
and
we'll
return
a
response
accordingly
and
we'll
see
that
here
in
just
a
second,
these
services
are
required
to
use
https
and,
as
noted
here,
if
you're
running
your
own
emission
plug-in
be
careful.
Okay,
it's
part
of
the
control
plane.
A
So
if
your
your
emission
controller
starts
dorking
up
and
use
nine
requests
well,
you
could
basically
lock
yourself
out
of
the
cluster,
so
just
be
careful.
Okay
and
the
way
that
we
define
web
hooks
is
using
another
object
called
a
validating
web
hook,
configuration
which
an
example
is
right
here.
Okay,
so
this
is
saying
I'm
I
want
to
define
a
validating,
webhook
configuration
and
so
any
requests
that
are
going
to
the
the
v1
v
beta
1
api
groups.
A
I'm
going
to
notify
this
service
so
in
in
the
example
namespace
namespace,
I'm
going
to
send
a
request
to
example,
service
and
we'll
see
on
the
next
slide.
What
that
request
actually
looks
like,
in
this
case
we're
using
cert
manager
to
inject
the
ca
and
and
then
the
app
would
actually
be
using
a
certificate
from
cert
manager
just
to
have
that
hdps
connection.
A
A
The
the
the
app
will
receive
this
request
and
it's
an
admission
review
and
it
contains
a
lot
of
stuff
like
the
request
and
request
kind,
the
user
info,
the
actual
resource
and
object
if
it's
an
update,
you'll
get
the
old
object.
So
if
you
want
to
do
diffs,
you
can
do
that
and
then
based
on
whatever
policies
or
whether,
whatever
configuration
you
define,
you
return
whether
it's
allowed
or
it's
not
allowed.
A
In
this
case,
you
could
say
you
can't
apply
this
change
because
it's
a
friday
and
your
name
starts
with
an
a
so
you
can
come
up
with
whatever
kind
of
crazy
policies.
It
is
that
you
want,
and
the
submission
review
process
and
web
hooks
allows
you
to
kind
of
insert
yourself
into
that
validation
chain.
So
super
powerful.
Okay.
A
Okay,
so
opa
and
gatekeeper
opa
is
a
policy-based
control
for
cloud-native
environments
and
allows
us
to
define
basically
policies
using
a
language
called
rego,
which
I'll
admit
is
a
little
funky
and
a
little
hard
to
wrap
your
head
around.
But
that's,
okay
and
opa
is
used
in
many
different
environments
and
gatekeeper
is
basically
a
wrapper
for
opa
to
run
in
kubernetes
and
what
it
does
is.
It
runs
the
the
opa
engine,
but
then
also
runs
a
web
server
to
be
able
to
serve
as
that
emission
controller.
A
So
it
will
receive
the
request,
pull
out
the
pieces
and
then
pass
the
context
to
the
policy
engine
and
and
run
things
and
another
really
cool
thing
about
gatekeeper.
Is
it
allows
you
to
define
your
policies
through
kubernetes
objects
and
we'll
see
examples
of
that
here
in
just
a
minute,
so
I
can
define
my
policies.
A
Gatekeeper
will
ingest
that
put
it
into
the
opa
engine
and
then
the
next
request
could
be
validated
by
the
policy
that
you
just
defined.
Okay,
so
here's
an
example
of
an
of
an
opa
policy.
Again,
it's
it's
written
in
regula
and
the
way
to
read.
Rego
policies
is
basically
a
series
of
truth
statements.
Okay
and
if
a
statement
is
truthy,
then
it
moves
on
to
the
next
statement
and
you
keep
going
until
you
hit
a
false
statement.
A
A
So
we
look
at
the
the
input
that
request
and
again
this
is
going
back
to
that
object
that
we
receive
through
the
web
hook.
So
if
the
kind
is
a
pod,
what
we're
going
to
do
is
we're
going
to
look
at
the
the
object.
That's
part
of
that
request,
pull
out
all
the
the
containers
suspect
that
containers,
and
this
is
going
to
start
doing
an
iteration.
A
So
basically,
from
this
point
on
it's
going
to
do
execute
each
of
these
commands
once
for
each
container
and
again
it
it
takes
a
little
while
to
wrap
your
head
around.
So
image
is
both
a
an
array,
but
also
it's
a
single
instance.
It's
it's
iterating
through
it.
So
again
read
this
says:
we're
going
to
pull
all
the
images
from
from
the
containers
if
any
of
those
images
don't
start
with.
In
this
case,
myregistry.com
we're
going
to
set
a
message
in
any
sort
of
assignments.
A
So
this
is
an
ingress
allowed
domain
and
the
reason
that
we
want
this
policy
is
if
we
want
to
allow
our
tenants
to
be
able
to
define
ingress
objects,
we
want
to
make
sure
that
they
are
only
defining
ingress
objects
for
the
domains
for
which
they're
authorized
to
use.
I
don't
want
10
a
to
define
an
ingress
that
would
basically
intercept
the
traffic
of
tenant
b,
and
so
what
we
do
is
we
create
this
policy
and
then
we
create
the
ingress
allowed
domain
objects.
A
Okay,
and
then
this
is
how
we
actually
provide
this
parameter.
So
again,
the
constraint
template
is
basically
saying
here's
a
template
for
constraint,
here's
the
policy
for
it,
but
it's
not
until
we
actually
create
the
object
and
specify
the
namespace
and
the
parameters
for
it
that
it
actually
puts
the
policy
into
the
the
engine.
So
in
this
case,
what
this
would
be
saying
is
that,
for
the
example
app
namespace
they're
allowed
to
use
app.localhost
for
a
domain
name,
so
if
they
use
anything
beyond
that,
it's
going
to
get
denied
okay.
A
So
applying
this
at
scale
like
I
talked
about
earlier,
we
are
trying
to
do
this
for
all
of
our
our
tenants
and
our
platform,
and
as
of
right
now
we
have
about
well.
We
just
kicked
off
a
workshop
yesterday
that
had
about
35
participants
and
each
of
them
had
their
own
tenant
name
space
and
beyond
that
we
have
about
another
20
tenants,
so
we've
got
about
just
over
55
tenant
name
spaces
that
we're
leveraging
right
now.
A
So
the
way
that
we
do
this
is
kind
of
building
on
the
whole
tenant
idea,
and
this
is
college
town
as
well.
We
built
a
helm
chart
called
the
landlord
and
the
landlord's
in
charge
of
defining
all
the
tenants
and
making
sure
that
they're
they're
ready
to
go
and
provides
all
the
right
configuration
for
it,
and
this
is
an
example
of
what
it
looks
like.
So
it
has
a
tenants
array.
We
give
an
operator
a
group
that
goes
into
the
rbac
mechanisms,
but
here
are
the
domains
that
they're
authorized
to
use
node
affinities.
A
So
we
we
actually
mutate
on
to
each
of
the
the
pods
within
a
tenant
namespace
to
say
here's,
the
node
pool
that
you're
allowed
to
use
and
it
forces
them
into
that
node
pool
so
that
they
only
run
in
their
node.
So
we
do
that
now
time
to
do
a
demo
here
and
what
I'm
going
to
do
for
this
demo,
and
this
is
fully
available
to
anybody
else
that
wants
to
try.
This
out
is,
let's
see,
gatekeeper,
accidentally,
close
the
tab
and
so
I'll
pull
it
back
up
here.
A
We're
going
to
run
through
this
real
quick
and
what
we're
going
to
do
is
we're
going
to
run
some
setup
and
that's
going
to
install
all
the
gatekeeper
stuff,
all
the
components
there
we're
going
to
install
the
actual
constraints
and
then
we're
going
to
install
a
landlord
and
and
try
breaking
it
here.
Okay,
so
this
is
that
that
repo
just
cloned
locally
and
so
I'm
going
to
just
apply
the
setup.
A
This
is
going
to
install
gatekeeper
and
all
the
crds
and
also
have
traffic
just
for
some
as
a
ingress
controller.
Here
and
now.
What
I'm
going
to
do
is
I'm
actually
going
to
install
my
gatekeeper
constraints
and
I'm
just
going
to
use
the
local
chart
that
I've
got
here
and
what
I'll
show
what
that
looks
like
here
so
that
chart
I've
got
a
regular
policy
here.
A
That
is
doing
exactly
what
we're
just
talking
about
this
authorized
domain
policy,
so
we're
going
to
validate
the
ingresses
and
certificates
if
we've,
if
we're
using
them
and
validate
that
we're
authorized
to
use
that
now.
The
reason
we
actually
split
the
rego
out
into
its
own
file
to
write
tests
for,
and
I've
got
the
test
here
and-
and
so
I
can
actually
do
an
opa
test.
A
A
We
we've
got
a
template
here
that
is
going
to
create
a
authorized
domain
policy
object
which
got
created
that
crd
was
created
by
the
constraint
template
earlier,
and
it's
going
to
authorize
the
domains
that
are
specified
in
the
values,
yaml,
okay,
and
so
that
that's
how
that's
working
all
right.
So
at
this
point
I'm
going
to
go
into
hello
world
and-
and
here
I've
got
a
couple
different
applications
and
we're
just
gonna.
A
A
If
I
look
at
my
pods
I'll
see
ingress,
is
there
that's
great
now?
If
I
try
to
change
my
ingress
to
you,
know
bad
hello
world,
and
when
I
try
to
apply
this,
it's
a
pretty
nasty
message
here,
but
it
tells
me
that
the
mission
controller
denied
the
request
unauthorized
host
on
ingress
bad
world,
bad
hello,
world.localhost,
because
that
wasn't
one
of
the
authorized
domains
for
for
my
application
or
from
this
tenant
namespace.
A
So
again,
you
know
pretty
quick
demo
here,
but
it
allows
us
to
extend
the
capabilities
of
the
kubernetes
rbac
system
and
be
able
to
add
our
own,
our
own
policies,
our
own
capabilities
and
and
the
things
that
that
we
want
to
do
so
with
that
I'll.
Just
throw
this
slide
up
here,
I
won't
go
back
full
screen,
but
gatekeeper
has
its
own
library
for
a
lot
of
regular
scripts
and
a
lot
of
common
practice
things.
A
This
is
just
an
example
of
one
of
our
policies,
but
we've
got
policies
that
do
a
wide
variety
of
things.
We
implement
the
pod
security
standards
and
the
authorized
domains.
We
block
in
node
ports
and
service
load,
balancers
and
quite
a
few
other
things
as
well
too,
to
keep
things
safe
and
protected
for
our
tenants
too.
A
So,
and
with
that
thanks
again
and
if
you've
got
questions
I'll
I'll,
be
looking
through
chat
and
kind
of
catch
up
to
things
but
feel
free
to
reach
out
feel
free
to
look
at
the
the
demo
here
and
I
try
to
be
pretty
accessible
and
you
know
answer
questions
so
feel
free
to
shoot
me
an
email
or
hit
me
up
on
twitter
or
whatever,
whatever
method
you
want,
and
with
that
I
say.
Thank
you.
B
All
right,
thank
you.
So
much
michael,
I
do
have
a
question
before
I
let
you
go
sure.
So
how
do
we
move
these
in
like
a
pipeline,
so
that
I
don't
have
to
go?
I
mean
think
of
flux
right.
So
when
you
have
flux,
you
think,
like
you
merged
something
and
should
be
working
right.
I
don't
want
to
catch
that
when
it's
already
emerged.
I
want
to
catch
that
before
the
merge,
so
the
merge
fails.
So
what
are
your
thoughts
around
that.
A
Yeah
and
that's
a
good
good
question:
it's
it's
not
a
problem
that
we've
addressed
yet
so
what
we've
got
right
now
and
I
won't
show
it
off
right
now,
but
we've
got
a
we've,
got
a
custom
dashboard
that
we've
built.
In
fact,
we've
been
collaborating
with
the
flux
team
on
our
dashboard,
a
little
bit
that
that
presents
a
a
tenant
view
of
what's
going
on
in
their
name
space
that
we
we
highlight,
here's
the
customization
object
since
we're
using
to
has
it
applied
successfully?
A
Were
there
errors
with
it,
and
so,
if
they
do
define
an
ingress
that
fails?
Yes,
it
technically
flux
tried
to
apply
it,
but
on
their
dashboard
they
can
quickly
see
that
and
it
we.
We
highlight
that
error
and
kind
of
put
it
in
front
of
them.
So
we
don't
have
the
quite
yet
that
it
will
catch
it
earlier
in
the
pipeline,
but
we
at
least
have
tried
to
to
give
the
right
level
of
visibility
when
when
something
does
fail,.
A
A
How
do
you
make
sure
that
they
yeah
that
they're
authorized
to
even
use
the
namespace
they
just
created
and
then
what
sorts
of
protections
do
you
put
on
that
new
thing
that
so
you'd
have
to
do
quite
a
bit
more
thinking
about
what
sorts
of
events
or
things
do
you
do
once
that
namespace
is
created,
so
as
of
our
team
right
now,
we
don't
allow
the
tenants
to
create
their
name
space.
They
have
to
reach
out
to
us,
and
then
we
set
that
up
for
them.
A
Okay,
virtual
cluster
yeah,
and
so
that
that's
you
know
if,
if
you
really
wanted
to
give
people
that
level
of
ability
to
create
their
own
name
spaces
or
their
own
crds,
and
that
like
we,
don't
allow
our
tenants
to
do
that,
then
you
would
have
to.
If
you
want
to
do
it
right,
you'd
probably
want
to
be
looking
at
the
virtual
cluster
kind
of
stuff.
There.