[MUSIC]
SEAN DASTOURI: Hi, my name is Sean Dastouri.
I'm a Senior Cloud Architect on F5.
I'm here with my colleague
Kevin Reynolds and we're here to talk about
deploying and protecting your apps and API
using F5 Distributed Cloud. Lets get started.
Technical challenges for delivery
application in the Cloud.
These are due to complex coordination
between the technology and
consistencies between Teams and across environments.
Automation is also challenging.
That is because stitching multiple environments,
flaring networking, security and
apps at scale it can be quite difficult.
There are also security difficulties that is due to
multiple attack surfaces and
sophistication of bad actors.
Monitoring of a silo telemetry
trapping disjointed systems and
environments can also be a challenge.
Let's see how F5 solves this.
F5 Distributed Cloud is a SaaS offering.
It solves these problems by allowing
to collaborate across Teams
with a centralized SaaS console to
simplify planning and streamline execution.
It helps automate network configs and
security deployment to reduce
effort errors and gap in coverage.
In addition, it offers advanced security.
These help to filter out bad traffic
before it hits customer networks
and keeps them stay up to date.
It also allows for visibility.
Visibility of networking, security,
and application performance and is
Cloud agnostic as far as this exportable.
Let's talk about F5 Distributed Cloud
from an infrastructure perspective.
F5 Distributed Cloud is a platform.
It's not a group of widgets that are customers stitched.
We are the Cloud the platform and the global network
is designed to manage
exactly like a Public Cloud Provider.
There's a centralized control plane.
This runs in our global network,
and as a control plane for everything,
we're not reliant on any other Cloud provider for this.
If we look at it,
because this is our network,
it helps us connect Public Cloud to
Private Cloud or the
telco edges or even enterprise edges.
Regardless of where your application is,
your application can use
our back network and
access is services regardless of where they are.
Next, let's jump into a demo.
Kevin's going to give us a demo of
F5 Distributed Cloud as less
as is features and services. Kevin.
KEVIN REYNOLDS: Thank you, Sean.
In this demo, we're going to build,
observe, and secure
small API application on
the F5 Distributed Cloud platform.
In the first section, we'll build the application.
Our application is a simple microservice application
with the web front end hosted on GitHub.
The repository will be linked
in the notes after the demo.
The application flow is quite simple.
There's a web front end accessing
a sentence microservice,
the sentence microservice then accesses
a handful of secondary microservices to
build individual components of
a sentence and there's also
a background service for the web front end.
We'll build the containers using
GitHub actions and then
we'll publish the containers to Azure Container Registry.
We'll host the application on what
XC calls Virtual Kubernetes.
Virtual Kubernetes clusters are made up of
one or more customer or regional edges.
Here we have customer edges
located in three different CSPs.
We'll use the one located in Azure for this demo.
Think of a Virtual Kubernetes cluster as
a managed names pace distributed
among multiple customer sites.
In this case, we've associated the Azure site.
Let's grab a cube config,
and now we're ready to deploy.
In this demo, we're using XC to host our app.
But the platform can easily
discover third-party services using
DNS HashiCorp Consul or the Kubernetes API.
We'll use the cube config we grabbed
earlier to deploy our application.
The Virtual Kubernetes interface is
compliant with standard Kurbernetes tools.
Let's verify that our app is running.
Here we can see our deployments,
our services,
and the pods that make up our microservice.
Now that our app is running in our VGG aids cluster,
we need to advertise the app outside of the cluster.
Let's create an origin pool
that points to the front end service for
the application and let's
create a health check that
checks the status of our service.
Next, let's create an HTTP load balancer that exposes
our application to the Internet. Let's give it a name.
Assigned an FQDN in a domain
that's managed by F5 Distributed Cloud.
Let's have Distributed Cloud
generate a certificate for us.
Let's assign the origin pool we created earlier.
We'll tell XC that we want to do
API Discovery on this load balancer,
and finally, we'll tell XC that we want
to advertise this load balancer on the Internet.
When ready, this load balancer will be advertised out
of all of the regional edges using any cast.
Let's wait for the certificate.
Now, we can access the API as well as the web front end.
Our build is complete. In the second section,
we'll observe the application.
Now that our application is advertised on the Internet,
let's take a view of how traffic is hitting our site.
Here you can see Internet traffic
ingressing several regional edges.
Reaching Azure app stack,
which is hosting our application.
Here in the HTTP Dashboard,
we can start to get a feel for Layer
7 metrics of our application.
Latency, browser type, where our clients are located.
Top URLs, area codes.
We can use the dashboard to view
this data across various time periods.
We can also go
much more granular by
looking at sampled HTTP requests.
Here we can view a derived service graph of
how our individual microservices
are talking to each other.
You can see that this closely
approximates the API design.
Recall that we told the HTTP load balancer
to do API Discovery.
Here's a visual representation of
the API spec learned from traffic.
Here we can download the open API spec file.
You can find the XC-generated spec file as well as
a manual spec file in the repo to compare them.
In the third section,
we'll secure the application.
Let's upload a spec file that doesn't
include one of our API endpoints.
In this case, it's the colors endpoint.
We'll then associate that API definition
with our HTTP load balancer.
Now instead of our derived spec,
we can see live traffic as compared to our uploaded spec.
Here's the API endpoint we removed.
From here, we can easily create
an API protection rule to drop
traffic to our shadow endpoint.
The request is now blocked.
API protection will also identify
PII in your requests by endpoint.
The XC platform allows for
rapid deployment of a simple and effective WAAP policy.
In this example, we'll simply take the default.
We can configure a user identification policy
to tell the platform how to identify our users.
Once we associate the user policy
with our HTTP load balancer,
the platform can determine which users are
malicious using behavioral analysis.
With this suite of API Protection Services
and performance dashboards,
we can generate meaningful insights into
the performance and traffic against our web application.
Here we can see a roll-up security view of
our applications traffic since
deploying these additional security features.
Here we'll drill down into
the HTTP load balancer dashboard.
Notice the security events have increased
dramatically since applying the WAAP policy.
A dashboard provides us
additional data on ongoing attacks.
The system has detected several malicious users.
We can mitigate them from here or at the policy level.
Here's a view of the geolocation of our malicious users.
The default WAAP policy comes with F5 threat campaigns.
Threat campaigns are curated by
the F5 sock and target ongoing global attacks.
Remember that the F5 distributed Cloud dashboard provides
granular security in HTTP request event information.
These events can be streamed from the console
for customer analytics or other purposes.
To summarize, we showed how easy it is to build,
discover, and advertise an application
on the XC platform.
We then showed the console's
various views of the application
from the global Ingress perspective
to HTTP request events,
the discovered API spec and a
service graph of how
the microservices talk to each other.
Finally, we secured the app by
discovering a shadow API in
building an API protection policy,
detect a malicious users and
built a simple but effective WAAP policy.
Thanks for attending everyone.
SEAN DASTOURI: Throughout
the end of the presentation.
At this time, I want to
share some useful links with you guys.
To learn more about F5's Distributed Cloud,
you can go to f5.com/Cloud,
or you can check out the platform overview link
that talks about the features of the solution.
If you are interested in trying
out the demo that Kevin presented,
you can go to F5 DevCentral
on GitHub and check out the MSBuild demo.
As always, if you have any questions
about the Distributed Cloud or any other F5 offering,
you can e-mail us at azureteam@f5.com.
I'd like to thank you for your time today,
and we look forward to talking to
you guys in future presentations. Thank you.