ECS on Fargate
The Sysdig serverless orchestrator agent is installed on each virtual private cloud (VPC) and collects data from the workload agent(s). It sends the collected data to the Sysdig backend and syncs the Falco runtime policies and rules from the backend to the workload agent(s).
The Sysdig serverless workload agent is installed in each task and requires network access to communicate with the orchestrator agent. It monitors the serverless workload and enforces the Falco policies and rules to detect and prevent security threats and compliance violations.
By default, the workload agent prioritizes availability over security to ensure the workload can start even if policies are not in place. However, users can change this setting by configuring their workload starting policy to prioritize security over availability.
The Sysdig Secure ECS Fargate agent allows users to ensure the security and compliance of their serverless workloads on AWS Fargate on ECS, reducing the risk of security incidents and compliance violations.
Installation Requirements for ECS on Fargate
Before starting the installation, ensure that you have the following:
- A custom Terraform/CloudFormation template containing the Fargate task definitions that you want to instrument through the Sysdig Serverless Agent
- Two VPC subnets in different availability zones that can connect with the internet via a NAT gateway or an internet gateway
Sysdig Secure up and running
The endpoint of the Sysdig Collector for your region
From the Sysdig Secure UI, retrieve the Access Key to install the agent and push the data to the Sysdig platform
CPU Architecture Support
Serverless Agent supports only the
aarch64 is currently unsupported.
Pulling Workload Images from Public vs Private registries
Sysdig instruments a target workload by patching its TaskDefinition to run the original workload below Sysdig instrumentation. To patch the TaskDefinition, the Sysdig instrumentation service pulls and analyzes the workload image to get the original entrypoint and the command, along with other information.
- If your workload image is hosted in a private registry: you must explicitly define the entrypoint and the command in the ContainerDefinition in the template. Otherwise, the Sysdig instrumentation might not be able to collect such information and the instrumentation might fail.
- If your workload image is hosted in a public registry: no additional operations are required.
Referencing a Parameterized Image in CloudFormation Workload Template
When instrumenting a workload over CloudFormation you must define the Image inline in your TaskDefinition.
Using a parameterized image in the TaskDefinition instead might prevent the Sysdig instrumentation from retrieving the workload image configuration. That could lead to incorrect workload instrumentation.
The example below shows a valid TaskDefinition.
Resources: TaskDefinition: Type: AWS::ECS::TaskDefinition Properties: ContainerDefinitions: - Name: !Ref MyContainerName Image: "MyContainerImage" # Inline Image
|Orchestrator 4.3.0||Orchestrator 4.2.2||Orchestrator 4.2.1||Orchestrator 4.2.0||Orchestrator 4.1.2||Orchestrator 4.1.1||Orchestrator 4.1.0||Orchestrator 4.0.0|
Was this page helpful?
Glad to hear it! Please tell us how we can improve.
Sorry to hear that. Please tell us how we can improve.