►
From YouTube: OpenShift Commons Briefing #131 End-to-End Security for Microservices - Ariful Huq (Aporeto)
Description
In this OpenShift Commons briefing, Aporeto's Ariful Huq discusses best practices around securing your microservices:
Comprehensive: Zero Trust security for Network and API access control. Run-time visibility
Identity-driven: Identity is central to access control – and why cryptographic methods for assigning an identity to workloads are essential
Heterogenous: Because enterprises have mixed environments, the right security solution has to operate across clouds as well as in non-cloud native and service mesh environments
Following the best practices discussion, we will have a quick overview of Aporeto 2.0 as well as a demonstration of:
Network access control & API access control for apps deployed across multiple clouds and clusters.
A kill chain scenario
A
Hello,
everybody
and
welcome
to
another
open
ship
Commons
briefing.
This
time.
Curco
is
going
to
talk
about
end-to-end
security
for
micro
services.
We
have
Ari
full
who's,
the
director
of
product
management,
I'm
gonna.
Let
him
introduce
himself
the
format
again,
as
always
is
ask
questions
in
the
chat.
While
did
it
talk
and
the
demo
are
going
on
and
then
we'll
have
live
Q&A
at
the
end
and
with
that
I
like
a
refill,
take
it
away,
hey.
B
B
Okay,
so
what
I
want
to
start
off?
The
discussion
is
talking
to
talk
about
because
a
shift
that's
happening
from
monolithic
applications
to
cloud
native
applications
and
how
that
is
impacting
security.
So
in
the
monolithic
world
you
typically
have
a
single
monolithic
software
running
within
the
context
of
a
data
center.
B
You
have
a
perimeter
firewall,
that's
protecting
that
application
and
that
perimeter
firewall
typically
doing
north-south
protection
right
and
then,
as
you
move
towards
a
cloud
native
world
what's
happening,
is
that
monolithic
application
starts
to
become
a
distributed
set
of
components,
and
these
components
can
be
on
your
on-prem
data
center,
or
can
they
can
be
in
the
cloud
as
well?
So
right
there
there's
a
few
changes
that
have
happened.
The
parameter
is
no
longer
within
the
context
of
your
own
data
center
and
your
longer.
B
The
infrastructure
over
which
your
application
is
hosted
may
and
all
longer
be
under
your
control,
because,
if
it's
being
posted
in
a
public
cloud
environment,
you
don't
have
control
over
that
infrastructure.
So
there's
a
couple
of
things
that
are
required.
A
number
of
things
are
required
or
considerations
that
need
to
be
taken.
As
you
make
this
transition
and
the
person's
the
parameter
no
longer
exists.
A
distributed
security
model
is
required.
B
So
that's
going
to
be
the
kind
of
the
focus
of
discussion
today
as
customers
are
making
the
transition
from
monolithic
to
cloud
native
adoptive
adopting
cloud
native
services,
what's
kind
of
the
security
considerations
required
so
to
start
off,
I'd
like
to
discuss
the
security
challenges
as
you
make
this
journey.
So
we
talked
about
cloud
native
and
one
of
the
things
about
planet
'iv
is
their
dynamic
in
nature.
What
do
I
mean
by
this?
Typically,
when
you
want
to
make
use
of
cloud-based
infrastructure,
you
want
to
make
them
elastic.
B
You
spin
up
a
host
in
your
cloud
infrastructure
and
your
applications
in
your
deployment
application.
You
want
that
infrastructure
to
be
elastic
in
that
based
on
demand.
As
you
see,
demand
increase,
the
infrastructure
should
be
flexible
where
it
grows
as
the
demand
increases.
So
that
means
the
the
nature
of
deployment
is
actually
a
lot
more
dynamic.
It's
no
longer
a
static
deployment,
it's
no
longer
a
virtual
machine
on
a
host
and
the
life
that
virtual
machine
is
quite
long.
B
B
Acls
based
on
IP
rules
really
really
becomes
hard,
because
when
you
deploy
containers
in
a
dynamic
environment
or
when
you
deploy
micro
services
in
a
dynamic
environment
and
you're,
deploying
on
a
daily
basis
or
even
multiple
times
a
day,
the
IP
addresses
will
definitely
change.
So,
if
you're
writing
rules
based
on
IP
addresses
those
become
extremely
hard
to
manage.
B
Even
if,
even
if
you
automated
that
entire
process,
the
number
of
rules
increase
over
time
and
it's
really
kind
of
hard
to
figure
out
what
those
will
actually
mean,
so
the
the
deployment
velocity
also
reduces
because,
if
you're
going
to
try
and
deploy
these
application
multiple
times
a
day.
Typically,
what
happens?
Is
your
security
teams
get
involved
before
that
application
gets
deployed
for
compliance,
and
the
institutions
have
to
now
figure
out
what
IP
addresses
update
rules
so
really
the.
B
Process
of
deployment
is
also
hampered
it,
and
this
is
a
big
challenge.
We
talked
about
the
fact
that
you
no
longer
own
the
infrastructure,
so
this
introduces
new
threat
vectors
because
your
container
is
posted
on
infrastructure
that
you
know
you
may
not
no
longer
own.
So
you
need
to
get
visibility
at
the
hosts
layer
right.
You
need
to
figure
out,
what's
happening,
the
interactions
between
your
container
and
the
underlying
post,
as
well
as
when
you
deploy
containers.
What
are
what's
the
base
image
for
that
container
and
what
are
the
vulnerabilities
associated
to
that
container?
B
You
may
choose
a
basement
that
somebody
built
a
container
with
a
base
image
over
time.
You
kept
the
same
base
image,
but
you
didn't
really
figure
out
what
are
the
new
vulnerabilities
associated
to
that
new
container
to
that
container,
so
that
introduces
a
new
kind
of
threat,
vector
identity,
certificates
and
secrets.
This
is
important
even
in
monolithic
applications,
but
then,
as
you
head
towards
microservices,
this
becomes
a
lot
more
pronounced
because
you
have
a
lot
more
application
components
and
the
key
to
kind
of,
and
we're
going
to
talk
about
this
in
a
lot
more
detail.
B
The
key
to
doing
authentication
authorization
is
to
assign
identity,
so
assigning
service
identity
becomes
really
really
critical,
and
doing
this
in
massive
scale
becomes
important
distributing
secrets.
You
don't
want
to
have
secrets
within
your
application.
Distributing
these
secrets
across
your
applications
also
becomes
important,
participate,
a
rotation
and
certificate
issuance.
Those
are
things
that
you
also
have
to
consider.
B
Typically,
what
we
see
is
developers
spend
a
lot
of
time,
building
this
infrastructure,
as
opposed
to
working
on
business
logic,
so
they're
trying
to
introduce
new
ways
to
distribute
secrets
and
doing
building
a
PGI
infrastructure
to
manage
certificates,
and
that
takes
up
time
away
from
business
logic,
so
that
work
needs
to
be
offloaded.
And,
finally,
the
API
is
a
new
resource
in
micro
services
and
everything
is
controlled
through
this
API,
so
how
you
access
a
micro
service?
B
What
are
the
crud
operations
towards
that
micro
service
is
all
controlled
through
an
API
and
authentication
authorization
for
these
API
is
extremely
critical.
What
we
typically
see
is
customers
try
to
do
this
authorization
logic
within
their
application
and
that
becomes
really
really
difficult
because
it
becomes
harder
to
manage
if
you
have
a
change
in
the
authorization
logic,
it's
hard
to
manage
that
change.
A
B
Know
you
have
to
go
deploy
the
application
again.
So
these
are
the
challenges
that
we
see
in
the
micro
service
world,
and
what
we're
going
to
talk
about
is
some
of
the
considerations
you
should
take
when
approaching
a
security
solution.
Given
the
challenges
that
we
just
talked
about,
so
there's
two
things
that
at
aparato
we
focus
on
is
the
fact
that
the
solution
must
be
based
on
the
principles
of
zero
trust,
security
and
I'm.
Going
to
explain
this
in
a
lot
more
detail.
What
do
we
mean
by
zero
trust?
B
The
fact
that
you
should
assume
that
you're
always
under
attack
and
no
communication
is
permissible
until
you
are
you
present
the
right
identity
and
number
two
is
this
concept
of
a
heterogeneous
environment?
What
we
see
is
customers
when
they
deploy
micro
services,
they
do
this
across
on-prem
clouds
and
and
it
has
to
take
into
account
multiple
types
of
environments.
So
we'll
talk
about
that.
B
So
what
do
we
mean
by
zero
trust
security
through
identity,
so
the
court
to
any
authentication
authorization
operated
operation
is
presenting
the
right
identity.
I
need
to
present
my
identity.
First,
before
I
authenticate
this
communication
and
once
I've
presented
my
identity,
then
I'm
able
to
authorize
based
on
an
existing
policy.
So
we
break
it
down
in
terms
of
kind
of
really
two
actors:
one
is
the
user
and
the
other
is
a
service
or
an
API
endpoint
both
by
that
service.
B
So
the
interaction
point
can
be
a
user
trying
to
access
a
service
or
an
API
endpoint
exposed
by
that
service,
or
it
can
be
between
two
services.
So
when
a
service
tries
to
initiate
a
community
connection
with
another
service,
it
has
to
present
a
service
identity
and
what
is
that
service
identity
mean
it
can
come
in
many
ways
and
it's
contextual,
so,
for
instance,
container
metadata
can
be
part
of
that
service
identity.
What
is
the
image
information
associative
container?
Is
it
running
mangal?
Is
it
running
nginx?
What's
the
build
data?
Did
it
pass
regression?
B
Did
it
pass
the
critical
milestones
that
are
required
before
this
application
should
be
deployed?
All
of
these
milestones
can
actually
be
embedded
as
metadata
into
your
container
through
the
defense
or
the
deployment
process,
and
you
can
extract
this
information
when
you're
deployed
this
container.
What
type
of
container
is
their
front
end
is
their
back
end.
What
type
of
vulnerabilities
are
associated
this
container?
B
We
see
customers
due
to
vulnerabilities
and
as
part
of
the
CI
CD
pipeline,
but
when
one
second,
once
the
container
gets
deployed,
how
do
you
have
visibility
in
day
two
for
what
vulnerabilities
are
associated
in
this
container
in
day
two,
if
there's
a
critical
vulnerability
associated
to
a
container,
and
it
is
a
front-end
container,
you
want
to
take
remediation
actions.
So
having
that
vulnerability
data
be
part
of
the
contextual
identity
of
the
container
is
actually
really
really
critical.
So
this
is
what
we
mean
by
the
identity
of
a
container
we
extract.
B
You
can
extract
this
information
and
kind
of
use
it
as
a
fingerprint
anytime.
It
needs
to
communicate
with
another
service
or
a
user
tries
to
communicate
with
it
and
in
terms
of
a
user.
The
identity
is
some
sort
of
a
token
that
may
have
been
issued
by
an
identity
provider
right,
so
an
identity
provider
could
be
octa
or
odd
zero.
You
basically
get
authenticated
and,
as
a
token
that's
issued-
and
you
present
that
token
and
that
token
allows
you
to
authenticate
authorize
the
user
to
service
communication,
the
heterogeneous
environment.
B
That
kind
of
what
we
mean
here
is
the
application
in
itself
can
be
hosted
across
multiple
environments.
Here's
one
example
that
I
like
to
bring
up
here
is:
we
were
talking
to
one
of
our
customers,
they're,
building
a
loyalty
program
and
with
microservices
what
they
realized
is
they
have
small
teams,
and
people
can
build
the
their
own
functions
using
their
own
languages
and
their
choice
of
a
platform.
This
specific
customer
actually
had.
B
They
were
using
AWS
everything
sure
they
were
using
microservices
their
use,
basement
containers
and
virtual
machines
they're
using
Azure
functions,
because
one
of
their
teams
decided
hey
as
your
functions
is
actually
going
to
work
really
well
for
what
we
want
to
do
so
now
you
have
a
mixture
of
lambda
func,
serverless
functionality.
You
have
service
mesh
technology
that
you'll
be
using
on
top
of
kubernetes.
If
you
have
darker
clusters,
you
have
Linux
services.
How
do
you
implement
authentication
authorization
across
all
these
technology
stacks?
B
Because
it's
important
to
do
that,
you
need
to
have
a
centralized
way
to
authenticate
authorize
any
sort
of
communication
in
this
environment
and
the
fact-
and
this
CD,
the
environments
themselves-
can
be
deployed
across
any
I
as
a
path
environment.
So
it
can
be
deployed
it
a
tub.
Yes,
as
your
open
shift
in
what
we're
going
to
talk
about
today,
IBM
cloud
or
booth,
so
sort
of
any
type
environment.
So
that's
what
we
mean
by
hydrogens
environment
and
the
security
solution
needs
to
consider
this.
B
Taking
those
things
into
consideration.
Let's
talk
about
what
we're
doing
in
aparato
and
some
of
the
use
cases.
So
I'll
start
off
with
you
stasis.
The
the
first
thing
is
service
identity
with
aparato.
What
we
do
is
any
sort
of
component
any
application
component,
whether
it
be
a
container
or
virtual
machine
we
assign
it
automatically
assign
its
service
identity
and
how
we
assign
it.
We
talked
about
this
briefly
in
the
case
of
a
container
we're
able
to
extract
a
lot
of
metadata
from
this
container
and
use
that
as
the
identity
of
that
container.
B
So
when
a
container
comes
up,
whether
it's
in
a
docker
environment
or
whether
it's
in
a
proven
native
environment,
we
we're
able
to
inspect
to
the
docker
API
through
the
tube
API.
What
is
this
container
validate
that
and
then
assigned
an
attested
identity
to
that
container
right
as
part
of
identity?
There's
also
certificates
distribution,
because,
typically
the
identity
is
being
assigned
to
a
certificate,
and
you
need
to
handle
certificate,
rotation
and
revocation
that
those
are
all
things
that
we
actually
take
care
of
segmentation
access
control.
B
So
this
is
by
far
our
biggest
use
case
being
able
to
do
network
segmentation.
So
you
have
kind
of
process
to
process
or
container
to
container
virtual
machine
to
virtual
machine
level
of
segmentation
right,
and
this,
for
me,
can
be
for
compliance.
It's
just
to
reduce
the
scope
of
your
thread
vector
make
sure
that
everything
is
authenticated
authorized
before
you
allow
the
communication
across
any
environment
whether
the
application
is
being
deployed
in
a
public
line
environment
or
whether
it's
being
deployed
and
in
your
own
on-prem
datacenter,
doesn't
matter.
B
We
will
authenticate,
authorize
those
communications,
API
level,
access
control
so
getting
into
the
API
level.
Visibility,
so
I
can
give
Network
level
access
between
two
containers
or
two
pods,
but
that's
not
sufficient,
because
given
I
have
access
between
two
pods,
what
are
the
API
endpoints
I
should
have
access
to
what
are
the
API
endpoints
I'm
authorized
to
have
access
to?
That
is
the
level
of
access
controls
that
we
provide
automated
flow
and
telemetry
logging,
so
being
able
to
get
visibility
across
your
applications,
a
dependency
map.
So
when
an
application
initiate
the
connection,
is
it
allowed?
B
Is
it
denied
across
what
what
are
your
dependencies
across
your
application?
What
is
this
application
talking
to
getting
that
level
of
visibility
is
extremely
important,
so
that's
something
that
we
provide
encryption
so
being
able
to
do
services
service
encryption
using
neutral
TLS.
This
is
extremely
important
because
you
don't
want
to
integrate
this
into
your
application.
If
you
have
that's
fine,
then
you
don't
have
to
use
this
capability,
but
you
haven't
be
having
the
burden
of
integrating
TLS
libraries
into
your
application
and
setting
up
the
TTL
logic
associated
to
that.
So
you
can
do
certificate.
B
Distribution
is
very
painful
and
a
lot
of
work
for
developers
also
that
from
your
application,
vulnerability
analysis
so
being
able
to
continuously
monitor
or
vulnerabilities
within
that
container
and
notify
the
user
that
hey
a
new
vulnerability
has
introduced.
A
new
critical
vulnerability
has
been
excused,
so
you
can
assess
the
impact
of
that
vulnerability.
These
are
the
four
use
cases
that
we
focused
on
a
Toretto.
B
So
where
is
a
better
fit
where
we
fit
is,
if
you
think
about
a
host
in
the
case
of
a
simple
bare
metal,
virtual
machine,
we
are
a
system,
deep
process
and
agent
on
that
coast
in
the
case
of
a
docker
environment,
where
another
container
on
the
doctor
environment,
in
the
case
of
kubernetes,
for
example,
in
an
open
shift,
is
actually
exactly
the
same
as
any
other
kubernetes
cluster.
We
are
dealing
set
right,
so
you
bring
us
up
as
a
daemon
set
in
that
environment.
B
We
operate
on
top
of
any
infrastructure,
so
doesn't
really
matter
where
your
open
ship
cluster
or
where
your
application
may
reside
it
can
be
on
any
public
cloud
or
private
cloud
environment.
We
also
work
with
if
you're,
making
use
of
kind
of
Linux
processes.
The
automation
mechanism
can
be
done
to
chef
puppet,
so
multiple
ways
to
kind
of
bring
up
our
solution.
B
So
since
there's
an
enforcement
point
or
an
agent,
that's
on
the
host
and
then
there's
what
we
call
the
apparatus
security
Orchestrator,
which
is
your
single
pane
of
glass
into
the
apparatus
solution.
It
is
what
you
use
to
get
visibility.
It
is
what
you
use
to
go,
define
policies
and
it
allows
you
to
do
everything
that
you
need
to
manage
this
entire
solution.
Through
a
SAS
platform,
the
SAS
platform
in
itself
can
be
single
tenant
or
multi
tenant,
depending
on
sort
of
the
user
preference.
B
The
platform
also
has
access
to
third
party,
providing
like,
for
instance,
vulnerability
scanners,
so
we
are
able
to
kind
of
tie
into
a
Qualis
or
tenable
vulnerability,
Center
that
you
may
be
using.
So
you
because
you
have
that
in
your
environment,
we
are
able
to
kind
of
extract
the
information
from
those
vulnerability
scanners
and
use
that
to
enforce
stronger
policy
in
our
environment,
tying
into
a
theme,
environment,
dreams
and
management
tools.
B
So
being
able
to
tie
into
a
Splunk
or
curator
arcsight
tying
into
a
CI
CD
pipeline,
we
talked
about
the
fact
that
you
can
get
a
lot
of
rich
data
on
the
light
mode
container.
So
what,
as
it
went
through
the
deployment
process,
did
it
pass
some
aggression
who
committed
the
code?
What
that
resulted
in
is
container
actually
being
built?
Getting
that
information
and
being
able
to
enact
policy
based
on
that
is
actually
very
important.
B
So
we
can
tie
into
github
to
get
all
that
kind
of
information
and
then
kind
of
connecting
to
Claudia
as
I
get
up.
Yes,
because
we're
in
the
case
beta,
because
what
we're
able
to
do
is
figure
out
what
are
the
AWS
managed
services
that
you're
using
and
actually
give
you
access
control
to
manage
service?
So,
for
instance,
your
server
needs
to
talk
to
dynamodb,
so
dynamodb
will
show
up
as
as
an
external
sort
of
service
at
managed
by
AWS,
and
you
can
enforce
policy.
Should
the
server
have
access
to
this
data,
we
give
you.
B
Okay,
so
how
does
this
solution
actually
work?
So
I'll
kind
of
walk
you
through
from
the
beginning.
So
what
happens
is
there's
an
enforcer
that
comes
up
on
a
host
again
as
the
demons
that
are
as
a
container
or
the
agent?
It
goes
through
a
registration
process
and
as
far
as
this
registration
process,
it
gets
an
identity
itself
right.
So
then
the
identity
that
we
actually
assigned
to
the
enforcer
that
has
we
trust
through
a
certificate.
That's
certificates,
route,
Authority,
that's
on
that's
on
the
a
fraud
Orchestrator
or
it
can
be.
B
We
can
be
an
intermediate
the
certificate
authority
as
well.
So
if
you
want
to
use
your
own
CS,
that's
going
to
be
fine.
Once
that
happens,
the
application
comes
up
and
we
assign
an
identity
to
this
application
right.
So
there's
an
intested
identity,
that's
a
scientific
application.
Once
the
application
comes
up,
and
once
that
happens,
there's
a
pub
we
get
the
policy
for
the
specific
application.
What
are
the
authorization
rules
for
this
specific
application?
And
then
the
application
tries
to
initiate
a
connection,
and
this
is
a
three-way
handshake.
B
Since
then,
I
can
act
as
part
of
that
three-way
handshake.
We
authenticate
and
authorize
this
interaction
with
a
service
identity,
so
the
application
has
to
present
its
service
identity
to
its
remote
endpoints.
We
authenticate
authorize
based
on
the
server's
identity,
and
only
then
we
allow
this
connection
to
go
through
once
the
connection
goes
through.
We
actually
get
out
of
the
path,
so
we
are
only
in
the
path
for
the
three-way
handshake.
Now,
if
you
want
us
to
do
encryption,
then
certainly
we
have
to
be
in
the
data
path
for
the
encryption
piece.
B
But
if
you
don't,
if
we're
not
enabling
encryption,
then
all
we're
doing
is
looking
at
the
two,
your
handshake,
embedding
the
service
identity,
authenticating
authorizing
authorizing
that
communication
and
then
we're
out
of
the
back
now
with
API
level.
Access
control
is
slightly
different.
It's
the
same
process,
but
once
the
FinCEN
act
is
complete,
the
TCP
level
negotiation
is
complete
again
we're
doing
that
based
on
service
identity,
then
what
we
do
is
does
an
HTTP
request.
That's
made
right
now
we're
doing
rest
based
services,
that's
kind
of
what
we're
focusing
on
for
the
API
level.
B
Access
control
will
extend
this
to
Kosta
and
G
RPC
as
well
Oh
once
HTTP
requests
them,
then
we
actually
insert
service,
identity
and
claim
to
this
request
through
through
the
HTTP
header.
As
a
token,
and
these
this
identity
and
claim
is
presented
and
then
only
then
you
have
access
to
the
specific
HTTP
endpoint,
the
specific
API
endpoint
that
you
want
to
have
access
to
right.
So
it's
just
another
level
of
access
control
that
you
have
beyond
just
the
TCP
connection.
We're
actually
doing
it
this
at
the
HQ
p
layer
as
well.
B
A
B
B
So
what
you're,
looking
at
here
and
I'm,
going
to
switch
screens
here,
real
quick?
What
you're
looking
at
here
is
what
we
call
the
aparato
security
Orchestrator,
so
I'm
going
to
let
this
load
for
a
second.
So
there's
a
few
things
that
I
want
to
highlight
to
this
again.
This
is
that
based
service.
We
have
this
concept
of
a
named
base,
and
this
is
important
to
highlight
early
in
the
discussion,
because
this
is
this
is
sort
of
how
you
control
access
and
how
you
define
policies
and
who
you
give
access
to
this.
B
This
is
a
control
controller,
so
the
concept
of
namespace
allows
you
to
kind
of
build
isolated
environments,
so
my
name
is
Orville.
Husk
I
have
a
dev
a
prod
and
a
test
environment,
but
think
of
this
as
a
company
that
has
multiple
business
units
and
each
business
unit
is
given
its
own
namespace
and
within
that
namespace
to
have
a
dev,
a
prod
and
test
environment,
and
these
environments
are
completely
isolated
right.
A
B
Shift
so
I
basically
have
created,
within
my
prod
environment,
multiple
clusters
and
within
one
of
those
clusters.
I
have
an
application.
That's
deployed
right,
so
this
concept
of
a
namespace
allows
you
to
create
hierarchy.
So
your
information
security
team
can
essentially
write
policies
at
our
very
top
level
hierarchy
and
say:
I
want
all
communications
between
pods
or
between
containers
to
be
encrypted.
That
can
be
a
very,
very
high
level
policy
construct
that
gets
propagated
down
to
every
single
organization.
Right
geo
information
security
team
can
enforce
that
policy.
B
A
B
Very
simple,
app
called
look
info.
You
might
have
actually
seen
this
number
time,
so
a
lot
of
people
use
this
app
nowadays,
so
now
this
environment.
What
I'm,
showing
you
here
is
our
containers
right.
So
this
is
the
the
application
itself
consists
of
multiple
micro
services,
so
it
consists
of
a
details:
micro
service,
a
product
page,
a
ratings
and
reviews
page.
B
These
are
all
individual
micro
services
and
when
I
click
on
a
specific
micro
service,
in
this
case,
a
container
I
can
actually
start
to
get
the
metadata
associated
to
this
container,
and
this
is
what
we
mean
by
the
contextual
identity
of
this
container.
So,
for
instance,
this
container
happens
to
be
deployed
on
a
host.
B
It
is
deployed
in
an
open,
shipped
cluster
and
it's
deployed
in
Amazon
and
in
this
case
I
can
actually
start
to
get
information
around
what
am
I,
what
availability
zone
in
Amazon
is
that,
is
it
hosted
on
what
actual
hosts
is
it
is
it
residing
on?
What's
the
type
of
host
which
region
there's
a
lot
of
information
that
we're
starting
to
extract
right
from
from
Amazon,
and
you
can
build
policy
on
that?
B
All
of
these
are
key
value
pairs
that
you
can
use
to
write
policy,
there's
user-defined
tags
so,
for
instance,
I've
assigned
a
people
details.
So
this
is
a
details,
page
app
and
so
that's
kind
of
the
user
identity.
There's
also
vulnerability
of
data
associated
this
container,
and
this
is
the
contextual
identity
that
we
were
referring
to.
So
this
container
happens
to
have
a
number
of
vulnerabilities
associated
to
it,
and
you.
A
B
Write
policies
based
on
that
you
can
say
if
I
have
a
critical
vulnerability
and
it's
a
front-end
container.
You
know
give
me
first
alert
me
that
there,
in
fact
there
is
a
front-end
container
that
has
a
critical
vulnerability.
You
can
say
things
like
log
connections,
you
can
say
things
like:
don't
authorize
communications
after
a
specific
period
of
time
you
can
so
we
have
this
capability
where
you
can
say
if
a
vulnerability
is
a
critical
vulnerability,
it's
on
a
container
for
more
than
a
specific
period
of
time.
B
Then
this
allows
communication
with
this
condition,
gives
your
team
strategy
sometimes
actually
remediate
the
scenario.
So
you
don't
have
to
you
know
disallow
communications
or
enforce
a
strong
policy
immediately.
Give
your
team
some
time
before
that
happens.
So
that's
kind
of
contextual
identity
of
that
container
and
these
containers
these
applications
can
be
deployed
across
multiple
environments.
Right
so
part
of
my
cluster
is
in
AWS
part
of
it
is,
and
it
can
be
across
multiple
AWS
regions.
It
could
be
in
US
West,
it
could
be
in
USD.
It
doesn't
really
matter
right.
B
The
application
is
in
itself
can
be
deployed
across
multiple
clouds
across
multiple
cloud
regions
and,
more
importantly,
it
kind
of
work
across
a
load
balancer.
You
can
work
across
in
that
gateway.
It
doesn't
really
matter
to
us,
because
what
we're
doing
is
using
the
contextual
or
service
identity
to
authenticate
authorize
communications
without
looking
at
IP
addresses.
One
other
thing
here
is
the
fact
that
we
don't
even
care
about
that
Ghidorah,
so
it
can
be
over
overlapping
IP
addresses
as
well.
This
is
an
interesting
point
in
a
lot
of
large
companies.
B
B
In
here
refresh
and
as
I
do
that
you
start
to
see
connections
start
to
show
up.
So
what
just
happened
here
and
we're
giving
you
real-time
visibility
into
all
the
interactions
that
happen
as
a
result
of
me,
just
interacting
with
that
app,
so
I
came
in
from
the
internet
I
give
in
to
what
you
saw
is
the
product
page
from
the
product.
Page
I
went
to
another
secondary
page
I,
went
to
this
details
and
reviews
page
and
a
result
of
that.
B
B
Let's
click
on
one
of
these
interactions
and
what
I
can
see
is
there's
the
reason
why
this
interaction
was
allowed
is
because
there's
a
policy
associated
to
that
right
so,
and
a
policy
is
very,
very
simple
policy
here
is,
if
applicable,
product
page
wants
to
talk
to
applicants,
reviews
or
applicants
details,
except
that
traffic
encrypted
and
login
source
that
destination.
That's
the
policy
and
you
can
define
this
policy
in
a
number
of
ways.
You
can
define
it
through
our
product
through
the
wizard.
B
You
can
define
it
as
a
in
a
declarative
matter
to
a
llamo
file,
because
that's
what
we
realized
people
want
to
do
now.
As
far
as
a
DevOps
process
develops,
engineer
wants
to
automate
the
deployment
of
the
of
the
of
the
policies,
so
you
can
certainly
do
that
in
a
decorated
manner
through
Toriyama
file
as
well.
So
that's
those
a
policy
associated
the
fact
that
we
allowed
that
connection
to
happen.
Now
we
can
also
get
some
information
as
to
you
know,
this
was
a
GRDC
connection.
B
You
know
what
type
of
connection
it
was
as
well,
if
you're
coming
in
from
the
internet,
for
instance,
if
you're
accessing
an
external
service
like
in
this
case,
I've
enabled
UDP,
because
service
discovery
is
happening
through
DNS
and
I
need
to
enable
UDP.
So
I
will
tell
you:
what's
the
IP
address,
it's
actually
it's
using
to
to
deter
it
for
DNA
right.
So
let's
look
at
the
policies
that
were
implemented
as
a
result
of
this
interaction
being
allowed
so
I'm
going
to
go
back
to
my
network
policies
here.
B
And
so
I
allowed
you
TP,
so
essentially
my
ass
post
product
details,
room
is
rating
all
have
access
to
a
service.
Dns
and
I
define
the
service
as
an
external
service,
because
I'm
not
controlling
this
DNS
service,
but
I
can
show.
You
will
show
you
how
we're
at
providing
access
to
DNS
service
I'm,
allowing
connections
from
the
internet.
So
the
fact
that
the
internet
connection
is
allowed,
that's
the
policy
asserted
in
that
and
then
the
product
page
accessing
reviews
and
details.
B
This
is
a
policy
right,
so
if
I
want
to
modify
this
policy,
all
I
have
to
do
here
is
look
at
the
source
go
in
here
again,
it's
the
key
value
pair
I
can
assigned
in
a
key
value.
Pairs
would
go
into
the
destination
destination
is
absolutely
bays,
are
orgeat
or
details.
Action
is
to
allow
encrypt.
Those
are
the
actions
that
can
be
allowed.
B
B
So
I'm
trying
to
access
the
state.
Obviously
it's
taking
some
time
because
a
I
actually
didn't
allow
the
details.
Page
I
didn't
a
lot
of
product
to
details
base.
So
what
will
happen
now?
Is
you
will
see
that
I
try
to
communicate
from
the
Internet
to
product
page
and
it
try
to
initiate
a
connection
towards
details,
and
you
see
it
in
a
dotted
line.
B
B
And
in
this
case
you
see
the
connection
is
denied
because
there
is
no
policy
associated
to
it
right.
So
that's
the
policy
structure
is
very,
very
simple
in
terms
of
how
it
gets
implemented
and
how
it's
enforced,
the
you
define
all
the
policies
through
the
orchestration
tool
and
it's
all
enforced
in
a
highly
distributed
fashion
across
your
application.
B
So
there's
also
another
part
of
the
demo
related
to
API,
so
I'm
actually
going
to
just
switch
my
namespace
here
so
I
can
show
you
from
an
API
perspective.
What
I
just
showed
you
was
all
at
the
network
layer
now
at
the
API
layer.
What
we're
able
to
do
is
actually
typically,
what
happens?
Is
the
developer
defines
an
API
spec
and
the
API
suspected?
B
These
are
the
API
exposed
by
by
a
specific
micro
service,
and
what
I'm
going
to
be
able
to
do
here
is
take
this
API
spec,
which
can
be
a
llamo
or
it
can
be
a
swagger
file.
We
take
the
swagger
box
and
we
input
we
take
the
inputs
from
the
swagger
file
as
the
API
spec
right
and
then
we
define
services
between
in
this
case,
I
have
a
very
simple
app
and
the
app
is
what
we
call
an
apple
wine
app.
B
It
has
a
server,
it
has
a
MongoDB
database
and
a
UI
element,
and
what
I'll
do
is
now
I
will
define
the
specific
services
for
my
micro
service
and
I'll
apply
the
API
spec
to
these
micro
services
and
I'll
apply
a
policy
and
the
way
of
policy
is
applied.
Is
using
this
concept
of
a
scope,
so
I
sign
a
scope
to
a
specific
container
or
service
and
say
you
have
these
specific
privileges
right.
B
So,
for
instance,
in
this
case,
I
have
this
app,
which
is
called
a
beer
getter
and
a
wine
getter,
and
it
has
a
specific
scope.
It
presents
the
scope
and
has
access
to
what,
in
these
actives
I
have
a
UI
app
and
it's
given
a
specific
scope.
It
presents
the
scope
and
it's
given
the
access
that
it
needs
in
the
API
spec.
B
What
you
can
do
is
you
can
actually
define
these
scopes
so,
for
instance,
in
the
internal
API,
you
can
see
that
if
I
want
to
get
to
a
beer,
API
I
have
to
present
the
default
scope.
If
I
want
to
get
the
wine
API
I
have
to
present
the
protected
scope
with
the
specific
data
organization.
So,
for
instance,
we
can
even
look
at
if
the
user
is
trying
to
access
the
specific
API,
which
organization
is
the
user
from
right.
We
actually
look
into
the
token
that
was
issued
by
the
IEP.
B
Look
at
the
claims
from
that
token
and
determine
who
this
user
have
access
to
this
API.
So
not
only
are
we
enforcing
policy
as
the
network
layer,
but
we're
actually
doing
it
as
well
as
at
the
API
layer
through
API
level,
access
control
in
our
product,
that's
sort
of
the
end
of
the
demo
and
have
accomplished
everything
that
I
actually
wanted
to
show
at
the
product
dance,
so
I'm,
actually,
gonna
switch
back
to.
B
B
Yes,
that's
exactly
right,
so
I
did
I
just
skipped
this,
but
yes,
so
we
are
able
to
show
you
sort
of
the
anytime
of
policy
changes
happen.
You
know
where
was
audit
these
these
interactions
with
the
product,
so
you
change
the
policy.
Why
would
this
policy
changed?
So
you
have
otter
ability
into
sort
of
policy
changes.
Also,
you
have
audit
ability
within
the
product
for
any
sort
of
interaction.
That's
happening
right
so
when
I
showed
you
that
specific,
let's
go
back
to
a
namespace
here.
B
So
we
have
this
ability
to
actually
look
back
in
time,
so
over
the
last
hour
or
over
the
last
12
hours
or
a
day
or
week.
What
are
the
interactions
for
the
specific
applications?
You
have
visibility
over
time.
What
happens
actually
right?
What
are
what
were
the
interactions
and
yeah?
We
have
visibility
into
even
or
the
flows
between
the
interactions
between
these
specific
applications.
A
So
so,
for
me,
I
mean
I.
You
know
I
come
a
long
time
ago
from
an
audit
and
IT
compliance
background.
So
these
things
are
really
important
from
you
know
the
compliance
and
the
regulatory
possibility,
but
it's
also
an
amazing
tool.
If
you're
trying
to
figure
out
how
to
track
down.
You
know
something
that's
gone
catastrophic,
long
or
try
and
track
down
these
things.
It's
really
it's!
It's
not
just
for
the
auditors.
This
is
it
making
a
really
fun.
What
wonderful
UI!
First
of
all!
B
And
the
other
thing
we
also
do
and
I
skipped.
The
80ies
is
our
ability
from
an
API
perspective,
so
you
can
actually
see
what
api's
were
accessed
by
a
specific
client
and
why
was
denied
so,
for
instance,
if
we
was
denied
a
rationale
for
why
was
denied
who
acts
as
this
API?
What
were
the
claims
associated
this
API?
So
we
have
visibility
of
the
API
layer
as
well
sort
of
what
are
the
interactions.
B
A
Is
this,
is
you
know
this
is
this
is
in
some
ways
a
dream
tool
for
somebody
like
me
that
likes
to
dive
in
and
figure
out.
You
know
where
it
went
wrong
or
or
who
did
it
and
the
whodunit
piece
of
ID,
and
so
that's
pretty
cool,
so
I
don't
see
any
other
questions
from
the
folks
in
chat.
I
think
you've
done
it
an
awesome
job
covering
off
the
topic
and
showing
off
this
so
yeah
so
show
us
how
we
get
a
hold
of
you
and
how
to
try
it.
Thank.
B
A
B
A
try
it
now,
so
essentially,
you
can
just
come
in
and
register,
so
it's
very
easy
to
get
started.
Essentially
all
you
need
to
do
is
there's
a.
We
have
a
console.
You
basically
create
an
account.
We
allow.
We
permit
you
to
get
that
account
and
then
once
you
have
that
all
you
need
to
do
is
bring
up
the
enforcement
technology
on
the
host,
which
can
be
a
Linux
process
or
illuminating
daemon
set
right
indicators
kubernetes.
We
actually
even
generate
the
llamo
files
that
use
deploy
to
deploy
the
daemon
set
in
your
environment.
B
A
Very
cool,
thank
you
very
much
for
taking
the
time
today
to
talk
to
us
about
this,
and
hopefully
we'll
get
to
see
some
of
this
in
action
soon
at
some
of
our
production
and
deployments
and
get
some
more
feedback
from
some
customers
for
you.
And
if
anyone
has
any
questions,
please
do
reach
out.
I
know,
there's
a
number
of
folks
from
Apeco
who
are
in
the
in
the
slack
channel
and
also
available.
You
can
just
ping
them.
I
know
they
have
chat
on
their
website.
So
I
have
seen
that
pop
up
a
few
times.