Thomas Kee: [00:00:07] Thank you. I'm Thomas Kee. I'm an engineer here at Tempered, and I work on cloud and virtualization and Linux things. So I'd like to talk to you a little bit about our Federated Cloud and virtualized solution, as Ludwin mentioned. We use open WRT Linux and we use the same bits in our virtual appliances as we do on our physical appliances. The great thing about that is all the features are there. And everything is available, and we only have one product to develop. The bad thing is working in the cloud, sometimes without a console and a J tag, it's a board bring up situation. Our cloud solutions are pure L3 network-based management, and we have a cloud connector delivered with every Conductor appliance that provides a resource, abstraction, and management layer. And we take over a region, network, sub-networks, security groups, route tables, and images, for Airwall infrastructure deployment. We kind of make it really easy to deploy and manage across all providers and we glue it all together with an API orchestration, trying to find my way over to the cloud providers. And here we have all our provisioning for all the cloud providers available to us. We have AWS...
Thomas Kee: [00:01:44] we have Azure, and we have Google Cloud.
Thomas Kee: [00:01:51] So I'm just going to create myself an Airwall...
Thomas Kee: [00:01:55] in Alibaba Cloud. As Bryan mentioned before we can create a stand-alone Airwall Gateway, we can also launch Windows and Linux platforms and deploy the Airwall agents. I'm going to...
Thomas Kee: [00:02:12] Just launch an Airwall
Thomas Kee: [00:02:15] There's a template already there. So in a previous deployment, we're just going to reuse the template for that deployment. And what the Cloud Connector is doing right now is going out to query for all these resources that we need to manage and deploy the Airwall on. So here we've just returned a name.
Thomas Kee: [00:02:43] On Airwall, you see, we have all sorts of machine types that were pulled from Alibaba, all the different versions of software that you could deploy as an Airwall. And then we have our public subnet. And protected subnet or we're going to deploy or host, we could even create a network from this view.
Delegate: [00:03:09] Do you have to go with a large instance or can you go with a much smaller footprint for the use case?
Thomas Kee: [00:03:13] The image itself really only requires one gig of space for the route file system and maybe a gig of memory and two cores.
Thomas Kee: [00:03:29] So here's my confirmation screen with all the resources that I've asked to configure.
Thomas Kee: [00:03:37] And we're sending the job off to the deployment manager.
Thomas Kee: [00:03:43] So that's going to be busy for a while. I'm going to just tell you what's going on underneath the hood. We've already done that. So when we arrive at a VPC, the customers are...
Thomas Kee: [00:04:00] running a workload through the Internet gateway and to the Internet.
Thomas Kee: [00:04:07] What we do is we decouple that pass to the Internet gateway. We add another public subnet. We hydrate an Airwall and we put a NIC in each one of those subnets.
Thomas Kee: [00:04:26] So what's going on right now in the Alibaba Cloud is we're seeing the step where I sent the Airwall image to the deployment manager. So what's happening right now is that the Airwall is waking up and trying to determine what hypervisor, where it's living and then gets the right drivers loaded up for optimum performance of the disk and the networking cards. Then it's going out to the Using Cloud INIT to talk to the meta data server, to get to the Conductor's address so it can configure itself with the Conductor address and establish a connection to the Conductor. Then the Airwall collects all the instance attributes and sends the capabilities and the cloud meta data to the Conductor, at which time the Conductor has enough information to find the route table that needs to operate on and manage.
Thomas Kee: [00:05:26] So once it's provisioned...
Thomas Kee: [00:05:29] we see that we have a view into the provider, it saves the operator a lot of clicks to just see the most important things about that cloud instance. And what we have here is the cloud attributes and the the protected route table that we would manage. Also, an important thing to manage with the Airwall is the security groups, and to be able to see all the rules that are configured in that security group. So I mentioned that we manage the round table, we use policy enforcement through the management of the protected subnet router table and, we call that feature route injection. So it's disabled, if the operator wants to manage the roundtable themselves, or if you're running as a relay, you don't need the route injection.
Thomas Kee: [00:06:25] If you do want to handle the traffic, we have individual traffic management. Or you can send all the traffic to the Airwall. So here's what it looks like in an AWS route table when we manage the individual routes. It's a 32-bit net mask. So it's one route or per host. And here is the all traffic. All the traffic is sent to the protected-side NIC of the Airwall.
Thomas Kee: [00:07:03] So somebody had a question about the APIs. So the Conductor APIs are...
Thomas Kee: [00:07:08] full-featured; anything that you can do from the UI is available as an API.
Thomas Kee: [00:07:18] The API is ready to integrate into a heterogeneous solution that extends orchestration tasks to any program or script. And most important to this conversation, it extends all our cloud connector abstraction layer to developers.
Delegate: [00:07:34] So I've got a question regarding geo capability. Can I have multiple Airwall Conductors that communicate to each other so I can have them geographically located while still being able to have everyone be able to kind of like, what's the word, federated across each of them so I can manage them as one umbrella basically?
Thomas Kee: [00:07:55] A new feature that we had is whether you're your primary Conductor is in the enterprise closet or out in the cloud. We can squirt out another Conductor in another, ideally in another provider and in a different region. And that's giving you a high-availability solution using the cloud. The final point that I want to make on the conductor API is that we use the open API standard to create and it helps the developers create language bindings for any language platform that they want to use. So this is important in the conversation for the next couple slides. So Airwall for containers; we have two deployment options. One is the Airwall Agent inside the container and we provide tooling to our operators in the form of CentOS, ubuntu and Alpine Docker files.
Thomas Kee: [00:08:56] The other way to deploy the Airwall is as a V switch on the host. So this is what that might look like.
Thomas Kee: [00:09:05] So in the first scenario, there's a container in each one. I mean, there's an Airwall Agent, a Linux agent inside the container. And then on the right-hand side, we're shimming in between the Docker networking and the physical ethernet as like a top of rack switch. But we also believe using our name spaces, we could commandeer the Docker networking and put the virtual interfaces into the Airwall and manage East-West traffic on the container.
Delegate: [00:09:42] So today, we've got agents for Windows and Mac OS and Android, and iOS, do you have support or are you building support for Chromebooks or devices along those lines?
[00:09:55] I'm sure that's possible. We use it. We can we can make that happen, although we don't have a solution for that right now.
Bryan Skene: [00:10:00] So we can, right? I'm going to jump in for a second - just real quick is; you would think that would be the case. But since we run Android and all those other systems. But there is some - we haven't quite - Chromebook has some things locked down and we haven't figured out how to break through those yet, but we'll get there.
Thomas Kee: [00:10:27] Thanks.
Thomas Kee: [00:10:32] So Airwall for Kubernetes. We don't have a shipping solution for Kubernetes right now, but we're working on it; I thought I would share some of the ideas that we have. So what we want to do is attach work pod workload's to an overlay and include them with our physical and other virtual devices. So what we're thinking about doing is writing a Container Network interface. And as you probably already know, the container networking interface sets the policy to the pods, creates a network namespace and configures namespaces is with interface names and IP addresses and Macs and gateways and bridge names. So we would also utilize and integrate with Kube Admin the Airwall Conductor API. So for the things that the Kube Admin wanted to do with Kubernetes, we just let him do it and then anything that we wanted to manage for networking and security, we would use the Airwall Conductor API to perform those tasks. Does that make sense?
Thomas Kee: [00:11:44] Okay, maybe we should check on our Alibaba Airwall deployment. It looks like it's finished.
Thomas Kee: [00:11:59] So, let's give it a license. So I'm granting a license to this Airwall.
Thomas Kee: [00:12:19] And then. I wanted to find...
Delegate: [00:12:26] Speaking of licensing, how would I license an air gapped device that doesn't connect to the network at all. But I need to pre connect it, or is there like, you know, a USB key or something like a floppy?
Thomas Kee: [00:12:37] Exactly right. I'm not familiar with the process, but there is a USB key that has the licensing on it.
Thomas Kee: [00:12:47] And so here's my Airwall.
Thomas Kee: [00:12:55] I can manage it.
Thomas Kee: [00:13:00] And now this Airwall is ready to protect clients.