Good morning, good afternoon, and good evening, depending on where you are in the world. Thank you for joining us today. This is the Tech Strong Learning Experience with Aqua Security and AWS. My name is Amanda. I'd like to welcome you to our Tech Strong Learning Program.
Today's topic is Accelerate Application Modernization, Faster and Smarter Deployments on AWS.
Today, I'm joined by three great speakers, Nidhi Mota, senior container specialist at AWS, Itamar Evgey, solution act architect at Aqua Security, and Jooheon Kim, senior container specialist and solutions architect at AWS.
And I'm gonna give the floor to all of you today. Mimi, would you like to take it from here?
Gladly. Thank you so much.
Hi everyone. I have been at AWS at, about three years now. I lead the go to market for Amazon ECS and AWS Fargate. And, yeah, super thrilled to be here.
Do let us know where you are in your containerization journey, how familiar you're with Fargate.
Yeah. And let's let's keep this interactive. So alright.
Setting the Stage for Application Development
As, as I mentioned, we are going to be talking about accelerating a model and application development with Aqua and how and introduce you, to the serverless platform operator kit that we call Spark. Okay.
So before we before we before we do this dive right in, I sort of wanted to set the stage, by talking about when customers like, what do, you know, I, I often get this there when I'm building a modern application at scale, what do customers really want? Right?
Your developer team, your, your, your application teams wants to focus on building apps. They do not wanna worry about infrastructure provisioning. They want to be able to scale seamlessly. They want to be able to respond to demand shocks.
They want to, they want their application to be performing. And finally, they they want to do it in a manner which is secure and reliable, you know, maintaining your SLAs and SLOs. And and really the the customer want to do this at scale for their production workload. Right?
So when they when we say a modern cloud native app, really what we are alluding to is business agility. Right? It's the ability for your application to respond to your, business needs in real time and seamlessly.
Well, so where do containers fit in over here?
Unless unless, you know, you've never heard of containers, you are probably familiar that containers have moved well past being the, this problem doesn't occur on my laptop to the de facto standard, to modernize applications. Right?
Not only do they reduce the risk, in terms of having a, you know, uniform security across, across environments, which you which really the key value proposition here is the automation that containers provide as opposed to, you know, having to do it yourself and managing your host, worrying about, worrying about scaling, and responding to to demands. Right?
Reduced operational burden.
This is something that you wanna offload to AWS, and not have to ever worry about, you know, managing your own host or worrying about deploying your containers out there in the cloud. Right? And previously, as I mentioned, the your your primary business metric, especially as you get new production workloads and new applications, into the market is your developer velocity, and containers helps helps with that all while maintaining, agility.
Sustainability and Containerization
And I think that a really interesting part about containerization, which oftentimes customers don't think about is how they contribute to sustainability. Right? Now when you are elastically, allocating demand, you're only using you're paying for what you use. And at the same time for at AWS, when you use instances like Graviton, you're really contributing to that sustainability, some sustainability conversation as well. And using, you know, fewer, fewer resources to deliver the same performance.
Alright. So where does Amazon ECS and AWS Fargate, fit in here? One of the things that I've seen over my years here at AWS is that when when customers adopt the cloud, they begin with Amazon ECS. Actually, about sixty five percent of all new, AWS containers customers, use, use ECS.
And so much so that we can sort of think of ECS as the serverless container orchestrator. So we have the serverless compute engine, which is AWS Fargate, which, you know, seventy percent of customers start to begin with. You know, they they offload all of the host management, the patching, to, to us. Right?
And also it solves the problem of bin packing at scale. When you are trying to pack a whole lot of tasks, on a single EC two instance, over a period of time, your clusters get fragmented and then you're you're really in those low low utilization numbers. With with Fargate, you know, which is basically which is a tenant of Fargate. Right?
You're only paying for what you need, and you have one task per micro VM or per instance.
You're sort of, you know, taking care of that bin backing problem, or or AWS is taking care of that bin packing problem for it.
And just the scale at which our customers deploy it is, you know, over billions of ECS tasks are launched every week, making sure that, you have the, you have the agility and the performance that you need.
Customer Success Stories with ECS and Fargate
Just some just some some key customers that, you know, to to kinda talk about really how customers are getting value, I wanted to talk about a few customers.
United Airlines, is a big one where they actually use their travel app, which, which has a feature of called delays and and, cancels, and that's built on ECS Fargate. And it really helps them, you know, seamlessly adopt or or react to scale. And and and and the value that they get out of Fargate is never having to worry about that extra operational overhead, and it helped them build a net new app, quite quickly.
Autodesk is one of our customers that actually has hydraulic simulations, running on ECS and Fargate. And while we won't talk about it, they use this technology that AWS has open sourced called Seekable OCI, Sochi, which help them, deliver and increase their startup performance. So it's, you know, one of the bottlenecks for a container image, or for your entire deployment time is when a container image is being downloaded and the the finite amount of time that it can contribute to your container startup time, and Autodesk Autodesk was able to optimize that. And then finally, our regulated our customers working in highly regulated industries, financial industries, such as Goldman Sachs, they rely on that built in security that Fargate, provides, with all of the compliance built in that they would need for their end cost, end customers.
And a little little long fact, but a lot of Amazon's own applications are powered by ECS and Fargate. You're talking Prime Day, which is gonna be coming up. That's gonna be running on ECS and Fargate.
Fire TV, dot com itself, PolyTranscribe, SalesMaker, a lot of AWS's managed services, run on top of ECS and Fargate.
Challenges in Application Modernization
Alright? That being said, while I've kind of painted a picture of where the customers, where the customers tend to adopt serverless computers, One of the key things to note is it's not as simple as I have a container running up in the up in the cloud, and I can go about and, you know, go out and and and celebrate. There's a whole lot of challenges to getting that entire deployment pipeline, running on all the automations up in place. So what customers actually think app modernization looks like is I have my idea. Yeah.
And I I I have my application code. I push it into a CICD pipeline.
And great. I can use, you know, ECS, which is a completely managed control plane for free and run these containers serverlessly in the cloud using the Fargate launch type, and I have innovation.
This this would this is a realist this is a very, very unrealistic and simplistic picture. This is what we aspire to be, but that's not where reality is. Right? So here's here's the reality, and I talk I talk to customers all day, as they just begin their POCs.
So in reality, they get bogged down by the complexity of tools, to get started on contents. For instance, the first thing they probably have to worry about is the plethora of choices that they have when they are building a CI pipeline. Do they wanna use the code star products? Do they wanna use GitHub actions? How are they going to be you know, how are they what is that automation gonna look like? Are they go are they gonna be using infrastructure as code? If yes, what would it look like?
Right from the get go, observability is oftentimes not not top of mind for customers, and you wanna think about it, you know, a good when you're when you're running your containers in the cloud, you want them to be instantly secure and observable.
Again, by choices, oftentimes, if you already have a tool that you're working on premises and you're moving that to the cloud, that's something that, you know, you want in your observability stack, not to mention, open source tools like Otel.
We haven't even touched upon networking. Then if if there are needs to do east west, you know, east west, service, service discovery or more complex mesh like needs. You wanna think about this, you know, while you're building your while you're decomposing your monolith and bringing it into containers.
You you what kind of runtime security would you need?
Much, much many more decisions just outside the one compute piece, which might seem apparent to you, which is, you know, go pick Fargate and go and and not manage your VM. So all of these all of these, all of these components is what is what really, is behind, a a modern app. Right? All the way from your delivery, observability, security, and networking, and even compliance and governance. Right? So these these decisions bog you down and just make it slower to get started.
So as I mentioned so so so just to, like, further elaborate on, you know, what would it take to transition to this production work words, Here are some of the components. Right? Not only do you have to containerize your application, you have to configure your infrastructure with an IEC tool, you have to build a deployment artifact, all of that and all this doing it at scale. Are you gonna be operating on a machine VPC?
Do you need a single cluster or perhaps multi cluster from the get go? You need to have a multi account posture because you wanna attribute applications or charge back to different, to different, you know, application development teams. So a lot of considerations when you're building even just your first app. So, the the the reason why we've sort of come together here is to address this problem.
When I see customers who are on self managed DC two or moving for from on premises, They often they often come to AWS to ask for best practices that other customers who look like them, who have similar challenges like them, you know, are trying to are are trying to address and how they do that.
Introducing the Serverless Platform Upgrade
So this is where I introduce something called the serverless platform upgrade. Okay? The way I want the the way I wanna think about I want you to think about it is it is a set of tooling that helps you accelerate or get get started faster. It is opinionated.
It is end to end and well tested, and it gives you a framework in which to think about how other customers have, you know, built their applications grounded in best practices from, AWS. So while SPOC is meant to be extensible, this is not a one size fits all. It is absolutely it's a it's it's meant to be a starting point, and we will, you know, we will do a demo here, and I will point you to the repo. It's meant to be a starting point for your applications to get started on AWS quickly. It is extremely configurable.
We will be talking about how AquaMon security integrates with it. But at the same time, if you do not wanna be using your IOC as Terraform and you wanna use CDK, that's something you can do as well. But for this version of, Spark that I'm introducing, there are a few key components to consider. For IAC, we are gonna be using, Terraform.
We are going to build our CI pipeline for this demo for code pipe, and actually, for corporate pipeline. But if you if you want a GitHub shop, you could use GitHub actions. Our repo of choice would be ECR. That's where we would have our images.
For monitoring, CloudWatch container insights is often the first step or rather, you know, the most integrated, the most integrated solution that a large majority of our customers who are getting started on Amazon ECS use.
We will enhance our security, and Duane's gonna talk to that. But for now, assume a really good integration with Secrets Manager all while all while using the Fargate, launch tag. So hopefully, this gives you an idea of sort of a reference architecture of sorts, which is end to end. It is a bundle.
Reference Architecture for Modern Applications
I like to I like to simply think of it as ECS Fargate in a box. It's, when when you are consuming Fargate, it's more than basically two and gigabytes. Right? You need all of this instrumentation to, to be able to build a modern app.
And, that's that's the problem that we're really trying to, trying to solve. It it takes a stance and an opinion on some choices, which is not to say it is not extensive.
Alright?
I wanted to with that, I wanted to hand it over to Julian to kind of talk about how Aqua is is enhancing, stock.
Over to you, Julian.
Thanks, Nidhi.
Can you move to the, next slide?
Yeah. So as Nidhi already previously mentioned, Spoke is a serverless platform, operator kit, and it offers a robust technical stack that emphasize best practices.
So what that means, this, with spoke, you can, provision, like, a production level workflows on ECS, now can can be done more kick quicker. But it is not just for about the ECS and market, but the thing is, Watch and AWS as a secret manager for establishing end to end to Watch and AWS secrets manager for establishing end to end solution. That was the thing was needed already mentioned. But the thing is today in our webinar, we we not only include the AWS secret manager, but also include the Aqua MicroInfoster agent into the one of our spokes security components.
So with that, Itima will, explaining about what is the aqua's microinforcer agent. And then for me, I will going to show you about how can we, include, microinforcer agent into the spoke, and then what kind of security inside did did you get from there? So that is the thing I want to highlight, in today's of spoke components and then demo stuff.
Yeah. I think, with that, I can hand it over to the Itma about he will, dive into the Aqua security solution.
Securing Containers with Aqua's Solutions
Just sharing my screen here. So good morning, good afternoon wherever you guys are. My name is Itamar Ibiani. I'm a cloud solution architect here at Aqua as part of the business development and strategy team. And part of my role, here at Aqua is working with wonderful partners such as AWS on these, wonderful projects.
And so, talking a little bit about how where we start in terms of, securing these containers, we we look at that. We start with a crawl, walk, run approach. Right? First is going to be scanning the image, looking at the various components within the image if we're looking at any opens any vulnerable open source packages, any, any sensitive data within the image.
We wanna know what we're pushing out to production. Right? Very similarly to when you're walking, through the store and you're you wanna purchase something, you wanna look in the ingredients. Right?
Am I putting something in my body, something bad in my body? Am I, what am I what are this, what are the components of this what the ingredients is as part of this, product. So, we start we see a lot of our customers also using the the open source version, the Trivia open source version of, of Aqua in doing the the scanning. And then gradually taking that into, the second into the more walk approach where, a lot of these containers are being run-in a sandbox environment, to identify any, malware or any be any activity or any malicious activity happening in runtime.
Right? So when we're looking at image scanning, we're looking at static, vulnerabilities. We're looking at outdated packages.
But when we take that container and we run it in a sandbox environment, we can see if there's any malware in memory. Is it dialing out?
Is it doing anything that it should not be doing? And then the last part is, runtime protection. When you finally have it running in production, we wanna know what is the container doing, is there any shift in configuration, and making sure that the container is not exposing us, to, to additional risk.
So there was a lot of, great conversation around the benefits of of a Fargate. And so that being said, some of the challenges that we see, or our customers are facing is that when we have the traditional, EKS or ECS environment, we can see the host. Right? The the customer is able has access to the host. We're able to deploy those agents, on the host and really get granular information, as part of that as part of that, approach. With Fargate, that creates an abstraction layer, from the host specifically, and it's very hard or impossible to really create that, or to deploy that, to deploy that agent. And so there are two different approaches to, kind of deploy that agent.
We have the ability to deploy sidecar, right, which is essentially a container that sits alongside the, the application container.
It's enable enables you to deploy the container in a in a way that you log in to the console, you're able to, attach it as a as a site container. There's some some pros and cons to that as well as you can see. And, there's also the embedded approach where you embed the, embed the the, aqua agent, as part of that as part of that deployment.
Introduction to Micro Enforcer
And so, to that, the the Aqua has developed a the micro enforcer, which is worth mentioning, for a moment that, it is a patented, a patented, micro enforcer that was kind of about six years ago, and we had the our our our founders were able to foresee the the adoption of of the, Fargate and serverless. And so we're able to deploy these two as a sidecar, or as an embedded, the the two different approaches. And, again, really being able to focus on detecting malicious activity, preventing any, any, malicious activity from happening and and collecting some of that, forensic data if there is a if there is a, an event that's happening.
And so if we kinda zoom out for a moment and see how that micro enforcer is, deployed within the platform. So the first thing that we do is we're we're onboarding a lot of the, the, the the accounts from from the various, environments, and we're able to do a discovery of the environment. What are we actually looking at? How many containers? Where do they reside? And then on top of that, create and assess, create and assess the risk as part of those and then, create a policy that will eventually, be enforced by the, micro enforcer.
Forensic Insights and Security
And so to kind of tie that, some of the highlights of the, utilizing Okwoye is, being able to gain a lot of forensic insight as into the environment, prevent those attacks before they reach production. Right? We are looking at, securing from code to cloud. So from the time the repositories, code is being submitted to the repository into the container when it finally moves, to the, to production.
So with that, I will hand it back to Jooyoung for the demonstration to kick it off.
Okay. Yeah. Let me share my screen. First, we are in a real kick, and then we can start from there. So, can you guys see my screen at this moment?
Yes.
Yeah. And then, let me know if the, letter is too small, then I can enlarge a little bit more. So this is a a repository that is a stand for the spoke, we mentioned earlier, and I just copy and paste the link in here. So if you have any, like, suggestions, something like ECS CC two, or do you want any component, like, we doesn't cover at this moment, then feel free to, put some issues, then we can start from there. But the thing is, as Nidhi mentioned and then I already mentioned, spoke is the end to end the solution. So it's not only just cover of something or component, but it is all about it. So what that means when you provision, this Terraform source code pile, then all the spoke running is that at very first, it will provision the VPC and then create the ECS cluster.
Integration with Other Components
And, also, as you can see in in here, you can integrate couple of components like a Datadog or Aker Security or GitHub as well. And then, the thing is we also adding some of the other component to something is good for, ready to production level. What that means, we also can integrate the CICD pipeline, and, also, you can saw or you can get some observability, from the spoke as well.
And we also have a sample application already, uploaded in here, but you can just, put your application and then upload it. Then the spoke will be running, your is a containerized application.
So, at very prerequisite, when you are trying to start the spoke, since all the source code is made by the Terraform. The reason why we, to choose the Terraform is that, during our observation, like, a major tier of ECS for our gateway customer using the Terraform. So with that, we just select the two go ISD component.
So, before we provision the Terraform stack, well, we need to provision, like, a DynamoDB and then s three for the tracking telephone status. And then we are ready to provision all the things. So when you look at the readme file, all you have to do is just to change the back end telephone file and then put your account ID information into here, then you can start from there.
Spoke Hierarchy Overview
So yeah. And then, I'm gonna explain a little bit about the hierarchy about, this spoke. So as you can see in here, here is a couple of docs, that you can see. The thing is at very first, if you just deploy the spoke in a simple way, then you'd, maybe CICD pipeline and then Datadog or Aqua Security doesn't attach it. So I'll right after that, I'm going to explain in how can we attach Aqua's, securities of microinforcer into the spoke. But the thing is I also, adding some detailed readme file in here, so you can definitely take a look this one and then integrate, microinforcer into the spot.
And then here is the module as you can see.
We made all the components in a module way. What that means, you can easily reuse it or if you want to customize some of the things, like, let's say, in terms of aqua security, there's a lot of bunch of thing you can configurable. So with that, if our, baseline taste baseline, the Terraform file that is doesn't satisfy or you want to add a couple of customization thing, then you can just change this module or Terraform file, then you can easily make something in your taste.
And this is the main point. So as you can see in here, there is the pattern, in this spoke file. And in terms of target cluster, under this, you can see the bunch of tariff profile. And then this is all the thing that include, that we include all the components, for the spoke.
Main Terraform Configuration
So this is the main Terraform file, and we configure all the thing into the here. But the thing is when you are trying to obtain or obtain a couple of components, then you must have to jump into the Terraform, variable file so we can start from there. So at very first, I just set up my, cluster name to the ECS core. And then since we are trying to, set up this, develop, deployment, development stage, so I just stick it there. And then we are going to provision, all this thing into the US eastern one region. So I mentioned, like, this way. But if you want to change your vision, then, absolutely, this is a configurable.
And then here is the ECS ECS service sample, but you can also, set up the we see PUM memory, based on your application stuff.
And then scrolling a little bit down, you can see a couple of configuration that you can customize.
And here is the point at, at today.
So as I previously mentioned, we include a couple of module, and then you can opt in, opt out. Right? So today, we are going to integrate our spoke, application or spoke system with the aqua aqua's, micros enforcer.
So at initial pace, we force everything.
But when you change this one to the true value, then it will provision, acquire sidecar, ECR repository, and also we create the microinforcer sidecar as well. So you can make, you can just turn on, turn out by setting the value of whether true or false.
CICD Pipeline Integration
And then in the right here, since I told you this is a end to end solution, and we definitely need to conclude, definitely need to conclude, include the CICD pipeline as well. So with that, I also set up this to the true, and all you have to do is just set up the which repository are you going to use and then, like, set up the Docker Hub a secret name, and then feeding those of value into the, secret manager, which name is a GitHub, then you can deploy CICD pipeline as well. And then also if you enable the aqua set component, then it this will be also included.
So for the saving the time, I include everything and then provision the, into here. So what I first, what I did was at bay at very baseline, I set up the older value to the false. With that, it only create the ECS cluster.
So here is the wizard, like a ECS core, with the just one ECS services.
But after that, I previously mentioned, I just opt in the GitHub c I GitHub with the AWS code pipeline.
Then with that, you can configure this one. But the thing is we are going to melt our, our Quasex microinforcer into this CICD pipeline. So, we before we provision or obtain our CICD pipeline, we need to configure and then, provision all the aqua relevant component like Amazon ECR repository and then making the, sidecar stuff as well. So, with that after that, you provision the CICD pipeline, then you can include, those of, solution to the your CICD pipeline as well.
Secret Management Best Practices
So I'm gonna briefly explaining about what I configured when it comes to this demo environment. So at very first, previously, did you mention, we are stick to the best practices. With that, we are saving all the value into the secret manager. So at very first, when you started, this AQUASEC integration module, then you have to fit, like, a a key put the AQUA URL and the username password into the secret manager, component, and then you have to set up the name to the.
But you can change this name, then you need to, change our main terraform as well.
And then we are going to, today's demo, we are going to, show the demo about the micro enforcer sidecar.
But as Itma mentioned earlier, there is a two way to secure AWS of Fargate containers with the aqua sec, right? One way is the well known side of the cockpit. I'm going to show you today. But the other one is improving the embedding the aqua security agent, meaning microinforcer directly melted into the container image.
But today, I previously mentioned, I will going to show you the sidecar. So with that, we need to make the sidecar container image ahead before feeding into our ECS task submission.
With that, at very first, the thing that I previously show you, the Terraform variable file, at very first, we need to, set this value to true. What that means, we are going to provision, ECR repository which will contain the aqua sec sidecar container image. And then just initialize your telephone file and then apply it, then the sidecar, the ECR repository, which name is aqua sidecar, will be provisioned.
Building the Sidecar Container Image
And we have a guideline of when it comes to we are making this container image, at very first, we need to download microinforcer execute file. And then we also have to use the doco file, for building this one. So this one is already made in here, as you can see. So we put the doco file in here.
So all you have to do is download it, the execute file, and then put it into here, and then making container image and push to the ECR image. Then you're ready to, use this, microinforcer into your ECS nation. So this is the process, I previously already did. So as you can see in here, when you click the aqua sidecar, then I already made the, late container image with the latest tag, which include microinforcer.
And then moving a little bit down, so we are going to feed this aqua sidecar into our ECS task definition.
So with that, we need to put some, information, something like aqua server and then aqua token or aqua image. So we need to have fit fit those of thing into here. And then after you enable the, aqua seg sidecar through and then put your account ID, into here and initialize the Terraform, again and then apply, then you can, get the ECS service with have a micros, enforces inside the car.
And then I told you, after at very first, like, feeding this way, when you want to, put some of the CICD pipeline, then all you have to do is just to enabling the GitHub, component, then you can get this one, in the same way. So I already provision all the things, and then let's see the wizard of what this looks like.
ECS Service Configuration
So here is the ECS demo. As you can see, this is, ECS service.
And when you click the task, we just running the one ECS task. And let's take a look at what kind of stuff is configured into ECS task operation.
So scrolling a little bit down, as you can see in here, you can see the two containers in one ECS task one ECS task. So, ECS sample is the main application, where main container as application, we made. And then right beside, you can see the aqua sidecar in here.
So, like, this way, you can see, and then we already did some configuration, like, fitting environment value that I previously mentioned.
And, yeah, other than that, you can see the aqua sidecar here. But as you can see, he this is the, image that is came from the ECR repository that I previously mentioned.
So with this, when this one executed, then, Aqua sidecar will be melted into the your containerized application, and then it will start to posting some of the insight value to the aqua platform's dashboard.
Monitoring and Insights from Aqua
So in oh, sorry. Oh, seems like my session is all about at this moment. Let me take you a little bit more.
So as you can see in here, I already feed the enforcer in here. So as you can see, one of the thing is connected.
But let me show you some detail. As you can see in here, there is a IP which is added to one nine seven. And then when we look at that ECS task provisioned in our area, Yeah. This is the same IP, private IP that is attached to here. And then, you when it comes to click the dashboard in here, you can see the various of, like, risky things or what kind of vulnerability can be observed this containerized image and then, like, application stuff. So with that, I'll hand it over to the ITMA because ITMA has a abundant, aqua platforms of dashboard.
So, yeah, it's my if you don't mind, you can switch to the your, page and then, yeah, we can start from there.
Summary of Deployment Approaches
Awesome. Thank you, Jiyoung. Just wanted to let me take another a brief moment, and, touch on the, what was covered here. Just one moment.
So, again, we have two different approaches. Right? When we want to, create or secure the Fargate environment. So the first one, like Jun mentioned, is through the sidecar.
The sidecar is essentially, again, another container that we're adding.
Besides the application container, you can very quickly deploy it and, you know, some of the and we'll talk about some of the challenges, but, essentially, you don't have to pull your, you don't have to pull down the the the image running in production, and then essentially a, another container. Within the embedded, image container with the with the, agent rather, obviously, there's some some challenges, but, essentially, it's part it becomes part of the image. Right? And so, again, taking a look at some of the advantages and, maybe not disadvantages, but there are certainly different use cases, right, to each one of the, each one of those and and how you, decide to, secure your ECS Fargate environments.
And, we see that with the adoption with a lot of customers. So if you have two hundred environment with two hundred containers with multiple applications, most of the customers will will start with a sidecar and then gradually as the adoption of, Fargate and Aqua continues, they move towards, the embedded enforcer as well. So with that, let me go ahead and share my screen and bring up the AQUA platform.
Overview of Aqua Platform
Okay. Coming up here.
Alright. So, essentially, what we're looking at here is the Aqua platform. It is important to note that we're looking at the SaaS, version of Aqua, but we also have an on prem environment that allows you to, secure workloads in a more, restricted environment.
And so when we onboard, some of these accounts, cloud accounts, when we onboard, and start pulling information, we get a lot of events from a lot of different, sources. Right? It creates a lot of different noise. And one of the thing that we we pride ourselves in is being able to cut the extract the music from the noise.
And so what we do is bring all of those variables together. There are three different components. We talk about securing from code to cloud. So we're looking at the repositories.
We're looking at the environment in which your ECS environment resides, and and we're obviously looking at, the workload themselves. And we distill that down to what we call, insights. And so we get a very, contextual events within your, within your, environment that needs to be addressed immediately.
Understanding Vulnerabilities: Reverse Shell
And so if we maybe, look at kind of drill one of those down and be able to kind of get a little more insight, I wanna draw your attention to a, one of those vulnerabilities. It's the, reverse shell, vulnerability. And for those who are not familiar with that, type of vulnerability, it is a typically a misconfiguration that allows somebody to inject code into your application and, be able to access your environment and, being able to do either malicious activity or extract data. So that is an often, misconfiguration, obviously, not in a malicious way, but kind of, like, leaving the kind of leaving the, the backdoor open.
And so, you know, some of the these are real events that, you know, that happen in in these, ECS, environments, obviously, also over within Fargate. And we want to be able if there is if anybody was ever part of an incident, you know that you wanna extract as much information, from the incident. You wanna know what happened, what got impacted, where the containers reside, what kind of what cluster it's in, and really start piecing together the incident that occurred.
And so, one of the things that we're able to do by collecting all this information is being able to, clearly articulate where things kind of started and really draw a chain of events here, and I'll scroll all the way down here, and and really understand where kind of things, started.
Visualizing Vulnerability Data
And so, a lot of this one of the thing that I wanted to show you is, again, being able to, collect a lot of that broad data as part of that event.
And if we maybe you wanna take another view how this represents, from a visual perspective. You see that we have a developer that submitted code into, our repository.
It got pushed, it got compiled into an image, and then finally, it got, pushed into production, which allowed this, vulnerability to take or expose, this container to this, particular particular vulnerability.
And so as you kind of see, everything kinda starts with the image. Understanding what we have with the image if we're pulling any sort of, vulnerable open source packages or we're adding, any, any any, private information or keys, of that sort. So it kind of, like that's that's where a lot of the issues start. And being able to really look at the image and being able to clearly articulate what vulnerabilities might be on that, image is is, obviously very helpful. So maybe taking a moment or two to take a look at what we actually extract, what information we see when we're doing an image scan. So first and foremost, there is quite a bit of of vulnerabilities and good information that we can extract from each one of these.
Remediation Strategies for Vulnerabilities
We're able to pull, context tool information regarding the remediation of the, of the, of the vulnerability and kind of a step by step guide of how to, remediate the, the vulnerabilities.
We mentioned at the top of the call, running a dynamic threat analysis or using the dynamic threat analysis, feature of Aqua, which enables you to deploy the, image in a sandbox environment that will allow you to see if there's any anomalous behavior or if there's any malware running, in in, in memory.
Once we have those defined and we want we sanitize their image, we remove vulnerabilities, we want to add and create policies, for our runtime for the containers to really lock them down. Right? We wanna make sure that, there is no drift in our configuration that, we're not allowing anyone to access or exec into the, into the container and really prevent drift from happening, within those within those environments. Obviously, that's a a a fairly big indicator of compromise since containers really should not be doing anything besides what they're meant to, meant to be doing.
Isolating Vulnerabilities in Your Environment
And so to kind of wrap that up, we talked about, really isolating the vulnerabilities and the risk within your environment for and really focus on, the the, important incidents within your environment. And so, part of that is, again, taking the vulnerabilities you have and really narrowing down to the we we went from a hundred and twenty five thousand to a hundred and thirty five, exploitable vulnerabilities that you have right now within your environment today.
One of the things that we're also able to do is also, as part of that is enforce something called VShield, which enables you to create a policy specifically for that package and lock that, package down from being, from being utilized.
So, obviously, I've I've I've glanced very quickly over the platform. It's it's feature rich. There's obviously a lot more to cover, and we'll be more than happy to spend some time, with anybody, kind of going through it.
So with that, I will, turn it back to you, Ray.
Awesome.
Thank you, Kumar.
Thank you, Jooyoung for going over that. Let me go ahead and pull my slides up here.
Key Takeaways from the Session
Okay. So as we wrap this up, what did we learn?
So some of the things we learned is as we think about modern modernizing applications of scale, SPOC, ECS, Fargate allows, applications to scale without managing underlying infrastructure.
It reduces, management overhead and enables enterprises to focus on essential tasks, and it fully supports GraphCon based work workloads, which lower cost and enhance performance.
As we think about scale through security, Aqua is a differentiated solution for superior security when running containers on ACS and Fargate, and we have a recognized patent, patented technology.
AquaWall supplies the same policies to all containers without changing security settings, and it ensures transition during hybrid deployments from day one, allowing you to scale and modernize applications in the cloud.
So wanna open up the question. We I see there are some questions in the chat, so we'll continue addressing those. But, you know, feel free to, also ask questions, directly.
Big thank you to everyone for joining. As we leave, there are some additional resources and and ways to engage. First and foremost, we'd love to see you in person. So we have two events coming up, the New York Summit, on July tenth, as well as Black Hat, in August.
We will be sharing some additional links, after this so everyone can take a look at the Aqua Fargate microsite.
We'd love to, you know, provide a personal demo, so we'll have our demo request. Also, our AWS marketplace listing, we are, a marketplace partner, and there's a demo link in there as well, but a lot of great information.
For any partners that joined today and are interested in learning more about, the Aqua, partner program, we'll, provide a link to become a partner.
And then also in there, we're gonna have the AWS Fargate, SPOC repo.
And then there is a link, to an immersion day. So that's an ECS immersion day, by AWS. And then also keep an eye out. We'll be, providing updates, later in, August where we are going to have a, a brand new, ECS Fargate Aqua Security Immersion Day workshop, that we're super excited to get out to everyone. So, again, thank you, Nidhi, Junyoung, and Itamar for the presentation.
And thank you everyone who attended and for, being here with us today. And so now we'll, turn it over for some questions.
Q&A Session: Addressing Customer Concerns
Yeah. Thanks, Ray. I think couple of questions, from some of the, people.
Major your top cost customer are asking about, like, what kind of vulnerability can be checked from the aqua dashboard or, yeah, it just so another question is, can you map this issue to compliance centers? Those of thing was the question. So I think that is more about the how what kind of thing can be provide that can be observed to the AQUA platform. So, if you don't mind, it's much just to see the q and a, then, yeah, can you answer those questions?
Absolutely. Yes. So, there's a couple of different vulnerabilities that we can see. Obviously, we we can see vulnerabilities in runtime. So we're looking at malware.
We're looking at, vulnerabilities that are part of the image, like I mentioned, and we're also looking at the environment. So, again, looking from from code to cloud, we're looking at, the repositories. If there's any vulnerable, code that's being submitted or any, sensitive information, any hard code, keys within, within the, code that's being submitted into the repositories and then how it traverses through, the repository.
And then when it gets pushed down to production, right, we wanna be able to lock down, the image to say only if it follows a certain criteria or it it it adheres to, a specific policy, you will let it go through, the CI pipeline and then eventually to production.
And then from a compliance perspective, we have about twenty five different compliance frameworks that are built into the platform.
They can be modified. They can be integrated, and, there is a your there's a PCI, and some of those, common frameworks within the, well recognized, compliance frameworks within the, Apple platform. So hopefully that answers the question.
Yeah. Thank you.
I think I can take this next one. I think there's a lot of chatter left around what kind of applications can run on Target. I have a long running container. I have a short running web app.
Like, what what what what does that what does that kinda look look like? Right? So I I would say, I would say you wanna think of Spark as more than just the the, Froggy compute. So I'm just gonna answer it in two parts.
Right? One, if it can run on a container, you can use Spark to get started with. Right? And the kind of applications I alluded that earlier.
Right? Customers run a whole variety of applications, and, long run, what else is is one perfect perfect example. You could run real time streaming. You could do video transcoding.
Anything that doesn't require a very specific instance that you, you know, are a network optimally. You you have some very specific network requirements. You probably wanna run that on a specific instance on e c two. Outside of that, if you, if the vast majority of customers, for the vast majority of use cases out there, you could run it on Fargate.
There was also questions, and as we get this all the time, is when do you use Lambda and when do you use Fargate? And, I'll give a short answer here and point you to some excellent resources that AWS has there. Right? Think of think of Lambda as, as your serverless, computing when you wanna scale up concurrently, to, you know, millions of functions and then scale down to zero, seamlessly.
So sort of, you know, you you you wanna think of that massive, massive parallelism, that Lambda provides to be the key differentiator there. Whereas there's there's there's when you have a long run long container that you wanna understand, so that So hopefully, that answers that question.
Best Practices for Modernization Projects
And the second one was just best practices around modernization projects.
I think that's a very long, answer. I would say, I I would say there are many engagements. It really depends on where you're where you are in the journey. Are you lifting and shifting to the cloud? Are you refactoring? So sort of think of those six r's engaged with AWS.
We have something called an EBA, or a mod x, engagement where we actually walk through and assess which applications can be modernized, what would that modernization journey look like. But if you if you if you know you wanna use serverless containers and you wanna do it in a way which is, embedded in best practices across hundreds of hundreds of customer use cases, you could probably use Spark or the serverless platform operator to get started with common practices, to get started with CloudWatch, to know to to to have a secure solution integrate with the, with an ISP like Aqua, have built in secrets management, and, you know, use use start up use ISC, use infrastructure to support from the get go to automate your pipeline. So I saw that part of a good question, but hopefully, I answered some.
Yeah. I would also I would also add that, we are able to kind of walk you through with this, from this from a journey perspective as you transition into, into utilizing Fargate since we're already able to support, your your traditional EKS ECS environment. Right? So we have another, enforcer that is called the queue enforcer, which is actually looking at the Kubernetes and being able to give you a more holistic, insight into the entire cluster. As I mentioned, the MicroEnforcer is a Canon technology that was developed around five almost six years ago with the vision that this is going to transition to what it is today and being able to utilize the, enforcers that we have today, but also enable you to, embed or to use as a sidecar as a transition into unit utilizing Fargate, but also using it from a single point of glass. Right? So you're able to see those multiple, multiple, enforcers and being able to transition as your adoption, kind of grows.
Closing Remarks and Future Engagements
Yeah. With with that, I think time's almost up, so I want to just emphasize, some of the things. So as you can see in the screen, we can definitely meet in person, like, in New York upcoming New York summit and then Black had a meeting as well. And the other thing, I just copy and paste it into our chat as well.
So if you're not familiar with the ECS Fargate, one thing I would like to introduce is that ECS Immersion Day, you can definitely take a look what kind of anti matter component in there or how can you configure like a auto scaling observability or CICD of things in, into the ECS Fargate work road. So that's this is the first thing I would like to say. And the second thing, you know, as you saw, in this, today's demo, it is really easy to integrate spoke with the Aqua Micro Enforcer. So we already made the older Terraform stuff into our our GitHub repository.
So all you have to do is just turn out the true and then put some your information like a ECR repository information.
Other than that, there's nothing you can do there. So with that, you know, when it comes to like a container not only for container workload, but the security is a really significant thing, and then you have to check those of your vulnerabilities, in a proactive way or active active way as well. So, hopefully, yeah, you can explore, spoke with the my AQUAS microinforcer, then I will say you can definitely definitely can check a container image vulnerability as well as a containerized application vulnerability as well. So you can make your, containerized workload more like a a security, enhanced security way. So, yeah, that's all thing I would like to share. So, right, Ray, Itma, Nidhi, if you have any closing minutes, then, yeah, please talk about it.
This one, I see, it's brand new. This is our first offering. Please raise issues. We are listening, and hopefully, we can incorporate that for you so that, you know, Spark works for your use case.
And, yeah, as far as, you know, benefits of modernization, definitely happy to engage and sort of talk to you about, you know, customers' journeys from on premises to the cloud. Yeah. That's all I had. Thank you.
Conclusion and Appreciation
Wow. Today was a great session.
Thank you all for sharing your knowledge and experience with us. I'd like to take the time to thank Nidhi, Itamar, Jooyoung, and even Ray today for taking the time to join us and sharing their knowledge and experience with us. A lot of great information was shared, and it's been a pleasure having all of you.