►
From YouTube: Securing Helm 3 Matthew Fisher, Microsoft
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
Securing Helm 3 Matthew Fisher, Microsoft
A
Microphone,
thank
you.
I
just
got
married
and
so
I
was
just
on
my
honeymoon,
so
welcome
everyone
to
my
thank
you
to
my
post,
honeymoon,
slideshow
I'm,
getting
we're
gonna
talk
today
about
securing
helm
3
and
what
that
means.
So,
a
little
bit
about
myself
here,
I'm
Matt,
Fisher,
I'm,
a
helm
core
maintainer
I'm
software
engineer
at
Microsoft,
I've
been
working
on
helm
now,
I
think
three
years.
Don't
quote
me
on
that
I
think
it's
more
like
to
actually
as
emotionally,
but
I'm
bacon,
gobbler
on
Twitter
github
slack
anywhere.
A
You
can
really
find
me
on
social
media.
So
the
agenda
for
this
talk.
I'm
gonna
talk
about
a
very,
very
quick,
brief
overview
of
helm
to
security
and
how
it
relates
this
talk,
then
I'm
gonna
talk
and
how
it
relates
to
helm.
Three
we're
gonna
talk
about
user
management
in
kubernetes,
just
a
very
basic
how
that
works,
and
then
role
based
access
control
and
a
little
bit
of
a
demo.
A
So
the
format
for
this
is
that
I'm,
just
gonna
fly
through
the
slides
as
quickly
as
possible
to
get
to
the
demo,
because
that's
really
gonna
be
the
good
meat
of
content.
I
think
here,
so
how
many
people
think
there
are
a
little
bit
of
a
kubernetes
security
expert
and
they
play
with
like
open
policy
agent.
They
work
with
network
policies,
pause
security
policies,
auditing.
All
these
things
that
are
up
on
here.
This
is
basically
when
you're
talking
about
securing
helm.
A
This
is
a
lot
of
the
things
that
you're
trying
to
talk
about
and
I
wish.
I
was
there
for
Paul's
talk
actually
on
hacking
helm,
but
these
are
a
lot
of
those
concepts
that
you
can
talk
about,
so
tiller
chart
provenance,
user
management,
cert
management
role,
based
access
control,
so
locky
gave
a
talk
at
last
helm
summit
and
I.
Absolutely
love
this
quote,
so
I
had
to
bring
it
up
again.
The
only
truly
secure
system
is
one
that
is
powered
off
cast
in
a
block
of
concrete
and
secured
in
a
lead-lined
room
with
armed
guards.
A
This
is
a
quote
by
Gene
Spafford,
and
it's
personally,
my
favorite
quote
so.
I
just
had
to
add
that
on
there
so
I'm
not
going
to
go
into
too
much
overview
or
any
overview
of
like
helm
to
security
with
tiller
and
everything
else.
Lockey
did
a
fantastic
talk,
an
overview
of
that
at
helm,
summit
north
america.
So
if
you
want
to
that
cue
a
coat
or
a
QR
code
over
there,
you
can
take
a
picture
of
it
and.
B
A
What
we're
going
to
talk
about
today
is
helm
three
security,
so
this
is
the
exact
same
slide
that
we
were
talking
about
before
notice
that
only
two
things
have
been
crossed
off
the
list
when
we're
talking
about
helm,
3,
tiller,
the
certification
management
and
role
based
access
control
management
in
terms
of
tillers
role
based
access
control.
However,
we
still
have
a
lot
to
cover
we're
only
gonna
cover
3
today,
because
there's
so
much
to
cover
on
everything
else,
but
we'll
get
there
and
then
hopefully
we
can
give
an
ab
depth
guide
with
those
things.
B
A
Talking
about
the
CLI
tool
that
so
in
helm,
3
is
just
a
CLI
tool
that
interacts
with
the
kubernetes
cluster
with
helm.
It
was
helm,
3
talkin,
over
G
RPC,
to
talk
to
tiller
3.00
beta
3
is
what
we're
using
in
this
demo.
That's
the
current
preview
release
that
was
released
last
week,
so
that's
what
we're
gonna
be
showing
off
and
then
again,
yeah
tiller
was
removed
as
a
component.
The
business
logic,
however,
is
now
all
part
of
this
helm
CLI.
A
They
share
the
exact
same
security
models
in
terms
of
how
you
access
a
resource,
how
you
deploy
a
resource
if
your
user
account
that
you
set
up
for
your
kubernetes
context
does
not
have
the
correct
permissions,
it
won't
be
able
to
deploy
in
certain
namespaces,
so
we'll
show
that
in
a
bit-
and
this
is
a
community
effort-
this
is
just
one
part
of
the
security
story.
There's
also
like
I
said
the
network
policies.
A
There's
a
pause,
security
policies
that
a
lot
of
people
are
talking
about,
doing,
linting
and
chart
testing
and
all
that
kind
of
fun
stuff.
So
this
is
a
community
effort.
There's
so
many
facets
of
this.
So
we're
only
gonna
leave
a
few
basic
scenarios.
We're
gonna
leave.
The
rest
is
homework
for
the
reader,
so
user
management
many
people
have
played
with
kubernetes
management
more
so
than
just
the
first
default
user.
That's
created
in
kubernetes.
A
There's
a
fair
few
of
you,
so
there
is
a
concept
in
kubernetes.
It's
called
service
accounts
and
user
accounts.
For
those
that
don't
know,
service
accounts
are
the
things
that
are
managed
through
the
API.
That's
basically
like
a
client
API.
You
use
that
when
you're
interacting
with
the
kubernetes
api
and
that's
kind
of
like
a
machine,
it's
used
to
represent
applications
communicating
with
the
IP
I
either
internally
or
externally.
A
User
accounts,
however,
which
is
the
part
that
you're
using
to
represent
a
human
interacting
with
a
kubernetes
api,
is
not
a
cluster
resource.
It's
not
something
you
do
a
KU,
CTL
create
user,
that's
something
that
I
have
to
do.
At
the
controller
side,
user
accounts
can
be
configured
through
the
API
server
and
they're
managed
externally,
depending
on
whatever
way,
you've
set
it
up
with
TLS
certificates,
bearer
tokens,
username
or
basic
username
passwords
and
open
ID
Connect
tokens
we're
in
this
demonstration.
A
We're
only
gonna
show
one
scenario
which
is
just
using
TLS
certificates,
so
how
that
process
works
when
you're,
creating
a
brand-new
user
in
the
kubernetes?
Is
you
first
generate
a
private
key
to
identify
that
as
the
user
you
generate,
then
a
certificate
sign
request
to
say
that
I
want
to
sign
as
or
I
want
to
authenticate
myself
as
this
user
against
this
cluster,
then
using
the
kubernetes
clusters
certificate
authority,
you
sign
that
certificate
sign
request,
and
that
gives
you
a
public
key.
A
That's
what
you
use
with
the
kubernetes
cluster
to
say
I
am
acting
as
behalf
of
him
or
her.
Then
you
create
now
you're
actually
getting
into
the
role
based
access
control
stuff.
So
you
create
role
bindings
for
the
new
user.
When
you're
the
first
user
created
on
kubernetes,
you
are
given
cluster
admin
access,
so
you
can
create
these
role
bindings
and
whatnot
for
the
first
user.
So
you
have
to
be
a
cluster
admin
and
then
you
just
add
these
public
private
keys
to
your
kubernetes
config
locally,
and
you
create
a
new
context
for
your
account.
A
So
that's
how
you
wanna
kate,
against
a
cluster
now
we're
actually
getting
into
the
role
based
access
control.
Part
of
it,
which
is
this,
is
how
you
are
given
these
or
granted
these
roles
to
be
able
to
deploy
into
a
namespace
given
read-only
access
to
certain
namespaces
or
not,
and
by
default,
when
you
create
a
brand
new
user
in
kubernetes,
you
were
given
no
authentication
whatsoever.
The
only
the
first
user
has
cluster
admin
access
and
then
it's
up
to
the
cluster
admin
to
make
those
roles
and
then
for
helm.
3.
A
How
this
relates
to
us
is
that,
when
we're
auditing
against
a
kubernetes
cluster,
does
anyone
work
with
the
cube
context
flag
before
ok
yeah,
a
few
of
you?
So
that's
that's
the
flag
that
you
can
use
to
switch
on
the
fly
and
your
kubernetes
config
to
say
that
I
want
to
authenticate
as
this
user
in
my
kubernetes
config
or
you
could
do
a
coop
CTL
config
set
context
so
that
you
can
change
your
default
user
when
you're
authenticating,
but
that's
how
it
works
in
there.
So
when
first
creating
a
new
user.
A
There
are
a
lot
of
information
out
there
on
the
internet
about
telling
you
to
create
the
following
cluster
role,
binding,
which
is
to
give
you
cluster
admin
access
and
play
around
with
that.
This
is
basically
equivalent
of
saying
that
all
your
base
are
belong
to
us
from
this
point
forward.
This
is
not
a
good
security
policy
going
forward,
so
let's
actually
dive
into
what
are
some
of
the
other
ones
that
could
be
usable
for
whatever
sonar
you
and
you
need.
A
A
That
gives
you
readwrite
access
to
most
of
the
resources
into
a
namespace,
including
roles
and
role
bindings,
but
it
does
not
allow
you
write
access
to
the
resource
quotas
in
that
namespace
or
to
the
namespace
itself.
So
if
you
give
someone
admin
access,
they
can't
actually
delete
that
namespace.
If
you
grant
them
edit
access
its
basic
readwrite
access
to
most
resources
in
a
namespace,
it's
a
little
bit
more
restricted
than
admin.
So
you
can't
do
other
things,
I
think
it's!
You
can't
see
the
roles
and
role
bindings
is
the
other
part.
A
So
there's
that
and
then
there's
view
access
and
this
one's
a
little
bit
tricky
we'll
get
into
it
a
second,
but
it
gives
you
read-only
access
to
most
resources
in
a
namespace,
but
and
it
does
not
give
you
access
to
roles,
role,
bindings
or
secrets.
So
you'll
know
that
in
something
in
home
3
we
use
storage
or
secrets
as
storage,
so
we'll
have
to
work
with
that
in
a
moment,
but
we'll
cover
two
basic
use.
Cases
in
this
demonstration
we'll
give
read-only
access,
which
is
helm,
list
helm
status
in
film
history.
A
So
you
can
take
a
look
at
what
the
status
of
a
deployment
in
another
name.
Space
is
like
the
other
name
or
the
other
basic
use
cases
readwrite
access.
So
if
you
want
to
give
a
user
be
able
to
do
a
helm,
install
an
upgrade
a
rollback,
a
delete
or
an
uninstall,
quick
sidenote
about
the
view,
cluster
role,
as
I
mentioned
before
it's.
B
A
Says
it
allows
me
to
only
access
to
see
most
objects
in
a
namespace.
It
does
not
allow
viewing
roles
or
role
bindings
and
it
does
not
allow
viewing
secrets,
since
those
are
escalating
not
actually
quite
sure
what
it
means
by
its
escalating,
but
I'll
figure
that
out
sometimes
that's
homework
left
for
the
reader
helm,
actually
stores
the
released
metadata
as
secrets.
A
So
in
order
for
us
to
gain
read-only
access
to
say,
helm
lists,
we
need
to
see
that
release
metadata,
so
we'll
need
to
create
a
special
cluster
role,
that's
similar
to
the
view,
only
role
but
for
secrets.
So
there's
this
one,
it's
actually
in
the
kubernetes
documentation.
If
you
want
to
create
a
secret
Reader
cluster
role
and
what
this
does
is
it
gives
you
API
groups,
nothing
there.
It
just
gives
you
access
to
the
resources
of
Secrets.
It
lets
you
to
get
watch
and
lists,
or
the
API
endpoints
for
that.
A
So
if
you
do,
coop
CTL
create
dash
F
with
that
cluster
role,
secret,
Reader,
you're
all
good
to
go,
and
then
a
last
thing.
I
also
want
to
add
on
here
about
the
Edit
cluster
role.
If
your
charts,
that
you're,
depending
on
they
create
roles
or
role
bindings
in
the
actual
chart,
the
Edit
cluster
role
does
not
give
you
access
to
create
those
roles
and
role
bindings.
A
So
now,
let's
actually
look
at
some
practical
examples
here
before
we
go
into
the
demo.
So,
if
you're,
giving
a
read-only
access
for
a
user
against
a
particular
namespace,
you're
gonna
need
in
helm
these
two
different
roles,
which
is
a
view
cluster
role
and
then
a
secret
Reader
cluster
role
with
that
API
that
we
created
before
read-only
access
for
a
user
clustered
wide
I'll
quickly
go
through
these
and
then
I'll
show
them
in
the
actual
demo.
But
we've
got
the
read-only
access
for
a
user
cluster
wide.
A
This
is
important
for
when
you
want
to
do
a
cross
cluster
to
see
all
the
namespaces
or
all
the
deployments
that
are
available
on
every
namespace.
You
need
to
have
secret
reader
access
and
view,
so
you
can
see
those
resources
that
are
being
deployed
and
then
for
service
accounts,
same
thing,
you're
just
doing
it
with
service
accounts.
Service
accounts
service
accounts,
cluster
wide,
which
is
kind
of
highly
discouraged,
because
what
that
means
is
essentially,
you
are
giving
any
single
service
account
that
is
created
in
the
kubernetes
cluster,
complete
view
access
to
absolutely
everything
else.
A
A
A
service
account
readwrite
access
for
all
service
accounts
in
a
namespace,
so
we're
just
giving
all
service
accounts
that
and
then
this
is
like
the
cluster
admin
access
again,
which
is
greeting
a
cluster
role
binding
for
all
service
accounts
in
your
cluster
you're,
able
to
edit
anything
in
there,
except
for
namespaces,
and
the
quotas
again
super
highly
discouraged
because
you
can
delete
any
of
the
resource
one
more
time.
All
your
base
are
belong
to
us.
So
let's
go
to
the
demo
all
right,
so
in
can
everyone
in
the
back
see
the
screen.
A
Is
that
big
enough
or
do
I
need
to
make
it
a
little
bit
bigger
a
little
bit
bigger,
oh
you're,
saying
is
okay,
okay,
so
for
this
demo,
I'm
just
gonna
show
a
mini
cube
status,
I'm
just
running
with
mini
cube
here,
because
it's
just
really
easy
to
get
access
to
the
certificate
authority.
So
then
I
can
actually
create
new
users
rather
than
having
to
go
through
the
cluster
admin
as
a
seiche
into
the
cluster
figure
out.
A
What
the
certificate
authority
is
so
just
for
demonstration
purposes
is
gonna,
be
super
simple,
but
let
me
show
you
what
we're
gonna
do
here.
So
we
got
a
couple
of
scripts
here.
First,
one
we're
gonna
create
a
user
called
Sam.
Sam
is
just
going
to
be
giving
their
own
namespace
OOP
CTL,
create
namespace
Sam
and
then,
as
per
the
kubernetes
documentation
for
creating
a
new
user
with
TLS
certificates.
We're
gonna
generate
a
new
private
key
for
Sam.
A
Then
we're
gonna
generate
a
certificate
signed
request,
we're
gonna,
give
them
the
username
Sam
and
the
organization
is
helm
summit
and
then
using
the
CA
certificate
or
this
certificate
authority
that
is
created
with
the
mini
cube
cluster.
We're
going
to
assign
that
certificate,
sign,
request
and
say:
yes,
it's
okay
to
use!
A
You
I
authorize
you
as
a
user
to
go
and
authenticate
against
this
kubernetes
cluster
and
then
we're
gonna
give
them
five
hundred
days
to
work
with
it
and
then,
at
the
end
of
the
script,
we're
just
setting
our
kubernetes
or
coop
CTL
configuration
we're
gonna,
set
a
new
context
and
the
credentials
for
that
user
for
the
kubernetes
or
a
mini
queue.
Cluster
and
then
we're
gonna
give
them
the
name
space.
Actually,
that's
a
typo,
we're
gonna,
do
it
not
in
the
shared
namespace,
but
in
the
Sam
namespace
there.
A
You
go
earlier
demo
problems,
so
we're
just
gonna
run
that
script
and
that's
gonna,
do
absolutely
everything-
and
we
mentioned
here.
So
we
created
a
new
Sam
certificate,
the
private
key,
the
certificate
sign
request
and
the
public
key.
Here
we
added
it
to
our
community
config,
so
everything's
there
now
we're
gonna.
Do
the
exact
same
thing:
we're
gonna,
create
a
user
for
me
called
great
bacon
gobbler.
So
let's
go
into
the
actual
cluster,
and
what
does
that
mean?
A
So
if
you
go
name
spaces
now
we
have
a
bacon
gobbler
namespace
and
we
have
a
SAM
namespace.
We're
gonna
show
this
off
is
where
the
bacon
gobbler
namespace
is
what
I'm
gonna
be
giving
myself
read/write
access
and
then
Sam
is
gonna,
have
rewrite
access
to
the
Sam
namespace
and
what
I'm
gonna
demonstrate
is
myself
bacon.
Gobbler
is
gonna,
be
able
to
also
have
view
access
into
Sam's
main
space.
A
List
we
don't
see
anything
at
this
current
time.
If
we
installed
something,
we
would
not
be
able
to
install
anything.
So
we
try
install,
let's
do
WordPress
stable
WordPress
and
it
will
give
it
a
fancy
name.
This
will
not
work
because
we
don't
have
readwrite
access
into
that
namespace,
so
we
need
to
actually
go
and
create
those
roles
for
that
user.
So
we're
gonna
use
another
script
to
actually
go
and
do
that
here.
A
So
the
Edit
for
dot
sh
script
here,
just
as
we
showed
before
it
just
creates
a
role
binding
in
that
namespace
for
a
particular
user
and
then
in
a
particular
namespace.
So
we're
gonna
give
that
it
was
edit
for
bacon
gobbler
and
we're
gonna,
give
bacon
gobbler
edit
access
into
the
bacon,
gobbler
namespace.
So
now
that
role
base
or
that
role
has
been
created
or
that
roll
binding
has
been
created
for
us,
and
now
we
can
install
charts
into
that
namespace
and
there
we
go.
We've
got
namespace
in
there.
A
A
List,
let's
try
and
do
the
namespace
bacon
gobbler.
We
can't
see
anything
because
we
don't
have
view
access
over
to
him
or
her,
so
we're
gonna
do
a
view
for
them.
We're
gonna
do
a
view
for
that.
Script
is
just
a
role
binding
and
again
notice
that
this
has
the
secret
reader
cluster
role
binding
or
the
cluster
role
that
we
created
before
in
the
I
didn't
show
it
in
the
first
script.
It
uses
the
cluster
role
secret
reader
and
it
creates
that
instance,
and
that
is
in
the
cluster
role
secret
reader
gemmell.
A
So
that's
creating
that
cluster
role,
secret
Reader,
API
groups,
resources
secrets,
get
watching
the
list,
so
we
can
actually
just
view
the
secrets
can't
edit
them.
So
now,
we'll
do
a
view
for
Sam
and
we'll
give
Sam
view
access
into
the
bacon
gobbler
namespace,
that's
ones
created.
So
now
what
we
can
do
in
helm
is
cube
context
time
where
we
have
we're
good
Sam,
and
then
we
can
do
a
list
we'll
see,
there's
nothing
because
we're
not
looking
in
the
we're
looking
in
our
own
namespace
there's
nothing
there.
A
But
if
we
look
in
namespace
bacon
you're
all
there,
we
start
seeing
other
things
now.
What
if
we
want
to
actually
see
everything
from
a
holistic
point
of
view,
so
we
want
to
see
absolutely
everything
in
the
cluster
at
any
point.
That
is
a
completely
different
role
than
what
was
shown
here.
So
if
I
try
and
do
that
right
now,
all
namespaces
so
Sam
does
have
access.
A
role
has
been
created
inside
of
names,
bacon
gobbler.
That
Sam
can
see
all
those
resources
in
there,
but
can't.
B
A
Trying
to
see
everything
at
a
holistic
point
of
view,
we
can't
see
anything.
This
is
a
separate
kubernetes
endpoint
in
terms
of
how
the
API
works.
When
you
use
the
all
namespaces
endpoint,
you
are
seeing
things
from
the
cluster
point
of
view
from
a
holistic
point
of
view.
So
it's
not
a
fine-grained
role.
You
have
to
create
a
cluster
role
to
be
able
to
view
those
resources.
So
we
have
another
helper
script
here.
A
It's
called
cluster
role,
view
for
and
that
script
is
a
cluster
role
binding
for
viewing
thing
or
viewing
resources
in
any
namespaces
as
a
particular
user
and
the
secret
reader
again
because
of
Secrets
not
being
viewable
but
with
the
view
closer
role.
So
we
will
do
that
and
we
will
give
Sam
access
so
now
those
two
role
bindings
we
created
for
Sam
and
if
we
do
a
helm,
cube
context,
Sam
lists
all
namespaces
and
now
we're
able
to
see
inside
of
every
single
namespace
anything
that's
been
deployed
inside
of
there.
A
So
that
is
the
majority
of
what
I
got
here
and
then
again.
If
I
just
want
to
be
able
to
do
one
last
thing,
which
is
give
bacon
gobbler
edit
access
inside
the
Sam
namespace
I
can
do
edit
for
bacon
gobbler
in
the
Sam
namespace
and
then
we'll
do
a
helm,
cube
context,
bacon,
gobbler,
install
stable
word,
press
generate
name
and
we
will
deploy
it
into
a
different
namespace
will
deploy
it
into
the
Sam.
A
Namespace
I
should
have
actually
deleted
this
role
first,
just
to
show
that
it
would
not
go
the
first
time,
but
you'll
see
here
that
big
and
gobbler
now
has
write
access
into
the
Sam
name,
spacing
and
deploy
those
in
there
and
can
actually
see
them
too.
So
helm,
cube
context,
gobbler,
lists
namespace
and
can't
see
them
from
the
all
namespaces
name.
Spaces.
Typing
I
can't
see
it
at
all
from
the
all
name
Caesars,
because
that
cluster
role
is
not
available.
A
A
That's
all
I
have
for
time
here.
So
left
is
homework
for
the
reader.
For
anyone
who
is
interested
in
this
there
is
on
helm,
3.
There's
the
v3
LSH
slash
docks.
The
goal
of
this
talk
was
actually
to
add
this
as
documentation
to
so
then
everyone
can
benefit
from
this
talk
and
everyone
can
benefit
from
role
based
access
control
in
home,
3.
So
I'm
gonna
take
this
as
a
homework
for
myself
as
updating
the
documentation
on
this.
A
The
resources
where
I
learned
all
about
role
based
access,
control
and
kubernetes,
was
on
the
kubernetes
documentation
and
then
I
accidentally
I
forgot
to
not
leave
a
link
on
here,
but
there
was
a
fantastic
blog
post
by
the
bitNami
folks
on
how
you
actually
create
the
roles
or
not
the
roles,
the
users
and
how
that
relates
to
doing
all
that
with
the
TLS
certificates
and
doing
that,
although
I
thought
mini
cube.
So
that's
all
I
have
for
the
talk.
A
B
A
So
the
question
was:
do
I
envision
this
as
being
something
like
a
helm
in
it
for
helm,
3
I'm,
imagining
as
in
you're
talking
about
how
it's
a
little
bit
of
a
tough
question,
because
all
of
this
is
very
opinionated
on
what
is
exactly
you're.
A
Trying
to
deploy
like
you
could
you
could
have
an
opinion
on
whether
you
want
to
have
a
cluster
role
for
viewing
editing
or
anything
else
completely
dependent
on
what
you
are
doing
so
I
think
it
might
be
better
served
as
like
a
plug-in
to
be
assistive
and
saying,
like
here,
are
some
user
profiles
where
you're,
really
interested
in
say
I
want
to
give
edit
access
to
a
particular
namespace,
or
things
like
that.
I
could
see
an
assistive
tool
I'm
not
entirely
certain.
A
B
A
A
So
if
you
did
a
helm,
install
the
kubernetes
api
would
just
encrypt
it
on
the
SED
back-end
and
then,
if
you
were
to
have
your
helm,
client
similar,
like
coop
CTL,
be
able
to
decrypt
those
secrets
as
it's
being
fetched.
That
would
be
a
really
fantastic
security
story.
So
it's
kind
of
like
we're
waiting
for
things
on
the
secrets
backend
to
move
forward.
You
can
change
the
Seekers
back-end
to
something
else,
but
I
guess
we'll
just
see
from
here.
What's
going
on
with
the
Seekers
back-end.
B
A
Yeah,
so
the
question
is
a
good
question.
The
question
was,
if
you
have
a
chart
that
has
templates
that
install
resources
in
a
separate
namespace
than
what
you
currently
have
access
to,
will
that
like
gain
access
outside
of
those
roles,
the
answer
is
no
because
when
you're
authenticating
against
the
kubernetes
cluster
and
those
resources
are
being
installed,
they're
being
installed
on
that
kubernetes
users
roles
and
that's
basically.
So
when
I
did.
A
The
first
demonstration
I
showed
that
you
were
trying
to
helm,
install
stable
WordPress
into
a
namespace
which
that
user
did
not
have
access
to,
and
if
you
were
deploying
resources
that
had
a
namespace
hard-coded
in
there
and
that
user
did
not
have
read
or
write
access
to
that
namespace
than
those
resources.
It
would
just
Bork
out
and
say
that
I
don't
have
access
to
install
resource
foo
in
namespace
bar
basically
is
what
would
happen.
A
Yeah,
so
that's
a
good
question,
so
the
question
was
prior
to
installing
the
resources
in
the
cluster
does
the
does
helm
actually
verify
that
those
resources
can
be
installed
and
such
that
you
don't
get
in
like
a
halfway
house
where
some
of
the
templates
are
installed
and
some
are
not
it's.
My
understanding
well
I
actually
have
to
take
a
look
and
leave
that
as
homework
to
the
reader
I
guess,
but
the
question
would
be
I'm
fairly
certain.
B
A
Yeah,
so
the
question
is:
if
you
want
to
grant
roles
such
that
the
user
can
create
namespaces,
but
not
create
or
create
resources
and
other
namespaces
and
I,
don't
think
there's
that
kind
of
fine-grained
control
inside
of
kubernetes,
where
you
can
actually
I,
could
be
totally
wrong
there.
The
custom
or
the
ones
that
I
used
in
this
demonstration
are
the
ones
that
are
off-the-shelf,
which
give
actions
and
verbs
to
certain
names
and
namespaces
or
resources,
and
so
like
that
secret
reader
role
that
I
created
it
was
secrets,
get
which
and
get
watch
and
list
I.
A
B
A
So,
actually
now
in
helm,
three,
it
doesn't
create
that
namespace
by
default.
So
you
actually
have
to
create
that
namespace
ahead
of
time
before
you
deploy
that
helm
chart.
So
you
it's
assumed
that
you
have
to
have
cluster
admin
access
when
you're,
first
creating
that
namespace
and
then
the
users
have
the
fine-grained
control
or
not
on
whether
to
install
name
or
resources
in
that
namespace.
A
If
you
wanted
to
blow
a
chart
that
has
a
namespace
in
there,
then
you
need
to
give
them
role
access
to
create
a
namespace
as
well
as
those
roles,
but
that
would
be
part
of
the
validation
that
we
were
talking
about.
The
only
case
would
be
with
custom
resource
definitions
that
could
that
they
could
be
installed
prior
to
validation.
Otherwise,
all
the
other
resources
would
go
through
validation
and
say
you
don't
have
write
access
to
create
those
names
or
those
resources,
and
so
you
wouldn't
get
into
that
scenario
where
the
namespace
is
created.