How to Protect Your CI/CD Pipeline

How to Protect Your CI/CD Pipeline - overview

This session, presented by Teleport’s Allen Vailliencourt at the Application Architecture Summit (January 2021), covers how to protect your CI/CD pipeline so it doesn’t turn into a vulnerability superspreader. CI/CD pipelines bring so much application security good to the development process. They help increase test coverage and reduce human error by automating away toil. But without proper controls, an over-privileged and insufficiently monitored CI/CD pipeline can turn into a vulnerability superspreader. This talk will show you how to manage identity-based access so your CI/CD pipeline stays secure using the open-source solution Teleport and GitHub Actions.

Key topics on How to Protect Your CI/CD Pipeline

• CI/CD pipelines can deliver good app security to development
• Without controls, a CI/CD pipeline can turn into a vulnerability superspreader
• You can achieve best practices and obtain secure access solutions from Teleport and GitHub Actions.
• Teleport leverages impersonation to help secure service accounts and CI/CD systems.
• GitHub Actions makes it easy to automate all your software workflows, now with world-class CI/CD.

Expanding your knowledge on How to Protect Your CI/CD Pipeline

• Teleport Impersonation
• Teleport Server Access
• Teleport Application Access
• Teleport Kubernetes Access
• Teleport Database Access
• Get started with Teleport

Introduction - How to Protect Your CI/CD Pipeline

(The transcript of the session)

Vance: 00:00:00.000 And welcome to the Teleport session for today's Application Architecture Summit, where we'll learn how to protect your CI/CD pipelines and keep them secure. This is a special important topic these days with distributed teams. Our guide for today's session is Allen Vailliencourt, solutions engineer at Teleport. Allen, welcome.

Allen: 00:00:17.892 Thank you. Glad to be here.

Vance: 00:00:19.933 We're glad to have Allen with us here, too. He is one of the geniuses behind Teleport's ability to provide a unified access platform for developers and security professionals. This technology simplifies secure access to servers, applications, and data across all environments. And to his credit, Allen has deep expertise in DevOps, public cloud development, security systems, and administration. And in Allen's session today, it's entitled How to Protect your CI/CD Pipeline So It Doesn't Turn Into a Vulnerability Super Spreader. We all know CI/CD pipelines bring a lot of value to application security and the development process. But without proper controls, an overprivileged and insufficiently monitored CI/CD pipeline can turn into what Allen calls a vulnerability super spreader. So today, Allen's going to explain how to protect your CI/CD pipeline, how to keep it secure. And we'll also get a look at the Teleport solution along with GitHub Actions. So great session with some real good hands-on information. Just a quick note before I give it to Allen, you can download his slides. Just click the big red button under the view area. You've also got some other great, valuable resources and downloads available to you right now just with one click. Take a look at those and ask any questions. We love those too. So just type in the submit-a-question box. So, Allen, with all that, great to have you here. Tell us about how to protect our CI/CD pipelines.

Allen: 00:01:44.079 Well, thank you, Vance. I'm excited to talk about this topic. For a lot of teams and development teams, we get so focused on securing front ends and back ends that a lot of times this middle part gets looked over a good bit. And so that's what we're going to talk about a little bit today. So hopefully after today's webinar, you're going to be a little bit more informed of how we do it, how Teleport can help you along that line. So let's just jump right into it. But first of all, I always like to brag a little bit about my family. I do what I do because I love technology, and I have a family, a wife, and two boys that are growing rapidly that give me the energy and motivation to keep going. Last year, we adopted a little puppy, and she's a little bit bigger now. And so she brings a lot of joy. And of course, being a tech person always on conferences and calls, tend to fidget a lot with my fingers. So a couple of years ago, I jumped into solving speed cubes or Rubik's Cubes. And so I've amassed a little bit of a collection. So I always tell people when you're a technologist, you're living in this world all day long, having something that's tactile and non-screen related is always something fun. So I always try to champion and say, "Hey, pick up a cube. You're never too old to learn how to solve one of those."

Simple, secure access for engineers

