Kubecon 2019 - Scytale (Spiffe)
Transcript
>> Hey, how's it going, it's Keith Townsend from The CTO Advisor. This noisy background you're seeing is Kubecon 2019 in San Diego. You can't tell it is beautiful outside. I'm lying. And with me Sunil James, CEO of Scytale. Sunil, 200 vendors on the show floor. The reason why there's 200 vendors here is because enterprise IT companies, the traditional players are not solving all the problems we see in this cloud native space. What problem is Scytale solving? >> Well, first off, thanks for having me on your show.
You know, enterprise IT has been around for a very long time, they've been solving enterprise problem for a very long time using a variety of technologies, virtual machines, physical machines, everything under the sun from vendors like Microsoft, and Oracle, and beyond. But when they started looking at public cloud, and they started looking at the word cloud in general, it's not just a matter of taking something that you've already built, and just running it in the cloud. It's understanding, how do I actually take this thing, break it up into four or five pieces, and then give myself, and my team the flexibility to scale at those pieces independent of each other.
'Cause that's where the real power of cloud comes in from. And I know this because I've been on the inside of Amazon, and Google, I was a product manager at both these organizations. I've helped build some of the cloud technologies that many of these folks are using today, and I think where the problem is that we have seen, is that as the organizations go through that transformation, where they take their application, they start to break it up, they start to run into the cloud, all of a sudden they realize that the way in which they used to provide security for these applications in the world of yesterday, is going to have to be fundamentally rethought because of how applications are getting built in this cloud world.
>> One of the problems that is really common is that I can't easily say that this server and AWS, or this service in AWS can talk to my Oracle database on prem because this thing is ephemeral. It may go way. And to make matters worse, this service, or server in AWS is not the same thing in Azure. >> Correct. >> Or GCP, those things are named differently, they look differently, they smell differently from my firewalls, and my firewall can't provide the controls that I'm accustomed to.
How do you guys solve that problem? >> The thing that we realized with our open source community that we've been working with as well as the commercial customers we've been working with is that they fundamentally look at their services, and I'm not going to get into a micro service versus a this service, it's a software service that has some function to serve some role. These services are kind of like people. They got to job. >> Right. >> They share information, they receive information.
They have a set of other services that they got to talk to as well, and they move around. >> I'm not talking about Cisco Pro role, isn't a role. This is a role that has rights and security to other objects inside of my environment. >> That's exactly right. And so what we've realized and the opportunity for us is to actually say well why do we actually have a lot of the control points key off of the fact that the service itself needs to do certain things.
And so, how do we do that? How do we actually create a primary key for a service and then take that primary key and then teach all the other infrastructure? Whether it's networking, middleware, databases. Whatever it might be, proxies. About how to read that key and understand what that key means, so that you could unlock the roles, and responsibilities, or even the entitlements associated with what you can do. And So the way we do that is we basically brought together a large community around a open source project called SPIFFE, and SPIFFE stands for Secure Production Identity Framework For Everyone.
It's a play on how we used to name projects inside of Google. >> Right. >> And that's the acronym we came up with, but the fundamental ideas is we wanted to provide a mechanism for anybody, to be able to define, almost like a whitelist policy for what a service is. That policy can be composed of a variety of attributes. You could say things like: this service is only allowed to run on this subnet, this service has to have this SHA-256 of its binary, this service can only be built by these teams, so whatever they might be, right?
And so what we do is we say, okay you can encode all of those factors into a policy, and then we give you an actual piece of open source code that enforces that policy. >> So what that sounds like to me is I'm rebuilding a whole another AD infrastructure. And components of that, AD doesn't do all of that, but components of it is in AD so am I building the overlapping system, and redundancy of redundant directory services like how. Help me out with that like, that sound like more maintenance to me.
>> So I think that the audience, your audience in particular, is an audience that has been building in a very vast, you know, active directory or just LDAP based infrastructure for the last 30 years. >> Right. >> Strong controls, strong identity based on that. >> Right. >> And as these organizations are going into the cloud, they're recognizing that these things in the cloud, and you still need to talk to these things that are on-premise. >> Exactly. >> The identities that are in the cloud are distinct and different from the identities that are on-premise.
>> Absolutely. >> And so there needs to be some way to map these things to each other. >> Well there has to be some way to map those things to each other and on top of that, I don't necessarily want those two things to know about each other, like the directory, like there's things in the cloud and I don't want those things in the cloud to be in the same database, or security system as my things on-prem. >> You got it. >> Because I want to protect my things on-prem from the cloud.
>> You got it. And that hard line of separation is a construct of how relatively little these organizations trust the cloud. >> Yes. >> And there's good reason to not have that trust, but that will change over time as we all prove the value there, but I think that for us is the opportunity to say to them you don't have to have all your keys in one place. You can keep all your keys in active directory. You can keep all of your identities in EC2, or Google Cloud, or Azure.
You can have something over here VMware. Something over there in another back-end database. And what we'll do is we'll give you a mechanism to basically synchronize all of that, keep it where it is, but then generate that primary key that I was referring to, that can then be used, to be able to say what a service can do based on the context that it's communicating with something else. >> So I'm a infrastructure guy, that sounds great to me, but I can't tell you the number of times I built a service, an essentialize service, and the developers just didn't come, they didn't consume it.
They went out and did their own thing anyway. What's the appeal for developers to adopt something like SPIFFE, through asthenic, something like Citel to manage security in a application. >> So one of the things that we hear a lot from Enterprise IT Architects, Chief Information Officers, VPs of Engineering, CTOs, is that the pool of engineering resources that they have with is becoming tougher and tougher to maintain to protect, and the amount of work is only getting bigger and bigger. >> Right. >> And so what you really want to see your folks working on are the more meaningful problems that require the kind of mental capacity that is why you hired them.
Things like authentication, which is really what we're talking about. >> Right. >> Can service A and B talk to each other? Really should not be a primitive that is left into the hands of a developer because that's not what they're there to do. >> No, if they didn't have to do it, they wouldn't do it at all. >> They wouldn't do it at all. And if they didn't have to do that they'd have capacity to do other things instead.
>> Right. >> So you get more bang for your buck from your development team, and you get a standardized way instead of tackling authentication in your organization that's increasingly heterogeneous. May not be under the same, you know, line of business, or what have you, and it's all auditable. And so this allows you to start getting more utilization out of an existing labor force you have, at a very macro level that we're talking about here. The other thing too, as I said before hand, is the consistent way of doing this.
Large enterprises are islands of acquisitions that are dispersed all over the country and the world. >> Yes. >> They don't always know what the right hand is doing from the left. And so in such situations, we've had many conversations where people say, we just want the underlying infrastructure, or set of infrastructure services to be utilized by developers, not have to think about it too much, and just do the work under the covers to figure out what service A is, what service B is, and whether they can talk to each other, and give me an audit log of when those things are happening, and then call it a day.
That I think is the opportunity that exists when we think about why a developer would care about this because they don't have to care about this anymore. >> They shouldn't have to. >> So Sunil, how do people find out, how do they find the open source project first? io and from there it's a jump-off point to learn about the genesis of where this came from. The underpinnings of how zero trust ties in to what identity means for that world. Inside of that you'll also learn about, not only SPIFFE, but some of the runtime code implementations that build on top of SPIFFE, which is our other open source project called SPIRE.
So they're kind of sister projects to each other, but that's a perfect good place to start there. >> Well that's it for this episode of the CTO Advisor. We want to thank Scytale for sponsoring this episode on CTO Dose. com. Of course you can follow me on Twitter, @ctoadvisor. Talk to you next CTO Dose.
