 Thank you so much. Thank you all for joining today in beautiful Detroit. So today we're going to talk about why machines deserve rights, rethinking automated infrastructure access with open source teleport machine ID. So this is what my terminal looked like at an internship I did many years ago. We had this command. We had this whole file living there called secrets.txt. When we open that up, we get these. Some long-lived credentials that our team used to access automated worker nodes that would frequently break. These lived in AWS, and we had them stored in a password vault, but because of the frequency we needed to access them, a bunch of people on the team just added them to local files on their machine. And this was a terrible, terrible, but common practice. And this is still a problem today. One in four employees still have access to old passwords. And 41.7% of employees admitted to having shared workplace passwords, long-lived credentials, AWS keys, SSH keys, et cetera. And this brings it to a security breach. Every security breach has two things in common, a human error for an initial infiltration and attempt to pivot to maximize the blast radius. Human error. Six million of these credentials were leaked in 2021. This is according to a Git Guardian study that they did. These types of secrets that were committed were Google Cloud keys, AWS IAM, Azure API keys, join tokens. That's a two times increase since 2020. And this is because more and more companies are scaling with their cloud infrastructure, thus leading to more and more of these secrets and more of these leaks. And you might say, but we're not open source, so we'll never do that. Well, 85% of these corporate leaks came from developers' personal repos. They would fork the repo, and it was public, and then they would merge it back in once they were done with the PR. The next step is to maximize the blast radius. You get into a Slack workplace. You get access to a server. Get into a server. You're going to escalate those privileges. From there, do what you want, and then profit. 50-50, your results may vary. You'll either be on the beach or someplace a little bit less nice. So some more numbers real quick. 26.8 million active software developers. There's supposedly 45 million by 2030. There's around 8,000 data centers in the world with 50,000 physical servers per center. This varies widely depending on the size, but this is the average. 400 million of those physical servers, which means billions of virtual servers, trillions of containers. The numbers are incalculable. How many virtual environments there are open to attack? The attack surface is immense. And all of these virtual servers, all of these physical servers, are all running software written by humans. Humans who make mistakes. The problems with machine access. People make mistakes writing code. A misconfigured file here or there is the difference between a secure setup and an embarrassing hack. Access problems are not limited to human developers. We need to stop thinking like this. Machine to machine communication operates on outdated security principles. Security principles such as static credentials, SSH keys, API keys, shared Cres when keys are used by different services, and perimeter security. Only the network boundary is protected. A VPN is simply not good enough anymore. And we also have siloed access policies for humans versus machine access. So what can we do? Treat machines the same way that you treat your developers. Give them rights. Provide each piece of automation with an identity, from a microservice to a VM to any worker node in your environment. They should have an identity exactly like your human workers do. And eliminate shared credentials entirely. Every machine, every automated service, every node, should have its very own way of accessing the resources it needs to. Replace them with short-lived certificates. This way that there's no cred to lose. And enforce best practices by default. So this eliminates the need for these costly and expensive configurations, where it takes hours and hours to make sure you get it right. And a missed comma here or there, or an configured service account, is going to wind up in trouble. And tear down those access silos. So you have to think about the way you handle access for your machines with the same care that you do for your developers to minimize the blast radius. Say worst case scenario, one of those machines is compromised, you have to be able to eliminate from your network immediately without letting it be the skipping point to the rest of your infrastructure. And keep it simple. The most secure solution also has to be the easiest. This is what we saw at the beginning, where those credentials were ended up saved to these people's workstations. It's because it cut down on developer time. Accessing these creds through some vault ended up costing time and was very annoying. So people circumvent your security methods if you let them, if it's more complicated. So this brings us to open source teleport machine ID. Machine to machine access. So what open source teleport does is it handles four key pillars of access. Authentication, connectivity, and audit. Authentication. So for every service, for every node, you generate an identity in the form of a short lived X509 certificate for the microservice and tie that identity to a role managed by teleport. So teleport has its own concept of RBAC that you can assign every machine directly to. So you can share roles while at the same time maintaining that, you know, maintaining that accountability for these machines. Authorization. You need to be automatically able to approve or deny access requests to a range of resources like servers, databases, Kubernetes clusters, microservices, and CI CD systems. And connectivity. We're going to come back to this diagram in a second. But it also needs to handle the connection. It needs to establish a connection between the microservice and the requested resources using a reverse proxy tunnel from the teleport server to the resource. This communication is all encrypted and secure, eliminating the need for VPNs or, you know, traditional bastion hosts and the like. And then audit. Extremely important for any compliance and any standard you're trying to reach, any security standard, you need accountability and you need to be able to review all of the actions that were taken by both your human workers and your machines. So this is kind of the high-level architecture. This is an example for teleport configured with Ansible. And so what you have is this orange teleport cluster over, well, I guess you can't see my cursor, but this orange teleport cluster that has two parts. It has an off and a proxy service. The proxy service handles all of the traffic inside and out of the cluster. And then the off is a separate service that handles your logging. It handles your authentication and handling all those RBAC roles. Then you have this Ansible control node, and this is a separate node in your cloud. And so when you create a new node or create a new worker, you're going to onboard that to the teleport cluster. Once that teleport, you can do this in two ways. You can do this with either an ephemeral token or a dynamic join token like an AWS IM. And once you do that, then the machine will refresh its credentials every 20 minutes, or that's configurable. You can set it every five minutes, every 30, every hour. That way, there's no long-lived credentials, and there's no secrets that can be leaked. This, then, will go through the teleport proxy and access your host VM. In this case, this is a VM hosting a Kubernetes cluster. From there, you'll use the SSH protocols to actually run kubectl commands directly on the VM from your worker node. And you can do this in another way as well, where you can access the kubectl config directly through machine ID. It'll actually populate the kubectl config with the machine's RBAC roles baked right in. And then you can just run the kubectl commands from the node itself without having to go through Ansible or any SSH. So let's see it in action. This is going to be interesting. Live demos. Let's see if I can type on the screen. Let's get rid of this. Close. Perfect. No, email. Bad. Get rid of this. OK. OK. We can see this. I'm sorry. Oh, OK. All right. So let's begin. So what we're going to do today is we're going to see both of those examples from the two architecture diagrams I showed you. And let's see. Can I make this bigger? Ooh. OK. Can everyone see this OK? Or should I try to make it bigger? Do something? Oh, now you can't see the edge? OK. Let's just do this instead. No, I didn't do that. OK. Can you see this? No. Yes, perfect. So we're going to have three windows here, three terminals. We're going to have our Ansible control node. We're going to have our Kate's host here. And we're going to have our teleport host. So first, what we're going to do is we're going to create our role for our bot. And this is the role that teleport is going to use when it's assigning that role to the machine. And so let's go ahead and log in to our cluster. This uses GitHub to authenticate as an SSO. And we're going to log into our teleport cluster. So we're logged in. Now we're going to actually SSH onto our teleport host. Perfect. So now we are in our teleport host. So now what we're going to do is we are going to create our role that our machine is going to use. So we're going to go ahead and this role looks like this. We have our name, the machine ID cube demo. This is going to be the name of, this is so tiny. Oh my gosh. Okay. So we're going to have our name here, this machine ID cube demo, this is going to be the name of our role. And then we're going to give it examples. We're going to give it Kubernetes access. And we're going to assign it the Kubernetes user Alice. And so let's go ahead and make our role here. Great. So we got our role now. And next we're going to go onto our Kubernetes host. And we're going to create a Kubernetes role that we're going to mirror with our teleport role. Again, very small. Great. Now we have our Kubernetes role. And then we're going to create the role binding, of course. Got that. And then we're going to go back into our teleport control node here, our teleport host. And we are going to actually onboard this bot into our cluster. So we're going to run this command. T-Cuttle is a CLI tool that allows you to interact with the teleport cluster. And we're going to go ahead and add our cube demo bot with the roles of machine ID, cube demo, which is the role we just created, and another access role that we'll use for our SSH. Perfect. So we have this role. And we have now this token, this bot token here. This is what we're going to use. This is only valid for 59 minutes. We're going to use it to onboard our bot to the teleport cluster. And like I said, there's two ways of doing this. You could also use an AWS dynamic token as well. Perfect. So on the Ansible node here, we're going to open up this tbot config here. Sorry, got a SSH onto our Ansible node first. I love live demos. Perfect. We're in our Ansible node. So now we can do our pseudo vim at Ctbot.yaml. And this is what we're actually going to use to configure our tbot service, which is going to do the credential refreshing. So we're going to take this token. We're going to swap it out for the token that we had before that we got from our teleport host. So we're going to give it this token. And this is what we're going to use to onboard our bot. So next, we're going to actually initialize this bot. And so this is going to take in our config file. We specify the directory that we want all of our credentials to be written to disk. So this is the directory that all of our SSH config and our kube config, it's all going to be written there and refreshed at a regular rate. We specify the bot user. These are the Linux users. And then the reader user, which is over here, which is going to be the user that our service is going to be imitating. Great. So now we have this. So if we go in here, we can see all of these files that were created. All of this directory is just generated. And all of these files right now are completely blank. And what our tbot service is going to do is it's actually going to instantiate those files with the credentials from the teleport host. Great. So now we're going to create a service using system D to actually run the tbot service in the background. And it's going to look like this. It's pretty simple. And this is going to tell our system D to start up the teleport tbot service. And then we can start refreshing those credentials. So this looks good. We're going to go ahead and start up that service using system cuddle start machine ID demo. And let's check the status. OK. So we can see that I ignore this error. That's fine. We're successfully renew the impersonated certificates. We persisted the new certificates to disk. And we're starting to watch for the CA rotations. So this will persist every 20 minutes. And let's take a look again now at our files that we had. So if we go back into our directory that we specified earlier, let's go into here. And we can take a look at some of these files. So now if we cat our kube config yaml, we actually see that we have a whole kube config. And this was generated from the teleport host. And so if we export our kube config here to this opt machine ID kube demo, now we can actually interact with our cluster. Whoops, kube config. There we go. And now we can actually interact with our cluster. From the worker node, all going through the teleport proxy service. And we can go into and actually check it out. We have a web view here. And we sign in with GitHub. And we can see, if we go into our audit log, we can see all of the activities that we were just doing. So we can see that the Kubernetes request, we can see all the metadata from here. All of this can be fully fed into anomaly detection tools or other log aggregators. And we can see our active sessions here. So we see that we're logged into Ansible. We see that we're logged into the control node. And we can see our session recordings as well. So all of the SSH sessions are actually going to be recorded here if this would load. And then you can actually play them back. And these aren't actually videos. They're just a collection of commands that will run. Perfect. And so the last thing we're going to do is we're going to show the Ansible example. So in our Ansible node here, we're going to look at our Ansible config and see that our SSHRs are actually just set to our machine ID directory where we get those SSH configs that are refreshed on a regular rate. So this way, in the past, what you would do is you'd manage SSH keys, which were long lived and become a pain, both for rotation and just for security vulnerabilities. Once those keys were leaked, they're out there. But with the teleports machine ID, these are refreshed every 20 minutes, on whatever cadence you want, making it much more secure and easier to deal with. So we have this. So now, if we go into our other directory, we go into our demo folder here. And we can try to actually run our playbook here. And what this playbook is going to do is that it is going to actually run cube-cuddle commands on the SSH node that's hosting the Kubernetes service. Perfect. So we just have to change our key permissions here for Ansible. And then we should be able to run Ansible playbook and playbook.yaml. Ansible playbook.yaml. And so what we should see here is that this Ansible control node is going to copy. Nope, that is not correct. OK, that's fine. So we're going to change this permission again, cube demo. And now we should see. Perfect. So now what the Ansible control node is going to do is it's going to access our Kubernetes host. It is going to upload the pod.yaml and deployment.yaml configurations that we have written here. And it's actually going to create a pod and create a deployment on the Kubernetes cluster. And we see that the pod nginx was created. And we see that the nginx deployment was created. So if we actually say cube-cuddle get pod dash name namespace equals demo namespace. Let's see where these goes. So we see our nginx pod in the demo namespace along with our nginx deployment replicas. And that is the end of the demo. So let me go back to the slides. And we can skip to the end here. Maybe if we are cooperating, please. OK, well, I mean, you get the picture. So thank you all so much. Thank you for that teleport machine ID. And we also have our Slack here. We're also going to be at KubeCon at booth P13. So if you want to come chat more, I'll be around as well as our CEO and some other folks. So come hang out. And then we also are hosting a happy hour. We still have registration spots open if you like beer and chicken. So thank you. Any questions? Hey, so I liked your talk. Thank you. One of the kind of core Kubernetes things is cattle, not pets. And I know also like kind of if you spire, which I'm a lot more familiar with, also kind of with the way it does keys and management of identities and other things like that also has somewhat of a cattle view. Sure. And I may have just picked up on something on your slide without really understanding it. So I'm just asking, when you talk about all machines have identities, is this more in the pets category or the cattle category? And maybe you can also explain what I mean by pets and cattle. Yeah, so it certainly falls more into the reason that you give it an identity is to treat it with the same accountability that you would like a human. So it's not like a pet in that like you can do this also for like just ephemeral like worker nodes. So it's all about just kind of consolidating access rather than like making it something it's not. It certainly is a cattle and we're still viewing them just as like worker nodes and they are can be completely ephemeral. So it's just all about way of like consolidating that access rather than making them like more special than they need to be or something like that, which I also forgot actually is in the future. So a lot of like a core of this product in the use is like a CI CD workflow way so that you can handle this access without having these long-lived credentials that then get leaked in a GitHub repo for example. So in teleport 11 the next release will actually have GitHub action support so that you can interact with teleport protected resources directly from these workflows without need for secrets in GitHub even for example. And we also have Kate's support for automatic service discovery so you can have a cluster running this service and anytime you create new pods or new microservices or new nodes those will automatically be added and onboarded to the teleport cluster without doing that whole setup that we just did. So right now we have that support for SSH nodes like in EKS for example but we don't, sorry not EKS, whatever it's called. Oh yeah EKS but that'll come in teleport 11. So this is like the core value here is this CI CD workflow so that you don't have to have these persistent creds in your infrastructure and that's kind of the idea. Does that kind of answer your question? Another one over here? Yeah, yeah absolutely yeah so great question. So yeah you can do it by tags or by labels and as soon as there's a match that will be, that node will be onboarded to the cluster with its own unique identity. So this identity will be generated again from its own X599 certificate and it will have some like configurable naming convention that you can give it and you can differentiate them while still grouping them under the label of whatever you know like worker node or whatever like service that you're employing them. Does that make sense? Perfect, great oh over here as well. User identity in terms of like I'm sorry a developer laptop yeah no absolutely so that's more of like the human use case but that's also like a core teleport service is that like machine ID is just one of the offerings but what people typically do is that it'll integrate with like your SSO like octa or github or whatever and then you can do all of this for like a human developer or like a even just like a developer laptop like you said so you totally can do that yeah and that's kind of the core business right now of teleport the wider use case is for engineering teams that need shared access to different resources they use teleport instead of like using a password vault or you know like juggling a bunch of SSH keys or something like that but yeah thank you guys so much again and I hope to see you at the KubeCon booth thank you.