►
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
A
very
good
morning,
good
afternoon
and
good
evening,
to
all
of
you
from
wherever
you
are
joining
welcome
to
this
webinar,
where
we
would
be
talking
about
securing
requests
with
key
cloak
and
istio.
So
we
would
be
diving
into
the
world
of
kubernetes
security
before
we
do
that.
A
A
quick
round
of
introductions-
I
am
Atul
Priya
Sharma
I
am
a
cncf
Ambassador
and
I
also
work
as
a
senior
developer
Advocate
at
info
Cloud,
where
I
deal
in
Cloud
native
Technologies
like
kubernetes
istio
and
have
been
exploring
observability
of
late
as
well
outside
of
work.
I
am
a
foodie
and
love
doing
road
trips.
B
B
Afternoon
I
am
working
as
a
site
laboratory
engineer
at
in
fact,
actually
I
started
using
it
on
cognitively,
West,
black
and
now
I
help
our
clients
build
robots
and
reliable
infrastructure.
You
think
I
need
to
technology
quickly.
A
Getting
into
the
agenda
of
what
we
plan
to
cover
in
this
webinar,
so
we
would
start
by
giving
an
overview
of
the
various
Security
Options
in
kubernetes,
we'll
then
dive
into
istio
and
we'll
see
how
authentication
and
authorization
works
with
it.
We'll
also
look
at
request
level,
authentication
and
authorization,
a
quick
look
at
JWT
tokens
and
finally
into
the
demo.
A
So,
to
start
with,
we
know
that
you
know:
kubernetes
has
become
the
operating
system
of
the
cloud
and
with
the
complexities
that
our
application
and
infrastructure
have
it's
very
important
to
have
a
robust
security
measure
in
place.
So
we'll
start
by
discussing
some
of
the
existing
security
features
that
kubernetes
has
so
airbag
basically
helps
us
control
who
can
access
and
perform
actions
without
your
you
know,
accessing
your
kubernetes
clusters,
so
you
can
think
of
them
as
bouncers
at
an
exclusive
Club.
So
it
allows
you
to
Define
fine
fine-grained
permissions
for
user
groups
and
accounts.
A
This
is
one
of
the
very
popular
ways
for
securing
access
to
your
clusters.
Next,
one
we
would
like
to
discuss
about
is
POD
admission
policy.
You
can
think
of
it
as
your
Vigilant
Security
Guard,
outside
your
building,
and
so
when
a
part
is
created,
the
policy
kicks
in
and
validates
the
configuration
and
ensures
that
only
authorized
folks
are
allowed
access
to
your
pods.
And
lastly,
and
most
important
is
the
network
policies,
and
if
you
are
dealing
with
networks
within
kubernetes,
you
would
have
come
across
Network
policies.
A
These
are
basically
like
virtual
fences
that
Safeguard
your
network,
so
we
can
create
logical
boundaries
that
allow
only
authorized
communication.
These
three
are
relatively
the
basic
options,
yet
important
options
that
kubernetes
provides
out
of
the
box.
However,
there
are
a
few
shortcomings
of
these
particular
native
options,
so
especially,
you
know
looking
at
it
from
a
point
of
view
of
network
policies,
so
the
first
one
is
that
Network
policies
focuses
only
on
controlling
the
traffic
and
it
does
not
provide
a
mechanism
to
force
your
internal
traffic
going
through
a
common
Gateway.
A
Apart
from
this,
it
also
doesn't
provide
any
feature
to
tackle
with
TLS
related
configuration.
So
if
you
are
going
to
handle
anything
related
to
SSL
certificate
management
and
encryption,
these
options
don't
quite
provide
these
features.
Out
of
the
box,
so
that's
where
you
know
we
need
some
tool
that
can
help
us
deal
with
all
of
this,
and
that
is
where
service
mesh
comes
in
a
service
mesh
such
as
istio
or
Linker
D.
It
provides
a
dedicated
infrastructure
layer
specifically
designed
to
handle
secure
communication.
A
So
in
a
typical
microservices
architecture,
you
know
that
Services
communicate
with
each
other
extensively
and
it's
very
important
to
ensure
that
all
the
communication
that
is
happening
is
authenticated
and
secure.
So,
apart
from
you
know,
the
regular
features
like
traffic
shaping
you
know:
load
management
as
well
as
traffic
routing
most
of
the
service
meshes
also
come
with
security
features.
Some
of
them
include
native
support
for
mtls
and
JWT
Authentication,
which
is
basically
you
know.
A
You
can
offload
the
authentication
from
your
application
from
your
cluster
to
istio
or
Linker
D,
whatever
service
mesh
that
you're
using.
It
also
gives
you
an
observability
layer,
so
you
can
control
and
have
a
visibility
over
the
network
traffic.
So
in
a
way
it
also
helps
you
secure
and
monitor
traffic
within
your
network.
And
lastly,
it
also
gives
you
some
fine
grain
access
control
over
your
network
and
the
requests
that
are
coming
in.
So
this
was
pretty
much
about
what
service
mesh
can
do
when
it
comes
to
security.
B
So,
let's
see
the
skills,
authentication
and
authorization,
how
Isco
provides
the
Dr
box,
authentication
and
authorization
for
your
services
in
your
kubernetes
cluster,
so.
B
Skew
provides
toolbox
of
authentication,
one
is
peer,
authentication
and
another
is
a
request
authentication.
So
so
peer
authentication
allows
like
Define
how
traffic
is
getting
terminal
to
your
workloads
in
your
automation.
That
means
like
a
peer
authentication
controls.
The
mutual
DLS
traffic
between
your
services
in
your
biggest
authentication
policy
allows
you
to
define
the
mode
of
mtls,
which
should
you
are
going
to
be
used
in
your
class
in
your
mesh.
B
Actually,
so
there
are
three
types
of
mtls
modes:
actually
one
is
permissive,
one
other
is
restricted
and
the
last
one
is
disabled,
so
by
default
the
mode
is
permissive.
That
means
the
client
is
sending
a
request
to
a
server
service.
I
think
that
our
client
service
don't
have
any
certificate
with
it.
Then
it
will
allow
that
it.
Basically,
it
will
allow
plane
as
well
as
mpls
traffic.
B
So
that
is
what
we
can
control
through
the
your
authentication
and
request
authentication
use
for
the
end
to
end
user
authentication
like
whenever
a
end,
User
make
a
request
to
your
services
with
any
credential
attached
to
it.
So
is
Theory
or
request.
Authentication
is
responsible
for
validating
those
credential.
It.
B
Istio
only
supports
the
Json
web
tokens,
which
we
abbreviated
as
jwp,
so
request,
authentication
verifies
the
attached
JWT
to
your
request
and
decide
like
whether
the
request
identity
is
authenticated
or
not,
and
when
they
investigate
authenticated,
it
forwarded
it
for
the
authorization.
So
next
part
of
this
process
is
authorization,
so
it's
Q
or
what
is
the
authorization?
It's
a
simple
of
the
cdrd
custom
resource
authorization
policy
and
lets
us
control
the
workload
to
workload
and
the
work
end
user
to
workload
traffic.
B
The
action
is
allowed
so
whenever
we
create
any
authorization
policy
in
our
organization,
so
without
any
action,
so
by
default
get
created
with
the
allow
action
it
is
recommended
to
start
with
all
deny
in
your
cluster
and
start.
You
start
creating
some
allow
policies
for
authorizing
the
request.
Coming
from
outside
your
left,
outside
your
base
or
the
traffic
coming
from
the
same
same
Niche,
or
we
can
use
authorization
policies
in
multi-cluster
setup
as
well,
because
our
history
works
very
well
with
setting
up
a
multiple
cluster.
A
B
This
diagram,
we
can
clearly
see
like
how
traffic
flows
or
when
we
introduce
a
skills
of
information
in
our
cluster.
If
you
see
the
traffic
is
like,
the
traffic
between
Services
is
mdls
like.
If
you
see
the
green
lines
that
showing
traffic
is
going
from,
one
service
a
to
service,
B
is
mpls
and
it's
secured
and
the
traffic
from
end
user
to
your
services
coming
through
the
interest
Gateway
and
that
JWT,
or
with
the
JWT
plus
from
interest
gateway
to
your
backend
server.
B
It
is
again
ntls
so
end
to
end
your
application
could
be
secure
with
mtls
and
proper
authentication
and
authorization.
Okay.
This
is.
A
So
let
us
get
into
the
request
level,
authentication
and
authorization
before
we
dive
dive
in
it's
important
to
understand
why
something
of
this
sort
is
actually
needed
within
your
cluster.
So
a
request
level
authentication
in
kubernetes
cluster
serves
multiple
purpose.
It
allows
users
to
access
data
securely.
It
grants
programmatic
access
for
various
applications
and
facilitates
reliable
communication
between
various
services.
So
what
you
see
here
are
different
use
cases
that
we
have
listed
where
request
level
authentication
might
be
required
rather
is
required.
A
So
you
know
it
basically
is
required
to
allow
users
of
your
application
to
access
data
on
your
server
through
your
through
a
through
a
browser
or
over
a
mobile
phone
app.
It
also
is
required
to
give
your
end
users,
both
people
and
programs,
programmatic
access
to
data
managed
by
our
application,
which
can
be
through
means
of
apis
or
some
endpoints
and,
lastly,
to
let
other
services
that
make
up
your
applications,
infrastructure
communicate
with
each
other.
A
So
these
are
some
scenarios
where
you
know:
request
level
authentication
is
required
and
before
we
Deep
dive
into
the
demo
and
the
Crux
of
today's
webinar,
let
us
quickly
go
through
what
JWT
is
so
Json
web
token
is
an
open
standard
that
defines
Compact
and
self-contained
way
of
transmitting
information
between
parties
as
a
Json
object,
and
it
is
a
very
popular
user
authentication
standard
as
well.
So
this
token
is
made
up
of
essentially
three
components:
you
have
a
header,
you
have
a
payload
and
you
have
a
signature.
A
So
in
this
diagram
is
a
basic
structure
of
a
Json
web
token.
So
you
can
see
the
header
which
defines
the
type
of
algorithm
and
the
type
of
token.
So
here
you
can
see,
the
algorithm
type
is
hs246
and
type
is
JWT.
The
payload
essentially
has
the
meat
of
the
token
so
things
like
the
name,
the
issuer.
What's
the
role,
the
issue
and
time?
A
These
are
the
things
which
we
Define
in
the
payload
and,
lastly,
is
the
signature
where
basically,
we
can
use
a
combination
of
our
public
and
private
key
to
sign
the
entire
token.
So
the
JWT
token
is
basically
consisting
of
these
three
particular
components
and
in
today's
webinar
that
would
be
the
Crux
of
the
demo
that
we
have.
B
Yeah,
so
it
still
allows
us
to
validate
JWT
tokens
using
their
request,
authentication,
which
is
a
custom
resource,
which
means
which
we
will
see
how
we
can
create
the
request
authentication
in
the
demo,
so
request
authentication
will
validate
whatever
the
Texas
coverage
will
attach
to
our
request,
while
making
API
calls
to
our
applications,
API
endpoints
and
validate
in
Twitter
key
clock,
because
we
will
be
using
keep
flow
as
our
authentication
provided
in
this
demo
and
was
that
JWT
get
authenticated,
it
will
get
passed
to
the
authorization
policy.
B
An
authorization
policy
verifies
whether
or
it
is
the
authenticated
or
Identity
or
not.
If
it
is
authenticated
identity,
then
it
will
allow
us
to
access
the
API.
Otherwise
we
will
get
a
r
back
exercise
error
and,
as
you
can
see
in
this
diagram,
it
is
like
high
level
of
like
a
flow
of
our
like
how
our
application,
workflow
will
look
like.
B
So
we
will
make
the
API
call
to
our
looking
for
application
with
the
Json,
which
we
will
generate
from
Key
clock
and
will
pass
attack
it
as
a
authorization
Bearer,
and
that
request
will
go
through
the
request,
authentication
and
authorization
policy,
and
it's
all
the
things
identified
that
JWT,
which
we
have
attached
is
valid.
Then
we
will
get
a
response
or
like
that
moment
that
response,
otherwise
we
will
get
a
403
or
that
x89.
B
So,
let's
see
how
this
actually
will
look
like
in
the
day.
So
let's
get
started
with
this
with
today's
demo
and
for
today's
demo,
IMB
I'll
be
using
a
local
current
cluster
with
metal
and
be
installed
on
it,
which
will
allow
us
to
create
a
node,
whereas
the
service,
because
we
would
need
a
loadback
itself
or
sq
increase,
Gateway
and
key
clock
service.
I
have
deployed
one
simple
application,
which
is
a
book
in
for
application.
B
That's
application
exposes
to
eight
points,
one
for
adding
a
book
and
one
for
about
living
table
which
we
have
already
added
into
the
database.
So
these
two
like
this
is
the
application
with
it,
and
this
is
the
database
which
you're
going
to
store
the
book.
Information
I
have
already
set
up
a
SQL
upon
this
local
cluster
or
with
the
demo
profile,
and
installing
a
studio
is
fairly
a
simple
step.
You
can
follow
the
documentation.
B
So,
let's
see
how
our
application
actually
look
like,
so
let
me
first
make
an
API
call
to
my
get.
I'll
first
extract
the
IPS
of
Click,
lock
and
SQL
Gateway,
because
we
needed
frequently
in
in
this
demo,
so
I
have
did
this
late
or
let
us
make
a
API
call
to
get
put
API
endpoint
and
see
what
we
get.
B
Foreign,
let
us
add
one
sample
book
or
application
to
the
database
in
case
if
they
say
this
means
it's
got
added.
Let
us
check
by
making
making
a
good
books
now
we
can
see,
we
have
added
volume
yeah,
but
in
real
world
you
may
have
your
application
and
exposing
the
API,
which
is
which
allowing
your
users,
you
know,
store
and
data
into
the
database,
sensitive
data,
and
you
don't
want
anyone-
can
access
those
inputs.
It
should
be
accessed
by
the
authorized
persons.
B
Only
let's
say
in
your
in
our
application
example:
we
have
to
do
restrict
our
Adib
in
this
case.
In
this
way,
only
the
authenticated
user
can
only
be
able
to
add
a
books
and
the
get
book
API
would
be
available
for
formula
to
view
all
the
books
from
the
database.
Let's
see,
how
is
Q
tell
us
to
do
that
with
develop
any
authentication
provider.
In
this
case
we
are
using
key
clock.
So,
let's
first
set
up
a
key
clock.
I
have
already
installed
the
click
log.
B
Keep
it
simple
for
the
sake
of
this
demo,
then
we
have
to
create
a
client.
We
will
create,
create
open,
ID
connect
client,
which
will
allow
us
to
request
the
jwd
and
Generator.
B
B
So
we
would
use
this
user
to
generate
access
token
and
make
a
API
request
to
our
application.
So
I'll
create
a
user
as
an
academy.
B
So
I
have
all.
Let's
create
this
user
set
a
password
for
this
user,
like
we
said
it
has
three,
hence
again
don't
use
such
a
big
password.
So
now
we
are
done
with
gate
log
setup.
Actually,
that's
all.
We
have
created
a
real
in
that
real,
the
accurated
client
and
we
have
created
a
user.
So,
let's
see
if
we
are
able
to
generate
a
token
or
not.
B
B
Application,
so
let's
see
how
this
would
look
like
in
action
yeah.
So
for
that
first
we
have
to
create
a
skills
request,
authentication
to
validate
that
access
token,
which
will
attached
to
our
request.
So
let's
see
how
how
this
authentication
policy
will
look
like
it
is
fairly
simple
here
we
have
just
created,
match
rule
so
where
to
apply
this
authentication
policy.
So
here
we
are
saying
like
to
apply
this
authentication
policy
for
all
the
ports
which
are
running
with
the
level
book
info
and
we
have
given
the
jwq
rules.
B
So
here
we
have
given
the
issue,
one
from
where
we
are
generating
statewpts,
and
here
we
are
using
this
jwks
you
all
right
is
nothing
but
Json
key
set
URI,
which
textbook
it's
public
key
on
this
URL
and
SQ
will
go
there
and
verify
the
as
we
displayed
in
slides.
This
queue
will
verify
the
jwts
signature
over
this
URL,
so
it
is
fairly
simple.
You
will
find
more
information
about
request,
authentication
on
istio's
official
documentation
of
all
this
works,
so
you
can
also.
B
We
can
check
out
that
now,
let's
apply
this
authentication
for
this
request:
authentication
policy.
Sorry.
B
B
Yeah
but
but
that
is
not
a
case
here,
we
are
able
to
add
good
and
that's
because
we
don't,
we
have
to
use
the
authorization
policies
that
is
to
authenticate
and
request
only.
We
have
authenticated
that
request,
but
we
have
not
restricted
the
accent,
then
only
the
authenticated
request
only
about
200
API,
which
is
ADD.
We
can
you
know
about
this.
So,
let's
see
we
have
authorization
policy
as
well.
So
in
this
series
authorization
policy.
B
A
B
Sorry
now
we
have
a
from
rule
as
well,
so
that
from
rule
defines
that
the
request
is
coming
from
the
authenticated
identity
and
only
it
will
allow.
So
here
we
are
using
star,
but
you
can
find
credit
if
you
have
multiple
JWT
issues
or
for
the
multiple
endpoints
you
can
use
that
combination
of
issuer
and
the
subject
which
you
will
get
into
the
JWT
payload.
So
as
we
showed
in
the
slides
there
were,
there
are
three
parts
of
JWT,
the
header,
the
payload
and
the
signature.
B
So
in
a
payload
we
will
get
a
who
is
the
issuer
of
that
jwd
and
what
is
the
subject?
So
you
can
use
a
combination
of
issue
and
subject
to
find
Trend
your
Access
Control
platform,
so
here,
after
the
sake
of
this
demo,
I'm
using
a
star.
So
let's
see
how
let's
apply
this
authorization
policy
and
let's
see
what
happens
so
the
authorization
policy
is
created.
B
B
B
B
Is
added
yeah,
so
it's
fairly
simple,
actually
adding
authentication
authorization
for
your
application,
but
it
make
it
get
difficult.
It
feed
our
multiple
endpoints,
multiple
authentication
providers
Originals.
So
in
that
case,.
A
A
So
that
was
a
wonderful
demo.
By
shabbas
we
saw
how
we
can
use
Key
Club
to
generate
JWT
tokens
and
then
authenticate
our
request
using
istio's
request
Authentication.
A
So
to
sum
it
up,
you
know
proper
authentication
and
authorization
are
essential
for
securing
any
application
that
you
might
have
so
kubernetes
native
Securities
Solutions
are
not
enough
for
a
production
grade
security,
so
you
might
have
to
you,
know,
mix
and
match
a
couple
of
tools
to
create
your
Custom
Security
solution
and
istio
provides
a
seamless
solution
for
controlling
access
and
simplifies
request
level,
authentication
and
authorization,
as
we
saw
in
the
demo,
and
it's
fairly
easy
to
use
an
external
authentication
mechanism
like
key
cloak,
which
can
help
offload
authentication
from
istio
as
well.
A
So
this
approach
makes
the
system
more
robust
and
secure,
so
that's
pretty
much
it
for
the
webinar.
We
would
like
to
thank
you
for
joining
in
and
we
hope
that
the
webinar
was
insightful
and
you
took
away
something
new
from
this
webinar.
You
can
reach
out
to
us
for
any
queries
and
any
further
questions.
So
thank
you
so
much
and
have
a
wonderful
day.