CEO Interview: Armory’s Policy Engine (based on Open Policy Agent) + What’s Coming

I caught up with two of Armory’s product managers, Beth & Akshay, and three engineers, Ethan, Fernando & Jacob, to do a CEO interview about Armory’s Policy Engine, what we’re hearing from customers, and what’s coming next:

You can subscribe to Armory’s YouTube channel here — let us know in the comments if you’d like to see more of these CEO interviews with the Armory team!

Here’s are highlights of some of the topics we covered:

• Armory’s Policy Engine, built on the Open Policy Agent, and how it’s evolving to give companies better control, while also unlocking more velocity for their application developers
• How Policy Engine and Pipelines as Code work together and are maturing to provide even more functionality around RBAC / Least-Privilege
• What we’re hearing from customers using these enterprise features, and how we’re solving for their use cases, both in terms of progressive needs and massive scale
• How Policy Engine leverages the new Spinnaker Plugin framework
• Much more!

Here is a transcript from the session:

DROdio: All right, we’re recording. So hey, this DROdio, CEO at armory. And we’re going to do this as “bbetween two Ferns”  — but it’s actually between a Fern and a Shield, which is our office here. I’m here with three Armory engineers and two product managers. I’m going let them introduce themselves and we’ve got some pretty exciting things to talk about today. So, Beth, why don’t you kick it off here.

Beth: All right. Hello. I am Beth. I’m a product manager here at Armory, and I work on the SPIN team. And there’s there’s some fun stories around why we’re the SPIN team. Our focus is terraform and the terraform integration as well as policy engine and some other plugins that we have that perhaps we’ll be talking about on this call or in the future.

Akshay: Folks, my name is Akshay. I’m also a product manager here. My team works on Pipelines as Code which does integrate into the Policy Engine feature that Beth just spoke about. When you create and update pipelines, you can enforce that certain policies are being met by the pipelines. My team also works on Cloud Driver performance as well as installing and configuring Spinnaker

Ethan: Hey, my name is Ethan Rogers. I am the team lead of the SPIN team, the engineering side of the SPIN team. So I’m really closely involved in actually building out the Policy Engine plugin, and building out the technical side of all of the awesome things that Beth and co are bringing into our team.

Fernando: Hey, how’s it going? My name is Fernando. I’m the team lead for the ICO team, which is Akshay’s team and have been spending several years working on pipelines as code and happy to be doing it here as well.

Jacob: My name is Jacob Kobernick. I’m a software engineer on the SPIN team with Ethan and I’ve been spending a lot of dedicated time recently working on Policy Engine and getting really excited about what we’re hoping to bring to market.

DROdio: Awesome. Okay, great. So, very excited to do this. I was on a call with Beth Last week, and we were just talking about some of the incredible things that are coming not only in market, but that we are evolving and how important it is for us to really share some of that, because when when these large enterprises buy Armory, they’re not just buying what’s in market today. But they’re buying a partnership, which is a long-term ability for us to help them unlock innovation. And so we will try this once, and maybe we do this on a regular basis. But let’s just talk a little bit about what we’re seeing it from our existing customers, what they’re asking for, where we’re focused. And we can start wherever you’d like. So I don’t know who wants to throw out something that you’re seeing that you’re excited about that we should really talk through.

Ethan: I’m happy to, I’m happy to throw something out. So Beth mentioned a feature that we are working on with Policy Engine, which is something that we’re all really excited about right now. What is the the kind of the biggest driving factor behind Policy Engine is all of To the kind of feedback that we’re hearing from companies about how the hardest thing for them to do is actually give software engineers — like the actual people who are building the applications that back some of the greatest software that we use day to day — is actually giving them the power to enable them to actually like build and deploy their software. And a lot of that problem, a lot of that kind of like worry, and stress comes from the fact that there are all these like organizational policies that have to be kind of implemented. I would say that historically, most organizations are using something like Jira to enforce these policies and kind of “mechanical turking” their way around enforcement. But what we’ve found is that the large majority of risk for violating these policies happens at deployment time. And so that’s why we see Spinnaker as like the best place to start implementing some of these, and automating and codifying these policies. And so we’re doing that with Open Policy Agent, which is kind of the policy decision maker in the background. It’s a pretty hot technology in the cloud native landscape right now. But what we’re doing is actually bringing those hook points into Spinnaker, to actually let you start codifying these policies. And what that actually enables us to do is, is take all of the manual toil of, of like approving or rejecting Jira tickets and all of these other ways that you do policy enforcement, and actually automating that and bringing that into kind of the first line of defense, as you can say.

