>> Hello and thank you for joining this session.
My name is Phil Gibson a
Program Manager here at Microsoft.
Today, we're going to be
talking about Open Service Mesh,
a lightweight and extensible,
Cloud-native service mesh that is built on
the following core principles of being simple,
to understand and contribute to,
effortless to install, maintain, and operate,
painless to troubleshoot,
abd finally, easy to configure via the SMI specification.
In this session, we're going to showcase
some demos with techniques you can
use with OSM to strengthen
the security posture of workloads
running in Kubernetes such as mTLS validation,
Traffic Access Policies,
OPA Authorization Policies,
and Egress Access Policies.
With mTLS one question we always get is,
Hey, how do I know the service mesh is providing mTLS?
This is a fair question.
Let's set up a simple package capture
so that we can see what
HTTP data is viewable before and after OSM is installed.
Let's first take a look at
our pods and you'll see that we have
the bookstore application running and
OSM is deployed using the AKS add-on.
We'll get the pod name of all the bookstore
App Services and next we'll
query to get the pods IPs
of all those services and output them.
Using the case snuff project,
we'll deploy a privileged parts and start sniffing
the HTTP traffic on the bookstore TCP port.
You'll notice the good traffic is originating from
the actual IP of
the book buyer and is destined to the bookstore.
Next, we'll on-board the bookstore applications to OSM
and restart the deployments for
the envoys' sidecar injection.
We'll then re-query to get
both the new pod names and IP addresses.
Just to double-check, we'll
take a look at the book by a pod and see it
has a ready state of two of
two with the inclusion of the envoys' sidecar.
We'll now restart the capture.
What you'll notice is the gate traffic is no
longer originating from the actual pod IP,
but the loop back addresses within the pod.
Next, let's look at Traffic access.
We'll take a look at our pods again,
and we're still working with
the bookstore application deploy.
We'll list out the namespaces managed by
OSM and check for the envoys' sidecar in the pod.
Next, we'll take a look at the current permissive mode
policy setting and that it is enable.
We'll then check the logs of
the book buyer and see if it's able to reach
the bookstore and if it is
successfully communicating through envoy.
We'll turn permissive mode off or to false and recheck
the logs of the book buyer and see if they
can no longer communicate to the bookstore.
We'll now deploy specific traffic access policy,
allowing the book buyer to communicate to the bookstore.
Next, we'll deploy the Book Thief service
that is attempting to contact the bookstore.
Looking at the book Thief logs,
it cannot contact the bookstore
without an explicit access policy.
We'll update the existing policy to allow
the Book Thief to communicate to the bookstore.
Now, the book Thief can
successfully communicate to the bookstore.
Next, let's talk about using
an external authorization provider,
such as using the open policy agent project.
Checking the logs, the book buyer is
still able to contact the bookstore.
We'll now sit up and deploy
the open policy agent to integrate with OSM.
We'll need to edit the OSM Mesh Config with
the OPA endpoint and
configuration by adding some necessary attributes.
If we check the book buyer logs we'll see OPA is denying
communication to the bookstore
even though OSM has a traffic access policy.
If we look at the OPA logs,
you'll see we have a process rule decision
id with a result set to false,
prohibiting the traffic access.
We'll now disable the OPA policy rule
and restart the OPA pod to take effect.
Looking at both the book buyer logs and OPA logs,
we can now see successful communication
with the rural result being true.
Finally, let's talk about the use
of Egress Policies in OSM.
If we take a look at the global
Egress Policy is set to true,
allowing all pods that communicate outside the cluster.
We can test this out, deploying a curl client to
access the httpbin.org endpoint.
We'll enter the curl pod to issue
the curl command and see were
successful in accessing the external endpoint.
Next, we'll disable the global Egress Policy and see if
the curl client can still access the external endpoint.
The curl client can no longer access
any endpoint outside the cluster.
We'll now configure a fine-grain Egress Policy to allow
specifically the curl client
to access the external endpoint.
But no other pods will have
external access outside the cluster.
If we check the curl client again,
you'll see it has explicitly been
allowed to access the external endpoint.
We'll now delete the fine-grain Egress rule
to prohibit external cluster access.
Again, thank you for your time and
we really hope you enjoyed this session.
Hopefully, you saw some new OSM features and techniques
that you can go and configure to make
your cluster even more secure.
If you haven't done so already,
please visit the openservicemesh.io page for
the latest news and documentation around OSM.
As well as visiting
the Azure Kubernetes Service documentation
for setting up the AKS OSM add-on.