Teleport Cloud Demo and Discussion - Overview
Teleport Cloud allows you to secure access to your servers, Kubernetes clusters, and Web applications while leaving the operation of your Unified Access Plane to the experts at Teleport. You can still control access to your compute resources anywhere else in the cloud, plugin approval workflows, and use your choice of SSO identity provider. But now you can get your security deployed faster, and you have peace of mind knowing Teleport is continually patched, monitored, and maintained for you.
This webinar covers:
- Architectural outline of Teleport Cloud
- Demo of the signup experience and visual walk through - When to use Cloud or Self-Hosted
Key Topics on Teleport Cloud Demo and Discussion
- Teleport unifies secure access to servers, Kubernetes clusters, applications, and databases.
- Teleport Unified Access Plane comes in three flavors.
- Teleport Cloud is a hosted, managed Teleport cluster that is currently in preview status but we are allowing limited production deployments
- The preview version of Teleport Cloud is provided free of charge primarily for testing and POC purposes until we commit to a formal SLA.
- You can easily use Teleport Cloud as a central place to manage all of your already existing Teleport clusters.
- Clusters are deployed in a single AWS region in 2 availability zones. AWS guarantees 99.99% of monthly uptime percentage.
- For the first half of 2021, we will be working with auditors to realize the threat modeling and security controls. Once we realize, test and audit the security model, we will start working towards meeting compliance programs such as FedRAMP.
- While Teleport Cloud is designed for engineering teams that require the peace of mind and simplicity of a hosted and managed service, Teleport Self-Hosted is designed for engineering teams that demand the flexibility to run software anywhere, on any infrastructure.
Expanding Your Knowledge on Teleport Cloud Demo and Discussion
Learn More About Teleport Cloud Demo and Discussion
Slides - Teleport Cloud Demo and Discussion
The slides for Teleport Cloud Demo and Discussion are now available
Introduction - Teleport Cloud Demo and Discussion
(The transcript of the session)
Mark: Well, hi, everyone. I think it’s time to — we might as well get started. Welcome to another Teleport webinar. Our webinar topic today is Teleport Cloud. My name is Mark Herring. I’m the CMO here at Teleport. And I’m joined today by Ben Arent, who’s our product manager for Teleport. Ben, welcome to the show.
Ben: Hi, Mark. Thanks for the intro. Let’s kick it off. Hi, everybody. Thanks for joining. Let’s kick off. I’m British — it’s the accent. Lots of accents here at Gravitational. I’m Teleport’s director of product. And during this year, one of the highlights is that we’ve supported at least three companies’ secure system access prior to an IPO. And throughout this webinar, we’ll go through some of the tools and methods that they used to secure machine access prior to getting compliance for the IPO. And also, happy holidays and I hope everyone’s well. This is sort of a unique year. I’m currently in the UK and in quarantine. So if you hear any children running around, that’s the reason why.
Ben: So in today’s content, we are going to just do a quick introduction into the cloud and cloud access and about the Teleport Cloud preview. I’m going to bootstrap a Teleport Cloud instance and add a server to it. I’m going to give a quick Teleport tour highlighting a range of its sort of key features and some of my favorite more advanced features that we have, that I don’t always get a chance to demo. And then I’m going to run through a few case studies. So for people who are new to the Teleport ecosystem, these are kind of case studies for customers who may not necessarily want to run it self-hosted. But there’s many advantages for Teleport’s team running it for them. And lastly, how to get access to the latest release, a few key dates around our security audit, and other monitoring reviews. And then we’ll have a Q&A at the end. So Mark, I believe there’s a Q&A box people can put in and ask questions?
Mark: Yeah. Absolutely. So at the bottom of your screen on Zoom, you should see a little thing that says, Q&A. If you put your questions and answers there, we’ll sort of get to them. Try not to use the chat one. We do try and monitor both, but Q&A’s the easiest one to find out from. And I know I’m going to jump the queue here, Ben — we’re going to keep Q&As to the end — but you did bring up an interesting word here, that the cloud is in preview. What does that mean?
Ben: So it means from now until Q1, we’re onboarding customers to get feedback to improve our Teleport Cloud instance that our Teleport teams runs itself. And there’s a range of sort of additions that we’ve added to make the onboarding very smooth. And so we’re looking to get teams involved who can sort of really streamline the experience and make sure it’s really smooth for the rest of our customers. We have a pretty good SLA, but for customers who have a very strict FedRAMP compliance or maybe PCI, I’d recommend waiting until the end of Q1. Also, if you need a very strict sort of six nines SLA, it’s better to use this time as a POC to sort of try it out and see if it’s a good fit to your team.
Mark: Awesome. Well, tell us more about the cloud then.
What is Teleport Cloud & Why Did We Build It?
Ben: Okay. I’m going to just dive in, so first, the cloud. So I think a range of engineers and team members at Teleport come from a history of the SaaS background, and a bunch of them ceased to work at Rackspace. But this is US East, one of the main data centers. And the cloud, as they say, is just someone else’s computer. And so we’re going to talk about sort of all of these clouds have all sorts of methods to getting access to the infrastructure. And if we take Amazon Web Services, for example, they provide at least three ways of accessing a EC2 instance. So I think there’s this instance, Connect, which is even if you lose an SSH key, you can connect to instances; Session Manager, which provides almost on par capabilities to Teleport. But you still have to go to the IAM process. And you can just use plain old OpenSSH with public-private keys. And we have these multiple options for access.
Ben: But Jeff Goldblum’s saying, “So preoccupied whether or not you could, you didn’t stop to think if you should.” And we hear this quite often from lots of teams moving from pets to cattle. And so teams no longer log in to machines to run updates. They sort of use GitOps and a range of infrastructure for accessing them. So it’s almost 2021. Why are we talking about SSHing and accessing systems? And so I like to bring up this book by Julien that came out this year, Securing DevOps. He’s a security engineer at Mozilla. He sums it up perfectly in his book and he says, while manual operations is frowned upon in DevOps, if you run any system at scale, you need operators and team members to get access. So you might need to diagnose problems on a host or on a Kubernetes server. You might need to retrieve logs. Or you might even need to adjust parameters prior to automation. There’s a range of different scenarios. These could be through either a security incidence, or if you have a very large fleet, there might be some hosts that behave in an odd manner, and you have to do more extensive diagnostics on them. So —
Mark: And Ben, before you — oh. I was going to say — yeah. Before you dive into more of that, maybe if we — I mean, we have a couple of people online who are brand new to Teleport. So yeah, a little overview of Teleport would be awesome.
What is Teleport?
Ben: Yeah. So for the last five years we sort of have provided access for SSH. But in this last year, we’ve really sort of unified access to a range of things. So we call this our Unified Access Plane. And you can think of this as — if we go back to all of the cloud providers, Teleport is the essential place for getting access to all compute and of range of other things. So we started off with server access, and our server access really leveled up the access from public-private keys to short-lived certificates linked to either an SSO provider or a second factor. And this also has a complete audit trail. And then as Kubernetes sort of came aboard, we had teams migrate from server fleets to Kubernetes clusters, and they wanted the same ability to access and audit what people were doing with their Kubernetes clusters.
How Does Teleport Work?
Ben: We also have a big update in Teleport 5.0 which was our last release that goes beyond just kubectl execs. And you can think of kubectl execs as a sort of a SSH sort of root into a pod. And Application Access was another addition recently. We had feedback from customers who had many internal applications or DevOps tools they were running that were open to the public internet, that were kind of unsecure. Actually, the Kubernetes Dashboard is a perfect example of this along with, like, Jenkins. But this can also include internal apps that teams build that they also want to provide a second factor and an audit log for access. And lastly, database access, this is sort of fresh off the press. We’re currently in an alpha stage. And in Q1 we’ll have more information about Teleport for database access. But this brings the same role-based access controls to databases without having to expose them over the internet. And you can also get compliance and auditability too. So —
Mark: But if we start in the cloud, are all those different access: server, Kubernetes, application, those different protocols, are they all in cloud? Or is there one for server, one for Kubernetes? How do we think about that?
How Teleport Cloud Changes How You Use Teleport
Ben: Yeah. So you can think of your Teleport Cloud instance as the Unified Access Plane that you can connect servers, Kubernetes, applications and databases to that, and that’s sort of your central place. And so I’m going to want to do a few case studies later, Mark. But we have customers who migrate from AWS to GCP. And by using Teleport, they sort of unify the access, and it becomes standard across their sort of two cloud providers. And it makes that migration and access much easier.
Mark: Thanks, Ben.
Architecture of Teleport Cloud
Ben: So let’s go into the cloud setup. Here we just have a video of us bootstrapping a cloud instance. On the right-hand side, I have arranged some technical details. We’ve architected Teleport as a single-tenant system that runs on our other product, Gravity. It’s currently deployed within two AWS zones, and we use our high availability DynamoDB and S3 for our session recordings. Through this process you’ll see that I’ll go to a subdomain. But when you sign up you pick your own individual subdomain, and we use TLS certificates, and that’s encrypted. So everything end-to-end, is encrypted. And lastly, it’s monitored and maintained by the Teleport team. So —
Mark: And just wanted to sort of make sure it’s clear for the audience. So get on the preview list we talked about. Once you get access to it, we’re going to give you a link that then kicks that process off. Is that the right way of describing that?
Ben: Yep. That’s right. You’ll get an email. There’s a step prior to this where you just pick your subdomain. It takes about five minutes. We kind of configure this. One of the reasons of using Gravity is we have a lot more network isolation. And so this makes our security position much stronger. So yeah, you can see here I have a range of asteroid-based subdomains for my example environments, but this would be your [inaudible]. It could be, like [inaudible] and then teleport.sh is the domain name for you to access the cluster. So to this quick first demo, I’m going to skip that first bootstrap process. But I’m going to add a host to the Teleport Cloud, view session recordings, and invite a new user, and a quick introduction to RBAC, which is role-based access control.
Teleport Cloud Tour
Demo of Signup Process
Ben: So I have it here. So this is sort of how you’re greeted. The first stage that I sort of skipped here is, I’ve registered a local user, which I’m going to log in as. And when you register that first initial sort of bootstrapped local user, you have to add a second factor. Here, I’m using Google Authenticator to provide a short-lived token, which, I’m just waiting for it to refresh. 743 and now we’re in. So this is sort of the Teleport Unified Access Plane, but there’s currently nothing here. I only have one cluster. I don’t have any servers. I don’t have any applications. It’s a lonely world. It’s just myself. So we’re going to start first by just adding a server. And this is sort of a new addition to Teleport Cloud to make this sort pf onboarding experience much smoother.
Ben: But we provide a very easy batch script to install a new server. And so I have a Ubuntu instance here, which, I’m just going to run it. This is just going to run in the background. It sort autodetects all the distros. Most major distros work, and you can see it’s already installed. It should have registered and here we are. So we’ve connected our first instance into Teleport Cloud. So this makes it very quick to get up and running. I’m going to log in as this root user. And so we’ve gone come from, “This is my local environment where I have a SSH instance machine,” to, “I’m now accessing it with the Teleport UI.” And so I can do things, like htop. You can see I’m almost running out of memory. Let me exit. I can just do echo “hello cloud”.
Ben: And so one of the reasons why I’m just sort of running through a few examples there is, all of this activity that’s happening here is also recorded and captured in Teleport itself for people who’ve sort of used Teleport. So if I come to the audit log, you can see I’ve logged in, and I’ve started a session. All of this information, JSON structured logs that you can send to a SIEM solution. We currently don’t have a native SIEM solution for Teleport Cloud, but we would love to get early feedback from customers if there’s a current stack that customers would like. And we can pipe all these events into sort of a partner or third party. So this provides a lot more detail than you’d get with, let’s say, OpenSSH. But it’s still sort of hard to figure out what’s happening. And so we have this feature, which is our Session Player. And you can think of this as sort of a — this is a full tty output. And you can even copy and paste and sort of like interact with this to figure out what happened during that session. And so that was Teleport Cloud.
Ben: So there I have added an application. So we finished Session Recordings. The last step for the setup is I’m just going to invite a user. So I’m going to invite Mark. You can help me out. So you can invite users with the Create User system. If I sent this to Mark — actually, I’ll even use this in incognito — you will see that Mark would go through a process that would be very similar to myself, that he would have to register, pick a password, and pick a second factor. But this is also not sustained, a very scalable way to add users to Teleport. And so in my next cluster, I’m going to go through sort of — this is just one I set up earlier. So just before I go into the other cluster, I’m going to talk through what we just did.
Ben: So we added a new cloud server, as I like to say, using ClickOps. But we do have our manual installment instructions for adding servers, which is the SIEM addition. So this is probably a good segue. I can go through here. So I’m going to go on my local terminal, log in again, and the CLI also requires a second factor. So now I’m logged into the same cluster, asteroid-moon.teleport.sh. I’m logged in as admin. And this is another new addition that we added in Teleport 5.0. So tctl is our admin tool, and it lets you perform a range of actions that you may not get in the UI. So we have a very fast output of help commands. But let’s say if I do — actually, I’m just going to make this a little bigger for everybody. tctl tokens add — going to add a Kubernetes token. And so you can do a lot of administrative things just using the command line. And then you can also edit some of our resources. I’ll sort of go into that a bit later. And we also have the Terraform plugins so you can very quickly go from a POC from using our wizard to our manual install instructions to fully scripting to make it sort of scalable. I shared a session that started and if you go to events and sessions playback. And I invited Mark as an extra user.
Ben: But we’re going to go a little deeper into RBAC, in my one I made earlier. So let me close the moon and then we go to asteroid-sun. So this server, you can see first, the landing page is different. We’re having everyone going to go through GitHub as an SSO provider. GitHub is actually one of the SSO providers we also provide our open-source community edition, for SAML and OIDC provider such as Active Directory. They are supported in Teleport Cloud, but that’s also in our sort of on-prem Enterprise edition. So I’m going to log in now. And because I was already authenticated with GitHub, I didn’t have to do anything else. I’m now logged in to Teleport. And so this is sort of a prepopulated Teleport cluster, and you can see here I have a range of servers already added. And one thing you can see — that these are all EC2 hosts. This is Google Cloud Compute host. You can add any sort of cloud provider or on-premises host to Teleport Cloud. And I’ve used these labels which you can set manually. But we also have dynamic labels, which can pull in other metadata. So you can put in, let’s say, tags that you’re also using for AWS EC2 instances.
Ben: And here, you can also see that this server has eBPF in our on-session recording. And I’m going to log in to this one to just show another advanced feature of Teleport. And so get my eBPF example. And so this is very — I need to press enter here. So you can see here that I have a string that I’m echoing that’s base64 encoded and then it gets executed. And so I run this. And you can see there’s sort of some output. But this kind of to some degree shows us the limit of the standard tty session recording output. But because this host has our eBPF session recording, the audit log is much more detailed. And so when you come in here, that you see. We have a session network connection. We can see which session commands you run. And so you can see that through that one command that I ran, I made a curl connection to this IP address. And so this can be very helpful if you have a very sensitive host that you want to capture, possibly like an employee exfiltration or some other suspicious sort of activity happening on those hosts.
Ben: So next up in my sort of pre-going cluster, you can see I have another server up here in our cluster switcher. And so this AWS one is actually a cluster that I used for another demo from my last webinar. And this is using our trusted cluster feature. And so this lets you connect multiple Teleport clusters and share trust. This can be within your own environments. Or if you’re an MSP and you support other people’s clusters, you can connect them, and you can also sort of limit access. And so if I come back to asteroid-sun, you can see this cloud instance is the root. And then I have one leaf, but you could have many hundreds of leaf, other clusters. So you can really easily use Teleport Cloud as a central place to manage all of your already existing Teleport clusters.
Ben: Next up, I have application access. Application access was designed to, as I said earlier, secure internal applications and developer tools. I’m going to log in to my last cluster. If you’re more interested, I’d recommend checking my last webinar. I did a really good deep dive. But here you can see, we have these cards that you can log in. I’m logging into Grafana. It’s sort of booting up, and this is sort of an example of a developer tool that provides secure access, and you can only access it using Teleport Cloud.
Mark: Hey, Ben, while that is firing up — want to just remind everyone to use the Q&A feature. Got a couple of questions coming in, but we will take those at the end. Again, just more the little advertorial here of please put questions in the Q&A button. Back to you, Ben.
Ben: Thanks, Mark. That’s good. And then here’s another example of an internal application. This is because they’re a small implementation detail. But for people who are interested, you can see asteroid sun is the name I picked from my cluster. But each application that you add also has its own subdomain. And so this makes it very quick and easy to just use standard URLs to access these applications. And so if I was to access this in an incognito window, it would prompt me to reauthenticate into this cluster, and then it’ll redirect me to that application as it’s booting up. And so yeah, you can see here — oh. Here we are. And so if I — I’m not logged in GitHub in my incognito window, but that would sort of take me to this application, and you can see we’ve used JWT web tokens to log in as myself into this application. So then you could even extend your application to take you to Teleport roles.
Demo: Add A Node, Add a K8s Cluster, Add an App, Admin Vs. User Views
Ben: So it’s probably a good time to dive into roles. I have a range of other users here, but Teleport roles also combine very well with our labeling system that I showed earlier. And so you can create many Teleport roles, and you can sort of limit access based upon role definitions. And so you can label Kubernetes clusters, application, nodes. And this can be very helpful if you wanted to just provide access for engineering to only staging, but you want your DevOps team to access all infrastructure. You can use our role-based access control. Another feature you can limit is sort of what sections get shown up. So you can have a role of an auditor that doesn’t have access to the session recordings or the events or the user list. There’s a lot to sort of unpack here. And if your team’s sort of running into any sort of problems, we can be more than happy to sort of help, sort of create custom roles to sort of solve the problems that you’re running into. And this is the Auth Connector that I showed earlier. It’s sort of GitHub. And you can add, basically, any SSO provider that you have, that either has a OIDC or a SAML connector.
Ben: So next up, diving away from the UI, I’m going to tsh log out because I was logged out into my moon cluster. And I’m going to re-log in to the cluster that I currently have my sort of asteroid-sun. And if you saw quickly there, the CLI we authenticated has logged me back in. And if I do tsh ls, you can see the similar experience. So often we have many engineers who just use the CLI experience for all of their day-to-day work. And so you can do tsh ssh ec2-user, and just pick the hostname. So you don’t have to worry about IP addresses — echo “tsh example”. And then this CLI experience is also sort of monitored and audited in Teleport as well. But I came here to show off our new multiple Kubernetes clusters and some other examples. So Teleport 5.0 lets you add multiple Kubernetes clusters to one Teleport instance. And so here I have a DigitalOcean and two Google GKE clusters.
Ben: I’m going to log in to my cloud demo. And then the experience for anyone who’s using Kubernetes is just the same. So you just use kubectl. And so I could do kubectl get pods. There’s a bit of a quirk. The first couple of times you make it, it catches all your credentials. And you can see I’m running this one — show example here. If I come in here, I’m going to exec into this pod. And so this is sort of — I’ve gone from SSHing into servers into kube exec-ings and just see what’s running here. I see I also have a pod that’s running Nginx, and so I can exit here. And then if we come back into — oh. Let’s exit this, back to my cluster activity. You can see all of the Kubernetes requests and all these other sessions that I did in the terminals have been recorded and captured. And that brings me to the end of my sort of more complete demo.
Ben: So just to do a quick summary, we did a quick introduction to tsh, and also, our tctl administrative tool. I showed how eBPF can sort of provide a X-Ray-type vision into user input for servers you really want to secure. Trusted Clusters — I showed how you could use Trusted Clusters to connect to self-hosted clusters to the cloud because this is also opens up the option for existing customers to take or to use Teleport Cloud as sort of a gateway to all of their other trusted clusters. Application access to custom apps and developer tools, multiple Kubernetes clusters and kubectl, GitHub, and Teleport’s raw base access controls — so just take a quick break.
What About Current Customers?
Ben: I think I kind of covered a lot of this, but this is sort of the network overview. Everything goes through an SSH reverse tunnel. So you can connect service from anywhere. While Teleport Cloud itself is hosted in AWS, you connect from your on-prem or whichever cloud provider you get. And it all goes through the internet. And so we’ve had some interesting examples of customers deploying sort of nodes in sort of interesting areas. Yeah. This is a great example. So we had one customer who was deploying a medical device that had a computer, that needed to run some diagnostic tools, but it went to a range of different hospitals. And one of the problems of deploying this sort of hardware device into all these different hospitals/networks, is that it can be very difficult to open ports in, let’s say, 100 different hospitals. But by using Teleport, they could sort of break through sort of their network firewall, instead of get through the [inaudible], as it were, and easily provide access. And so one of the benefits of using Teleport Cloud is that this sort of company is in the profession of providing sort of top-notch medical devices. They didn’t necessarily want to maintain another piece of infrastructure for access. And so Teleport Cloud sort of offloads that for them.
Ben: And I sort of used this as the example earlier. So if we go back to a Unified Access Plane, Teleport Cloud can make it very easy if you’re going through a cloud migration. And so you don’t have to worry about the difference between sort of IAM rules and GCP custom IAM rules too. You can just use the standard Teleport instance, and you make access very consistent between the two clusters. And you create two Teleport clusters, or you could just create one and use labels to sort of differentiate which each pieces of infrastructure you’re having — and we actually have lots of people who Teleport as sort of the source of truth for inventory. So to learn more, we have this page on our docs site that sort of goes through the status of sort of what’s happening. We have some more information on sort of our roadmap. This is sort of a new addition that we have from the sort of product or the Teleport that we’re publicly leading with our roadmap. So you can see what’s going to be released in our next San Diego release as we sort of implement database access and session termination and access workflows. And —
Teleport Cloud Roadmap
Mark: And I know you’ve mentioned that a little, but that’s a key point for Renee. We had a couple of questions on the Q&A, on when are things going to be available to this? So our whole roadmap now is public. It’s out there under docs in that our upcoming releases tab and then just — I know you covered that quickly. But that’s pretty impressive, right? That’s cool.
Ben: And it also links to our GitHub milestones. We’re an open core company. Any sort of feedback that we get will be in our GitHub repo so it can be very easy to sort of track issues. And that’s sort of one of the reasons that we have this preview release — is that we’re trying to improve it for all of our customers and also improve Teleport itself. A few key dates for Teleport Cloud itself, so we were saying now it’s ready for non-mission critical systems. If you need eight nines of uptime, or you need it for FedRAMP compliance, probably wait until the end of Q1. But if you only occasionally need access to your systems, four nines, three nines, right now is a pretty good time to try Teleport Cloud. We are having a security audit that is starting in January. We have a pretty good breed of going through, at least twice a year, security reviews, that we always sort of help improve our product. But it’s sort of the first time of going through that for software that we’re hosting ourselves. And lastly, we obtained SOC2 this year for our self-hosted Teleport software. But we don’t have it yet for SOC2 because you need to go through a whole range of new tests. But we expect this to get SOC2 compliance in Q2 of 2021, if this is something that’s important to you.
Mark: And obviously, for those of you frantically taking a screenshot of that, well, hey, two things. One, we’ll definitely publish all these slides to SlideShare. So you’ll get that. But the latest and greatest dates, now, will always be up in our documentation site. So if these things move or different features come in and out, you can obviously monitor it there.
Sign Up for the Preview Release
Ben: Yeah. So lastly, the service box, if you go to this URL, there’s a button for cloud to submit your information. This is kind of cheeky, but if you want to skip the line and join this webinar, just drop me an email after this, and I’ll be more than happy to even get you set up today.
Mark: Oh, Ben, I told you not to do that, man. [laughter] Good luck answering emails tonight. Yeah.
Ben: [laughter] Yeah. And so I guess, Mark, this is the time you can see how the questions are coming in.
Mark: Excellent. Q&A, the most favorite part. So again, if you do have questions, put them into the Q&A box there. We’ve got a couple, and I’ll just sort of take them in any order here. You talked a little bit about FedRAMP and when it’s — is it FedRAMP compliant now? Or when is that coming out?
Ben: No. This would likely be after our SOC2 compliance. So expect sort of middle of the year. They’re saying that if we have lots of customers who use our enterprise product, to also make their software FedRAMP compliant. And so it’s actually a great page in our docs. Let me find it — actually, on FedRAMP for SSH and Kubernetes access. And so we have some of our customers run fast tools, and they’ve used Teleport to get their FedRAMP compliance. It gets a bit meta, but we already have all of these controls that even help your company go through that process. And it’s always an interesting process to go through, and we have lots of great experiences getting customers through that FedRAMP journey. So if you’re currently going through that, we’d love to talk to you.
Mark: Awesome. What advice do you have for existing Teleport customers and the cloud? How do the two things work together, or don’t they?
Ben: Yeah. If you’re an existing customer you can reach out to your account rep, and we can get you set up with an instance. It may work for you. It may not. I shared a few examples here in which you could use it, possibly as a centralized gateway. We seized a whole range of sort of infrastructure and setup. Some people really want to run and maintain it themselves, and some people want one less thing to run and maintain. So if you’re more focused on your app than running infrastructure, Teleport Cloud’s probably the ideal solution, and we can help migrate you sort of early next year.
Mark: Excellent. The question is: how do you configure — and sorry about the banging. I’ve got someone doing some work that’s just decided to bring out the hammer. Perfect timing. But the question is: With Teleport Cloud, can you configure where to send the log information?
Ben: Not currently. But we’re kind of collecting feedback about, where would you ideally like to get this log information? So we have process logs, and then we also have the audit events. We would likely partner with sort of a SIEM solution that will ship them to you, so if you have a strong preference, like [inaudible], we would like to collect more information.
Mark: Excellent. Then more of a general availability question in terms of going — so we have it on AWS at the moment. When will it be on GCP and Azure, and how are we thinking of that as a roadmap?
Ben: It’s a great question. As I’ve already kind of gone through this, you can already connect GCP instances or Azure instances to Teleport Cloud. Latency isn’t a huge issue. But if there’s a specific requirement for one cloud or the other or a particular region — I know people who are in, let’s say, Hong Kong AWS region or in China. It can be difficult to get good network access to the US. Just feel free to send us an email at [email protected], and we can sort of architect something, either through our Enterprise product or through Teleport Cloud that will work well for your team.
Mark: Perfect then. Now that we’ve shared this, maybe it gets back to some of the login stuff is, can you bring your own S3 bucket?
Ben: You can’t currently.
Mark: That was an easy answer [laughter].
Ben: But the same with — you can’t bring your own TLS certificates. All the certificates come through Let’s Encrypt. This is kind of the reason for the early access. If people have strong opinions on it, please get in touch.
Mark: Excellent. The other one might be best followed up as a — and so I’ll read you the question. But if it’s best followed up on an email, we can reach out to Tony. But where does the process need to sit that allows access into applications? If public anything, if net application, does there need to be a Teleport node between the net firewall?
Ben: Yeah. So there’s a few ways in which you can run it. Here, I’m trying the Trusted Cluster. So in our sort of example you can — actually, I think I — in our example here you can run Teleport on the host itself and then point this to a local IP address. And then all traffic goes through as a reverse tunnel. And so the only method of getting access is using the Teleport daemon itself. I think there’s a good image in our application access guide or maybe not. I can follow up with this guy, but you don’t necessarily need it. But I mean, if you really want to secure it, that’s the best way to secure it, is that you would run it on an internal IP address and port. And then you’d use Teleport Application Access to forward it to Teleport.
Ben: Yeah. I mean, like all vendors, even if I go back to that initial picture of the cloud, someone can technically walk into your server and get access to it. So you trust cloud providers to some degree. But running the SaaS product — one of the key things that we have sort of implemented is that we’re using Teleport to access Teleport instances. And we have our own approval workflow. So if any engineer needs to access an instance, they need to create a ticket and everything is audited. Hence, we have a very limited amount of access to people’s infrastructure.
Mark: Awesome, so drinking our own champagne, as they might say. Or I think there’s an alternative way of describing it. Last question I have — if there’s any others just drop it into the Q&A — is back more into sort of, I guess, a roadmap. So at the moment, it’s in early access with the preview release. When will it be available as a self-service?
Ben: I think we’re targeting beginning of Q2.
Mark: Perfect. I mean, I think, again, I’d say to go to Teleport docs and look at the roadmap there. And we’ll sort of keep everyone well-informed there.
Ben: Yeah. Also, everything that I’ve shown today is available in both our community open source edition and our Enterprise product. And so you can try all of these features. Nothing is sort of unique to Teleport Cloud itself apart from us running it for you.
Mark: Excellent, Ben. That’s all the questions we have. Definitely want to thank you for your time and for the audience, a couple of housekeeping items. We will put a link to the slides that Ben went through. Obviously, you’ve got the super-secret way of getting hold of Ben now to get ahead of the queue. I don’t know what your boss is going to say. I think he’s on the call. And finally, stay in touch with us. And let us know if you have any questions. But again, thanks a lot, Ben, and enjoy the UK.
Ben: Cheers. Thank you, Mark. Thanks, everyone, for joining today.