Sponsored Conversation: Ev Kontsevoy from Teleport

Now these are sponsored, so I'm not likely to blast someone from orbit. But I'm also going to be honest if I see a challenger or a question just like I would during a lunch conversation. And the way we're looking to avoid conflict here is by pre filtering, we allowed to do sponsored interviews. So that's the approach the natural pitch in a conversation over the time span of a meal.

I was naturally attracted to this cloud revolution that started to happen because just being in a data center, I see the ceiling racks and racks of servers. It's just that there's always been various fascinating. So it's a second company has started to make the lives of other engineers a year. So the first was what was an email cloud delivery technology. So if you were to run the applications in the cloud and you wanted to kind of send and receive email messages of massive scale? That was

my first company called Mail Gun. But after Milgrom got acquired by Rackspace, which at the time was second biggest cloud provider, so I got exposed to big cloud problems. And one of those problems was the access because as companies continue to push more and more data to the cloud. So the importance of data security in data centers is

now more important than ever. And it just so happens that when it comes to infrastructure security, when it comes to infrastructure access, the technology we use for that surprisingly is a lagging application level security where, like 10, 15, 20 years. In other words, when you're accessing web apps online and by web apps, I mean, like banking. When you log into your bank to check your balance or pay your bills, you're actually using state of the art technology.

But if you are an engineer at a sales company and you're accessing products, servers, computing environments, you're using antiquated stuff and people don't realize that they actually using better tools than engineers that build software. But that's true. So that's why Teleport was started to go and bridge this gap to get this state of the art technology into infrastructure access space. So software developers and another types of engineers can securely and conveniently access infrastructure.

do computing like, what is the process of computing? Who's involved? So you will see that there are three very different kind of actors in that dance. So you have hardware, but the actual things that stored data and perform operations and the data and the actual hardware. So then there are software and software. They act intelligently. So because we are pretty good at baking software, that makes decisions. So software is like control in hardware to make computing happen. Mm-Hmm.

And then you have humans. Humans are obviously the most important thing. So humans create software. So there is this kind of loop of humans make decisions and then they create software, and then the software makes decisions on behalf of humans. And then it tells hardware what to do and hardware on behalf and software makes changes to the data. OK. So then if you are thinking about stealing someone's data, you now have a choice. You can attack hardware, right?

So you can try to gain access to that machine, maybe even physically. Just break into data center steal, get the server out of the rack and run away. Like a Hollywood movie? Hard to imagine, but probably possible. Or you can attack software. You can try to inject your code into that software somehow, maybe through access, through cross-site

scripting or by attacking supply chain. So you put your code into your software and then you get into hardware and then you get to today or you attack humans, you send an email and say, Hey, click on this thing to claim your whatever, and then you end up in their laptop. And from that laptop you get in software, hardware store and so forth. So that is important thing to realize that there are these three different entities and stealing data attacking could be done in three different dimensions.

And historically, there have been completely different industries, completely different products, completely different organizations responsible for protecting each one separately. So you've heard the words like endpoint security or things like infrastructure access and then the like. These solutions, they would say we protect laptop or we protect your code or we protect your servers. And that is a broken approach. You see how fundamental that is. It's broken because they

all disjointed. It means that if you were to have a complete protection, you have to, first of all, use different solutions for each of these three components. But then you also have to synchronize. You have to synchronize how they configured.

Most companies probably want to enforce one simple rule that states that a software engineer who no longer works here doesn't have access to our infrastructure. Yeah. Now, thank so for that to be true. You have to configure multiple tools in the same way. Mm-Hmm. So if you forget to say that this laptop is no longer trusted, that that laptop will be allowed to get in, or if you forget to say that this password is no longer valid through a web UI somewhere like intellect cabinet, just

control panel engineers will be able to get it. If you forget to say that SSA is no longer accepts that they will be able to access infrastructure, you see simply because your data like it sits in the house, that's data center. And that house has dozens of doors for software hardware people where you have to synchronize access across all of them. And that is now becomes. It's almost actually impossible for most companies just due to the complexity of it.

struggling to hire engineering, talent and security in particular. And that, I would argue, is the fundamental problem that we solve with the act to splain concept, where we say that treating software access, hardware access and people were accessed separately is just not no longer scales like we have to have a single plane that works for all three actors. And in order for that to work, we need to agree on a common technology or common technological platform. It

needs to be open. It needs to be an open standard. It needs to be easy to understand the reason about. And then when you say we're not going to support anything else like all the legacy stuff needs to go away, that is what teleport is. Teleport estates that for software, hardware and people where to seamlessly work, create this trusted computing environment. Everything has and everyone, everything and everyone really important has to have an identity and identity is represented

