Decisiv's Journey to Secure Developer Access
Learn how Decisiv provides secure access to developers and deals with compliance hurdles. Senior Engineer Hunter Madison will talk about how Decisiv needed to quickly solve the pain of scaling the engineering team, migrating to AWS, maintaining ISO 27002 compliance, and a few of his key learnings from his two-year journey using Teleport
Slides from Secure Developer Access at Decisiv
Slides are available from slideshare: Hunter Madison on Secure Developer Access
Case Study - Decisiv's Journey to Secure Developer Access
Mark: Well, hello everyone. And thank you for joining our webinar, where we're going to talk a little bit about secure developer access at Decisiv. And really appreciate you all joining us today. I'm Mark Herring. I look after marketing here. And I'm joined by Hunter Madison, who's a senior engineer at Decisiv. Welcome, Hunter.
Hunter: Good morning, Mark. And thank you for having me.
Mark: Well, thank you for being so gracious with your time and agreeing to spend some time with us and really looking forward to the lessons you've learnt and to tell the audience what you've learned along in your journey. So why don't you just maybe just give us a little brief overview of who you are and sort of your background.
Who is Hunter?
Hunter: All right. Well, as you've said, I'm Hunter Madison. I'm a senior engineer in Decisiv. I come from a background of doing cyber liability engineering and full stack engineering together. So my career has basically had me go from end-user computers, all the way down to just above hardware and solving problems, fixing things, getting people secure access to tools, to application upgrades, to user experience design, and generally making things just happen with computers.
Mark: That's awesome. So before we dig down into maybe a little more on that, what does Decisiv do, for the audience? You've told me some of the good stories, but our audience doesn't know. So what does Decisiv do?
What does Decisiv do?
Hunter: All right. At a very, very rough and very, very high level, Decisiv is a company that does your equivalent of your health records, but for commercial assets. So the idea being that if you have things like a large truck that keeps being on the road, when that truck breaks down, it costs you money as a business owner. So you want to get this thing repaired and back on the road as fast as possible. Our platform helps manage that relationship from when it rolls off the line — as we partner with a bunch of manufacturers — to when it shows up at the shop to when you have to go into your routine maintenance on it. So, again, it's like your full-service medical record system, but for a truck.
Mark: Really interesting. I just heard from our producer here that we don't have your video on. Can you switch that on or we [crosstalk] —
Hunter: Oh. Apologies.
Mark: Yeah. That's okay. Perfect. We can see you as well and the slides. Wonderful. So tell me a little bit on terms — I understand what Decisiv does and I know you're senior engineer, what does that mean for Decisiv? What are you responsible for at Decisiv?
Hunter: So I'm part of the technology and engineering team. So I'm responsible for a lot of the infrastructure and the applications that the infrastructure supports. So I primarily deal a lot with application performance monitoring, Amazon, and then, also touching on some of the security aspects of this stuff: how do I get developers to securely deploy things, get access to production, non-production environments to look around and do their job?
Mark: Excellent. And I know we were talking about a little bit before the webinar, you joined Decisiv and there was this major sort of pain points. Do you want to elaborate on that? What were the major sort of pain points you were experiencing as you joined? And let you [crosstalk].
Hunter: Yeah. Sure. So when I joined Decisiv — so something just to keep in mind because we're playing in the trucking space and we're so interconnected with everyone in that space, we have some very, very, very large customers, who when you get up to that massive multinational enterprise size, they want you to go through security audits and have these controls and have these processes in place. So when I came on, we were really kicking off a lot of that work and it was this transitional time of us going from the old style, very simple, very basic patterns of access control over to a more heavy "auditor-friendly" [inaudible].
Mark: Interesting. So you're keeping the auditor happy as well. Were there any sort of changes to infrastructure at the same time? I think you mentioned you're doing a bit of a lift and shift happening at the time.
Hunter: Oh, yeah. So we were essentially — and we're still finalizing this because I argue infrastructure has never been finalized, but this was also —
Mark: Nor will be. Exactly.
Hunter: Oh, yeah. This was also us really going and starting to take some refactors from us going from in a co-location center in Richmond to Rackspace to AWS and towards a more cloud first architecture and shedding off the concepts of, "Oh, well, we have access to a physical server." Someone can drive and put their hands on it to. Well, maybe everything's ephemeral in the cloud and maybe we're going to have 100 servers, maybe we're going to have 1 server. And we're just going to let some automated process figure that for us.
Mark: That's really interesting. So yes, this whole push to more ephemeral and sort of cloud thing. How did the developer population, let's say, or the engineering population you got there, how were they dealing with this? Were they super-excited about the auditors looking into their business? I assume not, but.
Hunter: I mean, I've been through two of these security audit-type deals in my career and generally speaking, nobody's particularly happy when an auditor shows up and says, "I need you to check 10,000 boxes every time you make a change." But I do think we probably have hit a pretty happy medium, where we have all the information that we want for getting through some of these audits and having those controls in place while still letting people do what they normally do.
Mark: Really interesting. And I know you've been using Teleport for a while, so I'm going to put a little poll up here just to find out from our audience out there, if you want to just fill in the poll and just tell us if you've ever heard of Teleport to, "Hey, I'm already a customer. I'm using this stuff," just so we will let that run. And we will close that maybe in about three or four minutes. But tell me, how did you find Teleport? How did you find us?
Hunter: Oh man. So this was maybe back when you guys started the company, I think you had a Hacker News post talking about version 1. And at the time, I was very, very much a developer and it's like, "Oh, yeah. This is a really cool idea." And just throughout the years, it's popped up again. I've run your open source version for myself personally for a while. And coming to Decisiv and being like, "Oh man, we totally are going to have this problem with the audit and being able to go and say, "Oh, I can just get Teleport in and that solves it."" I think it was really, really nice.
Mark: That's awesome. I definitely appreciate you being an early adopter and using our product. But maybe moving a little away from just pure tech, how did you deal with engineers sort of dealing with change? Right. I mean, it's like you're implementing something new. Yeah. How do you deal with that culture changes there?
Hunter: Oh, yeah. So, I mean, that's basically my entire slide deck.
Mark: Yeah. Perfect. So we'll dig into that one. And then, maybe just before we sort of dig down into your sort of slide deck there, tell me in terms of what — we're obviously living in COVID times as we all know, but I think there's also other things that have always been true. What do you think are the big problems that engineers having to address today around the sort of security side?
Designing Secure Systems
Hunter: Yeah. So I think fundamentally we have to deal with security audits. And when you think about security audits, really I think people think in terms of auditable standards. Things like ISO 27002, 9,000, which isn't necessarily a security audit, but still talks about having that whole process. You have PCI, FedRAMP, NIST, GDPR, CCPA. And fundamentally, there are two core questions that all of these audits basically boil down to: it's, who can do what when; and it's, why did someone do something then? And the problem with answering these questions at scale is that if you want to design a secure system, you basically have to make it usable. I think Don Norman, who, for those who aren't super familiar, he was the big UI guy at the Apple and his book; Design on Everyday Things, is a mainstay in every single usability course across the country. Absolute legend — and I highly suggest the book if you've never read it, albeit it was written in the 80’s and it's kind of dated. But he put this paper together for interactions. And there's this quote that I love from it, which is, the audience, either not understanding the rationale or simply disagreeing with the necessity for the procedures imposed upon them, see these as impediments to accomplishing their jobs. And, to me, that really speaks to the problem that Teleport solves when it comes to all these auditable standards is it's like you have to make something that's usable and auditable. But first and foremost, it has to be usable because if it's — it has to be secure, period, and that's table stakes. But if it's not usable, no one's going to use it. It could be at work around and you're going to be in a worse off place than you were. So [crosstalk] —
Mark: Can I just ask one sort of follow up question? When you say usable — and I'm just thinking of the engineering population — what does that look like to you? What does usable mean? Or what are the trendsetter?
Hunter: Well, when I generally think of usable in terms of software engineering, I think that you are either going to — so there's the Indiana Jones stacking for the bag of sand type usability, where you have made a change and it's completely invisible to them, which is usable because their experience hasn't changed, or you're going to save them some amount of time. And this could be things like, "Hey, we brought in a new CI tool, your builds are 50% faster." So you're saving them 50% of their build time across of the day. That's just inherently more usable because they can get work done faster. I think for security products, it's getting their access to be faster. So previously, when we managed all of the SSH keys by our provision management process, to get someone set up, it would take 6 to 12 hours just having to let it run everywhere because we had that many hosts. Now, with Teleport, the day that they start and the day that their manager says they're ready to start taking advantage of servers, they can click a button in our identity provider Okta, and we hit an approved button on the backend that creates our audit entry and they have SSH access to everything that their team has responsibility over. So I think that's core for usability. It's making those loops faster.
Mark: Excellent. Thanks.
How Decisiv Solved Usability with Teleport
Hunter: So, fundamentally, I want to run through, how Decisiv fixed this with Teleport. And basically, I have a couple of vignettes talking through various stages that we went through and just various bits of understanding that I have learned having to admin Teleport from 3.0 to up to 4.2. And then, I want to walk you through how we designed our cluster, just to give you guys, if you're thinking about adopting Teleport, a bit of an understanding as to the tradeoffs of both types of things. So first and foremost, Teleport at a high level, it's a highly available cluster of authentication proxy servers, which basically creates an SSH bastion that's auditable and gets tied into your IDP. It also will act as an X.509 Certificate Authority. Something that I take advantage of, because if you've never had to distribute passwords or certificates to people before, it's an absolute headache, especially if your company doesn't have a single centralized password manager. It'll also store everything in S3 and DynamoDB, which is really nice because it's stateless and it's really nice because you get access to that data.
Configure Your IDP
Hunter: We host everything in DynamoDB and S3 and we're entirely AWS, so this talk does assume that you're hosting on AWS. I believe you can do Google Cloud as well. I've just never played with it. And then, finally it records everything in multiple auditable forms, so win-win-win. The first bit that I want to touch on is the IDP. And what I've realized running Teleport for two years is that you really want to configure your IDP well. Basically, if you can push groups through your IDP, which turn into Teleport roles, but also a bunch of attributes which you have access to in those Teleport roles, it really s to cut down on the amount of administrative overhead with Teleport. Something that Teleport doesn't do particularly well today is support tools like Terraform or other configuration management tools for its administrative interface. So the less that you need to go in and monkey around with roles on 4.2 and 4.3, just the smoother it becomes.
First Time Provisioning Workflow
Hunter: So for us, our first-time flow works this: when the person joins the company, HR will set their Teleport team, that'll create a bunch of group mappings under the hood to give them roles; and then, they can go through the request workflow that Okta has, since we use Okta as our IDP, that gets them access to the Teleport application; and from there, that Teleport team role mapping and the request workflow come together, pass out the data that we need over to Teleport, that gets them all the SSH access that they need. We then take advantage of Teleport's labeling system. So each node can have a bunch of labels, they're either static or you can drive them off of commands. So for example, I can pull in things like the instance_id, account_id, the tags that it has, so on and so forth. They'll all show up in Teleport and this is how it'll look in the UI. You can use all of these labels when you're evaluating your roles to give people access. So in our case, we have a single —
Mark: Just a minute. Just pause for a second there just so the audience knows we will be putting these slides all up on SlideShare. So if you're trying to frantically take screenshots as we go through here, don't worry. Hunter's been gracious enough to share these things. But just one of those people freaking out going, "Oh my God, I got to make two slides without taking photos." So yeah, carry on. Just want to let the audience know. Hunter Madison on Secure Developer Access
Use Labels and Metadata Interpolation
Hunter: Yeah. No problem. And also, everything I'm showing also is present in the Teleport admin guide and the Teleport RBAC Guide as well, so don't feel you're completely lost. But yeah, just back to what I was saying. We have one single role for all developers. And the way that we do that is, is that we interpolate their team in with those labels. So we just pull all the labels from our Amazon control plane, give them to Teleport, and then use them in Teleport to do the access so every developer — we have a single shared restricted developers user that everyone uses. If you wanted to get fancy, you could actually make it, the SSH user, come from your IDP. I don't right now because we're keeping it simple. We're using node labels to basically say every server that your team's responsible for, you have access to. And then, we're throwing in some deny operations to say any server that's tagged for my team, you'll never get access to ever.
Really, Just SSH
Hunter: And then, we set up some standard options like, I say that your maximum session time to life is eight hours, which is your standard American working day. And then, this is the one role that we have. It's really simple to debug. It's really simple for people to keep in their head servers that my team are responsible for, I see in teleport. The other bit about Teleport, and this is why I strongly feel that Teleport, right now, is probably best in show in the market for this type of tooling, is the fact that under the hood, Teleport is literally just an SSH server. So if you set up — and again, this is basically coming straight from the Teleport guide, I just added a couple of lines to make it easier on myself. You put this in your SSH config, and every single tool that works with certificate authentication and can handle an SSH config works with Teleport. So you do one tsh login at the start of your day, all of your tools will work for your session TTL.
Hunter: Ansible works. I've got an Inspec, Capistrano to work. OpenSSH and Windows works. This is also how, if you have windows clients, you're going to have to have them log in just with tsh.exe, just to get the circuits and use OpenSSH for windows. I will say though, some Java data sciency tools, for some reason, don't seem to really support certificate off. So if you have key critical tools that end users rely upon, I'd highly suggest getting the open source version set up and just testing that out before necessarily saying, "Yeah. We're going to use Teleport for everything," and having to use this SSH access to go through those tools. The other bit that I've learned past couple of years, which I think is really important especially for new Teleport admins to understand, is the fact that if you have processes that were started by Teleport users, you can figure out the exact session that those processes were started in and get that history. Which if you've ever had to debug a server that someone's gone and they've touched a bunch of stuff on, this is really, really helpful.
Identifying What Users Started Teleport Processes
Hunter: So under the hood, in your Teleport binary that you have, which is your node binary, that lives on disk, it'll set a bunch of environment variables for every session. And because of the way that just its environment process hierarchies work, you can pstree [command] and find a parent that will have these environment variables and their environ. The two that I think you should know is SSH_TELEPORT_USER, which is their Teleport username, and TELEPORT_SESSION. So quick and dirty example: I started a screen session, I found its pid, checked its environ and you can see my username and my session_id there. So if I wanted to get some context on why this session was started, I can look at that session_id in the console. And if I just want to know who it is, I have a username. I've had to do this to every director that we've had twice now. It's a very, very useful trick when you're looking at servers that people have jumped on and off to do a bunch of debugging on.
Hunter: Now, that trick's really good. This is also why I absolutely love having Teleport, which is the fact that you can do what I just showed you proactively. So Teleport does record every session by default, no configuration. It works on a bunch of different Linux distributions including older kernels, which is great. You really can't search through them at scale because under the hood, it's a zip file that they have a json and a txt file together, and you do a semantic stitching, and that makes the movie. But there's also something called enhanced session recording. So you do have to have a newer Linux kernel, I believe it's 4.19 and up for it. But you turn that on, you get access to this session command event, which if you're living in DynamoDB for these sessions like I do, you can pipe that into your sign using a DynamoDB stream and the NEW_IMAGE option. And it really lets you just find problem commands quickly.
Hunter: So we use Okta as our sign lock management tool. I have all the data — sorry, Humio is our sign lock management tool. By pumping all of our log events into there, so I get to see who did it, the program, the return code, the session_id, and then what index it was in that session. And the cool part is now that it's in Humio, I can set alerts, send them to Slack when people start things like screen or connect to network hosts that I don't want them connecting to, or around [inaudible], just world is your oyster once you start getting this data into a tool like this. And I think it's really, really powerful that Teleport is starting to offer these types of features because this is basically hyper proactive, hyper searchable, very, very easy to audit, which is great.
X.509 Certificate Authority
Hunter: The last bit I want to touch on before getting into some infrastructure beds is the fact that you can use Teleport for other things. So you do have an X.509 certificate authority, which is great because every time they use tsh, they have a new X.509 certificate, which has been refreshed, which is limited for your session TTL. And you can use a tctl command on your Auth server to get your cert authority, create a couple of new certificates based off of that, and pass that to tools MariaDB, Postgres, OpenVPN, which support certificate authentication out of the box, but not necessarily your IDP. So we use this with OpenVPN and AWS right now, which is really great because I get all the advantages of OpenVPN, I get all the advantages of certificate authentication, and they already have access to the management tool that they need. I've also done this for Postgres and MariaDB. Just to keep in mind, you can see groups mapped as organization, valid logins mapped as locality, and the username as the common name, but the tool will determine what it's able to necessarily parse. For example, Postgres will only let you use the common name, MariaDB will actually let you look at the entire certificates presented attributes and do auth based off of that.
Hunter: So I think, finally, I just want to walk you through how we set up our cluster and some of the thought process behind that. In case you want to go and take a punch and do it yourself, you at least have someone else's example to look at. I like to think of this in terms of tiers, where you haven a user tier at your bottom left and your locking tier in your upper right. And I'm just going to run through all of the decisions that we made at each of these levels and try to give you guys just learn from my mistakes basically. So I think at the start, you have a user tier. You really got to understand where your users are and then where your nodes are. So for us, we're the size of the global remote company, I have Okta as my IDP, but I'm dealing with people all around the globe, essentially from St. Petersburg to Chile in terms of time zone.
Hunter: Node-wise, we have a lot of Amazon accounts and we basically do a light form of account vending right now. And as we've been doing more and more cloud work, we're pushing to a stronger and stronger form of it. So being able to do things with cross account STS and SSM to get going tokens is really, really helpful.
Hunter: Keeping that in mind, you basically move on to how do you want to set up your cluster based off of your user requirements? There's two ways that you can — there are three ways that you can do that too, which I would suggest. There's either the tunneled mode or the trusted mode. So the tunneled mode is you would run a single cluster. Nodes are going to connect over the internet. You have a single SAML service provider. This is kind of what their Teleport cloud offering, I believe, works and looks like. So for us, the way that we do it, we have one dedicated Teleport AWS account. All it does is run Teleport and the Teleport infrastructure, and all the nodes get latched to that. It's really, really clean. It's easy to debug and it works.
Hunter: You also can do a trusted cluster mode, where each account gets its own Teleport cluster. You have one SAML IDP which is shared through your primary master cluster. We used to do this up till 4.0. What I have found is: one, users have to really be aware of switching the clusters; and two, when a trusted cluster breaks, it's very, very painful to debug and fix. If I were to talk as long as I needed to on fixing these things, it would probably be a college course. So keeping that in mind, since we're on Amazon and we want this to be highly available, we need some load balancers.
Load Balancing Tier
Hunter: I found that the application load balancers work great for the [inaudible]. Basically, just be aware that you want to change your timeouts to get the web console to work, since the WebSocket implementation doesn't heartbeat in such a way that the ALB likes it. You also can let Teleport generate its own self sign certificates because ALBs don't actually check SSL. They use a different security feature that is accessible only to Amazon to make your connection secure. So it does cut out a couple of steps in your configuration management.
Hunter: And the network load balancers do work for the proxy stuff and the SSH stuff. Just be aware that you're going to constantly see error messages in the log coming from the NLB, because the way that the heartbeat is they connect to the author proxy socket, open-end TCP connection. If they get a TCP response, they immediately close it and that's a heartbeat. It's very frustrating. I have yet to find a way to make that disappear. If anyone knows that one, please tell me because it's pages of these things.
Hunter: So from an application perspective, just thinking can we host Teleport, we're running it in an auto scaling group so one host per AZ. We're stacking the Auth and Proxy components together on the same host, because again Teleport's going binary with just different configuration modes you turn on and off.
Hunter: And I found that Amazon's SSM, if you need a “break glass” mechanism to get direct access to the Teleport host for troubleshooting, works wonderfully not only for being your “break glass”, but also just for general management and use. So you can use the assessment documents to do a lot of the config things. Basically, the setup works. I don't have any direct access into that account. I have to go through SSM to touch things. Outside of that, everything's bottled up and the only publicly accessible things are downstairs, which is great from a security perspective.
Hunter: And finally, just thinking about data storage, we put all of the session recordings in S3, DynamoDB store sustaining the events. This means our hosts are stateless, so when I go to upgrade, I just say on my auto scaling group, "Everything is there with the old launch configuration. Give me one instance for the new launch configuration," run that for a bit to let the upgrade finalize if they're under migrations, go back up to three. Very stateless, very painless. It takes 20 minutes to do an upgrade. It's great.
Hunter: And then, because we're sticking the events in DynamoDB, like I said previously, we had that SIEM integration with NEW_IMAGE, so I get a bunch of really, really cool starting stuff. So, yeah, I think just keeping in the mind when you're thinking about doing Teleport, it's worth sitting down and thinking through how you want this designed and how you want this, just figure it out. For us, being a global remote company with a really, really heavy emphasis on basically just having dynamic servers, spinning stuff up, turning stuff off, a lot of AWS accounts for isolation, I think our setup works pretty well. It might not work the best for you, so play with it and experiment with it. But hopefully, this type of structure at least gives you a good starting point. So yeah.
Mark: Yeah. I definitely appreciate that. That was great. I mean, and definitely sort of giving us your architecture. So yeah, for the audience out there, there is a little Q&A button with Zoom. So if you want to put it there, we'll get to some of the open questions. I have a couple that have come through as well. Maybe the first one I have here is, how hard was it to get started with Teleport? So I know this is — you have to go back in the way back machine, but yeah, for someone new, how hard is it to get up and running?
Hunter: I think for simple setups, where you have a single Amazon account or just a single set of servers, Teleport's not particularly difficult. I think the big things just to remember that I always get burned on it's, are you running IP tables? Do you have your network access, NACLs, set up properly? Basic stuff that. If you're going to run a single, just one Teleport server, that's all you have to think about. If you're doing HA, a little bit more comes into place. And actually rolling everything out and getting it installed, I'd say it's easier now than it was when I started. Because back when I started, I had to make my own RPM packages for Teleport. Today, you can just download RPMs, which is just amazing.
Mark: Awesome. And then, another question was: Which version of Teleport are you using? Are you using the Community version or the Enterprise version? Teleport Features by Edition
Hunter: Oh, we pay for Enterprise just because our backend SAML IDP is so incredibly huge for us. Being able to just quickly provision users via Okta is great. Literally, every application in our company now goes through Okta. And coming from a background where that was not the case, it is so nice when I can just go to our Okta dashboard and get into everything that I need to.
Mark: Awesome. I think a question came up, in terms of which SIEM tool are you using? I think you said Humio, but yeah. Do you want to tell us a little bit more what was that like and why you chose Humio?
Hunter: Yeah. So, and not to get super into it, Humio basically, for me, meets the implementation details around their search query language the developers like and makes finance happy in terms of their pricing structure. It makes me happy in terms of their security and management infrastructure. So it's one of these things where, for us, it checked all the boxes that we needed. And I do not have a bad experience with them as a company, but that's just my end.
Mark: It might vary. Yeah. Sure. Next question we have is, do users prefer using the web UI or tsh when connecting to nodes? See How I Found Myself in a Command Line vs GUI meeting
Hunter: I think it's about a 50/50 mix and it gradates the more manager you are, the more likely you are to use the web UI. I will say —
Mark: Is it a religious debate in the company, or not really?
Hunter: No. I don't think it particularly comes up. I will say for me though, I go back and forth between the web UI and the tsh terminal stuff because when I'm on call, I have, legitimately, had to pull off the side of the highway, log in to Teleport on my phone with an external keyboard to fix a server because it was down, and then keep driving to the office or wherever I was going. So massive plus on the web UI, totally works in mobile safari if you're willing to hold your nose a little bit. 10/10 would do again if you're desperate in a pinch. So, I would say, if you're thinking to not run the web UI, maybe reconsider running it because there are — I'd say every user will have a legitimate use case for tucking it at least once.
Mark: I appreciate that. If there are any more questions, definitely put them in the Q&A. Just a couple more. So advice for people getting started today, what advice would you give them? I mean, obviously, they don't have to create their own packages, which is good. But yeah, where would you start? Obviously, start with your talk maybe, but what other advice can you give them?
Hunter: What I can suggest doing is just — one, really sit down and think about how does your organization currently access servers, and try to come up with a list of acceptance criteria that you can then go and look at tooling with. I think Teleport will probably hit it since most companies are just SSH in box, [inaudible] SSH access. But really think through some of the intricacies like it doesn't matter that everybody logs in as a shared user or is it the case to where it has to be a personal name user with a set UID and a set GUID. Knowing that stock will then help inform like well, how am I going to roll this out, how am I going to configure it? Because Teleport can read and attribute to get user access, stuff that. I think once you have that done, it's worth getting it set up, running it alongside your traditional SSH setup for a month or two, just so that way you can build some administrative continents going through it and users can start building on acceptance of the tooling. And then, from there, it's just a matter of picking your flag day and really making sure that everybody who hasn't switched over has at least tried to switch. Just because, again, there are certain tools that don't support certificate authentication and the faster that you can identify those, the easier time that you're going to have either pulling in a replacement tool or working with that tool's vendor to get patches put in place where it does support certificate authentication so you can do that move.
Mark: Excellent, Hunter. Those are the main questions. I have one question, which is a completely unfair question. Because I think we might have a couple of engineers from Teleport team on this. One wish from you, if you had one wish for Teleport, what would it be now? Now, I've not asked Hunter this before this.
Hunter: Oh boy. I get to wish for something.
Mark: I can't guarantee that I can fulfill any of these wishes, but yeah, what's your one wish?
Hunter: Okay. I'm going to exclude some things that I've seen on the roadmap, because I have a general sense of what's coming. Okay. I would like a — and you could pay me to do this honestly, I am that badly wanting this. I want to tag the logging support based off of application internal component, because the one thing that I run into trying to get debug logs for Teleport, is it either goes from no actionable logs to Niagara Falls. And I would love something to where I could say, "I don't care about users. I just care about the trusted cluster bed," or, "I don't care about the trusted cluster bed. Just show me user authentication errors and know the login in the logs in my terminal."
Recommended Next Steps
Mark: Well, like I said, I can't promise that, but I will speak to our product management team. I'll chat with Ben and go, "Hey, let's see what we can do." But definitely appreciate all your time. And if we're putting this thing together — for the audience out there, we will put a transcription together. We have sort of a couple of ideas of sort of what to do next. Hunter talked a little about this —he was like, "Hey, read the Teleport admin guide," obviously download Teleport. And then, we have a community forum out there you can ask some of your questions on. Obviously, as a company, we're happy to engage. But again, Hunter, thank you for your time and thank Decisiv on our part for allowing you to spend this time with us. Thanks so much.
Hunter: Yeah. Thank you for having me. And I hope everyone has a wonderful Wednesday afternoon.
Mark: Excellent. Thank you.
Join The Community