DROdio: So when I speak to Engineering Leadership, the thing that I just hear over and over and over again at these Global 2000 companies is that they want to innovate faster, and it just ties in so well with what you’re saying, Ethan, because companies have all of these policies in place for a reason, but they also really slow the company down. And this hodgepodge network of policies that have to be enforced, being able to do it in a much more consistent and streamlined way and a “Golden Path” that’s, that’s the same for all developers when a company has thousands or tens of thousands of devs is a pretty attractive thing. So maybe we can talk a little bit about what’s in market today with armory, but also what’s coming like how are we evolving that?

Beth: I think in looking at that some of the things that we have right now is the Policy Engine that uses OPA. And the great thing is that OPA is the Open Policy Agent, and it is much loved by a number of security folks. And the win there is — and I’m going to talk a little bit; I’m going to bounce around a little bit — the win there if you have like this culture clash internally with our customers. Which is a long standing culture clash between the DevOps team and the Security teams. Quite often when we go in, our our product Armory is going in, and we’re working with the DevOps team. So how do you get Security teams to buy in? Well, they actually love and already use and a lot of ways and expect to use OPA. So we’re actually working on meeting our customers where they’re at, by understanding just simply some of the tensions that our customers have internally, and helping them to bridge that gap. So I mean, that’s, that’s a gap that people are going to need to face. And we’re helping to build; we’re removing that challenge in a lot of ways, based on simply the technology that we’re using, because Fernando and I, we’ve talked about how our internal users often have fandom in terms of the tools that they use. And so you may love Spinnaker, you may not love Spinnaker, but what I want to make sure that we pull out is the fact that Armory is working on building that connective tissue tissue to help people. So taking it back: What do we have today we are working on a open source, or not an open source; It’s a plugin for Policy Engine that’s going to allow you to create those policies. You can use it with both open source and enterprise. The great thing there is you might love we have some of our customers that are using open source Spinnaker, but they also want to have some proprietary features that are going to help them with that security piece. We’re actually working with Security teams to help partner with those DevOps teams to build that feature functionality. And, and with that, it’s really it’s going to help with permissioning. So to go back, I don’t actually like using RBAC because RBAC has so much “feel” behind it. So I like using the concept of “least privilege” because I think that’s really what it is. What we’re talking about when we’re talking about role based role based access control is: “Who is what is the least amount of privilege or the most amount of privilege that you need to have?” So Open Policy Agent with our Policy Engine is helping to do that. So it’s actually it’s super exciting. And then what we’re doing — I know Jacob has been forced to sit in a number of meetings. He’s like a great sport where I just send him a link and he clicks on it, not knowing what kind of meetings he’s going to land in. Sometimes it’s internal, and sometimes it’s with customers. So talk about some of the stuff that you’re hearing from customers.

Jacob: Yeah, thanks Beth. I think that this has sort of been an interesting development cycle because we on the inside can see a lot of possibility. We see a lot of cool features but actually showing the customer what’s possible to get the feedback we need has been a little hard. And so we originally, Armory, we came out with this proprietary Policy Engine feature that was like Fernando and Akshay were mentioning the “saving the pipeline, you can verify what’s being saved to your pipeline as you’re building it”. And that was the initial feature we rolled out. And as we worked on that, we’ve been able to get some feedback from customers about what was working what they want to see. And I remember specifically that conversation with the customer where they said, they said, “if you had the ability for us to validate what’s happening at the execution of the stage in a pipeline,” he’s like, “it would solve all of our security problems right now.” And that was that was one nugget of several conversations with customers that really sunk in for me, and we went back to the drawing board and figured out how can we deliver on that and that’s the thing that that makes us working on. Probably the past month is finding how to how to deliver that for the customers that need the validation of execution before execution of a task, that pipeline after an execution of a task, the pipeline and bringing that out in such a way where they can use it and they can leverage that in their production code.

DROdio: By the way, I just love the way that we build products at Armory — to to be such a good sport, Jacob, being thrown in on external customer calls and just really listening and understanding and working with the product team to figure out how to solve those problems. It’s just so so core to our DNA and the way that we we build value. So that’s great. It’s really great to hear these stories as well. I guess I would also mention, I heard you talk Beth about doing this as a Plugin and I think it would be good for us to talk a bit more about what that means. This Plugin framework is relatively new, and it gets back to this this larger reason that companies buy Armory, which is the ability to to make their entire SDLC work more effectively together. And so I don’t know if anybody would like to just talk a bit about what it means to be able to consume something like this as a Plugin. I think that’d be a great a great thing to explain.

Ethan: I’m happy to kind of explain a little bit of that, or Akshay, Fernando? Would either of you prefer to, to take that one?