in the form of a certificate. So there are two standards for certificates that exist that we support both SSA certificates and X five of nine certificates and teleport says that to do anything for machines, for software and humans. All three have to have certificates and either something is allowed or not is done by looking at all three certs for every security related action and then saying yes

or no. So that is the major innovation here. Is this consolidation of these three actors of computing and on top of Common Foundation, which is a certificate which is identity. So it solves, first of all, it solves the fragmentation issue where you have these kind of silos of security all over. But it's also often methodically eliminates the. Huge, a risk that exists in your system if you have secrets.

So when companies talking about secure a vault, when they're talking about passwords, rotation, when they talk about encryption addressed, so they basically saying that our infrastructure has certain things on it that are protected by encryption. Mm-Hmm. So protected password is protected by encryption, so you cannot claim that the data itself will never be stolen, like things get stolen every once in a while. But you are relying

on decryption or encryption decryption as your last line of defense. Mm-Hmm. So here's why it was just statistically not going to work. So if you have, let's say, a secret, let's use such a key. For example, we have a private association somewhere in your system. The worst case scenario here, like a lot of them, engineering laptops, but just to let, let's assume you have an encrypted key. So which means that there's decryption happening somewhere. Mm-Hmm. It could be happening

or thematically. So you have some kind of scripts, some applications, some automation that does decryption, or it could happen manually. So there is a human that needs to type in the decryption key on a keyboard. OK. So in the first case, if it's a piece of automation that has decryption, you could have a bad deployment. You might have your code that does. Decryption with the decryption key might accidentally end up on on GitHub visible to the entire world.

You know, mistakes happen. Mm hmm. The probability is close to zero, especially if you're world randomization. So doing your best not to do these bad deployments. And if you're doing it manually, well, humans are humans. Everyone like you might end up with a sticky note in the monitor somewhere. Mm-Hmm. And that sticky note may end up in the news, if that possible. It was a real story in

it's not staging AHA. So it triggers production policy because what what happens in private to production data versus staging is very different, right? So and then if one of these certificate says that I'm a like, a temporary contractor. So now you know that there is something happening on production with a temporary contractor. So you want to see what the policy of enforcing, but you should not paying attention as a human is a machine is itself doesn't matter.

That is the key distinction because if you implement a system like this, then you have this massive unification. You essentially saying there is a single source of truth that issues identities to everyone and a single source of truth that makes authorization and authentication decisions and a single source of truth where the audit goes?

So here's the thing. If you are a human and you going through a log and process, that metadata will get injected by idea the identity platform your company uses. It could be Active Directory sell point Okta. Like all of these things they can, they deliver a lot of metadata when you go through authentication. Teleport doesn't do authentication, by the way. We rely on your SSL. Sure, we just get your right that your identity is given to us. OK, so that's where it's come from that comes from in

this case. So it's already there like your company knows who you are, like you are a member of a group, you have an email address, you have a manager. All of this going to be in your certificate. So then if your piece of software like you're a microservice and you are lunching inside of, let's say, a Kubernetes cluster, your identity will be handed to you in the form of a certificate and it will. The queue environment will be encoded in there. The the the community cluster knows

I'm staging and production. If you database machine, it will all be there. So we already have this metadata on the infrastructure level like that. Technologies have been built by other people like we don't really need to imagine that or I'm sorry not imagine them re even invent that will. And the same is true for hardware when the hardware, when the company issues you a laptop, if it's OK, it's an Apple laptop that there is a hardware security module on it and you can mark like this laptop

belongs to us. So some other laptop shows up and it has a TPM with a different fingerprint on it, and it will not. It will not be trusted, right? So the key technologies for having metadata and storing it already exist. So what teleport does that? We suck all of this metadata out, put it in a certificate, and then we make sure that these certificates are available when the decision is to be done, either to allow or deny specific operation.

they have. Things like VMware, OpenStack, they have private versions of what Ada Bliss offers, and those have similar capabilities.

customer data, don't you? So the policy for that is like a couple of lines of configuration using like arbitrary language like you and I could come up with a way to declare its policy. So the difficulty has been to actually enforce it because of this siloing off axis, because you have like cloud access through the API, you have a say you could go through just control panel through web. You I can go through Kubernetes. You see that there are just so many protocols, so many different doors.