Allen: 00:03:04.955 So anyways, let's jump right into it. And so we're going to talk a little bit of Teleport, of what we're doing, what Teleport is, and then we're going to jump right into today's portion about impersonation and protecting that middle layer, that CI/CD piece. So Teleport is, as we define it, is simple, secure access for engineers. Our founders are engineers, and they solved this problem a number of years ago. And so we've been rapidly trying to solve it by providing tools so that engineers, no matter where they live, especially today with everyone working remotely, to be honest, and distributed. Our company is all over the world. That we need to provide easier ways for accessing resources. On top of that, we need to protect those resources. Gone are the days where you're sitting in an office and you have your network team, your firewall, and your security team securing it one piece. With distributed systems and employees all over the world, it makes it a little bit more challenging. And that challenge falls in with this scale, what we call the security versus agility, startups, legacy, some monolithic unicorns, you name the company as they're trying to innovate today, and developers are trying to get products and services out there to better their environment, better their customers lives, and healthcare crisis, you name it. Comes in the security agility piece where devs want to push fast, but security teams want to hold back. And so you strike that balance, and it comes in — really — this tension where we see it manifesting in three years.

Introducing Teleport Access Platform

Allen: 00:04:48.051 Access workflows. Does user A have access to this? Do they need access to this? What is that process of getting that person access to said resources? Credential management, which is huge, right? We've got every website asking for a username and password or public-private key or some sort of token. So how do we manage these secrets and these credentials across all these environments? Then compliance and auditing with things like, as you can see here, FedRAMP, PCI Compliance, HIPAA, SOC 2. There's a huge, huge level of compliance and auditing, and especially as we're — fintech and healthcare, so much data out there that needs to be protected. So companies need to have a way to make sure that their systems and users are in compliance as well as keeping that agility and going along that line. You can see it can be a balance that can sometimes be a little bit challenging to strike. So we do this through Teleport, what we call our Access Platform, which provides access to these resources, whether it's servers, Kubernetes applications, databases, or even desktop access for Windows-based resources that no matter where they live, we're allowing those engineers, security professionals to unify and to protect that while keeping things compliant and audited.

Identity certificates and RBAC

Allen: 00:06:13.431 And we do this through a couple pieces here. We'll go through those quickly. The main one is we're using identity certificates. We're tying into something like Okta or Azure Active Directory or anything that's OIDC or SAML compliant. So you have a source of truth where your users and your groups are stored at. And then we're leveraging certificates. And you're going to hear that a lot as we go through today's presentation about managing that with these certificates. Then we're tying it into RBAC, role-based access control. Anyone in today's development security world understands that role-based access control is critical because instead of just giving blanket permissions to users across the board, or they come on say, "You're an admin just because everyone's an admin," right? That you define these users' roles, you restrict them with specific actions, and you're really granular on how you're managing that with RBAC.

Visibility into access and behavior

Allen: 00:07:15.672 And then we allow visibility into what's happening in your environment. So if you're SSHing into a Linux server, you're doing a queue control exec into a Kubernetes Pod, or you're logging into a database, we get the ability to have session information through our audit log, through session recordings to see what is happening within these environments. And then, of course, you need that point of, "Well, I'm a user, but then I need access to this specific system," because again, we're leveraging role-based access control. And by doing so, we're not giving everyone access to keys to the kingdom. Do all your developers need access to production servers? Probably not. Maybe a certain subset of it. But what if you have the ability to elevate access or grant access on an as-need basis? So that comes in through something like access request. So you can tie it in using what we — industry we call it ChatOps, right? Using chat and operations to kind of see what's happening. Slack, PagerDuty. And we even have a full API that you can build, really, your own custom integrations along that line.

Access requests

Allen: 00:08:31.685 And the cool thing about all of this, we're an open-source project. If you look out on GitHub right now, and we'll have a link here in the slides, you can see where our project lives. We have almost 11,000 stars. It's like 10,800. So we just rounded up here. But it's a fast-growing project, and you can see users that are contributing to it. You can see issues that are being done, the release cadence that our development team and our engineers are putting out. So we're firm believers in open source and the value of it. So that way, as an enterprise or as a company, you're looking at this and being able to know what is happening, what is in the code that I am now dependent upon for securing some of my systems. And of course, being open source, we also have an enterprise version. And this is something where some companies say, "Hey, we need that enterprise-level support." So enterprise brings along a few other options that are not necessarily in our community. Advanced access request, support is pretty much the big tenet there where we have a phenomenal customer success team and a customer support team that does that follow-the-sun model and making sure that support is available for our customers, as well as a cloud-hosted SaaS version of our software. And lastly here, you can see just a few of the companies that are using Teleport today in production all across the world. Here's a couple of their logos. You can go to our website and see a little bit more.

