 Hello everyone. Hope all of you are doing well. Good morning. Good afternoon and welcome to today's OSS North America Summit session on apps are the new inch. A bit about myself. My name is relax me Sarva. I've been hanging around in the networking industry for almost the last two decades. Most recently working on SDN and cloud technologies. My current role, I had products at that foundry. Very innovative startup, redefining the network paradigm and enabling new programmable constructs for the hyper connected world of applications with its open source initiative called project CT, which we will hear through this session today. Prior to net foundry, I was at a company called Jennifer networks, driving the SDN and cloud solutions with product called contra which was also open source initiative at Jennifer. And that's my Twitter handle. Now, in today's session when I say applications are the new edge. What do I mean by by that. You know, we will review some of the trends that are fueling the edge and cloud trends cloud innovation trends. What is project CT and why should you care about it. I'll talk a little bit about the apps that fit into the need or domain of secure by design applications. We will do a code walkthrough or a demo based on based on the time that we have for the session and we'll end up with Q&A. Now when I say the edge. You know, edge has a different connotations it's mostly a misnomer. You know, I will create a baseline reference on what I mean by the edge in the next slide or two application architectures have evolved from a centralized mainframe based model to a distributed client server model in the last several years and most recently into virtualized and containerized form factors with cloud adoption being on the rise. With the advent of microservices based application architectures, containerization service measures, enterprises are embracing open architectures white box based technologies open source software with 5G and private LT becoming a reality in terms of scaling the notion of connected things to thousands or tens of thousands of devices. There's yet again an evolutionary trend of enterprises embracing digital transformation to re architect modernize their applications, build new industry for auto applications that fuel their businesses processes and things to a magnificent scale that we have never seen before. And it's all centered around cloud and edge computing. Now the AI and ML based technologies with the data learning modules and analytics are further fueling and putting edge at the forefront. Edge I said is a misnomer, the wide variety of definitions. Edge in the context of this presentation is anything that can give us that can span between the end device the application or the sensor that's generating data and the cloud, whether it's private or public modern digital applications, whether it's smart factory floor automation with their VR type capabilities, a smart retail enhance consumer experience with drone based deliveries or contactless deliveries, mainly due to coven 19 or a smart retail market application experience with telemedicine type applications connected vehicles with v2x technologies and smart cities for connected infrastructure. Take any of these applications that are usually frontended by a mobile app, providing an interface into the environment. AI and machine learning data analytics that are responsible for analyzing the data from the sources that are being generated by the devices or the applications of the sensors require extensive compute capacity. In an effort to reduce costs of sending the generated data over to cloud environments and to help increase the intelligence in real time, near real time. The inference portion of the processing workflow is emerging to collocate closer to the device or the application that's generating this data and enable real time data pretreatment filtering and interpretation in the form of an edge platform. Note that the training models themselves are still residing in the cloud, the input data with the edge is sent back to the cloud. Now there are several vendors providing these edge platforms today, Supermicro, Smart Retail Edge, Azure Stack, Edge, Valterra and other vendors are offering these edge platform capabilities. Gartner also predicts that 50% of the enterprise data will be outside of their data centers of cloud environments by 2022. Now how do you securely connect these applications, the data sources, the mobile devices, the users, Edge, cloud on demand, using an internet as the connectivity medium. The traditional networking and security approaches are too heavyweight and expensive to solve these application connectivity needs. Now that's where NetFarmry comes into play with its cloud native networking approach to solve this distributed dynamic programmable connectivity needs across any application, any cloud or Edge. To draw an analogy similar to how one would log into a cloud provider's console to instantiate VMs or containers on demand and tear them down once they are done. In case of NetFarmry, an IT cloud or an OT administrator can spin up global scale networks on demand, programmatically enable access to the distributed endpoints, the applications, the devices across the globe. All that the IT administrator has to do is to log into the NetFarmry NAS console, spin up a global scale private network, which would be ready in the matter of minutes and enroll the identity of the endpoints and the applications or the IoT devices or sensors that need to be part of the overlay. Now based on the identity, trust, context, such as geolocation, NetFarmry would use an authenticate before connect model to orchestrate a zero trust secure overlay an app specific connectivity which is called as an app man, the one that you see as color coded in this slide across these endpoints and in public private cloud or secure global fabric. Now global fabric itself spans across you know hyperscalar environments and private data centers that we own. All we need is internet connectivity and some co application developers. And you know what's unique about this hybrid model is that we support legacy applications that have been returned in in the previous years in legacy environments, as well as modern applications that can benefit with the zero trust approach. We have the endpoint clients cloud gateways across market, several cloud service provider marketplaces. In addition, what's unique about net foundry is that we are enabling app developers to natively embed secure private networking with all before connect identity trust natively into the application itself. No longer one networking to be a barrier to innovate, not security to be an afterthought. How do we go about this how are we enabling this. Let's take a little bit deeper project CT is all about. We never trust anything verify everything before we establish that trust to give a high level block diagram. The network platform has the microservices based SAS implementation that manages the orchestration of the network and enrollment of the edge devices or IoT cloud mobile applications that are connecting and dialing into the fabric. Now under the hoods below the SAS layer is what we call as our open source platform project CT. Yes, that's true that we build our network as a service platform on top of the open source building block that we believe in. And that has the fabric and the edge component to make this a programmable zero trust network experience possible. So the rest of the session, we will focus on the ZD fabric initiative and we'll talk a little bit deeper around what fabric does and edge does and what are the application developers should care about. CT in addition to it being the yummy pasta also means that it's a modern programmable network overlay with associated edge component to be for an application embedded zero trust networking approach. It is written by developers for developers. CT allows app developers to take secure programmable constructs identity and trust and embed natively didn't natively into the application a few lines of code. Five to 10 lines of code and it's available in multiple programming like the libraries and SDKs are available in multiple programming languages. Now, the best mental model to picture CT is as to separate modules the fabric in the edge. If you look at our source code, you would see that these two repositories, the ZD edge and the fabric repositories on our GitHub repo. The fabric. Let's talk about it a little bit further fabric consists of the network controllers the edge routers that are responsible for creating the long haul routing mesh. Plugable transport such as quick transfer TCP to UDP proxy optimizations concept of services routers circuits, tons of functionality that can be extended. The visibility and routing metrics across the data pads for a bunch of extra excellent management software that's really important and an amazing piece of software on its own for delivering open source long haul overlay by itself. Now the edge sits on top of fabric if fabric is the cake edges sort of the icing on the cake. It offers the ease of use. So, you know, the end applications or the endpoints can use the tunnelers the SDKs available multiple programming languages providing that last mile connectivity. So that the device or the app can talk to each other over the fabric based overlay. Now any client that's running the edges DK can host any service or it can be a client to any service. And all that comes down to the policy configuration, the policy engine by itself is extremely powerful extensible can be set up to do automatic roles. Such that when devices appear, they can automatically be enabled for auto enrollment and have access to other services and endpoints within the app fans. The policy configurations also allow you to configure things such as your fencing capabilities where you can restrict the edge routers and the controllers that need to be used in the fabric. A lot of complex systems fail to do this at scale mainly because of the difficulty to manage thousands of devices and their policies in here with Project ZT you can set them up pretty much automatically apply the device apply the policies and the devices when they show up enable connectivity. Revoke isolate access based on any external events triggers by simply modifying the policies same policies. The edge itself, as mentioned is available in multiple programming languages CC sharp Java Portland, Kotova electron go. We're adding many more in the coming weeks. Our customers are in fact helping us extend these SDKs on the basis on the applications that they are building, and they are innovating with us. In addition to the SDKs, which is mainly meant for greenfield applications, we also have pre built application connectors or tunnels of ground field applications that are pre existing in your environment. We also benefit from the zero trust secure connectivity models. In addition, we also have a cycle proxy implementation for Kubernetes environments, as well as a plain old Docker container available in our registries. The app embedded SDK or the app connector, pretty much intercepts the interest of traffic based on the service name or the policy is no mention of IP addresses anywhere. It sends it over the city fabric. The edge and the fabric are the two building blocks, while fabric can exist completely on its own, providing the long haul transport independent of the edge. All of its functionality all of its concerns are of its own can it can pretty much exist as its own entity for all practical purposes delivering the fabric capability. So how the edge uses fabric in the way it does is that it carved out a small space for itself. Call the fabric API layer. And it's an internal code level API that the edge uses to. Ed uses to connect with the fabric components. And that's how the edge and fabric work together in order to deliver the zero trust programmable connectivity models. The fabric has the network controller, the edge routers. The edge componentry comes with the application SDKs or the app connectors or the tunnels that plug into the fabric. And these applications and endpoints that are connecting and dialing into the fabric imagine them at scale with thousands of routers and 10s of thousands of these endpoints applications devices. And that's either a program or a programmable fabric. Theoretically, anybody could come along and start reproducing the edge capability and rewrite the edge using the fabric API's. However, the value is that we have already done this for them. And on top, we have done it securely. And on top of that, we have full lifecycle management of certificates, not just for the initial board of trust, but also for continuous trust with periodic search rotation and maintaining of the certain infrastructure is all handled by ZD. In addition, we provide end to an encryption across the endpoints and the applications that are riding on top of ZD fabric. Since we are a zero trust product and we don't trust, you know, this particular project is all about zero trust and we don't trust anything unless we verify. There's an interesting problem of how do we initiate and bear trust. This means that we would need to put cryptographic software all over the place, configure them properly, manage them properly, including the lifecycle. We are going to manage these entire lifecycle of private and public search keys for the devices. In large scale deployments, we're talking about thousands or millions of endpoints and devices and thousands of routers spread across the globe, across different cloud, hybrid cloud, public, private cloud environments. We would establish trust in these locations. So looking back at this picture, we have the SDK, we have the edge, the routers, the controllers, fabric, working in harmony, providing amazing capabilities on device identity, enrollment of trust, initiating the trust, fabric for long haul communication and end to an encryption, all packaged as a simple solution. When you compare this to a HTTPS type of a session where you're initiating a connection to a website. With a server, site connection is being validated. The server, the website is not validating the client who's originating the connection request. Single side, single side or server side validation mechanism. Whereas with CT, we're talking about with the edge and the fabric components, what we offer is a mutual TLS based third validation and verification, where communication in all directions in both directions is validated, authorized and cryptographically signed using public plus private infrastructure managed by us. Now let's talk about, before I talk about bootstrapping trust, I wanted to mention that the CT controller itself has its own CA. And it is responsible for bootstrapping trust and extending the trust to the routers, the edge routers, and the application edge instances with whichever with the SDKs. Now let's talk about how do you bootstrap trust from the controller to the edge routers and to the applications and to the applications that are built with the SDKs. An administrator who sets up the controller, sets up the controller, the controller comes with a default CA and a server server. Admin requests for creating identity for the unrolling app or device, and it will do the same thing for enrolling a Z router. In this case, the admin then sends the generated Jot token back to the enrolling device that has the SDK component in it. The SDK componentry of the app or the tunnel of parses the Jot token, retrieves the controller server, verifies the Jot signature to ensure it's a valid one and retrieves the CA store from the controller, well known CA store from the controller. At that point, the controller establishes trust with the SDK, however, the SDK establishes trust with the controller, however, the controller has to establish trust with the SDK as a known identity. That's when the app SDK sends and generates a CSR and enrollment request back to the controller and the controller validates the request and returns the sign certificates back to the application endpoint. In addition, all of this being done at scale across millions of distributed applications and devices and across thousands of ZDH routers. The SDK app, the ZDH routers, the ongoing trust it's not just about building that initial trust. The ongoing trust is something that needs to be maintained by periodic set rotation and that required infrastructure is managed by ZD. So, the identity trust into an encryption data flows across the fabric, the smart routing self healing capabilities across the fabric, all of that form the basis of a programmable network fabric, including distributed applications to use the mutual TLS identity trust and encryption constructs. Now, there are additional details on our GitHub page where an important aspect about ZT, the name it got, because of the fact that there is no network connectivity established, no connectivity established, unless the authentication is done across the initiating service on both sides. And the assets, whether it's the edge routers or it's the applications themselves remain dark to the internet, which means that we avoid potential attacks and security hacks that have been on the rise in the recent years with VPN like technologies. Identification and authentication is sort of integrated and baked into the platform offering where you get managed PKI infrastructure with ZD. Now let's talk a little bit about what kind of applications can leverage ZD. Think of smart trading applications where there are remote traders using applications trying to conduct transactions, low latency, high performance transactions that are connected to cloud and edge data centers. Typically, they are using VPN like technologies which are being replaced with a ZD based programmable overlay based connectivity from the app into the cloud and edge data center locations. Smart vehicles, silicon to cloud connectivity where fleet of forklifts are staged with telemetry gateway units built on Delage Gateway boxes, deployed with micron authentic based hardware root of trust. Three applications telemetry app over the top update app and a diagnostic app all built with SDKs with the ZD SDKs. The orchestrate connectivity from the edge appliance to the cloud data center locations for sending periodic updates on how the forklift is performing for predictive maintenance and in all the top updates. In case of malfunctioning, the forklift administrator can log in via the management app man isolate the failure and correct the issue. In this scenario, each application is getting its own private network, and there is no lateral movement in case a potential attack occurs. The next use case is an interesting one with B2X capabilities such as vehicle to infrastructure, vehicle to vehicle where the third party trust needs to be established. In car applications requiring OTA updates on vehicle maintenance or charging in case of electric vehicles charging stations integrating with the vehicle apps. In retail with enhanced customer services contactless delivery, drone based delivery, in store maintenance of the inventory, camera based surveillance, connected warehouse management. All of these applications require zero risk connectivity to the application users and to cloud services that they need access to. Last but not the least, which we will see a demo is the mobile point of sale applications that are being architected for secure MTL is based transactions between the mobile app and the cloud backing. These are few examples, but we are inviting app developers to start exploring this new paradigm of secure by design application innovation. Where do you want to ideally use ZD, you look for application architectures that require private business APN or VPN, you eliminate that with a zero trust ZD based overlay. Opportunities to embed secure by design very low footprint connectivity constructs natively into the app. Applications that require heightened security or less TLS with an MTLS implementation that's managed by ZD, all of that without the enterprise needing to maintain deploy PKI infrastructure it's done by us on behalf of the customer and no hardware deployment is needed. It's complete without a demo and I intended to show two specific demo showcases one with an application that is built within SDK with the ZD SDK written in Java. And the second one is a Windows application that leverages a pre-built a tunnel that's also built on top of our CSD. Go back for a second. So the first demo that we are seeing is a mobile point of sale application where there is a mobile app, the flash app that is enrolled in terms of identity and you know that's written in Java. The identity of that particular application is enrolled into a ZD based system. And the code for the impulse app is as simple as replacing a TCP connect with the ZD unit using the Java SDK libraries that we publish. And as the app executes, you will see that the merchant initiates a sale transaction, the merchant of this particular application is initiating a sale transaction on behalf of a customer. The customer then receives at that point the transaction is initiated and the customer needs to enter their mobile phone number and confirm the purchase amount. And once the purchase amount is submitted, the transaction is initiated over a Net Foundry ZD based overlay. At this point, the customer will receive an OTP code, an OTP code, where in the backend dashboard you could see that a transaction was initiated by a certain merchant for a specific phone number. The OTP code was issued. Once the end customer receives the OTP code, the OTP code 2988 in this case is entered in the mobile app. Then upon submission, the transaction is then confirmed to be submitted to be complete. Now both the transaction initiation and transaction completion are all done as secure MTLS based transactions over a ZD based overlay in this sample application. The source code of this app is available on our GitHub repo. We welcome application developers to take a look at it. You can use it as a boilerplate template as you're exercising or investigating more capabilities with CK. The second application that I wanted to show is one for brownfield apps that are on your Windows environment and you require secure access to those applications via your Windows desktops where you do not have access to rebuild something with the SDKs. What we have done is we have been published something called as app connectors or tunless that are again built on top of the ZD SDKs that we offer. And here is an example. This is done by one of my colleague Jeremy Teller. It's part of our advanced networking team at. Okay, I'm going to set this up here. We are. Let's see we're executing in a Windows sandbox that I just turned on. So everything is nice and clean. Nothing's been configured up. What I'm going to show is we have a service secured by a ZD network. Hello dot ZD so that if you're come here and you don't have ZD access, you just get the regular old 404 error. But if you do have access, you have the identities and the tunnel or running that uses our SDK, you'll be able to access that resource. So first off, I'm going to come in and I'm going to create an identity for the service. While I'm here, I'll double check to make sure we have a service defined. Which we do here. Hello dot ZD on port 80. So now I'll go to identities and sandbox identity. We'll save that. Search for it here. Download that. So I have my downloads folder. Now I'm going to run the ZD installer and we'll do this right from scratch through the prerequisites. You read the ULA and in a moment it'll be installed. Now this is just a Windows C sharp application that uses the CSDK. I will add an identity that I just created downloads. Give it a second to register. I'll turn it on. Of course, I will come and check to make sure hello. Z that there's hello. ZD port 80. And close this down. Yeah, we will come over here and now follow. Now I can access the resource using the Windows SDK and Windows tunneler. Thanks Jeremy. This is a very interesting use case where we are talking about scenario where you have an existing brownfield application that wants to leverage zero trust connectivity models. We have prebuilt the application connectors or the tunnelers. And you should be able to connect those brownfield applications into the zero trust secure fabric environment powered by ZD. And that was a excellent demonstration based on Windows applications. Now we will talk for Q&A. And, you know, I will respond to any questions that might come along the way. Thank you. Hi, this is Shriya. We are open to Q&A right now. I do see some questions posted on how do we handle end to end encryption. We do use RFP 7030 enrollment or security secure transport and end to end encryption between the IOT or the application and points to connect the apps themselves. Yes, there was a problem with this session recording. I think the OSS team will make sure that the recording that would be posted would have the original pieces around the demo and the slides would be made accessible to the audience. So GitHub repo, if you go to HTTPSZT.dev, you will find the URL that I shared during the presentation. It's github.com forward slash open ZT O P E M Z I T I. Please start our repo and please share your thoughts on what you think about this particular open source project and we would like to invite audience to start actively participating and discussing with us in the open source forum. I think those were the questions. Thank you for attending the session again apologize for a few glitches will make sure that the recording does have the end to end slides and the demos that we have shared during this presentation. Thanks a lot.