►
Description
Real Security for Services on Kubernetes [I] - Eric Wang & Yun Zhang, Databricks
We all love the ease-of-use Kubernetes provides to engineers to deploy and manage their services. But before you can start running production code and dealing with customer data, you need to ensure that everyone's favorite features are in place: audit logs and access control. (And the crowd goes wild!)
At Databricks, we know that the best way to do security is to make sure the simplest way to do something is the secure one. In this talk, we introduce a system called Genie which uses time-boxed TLS certificates to authorize engineers to talk to certain namespaces within Kubernetes. Additionally, we will discuss how we extended this framework to allow for continuous deployment/continuous integration without weakening our security story!
About Eric Wang
Eric is a software engineer on the Cloud team at Databricks. Before that, he worked at Cisco Meraki, developing core features for the time-series database Little Table. At Databricks, Eric and his colleagues on the Cloud team work on infrastructure to enable engineers to rapidly deliver reliable, scalable, and secure services in a variety of cloud environments.
About Yun Zhang
Yun is a software engineer of the Cloud team at Databricks. He is experienced in building highly-available cloud infrastructure for data processing engines like Apache Spark and Amazon Redshift.
Join us for KubeCon + CloudNativeCon in Barcelona May 20 - 23, Shanghai June 24 - 26, and San Diego November 18 - 21! 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.
A
All
right,
so,
let's
get
started,
welcome
everyone,
so
it's
already
late
afternoon.
I
think
you
guys
are
all
tired.
So
before
we
get
started
just
a
quick
poll,
how
many
of
you
were
here
for
some
of
the
security
talk
yesterday
and
today,
cool
yeah,
all
right,
so
this
talk
gonna
be
a
slightly
different
from
the
previous
ones.
So,
instead
of
providing
you
another
open-source
tool,
we're
gonna
present
how
at
their
breaks,
we
connect
the
dot
together
and
present
a
holistic
security
solution
that
works
for
our
company
and
hopefully
also
work
for
your
company
as
well.
A
This
is
my
colleague,
Eric,
and
my
name
is
ring,
we're
both
software
engineer
at
that
Rick's.
We
work
for
a
cloud
platform
team,
so
our
team's
responsibility
is
to
provide
the
infrastructure
services
like
the
deployment,
monitoring
or
permission
credential
control
management
system.
So
our
philosophy
at
that
breaks
to
use
open
source
project
manage
our
infrastructure.
So
we
do
use
a
lot
of
those
tools
being
discussed
on
this
conference
like
kubernetes
from
easiest
basil
and
a
lot
of
those
hashing
hub
tools
like
terraform
and
vote.
A
So,
first,
what
is
data
breaks
because,
most
of
the
time
when
I
talk
to
people,
the
first
impression
they
have
is
oh
you're,
the
creator
of
Apache
spark?
Yes,
we
are,
but
because
this
is
not
spark
summit,
we
cannot
going
to
talk
anything
about
spark
today,
and
this
is
not
to
talk
about
how
we
use
communities
as
a
cluster
manager
for
spark.
Instead,
we're
gonna
talk
about
our
product,
which
is
this
oh.
A
By
the
way,
there
is
a
very
cool
talk
about
how
to
use
spark
how
to
use
kubernetes
as
the
cluster
manager
about
spark
on
last
spark
summit.
So
if
you
interested
go
check
this
out
anyway,
so
we
provide
this
unified
analytics
platform.
You
may
not
know
what
that
means.
So
it's
actually
a
product.
We
call
it
data
breaks
notebook.
So
what
the
state
book
dated
bricks
notebook
is
is
a
SAS
offering
that,
on
top
of
money,
multiple
cloud
like
it
was
and
Azure
and
is
provide
better
performance.
A
A
Lake
data
warehouse
and
you
want
use
data
breaks
product,
the
notebook
to
launch
a
spark
cluster
and
run
your
spark
workload
inside
your
customer
environment,
and
in
order
to
do
that,
you
actually
talk
to
you
one
of
our
notebook
service
across
the
internet
and
make
it
connect
to
your
customer
environment
and
manage
a
spark
workload.
All
right,
you
may
have
two
observations
here.
One
is
our
control
plan.
A
Services
are
deployed
to
a
data
breaks
environment
that
running
on
kubernetes
and
on
the
other
side,
as
a
engineer
or
as
a
service
principle
like
jenkins,
you
occasionally
need
to
access
those
control
plan
services.
That
means
you
also
need
have
access
indirectly
to
those
customer
data.
That's
why
the
security
of
the
kubernetes
cluster
is
super
important
and
critical
to
the
success
of
our
company
and
our
customer.
We
have
a
couple
of
security
concerns
from
different
people,
for
example
from
our
customer.
They
always
want
their
data
to
remain
private.
A
They
don't
want
anyone
else
to
access
the
data
and
a
subset
of
our
customer
also
have
the
security
compliance
they
need
to
conform
like
those
in
the
house
industry
or
in
the
federal
agent
industry.
They
have
the
HEPA
or
a
sock
you
or
FedRAMP
those
compliance
right.
So,
if
you
are
a
security
engineer
inside
data
breaks,
your
concern
is
security.
A
So,
first
of
all,
you
want
our
security
solution
to
have
this
nature
of
defense-in-depth.
We
don't
have
a
single
security
feature
that
just
depend
anything
else,
so
we
instead,
we
need
to
have
network
security
as
well
as
service
security
right
and
second
of
all,
they
want
all
the
production
excess
to
be
limited
and
audited.
So
nobody
else
nobody
are
supposed
to
access
production
in
the
environment.
It
not
supposed
to.
Finally,
as
an
engineer
as
an
application
engineer,
you
don't
maybe
you
don't
care
that
much
about
security,
what
you
really
care
is
about
productivity.
A
So
what
that
means
is
when
you
build
a
new
feature,
you
build
a
new
service
right.
You
want
a
security,
it
should
be
an
integrated
feature
that
already
been
built
for
your
system
or
your
service.
You
don't
want
to
spend
more
time
working
on
your
security,
stuff
and
overtime,
because
security
is
the
ongoing
effort.
You
may
want
to
onboard
engineer
with
new
security
features
of
a
service,
the
actually
one
that
should
be
easy
to
integrate,
with
as
an
easy
to
extend
right.
A
So
with
all
those
requirement
we
boil
down
to
this
three
fundamental
aspect
of
a
security
management
system.
Basically,
is
access,
control
and
security
management
and
audio
logging,
so
we're
not
trying
to
touch
each
of
those
today,
all
right,
so
we're
gonna.
First
talk
about
access
control
as
access
control.
They
come
in
two
fold,
as
we
mentioned
previously:
the
network
access
control
and
the
service
access
control.
So
here
we
just
assume
that
network
access
control
has
been
taken
care
already.
A
So
you
already
have
those
ingress,
egress
rule
set
up
correctly
for
your
services
and
we're
gonna
focus
on
the
service
access
control
team.
Here
today,
so
service
access
control,
you
early
come
in
early
means
who
have
access
to
what
kind
of
resources
right
so
who
the
subject
here
basically
can
either
be
a
human
or
be
Servius
principle.
A
So
if
you
are
a
dead
risk
engineer,
the
access
control
is
very
simple
to
you:
actually
we're
all
developers,
we
love
terminal.
So
as
a
developer,
you
can
just
go
to
your
terminal
and
run
this
single
command
called,
get
cube
access
where
the
environment
of
that
kubernetes.
You
want
to
run
so
this
sketch
cube
access
script
just
help.
You
do
everything
magically
and
you
don't
get
me
to
care
about
how
implement
on
the
line.
So
you
can
see
from
this
screen.
This
command
actually
leads
you
to
your
browser.
A
A
Yeah,
so
basically,
you
have
to
fill
those
additional
informations.
First,
you
need
to
specify
this
authentication
type,
which
means
whether
you
want
you
access
to
a
customer
notebook
just
impersonally
that
customer
do
some
real
time
debugging
or
you
want
to
maybe
sometimes
ssh
to
one
of
the
back-end
services
and
grab
some
log
or
something
real
ously
that
happens.
Sometimes
we
can
avoid
that.
You
can
also
specify
how
long
you
want
at
the
access
to
that
resource
in
production.
A
So
after
you
fill
up
all
those
informations,
you
can
submit
your
form
and
you
can
see
that
this
genie
service
it
actually
returned
a
credential
back
to
your
laptop
and
with
that
credential
it
can
run
the
your
favorite
cube
control
command
to
get
information
out
of
your
kubernetes
cluster.
All
right
and
you
can
see
all
those
processes
are
self-service.
You
don't
have
to
talk
to
anyone
because
we're
all
shiny
developers,
here's
some
more
explanation
of
what's
going
on
under
the
hood.
So
remember
this
is
your
laptop
and
you
talk
to
this
back-end
service
cup
genie.
A
So
Genie
is
our
centralized
access
control
service
inside
data
breaks
it's
integrated
with
Google.
So
remember.
The
first
thing
you
ask
is
to
do
a
Google
authentication,
so
that's
the
genie,
allsparks
OS
proxy,
that's
forward
to
you
to
google
and
finish
the
authentication
right.
So
up,
you're,
authenticated
genie
will
send
another
request
to
Google
get
all
your
Google
group
information
and
with
all
those
information,
Google
will
bundle
them
together
and
send
it
to
vote
the
hash
code
here
and
vote
well
upon.
A
Given
those
information,
it
will
issue
a
employee
certificate
and
go
send
it
back
all
the
way
to
your
laptop
and
then,
with
that
search
you
will
be
able
to
run
your
cube
control
command.
So
that's
how
it
works.
This
is
an
example
of
the
employee
certificate.
There
are
a
couple
of
things
you
may
noticed
is
signed
by
this,
an
employee
CA.
We
will
talk
about
it
later
and
is
time-limited.
A
So
this
is
how
our
CA
trust
chain
looks
like
we
have.
The
single
rule
see
I
was
just
careless
toward
somewhere,
I,
don't
even
know,
and
this
rule
C
is
used
to
sign
a
signer
CA,
which
is
then
used
to
sign
two
branches
of
two
branches
of
certificate.
One
is
this
employee,
CA
and
employee
certificated
we've
already
discussed
and
other
is
the
services
AAA
and
surveys
certificate.
So,
basically,
on
your
laptop
and
on
all
of
those
daybreak
services,
they
need
to
transpose
the
employee,
CA
and
the
central
service
CA.
A
So
this
to
party
Cong
can
communicate
with
each
other
using
SSL
connection
yeah,
so
kubernetes
provide
a
lot
of
authentication
strategies.
If
we
go
to
their
website,
you
will
see
a
bunch
like
client
TLS
certificate,
all
those
token-based
like
open,
DZ
or
webhook
token
and
others
password
based
in
all
sprach,
see.
A
In
fact,
I
think
the
different
company
used
different
kind
of
all
strategy,
but
we
found
what
what
worked
best
for
us
is
this
TOS
certificate
and
the
reason
primarily
been
that
steel,
as
is
very
widely
supported
on
so
because
of
this,
is
actually
very
easy
to
apply
this
here
as
authentication
to
all
the
services
we
run
inside
data
bridge
and
as
a
developer.
That
actually
means
you
have
this
unified
experience.
A
When
you
want
to
create
a
service
you
want
authenticated,
you
want
authentication
for
your
service,
you
can
use
TLS,
and
if
you
want
to
get
access
to
some
of
the
service,
you
can
also
use
TLS.
So
it's
a
very
unified
experience
for
them,
and
also
it
here,
as
is
very
easy
to
control
expiration,
because
this
has
this
validity
that
data
in
it
and
finally,
it's
also
very
kind
of
easy
to
integrate
with
kubernetes
our
back
and
our
discuss
is
next.
A
Does
anyone
find
any
problems
here,
because
I
think
one
of
the
weakness
of
teo
asus
doesn't
actually
allow
you
to
revoke
your
access,
so
this
might
be
one
of
the
problem.
That's
also
why
we
want
one
other
certificate
to
be
short-lived,
but
I
think
someone
are
in
this
comprehensive
work
on
the
revocation
of
certificate.
I
think
there
was
in
one
of
those
hoc
yesterday
so
ever
interested.
You
can
check
that
one
out
I
think
that's
also
some
of
the
feature
that
we're
looking
for
all
right.
So
we
already
have
this
employee
certificate.
A
It
signed
with
a
Google
Group
information,
and
all
we
need
to
do
is
somehow
binding
to
kubernetes
role
and
then
use
that
to
access
your
criminality
resources.
Our
binding
strategy
here
is
also
very
simple.
Consider
you
have
a
kubernetes
cluster
here
and
different
color.
We
present
different
namespaces.
We
actually
do
namespace
a
specific
role
binding,
so
we
heavily
rely
on
this
cluster
role
as
a
user
facing
row
by
default.
I
think
provided
since
kubernetes
1.8,
maybe
earlier
this
edit
role
is
basically
a
namespace
specific
admin
role.
A
So
it
gives
you
all
the
enemy
access
to
the
specific
namespace,
but
it
doesn't
give
you
any
permission
to
do
operations
against
like
role
or
role
bindings,
so
it
essentially
like
the
power
power
user
role
of
a
to
us.
I
am
right.
So
if
you're,
you
already
have
your
employee
search,
it
will
be
bind
to
this
cluster
edit
role
through
this
role,
binding
in
the
specific
namespace.
You
can
see
this
ro
binding.
It
has
association
with
this
cluster
will
edit,
and
it's
also
have
a
subject
with
the
group
name
in
it.
A
So
that
means,
if
I
mean
I'm
from
gross
team,
I,
can
only
access
a
namespace
assigned
to
my
group
and
your
Eric,
your
from
different
organizations.
You
only
have
access
to
the
namespace
where
you're
assigned
to
he
will
not
be
able
to
access
any
resource
in
my
namespace,
and
if
your
automated
system,
like
Jenkins
Jenkins,
can
also
be
associated
with
a
Google
group,
so
it
will
be
binded
in
the
same
way
to
the
cluster
role
and
then
will
only
be
able
to
do
deployment
to
that
specific
namespace.
A
One
of
the
advantage
of
the
setup
here
is
because
your
company's
organization
structure
may
constantly
change.
When
that
happens,
you
may
want
to
transfer
the
ownership
of
service
from
one
to
the
other,
and
with
this
setup
all
you
need
to
do
is
do
your
organization
change
on
the
Google
side
and
then
update
this
role
binding.
You
can
just
assign
a
namespace
to
a
different
group
and
that
that
group
gonna
be
the
new
owner.
A
We
also
find
this
permission.
Impersonation
use
case
to
be
very
useful,
so
consider
if
you
we
have
a
use
case
here.
Consider
if
your
Alice
from
Team
a
and
you
need
access
to
service
part
belongs
to
team
B.
You
may
want
to
do
some
ad
hoc
debugging,
because
you
know
root.
Cause
analysis
usually
comes
across
like
different
teams,
you
don't
care
which
that
service
belongs
to,
or
you
may
want
to
do
some
fleet
scan
or
some
in
his
task
over
your
back-end
services.
So
when
that
happened,
what
do
you
want?
A
A
So
you
still
run
this
get
cube
access
command
and
remember
that
ugly
web
page,
where
you
can
also
specify
an
additional
group
in
this
case
group
team,
B
and
genie
will
get
that
request
and
it
will
notify
the
owner
of
Group
B,
say
someone
trying
to
access
service
in
your
group,
and
you
can
prove
that
request
and
then
both
will
be
able
to
generate
a
new
certificate.
Was
that
additional
group
information
inside
the
cert
and
then
you
will
be
able
to
use
that
new
cert
to
access
resources
and
team
that
belongs
to
team
B?
A
So
this
we
used
to,
we
found
it
to
be
a
very
useful
use
case
in
our
organization
and
finally
comes
to
continuous
deployment,
because
we
use
Jenkins
pipeline
to
do
end-to-end
deployment
and
one
of
the
challenge
we
found
about
Jenkins's.
It
cannot
just
open
the
browser
and
do
this
two-factor
authentication
right,
so
it
runs
in
headless
mode.
So
what
what
Jenkins
really
do?
Is
it
use
a
long-lived
token
that
was
issued
by
vote
and
it
was
sent
the
request
itself
to
the
front
end
of
this
genie.
A
It
sends
requests
directly
to
the
vault,
a
hash,
a
cup.
Both
backhand
and
vote
will
recognize
that
token,
because
this
is
issued
by
vote
and
will
issue
a
and
concert'
the
same
way
as
a
tissue,
employee
search
with
all
the
required
information
and
then
Jenkins
will
be
able
to
run
the
same
control
command
to
finish
a
deployment
the
same
way
as
an
employee
access
hakuna
days
cluster.
A
B
Well
so,
as
you
mentioned,
I'll
be
discussing
the
tooling
we
built
to
address
secret
management,
so
at
data
bricks
we
use
an
open-source
tool
called
Hasek
or
vault
to
manage
our
secrets.
It
provides
an
easy-to-use
restful
interface
for
configuring
and
managing
secrets.
For
example,
you
can
install
a
signing
certificate
background
to
generate
TLS
key
pairs
and
if
any
of
you
had
had
experience
working
with
open
ssl,
you
know
how
annoying
it
could
be
to
sometimes
use
and
vault
handle
all
the
heavy
lifting
for
you,
whether
it
be
certificate
generation,
revocation
or
auditing.
B
It's
so
easy
to
use
that
it
encourages
us
to
use
shorter,
live
certs
and
that's
the
approach
when
generating
headless
Jenkins
tokens
for
kubernetes
access.
Additionally,
for
other
secrets,
it
can
generate
generic
secret.
It
can
store
generic
secret
material,
which
we
use
for
storing
our
long
live,
fixed
certs,
so
all
of
our
services
are
deployed
to
kubernetes
and
we
use
kubernetes
secrets
to
inject
that
information
into
our
running
services
as
a
quick
refresher.
Here's
what
a
typical
secret
config
looks
like
here.
B
We
have
a
secret
called
my
service
secret
Keys
stored
in
the
development
namespace,
which
stores
a
basic
ste
4,
encoded
secret
key
by
secret
config.
This
is
very
easy
to
read
upfront
and
very
concise,
but
in
reality
you
may
have
secrets
deployed
across
all
of
your
namespaces
and
all
of
your
clusters,
and
it's
been
really
hard
to
manage
the
context
in
which
each
secret
was
generated
and
the
format
each
file
is
configured.
B
Now,
let's
take
a
look
at
the
equivalent
secret
template
to
the
secret
defined
in
our
previous
slide
notice
that
the
definition
looks
very
similar.
We
define
a
secret
template
with
the
same
name
and
namespace
as
before.
However,
since
we're
integrating
with
high-sugar
vault
to
generate
our
secrets
for
us,
we
provide
context,
name
and
URL
for
the
vault
server,
we're
talking
to
the
data
where
your
request
from
vault
is
reachable
by
the
following
path,
and
the
resulting
payload
is
referenced
by
the
name
secret
keys
and
might
look
something
like
this
above
JSON
blog.
B
Finally,
the
actual
secret
format
is
a
key
value
pair
with
the
key
secret
config
and
the
value
from
The
Associated
payload
notice,
here
that
we've
described
everything
needed
to
define
this
secret
without
displaying
any
of
its
confidential
information.
So,
to
recap:
we
had
an
internal
tooling
to
declaratively,
define
the
properties
of
our
secret
and
when
applied,
it
automatically
pulls
all
relevant
data
from
Hashi
core
vault
and
turns
it
into
a
kubernetes
secret.
B
B
We
found
that
this
declarative
formatting
for
our
secrets,
was
really
useful
in
improving
the
velocity
of
our
developers
and
when,
when
managing
their
security
related
concerns,
and
if
you
guys
are
interested
in
a
tool
like
this
or
have
faced
similar
problems,
please
let
us
know.
After
last,
I'll
talk
a
little
bit
of
our
auditing
story.
B
So
Jeannie
was
designed
to
be
the
de-facto
authorization
service
for
all
employee
accesses
to
our
various
services
and
we
built
auditing
in
from
the
beginning,
junior
records
all
types
of
authorizations
and
grants,
including
failed
attempts
at
access.
Since
we
since
we're
also
like
the
creators
of
spark,
we
naturally
use
spark
in
our
internal
systems,
so
we
run
a
daily
spark
job
to
compile
its
information
and
export
it
via
email
to
our
security
team
and
here's
an
example
of
what
that
email
log
might
look
like.
B
B
Last
thing
to
note
is
since
Jeanne
only
required
tracks
requests
to
gain
access
to
our
kubernetes
clusters.
We
don't
actually
have
insight
into
what
that
user
does
in
the
in
in
the
kubernetes
ecosystem.
So
we
leverage
Kubb,
API
server
audit
logging
to
get
command-level
logging
for
the
users
in
our
system.
B
To
wrap
things
up,
I'd
like
to
highlight
a
couple
of
the
key
lessons
we
learned
along
the
way
when
building
these
security
systems.
First
security
shouldn't
be
attacks
on
developer
productivity.
The
easy
way
should
be
the
secure
way
and
any
gnarly
security
implementation.
Details
should
be
seamlessly
hidden
by
automation,
a.
B
B
For
security,
compliance
reasons,
remember
everything
until
you're
allowed
to
forget
other
buyer
contract,
or
someone
tells
you
you
can
do
so
and
lastly,
don't
reinvent
the
wheel.
All
of
us
up
this
conference
can
agree
open
source
software.
Is
your
friend
take
advantage
of
the
battle-tested
solutions
that
others
have
been
engineered
and
you'll
be
a
lot
happier
along
the
way
cool,
so
I
hope
you
guys
enjoyed
our
talk
and
if
any
of
these
topics
interest
you
or
you
enjoy
working
on
other
projects
related
to
kubernetes.
Please
come
talk
to
us
after
because
we're
also
hiring
Thanks.
B
Yeah,
so
actually
we're
actually
not
using
custom
resource
definitions
to
apply
that
object.
What
we
have
and
it's
actually
it's
actually
like
a
a
wrapper
around
koop
CTL
that
transforms
like
I,
guess:
data
data,
brick
specific
object,
definitions
into
like
and
under,
like
I'm
into
the
underlying,
like
kubernetes
objects.
So
we
don't
actually
use
custom
resource
definitions,
but
I
think
that's
like
the
way
we'd
want
to
write
it.
If
we
had
been
like
we
had
known
about
like
the
later
preachers
and
kubernetes.
B
Got
okay:
the
data
notebook
is
working
on
that
stuff
is
that
stuff
is
stored
in
like
some
distributed
file
system
of
the
user,
which
typically
has
s3.
So
it's
like
it's
all
stored
in
the
customers
account.
So
it
depends
on
like
their
whether
they
use
encrypted
s3,
buckets
or
whatnot,
and
then
there's
just
appeared
with
the
connection
so
that
we
can
access
them
from
our
control
plane.
A
B
I
think
that
some
parts
so
having
a
well
sorry,
oh,
how
do
you
like?
How
do
you,
how
do
you
I
guess,
work
with
developers
to
take
away
some
of
their
like
privileges,
but
also
like
increase
security
like
what
is
that,
like
balance
for
for
things
like
secure
a
secret
management
having
the
secret
template
is
a
clear
win
from
the
from
the
sort
of
observability
perspective,
because
everyone
can
clearly
audit
what
secrets
they're
actually
using
is
ed.
B
So
there's
like
the
obvious
benefit
that
if
they
adopt
system
rather
than
manually
configuring,
their
secrets,
you
know
it's
a
win-win-win
things
like
auditing
and
security.
I
think
there's
a
top-down
approach.
Also
of
we
have
to
be.
We
have
to
comply
with
like
some
set
of
security
rules
and
that
trumps
the
rest.
B
A
A
How
do
we
replace
a
certificate
yeah?
So,
as
we
mentioned
previously,
the
one
of
the
I
think
one
of
the
drawback
of
using
some
POS
certificate
is,
you
have
no
way
to
easily
revoke
your
existing
ones,
and
so,
if
you
have
your
have
certificate
compromised,
then
we
have
to
switch
all
the
certificate
on
the
server
side.
But
I
think
there
are
some
come
in
some
people
working
on
the
revocation
of
certificate
in
this
community,
and
if
that
is
a
new
feature,
we
can,
we
can
on
board
I
think
they'll
be
great.
A
B
B
So,
currently,
to
actually
apply
it
to
apply
secrets.
It
actually
leverages
the
employee
credentials
to
actually
have
to
actually
apply
them.
So
when
you
like
cou
a
rapped,
coop
CTL
apply
the
secret
template
event
like
you,
it
will
use
your
credentials
to
talk
to
a
vault,
to
populate
the
secret
and
then
apply
it
to
kubernetes
right
now.
So
a
lot
of
it
depends
on
the
sort
of
employee
pathway
and
getting
those
credentials
like
and
the
source
of
the
employee
credentials
source
maggini.
A
I
want
position
Jeannie
more
as
a
seam
layer
on
top
of
all
those
open
source
tools,
that's
specifically
for
developers
for
interact
like
communication,
so
like
services,
if
they're
running
inside
kubernetes,
they
don't
have
to
talk
to
Jeannie
to
get
those
a
service
account
or
anything.
So
if
yeah
I
think,
if
won't,
have
some
integration
with
kubernetes,
we'll
definitely
look
for
that
solution
as
well.