The growing threat to CI/CD pipelines

Allen: 00:10:05.479 All right, so enough of the marketing stuff. Let's jump into the fun stuff, at least in my thoughts here. How to protect your CI/CD pipeline so it doesn't turn into a vulnerability super spreader. End of the day, right, we're surrounded by this pandemic that's been with us for a couple of years. And then you look at software where man-in-the-middle attacks, things start happening, and it becomes critical for companies. So why should you be concerned about your CI/CD? Well, do a quick Google of CI/CD attacks or MITM, man middle attacks. In fact, here's a couple of just high-level articles, one from 2021, still fairly new, the growing threat to CI/CD pipelines. And then even one that just came out weeks ago with NPM where a user had an agenda, someone who basically injected some code in these packages, and then thousands of applications around the world are being affected by this because of what this user injected. And that all falls in that man-in-the-middle kind of supply chain concern that we're talking about. So we want to be able to protect this with something like Teleport.

Teleport Impersonation

Allen: 00:11:21.962 So we're going to use what's called Teleport impersonation. And our definition of it, as I'm going to read it here, says sometimes users need to create short-lived certificates for noninteractive users, for example, CI/CD systems. Your programs interacting with Teleport may need to create their own authentication as well. So Teleport's impersonation allows users and robots to create these short-lived certificates for other users and roles. And that's right off our documentation around Teleport. So you're like, "Okay, that sounds kind of cool. So why do we need this?" Well, hopefully, you've kind of heard it a little bit right now, right? We're trying to reduce that potential of a supply chain attack because if we're leveraging short-lived certificates within our CI/CD and something happens where there is maybe a vulnerability or maybe a potential hack, we can revoke that certificate. We can roll out something new. And then immediately, we're securing our access. Or if a user somehow gets a copy of this certificate, well, guess what? It's going to expire. It only has a short time to live. And that's the key tenet behind some of this. Oh, and behind all of it, Teleport is auditing everything that's happening within this. So from an audit compliance standpoint, we're able to see really what's going on.

Allen: 00:12:46.219 So we leverage this in a couple ways. So instead of using a static username and password, which, if you look at like a Jenkins box or Octopus Deploy, Argo CD, or even GitHub Actions, right, you can use username and passwords, you can use public-private key pairs, both of which have their own concerns and pretty much no expiration. So we're going to get rid of that. We're going to use short-lived certificates, then we're going to create specific and role-limited users for these systems. So again, using RBAC, we're not going to grant this CI/CD keys to the kingdom. We're going to give them very specific and limited information so if there is a potential compromise, the damage vector will be very small because it's limited based on that role. So we're going to impersonate these users when our automation workflow runs. Teleport's going to audit this interaction. And of course, we do not necessarily need to do password rotation because of the use of short-lived certificates.

Creating short-lived certs

Allen: 00:13:47.811 And I'm going to sound like a broken record because I keep mentioning short-lived certificates, and that is really key because that is the tenet behind Teleport and what we're leveraging. Certificates expire. Public-private keys do not. Passwords, although they should, necessarily aren't rotated as often as they should. So today we're going to leverage it using GitHub Actions. So this is right off GitHub's website. So what GitHub Actions is, if you've never used it, it's basically their cloud version of running CI/CD. So it makes it easy to automate world-class CI/CD, build, test deploy. For our purposes today, we're just going to do the CD part, the continuous deploy. I'm not running integration tests, but hopefully this just proves as getting the idea, the picture behind what we're doing with Teleport.

Using GitHub Actions with Teleport

