The Evolution of IaC, GitOps and Open Source Security

[ad_1]

Infrastructure is now declarative language-based rather than defined through the use of screwdrivers. While the software life cycle revolves around the CI/CD pipeline, deploying all elements of the software stack from app to infrastructure can be done through GitOps. Loris Degioanni, Sysdig CTO and founder talks with Mitch Ashley about infrastructure-as-code (IaC), shift-left security, GitOps, Sysdig’s recent acquisition of Apolicy and the announcement of Sysdig’s automated service integration for open source Prometheus automated discovery, labeling and metrics. The video is below, followed by a transcript of the conversation.

Announcer: This is Digital Anarchist.

Mitch Ashley: I have the great pleasure of being joined today by Loris Degioanni, who is CTO and founder with Sysdig. Good to be talking with you, Loris.

Loris Degioanni: My pleasure. Great to be hear.

Ashley: Love to hear some more about you. Tell us a little bit about yourself and tell us a little bit about Sysdig.

Degioanni: Yeah. So I’m the founder of Sysdig. Sysdig is my second company. My first company was called CACE Technologies and was the commercial entity behind an open source network analyzer called Wireshark. So I’ve done open source my whole life. With my first company more like revolving around network packets, and with Sysdig, my second company, revolving more around security and visibility for containerized Kubernetes and cloud infrastructures.

Sysdig is a secure DevOps company and we’re a product family that specializes in tools that follow the life cycle of applications that are deployed for containers and for the cloud, and also we offer shift left and real-time security. We offer on-time security and we offer also forensics _____ in a complete lifecycle.

Ashley: Fantastic. Yeah, it’s sort of the whole infrastructure-as-code in containers, of course. Super popular. Very hot topic. Let’s do this. I’d love to get your thoughts on sort of the state of infrastructure-as-code, because now we’re talking about essentially the full range of what all the kind of products and tools that you have operate within, because I’ve been doing a lot of talking about how DevOps needs to think of itself as a dynamic.

Everything is changing, right? It’s a fluid, it’s not a solid. And that’s very much the world as infrastructure-as-code, because anything can change at any time. It can be ephemeral. So the ability to know what’s happening, what happened, where you’re going is a different model. It’s a different kind of thinking. What’s sort of your assessment of where we are, where we’re heading?

Degioanni: Yeah. So from this point of view, definitely the world is changing. The way we are writing our software is changing. The pipeline, the CI/CD pipeline is becoming the king, the center part of our existence as developers, which we do everything. We do our builds, but we also do security. We do our management. The tested with the lifecycle of our software revolves around CI/CD pipeline. And infrastructure-as-code sort of follows, in my opinion, the trend. We are moving from the time when infrastructure, deploying and delivering infrastructure, it was something that was related to screwdrivers, inputting servers on the rec. Now we’re moving –

Ashley: Rack and stack.

Degioanni: Exactly.

Ashley: We don’t say that much anymore, do we? [Laughs]

Degioanni: Exactly. You and I are probably old enough. The young generation doesn’t even know what that is anymore. Now you provision your software typically from a datacenter or even more likely nowadays from a cloud provider. And infrastructure-as-code is the evolution of this that allows us essentially to specify, to declare our infrastructures as a piece of software, as a declarative language. This is from one point of view in its evolution, because since we are just provisioning software on somebody else’s infrastructure, we just need to give instructions for what we need.

And the best way to give instructions to some external service is a code, is an API, is a definition. But at the same time it’s revolutionary because when we start treating our infrastructure really like it’s code we also start having all of the potential approaches with our code. And for example, GitOps is one of them. Right?

Ashley: Oh yeah, very much so. I mean, that’s only possible because when we become all software very much so.

Degioanni: Exactly.

Ashley: So often when we say infrastructure-as-code folks immediately go to Terraform. That’s what it is, and it’s much more broadly defined than just one tool, as great as Terraform might be. As you talked about the heartbeat of software being that CI/CD pipeline, is there a way that you think of infrastructure as code across that pipeline? Is that sort of how you build a mental model of it? How do you define it?

Degioanni: Yeah, very much so. And Terraform, of course, is super popular and super important. But to Terraform, which is becoming more and more like the cornerstone of declaring your infrastructure, for example, for the cloud, I would also add Kubernetes. Because in practice, when we are running services on top of Kubernetes, Kubernetes is completely declarative. So while maybe Terraform is more like at the machine level, Kubernetes allows us to declare our infrastructures at the service level, at the team level, at the dependency level.

So it’s more like these two files really coexist more and more and cover two very important aspects. And of course that ties to your comment about the CI/CD pipeline, because then when both our, let’s say, host declarations and infrastructures and also our services are all essentially stuff that is more or less YAML files then it’s very natural to put them and version them on a server like Git server or something like that, and then you can start doing with them stuff like, for example, Security-Net, which is something that Sysdig specializes too. Because the same way we talk about shift left when we secure our code and get closer and closer to where the culture resides, where the developers essentially manage this code in the Git repository, same with infrastructures. We can go left and we can start securing them early on in consistent way that reduces the mistakes and makes all of us more efficient.

Ashley: A mental model I’ve started to use, talking about this when people ask why is this so different than how we normally think about software architectures, how we create apps, I describe it as think of a solid cube and think of it as a Rubik’s cube, of a lot of elements comprised together that can be mixed in a variety of – and that’s changing constantly, and that’s kind of the environment that we’re in. And so you bringing up the security topic too, oftentimes security is sort of one of those last steps. Testing, security, compliance, documentation, we’ll talk to those folks at the end. Now of course shift left, that’s got to be built into that fabric, that architecture, that software architecture, that infrastructure throughout it, because that’s why we have the observability and things like that. It’s that you can’t treat it as looking at it from the outside, right?

Degioanni: And this is even more for i
nfrastructure, because with code at least at this point it’s pretty well accepted that, okay, it’s a good thing to start worrying about security early to expose security to the developers. And security at that point can really not only be an afterthought but can also be something that is actively recommended to you. With shift left security, we can have, for example, security tools automatically open a pull request for you, so when they detect something that you’ve committed that is not right from the security point of view. And as a developer that is actually a great benefit.

Imagine applying these two infrastructures. So there’s a lot that we can do in terms of defining policies and good practices for our infrastructures in terms of – imagine something very simple, but making sure that no machine gets started with a default password, for example, or with some unhealthy network configuration settings or stuff like that. We can encode these into policies and then we can tailor where to locate. Whenever one of my development teams declares an infrastructure for Terraform, for Kubernetes and so on, go and enforce that and maybe open a PI so that the developer doesn’t even have to ever worry too much…

[ad_2]

Read More:The Evolution of IaC, GitOps and Open Source Security