So synchronizing it the having a single way of defining that is the much bigger problem. And I'm not saying your question is not important. I'm simply want to remind that the focus is consolidation having a single voice, but then to define policy in teleport, we offer kind of two ways of doing it. Do you have like a static way of defining policy? You can think of like YAML file. The gamble says that like this group, this is what they could do inside of communities. This is

what you can do with telling them be. But the interesting one is policy as code, so you could basically use your like programming language of your choice, which will be teleport will just ask your code. But what shall

I do now? This read like this is what I. Identities of everyone involved like this allows you to kind of extend teleport behavior beyond static configuration so you implement completely arbitrary rules like if your last name ends with a Z, then you cannot do something on Tuesdays after 2pm. So that is kind of two ways of doing it through code dynamically or statically via a static concept.

policies that are currently in place. Here are the violations.

are animals. Dogs are animals. So then the program will say that both cats and dogs are animals, and you can ask the question Is dog an animal? And the and the system will respond yes and no. So as you add more and more statements like this and the system, your probably your application becomes more complex and then you can ask the question So is Bob an animal? And the thing will and and the system of predicts will look like Bob is a human and human is not

an animal. Therefore, Bob is not an animal. So you could just take a simple example. But notice that the answers will always be correct. You will either get yes or no or not enough data. But we don't have a system like this to query policies today because policies exist, as I said, because of that fragmentation and siloing, you have different policies for different systems declared using different languages and components, so you cannot ask a question can bob

touch production data right? So because no way you because you have no one to ask. Simply because of that fragmentation, so that is why we rely on audits. Mm-Hmm. Audit is a retroactive way to see if you have an error in your policy. It's essentially troubleshooting policy. That's what audit is. This is why auditors look for this all logs. Mm-Hmm. Because they want you. They want to see if you

have a way of spotting in there. I am basically saying that audit logging in the future should be considered almost like an absolute practice. Instead, we should have a system that is similar to prolog where you can ask a question can log access from production. And if the answer is no, it's not like they're there.

That is the kind of benefit that you get if you consolidate access policy and identity source in one place.

how much resources it requires. CCD is also it's almost stateless. It has a little bit of config. It's simple. It never goes down. It has no dependency. It's like the first thing that comes up and the last thing that goes down. Mm-Hmm. Maintenance free or almost maintenance free. So that is what teleport is. It's just a drop in replacement process. OK. So with get out of the way now,

how does it work when it's running you? You have to say that on certain machines, teleport works slightly differently. So in other words, you run the daemon with different flags in different places. OK. So you have to say like these machines are going to be proxies, so you have to select the proxy. OK, so proxy. It means that it's a machine that is exposed to the outside world, also on the inside. So that's your kind of front door.

So teleport proxy. Again, SOCOG works exact same way, so if you think of jump host, that's really your proxy.

So it will just do Fool Association limitation, right? So but if it's good or my sequel, or if it's maybe a Kubernetes cluster, then it will connect that connection directly to the cluster and it and it will put certificate on the wire. Because all of these workloads actually support certificates could be an instance of birth certificate databases do. Hmm. But with a certificate coming from the proxy by itself is really dumb. It simply connects sockets together, and that's

by design. Mm hmm. Because if you have an attack on the proxy, not because teleport is vulnerable, but simply because there is always an attack. You might have Postgres. I'm sorry, the WordPress or some other application that's older, built on the same machine, but like human made a mistake somewhere and people bad people have gotten onto the proxy fight. There are no secrets in the proxy, the

way it works that. Before even connecting to your proxy teleport, it will it will look on the wire and see if you have a certificate. And if you don't have a certificate that will redirect you to identity manager like actor sell point Active Directory, it will say go do your SSL. So you go through that you log in using the choice of authentication your company prefers, and then that system will redirect you back to teleport with certificate

on the wire. Mm-Hmm. Now we actually know what that's wrong. That's not how it works. It redirects you back to teleport with metadata on the wire. So we have standards like Samuel or Panaji Connect where your identity is going to be there. So the proxy will then take that identity and will send to the second component of teleport called Certificate Authority. Certificate Authority will look at you and there's OK which protocols you're using, or you need the

cessation ID MongoDB you need. And then this will issue certificates for everything you need, and those certificates will go back to you and they will be put in the wire and then you'll be redirected back to proxy. And then proxy will look at these certificates and it will connect you to this thing. And when you add it's encrypted end to end this, your proxy proxy only looks at the circuit doesn't actually see any data. So then your connection is established, let's say, into MongoDB or Linux

box and decryption only happens there. So that is the magic reminds me

