devopsy.kinsta.cloud

Tag: container security

  • Kubernetes and Service Mesh With StackRox

    Kubernetes and Service Mesh With StackRox

    DevOps and Kubernetes enable organizations to “go with security,” adding security to the code instead of on top of it. In other words, security is built-in rather than bolted on.

    This is one of the aspects of security in the DevOps world with a Kubernetes system that Ali Golshan, co-founder and CTO of StackRox, explained during this exclusive interview with Alan Shimel, Media Ops CEO and editor in chief. The other aspect is security has become continuous instead of snapshots, which provides “a lot more visibility into various stages, various deployments, as well as running environments,” he said.

    During the interview, he explored containers, orchestrations, Kubernetes and service mesh.

    “Leveraging this cloud-native infrastructure, Kube and service mesh the right way reduces your dependency on third-party tools, allows you to hand off things you typically handed off to vendors and does that inside your infrastructure, which makes it actually more secure and highly scalable,” said Golshan. “You can automate that and reduce your lock-in and your sort of dependency.”

    Check out the interview below to learn more about the best and emerging practices in Kubernetes, service mesh and the security feedback loop.

    — Veronica Haggar

  • The New Era of Kubernetes, With StackRox

    The New Era of Kubernetes, With StackRox

    Orchestrators are becoming the operating systems of cloud for the future. Which one do you think has become the dominant one? Ali Golshan, co-founder and CTO of StackRox, placed his bet on Kubernetes right from the start.

    StackRox is a Kubernetes-native security platform that helps DevOps and security teams operationalize security, providing richer context, native enforcement and continuous hardening.

    During this interview with MediaOps founder and editor in chief Alan Shimel, Ali discusses the adoption of Kubernetes and its prevalence today. More companies are realizing they can’t use traditional security. The tooling has to be native to the infrastructure they’re using, it must integrate into the build and the deployment. And Kubernetes is the best solution available, he said.

    Check out the interview below to learn more about microservices, containers and Kubernetes.

    — Veronica Haggar

  • Autonomous Security in Containers

    Autonomous Security in Containers

    With the advent of DevOps, the development world has quickly moved to agile development practices and containerized applications. At Forum Systems, we have responded to this trend by putting our API security software, Forum Sentry, into virtual form factors such as Amazon Machine Image, Azure Image, VMware Image, Linux, Windows and Docker.

    Why do we feel it’s necessary to containerize API security in this way, and what benefits does it deliver over traditional software or even hardware-based API security?

    What Is API Security?

    Before we explain why we containerized our API security software, it is first necessary to define exactly what we mean by API security. As a result of the major IT trends of the last decade–in particular cloud, mobile and IoT–more people and applications are connecting to IT assets than ever before.

    What’s more, the majority of these interactions are from untrusted entities outside the organization’s network perimeter (and as you will read below, across container boundaries). Securing your organization’s systems, data and business-critical processes is harder than ever.

    Almost every interaction relies on an API to communicate to an application or system somewhere in the world. The simplicity of APIs makes it easy for developers to connect their projects to other systems to enhance their functionality, with data being easily shared between a myriad of external partners, cloud providers, virtualized data centers and on-premise applications.

    As a result, APIs have become the primary channel for business transactions and the traditional boundaries of data exchanges have become blurred. APIs provide many benefits but also present risks, as wherever there is innovation, there is also the dark side of threat and attack, and always someone who will aim to exploit weaknesses.

    In many environments, APIs and their underlying technologies are designed primarily to share data; they are not designed to thwart threat and attack. This is where API security gateways are necessary to validate both the data and the identity of users, systems and devices interacting with the API.

    API security goes far beyond just access control, it requires specialized technology to perform dynamic data security to inspect and ensure the specific and unique characteristics of each API communication are correct. The API security policies are designed to prevent intrusion, data leakage and other forms of data loss as a seamless and transparent part of the technology architecture.

    API security gateways differ greatly from API gateways; the key word “security” immediately distinguishes this technology from simple API gateways, which serve only to provide proxy and simplified access control points. API security gateways are purpose-built to protect against API threats, and the dynamic data security capabilities they offer provide centralized protection of bi-directional API communications. API security gateway technology provides essential risk mitigation at each layer of the API architecture, and as rising adoption of containers and micro-service architectures arise, it provide zero-trust concepts within and across the container boundaries to protect the assets and technologies therein.

    Why Containerize API Security?

    Container technology such as Docker has become a popular means to deploy API micro-services, a collection of loosely coupled services which are fine-grained and lightweight. The move toward virtual and cloud was initially driven by fully virtualized images with their own operating system, but the adoption of lightweight services and on-demand environments has led to widespread adoption of container technologies run on a shared operating system. These container architectures provide flexibility and ease of deployment, but come with the same set of API risks.

    The concept of containers also brings into focus the trust model that needs to be considered for communication among technology components within and across containers. Containers become a new API boundary layer and thus represent the same type of risk paradigms, where a rogue container application can gain access or otherwise wreak havoc if the proper security controls are not put into place (commonly known as an insider attack).

    By deploying API security directly into a container, organizations can automate their API security into their existing workflows and provide zero-trust security capability that ensures real-time enforcement and protection of container-based APIs. This means API security becomes autonomous and baked into the architecture, rather than tacked on at a later stage.

    As mentioned earlier, dynamic data security is essential wherever information is traversing. The traditional cyber umbrella approach no longer applies in the interconnected API world. It’s like using an umbrella in a water park, it may stop the water from the top, but not from the sides. By having automated API security at the container and virtual layers, the ability to visualize, connect and secure information becomes an integral (and necessary) aspect of the container security strategy and a fundamental baseline for secure API enablement and trusted data exchanges.

    API security gateways deployed as container nodes allow DevOps teams to harness the power of virtualization, cloud computing and containers while at the same time protecting the organization against API threats from both the inside and the outside. With API security baked into the container, developers are free to focus their time on building the best functionality in their apps.

    — Jason Macy

  • Kubernetes Adoption: Are You Ready?

    Kubernetes Adoption: Are You Ready?

    Enterprises are rapidly embracing a cloud-first strategy and microservices play a pivotal role in this journey. But enterprises are achieving various levels of success, measured by many factors includingmaturity of DevOps in the enterprise, ability to identify the right candidates for microservices, selecting the appropriate container management platform, adequate tooling and, finally, cultural shift in design thinking.

    As there is plenty of material around microservices adoption and strategy, this article focuses on the container management ecosystem, which plays a critical role in the success of microservices adoption. Today, Kubernetes has become the de facto platform for container orchestration. Most public cloud providers offer Kubernetes as a service in some form to abstract the complexities of managing Kubernetes as a platform.

    Currently, we see three broad patterns of how enterprises are adopting Kubernetes within their organizations.

    Pattern 1: Kubernetes as a Managed Service

    While Kubernetes makes container management somewhat simple, it is still a complex beast to understand and manage as a platform. Enterprises that have already embarked on a cloud strategy find it easy to test the unchartered waters of Kubernetes by leveraging Kubernetes-as-a-service provided by their cloud providers. It enables them to understand the impact of Kubernetes on their respective application architecture strategy and identify the gaps in their systems (such as the maturity of DevOps management, security management and release management) as well as their monitoring capabilities.

    Pattern 2: Kubernetes as a Turnkey Solution

    Certain enterprises driven by industry regulations and are technology-focused (with considerable experience in other container technology solutions), have shown interest in setting up Kubernetes as part of a private cloud or on–premises with a view to avoid vendor lock-in and limited control associated with managed Kubernetes. There are many such turnkey solutions out there to choose from.

    Pattern 3: Self-hosted Kubernetes Platform

    This category is small compared to the other two categories. However, there are a few enterprises that fully embrace the open source software development model and contribute to Kubernetes community. There are tools and frameworks that can enable the enterprises to setup and manage Kubernetes on their own.

    There are advantages and constraints in adopting any of the above approaches. The decision regarding which strategy to choose depends on the maturity of the enterprise and their business strategy.

    Challenges in Adoption

    Some of the key challenges to be considered, irrespective of the adoption pattern selected, include:

    1. Namespace management: Namespaces play a key role in managing the isolation across application domains and environments, providing controlled management of resources and user management. Bounded contexts can be linked with namespace definitions and standards. It is important to define proper naming guidelines to drive namespace management across clusters.
    2. Resource management: It is necessary to define resource utilization (resource quota) guidelines to ensure the containerized applications co-exist without being eliminated due to resource violations at runtime.
    3. Policy management: It is critical to define appropriate policies including cluster access controls, service access controls, resource utilization controls and secret access controls.
    4. Audit and compliance: It is important to audit the platform for patch levels, secret stores, compliance against the security vulnerabilities, encryption of secret stores, storage volumes, cluster policies, role binding policies and user management controls.
    5. Chaos testing your platform: It is necessary to subject the platform to chaos testing to ensure the robustness of the cluster. It also helps to test the stability of the containerized applications and the impact of crashing these containers. It will also provide vital information about how the platform behaves during high loads or when resources are unavailable for the platform.
    6. Managing the deployment manifests: Kubernetes follows declaration-based management, which means that every object or resource instruction is described through declarative manifests. This leads to versioning complexities, prone to human errors and data corruptions. It is necessary to leverage tools or create custom utilities to manage these manifests.
    7. Observability of the platform: While Kubernetes provides various mechanisms to monitor its own internal components, it does not recommend a standard monitoring approach. It is necessary to introduce well-defined health management standards while designing the microservices. Include appropriate probes for liveness and readiness probes in every containerized application deployed on Kubernetes cluster. Integrate the probe-generated metrics and platform-generated metrics with an external monitoring platform to have comprehensive observability of the cluster.
    8. Continuous deployment of services: It is not recommended to use kubectl-based deployments in a large-scale production setup. Instead, use some of the established open source frameworks specifically built for Kubernetes (such as Helm or JenkinsX) to manage seamless deployments.
    9. Archiving and backup: Kubernetes uses etcd as its internal metadata management store to manage the objects across clusters. It is necessary to define a backup strategy for etcd and any other dependent persistent stores used within the Kubernetes clusters.
    10. Container security management: Kubernetes deploys the applications by downloading the respective images from a pre-defined image repository. It is the responsibility of the repository ecosystem to ensure the image provenance of the images being deployed. Continuous security must be included as part of DevOps pipeline to ensure containers are well-managed.
    11. Service mesh support: Service mesh plays a critical role in streamlining the service to service communication. It abstracts the service level access controls and security management between services through externalized policies. It also provides routing and load balancing features. It is necessary to choose an appropriate service mesh that is compatible with the Kubernetes cluster as well as the underlying infrastructure.

    Conclusion

    Kubernetes makes the container operational aspects simpler, but it requires a methodical approach and best practices to ensure smooth maintainability, as well as seamless developer interaction. For any enterprise which are in a transition journey toward adopting Kubernetes, it is imperative to have a strategy for Kubernetes adoption to ensure success.

    — Sreekanth Nyamars

  • DevOps Chat: Aqua Security Talks Funding, Security in a Cloud-Native World

    DevOps Chat: Aqua Security Talks Funding, Security in a Cloud-Native World

    Aqua Security, one of the leaders in container and cloud-native security, recently announced it has raised $62 million in a “C” round of investment, led by Insight Partners.

    In this DevOps Chat, we speak with Rani Osnat and Andy Feit of Aqua Security about how this validates the cloud-native security field that Aqua has helped develop.

    The video of our conversation is immediately below, followed by the transcript of our conversation. An audio version is also available on Soundcloud.

    [videopress 1pfe0tRG]

    Transcript

    Alan Shimel: Hello, everyone. It’s Alan Shimel, devopsy.kinsta.cloud, Container Journal, Security Boulevard for MediaOps and I’m really happy to be joined by my friends from Aqua Security. Charge of product marketing, we’ve got Rani Osnat, and, in charge of go-to-market, Andy –

    Andy Feit: Go-to-market, that’s right, Alan.

    Shimel: – none other than Andy Feit. Both of these guys are familiar to our audience or you’re both familiar to the audience – you’ve been on – but, guys, first of all, congratulations, mazel tov, whatever you wanna say. Big news today with Aqua. You guys raised a Series C, I believe it is, for $62 million.

    Feit: Yeah, thank you, Alan.

    Rani Osnat: Thank you, Alan.

    Shimel: Congratulations. So let’s talk about what this means, guys. So, first of all, it looks like this round was led by Insight Ventures, correct?

    Feit: Yep.

    Shimel: And I don’t know if we know; who is the Insight partner kinda leading the charge on this?

    Osnat: It’s Jeff Horing, was the _____ –

    Shimel: So I know Jeff and he’s one of the senior people there. Will Jeff be joining the board of directors?

    Feit: Yeah, so Insight will have a board seat.

    Shimel: Okay. Will it be Jeff, though, or you don’t know at this point?

    [Crosstalk]

    Osnat: Yeah, we’re not sure that it’s gonna be Jeff.

    Feit: We’re not positive, yeah.

    Shimel: Okay. I don’t mean to ask any trick questions, so don’t worry. So, Andy and Rani, you know, what I thought was interesting in reading the release was, yes, Insight did lead this round for $62 million, but a couple of things to note. Number one, your existing ventures, Lightspeed, Microsoft or M12, M7, whatever they call it –

    Osnat: M12, _____.

    Shimel: – Shlomo Kramer. You know, your existing venture investors all participated in this, correct?

    Osnat: Correct. Yeah.

    Shimel: And that says something, right? People believe in it enough to keep writing more dollars into it. Kudos to the Aqua team ’cause that does mean something.

    Osnat: Yeah, and it has been like that in all previous rounds as well, so we’ve always had the existing investors continue to participate. And I think, from their perspective, obviously, this is – they’ve taken – especially the early investors, like Shlomo Kramer and then TLV Partners, have taken a risk, investing in a very early-stage startup with an uncertain market. And now a lot of that risk is gone – you know, you can never know, but it’s a much more solid proposition than we had _____ _____ ago –

    Shimel: Well, it certainly less risky than a raw startup, but, you know –

    Osnat: It’s less risky, and so they deserve it.

    Shimel: – from an investment point of view, when they – it’s almost doubling down, when they continue to participate. Right? That’s saying, “I believe in this enough that I don’t wanna be watered down in my stake in the company, and so I’m gonna invest my pro rata or per-capita share so that my stake in the company remains constant, not decreased or watered down as they raise more money.” So it is very significant.

    The other thing I just wanted to mention is, hey, this brings the total raised, I think, to $100 million, maybe a little over $100 million.

    Feit: Just don’t round down, yeah.

    Shimel: I was doing the math on my fingers; I ran out of the toes, but I knew it was close. But the obvious question then becomes “So does this move Aqua into a unicorn, where you have a valuation of a million-plus?”

    Feit: Yeah, we’re not really sharing the details on the post-money valuation here. One of the nice things about being a privately-held company: you don’t have to share all those details. But, obviously, the number’s more than $100 million and we’re excited about bringing in a new investor that’s actually more than just bringing money to us. And I think what’s great about Insight is how involved they are, how well they know the space, the introductions they can make to partners as well as end-user customers. And this is really – they are a late-stage investor that knows what it takes to make a company successful.

    Shimel: No doubt about it. As we were talking off camera before, I have a relationship with Insight for a number of years now and, look, I’ve seen them invest in many companies that I’m very familiar with – some of them, I’ve worked with. Companies like FireMon and JFrog and Tricentis, Aquanow, and others. So, I mean, their record kinda speaks for itself. And I will tell you, more than just writing a check, I’ve seen firsthand, right, what they’ve done. I mean, frankly, we’ve talked about working with them here at MediaOps, in doing something for their whole portfolio, right? And great company. You couldn’t pick a better partner, in my opinion.

    Feit: We definitely feel that way and it’s impressive how well they know the space. Through the due diligence process and even –

    Shimel: No doubt about it.

    Feit: – here at the meeting, they’re digging in. And the fact that they spoke with our customers, they met with our team, they looked at our product, they went through it – it’s a testament to how far we’ve come and we’re excited about that.

    Shimel: Great. So let me pivot now. So, again, congratulations on the raise. That’s a significant amount of money. It means you guys can do some great things. In reading over or perusing the release, though, I saw some other kinda subtle changes in messaging, and that is I knew Aqua or many of us may know Aqua as a container security company. And now I see the messaging changing to more a cloud-native security company. Let’s talk about that. What does that mean, Rani?

    Osnat: Yeah, I think, when we started out, the market was different, in terms of adoption and also in terms of the technology landscape. A lot of the technologies that are now maturing were really experimental at the time – and we’re not talking about a long time ago; it’s three and a half years ago – but things like serverless, for example, that are catching on. They’re not as big as containers yet, but, if you believe some of what the proponents say, they will be bigger.

    And, in general, I think there’s a trend to look at this cloud-native space, for lack of a better term, as something that is supporting the next generation of application development, application deployment, and runtime environments, where cloud-native doesn’t – it’s not equivalent to cloud, right? I mean, you could run things in the cloud that are not cloud-native and you could run cloud-native applications on-prem as well. But the whole notion is that you support this very Agile, microservices environment that is portable, interoperable, and you can update it very frequently. It’s very resilient – you can update different pieces without impacting other pieces.

    And the benefits to enterprises that adopt these technologies are huge, and so that’s why it’s catching on. And we’re at that stage where we see not just the breadth of adoption across the industry, in terms of the number of companies that are actually using it, but also how deep it goes and how wide the adoption is within a given company. So we’re still at an early stage, but we see how a lot of enterprises like banks and insurance companies, not the tech industry itself, are looking at these technologies as strategic to their objectives – digital transformation, customer centricity, all those things.

    Shimel: You know, I was telling someone in the office here this morning, “We live in such interesting times if you’re a tech person.” Right? I think bank to my first Web hosting company in 1995 and what it meant to rack up a server.

    Osnat: Right.

    Shimel: Right? Set up a server for someone. My ops people walked around with tool belts, with pliers and screwdrivers, right, ’cause you had to literally screw in the server into the rack. It’s a different world; it’s an amazing world. Here’s another just something I wanna throw out at you: when we talk about things like serverless and we talk about what Kubernetes brings to the picture, it almost – there’s a place for everyone here. It’s not just the cloud, like we’ve seen with AWS or Azure or Google or Alibaba or – you know, the data center is back.

    Osnat: Right. Yeah, I –

    Shimel: Right? And there’s now _____ serverless stuff, right?

    Osnat: Yeah.

    Shimel: And it’s still native.

    Osnat: Yeah, absolutely, and we think if you really kinda distill it, from a technology standpoint, to one thing, we’re talking about a complete abstraction of the application layer from the underlying infrastructure. Right? So that’s –

    Shimel: That’s it right there. Mm-hmm.

    Osnat: – moving into a serverless world, but “serverless” not in a narrow sense of serverless functions that we have today but “serverless” in the wider meaning of the word, where you really don’t have to manage any servers. And any technology that aligns with that concept is legitimately cloud-native and we need to support those technologies.

    And, even today, there are many choices, right? You can do everything from running containers on VMs to running containers on bare metal to using container-as-a-service type solutions or serverless containers, like Fargate and ACI, and, of course, serverless functions. And there will be a lot of things in between that. We’re already seeing some technologies that are still very early-stage, like micro-VMs or hybrid container VMs, and this will all have a place because, ultimately, organizations will choose the technology that serves them in the most optimal way, without necessarily being married to one particular technology.

    Feit: And I would just add, Alan, I think the common theme between these technologies is the dynamic nature of the infrastructure and the ability to spin up, whether you’re spinning up a VM or requesting a microservice run for 70 milliseconds on a function. It’s happening over the course of the day, over the course of an hour, over the course of minutes. That network is changing and your security infrastructure needs to understand that. And the old-school models of securing these platforms didn’t work before and it’s only getting harder with things like microservices and moving to serverless architectures.

    Shimel: No, I agree. I think Rani hit it, actually, right on the head. We’re just seeing this abstraction where that whole infrastructure is so liquid, right, and so dynamic that you almost – you need to secure it, obviously, but the mission of securing the application, irregardless, wherever it’s _____, of the infrastructure, is a mission in and of itself as well.

    Feit: Which means you need to understand how _____ _____ _____.

    Shimel: And you still have to play nice.

    Feit: Yep. Yeah, you need to understand the application part of it, go with it wherever it’s running, and that’s really the magic of what Aqua does.

    Osnat: Right.

    Shimel: Yeah. Well, and I think that that is the magic, right, and that is the mission. Go with it wherever it’s running. Let me turn back. So, you know, some fresh fuel in the tank. What does the $62 million mean? Let’s talk about it just in terms of go-to-market with you, Andy, but, Rani, let’s talk what does it also mean in terms of product? In this new – I mean, one could say that – saying, “Hey, we’re gonna secure cloud-native. Gives us a bigger surface to play on, a bigger playground to play in.” Go-to-market’s a challenge, right? Both? Let’s hear.

    Osnat: Right. Yeah, I mean, so we’ve been – one of our key advantages in this market has been platform support and being able to support different clouds, orchestrators, operating systems, and modalities of cloud-native, right? And, as we see things right now, the market is not – it’s been consolidating around Kubernetes as the orchestration platform, but, at the same time, there are many different flavors and there are different dependencies, on where you’re running, et cetera, that have to be addressed.

    So we already are supporting a very large matrix of different technologies and combinations of those technologies. And, as the market continues to hold, we’ll need to continue to track that, so not just support them but actually provide deeper security controls at each level and at each step of the way because we’re not only a container security solution, as you pointed out earlier, but we actually provide this support for various types of cloud-native technologies, various pieces of the stack, and also the full life cycle. So, starting from their early stages of development and CI/CD, going all the way to production environments. And this requires investments in R&D.

    Additionally, we also have been investing in open-source tools, specifically around Kubernetes, and we will continue to do that and not only expand the capabilities of those tools that we’ve already put out there in the market but also add new tools. And we do that as part of our philosophy of educating the market, getting out tools that anyone can use, and then, when they get to large production environments, they’ll probably come to us for a commercial solution, with all the benefits of commercial interoperability and support and all that. So that’s – part of the money goes there, obviously.

    Feit: And part of the money definitely goes out to build the infrastructure, whether we’re talking sales globally. We’re working with some of the largest customers – companies in the world today and they have a global presence, but, as we go to market and look at growing the business, we have a proven model at this point. I mean, that’s what happens when you get to this late-stage investment. They’re looking for “Do you have customers? Could you do more of them if you had resources in various countries? Could you scale out more by solving more of their problems across divisions and departments in those enterprises and up-sell and cross-sell?”

    And then the support infrastructure. One of the things that has really differentiated Aqua, when we win our business – and we’re in a competitive marketplace, but one of the things that really drives us is our ability to be on site with a customer, to support them through their deployment, to be truly invested in their success and integrating with their CI/CD pipelines, integrating with their secrets management, integrating with their SIEM tools. Our solution is not standalone; it’s not a double-click install of a SAS solution. This is part of your entire application development life cycle and it requires resources, so we’ll be – there’ll be people, as part of those organizations, that help ensure the customer deployment is successful.

    Shimel: You know, I think Aqua is kinda taking the lead on this cloud-native security. Of course, we all at KubeCon in Seattle a few months ago. There’s another one coming up in Barcelona in – was it May? The end of May, I think.

    Feit: May 20th. Believe it, it’s on our schedule.

    Shimel: Yeah, no, us too. I think I fly out the 18th. We’ll talk about it. But, you know, I mean, we saw at KubeCon in Seattle this buzz, this palpable excitement – it reminded me of AWS Reinvent five years ago, right? Before the – when the cool kids still there. Where do you think we go? Are we at – I guess, are we at the top of the hype cycle here? Do you think it’s just starting? Where’re we going here?

    Feit: It’s still early, I think. [Laughs]

    Osnat: It’s not even close to the top. I mean, so KubeCon in Barcelona is gonna be – they’re expecting 10,000 attendees.

    Shimel: Wow.

    Osnat: Yes.

    Shimel: I didn’t realize it’s that big.

    Osnat: In Europe, _____ _____ _____ –

    Shimel: Yeah, that’s great to hear.

    Osnat: – _____ people coming from all over, et cetera. These European events are typically less well-attended than the US equivalents, so the last KubeCon in Seattle, I think, was 8,500, which was about double what Austin was the year before, and now they’re doubling Europe. So that’s, obviously, a very promising sign. But not only that, we see a lot of companies that are new to this space, new to Kubernetes, new to containers, new to serverless. And, sometimes, we get leads on our website – people who’ll purchase – and you can tell they’ve already done their homework, so these are not clueless people who are just kicking the tires, that are trying to learn the basics. They’ve already done that and now they’re actually looking for a solution because they know that they’re going to production, with their environment, in – whatever – six months, three months, nine months.

    And so that’s a level of maturity in the market that we didn’t see until recently. And also just the number – I mean, the sheer number of companies that are getting involved is huge and CNCF membership, including end-user organizations, is growing. So all of these are indicators to where it’s going. And I think Andy also wants to say something about our presence at KubeCon.

    Feit: Yeah, two things. I would also – before we talk about KubeCon, I think the other indicator is that most of the application workloads that are out there today are still very much in the data center. A lot of them are still monolithic applications; they haven’t all migrated to the cloud or, if they have, maybe they were done with a lift-and-shift. So I think we’re talking about a market that is poised for significantly more growth and we see a lot of different indicators of that. One example is our customers who deployed, say, a pilot project or a handful of applications one or two years ago are now asking us for enterprise-wide licenses and scaling this out to be “This is our cloud-native platform. We’re gonna do everything on this.”

    But, at KubeCon this year, in Barcelona, as we did in Seattle, where we did a pre-day event called “KubeSec Enterprise Summit,” we will be doing the same thing in Barcelona. You can register on the CNCF site. When you register for KubeCon, you can sign up for KubeSec Enterprise Summit, which is really an event built just for large-scale enterprise customers rolling out into Kubernetes in production. We’ll have customer speakers; we’ll have an analyst speaker; we’ll have panels. It was a terrific event, very positively reviewed in Seattle, and we’re repeating that now in Barcelona on the 20th of May.

    Shimel: That’s great news. You know, and one thing – look, I’m guilty of it; I think you guys are guilty of it too – we call it “KubeCon.” It’s “cloud-native con” too. Right?

    Feit: Absolutely. We do tend to – for those of us who’ve been in the market –

    Osnat: It’s like for a while.

    Feit: Yeah.

    Shimel: No, no, I do it. I’m guilty as charged, but I think there’s gonna come a day where cloud-native maybe is bigger than Kube itself, right?

    Osnat: Yeah. Well, I think it already is, in a sense, right? I mean, Kubernetes is just – it’s a bit like a fleet. You have a – Kubernetes is the aircraft carrier and then you have everything that surrounds it, the frigates and the destroyers and the minesweepers and all of that.

    Shimel: _____ and the battleships. Absolutely.

    Osnat: I think that you can tell I play – I used to play _____ –

    Shimel: I can tell that. Right.

    Feit: And the other thing that I think it comes down to, it’s just harder to say “cloud-native con.”

    Osnat: That’s true.

    Feit: It’s got too many Cs and Ns and _____ –

    Shimel: “KubeCon” does roll. You’re right.

    Osnat: Why don’t we call it “KubeCon cloud-native con”? Not “cloud-native con” or “KubeCon.”

    Shimel: Absolutely. Hey, guys, I know you’re coming to us from Madrid today. You’re at an Aqua team meeting, and so I appreciate you carving out some time, but I wanna be respectful as well. I know you only had 25, 30 minutes, so. First of all – or last of all, congratulations.

    Osnat: Thank you.

    Shimel: You and the whole Aqua team. I tend to think of you two as Aqua, but I know there’s more people behind it.

    Osnat: I mean, _____ _____ people behind this wall. I don’t _____.

    [Laughter]

    Shimel: Yeah. But congratulations to both of you. Congratulations to the whole Aqua team. It’s gonna be interesting to see how it plays out. As I said earlier, we live in interesting times in tech, so I will see you both in KubeCon in Madrid? I mean, in Barcelona.

    Feit: In Barcelona. And if –

    Shimel: In Barcelona. We’re doing videos there for Digital Anarchist, so we’ll have you in and we’ll talk some more.

    Feit: I will be at DockerCon before that if you’re going to San Francisco, so _____ –

    Shimel: I’m not at DockerCon. I have to go to Iceland. But –

    [Crosstalk]

    Feit: All right. Great talking to you again, Alan.

    Shimel: There’s only so many conferences that I can do, but we try. But we’ll talk more. But, for now, Rani and Andy, congratulations. Continued success with Aqua and we’ll talk to you later.

    Feit: Thanks, Alan. Buh-bye, Alan.

    Shimel: All right, guys. This is Alan Shimel for devopsy.kinsta.cloud, Container Journal, and Security Boulevard, with our friends from Aqua Security on their recently-announced $62 million raise of round C. Till next time, bye bye.

    Osnat: Bye.

    Feit: Bye.

    — Alan Shimel

  • DevOps Chat: Container Security and Aqua 3.5 with Rani Osnat and Andy Feit

    DevOps Chat: Container Security and Aqua 3.5 with Rani Osnat and Andy Feit

    In just a little more than three years Aqua Security has set its mark in the container security space. With its major new release of Aqua 3.5, the company has again raised the bar with serverless and container encryption upgrades and feature sets.

    I sat down with the Aqua Enforcer himself, Rani Osnat, and “Boston” Andy Feit to discuss the details of this major release. Rani and Andy give us an inside peek.

    As usual, the streaming audio is immediately below, followed by the transcript of our conversation.

    Transcript

    Alan Shimel: Hey everyone, it’s Alan Shimel, devopsy.kinsta.cloud, and you’re listening to another DevOps Chat. Today’s chat is a little bit about cybersecurity, container security, Kubernetes and a major new release coming out of our friends at Aqua, Aqua Security. I’m happy to be joined with the dynamic duo of marketing at Aqua, Andy Feit and Rani Osnat. Andy, Rani, welcome.

    Rani Osnat: Hi Alan, thank you.

    Andy Feit: Hi Alan, good to talk to you.

    Shimel: And just so people know, Andy, you’re joining us from Boston today. And Rani, you’re out in Israel. Is that correct?

    Feit: Yes. Yes. Today I am in _____ _____ [Crosstalk].

    Osnat: Right.

    Shimel: Modern technology. We have a worldwide panel. But guys, the big news is, Aqua just announced version 3.5 of their platform suite of tools. And you know, Aqua’s not a company that every single new time there’s a new release, and the DevOps mantra, you can’t get too excited about any one release. Right? Because there’s always a next one and a next one and a next one. But this is one to get excited about, huh?

    Feit: Absolutely.

    Osnat: We certainly think so.

    Shimel: So why should we be excited?

    Feit: Rani, you want to take that one?

    Osnat: Yeah, I’ll take this one. So, with every release we make, especially, and in the beginning of course everything’s new. But we’ve been in this space now for three years. Which is not a long time, but in this space it’s a very long time. And so now we’re at the point where we have a lot of large enterprise customers using our product. And we have a market that’s looking for innovation.

    And with every new release we try to balance these factors of, you know, offering something new that the market wants. But at the same time ensuring that our enterprise customers can make use of our platform, as they themselves grow their cloud native container implementations. So there is a maturity factor here as well as an innovation factor.

    And so on the innovation side, we’re introducing a few significant innovations. First and foremost, risk assessments for serverless functions. Which is a, you know, a kind of a sideways expansion for us into the serverless technology space, in addition to containers. Thinking that you know, what we see as, it’s basically the same teams and the same benefits that are gotten from containers people expect to get from serverless, it’s just another means to get the same end.

    And so we want to provide our customers with all the controls they need to address any challenges they have around securing those technologies. And it doesn’t matter if they use containers or serverless or both, or any sort of mixed environment. We also added something that’s innovative in the space, which is container encryption, and we can talk about that.

    And then on the side of enterprise scalability and ease of use, we’ve added quite a significant I would say rearchitecting of how we manage both administrative controls on our platforms and what users can do in terms of access. As well as the policy engine to make it a lot more scalable for multicloud, multiteam, multiapplication use.

    Shimel: Got it. Got it. Andy, did Rani leave anything out you want to add?

    Feit: No, I mean, those are the big pieces that are in the release. As he said. I mean, it’s very much being driven by our customer base and where they’re headed. And you know, in some aspects, it’s the technology elements. Like adding serverless. And in other aspects, it’s really about living with the solution. You know, as our customers, we now have customers that are we think the largest container deployments in the enterprise.

    We have some very large users and span of different industries. As they look to roll out, they’re finding they have multiple teams working on these projects. And they need to implement different levels of security. And in many cases, they’re implementing that on different technology stacks. And some are using containers, some are using serverless environments.

    And they may be using even different underlying providers of some of the infrastructure. Whether that’s tools for development or the cloud provider itself. And so we’re really, we’re becoming very heterogeneous in terms of what we need to support. And for our customers who, on the security side, are trying to look at that whole context and manage that whole context and have consistent policies, all our consistent reporting across all of them, and not be monitoring 17 different dashboards. It’s important that it be easy to do, to be able to see that whole network of activity. And that’s really what a lot of this release is about.

    Shimel: So guys, one of the things that you mentioned, both of you actually mentioned, was the serverless piece. And this is something that we are, we’re hearing a lot about from our readers and from people we speak to. You know, how quickly, and we live in crazy times, right? So the whole container revolution, if you backed up on hypervisors. And now, how quickly serverless is you know, gaining a foothold and people are building around that type of infrastructure.

    Osnat: Right.

    Shimel: Let’s, just baseline, what are some of the security challenges that you guys are seeing around this?

    Osnat: Right. So I’ll preamble that, you know, just add one more thing. There’s, you know serverless has been around almost as long as containers have, in terms of the, you know, its current incarnation of the use in the cloud. But, the use cases is quite different. And while it is gaining traction, the use cases are much more limited than containers. There’s a whole kind of religious war, you know, between the proponents of containers and the proponents of serverless. Personally I don’t believe it’s a zero sum game. I think that both are going to end up being used, and both are going to end up being used in hybrid architectures.

    Shimel: Yeah, I don’t think it’s either or.

    Osnat: Yeah, I know, but some people would like you to think it is. I don’t think it is. I think it’s both. And so we, but there are some fundamental differences between containers and serverless when it comes to security. First of all, most of the serverless workloads that happen today are cloud based and specific to a cloud provider, right? Mostly Amazon, because Amazon is the larger cloud provider in general, as well as in serverless specifically with Lambda.

    But basically you run those functions and it’s quite cloud specific. That’s one area of difference. The other is of course that you know, these are very small single-function entities that can run for a fraction of a second. So when we talk about run time security for serverless, for example, there is a lot less to do there than you have with containers.

    Containers are, there are applications that can run, they could run for a minute but they often run for a lot longer than that. With something that runs for a split of a second, there is really only so much you can do when it’s already running. So a lot of the stuff you need to do is before it ever runs. You want to make sure that what you’re running is actually something that is secure, that passed your policy, and that you know about, right?

    So when you look at the challenges, one of those is actually discovery. What functions do you have in your inventory, and what are you using them for? The second is ensuring that what’s in them is secure and not vulnerable, configured properly. And that also includes permissions. So, when you define for example a Lambda function to run on AWS, there is a set of permissions you can give it.

    And depending on how you configure it, this can be very liberal or not. And of course you want it to be less, the least liberal you can. So as not to allow it to do anything outside the scope of what it’s supposed to be doing. So right now we’re primarily concerned, and that’s also where our customers are, with preventive controls. Basically ensuring that you are, that when you run something you actually know what it is. You know that you’ve approved it. And you can run it safely. That’s the first step in what we think is the right approach to securing serverless functions.

    Shimel: Fair enough, fair enough. And back to what you said kind of right at the get go with the either or thing. It was the same arguments about, would container replace hypervisor type of thing. And I think what we see is the majority of people want containers on hypervisor.

    Osnat: That’s true. It’s –

    Feit: Yeah, and I would also add that the data centers with lots of VMware and hyper-v haven’t gone away yet either. And they won’t. They probably will never entirely go away. New development today is cloud native development. Most of your mobile customer facing development.

    It makes sense to do that in the cloud and as long as you’re doing new development, why not do it on the latest and greatest. But, and the flexibility that you get from doing something on containers or serverless or a hybrid approach of those, makes it a lot smoother, easier, scalable. You get all these wonderful benefits. But we don’t see people going in wholesale and saying, I must clean out this data center now. So I think that –

    Shimel: _____ [Crosstalk] throw out the baby with the bathwater. And people –

    Feit: Yeah.

    Osnat: Yeah. So I think that’s one thing that we did. The other, I think very interesting and innovative feature that we’re announcing is container encryption. And I want to explain the use case. So we work with, you know, we work with many organizations. For example, we work, some of our customers are ISVs, who create software for customers to use.

    And that software is proprietary IP that they’ve developed and invested in. And they often want to make sure for those reasons as well as for reasons of governance, to make sure only the latest stuff is being used, et cetera, that they have some control over where it’s running and who’s using it. And so one of the things we provide here is an ability to encrypt, you basically encrypt the container image when it’s built.

    And then in order to run it, you need to decrypt all its contents, so there’s basically a key that the customer will have, the end user will have. And that will decrypt the image as it’s running. And if you don’t have that key, the image will not run. So the container itself once it’s running is not encrypted. But up till that point, it’s encrypted and you have to decrypt it in order to run it. And then of course this prevents the sort of, someone reusing or forwarding your software and you can imagine various use cases except the ISV one where companies would want this sort of deep security control over their containers.

    Shimel: Sure. Sure. And I think it’s just the, you know it’s funny, Rani. I think you said right in the beginning that over the last three years, you know, the progress that Aqua has made, and the progress the whole industry has made in securing their containers. Like everything that’s come before it, right, with each new release, with each light bulb, _____ security we see like more polish being applied.

    So, to me this idea of container encryption is you know, maybe first we have to concentrate on just getting the containers to work in a somewhat secure manner. But now we can start thinking about next level, next, you know, how do we turn it up a notch? Things like container _____. What’s the word I’m thinking. Like the standard, the, you know, the container encryption becomes ubiquitous over time?

    Osnat: I don’t know if it will become ubiquitous. I mean, certainly today you have a lot of encryption happening with TLS and all the stuff, all the pipes that handle containers. But as for the code itself, you know, even in highly regulated environments, I don’t necessarily see everyone encrypting everything. But certainly there are some crown jewels that you will want to encrypt.

    And it’s especially those areas where you’re not talking about reusable components, right? A lot of the containers that our customers use are reusable based on open source components, that’s fine. You don’t need to encrypt your NGINX webserver container, right? That’s, it’s identical to the same, other NGINX containers people use. But if you have proprietary stuff, that’s where you want to, or something that’s especially sensitive, whether it’s for any kind of security, confidentiality reasons, or for IP reasons. That’s when you would want to use something like that.

    But what you said actually, you know, brought me to the other topic I wanted to talk about, which is how the use of these technologies has matured with some of the more leading or pioneering companies that we work with, which is why we’ve invested in these scalability, manageability features. So I want to kind of explain what it looks like in a customer environment.

    So when we started out, and we started out kind of together with the market, the companies we were talking to, even larger companies, would typically have one or two teams that actually use containers, right? And so, you were talking about isolated projects. And that’s one level of doing things. But as we move forward, you know, now we have customers that have hundreds of development teams working with containers. They make thousands of images on a daily basis, because it’s all in a CI pipeline.

    And it all gets, it all goes into this large blender where it’s being spit out at the end, through Kubernetes or mesosphere, basically through an orchestrator to a variety of delivery platforms, whether it’s OnPrem or cloud or a mix of both. And if you look at it from an enterprise perspective, what they want is a way for them to apply security policies but maintain segregation of duties. Maintain compartmentalization and multitendency models that they have. So what we’ve done is really change both our administrative access model as well as the policy engine to enable that.

    So basically, you’re talking about people who use the Aqua platform. They have one installation of the Aqua platform. But they can basically distinguish between what different teams can see and do, what different roles can see and do, and how those policies apply.

    I’ll give an example. Let’s say that you have an application that is PCI DSS related. Handling credit card transactions. And so it has to comply with certain criteria that are requirements of the PCI DSS standard. You want, and you’re, but at the basis you’re using some basic elements like, I don’t know, MongoDB or MySQL. That same MySQL image that you apply a policy to within the PCI contexts will have a different policy than in non-PCI contexts. So having contextual policy is important.

    So that’s one area. The other area is who’s got access to what. So of course the people who handle the PCI application, the developers, the DevOps team, will need to handle certain aspects of this. But they don’t necessarily need to control the policy. That’s expected to be done by the security and compliance team. And the same token, they don’t need to access, or other teams don’t need to access that PCI application.

    So we’re talking about a matrix that really separates who’s got access to what and what they can do with that access, according to the specific application or geographic location, or what cloud it’s on or what registry it uses. All of these parameters. So you know, we’ve done this and we have, now both of these models combine to basically give you this matrix that is, that has you know, dozens of parameters on each facet to basically determine who’s got access to what, and who can do, whether it’s view access or edit access or only access to the logs, for example, for auditors and so forth. And so, it’s really a step up in terms of enabling these large deployments to work in an enterprise environments.

    Shimel: Absolutely. Good stuff. Guys, I want to _____ two other topics or areas I want you to hit on. One specific to 3.5, one specific to the market. And we’re coming up on the end of our time. So you know, we hear about immutable infrastructure, and you know one of the advantages of a container environment.

    So how do you deploy, you know, now you’ve got a bunch of customers. They want to upgrade to Aqua 3.5. Talk a little bit about how do you actually upgrade or run out this upgrade deployment. Is it a question of throw out what you have and just stand up new? Because Aqua itself is containerized. Or is, what, give us a little insight, nuts and bolts if people want to upgrade. Do you know what I’m saying.

    Osnat: Yeah. So our upgrade process is you know, it is simpler because we use containers, right? So there’s nothing to install. You simply run the new container. We do have backward compatibility with our previous versions, so when there’s an upgrade path for anyone using older versions of Aqua to this version.

    We actually, we’re the last, we don’t, I mean, we release software more often than what some of our customers would like to follow, in terms of their upgrade schedule, right? And we don’t force them to do that. But in the last version, the last major release, 3.2, we actually had a lot of customers move to that. So we’re in good shape from that respect.

    And they can of course upgrade to 3.5 when it becomes available at the end of the month. So there’s really no, there’s nothing in particular they need to do except of course, we always, always recommend doing it in a test environment first. And then once you see everything works, you move that to production.

    Shimel: Excellent. Excellent. So let me add –

    Feit: There’s one more thing now I was going to jump in with, which is, we’re sort of talking about as our organizations of scale and especially if they have multiple teams that are working on different platforms and policies that need to be implemented. In some of these larger enterprises, it’s become very hard to really even see everything and know about it and track, you know, who’s running what and where, and who are these owners. And so one of the things that’s new in the product is a pretty slick interface.

    Probably that’s the prettiest part of our product right now. The dashboard’s always looked great. But you can now go in and do what we call workload explorer. And visually view all of your running workloads, whether they’re on Kubernetes or Docker or OpenShift, and you can see everything that’s running across a large distributed runtime environment. And drill down into them, and you can start doing things like highlighting those that are vulnerable or high-risk, and those that are PCI compliant can be coded to jump out, and you’ll see that much more easily.

    You can then do tabular mechanisms. Begin to filter. Show them only those running on this platform. Let’s say that there’s a vulnerability that’s exposed in a certain component. You can show me just those, and start drilling down and looking at them, seeing where are they running? Is this one on-prem? Is this one on the cloud? Which cloud provider is it running on?

    So you know, as companies have become multiteam, multicloud, multistack, it’s the matrix of what you’re looking at has become pretty complex. And as workload explorers, it’s a great way to just sort of move around in a large enterprise. See what you have and understand what you need to work on right now.

    Shimel: You know, and let’s not trivialize it. Let’s not belittle. I’m having a tough time with the word. Let’s not belittle it. You’re a hundred percent right, Andy. Today’s organizations are multi everything.

    Osnat: I agree.

    Shimel: _____ _____ distributed on so many different levels, that really, having a 360 degree view of, just of the lay of the land, where all this, how it all plays together. That in and of itself, someone could make a product out of. I mean, it’s crazy.

    Feit: It’s eye opening for customers. Just in the last, we’ve been working with this product for about a month or six weeks, with some of our early adopter customers. And some of our sales engineers have been implementing it in proof of concept environments. And when the customers see this map, and they, you start drilling down, they say wait a sec – where’s that running? Show me that one.

    They’re finding things that they didn’t realize they had because you can now visualize it and see it. You know, when it was coming in as yet another alert or a text field or you know, something coming in to your SIM system, that was one thing. You had to look at the logs and know the query to type. But when you see it visually and you jump in and start looking around, and says wait, what’s that?

    And people were, it was eye opening. Okay, I need to go talk to that person. Literally, people were discovering things they didn’t know they had in their environments. And that’s exactly how, in a big environment, this tool can be very helpful in organizing things and showing you what’s out there.

    Shimel: Absolutely, absolutely. Guys, that last question for you is not really 3.5 related but more mark related. You know, we seem to be undergoing a, well, it’s constant. But recently we’ve seen just more and more consolidation in the tech vector general within containers, around Kubernetes, you know, IBM’s Red Hat –

    Feit: Cloud, right?

    Shimel: IBM’s Red Hat acquisition, $34 billion. I mean, is the king of it. But we saw for instance, CA or Broadcom CA, whatever they call it now, spin on _____ for near a billion dollars. To Tom or Bravo. We saw, who, someone just bought, was it _____ just bought a –

    Osnat: Later insight, yep.

    Shimel: Container something.

    Osnat: Right.

    Shimel: I mean, at some point, consolidation to what Aqua’s been out here preaching for three plus years. How do you think that affects, I mean certainly now, 3.5, you’ve raised the bar again. Let everyone else try to catch up. But in this atmosphere, talk to us a little bit. What does that mean around Aqua? Or do you just keep doing your thing?

    Osnat: Yeah, that’s a good question, Alan. I mean really, I think you keep doing your thing. Because your thing is understanding where customers are headed and building solutions that address what they really need. We’ve tried to keep our eye on that ball. And we’ve been big pushers of the concept of supporting multiple platforms, from the early days.

    We were Docker first, but today we support all kinds of things including things, less broadly used technologies. But pivotal, and Microsoft containers. Supporting all the cloud. So you keep your eye on that ball with the goal of building a customer base that is satisfied and loves your product, is excited about working with you.

    And one of the things that’s important to us is our customers are going to continue to renew with us and retain. You know, we’ve only been around three years. But we look at, our largest customers are very happy and using us, and expanding their use of us. They’ve put us in a pilot two years ago, and now they’re in production and they’ve put us in production with five applications. And now they’re on 50 applications. So this is all good. We’re not very focused on hey, we must be acquired by some time or we must be public by some time.

    It’s, let’s build the right products, continue to see adoption. We’re growing very rapidly, both within our base and customers deploying more, and new names, new logos, that are using our solution. And that’s what’s important to us. And the market, you know, the market will be the market. If somebody says wait, I can’t let these guys get that much bigger. I’m going to try to snap them up. That may happen. But it’s not something that we’re really focused on. We’re focusing on building the business organically in the right way.

    I have to say, we’re all old enough to have been through the dot com boom. And you know, the craze that went on back then. And I think it’s important to keep level headed. We’ve been around for three years now. We’ve just crossed the 100-employee mark. Celebrated that. You know, we work with our customers, we’re happy about that. We keep our heads, you know, leveled and we keep doing the work. You know, someone comes along and offers $35 billion to buy us, like Red Hat, I’m sure the board will approve.

    Shimel: They might think about it as –

    Feit: They’ll think about it a couple of days, you know. But in the meantime, we’re trying to keep things sane.

    Shimel: I hear you. Guys, just one last reminder while I have you both on. I’ll see you both out at the TubeCon Native, cloud native, Linux foundation event, along with Red Hat, right? Sponsoring a Monday conference on container security. I think we spoke about it last time. And I just, I don’t want to mess up the date, but I thought it was December 9th, or 10th.

    Feit: Nope, December 10th. So it’s the Monday right before KubeCon starts, and it’s collocated with the event in Seattle. And you can register on the CNCF site when you register for KubeCon, or if you already did you can go back there and add on one of these collocated events. Ours is very focused on enterprise security, so it’s called KubeSec Enterprise Summit.

    So for larger organizations, facing you know compliance requirements and deploying containers in production, it’s a great way to learn what others are doing. We have a great lineup of speakers. We have, JPNC is speaking. We have Tinder speaking. We have Starbucks talking about their journey towards secure containers. We have Liz Rice and Michael Hassenboss, who wrote the recent book on Kubernetes security. Which is not even published in paper yet, it’s still an eBook, but it will be first delivered in paper form at KubeCon. We’ll have them in our booth, and they’ll be signing books there.

    So it’s kind of a great event that people can get exposed to all of these technologies, and hear from a lot of different people. We ran an open call for presentations, so we have everything from technology to compliance to best practices. It’s going to be a great event. We’ve got a couple hundred people already signed up. We only have room for 300. So, if any of your readers do want to attend, they should do that soon.

    Shimel: Absolutely. Well, I’ll be there as well. We’ll be reporting for it. Andy, Rani, we’re way over time as usual. I ____ _____, we’ll need to call a wrap here. Congratulations on Aqua 3.5. I’m sure it’s going to be a great benefit, and the customer base will really appreciate it, and we’ll look forward to seeing you in Seattle.

    Feit: Look forward to seeing you, Alan. It’s always great to talk to you. And share what’s going on with your listeners.

    Shimel: Thank you. Andy Feit, Rani Osnat, Aqua Security. This is Alan Shimel for devopsy.kinsta.cloud, and you’ve just listened to another DevOps Chat.

    — Alan Shimel

  • DevOps Chat: Container Security and More with StackRox’s Ali Golshan

    DevOps Chat: Container Security and More with StackRox’s Ali Golshan

    Security has many faces, which is why it’s so difficult to implement effectively. Each environment is different; each security solution is different; the needs of each organization is different. That’s why, as Ali Golshan, StackRox founder and CEO Ali Golshan put it, security has gotten a bad rap.

    Golshan and his company are approaching security from a more DevOps-focused view, providing the necessary tools to enable DevOps teams to include security throughout the entire process. In this DevOps Chat, he and I discuss the many facets of DevSecOps, container security and more.

    As usual, the streaming audio is immediately below, followed by the transcript of our conversation.

    Alan Shimel: Hey, everyone, it’s Alan Shimel, and you’re listening to another DevOps Chat. Today’s chat is a little DevOps, a little security, a little containers, little bit of everything. Happy to be joined by StackRox founder and CEO, Ali Golshan. Ali, welcome.

    Ali Golshan: Thanks for having me.

    Shimel: And, Ali, I think I mispronounced your name. It’s “Golshan.” Correct?

    Golshan: Correct. Yes, thank you.

    Shimel: Cool. I try to do it right. So, Ali, let’s start with the obvious, though, maybe some people out here have not yet heard of StackRox, so, before we dive in, just a quick sorta elevator pitch so they have some context.

    Golshan: Sure. We started StackRox three-and-a-half years ago. The premise for the company was we saw a couple of major shifts in the industry. One happened to be the introduction of containerization and microservices, which is a sub-effect of this larger trend that we’ve been seeing, which is application security and development becoming full product life cycle, so ensuring that you can cover security and compliance and requirements from build to deployment to runtime. And containers provided, really, a great packaging and a construct for building applications and microservices.

    And then the second part of it is is that, when you look at this model, we realize that there’s really three fundamental things that are disrupting a $30-billion security industry. This is the whole notion of a full product life cycle needing to be automated. It’s immutability and ephemerality. And, because you can’t forklift traditional security solutions and deal with these three constructs, we decided to go after solving this much bigger problem for what we like to see is for the future of cloud.

    And where we started was containerization just as the fundamental building blocks. As time and market has progressed, we’ve progressed with it, which is focus more on things like APIs and orchestrators and managed cloud environments, but very much with kind of a host-application-centric view of the world. We’re not a network-based tool. We’re not a log-ingest based tool. We tend to focus a little bit more on security automation, detection, and creating a multifaceted risk view of your environment, specific to containers and microservices.

    Shimel: Got it. So, you know, there’s a lot in there and we’ll come back to StackRox maybe a little later in our chat today, but I wanted to – let me hit on a couple of things you mentioned. So the first thing is this whole idea of cloud-native, container-native. You know, when we first saw the shift to the cloud, the security industry’s response was what some analysts called “cloud-washing” existing security solutions. So they took their existing security solutions and they said, “Okay, now it could run in the cloud too. It’s a cloud security solution,” but it really wasn’t. It was a on-prem security solution moved to the cloud. It wasn’t cloud-native and it really was a little bit of a round peg in a square hole.

    I think we’re seeing the same thing when we talk about security solutions built or trying to provide security for containerized applications. Right? What’s involved? Can you – you know, I don’t wanna coin the phrase, but can you “container-wash” an existing security solution and make it a container security solution, Ali, or do you really need sort of container-native-designed security?

    Golshan: To your point regarding traditional cloud environments, I think that was a smaller chasm, where security companies had to cross, because that original movement was a little bit more about virtualizing your environment. So there was still some kind of applicability of running things like WAS or endpoint solutions, to be able to broaden your security posture to the cloud. Obviously, the fundamental problems we saw were created were around how do you automate and provision workloads and then the nature of those workloads remaining. Those were kind of – the new capabilities in the cloud were actually the pieces that created gaps for security.

    So, if you then think about that and expand that further, the capabilities and designs for containers are even kind of another order of magnitude different than traditional. It’s not just virtualization and then outsize your boundaries. It’s virtualization; it’s microservices, every function broken down into a particular service; controlling it end to end. So, if you think about that there’s a large portion of the security industry that doesn’t even look at some of the most critical components of this process, which is the build and deployment. Building constant context there. Building declarative policies from that environment and then using it further. So I think that’s one of the major reasons we don’t see the applicability of traditional security solutions, even more so in containerized environments.

    Shimel: Yep. I mean, Ali, I agree with you and I think that’s why, frankly, a lot of what is today passing for container security seems to be people doing vulnerability scans of containers or, as I think I had spoken to you about the last time we chatted, you know, network IDS for the container. It just doesn’t – it seems very much square peg, round hole. And I’m not saying you don’t need vulnerability management, whether you’re in a container or not, and I’m not saying you don’t need intrusion detection, whether you’re in a containerized environment or not. But to say that that is, quote unquote, a “container security solution” seems just pushing it and just trying really hard to sell.

    But wanted to come back to another thing you mentioned in your opening remarks. And that was around this whole idea of not only are we living in a containerized age, but we’ve seen the rise – and I don’t wanna say the dominance of – but, you know, the whole CI/CD software factory pipeline model of which DevOps is an integral part of and we talk about shifting security left into the software development life cycle. And this is yet another way that traditional security has to give way to how things are done today, so how does that influence or how does that play itself out, in terms of StackRox?

    Golshan: The way we think about that is, if you think about who were the first companies who moved towards containerization and microservices, they were all companies that needed to deal with massive scale, building velocity in their development and to the offerings they have for their customers. And, as a result, they realized that kind of traditional model of building and deploying and managing was just not sustainable because it wouldn’t scale with the human element. So this notion of DevOps, and even containerization as a result, were really tools and methods for companies to be able to increase their level of automation and sophistication as to how they managed and run their infrastructure.

    So the way we look at this is is that, also, it’s the same reason why a lot of those first movers build their own security models around this environment ’cause nothing like it existed. So we see security kind of mapping to the same model, which is, if you think about it, things used to be a little bit more around a model of batch process, respond, do analytics, take those sorts of options. And, again, the way we look at this is is that what containers have done is break that fundamental workflow. That fundamental workflow isn’t kind of “Build something. Check. Build. Check. Build. Check. And have all these gating factors applied by security.” It’s a lot more fluid now. So, as a result, security has to kind of integrate into that whole workflow.

    And this is one of the big things we talk about, which is is that the reason you can’t take traditional security solutions and apply ’em here, it’s not just the form factor of what they’re applying to, but it’s also the entirely new workflow that’s been created by DevOps and these types of environments that impact how a security tool should run. Because it’s not just tying it to a form factor or choke point. It becomes more of a service mesh – not to borrow the word “service mesh” from kind of the service mesh project, but that’s why it lends itself very well. It’s a number of services integrated across the process and then, as you automate these processes, they become force multipliers for each other. That’s how DevOps works and that’s how security should work as well. You can’t break that workflow model just because your security tool.

    Shimel: Agreed. And you’re using the term “workflow model” and I think that’s a great descriptor of it, but, you know, a lot of goes back – and, again, part and parcel with DevOps – a lot of it goes back to the whole sort of Lean IT, based on Lean manufacturing. Sort of, it really is a factory pipeline kind of workflow model. And, when you think about it, the fact that, all this time, we’ve always kinda just stuck security on at the end, at the end of the packaging, so to speak, and then wondered why it didn’t work so great. It’s kinda obvious when you look at it that way, isn’t it?

    Golshan: No, absolutely. I mean, that’s a interesting analogy, right? If you think about it. If you have kind of a industrial environment and you have manufacturing, if you move from a manual workflows to robotics and automated work flows, the sort of security you apply is gonna be very different – how you look for bugs, how you look at, for example, applications. This is a good analogy because it’s a very indicative kind of model of what the current industry’s going through.

    Shimel: Mm-hmm.

    Golshan: So I’ve become a big believer that you can’t – this is where I think security goes wrong, trying to cover too many things at once. If you have a completely new emerging model, like containers and microservices and DevOps, it’s okay to say that our security or our approach deals just with that particular area. And, as small or as big as it may be, it’s important because it adds credibility that you actually understand what it fundamentally is built from and what it’s doing ’cause, if you say anything other than that – “Well, no, mine can cover network and end points and VMs and containers and Lambda.” – well, that’s just a lot of the reasons why the security industry got the bad rap it did. It’s just things fundamentally work different.

    Shimel: Agreed. Agreed. So, Ali, I think we’ve done a great job here, in the first ten minutes or so, of laying out these sort of macro-factors that are affecting not just the tech or even just the security industry, but the – it’s really affects the whole world because we’re all – every company’s a software company now. And so this really has worldwide bedrock kind of effect.

    But let’s turn back to StackRox, right? Full circle back to the beginning. So how are all of these things manifesting itself in –

    Golshan: Yeah, so the way we look at it is –

    Shimel: – in what became StackRox?

    Golshan: – is have one solution that has two modules to it that interoperate. We have the StackRox module that covers build and deployment and StackRox that covers runtime and production. And the way we look at this entire flow is very basic – on one side of the equation, you get to look at all the static and declarative information and you get to use it to say what things should be able to do, and then, any time you run it, be it in deployment, QA, or production, you get to learn from that application more and more and see what it actually can do.

    So our mission is really bridging what it should do versus what it can do. And the reason, for us, the automation part of it is a big part of it is, you know, as companies mature their overall workflow, they will have additional tools that are gonna be provided by their platform providers, by their cloud providers. As an example, you touched on vuln-scanning. Absolutely everybody should do vuln-scanning, but, more and more, we’re seeing it cloud providers and platform providers provide it, so the key there is not to provide vulnerability; it’s to be able to do vulnerability management.

    And the way we look at vulnerability management, it’s either being able to provide the customer the scanner or ingesting the data from all the scanners and then helping them prioritize it – “Where is this running in production? In production, what services are accessible by this?” So, if you have a low vulnerability that is running in a production environment, in a mission-critical app that is exposed to the Web, it should be valued higher than a high vulnerability that is running in dev in a closed-off EPC that has no access to any other services.

    So context is what helps you prioritize, but it also flows the other way. So, in runtime, if you’re doing detection, it’s important to understand, if an attacker, for example, shelved and broke into a – broke out of a container, grabbed some tokens or credentials, you wanna be able to go back and look at the, for example, the secrets that are being managed through the orchestrator and see where else those particular credentials or secrets are available, where else that deployment has happened.

    So, if you think about it, on the left side, you get a lot of really great insight. On the right side of the process, with the runtime and production side, you can make use of those to build very good boundaries and gating factors, and that naturally reduces your attack surface. So, as you feed this information back to the build and deployment, remove credentials or privileges or tools that are unnecessary, you’re inherently making your infrastructure and applications more secure. And, as a result, we have a much better landing zone for what we apply detection to. We don’t have to detect everything; we know where the weak points or where the gaps are in the system, to focus our detection.

    So that’s kinda how we think about the overall StackRox product. Give the customers, especially the build and deployment and dev teams, the right security, auditability, automation tools on the build and deployment side, and then give the right runtime detection, alerting, response, forensics, and enforcement on the runtime protection side, for security folks.

    Shimel: Excellent. And we’ve got a few minutes left here, Ali. I wanted to – for people who wanna get more information about StackRox, is it stackrox.com? S-T-A-C-K-R-O-X?

    Golshan: It is. Yeah. We have all of our information on our website and we actually offer free risk assessments using one module of our product, where a customer can just grab it and understand much better as to what they’re dealing with when it comes to their container infrastructure.

    Shimel: Okay. Let me come back one other thing to you and, you know, the proverbial “Let’s see your roadmap” slide, but I don’t really want you to show me your roadmap. But what do you think is next, not only for StackRox, but as a result of this macro environment that we’re living in? What’s the next shoe to drop here and how do StackRox sort of – I’m sorry about the noise there – how do StackRox respond?

    Golshan: Sure. I think it’s a couple of things. One is we’re seeing more maturity across this entire stack, so we’re seeing convergence around orchestrators; we’re seeing kind of the standards around runtime engines being built; we’re seeing how public cloud providers are consolidating certain services and making other services much easier to use. Perfect example’s all the efforts around, for example, Kubernetes, between AKS, between EKS and GKE.

    So, when we look at these trends, it shows a couple of different things. One, not only are the containers different, but the entire attack surface is going to look very different, so the way you approach this world is gonna look very different in the future. We’re not gonna make the same mistakes we did with traditional security, which is we’re not gonna make the host overly exposed with a lot of user accounts and credentials and privileges and tools and packages. So we think that that host will obstruct the way and the orchestrator will become kind of a new cloud operating system, with APIs.

    And, as a part of that, you’re gonna end up seeing a lot more complexity, so, as companies get more comfortable running applications as microservices, more containers, better grasp of the orchestrator, they’ll get more comfortable running more complex operations and applications on top of it. Naturally, that comes with maturity. And once you have that, you end up going from kind of what right now is, which is very early stages of this ecosystem, which I would consider to be low entropy, to a very high entropy environment you’re gonna end up seeing.

    As a result of that, the way we see security being built is, one, that’s why it’s very important to focus on automation, integration, and the workflow, but, secondly, we see security having to be built in cloud native as a form-factor-agnostic model, meaning leverage the existing frameworks to – if it’s collecting data, for example, from the system, use, for example, things like the extended Berkeley Packet Filter to use that. If you’re running on Amazon or Google, you can use things like Pub/Sub or Kinesis.

    So it’s building more modular, programmable, and pluggable architectures, versus building a binary that deploys in a container and then you replicate that container against a bunch of hosts. It’s about building a sensory model that can understand different environments and make sense of them, not single agents that unilaterally take action, because, as complexity, heterogeniality grows, naturally, there’s gonna be a lot more gray area, as far as use cases go. And that’s where you run into the old problem of alert fatigue, noise, false positives, and then, eventually, you end up with 50 security solutions.

    Shimel: Excellent. Excellent. Well, Ali, we’re about out of time, but I gotta tell you, man: I love this chat. This was great. I’d love to have you back on the –

    Golshan: Yeah, same here, Alan.

    Shimel: We’ll dive into some more of this stuff. Good stuff. Ali Golshan, cofounder and CEO of StackRox, here on DevOps Chat. This is Alan Shimel. You’ve just listened to another chat. Have a great day, everyone.

    — Alan Shimel

  • DevOps Chat: Aqua Security Seeks To Secure Containers

    DevOps Chat: Aqua Security Seeks To Secure Containers

    The migration to container-based application infrastructures is accelerating at a faster pace even than we saw with hypervisor-based infrastructure 18 or so years ago. Hand in hand with this is the race to provide better security solutions that are native to and purpose-built for containerized environments. Aqua Security has established itself in the container security arena, recently raising $25 million in capital funding as it seeks to lock down the container security market.

    In this chat, we sat down with Rani Osnat of Aqua Security to discuss the recent funding round and the state of the container security market. Below is the streaming audio of our discussion. Below that is the transcript of our discussion.

    Audio

    Transcript

    [su_pullquote align=”right”]Rani Osnat[su_custom_gallery source=”media: 1739530″ width=”100″ height=”100″ align=”center”]
    Rani Osnat has more than 20 years of enterprise software industry experience, in project management, product management and marketing, including a decade as VP of marketing for innovative tech startups in the IT security and cloud arenas. Previously Rani was a management consultant in the London office of Booz & Co. He holds an MBA from INSEAD in Fontainebleau, France. Rani is an avid wine geek, and a slightly less avid painter.[/su_pullquote]

    Alan Shimel: Hi, everyone. This is Alan Shimel for devopsy.kinsta.cloud and Security Boulevard, and welcome to another chat.

    Today’s guest is Rani Osnat, VP of Marketing for Aqua Security, one of the leaders in the container security market, and Rani, welcome to our DevOps Chat.

    Rani Osnat: Thank you, Alan. Thanks for having me.

    Shimel: Thank you. Thank you for being here. So, Rani, the big news out of Aqua recently is, by anyone’s yardstick, a large raise of capital to fuel Aqua’s continued growth.

    Osnat: Yep, that’s correct. We raised $25,000,000.00 in a series B round led by Lightspeed Venture Partners, which is a very well-known tier one VC.

    Shimel: Yep.

    Osnat: And, it’s—well, to the best of my knowledge, it’s the biggest funding round in our space in continuous security to date, and it also brings total funding for us to $38.5 million.

    Shimel: That’s fantastic.

    Osnat: So, we’re, I think, in a pretty good position to capture what we think is a tremendous opportunity in this market.

    Shimel: Sure. And so, Rani, we were talking off mic prior to recording today—you know, beyond the sheer magnitude of the number, right, 25 is a big number, 38 is a bigger number—but beyond that, there’s also the validation. Which is, you assume a company like Lightspeed Ventures, Microsoft Ventures is another investor in the company, Shlomo Kramer, of course, from Check Point is another investor. You would assume these people are pretty bright people and they don’t throw their good money away. That, if they’re investing this money, they invest it for two things. No. 1, they see the opportunity in the market, so the market itself is ripe and worthy of that sort of investment. And then No. 2, that the team and the product at Aqua are also worthy of the investment.

    Let’s first talk about the market, if we can, though. I mean, so this is a validation, I think, of the container security market, if you will, right?

    Osnat: Yeah.

    Shimel: The containers are real, that securing them are real, and there’s gonna be a big market for that coming up. What do you think?

    Osnat: Yeah, I mean, definitely, when we started Aqua just under two years ago, we didn’t quite know how fast the market would move and what kind of market it would shape up to be. And fairly early on, even when we were in beta in early 2016, it became fairly obvious that this is an enterprise market. That is that, you know, some of the biggest adopters of container technology are not just Silicon Valley startups or web-scale companies that kind of invented this, but Fortune 500 enterprises across verticals like financials, insurance, retail, aerospace, manufacturing, and so forth, as well as government.

    And so, paradoxically, you would expect this kind of new technology to be first adopted by startups, but the real boom in adoption comes from the fact that enterprises are adopting it very quickly, and I think there are several reasons for that. One is that the benefits of using containers are overwhelmingly positive, and the benefits are pretty immediate. So, you can see benefits in agility in terms of how fast you can deliver applications to the market, you can see benefits in moving to the cloud, and reducing your infrastructure costs and operational costs. And you can see much better control over what kind of applications you’re deploying, where, and when, et cetera, largely through automation.

    So, these benefits are overwhelming, and additionally, containers are easy, right? So, it’s—you know, one of the things that made containers, which in itself is not a new technology, it’s been around for a while, but what companies like Docker did is make containers very accessible and very usable. And so, the fact that they’re easy to use makes adoption easy as well, and you know, you kind of see a pincer movement of, on the one hand, grassroots adoption through developer and DevOps teams of containers, so they develop applications using containers. And on the other hand, you’re seeing a top down approach of, you know, CIOs, CTOs seeing the benefits of containers, adopting them, or mandating their use for, for example, cloud native applications to drive cloud usage, hybrid cloud, cloud migration—all of those good things.

    Shimel: Absolutely. So, Rani, you know—granted, I’m not as involved in container and container security as you are, obviously, but to me, a couple of different thoughts. Number one, in my limited—granted, limited expertise, containers aren’t that easy, right? I mean, I think when we talk about containers and then, like, Kubernetes and stuff to manage the whole environment—for someone who hasn’t developed on them before and is used to developing, let’s say, in VMware or in Bare Metal, there is, there’s a learning curve. Maybe once you pick it up, it’s easier.

    But the other thing is, I always try to compare sort of container adoption, let’s say, to hypervisor adoption or VMware adoption, and I would say that containers, their adoption curve is higher or steeper, faster than sort of hypervisor’s.

    Osnat: Yeah, that’s correct.

    Shimel: And really what I see, the last couple—you know, we’re always doing surveys here at devopsy.kinsta.cloud, announcing the new Security Boulevard site—what we’re seeing is, you know, we always saw people messing with the containers, right? R&D testing, what have you—but the numbers of containers, the percentage of companies that have containers in product deployment, you know, in real, frontline stuff? Where it was—jeez, just two or three years ago was low teens, below 20 percent—is now climbing, getting near that critical mass number, right, of 50 percents and stuff like that. And that’s huge, right? You’re talking about early adopters moving to mainstream in a matter of months, and that’s —

    Osnat: That’s correct.

    Shimel: — that’s the numbers you see as well?

    Osnat: Yeah, we see that. And again, I don’t think this would’ve been the case if containers weren’t easy, as I said. I mean, there’s always a learning curve with new technology, but I think if you’re a new developer, a new programmer working today, working on a greenfield application, there’s really no reason for you to use something that is not containers unless it’s something obscure for technology reasons.

    But mostly, it’s a much easier way to develop applications quickly than previous approaches. And I think, you know, if we take a broader picture, a container is—this adoption of containers does not occur in a vacuum, and we actually see a convergence of three trends that are kinda coming together and containers are probably the biggest enabler of those three trends. And these trends are happening independently of each other. So, you know, one trend is one that you are very familiar with, it’s the name of your site, is DevOps, you know, the proliferation of DevOps as a method, process, organizational philosophy, et cetera, which is all about delivering applications faster and in a more continuous way, and containers make that easier than before.

    Another trend is the move to microservices architectures, you know, for web applications or cloud native applications, which is basically adopting what web scale companies like Facebook and Twitter and Netflix started, and now bringing into the mainstream. That, too, is facilitated to a great degree by containers, because implementing microservices as containers is, today, probably the easiest method of doing that. I mean, there are the so—called serverless architectures, et cetera, but they’re much less mature than containers are at the moment. Not that containers are super mature, but they’re more mature.

    And the other aspect is the whole kind of hybrid cloud, cloud native movement where, you know, it took 10 years, but enterprises are adopting cloud services in a very big way, including industries that you would never dreamed of having on the cloud, on the public cloud, like pharmaceutical, health care, insurance, banking, federal, and so forth.

    So, all of these—and again, containers, because they’re portable, because they can run anywhere in the same way, they’re a really good way to realize this notion of hybrid cloud. For example, we at Aqua have a customer—who, unfortunately, I can’t name, but it’s a well-known company. And they are, for them, this is already a reality. They are deploying applications on both Amazon and Azure using the same framework, using the same security policies, and in a way that makes these clouds interchangeable for them, so they can run application A on Azure today and they can run the same application on Amazon tomorrow. So, that’s a real change that we see, and containers are a big part of that.

    So, all of these things together, I think, are what’s driving this adoption. And yet, you know, I think we have to distinguish between adoption and penetration or, you know, maybe some other word. But the fact is that today, if you look at the total workloads that enterprises are running, containers are a very, very small percentage of that. But, if you look at any new applications delivered over the next five years as well as looking at migrating legacy applications to the cloud, you’ll see this number growing exponentially over the next few years.

    So, yes, in terms of the number of enterprises now either looking at, working with, or already deploying containers, that number is growing very fast, and I think there’s probably hardly a large enterprise on the planet today that is not at least thinking about containers if not already using them. But at the same time, you know, it’s early days for them. Most of them—not all of them, but most of them, the vast majority are looking at the first few applications being deployed, and this is just the first drop of rain before the deluge. So, it’s gonna be a lot bigger.

    Shimel: Yep. Rani, a couple of comments, questions, follow ups. So, first of all—yes, DevOps, containers, they seem to go like peanut butter and chocolate. Again, so does microservices and containers, but to me, I—you know, when I was a kid, a teacher once taught us that all spaghetti is macaroni, but not all macaroni is spaghetti.

    Osnat: Sure.

    Shimel: So, it almost seems that, you know, wherever you see containers, you see microservices, but you don’t always see containers when you see microservices, right? In some regards, microservices can be even bigger, right? It has even more of a use footprint. Actually, on devopsy.kinsta.cloud, we’re launching a microservices channel which we hope will eventually grow into a standalone site, because I do think microservices is that big and has the potential to be that big.

    Osnat: Yeah, but microservices is not a technology; containers are. Microservices is an architecture, you know what I’m saying? There’s a difference.

    Shimel: Yeah, fair enough. Yep. But, you know, bringing it back—and, of course, loud usage and all of that. But, let’s turn for a moment and talk about the mission of securing containers and all of these architectures and platforms and so forth. That’s really what Aqua is, and when we talk about why they invested money, these investors, not just because the containers are so big, but because the mission of securing them is also big.

    Osnat: That’s true. So, yeah, I mean, when you look at—so, first of all, we’re not really, I mean, the fact that we’re a container security company might allude to the fact that we secure containers. That’s not exactly true. So, you know, we don’t look to secure a container or containers, we look to secure the workloads or applications that are running on containers.

    Shimel: Mm-hmm.

    Osnat: And that’s a difference. Because—and again, here, there are several trends that come into play. One is really that these things that I mentioned before, the DevOps trends, the microservices, architecture, and moving to the cloud, they also affect how you can and want to do security. You know, if we look at the cloud first—when you go to the cloud, a lot of the basics, you know, the bread and butter security that you use to invest in as an enterprise disappears. Why? Because these are services that are already taken care of or provided by the cloud service provider.

    So, you know, when you run your applications on Amazon, you don’t really have to worry about things like data center security, infrastructure security, network security to a degree, identity management to a degree. And so, a lot of these things are—you know, they’re basically taken care of for you. So, the focus shifts to the application layer, and that is one aspect.

    Another aspect, which is a really positive one for using containers, is the fact that, since you are now breaking up the application into a bunch of microservices, you can have much more visibility and control into what the application is doing. You know, if you look at an individual container or microservice, it’s much easier to understand the intended function of that container or service, and consequently, be able to understand what is considered good behavior, and be able to identify pretty easily what is bad behavior. And you do that at a very granular level.

    Additionally, if you look at the networking aspect, in a way, the networking has been brought into the application in a more visible way than before. Before, you could have things done within the application that maybe a malicious actor did within the application, and it’s all done internally, and it’s a black box. You don’t have visibility into it until it actually gets out.

    With microservices, you are able to see the interaction between the different components of the application, sometimes at a very fine grained level and, again, be able to identify any kind of weird or abnormal communication between, you know, parts of the application that are not supposed to be communicating that way. So, that’s another benefit. So, these things really allow us to have much more control and visibility over what the application is doing.

    The last piece is around DevOps, which is often nowadays coined as DevSecOps, which is the whole notion of shifting left security—i.e., bringing some of the control points not to the run time environment but to the developer environment. And why is that? Because containers are also immutable, right? So, if you’re using containers directly, you’re not supposed to see any change in one time environments. You’re not supposed to see patching, nobody is supposed to SSH into your host that’s running containers, it’s supposed to be entirely orchestrated and automated.

    And so, anything that happens there is by definition not good. But, at the same time, you have the opportunity to make the application more secure from the start, which is in the development phase, and that includes things like, you know, removing vulnerabilities, ensuring the configuration is correct, enforcing best practices. And if you can automate that—which we do—then you’re winning, right? Because you’re delivering a much more secure application to start with, you’re gonna have a smaller attack surface, and then in run time, all you need to do is make sure that there is no drift or no unexpected changes to the run time environment, which would be considered malicious or at least suspect.

    Shimel: Got it. So, Rani, we’re running a little low on time. We’re actually out of time, but let’s keep talking. [Laughter]

    Osnat: [Laughter]

    Shimel: So, now, we’ve got—what are you gonna do, how are you using the 25 million? What’s the plan?

    Osnat: Right, so you know, in our short life of two years, we managed to launch the product very early and get quite a few enterprise customers, many of them Fortune 100 customers across many industries, and that sort of traction is what really made Lightspeed and the other investors invest in us, and we need to continue this. The market is growing, right? As we mentioned, adoption is growing at an accelerated pace, so we need to be there.

    That means, you know, investing in the quality as well as the breadth and depth of our solution. There is—containers are not a singular technology. I mean, there’s a lot of variation in the stack, not just in orchestrators and OS’s, but in the container engines themselves, and this will become even more so over the next few months as things like, you know, additional run time engines are introduced, and not just the Docker open source run time engine.

    And so, this requires investing in the right technologies and making sure that we can fulfill the requirements of our customers and, additionally, of course, we need to expand our presence, both in the U.S. as well as in other parts of the world.

    Shimel: Let me talk to you about that a sec, Rani. So, I’m gonna assume U.S. probably represents at least 50 percent of your market, is that about right?

    Osnat: That’s correct, yeah. [Cross talk]

    Shimel: And probably Ameya the lion’s share of the rest.

    Osnat: At the moment, yes, but Asia is also growing, you know, there’s—

    Shimel: I also wanted to ask—what about AP?

    Osnat: Yeah, so Asia Pacific is growing as well. There are a lot of container users in places like Australia, China, Japan, and so forth. And so, this is—these are obviously big economies, there are big companies there. They’re as advanced in terms of cloud adoption as the U.S. in some cases. So, we need to be there.

    Shimel: Absolutely. Well, how do you—so, I was actually out at RSA APJ this summer, and it was in Singapore. And, you know, I had a chance—I actually put on a DevSecOps event there with RSA. So, I had a chance to talk to many of the RSA attendees, some of the vendors and stuff.

    I mean, what’s interesting there is, your infrastructure, you know, even in Europe, AWS is an 8,000-pound gorilla, right?

    Osnat: Correct.

    Shimel: Where do you—we don’t see that in Asia Pac. AWS is still a player, obviously, but there are other solutions there.

    Osnat: Mm-hmm. Yeah, that—

    Shimel: Go ahead. How does that affect you guys, or how do you deal with it?

    Osnat: Well, it affects us partially because mostly, you know, we’re pretty much cloud agnostic, right? We run on all the major clouds. It’s not a major effort for us to run on additional clouds. You know, even today, we support Amazon and Azure, Google, IBM Bluemix. And so, it’s relatively easy for us to support additional clouds, and it’s not a—that’s not the stumbling block, in most cases, right? It’s more like things like esoteric OS’s or weird configurations that we encounter sometimes. But, in most cases, that would not be an issue. Not to mention that a lot of companies are also running private clouds, using VMware or other types of virtualization infrastructure. So, that is really not a stumbling block for us, at all.

    Shimel: Good, good. Interesting. Rani, as I said before, we’re way over time, I need to wrap this up. But, first of all, congratulations on the raise. I’m sure Aqua has 25,000,000 good uses for this money as well, and we’ll see more coming down the pipeline in terms of both functionality products as well as reach around the world. You know, always good to have you on, you have a great handle on where the container market is and of course where the container security market is.

    So, thanks for being our guest today. We’ll have you on again soon.

    Osnat: Thank you.

    Shimel: Thank you. This is Alan Shimel for DevOps and Security Boulevard Chats. Thanks for listening. We’ll hope to see you soon on another chat. Bye bye, everyone.

    — Alan Shimel