Allen: 00:14:40.843 So let's jump into and look at how we do this with GitHub Actions. First of all, a couple of steps here that we're going to do. We're going to create that CI/CD user role within Teleport itself, and I'll show some examples of how that's done. Then we're going to create that impersonator role, and that's the key role, right, to impersonate this CI/CD user itself. Then we're going to export this and upload it to GitHub Actions. Then we're going to modify our workflow, our GitHub Actions workflow, to take advantage of Teleport impersonation and get things rolling. So let's jump right into these examples. So first off the top, we're going to be creating the CI/CD role and the user itself. Everything within Teleport is in YAML file. So the formatting here is YAML formatted. So as you work with Teleport and you're building out these roles or these users — so if you're familiar with YAML, it's going to be very familiar. It lowers that learning curve for trying to figure it out. So far, as an example here, what that role might look like in your environment. So I've got a role here that's defined GitHub Actions. It allows whoever has this role to log in with an Ubuntu user. We do some auditing and logging, and then I have a maximum session time to live of 720 hours. So basically I took one month, a 30 day, 24 hours a day, and came up with about 720 hours, which is about a month. So instead of having a six-month certificate or one year — in fact, some of you go look at your Jenkins and some of your other systems. How old is that key you're using? How old is that password? If it's more than a couple of months already, we've got an advantage here because we're limiting this role within a certificate that really only lasts for 720 hours.

Allen: 00:16:34.267 Then I'm going to create a user called githubactions, and I'm going to assign them this role. So my user githubactions is assigned the role githubactions as well. So a little note here, if you're familiar with Teleport, you'll notice that in our documentation we talk about a tool called tctl. Basically T control, tctl. It's an admin-level tool. So you could actually — in fact, the better way of doing all of this is using infrastructure as code, build this in your IDE, whether it's Visual Studio code, whether it's Notebook or Notepad or whatever it is that you can build it, store it, and get, and then use something like tctl to apply this to the cluster. But you can also do this from within our web UI as well, which makes it really nice. We'd like to provide options for users along that line.

Creating the impersonator role & user

Allen: 00:17:29.909 So the next thing after we get that done is we're going to create the impersonator role and user. So what I did here, my example is saying I'm using, again, that T control application, adding a user named Allen. So I created a user called myself. And I created a role. I assigned that impersonator role to my user. On the right here, you can see a little bit what this role looks like. So this impersonator role, whoever has it can impersonate the GitHub Actions user and the GitHub Actions role. And then we're limiting their time to live just a little bit less there. So whoever has this is really only going to be able to log in and leverage Teleport for about 10 hours until they need to renew their certifications.

Allen: 00:18:19.031 All right, so moving on. So as we start using this — so we have our user that has this role applied. So we're going to issue a certificate, and the certificate is what we're going to use within GitHub Actions because we need to export it from the cluster itself. So again, I'm logging in as my user with a tsh. I'm doing this from the command line. So I'm logging as my user. I'm pointing to where my cluster is. Authentication local because this is just — from a demo purposes, I have a local user. And then from my command line, I get a little status page from your terminal window. It'll look similar to this, that, "Hey, here's the cluster you're logged in as. Here's your user and which role that you've been assigned." So this user, because they have the impersonator role, it shows what that user is assigned as. On top of that, we can see that it's valid for about 10 hours. So if I stay logged in, you can see that based on my role, I'm only there for about 10 hours or so.

Exporting the certificate

Allen: 00:19:21.394 All right, so I'm logged in. So hopefully you're following along. We've created my user. We created my roles. I have a user that's logged into Teleport impersonating this. So what I need to do next is sign — is export out this certificate that we're going to use in GitHub Actions. So I'm going to use a command called tsh auth sign. So I'm signing as that user githubactions. My output, what I'm going to save the file as, and then what format. Well, we want this in OpenSSH format. We actually have a couple different formats. You can export certificates just depending on what system needs, what kind of requirements, and then a time to live of 720 hours. It's going to export out two files, a GitHub Actions file, and then a certificate. And these are actually part of the OpenSSH protocol. So if you look up OpenSSH and you're dealing with OpenSSH-signed certificates, you'll be able to see that these two are pieces of it. One is the private key. One is the signed certificate. In fact, you can even validate that with just a tool called ssh-keygen, which is part of any Linux or Mac operating system. You can actually input the certificate and then run an output on it, and it will display in your terminal window the details of that certificate and even show you the time to live.

Allen: 00:20:48.515 So as you can see in my output that my time to live is 720 hours because that is the max amount of time that this user github and the role githubactions allows for. So I could actually export this certificate out as, say, 360 hours if I wanted to, 15 days. I could do that. But because I want to set a 30-day certificate, I went ahead and put it to the full amount of time. But you can be flexible on that. So let's say you have a top limit saying up to 720 hours, but maybe we only want certificates valid for 40 hours or something along that line. You could export that. It just would involve a little bit more work because then you're rotating your certificates within those systems a little bit more often.

