S1: All right. In this stand alone episode, I'm doing a
S1: sponsored interview with Eva Concevoir of Teleport. So we've all
S1: heard sponsored conversations before, and the structure I really like
S1: is imagining that you're having a lunch conversation with an
S1: entrepreneur and you're learning about the product for the first time.
S1: So that's really how I approach these, basically, I say, look,
S1: we're having lunch. Tell me about the product. And I
S1: get to comment and ask questions just like a normal conversation.
S1: Now these are sponsored, so I'm not likely to blast
S1: someone from orbit. But I'm also going to be honest
S1: if I see a challenger or a question just like
S1: I would during a lunch conversation. And the way we're
S1: looking to avoid conflict here is by pre filtering, we
S1: allowed to do sponsored interviews. So that's the approach the
S1: natural pitch in a conversation over the time span of
S1: a meal.
UU: And with that, here's of from teleport. All right.
S1: Well, it's very nice to meet you. Likewise. Yeah, so
S1: I guess, could you tell me about yourself and tell
S1: me about the company?
S2: Absolutely. So I'm an engineer who was always obsessed with
S2: computing infrastructure. So probably the reason for this is as
S2: most engineers, I started programming at the fairly early age,
S2: and I always like to write code that kind of
S2: makes computers do things like physical things like play music,
S2: using something that moves inside of a computer or do
S2: some special effects with a monitor. And for that reason,
S2: I kind of grew up and gotten into the workforce.
S2: I was naturally attracted to this cloud revolution that started
S2: to happen because just being in a data center, I
S2: see the ceiling racks and racks of servers. It's just
S2: that there's always been various fascinating. So it's a second
S2: company has started to make the lives of other engineers
S2: a year. So the first was what was an email
S2: cloud delivery technology. So if you were to run the
S2: applications in the cloud and you wanted to kind of
S2: send and receive email messages of massive scale? That was
S2: my first company called Mail Gun. But after Milgrom got
S2: acquired by Rackspace, which at the time was second biggest
S2: cloud provider, so I got exposed to big cloud problems.
S2: And one of those problems was the access because as
S2: companies continue to push more and more data to the cloud.
S2: So the importance of data security in data centers is
S2: now more important than ever. And it just so happens
S2: that when it comes to infrastructure security, when it comes
S2: to infrastructure access, the technology we use for that surprisingly
S2: is a lagging application level security where, like 10, 15,
S2: 20 years. In other words, when you're accessing web apps
S2: online and by web apps, I mean, like banking. When
S2: you log into your bank to check your balance or
S2: pay your bills, you're actually using state of the art technology.
S2: But if you are an engineer at a sales company
S2: and you're accessing products, servers, computing environments, you're using antiquated
S2: stuff and people don't realize that they actually using better
S2: tools than engineers that build software. But that's true. So
S2: that's why Teleport was started to go and bridge this
S2: gap to get this state of the art technology into
S2: infrastructure access space. So software developers and another types of
S2: engineers can securely and conveniently access infrastructure.
S1: Awesome. And so just looking at it at a cursory level,
S1: it looks like the idea is controlling ingress and egress.
S1: It's like you have a single control point or all
S1: the different operations that need to happen is, is that
S1: the way you characterize it?
S2: So that's absolutely accurate. But I would say that so
S2: this type of description, it doesn't communicate much, right? So
S2: if someone would listen, it almost sounds like a network
S2: solution like, oh, you have a like a firewall or
S2: a proxy because they could be described using very similar language.
S2: The interesting thing is, it's all about identity at the
S2: end of the day. So even if you put security
S2: aside and you think about how is it that we
S2: do computing like, what is the process of computing? Who's involved?
S2: So you will see that there are three very different
S2: kind of actors in that dance. So you have hardware,
S2: but the actual things that stored data and perform operations
S2: and the data and the actual hardware. So then there
S2: are software and software. They act intelligently. So because we
S2: are pretty good at baking software, that makes decisions. So
S2: software is like control in hardware to make computing happen. Mm-Hmm.
S2: And then you have humans. Humans are obviously the most
S2: important thing. So humans create software. So there is this
S2: kind of loop of humans make decisions and then they
S2: create software, and then the software makes decisions on behalf
S2: of humans. And then it tells hardware what to do
S2: and hardware on behalf and software makes changes to the data. OK.
S2: So then if you are thinking about stealing someone's data,
S2: you now have a choice. You can attack hardware, right?
S2: So you can try to gain access to that machine,
S2: maybe even physically. Just break into data center steal, get
S2: the server out of the rack and run away. Like
S2: a Hollywood movie? Hard to imagine, but probably possible. Or
S2: you can attack software. You can try to inject your
S2: code into that software somehow, maybe through access, through cross-site
S2: scripting or by attacking supply chain. So you put your
S2: code into your software and then you get into hardware
S2: and then you get to today or you attack humans,
S2: you send an email and say, Hey, click on this
S2: thing to claim your whatever, and then you end up
S2: in their laptop. And from that laptop you get in software,
S2: hardware store and so forth. So that is important thing
S2: to realize that there are these three different entities and
S2: stealing data attacking could be done in three different dimensions.
S2: And historically, there have been completely different industries, completely different products,
S2: completely different organizations responsible for protecting each one separately. So
S2: you've heard the words like endpoint security or things like
S2: infrastructure access and then the like. These solutions, they would
S2: say we protect laptop or we protect your code or
S2: we protect your servers. And that is a broken approach.
S2: You see how fundamental that is. It's broken because they
S2: all disjointed. It means that if you were to have
S2: a complete protection, you have to, first of all, use
S2: different solutions for each of these three components. But then
S2: you also have to synchronize. You have to synchronize how
S2: they configured.
S1: Well, isn't isn't that because the history, though, is that
S1: they were very distinct components like it was a way
S1: up top and it was like a piece of iron
S1: sitting in a data center somewhere. So physically, the history
S1: is that they were very separate.
S2: Correct. Correct. And like you see, we as like, we're
S2: intelligent human beings. We obviously don't do anything obviously stupid.
S2: There's always a history behind. We've been making these incremental decisions.
S2: And each of those incremental decisions historically has been the
S2: right move. Right. But the end state that we really
S2: like we find ourselves in right now is just terribly wrong.
S2: Here's a very simple example of why it's broken every company.
S2: Most companies probably want to enforce one simple rule that
S2: states that a software engineer who no longer works here
S2: doesn't have access to our infrastructure. Yeah. Now, thank so
S2: for that to be true. You have to configure multiple
S2: tools in the same way. Mm-Hmm. So if you forget
S2: to say that this laptop is no longer trusted, that
S2: that laptop will be allowed to get in, or if
S2: you forget to say that this password is no longer
S2: valid through a web UI somewhere like intellect cabinet, just
S2: control panel engineers will be able to get it. If
S2: you forget to say that SSA is no longer accepts
S2: that they will be able to access infrastructure, you see
S2: simply because your data like it sits in the house,
S2: that's data center. And that house has dozens of doors
S2: for software hardware people where you have to synchronize access
S2: across all of them. And that is now becomes. It's
S2: almost actually impossible for most companies just due to the
S2: complexity of it.
S1: Well, especially on using separate software and also
S2: policies and software comes with expertise. So if you bought
S2: a solution, you better have experts who know how to
S2: set it up, configure and use it. And the expertise
S2: is always in short supply. Like every single company is
S2: struggling to hire engineering, talent and security in particular. And that,
S2: I would argue, is the fundamental problem that we solve
S2: with the act to splain concept, where we say that
S2: treating software access, hardware access and people were accessed separately
S2: is just not no longer scales like we have to
S2: have a single plane that works for all three actors.
S2: And in order for that to work, we need to
S2: agree on a common technology or common technological platform. It
S2: needs to be open. It needs to be an open standard.
S2: It needs to be easy to understand the reason about.
S2: And then when you say we're not going to support
S2: anything else like all the legacy stuff needs to go away,
S2: that is what teleport is. Teleport estates that for software,
S2: hardware and people where to seamlessly work, create this trusted
S2: computing environment. Everything has and everyone, everything and everyone really
S2: important has to have an identity and identity is represented
S2: in the form of a certificate. So there are two
S2: standards for certificates that exist that we support both SSA
S2: certificates and X five of nine certificates and teleport says
S2: that to do anything for machines, for software and humans.
S2: All three have to have certificates and either something is
S2: allowed or not is done by looking at all three
S2: certs for every security related action and then saying yes
S2: or no. So that is the major innovation here. Is
S2: this consolidation of these three actors of computing and on
S2: top of Common Foundation, which is a certificate which is identity.
S2: So it solves, first of all, it solves the fragmentation
S2: issue where you have these kind of silos of security
S2: all over. But it's also often methodically eliminates the. Huge,
S2: a risk that exists in your system if you have secrets.
S2: So when companies talking about secure a vault, when they're
S2: talking about passwords, rotation, when they talk about encryption addressed,
S2: so they basically saying that our infrastructure has certain things
S2: on it that are protected by encryption. Mm-Hmm. So protected
S2: password is protected by encryption, so you cannot claim that
S2: the data itself will never be stolen, like things get
S2: stolen every once in a while. But you are relying
S2: on decryption or encryption decryption as your last line of defense. Mm-Hmm.
S2: So here's why it was just statistically not going to work.
S2: So if you have, let's say, a secret, let's use
S2: such a key. For example, we have a private association
S2: somewhere in your system. The worst case scenario here, like
S2: a lot of them, engineering laptops, but just to let,
S2: let's assume you have an encrypted key. So which means
S2: that there's decryption happening somewhere. Mm-Hmm. It could be happening
S2: or thematically. So you have some kind of scripts, some applications,
S2: some automation that does decryption, or it could happen manually.
S2: So there is a human that needs to type in
S2: the decryption key on a keyboard. OK. So in the
S2: first case, if it's a piece of automation that has decryption,
S2: you could have a bad deployment. You might have your
S2: code that does. Decryption with the decryption key might accidentally
S2: end up on on GitHub visible to the entire world.
S2: You know, mistakes happen. Mm hmm. The probability is close
S2: to zero, especially if you're world randomization. So doing your
S2: best not to do these bad deployments. And if you're
S2: doing it manually, well, humans are humans. Everyone like you
S2: might end up with a sticky note in the monitor somewhere. Mm-Hmm.
S2: And that sticky note may end up in the news,
S2: if that possible. It was a real story in
S1: an interview with VIDEO.
S2: Yeah, yeah, yeah. Well, again, the probability of that happening
S2: is comically low. But notice what happens as you scale,
S2: as you acquire more and more and more secrets as
S2: you get more and more and more hardware and you
S2: get more and more humans who can make mistakes. So
S2: the probability the combined probability starts to creep up and
S2: then eventually that happens.
S1: So. So let me jump in here real quick. So
S1: you're essentially saying these three things let's wrap them with
S1: some sort of access control plane of some sort and
S1: then have a policy inside of that plane, which. Looks
S1: for certain actions being allowed to be done and tying
S1: that directly to people
S2: views or true identities. Yeah, actually, it's important to say
S2: that we should not treat machines or humans separately from
S2: each other. They need to be treated the same.
S1: OK, so there are
S2: three parties A, B and C, right? A is hardware.
S2: B is a piece of software like microservice, for example,
S2: and C is a is a is a human. And
S2: when they interact, you should pay zero attention to visit
S2: machine is that person doesn't matter. You simply look on
S2: a certificate, you look at properties of a certificate and
S2: then you look at policy. So if the certificate says
S2: that the like one of these actors is a production environment,
S2: it's not staging AHA. So it triggers production policy because
S2: what what happens in private to production data versus staging
S2: is very different, right? So and then if one of
S2: these certificate says that I'm a like, a temporary contractor.
S2: So now you know that there is something happening on
S2: production with a temporary contractor. So you want to see
S2: what the policy of enforcing, but you should not paying
S2: attention as a human is a machine is itself doesn't matter.
S2: That is the key distinction because if you implement a
S2: system like this, then you have this massive unification. You
S2: essentially saying there is a single source of truth that
S2: issues identities to everyone and a single source of truth
S2: that makes authorization and authentication decisions and a single source
S2: of truth where the audit goes?
S1: Well, that how about the asset data? So how do
S1: you complete the the details of the policy? So I
S1: need to access this web service. I need to contact
S1: this API. I need to get onto this hard disk
S1: and pull this data. When you're trying to write a
S1: policy that says only this identity can do this during
S1: this time of day or whatever. Doesn't that require a
S1: lot of asset metadata to exist?
S2: Correct. So the assets method data I received by saying assets,
S2: you inject that distinction because the asset assumes like machines, self,
S2: the right ones are not assets. So this is why
S2: I want to double click on do not make that distinction.
S2: Just simply says metadata, right? So you have metadata associated
S2: with identity. Where's it coming from? That's I think, your question.
S2: So here's the thing. If you are a human and
S2: you going through a log and process, that metadata will
S2: get injected by idea the identity platform your company uses.
S2: It could be Active Directory sell point Okta. Like all
S2: of these things they can, they deliver a lot of
S2: metadata when you go through authentication. Teleport doesn't do authentication,
S2: by the way. We rely on your SSL. Sure, we
S2: just get your right that your identity is given to us. OK,
S2: so that's where it's come from that comes from in
S2: this case. So it's already there like your company knows
S2: who you are, like you are a member of a group,
S2: you have an email address, you have a manager. All
S2: of this going to be in your certificate. So then
S2: if your piece of software like you're a microservice and
S2: you are lunching inside of, let's say, a Kubernetes cluster,
S2: your identity will be handed to you in the form
S2: of a certificate and it will. The queue environment will
S2: be encoded in there. The the the community cluster knows
S2: I'm staging and production. If you database machine, it will
S2: all be there. So we already have this metadata on
S2: the infrastructure level like that. Technologies have been built by
S2: other people like we don't really need to imagine that
S2: or I'm sorry not imagine them re even invent that will.
S2: And the same is true for hardware when the hardware,
S2: when the company issues you a laptop, if it's OK,
S2: it's an Apple laptop that there is a hardware security
S2: module on it and you can mark like this laptop
S2: belongs to us. So some other laptop shows up and
S2: it has a TPM with a different fingerprint on it,
S2: and it will not. It will not be trusted, right?
S2: So the key technologies for having metadata and storing it
S2: already exist. So what teleport does that? We suck all
S2: of this metadata out, put it in a certificate, and
S2: then we make sure that these certificates are available when
S2: the decision is to be done, either to allow or
S2: deny specific operation.
S1: Yeah, very, very interesting. So how does this touch in with?
S1: Because it sounds very cloud friendly because that's where we
S1: have a lot of metadata present.
S2: It's easier to do in the cloud, definitely, because cloud
S2: allows you to do everything through code. So as you
S2: provisioned machines, using your scripts, as you create Kubernetes clusters
S2: and your services as there's just a lot of it's
S2: just awesome if you're in the cloud, if you if
S2: you run your own data centers. Companies that do that,
S2: they don't just like bare metal and nothing else. Yeah,
S2: they have. Things like VMware, OpenStack, they have private versions
S2: of what Ada Bliss offers, and those have similar capabilities.
S1: OK, so you're going to get metadata from somewhere, whether
S1: it's VMware or somewhere, OK for an MDM or something. OK.
S1: Very interesting, so as in so how how upfront is
S1: the policy editor because it seems like the policy is
S1: is very key. Right. You have the you have the
S1: control plane and then you have the policies that sit
S1: on top of it. Is that a is that a
S1: huge part of the product and the interaction point with
S1: the product?
S2: So the answer is yes and no. I would say
S2: that companies historically struggled, not with defining policy. Mm-Hmm. Because
S2: like the mid-sized organizations, their policies are not that complicated.
S2: You have, like even even the basic ones that are
S2: often not enforced. For example, the policies like engineers must
S2: not push production data easy enough, right? Mm-Hmm. So if
S2: you are in engineering, you should be dealing with staging.
S2: You should be dealing with test environments like don't touch
S2: customer data, don't you? So the policy for that is
S2: like a couple of lines of configuration using like arbitrary
S2: language like you and I could come up with a
S2: way to declare its policy. So the difficulty has been
S2: to actually enforce it because of this siloing off axis,
S2: because you have like cloud access through the API, you
S2: have a say you could go through just control panel
S2: through web. You I can go through Kubernetes. You see
S2: that there are just so many protocols, so many different doors.
S2: So synchronizing it the having a single way of defining
S2: that is the much bigger problem. And I'm not saying
S2: your question is not important. I'm simply want to remind
S2: that the focus is consolidation having a single voice, but
S2: then to define policy in teleport, we offer kind of
S2: two ways of doing it. Do you have like a
S2: static way of defining policy? You can think of like
S2: YAML file. The gamble says that like this group, this
S2: is what they could do inside of communities. This is
S2: what you can do with telling them be. But the
S2: interesting one is policy as code, so you could basically
S2: use your like programming language of your choice, which will
S2: be teleport will just ask your code. But what shall
S2: I do now? This read like this is what I.
S2: Identities of everyone involved like this allows you to kind
S2: of extend teleport behavior beyond static configuration so you implement
S2: completely arbitrary rules like if your last name ends with
S2: a Z, then you cannot do something on Tuesdays after 2pm.
S2: So that is kind of two ways of doing it
S2: through code dynamically or statically via a static concept.
S1: Yeah, it just seems to me that the policy piece
S1: is huge. Not not the technical aspect of like, how
S1: do you write it or implement it? But the aspect
S1: of explainability understanding your security program by being able to
S1: look at your set of policies that are in place.
S1: So it's like someone comes audit you, a customer or
S1: a regulator or something something and they come to you
S1: and they say, I want to know the current state
S1: of our environment. You could say here are all the
S1: policies that are currently in place. Here are the violations.
S2: That's right. Yep, yep. It's actually interesting computer science problem
S2: that you reminding me off. So, uh, so those of
S2: us engineers who went to school and if you take
S2: like a prologue class. Mm hmm. The policy is very
S2: similar to declarative programming. Mm hmm. So if you're writing
S2: a piece of software or using those languages, you basically
S2: define a set of facts like predicates. For example, cats
S2: are animals. Dogs are animals. So then the program will
S2: say that both cats and dogs are animals, and you
S2: can ask the question Is dog an animal? And the
S2: and the system will respond yes and no. So as
S2: you add more and more statements like this and the system,
S2: your probably your application becomes more complex and then you
S2: can ask the question So is Bob an animal? And
S2: the thing will and and the system of predicts will
S2: look like Bob is a human and human is not
S2: an animal. Therefore, Bob is not an animal. So you
S2: could just take a simple example. But notice that the
S2: answers will always be correct. You will either get yes
S2: or no or not enough data. But we don't have
S2: a system like this to query policies today because policies exist,
S2: as I said, because of that fragmentation and siloing, you
S2: have different policies for different systems declared using different languages
S2: and components, so you cannot ask a question can bob
S2: touch production data right? So because no way you because
S2: you have no one to ask. Simply because of that fragmentation,
S2: so that is why we rely on audits. Mm-Hmm. Audit
S2: is a retroactive way to see if you have an
S2: error in your policy. It's essentially troubleshooting policy. That's what
S2: audit is. This is why auditors look for this all logs. Mm-Hmm.
S2: Because they want you. They want to see if you
S2: have a way of spotting in there. I am basically
S2: saying that audit logging in the future should be considered
S2: almost like an absolute practice. Instead, we should have a
S2: system that is similar to prolog where you can ask
S2: a question can log access from production. And if the
S2: answer is no, it's not like they're there.
S1: We don't really give me the current state of the employee.
S2: So that is the future that we're driving towards. But
S2: the first step is to consolidate everything in one place.
S2: You see, this is why. I answered my your first
S2: question that way, because when you said like, just can
S2: I single control plan that everything goes through? That is true,
S2: but you see how deep that consolidation goes, that you
S2: making entire things like audit, log and observability not needed obsolete.
S2: That is the kind of benefit that you get if
S2: you consolidate access policy and identity source in one place.
S1: Interesting. And so what are the technical steps here like?
S1: What is the plane look like when it's installed inside
S1: a different environment? How does it look for physical assets?
S1: How's it look for Cuba daddies versus easy to versus
S1: all these other places?
S2: So they're essentially, I would say, maybe three components of
S2: a system and. It's just kind of on a low
S2: level teleport is a single binary look, would you believe
S2: that simplicity is absolutely essential to security? So every engineer
S2: is familiar with the concept of a Unix daemon, so
S2: you have a system that's running on every box. So
S2: and we use that model. OK, we're going to be
S2: just like that because everyone knows how to run it.
S2: Everyone knows how it works. Everyone has an idea of
S2: how much resources it requires. CCD is also it's almost stateless.
S2: It has a little bit of config. It's simple. It
S2: never goes down. It has no dependency. It's like the
S2: first thing that comes up and the last thing that
S2: goes down. Mm-Hmm. Maintenance free or almost maintenance free. So
S2: that is what teleport is. It's just a drop in
S2: replacement process. OK. So with get out of the way now,
S2: how does it work when it's running you? You have
S2: to say that on certain machines, teleport works slightly differently.
S2: So in other words, you run the daemon with different
S2: flags in different places. OK. So you have to say
S2: like these machines are going to be proxies, so you
S2: have to select the proxy. OK, so proxy. It means
S2: that it's a machine that is exposed to the outside world,
S2: also on the inside. So that's your kind of front door.
S2: So teleport proxy. Again, SOCOG works exact same way, so
S2: if you think of jump host, that's really your proxy.
S1: OK, so this is like your your take on zero
S1: trust rather than VPNs like these are your proxies to
S1: get into everything behind.
S2: Correct. So but teleport proxies, peaks, all protocols. I feel
S2: like the massive difference there. Hmm. So when you try
S2: to connect to a MongoDB or teleport, the proxy will
S2: start speaking MongoDB protocol to you. If you're talking associate proxies,
S2: toxic assets h, so your existing tools think that they
S2: are talking to actual mongo.
S1: So if including on another distant host that's behind the proxy,
S1: how is it being routed to it? How does it know?
S1: So go.
S2: Yeah. So the proxy, what proxy does they? The proxy
S2: gets your request, and in there it sees which host
S2: you're actually trying to go to. So it makes this
S2: transparent connection and you go into that host on that
S2: host you have teleport to running and teleport is interacting
S2: closely with whatever it is you're accessing. Is it? If
S2: it's if it's Linux operating system, that's direct comparison to SSA.
S2: So it will just do Fool Association limitation, right? So
S2: but if it's good or my sequel, or if it's
S2: maybe a Kubernetes cluster, then it will connect that connection
S2: directly to the cluster and it and it will put
S2: certificate on the wire. Because all of these workloads actually
S2: support certificates could be an instance of birth certificate databases do. Hmm.
S2: But with a certificate coming from the proxy by itself
S2: is really dumb. It simply connects sockets together, and that's
S2: by design. Mm hmm. Because if you have an attack
S2: on the proxy, not because teleport is vulnerable, but simply
S2: because there is always an attack. You might have Postgres.
S2: I'm sorry, the WordPress or some other application that's older,
S2: built on the same machine, but like human made a
S2: mistake somewhere and people bad people have gotten onto the
S2: proxy fight. There are no secrets in the proxy, the
S2: way it works that. Before even connecting to your proxy teleport,
S2: it will it will look on the wire and see
S2: if you have a certificate. And if you don't have
S2: a certificate that will redirect you to identity manager like
S2: actor sell point Active Directory, it will say go do
S2: your SSL. So you go through that you log in
S2: using the choice of authentication your company prefers, and then
S2: that system will redirect you back to teleport with certificate
S2: on the wire. Mm-Hmm. Now we actually know what that's wrong.
S2: That's not how it works. It redirects you back to
S2: teleport with metadata on the wire. So we have standards
S2: like Samuel or Panaji Connect where your identity is going
S2: to be there. So the proxy will then take that
S2: identity and will send to the second component of teleport
S2: called Certificate Authority. Certificate Authority will look at you and
S2: there's OK which protocols you're using, or you need the
S2: cessation ID MongoDB you need. And then this will issue
S2: certificates for everything you need, and those certificates will go
S2: back to you and they will be put in the
S2: wire and then you'll be redirected back to proxy. And
S2: then proxy will look at these certificates and it will
S2: connect you to this thing. And when you add it's
S2: encrypted end to end this, your proxy proxy only looks
S2: at the circuit doesn't actually see any data. So then
S2: your connection is established, let's say, into MongoDB or Linux
S2: box and decryption only happens there. So that is the
S2: magic reminds me
S1: of Kerberos a little bit.
S2: Yeah, exactly. You see, these ideas are not new, but
S2: we as an industry, we know what the best practices are.
S2: It just so happens that they're not always available to people,
S2: so they have to resort to. So that's really what
S2: we do. We just make best practices easy by making
S2: him default. So and now when you connecting to, let's say,
S2: like a database or Kubernetes, you have certificates in the way,
S2: which means that Kubernetes will put you in the right
S2: group and the role based access control will kick in.
S2: And the audit will now have like your metadata will
S2: be in the audit, so it will all be now
S2: synchronized and then the same thing will happen if you
S2: are a bot. So if you're like a backup script
S2: and you get started by scheduler inside of a Kubernetes cluster,
S2: the certificate will be injected into Kubernetes secrets, right? So
S2: now you have certificates. So if you want to make
S2: connections during anything like every programming language runtime when you
S2: open socket call, there is a certificate optional parameter refresh TV, right?
S2: Just put it there. That's all you have to change,
S2: like one parameter, one line of code and that you
S2: don't need API keys anymore. That's it. Like now your Borth,
S2: your automation has an identity, and that identity will be
S2: used to give you access to whatever it is you
S2: need to back up. Mm-Hmm. So you see how it
S2: works for software now on the hardware side when the
S2: machine is booting, but you see teleport is a demon.
S2: So the first thing it does when it comes on line,
S2: it will go it so it will do its own off.
S2: It will go to certificate authority and say, Hey, I'm
S2: over here, I'm a production host. If that's true, the
S2: certificate will be issued and it will land on the box.
S2: So you see, every microservice has a certificate, every human
S2: has a certificate, every hardware piece of hardware has a
S2: certificate and in on the roadmap we're going into client
S2: as well. So which means your laptop when you try
S2: to get in because laptop, it needs to be compliant
S2: and you have IT-BPM, so your laptop will receive a
S2: client hardware certificate. And so now you have you basically
S2: covered everything with certificates. They have this identities, and now
S2: you can do this. Fun things with policy enforcement asking questions.
S2: Cook who has access to what?
S1: Yeah, really, really cool stuff.
S2: Yeah. But let's talk about the negatives, because if it
S2: was so obvious, why would it like didn't exist before?
S2: So the sacrifice is complete goodbye to backwards compatibility. Mm-Hmm.
S2: Because you have so much infrastructure out there. Let's start
S2: with routers like every piece of network equipment has a
S2: associated baked into it and you cannot get out and
S2: it works using public private keys like there is no
S2: certificate support. If you look on the client, like using
S2: windows using putty. No certificate support. Yeah, there are versions
S2: of SSA agent on some Linux distros. They cannot hold certificates.
S2: So we just basically making these choices that if we
S2: were to make a difference, I would have to go
S2: where the puck is going and saying if if you
S2: don't do certs, you should stop doing it. So that's
S2: that's probably the most visible kind of drawback of the system.
S1: That makes sense, which would make sense that it's easier
S1: for newer orgs, like if they were to spin up
S1: a new company tomorrow and start with this, it would
S1: be much easier.
S2: Well, you would be surprised. On one hand, though, what
S2: you're saying is definitely true. But yet let's also remember
S2: that any large company is basically a collection of orgs. Right? Yeah.
S2: And certain are newer than others. Mm-Hmm. Samsung is arguably
S2: like a huge company that's definitely not, you know, it's
S2: like feels like it's a half of the South Korean economy. Sure, sometimes.
S2: But we have a significant presence at Samsung. So the
S2: teams that are starting new projects or just or simply
S2: operating on the newer technological stack. So they are adopting
S2: to work more and more frequently, and we have plenty
S2: of large companies still apart.
S1: Yeah. And there are a lot of companies who periodically
S1: they say, how should we be doing this different? And
S1: that's a perfect time. There are regular intervals where it's
S1: a perfect time to reevaluate and move into the future
S1: rather than doing the old thing.
S2: Yeah, I think the big another like other than fragmentation
S2: of access, which is absolutely killing everyone. Another huge problem
S2: is now with just treatment of secrets. Mm-Hmm. For a
S2: long time, it was considered to be acceptable to store
S2: secrets in an encrypted way as long as you do
S2: it properly. So you would use some kind of encrypted
S2: vaults or you would use basically just you would rely
S2: on encryption to protect your infrastructure. And it's okay. It's fine.
S2: But we have solid algorithms. We had like amazing mathematical breakthroughs.
S2: So let's do that. And that's true. But the reason
S2: why secrets no longer work is because of scale. So
S2: let me walk you through why he managed just right. Well,
S2: key management is one use case, but you can. But
S2: you could think about it in the generic terms like
S2: you have data and there's the standard like data and
S2: you should be encrypted at rest. OK, encrypted with what? Well,
S2: with a secret. So where does that secret go? And
S2: you have these instances of that like sprinkled all over
S2: there have API keys for internal external services. You have
S2: message credentials, you have a data like backups encrypted, just
S2: like all of the secrets. Where do they go? Like
S2: what is happening? So that is a growing concern and
S2: the problem in the space because it's not scalable and
S2: this is where scale breaks here. So imagine for a
S2: second that you have a single secret in your infrastructure
S2: and your infrastructure is a single server and your team
S2: is like five people. Everything is really small, so you
S2: encrypted something that's secret. And then you have to ask yourself,
S2: what is the probability of that being stolen? OK, let's
S2: look into it. If you encrypted something, it means there
S2: is decryption happening. Mm-Hmm. If decryption is happening, it means
S2: it's either manual. So one of your five engineers will
S2: just remember the secret and do decryption. Or it's a
S2: piece of automation, something that you periodically deploy. Mm hmm. OK.
S2: So if you are periodically deploying, there's a slight chance
S2: you will have a bad deployment. Type the wrong thing
S2: in the keyboard to flip the wrong thing and your
S2: secret will be on your public GitHub repository. You will
S2: check in with the code every once in a while.
S2: We make mistakes. Well, humans. Mm hmm. So there is
S2: a tiny chance that might happen on the automation side.
S2: But if it's on the human side, same thing. Humans
S2: make mistakes. There is a tiny chance you're going to
S2: click on the wrong attachment. You can sign up for
S2: the book with a phishing attack. Your laptop will get
S2: compromised and the secret will be stolen, but you would think, Oh,
S2: we're going to follow the best practices. We hired good engineers,
S2: the smart people not going to happen. OK, fine. But
S2: then what happens if you have two secrets and then
S2: two servers and then 10 engineers and then 100 secrets
S2: and 100 servers in a thousand years? So as you scale,
S2: as you process more and more data, you can grow
S2: that combined probability of human error keeps increasing. And I
S2: will never accept and we shouldn't, that humans are infallible.
S2: We will eventually make a mistake. So which means that
S2: the existence, the mere existence of secrets and your infrastructure
S2: is a liability. And the bigger you get, the bigger
S2: that liability becomes. So the future then, is to move
S2: to completely scrupulous future, where there's zero infrastructure secrets that
S2: are present anywhere. And that is where the certificates come.
S2: Come in because maybe we don't eliminate the need for
S2: secrets for all things infrastructure, but we eliminate the need
S2: for static credentials for access. So the API keys go
S2: away because your applications will get this ephemeral certificates that
S2: are automatically expiring so you don't really need encrypted storage
S2: for your API keys. So things like associated passwords who
S2: go away, things like private public keys go away. Things
S2: like like passwords to windows. You see, that's a huge
S2: kind of liability exposure that certificates on identity just eliminate,
S2: which is a big, big shift that's happening in the
S2: industry that now is important.
S1: I love this. I think this is. I feel like
S1: it's where things have to go because complexity just continues
S1: to grow. Exactly. This is this is the only way
S1: to actually address it with a system like this.
S2: It's something I enjoy seeing the similarities in how humans
S2: think about different problems. Like one, when we talk about
S2: carbon footprint and global warming, it's basically the same answer. Yeah.
S2: It needs to go to zero. Like simply lowering something
S2: by 20 30 percent is not enough because it keeps
S2: accumulating so few, gaining 20 percent all the time. So
S2: eventually that that curve is going to get you to say, Oh,
S1: it's just like you said with population, the population grows
S1: and you have a small problem. Well, you have a
S1: big yes.
S2: Yep. Yep, yep, exactly. Exactly.
S1: All right. Well, this has been fantastic. Definitely enjoyed this.
S1: I wish it was a real lunch, but me too. Yeah. Yeah.
S1: Maybe sometime soon. And thank you so much for the time.
S2: Yeah. Thank you for asking all the right questions I
S2: couldn't hope for to cover so much, so quickly. Awesome.
S2: All right, ladies,
S1: we're listening to the standalone episode. We'll see you next time.