him default. So and now when you connecting to, let's say, like a database or Kubernetes, you have certificates in the way, which means that Kubernetes will put you in the right group and the role based access control will kick in. And the audit will now have like your metadata will be in the audit, so it will all be now synchronized and then the same thing will happen if you are a bot. So if you're like a backup script and you get started by scheduler inside of a Kubernetes cluster,

the certificate will be injected into Kubernetes secrets, right? So now you have certificates. So if you want to make connections during anything like every programming language runtime when you open socket call, there is a certificate optional parameter refresh TV, right? Just put it there. That's all you have to change, like one parameter, one line of code and that you

don't need API keys anymore. That's it. Like now your Borth, your automation has an identity, and that identity will be used to give you access to whatever it is you need to back up. Mm-Hmm. So you see how it works for software now on the hardware side when the machine is booting, but you see teleport is a demon. So the first thing it does when it comes on line, it will go it so it will do its own off. It will go to certificate authority and say, Hey, I'm

over here, I'm a production host. If that's true, the certificate will be issued and it will land on the box. So you see, every microservice has a certificate, every human has a certificate, every hardware piece of hardware has a certificate and in on the roadmap we're going into client as well. So which means your laptop when you try to get in because laptop, it needs to be compliant and you have IT-BPM, so your laptop will receive a

client hardware certificate. And so now you have you basically covered everything with certificates. They have this identities, and now you can do this. Fun things with policy enforcement asking questions. Cook who has access to what?

windows using putty. No certificate support. Yeah, there are versions of SSA agent on some Linux distros. They cannot hold certificates. So we just basically making these choices that if we were to make a difference, I would have to go where the puck is going and saying if if you don't do certs, you should stop doing it. So that's that's probably the most visible kind of drawback of the system.

operating on the newer technological stack. So they are adopting to work more and more frequently, and we have plenty of large companies still apart.

But we have solid algorithms. We had like amazing mathematical breakthroughs. So let's do that. And that's true. But the reason why secrets no longer work is because of scale. So let me walk you through why he managed just right. Well, key management is one use case, but you can. But you could think about it in the generic terms like you have data and there's the standard like data and you should be encrypted at rest. OK, encrypted with what? Well,

with a secret. So where does that secret go? And you have these instances of that like sprinkled all over there have API keys for internal external services. You have message credentials, you have a data like backups encrypted, just like all of the secrets. Where do they go? Like what is happening? So that is a growing concern and the problem in the space because it's not scalable and

this is where scale breaks here. So imagine for a second that you have a single secret in your infrastructure and your infrastructure is a single server and your team is like five people. Everything is really small, so you encrypted something that's secret. And then you have to ask yourself, what is the probability of that being stolen? OK, let's look into it. If you encrypted something, it means there is decryption happening. Mm-Hmm. If decryption is happening, it means

it's either manual. So one of your five engineers will just remember the secret and do decryption. Or it's a piece of automation, something that you periodically deploy. Mm hmm. OK. So if you are periodically deploying, there's a slight chance you will have a bad deployment. Type the wrong thing in the keyboard to flip the wrong thing and your secret will be on your public GitHub repository. You will check in with the code every once in a while.

We make mistakes. Well, humans. Mm hmm. So there is a tiny chance that might happen on the automation side. But if it's on the human side, same thing. Humans make mistakes. There is a tiny chance you're going to click on the wrong attachment. You can sign up for the book with a phishing attack. Your laptop will get compromised and the secret will be stolen, but you would think, Oh, we're going to follow the best practices. We hired good engineers,

the smart people not going to happen. OK, fine. But then what happens if you have two secrets and then two servers and then 10 engineers and then 100 secrets and 100 servers in a thousand years? So as you scale, as you process more and more data, you can grow that combined probability of human error keeps increasing. And I will never accept and we shouldn't, that humans are infallible.

We will eventually make a mistake. So which means that the existence, the mere existence of secrets and your infrastructure is a liability. And the bigger you get, the bigger that liability becomes. So the future then, is to move to completely scrupulous future, where there's zero infrastructure secrets that are present anywhere. And that is where the certificates come. Come in because maybe we don't eliminate the need for secrets for all things infrastructure, but we eliminate the need

for static credentials for access. So the API keys go away because your applications will get this ephemeral certificates that are automatically expiring so you don't really need encrypted storage for your API keys. So things like associated passwords who go away, things like private public keys go away. Things

like like passwords to windows. You see, that's a huge kind of liability exposure that certificates on identity just eliminate, which is a big, big shift that's happening in the industry that now is important.