Attaching cert to GitHub Actions

Allen: 00:21:38.625 Okay, so we've got our certificate saved locally. So now we need to upload and get this as part of our GitHub Actions. So for those familiar with GitHub, you can do this. And again, I'm going to say this from we're using GitHub Actions today, but you can take these and just think in your mind, say, "Hey, we use Jenkins," or "We use Octopus Deploy," or something along that line. You can easily take these ideas what GitHub is using, transfer to GitLab, to Bitbucket, and those different ways of deploying and managing that. But with GitHub, we're using GitHub-related tools. So I'm using GitHub CLI. And so from my command line, I can list any existing secrets that I have, and then I can make a path and point to it. So where I save this cert, where I save this GitHub Actions key, I'm actually going to set it in GitHub. That way I can reference it here in a little bit when we start showing our build. So why do we need this? Well, most CI/CD systems do need a way to have a service account user login in order to deploy software, so if you're deploying to a production server where we're doing it through SFTP or secure copy. So we need a way to actually authenticate and log into those in order to get those artifacts over there. So with GitHub Actions, we're just using short-lived certificates to manage that.

Allen: 00:23:08.405 One caveat. As I mentioned, this is not production ready. This is for a demo for today's webinar. So for some of you that are really security minded like, "Oh, don't do that. Don't do that," please take that into consideration that this is really to illustrate how we leverage impersonation and how you can use it when you have other security processes and code review and things along that line. Please make sure those are part of your security process as well. All right. So now our certificates that we've exported from Teleport have been uploaded into GitHub. So what does it look like? What do we need to do now? Well, if you've played with GitHub Actions in the past, they can create a generic template file as a skeleton file that you can just modify and leverage. So I've got a snippet of it here. We're going to run through a little bit what we're doing because GitHub Actions is really using runner containers or lightweight VMs. I think they're using containers. Spins up a container, copies your repo down, builds it, then deploys. So it doesn't know anything about my end systems. But those secrets that I put in Actions, I want to reference them. So I'm able to set an environment variable for both my certificate as well as my key. That way, when I'm running SCP from within my build, it's going to reference my certificate and key to make sure they're valid. So that's the example that I have showing up right here.

The GitHub Actions .yml

Allen: 00:24:38.095 The second part of my workflow YAML, because there's a number of steps in it, is that you can see the SCP part. I'm using secure copy and I'm proxying through Teleport using my GitHub workspace, which is where my product is, my repository, my index HTML page. And then I'm jumping, using Teleport to manage that because this is a Teleport production server, and I'm copying this over into that server. And then I'm running an echo saying, "Hey, it works." So in summary, we exported a Teleport user certificate. We imported it into GitHub Actions for use in our CI/CD pipeline.

Allen: 00:25:19.221 All right, so all that, let's see it in action and deploy a simple web page. So here on the left, I have my IDE Visual Studio code, and I've got a simple webpage. Over here on the right, I've got GitHub Actions, and I also have the website that I'm going to modify, fully qualified domain name sample generic webpage. So on the left here, we're going to edit some code. We're going to go ahead and delete this paragraph that we don't need. And then we're going to add a little bit more context of, "Hey, this does work. We're deploying it." So I'm a developer, and I'm coding on my local system, making my changes, and then when I'm done, I need to push them up to GitHub. So I make a commit using git commit within my repo, put my commit message, hit submit. It's going to fire it off, and then I'm going to sync. So I'm doing a git push. Here on the right-hand side, you're going to see a workflow kick in here in just a few seconds, basically, because when I make that commit to my repo, the workflow says, "Hey, we've got a GitHub Actions. Let's start building. Let's start compiling the code, and let's do what we're supposed to do." It goes really fast because this is just a lightweight SCP.

Teleport Impersonation in action

