►
From YouTube: How all devs use Istio Security without knowing Istio
Description
#IstioCon2021
Presented at IstioCon 2021 by Isan Rivkin.
At SimilarWeb we use Istio in all of our Kubernetes clusters and utilize Istio’s Authorization and Authentication policies for each service. As a small production engineering team, we wanted to let our developer’s full autonomy for writing new services with Helm without needing to know Istio internals.
To solve that problem we abstracted Istio completely inside a generic Helm chart for common use cases. For more complex cases create a MutatingWebhook in k8s that reads annotations from the deployments and configures the deployment to support all Istio related logic.
A
Hi
everyone
today
I
want
to
talk
to
you
about
how
to
simplify
the
use
of
istio
for
your
r
d
organization
or
in
other
words,
how
all
your
developers
can
use
the
istio
security
and
networking
features
without
really
knowing
istio.
So
a
few
words
about
me,
my
name
is
isan
rivkin.
I
work
at
similar
web
as
a
production
engineer.
This
means
I
love
infrastructure
and
platform.
Developing
I
like
kubernetes,
developing
in
rust,
in
go
and
generally
everything
about
distributed
systems.
A
You're
welcome
to
follow
me
on
github
and
maybe
collaborate
with
me
on
projects
or
follow
me
on
twitter
and
if
you
do
follow
me,
so
it
will
be
you
and
my
girlfriend.
So
thanks
for
that,
I
work
at
similar
web
we're
a
data
analytics
company.
We
provide
metrics
about
the
world,
we
run
with
microservices.
A
We
all
operate
on
aws
and
we
used
to
have
nomad
as
our
orchestrator
we're
moving
everything
and
almost
finishing
to
aws
kubernetes
cks.
We
use
an
active
active
setup,
which
means
we
have
cross-region
deployments
at
the
same
time
of
kubernetes
we
handle
about
100k
of
rps
and
we
process
about
10
petabyte
of
data
and
you're.
Welcome
to
look
up
on
our
similar
web
github
account
there's
bunch
of
open
source
projects
that
we
actually
maintain
and
develop
some
metrics,
and
also
why
we
chose
istio.
A
So
at
first
we
I
looked
up
istio
and
it's
other
two
biggest
com,
so-called
competitors
online,
to
see
some
popularity
to
understand
who
uses
what
and
actually
the
findings
are
interesting.
We
can
see
here
over
time.
The
graphs
of
the
blue
is
the
traffic
of
istio,
and
we
can
see
that
during
corona
or
during
carved.
There
was
a
big
increase
in
the
istio
usage
or
actually
visits
to
the
website,
and
here
we
can
see
another
increase.
A
I
guess
it's
related
to
the
fact
that
easterd
was
merged
and
the
new
releases
are
awesome
and
below
this
you
can
see
that
the
competitors
have
a
very
small
market
share
in
it.
Also,
I
picked
the
top
five
countries
that
actually
use
service
mesh
and
those
three
service
meshes,
and
by
order
you
can
see
that
in
china
still
is
actually
the
most
popular
than
united
states,
india,
brazil
and
poland
and
the
other
two
services.
They
have
a
very
small
market
share
and
this
is
a
big
reason
to
use
istio.
A
Also,
it's
not
enough,
so
we
needed
the
traffic
access
control
to
our
pods
in
terms
of
security.
We
needed
awesome
networking
capabilities
to
stop
reinventing
the
wheel
like
traffic
mirroring
and
we
wanted
distributed
tracing
which
we
already
had,
but
we
kind
of
invented
the
wheel
again
and
again
so
istio
is
all-in-one,
which
we
very
like
and
it's
easier
to
maintain
when
you
get
get
the
grasp
of
everything
now
the
problem,
so,
okay,
we
get
istio,
we
learned
it,
we
love
it.
A
What
now
before
istio,
we
used
to
work
with
nginx
ingress
controllers-
and
this
is
so
simple-
you
don't
need
to
know
much.
You
just
add
two
annotations
right,
maybe
even
less
to
your
ingress
and
there
you
go.
You
have
this
ingress
of
engine
x
and
you
get
a
salary
directs
and
you're
done.
You
don't
really
need
to
know
too
much
and
when
we
move
to
istio.
A
You
would
create
a
virtual
service
to
define
your
destination
rules
better,
maybe
you'll,
add
an
envoy
filter
for
some
https
redirects
or
some
clever
pattern
matching
you
would
have
to
connect
it
to
the
correct
gateway,
and
all
of
this
is
provisioned
with
the
istio
operator
and
it's
complex
there's
a
big
learning
curve.
We
wanted
to
prevent
all
those
copy
pasting
of
developers
taking
the
same
charts
everywhere
and
we
wanted
to
have
security
in
place
with
deny
by
default,
deny
all
and
you
need
the
correct
ingress
routing.
A
So
how
do
you
make
sure
that
internal
service
is
not
exposed
to
the
external
world?
And
how
do
we
get
the
visibility?
Maybe
my
sidecar
is
broken
and
maybe
my
application
is
broken
and
in
the
end
of
the
day
the
goal
is
to
always
enable
the
r
d
move
as
fast
as
possible
to
deploy
to
production
as
easy
as
it
can
get
so
quickly.
We
realized
implementing
in
integrating
istio
is
not
enough.
We
need
to
take
a
step
further
and
we
decided
to
go
with
the
idea
of
abstractions.
A
We
wanted
to
obstruct
the
business
needs
from
the
technical
needs.
So
if
a
service
in
terms
of
the
business
needs
a
high
sla,
but
technically
it
means
it's
need.
Many
replicas
inside
istio
those
things
doesn't
have
to
be
interconnected
and
we
can
obstruct
them.
So,
first,
what
we
did
I'll
show
you
a
little
bit
about
the
architecture
we
have
of
istio
in
our
organization.
A
Yeah
doesn't
matter
it's
a
black
box,
and
this
is
what
I
want
you
to
take
out
of
this.
To
use
the
obstructions
we
made.
You
don't
really
need
to
know
too
much,
which
is
a
good
thing.
While
you
have
the
best
practices,
so
we
leveraged
help
to
create
the
helm,
building
blocks
small
charts
that
can
be
used
by
another
charts
via
the
dependency
feature
and
kind
of
compose
a
bigger
stack.
So,
for
example,
we
created
security
chart
that
have
all
the
best
practices
in
place
and
obstructs
everything
for
you.
A
You
would
add
this
inside
your
chart
kind
of
like
a
one,
a
big
umbrella
deployment
and
in
your
values,
file
you
would
just
specify.
So
those
are
the
values
for
this
dependency
chart.
For
example,
this
one
allows
istio
english
gateway
access
for
get
methods
with
some
namespace
after
we
have
this,
it's
not
enough,
because
developers
don't
like
to
write
too
many
helm
charts
and
still
it
gets
complicated
to
configure
everything.
So
we
created
those
what
we
call
application
chart,
the
biggest
one
is
the
common
services
chart
where
everything
is
kind
of
possible.
A
So
it's
everything
in
terms
of
lists.
You
can
create
lists
of
deployments.
Lists
of
stateful
sets
lists
of
everything,
and
the
value
of
the
amount
of
this
chart
exposes
outside
everything
in
a
non-istio
language.
So
you
would
pass
an
array
of
deployments
and
you
would
have
an
api
object
and
a
ui
object.
A
Maybe
you
need
some
stateful
sets
and
the
terminology
would
be
like
just
security
configuration
ingress
service
configured
and
it's
all
encapsulated
under
one
umbrella,
as
I
said,
but
it
created
a
new
challenge
so
now
the
values
file
of
this
thing
is
very
big,
especially
if
you
have
more
than
one
deployment.
You
need
to
copy
all
those
configurations
again
and
again
and
again
for
each
of
the
deployments
you
have
so
we
we
created
this
idea
of
a
helm
generator
right.
So
we
wanted
to
prevent
the
copy
pasting
of
values
diamond.
A
We
want
people
to
use
precise
configuration
for
security
and
resources
and
networking,
and
we
want
people
with
zero
to
very
little
knowledge,
be
able
to
deploy
quickly.
So
we
created
a
questionnaire
and
basically
it's
a
ui
that
generates
the
values
for
you.
So
we
would
ask
you
on
a
web
page,
you
just
go
and
say:
okay,
so
I
want
maybe
a
production
cluster,
so
we
will
configure
three
replicas
or
more.
The
sla
is
high,
so
we
would
make
this
cross
region
deployment.
A
You
would
pick
a
cluster
a
region
and
most
of
the
stuff
would
be
configured
here.
The
next
step
is
kind
of
advanced
stuff.
Maybe
you
want
some
environment
variables
to
be
added.
Maybe
you
want
to
mount
with
the
config
map.
Your
containers,
some
configuration.
So
here
you
can
pass
a
yama
json,
whatever
container
arguments,
everything
you
need
here
in
case
the
defaults
are
not
good.
You
can
tweak
the
the
how
you
want
to
update
and
what
are
the
health
checks
in
terms
of
resources.
A
You
would
configure
everything
here,
the
site,
car
and
your
containers
as
well-
and
here
comes
the
istio
obstruction
part
and
the
ingress
obstruction
part
which
is
very
important
and
powerful,
because
you
don't
really
need
to
understand
things.
What
you
do
need
to
know
is
you
select?
If
you
want
your
service
to
be
externally
or
publicly
available
to
the
internet?
Maybe
only
internal,
maybe
both
you
select.
A
If
you
need
a
ssl
redirection,
and
maybe
you
have
some
custom
dns,
you
want
to
add
with
some
routes,
so
you
would
put
it
in
here
and
then
you
get
the
advanced
settings
of
a
virtual
service.
Maybe
you
want
to
have
different
destination
rules
based
on
your
service
or
some
custom
header
rule,
so
you
would
configure
it
in
here
and
then
there's
the
authorization
part
where
you
can
get
into
advanced
there
and
say
things
like
enable
all
the
name
space
services.
A
A
If
it's
cross
region,
so
you
would
have,
for
example,
one
for
each
region
already
configured,
and
this
is
how
you
start
up.
Just
to
summarize,
we
had
this
issue
of
istio
being
awesome
but
complicated,
so
we
created
building
blocks
for
security
and
traffic.
We
added
application
chart,
so
developers
can
move
much
easier
with
those
building
blocks
and
expose
the
hem
generator.
So
you
can
easily
create
a
precise
configuration
for
your
app
and
very
fast,
and
thank
you
very
much.
I
hope
you
enjoyed
it.
I
was.