Akshay: Sure I can try to the right thing that we’ve been developing recently, what we’ve committed this to open source Spinnaker is the ability to add capabilities and features without having to commit directly to the main Spinnaker codebase. One of the biggest hurdles previously was whenever you wanted to add a new feature or anything like that, you’d need to actually commit or fork the entire Spinnaker code repo and that was a lot of work with extensions and plugins added. Now you can just write a small snippet of code that does what you need. And you don’t need to modify the main codebase and you can augment the capabilities that are already available. So even the work that’s being done by our team around Policy Engine, making it a plug in allows people to use the open source Spinnaker if they want to, and then just add on our Armory features without having to switch to Armory version of Spinnaker. And the nice thing I want to mention also, with the Policy Engine integration with our Pipelines as Code is that we make it very seamless, you know, you create policies, and then when you’re creating a pipeline using our feature Pipelines as Code, if you create a pipeline that does that, violate one of the policies, there’ll be a clear error message indicating which policy was violated. So we’ve worked hard to make sure that that, you know, the experience is very seamless across the board.

DROdio: This is really exciting. And I know, Fernando, you’ve been working on CI/CD at a large Fortune 20 company in the past. And so I imagine you probably have a really good understanding from the the the other side; from the users perspective, about what what you think this could be as we evolve it to really solve some problems that these large enterprises are having. What else would you say here about what what this could turn into?

Fernando: Yeah, totally. So one of the things that we’re super excited about as we continue to mature that Policy Engine offering is the ability to build trust in the changes that we’re making with our Pipelines as Code pipelines. So one of the one of the problems that I’ve seen in the past and that we’ve heard from at least three different customers over the last month is that people write these pipelines and then they’re scared to change them because they’re not sure what that change is going to look like. Right? So if I have a pipeline that takes my service and deploys its production, but now I want to duplicate it and deploy to test instead, a lot what a lot of a lot of times what people end up doing is they end up building these like Byzantine test frameworks to kind of like validate what’s happening at the code level without actually executing the pipeline. And that’s usually like bespoke, it’s custom to whatever tool you’re using, especially if you’re just like, validating JSON files, right? Like, there’s really a good way other than writing expectations against that, to test them. So one of the things that we’re excited about is building in functionality for Policy Engine to allow you to write policies that essentially validate the behavior of the pipeline before you actually save it. So if I am Team A and you know, I’m committing a pipeline, and I want Team B to use that pipeline, I don’t want them to deploy my service; I want them to deploy their service. So you can actually write or, you know, as we’re building this functionality out, you’ll be able to say, okay, it’s “saving this pipeline, only Team A can deploy this application”. So we’re really excited to start building enough functionality so that you can make more complicated assertions about what’s happening in pipeline, before you actually save it, and then get some useful messaging back around, you know what went wrong. So there’s that kind of like “security validation” side but there’s also this aspect of “building trust in the changes that you’re making”. So unit testing is good for building software. We want that functionality for our pipelines as code offering as well.

DROdio: So there’s so much goodness coming here; I am just really thankful for the level of sophistication that all of you are sharing that is this mix of what we’re seeing from customers, where we have customers all across the spectrum; we have the more progressive cloud native customers that are just scaling and their entire business is built on their ability to deliver software. And then we have these really large enterprises that are in this very intentional, now, Digital Transformation process and really trying to understand “How do I do this at massive, massive scale with a lot of complexity with thousands or tens of thousands of devs?” Our ability to just be in that intersection and share the knowledge that we have about what not only we’ve built, but what what we can build, where we’re going. It’s just it’s a beautiful thing to just talk about it with all of you and brainstorm here and just just understand when I’m talking to these Global 2000 engineering leaders, the way that I can share all of this with them. So I guess, thank you for helping build the future! It’s it’s really great to have all of you so focused on this. And for anybody who’s watching this, who doesn’t know as much about Armory, we would be happy to talk to you about how we can help you unlock innovation by making software delivery continuous, scalable and safe. What we typically see is that companies think they either can be “secure and safe and compliant”, or they can have “velocity and innovation”. And we’re really here to say that there’s a way to get both and it’s really about increasing the sophistication of the underlying platform, versus all of these homegrown hodgepodge tools. Instead, moving to this modern best in class platform, that Armory is based around, Spinnaker. And using that as an actionability point, through these Plugins to really unlock a lot of the other systems of record that you have and make them all work better together. There’s a there’s a huge opportunity to be safe, but also to be able to do it with a lot of velocity. And we’re here to make that happen. So thank you. Any other last parting thoughts from anybody that they want to share before we jump off? No. All right. Okay. So if you’re watching this, and you’d like us to do this more often, we’re doing one of these to see how it goes. We’re obviously really heads down focused on building the future. But to the extent that we can kind of stick our heads up for a minute and just talk a little bit about what’s coming, we’re happy to do that more, if it resonates, so let us know if you’d like to see more of this and thank you all of you for for taking the time out of your busy days to do this. Really, really appreciate it.