Allen: 00:26:44.226 And we can see already that it has connected to my server, my remote server, and it has published my updated web page. I get a green check mark that says, "Hey, we're good to go." So let's refresh, see what happens. I refresh my page and boom — there is my updated page showing what I've done. And of course, Teleport, we can see what's happening here in our Teleport audit logs, which is really super cool. And from there, we have that ability to audit and manage and figure out what's going on within Teleport. So as I go in my Teleport audit and logs of this — because our demo showed a little bit fast there, as I open up and I can look at the details of what happened. So when I open up my SCP upload, you can see that address where it came from, which user I'm impersonating as, what the path is, what the file is. So when you look at that, all this happened automatically, or automagically, right? At least that's the way it looks like. Because I'm a developer just running code, I don't necessarily have access to this production server, but yet our CI/CD system has been set up, so that way when developers can make a push, we run through our workflows, and then we publish our systems and our artifacts or files as needed. And then, of course, we're managing that through Teleport. So we make sure we have a nice audit and compliance trail that goes along with that.

Allen: 00:28:22.414 So now, as we're nearing the end, so where do we begin? Where can you begin even today, as far as getting started? Well, we're open source, so I always tell people is hit GitHub, go out there, look at our repository, join us. We have a community Slack as well. Get involved in some of our discussions, and whether on Slack, which, it's actually fairly active, and even run it today. Because we're open source, you can pull down, you can get started today, you can fire it up in your own environment, whether it's Kubernetes on a VM, even a Docker container. And then I have a link here for impersonation. So you can say, "Hey, I want to tie this into my impersonation, into my CI/CD." So those are a few ways to get started right off the top. So that concludes my presentation today, and I'm going to turn it back over to Vance for any questions.

Vance: 00:29:22.063 Allen, great session. Really terrific. Look at the need to secure our CI/CD pipelines, but also make sure that they are efficient and productive for folks that need to actually do the operations and tasks they need to do to get those apps deployed quickly. Really great session.

Q&A

Allen: 00:29:37.303 Thank you, Vance. It was a pleasure. I love being able to talk about this.

Vance: 00:29:41.071 And I can see why. In fact, you mentioned questions. We have a few. Let's start with a big picture one. Just to put in context the value that Teleport's bringing to dev teams and CI/CD in particular, question here notes, we are using public or private keys or even old-fashioned username and passwords. Talk about some of the deltas that Teleport provides to that kind of environment. I'm sure we have dozens, if not hundreds of folks that have that situation.

Allen: 00:30:08.632 No, that is a great question, Vance, so thank you. And you're right. Enterprises are running CI/CD build systems right now, leveraging what they're comfortable and what they're used to using, which is usernames or passwords and/or public-private keys. Those do not have expiration dates. Public-private keys do not have expiration dates. Username and passwords, typically, unless it's tied into a system that's going to force it to expire, might not have an expiration on that as well. So right off the top, you've got users or public-private keys that if they get compromised, especially a public-private key, then they can take that and go anywhere and have access to that system. And then, of course, you don't have that logging and auditing piece. Whereas if you tie that and say, you know what? Let's get rid of that. Let's use Teleport. Let's use the impersonation features that we just kind of demoed here today, then we're using short-lived certificates. So now if something happens, a compromise, well, guess what? We don't really care because that certificate expires. And on top of that, there are some admin-level roles we can do within Teleport and actually lock out that user. So that way, if they attempt to log in with a compromised credential, Teleport's going to audit that and says, "That user is denied," because we're managing it from the Teleport piece.

Vance: 00:31:34.482 And to some extent, I also get a lot deeper view, if not maybe even in real-time, of some of the activity and the baseline auditing.

Allen: 00:31:44.185 Exactly. As I show that one slide, right, you can see that JSON formatted logging. In fact, I didn't mention this, but Teleport provides these logs in JSON format, and we, in fact, encourage companies to take these logs, forward it to their SIEM of choice, whether it's Splunk, whether it's Datadog, Devo, Elastic. And then you can forward all this audit into your SIEM. And then from there, you can build dashboards, you can build telemetry, you can build reports. So you now have a better insight to what's happening with your supply chain.

Vance: 00:32:20.834 Really great conversation. You mentioned logging a couple of times. Let's go into this question. What happens to logging if a user shuts down a node?

Allen: 00:32:30.284 So if that node shuts down and it's not accessible from Teleport, if it's a Teleport-managed node, it will go offline. So the nodes that are managed by Teleport, they have a heartbeat, and they're talking back to the cluster. So if a user does goes and shuts it down and they're doing it from an SSH or maybe a supply chain, you can look at some of the logging to see what happened. We have the ability to turn on what we call enhanced BPF, Berkeley Packet Filtering logging. So if a user somehow compromises this supply chain and then logs in and runs a shutdown command, we're going to capture that within Teleport's logs.

Vance: 00:33:13.002 That's great. You briefly mentioned your support for Kubernetes. Let's spend a minute talking about that. How deep does your support for Kubernetes users go, and does Teleport support Kubernetes groups?

Allen: 00:33:25.381 Yes, we have very strong support for Kubernetes. In fact, our parent company, Gravitational, their first product actually was a highly opinionated version of Kubernetes, and then they built Teleport to manage and access some of this Kubernetes stuff. So some of the commands I was showing, like T control and our YAML files — for those that are in our audience that are familiar with Kubernetes, you're probably like, "Hey, I recognize the formatting of that YAML file," or "T control sounds like queue control." So all that to say, our Kubernetes access is very robust where you've got users in Kubernetes groups that you can tie into Teleport. So I can say, "Hey, let's give Vance access to his specific namespace, but let's give Allen access to his namespace." So when we use Teleport to log into our Kubernetes clusters, we can only see our specific namespaces. So we can be that granular in our Kubernetes groups as well as using role-based access controls to limit what they can and cannot see. On top of that, from Kubernetes perspective, a big security issue is if somebody has that CUBE config file on their local desktop, they have pretty much access to that Kubernetes cluster wherever. If you're managing your Kubernetes clusters via Teleport, and even through our impersonation, when they're not authenticated Teleport or their certificate expired or they've been locked out, they no longer have access to these Kubernetes clusters. So it's another way to really manage and tighten down access to your Kubernetes resources.

Vance: 00:35:04.028 Really terrific. Really terrific. Allen, in the time we have left, let me just kind of turn to a little bit of kind of a hybrid or maybe even a large enterprise. I know that there's a lot of cloud-native activity going on, but we've got a lot of members that come from large companies, and they have some legacy technology they're looking to leverage. Here's one question. We use security information and event management. Can Teleport logs be sent to SIEM?

Allen: 00:35:28.816 Yes. That is one of the wonderful things about the formatting of how we format our logs as JSON-formatted events is that we make it really easy to export these into your SIEM of choice. We also have an open-source plugin called an event handler plugin that you can run within your cluster that will ingest these logs and forward them to whichever SIEM that you use. So we have users all over the world that are using a variety of SIEM and data logging platforms.

Vance: 00:36:04.959 Really excellent. Really excellent. With that, Allen, I see time has expired. But before you go, let's talk about deployment just quickly. I wonder if you could describe for our attendees the Teleport options for deployment, open source or commercial, or what's the best way to begin to test it themselves for their company?

Allen: 00:36:22.597 Yeah, definitely. Happy to. So a couple of ways, you can go to our website, goteleport.com/downloads, and you can actually download our open source binaries today. You can compile it from source code from GitHub if you would like. And we have a number of guides on our site that walk you through of deployment options. And even on GitHub, we have a couple of Terraform examples as well. So if you're interested from an enterprise side as well, we have a 14-day trial that you can just go to our website and sign up for a free trial and get access immediately to a production-ready Teleport cluster that you can then just start connecting and resources and start working with it right away. The 14-day trial — that is our Teleport Cloud, our SaaS model, where we have users all over the world leveraging it, and we have a full dedicated team. Now, that is only enterprise level. So our SaaS cloud offering is not open source, but for customers that are interested and just want to try it out, that is a quick way to get up and running without having to download the binary and install it yourself.

Conclusion

Vance: 00:37:35.750 Yeah, really important to have both options, I think. Allen Vailliencourt, Solutions Engineer at Teleport, thanks very much for a really great look at a very timely topic here, which is protecting our CI/CD pipelines as folks move to the cloud but also move to get their apps designed and deployed really quickly. Thanks again for your time, and I really enjoyed the Q&A.

Allen: 00:37:57.596 Thank you very much, Vance.

Vance: 00:37:59.193 No, totally. It was our pleasure to have you here, Allen, and so much going on at Teleport. We didn't have room for everything here in the breakout room, so here's a slide that’ll take you to some other great resources at the Teleport website, including some of the material from GitHub that Allen mentioned. Just download Allen's slides with that big red button, and all these links will be live. Thanks again, Allen, and thanks again to our attendees. Really great questions.