EKS on Fargate (CA)https://docs.sysdig.com/en/sysdig-secure/serverless-eks-fargate/Recent content on EKS on Fargate (CA)enThu, 12 Nov 2026 13:21:05 +0000 https://docs.sysdig.com/icons/sysdig-horizontal.pngEKS on Fargate (CA)https://docs.sysdig.com/en/sysdig-secure/serverless-eks-fargate/Sysdig logoEKS on Fargate (CA) - Prerequisiteshttps://docs.sysdig.com/en/sysdig-secure/serverless-eks-fargate/#prerequisitesRefer to the following prerequisites for both Sysdig and EKS on Fargate.Refer to the following prerequisites for both Sysdig and EKS on Fargate.

Sysdig

EKS on Fargate

  • An EKS cluster with a Fargate profile whose selector matches the namespace of the workload you want to secure.
  • Private subnets with outbound network access to the Sysdig Collector on port 6443.

ptrace dependency

Runtime detection and policy enforcement depend on ptrace, which the Workload Agent uses to instrument your workloads. EKS on Fargate currently allows it within a pod, but AWS does not document this behavior. Fargate also does not currently support adding the CAP_SYS_PTRACE capability. Any limitation the underlying infrastructure applies, such as removing or restricting ptrace, could affect serverless features, including the agent’s ability to instrument your workloads.

x86_64 architecture

Use the x86_64 image of the serverless agent, as EKS Fargate supports only that architecture. The serverless agent image is published as a manifest list containing both aarch64 and x86_64 variants.

Fargate profile order

Create the Fargate profile before deploying the workload.

]]>PrerequisitesEKS on Fargate (CA) - Deploy the Serverless Workload Agenthttps://docs.sysdig.com/en/sysdig-secure/serverless-eks-fargate/#deploy-the-serverless-workload-agentThe Serverless Workload Agent consists of two primary components:The Serverless Workload Agent consists of two primary components:

  • Instrumentation: Monitors the workload application and always runs in the same container as the application it monitors.
  • Agent: Analyzes the syscall data collected by the Instrumentation, performs policy matching, and communicates with the Sysdig collector.

The Agent can be deployed in one of two configurations:

  • Sidecar container (recommended): The Agent runs in its own container, so you can configure its CPU and memory independently of the workload containers. This setup requires a shared process namespace, a shared volume, and an additional container in the pod to run the agent.
  • Embedded (not recommended): The Agent runs in the same container as the workload and shares its CPU and memory. This results in a higher resource and network footprint. This setup requires additional environment variables and volume mount in each workload container.

To deploy the Workload Agent on EKS on Fargate:

  1. Instrument the workload image.
  2. Create the Sysdig Secret.
  3. Grant the workload read access to its pod.
  4. Deploy the workload using the recommended Sidecar Deployment, or Embedded Deployment as an alternative.

Instrument the Workload Image

Regardless of the deployment strategy you choose, first add the Serverless Workload Agent to your workload image.

Copy the Workload Agent into the image under /opt/draios, using a separate layer. Then prepend /opt/draios/bin/instrument to your existing ENTRYPOINT, and keep CMD as it is.

FROM quay.io/sysdig/workload-agent:latest AS workload-agent

# Your final layer
FROM ...
...
COPY --from=workload-agent /opt/draios /opt/draios

ENTRYPOINT[<original_entrypoint>]
ENTRYPOINT["/opt/draios/bin/instrument", <original_entrypoint>]
CMD["<original_cmd>"]

Create the Sysdig Secret

Save the Agent Access Key as a Kubernetes Secret in the namespace where your workload runs.

  1. Create a file called sysdig.env and add the following line, replacing the placeholder with your key:
SYSDIG_ACCESS_KEY=<ACCESS_KEY>

Reading the key from a file, rather than passing it on the command line, prevents it from appearing in the process list.

  1. Generate the Secret from that file:
kubectl create secret generic sysdig-agent -n <NAMESPACE> --from-env-file=sysdig.env

Grant Read Access to the Pod

The pod’s ServiceAccount needs the following permissions in the workload namespace. The Workload Agent uses the pod’s service account token to read its own pod from the Kubernetes API, which lets it identify the workload and enrich security events.

All these permissions are optional. Without them, the agent keeps running, but event enrichment is limited or unavailable, and policy scope matching results less accurate.

Resource Verb Purpose
pods get Pod identification and secure events enrichment
replicasets (apps) get Adds kubernetes.deployment.name
services list Adds kubernetes.service.name

Apply the following manifest to deploy the permissions:

apiVersion: v1
kind: ServiceAccount
metadata:
  name: my-app
  namespace: <NAMESPACE>
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: sysdig-pod-read
  namespace: <NAMESPACE>
rules:
  - apiGroups: [""]
    resources: ["pods"]
    verbs: ["get"]
  - apiGroups: ["apps"]
    resources: ["replicasets"]
    verbs: ["get"]
  - apiGroups: [""]
    resources: ["services"]
    verbs: ["list"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: sysdig-pod-read
  namespace: <NAMESPACE>
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: sysdig-pod-read
subjects:
  - kind: ServiceAccount
    name: my-app
    namespace: <NAMESPACE>

Deploy the workload

Sidecar Deployment

To deploy the instrumented workload and the sidecar Workload Agent, modify your pod as follows:

  • Pod spec
    • Set shareProcessNamespace: true
    • Set serviceAccountName to the ServiceAccount you granted read access to
    • Add an emptyDir shared volume named sysdig-run
  • Instrumented workload containers
    • Mount sysdig-run at /opt/draios/run
    • Set the environment variable SYSDIG_SIDECAR: auto
  • Sidecar container
    • Set image: quay.io/sysdig/workload-agent:latest
    • Mount sysdig-run at /opt/draios/run
    • Set envFrom to provide the Secret Access Key
    • Set the environment variables:
      • SYSDIG_SIDECAR: auto
      • SYSDIG_COLLECTOR: <host>
      • SYSDIG_PORT: 6443
      • SYSDIG_EXTRA_CONF: "k8s_cluster_name: <cluster_name>\nk8s_account_id: \"<account_id>\""
apiVersion: apps/v1
kind: Deployment
metadata:
 name: my-app
 ...
spec:
 selector:
   matchLabels:
     app: my-app
 template:
   ...
   spec:
      # PID namespace sharing
      shareProcessNamespace: true
      # Read permissions
      serviceAccountName: my-app
      # Shared Volume
      volumes:
        - name: sysdig-run
          emptyDir: {}
     ...
     containers:
       # Instrumented workload container
       - name: app
         ...
         image: <INSTRUMENTED_APP_IMAGE>
         env:
           - name: SYSDIG_SIDECAR
             value: auto
         volumeMounts:
           - name: sysdig-run
             mountPath: /opt/draios/run

        # Sidecar workload agent
        - name: agent
          image: quay.io/sysdig/workload-agent:latest
          envFrom:
            - secretRef:
              name: sysdig-agent
          env:
            - name: SYSDIG_SIDECAR
              value: auto
            - name: SYSDIG_COLLECTOR
              value: <host>
            - name: SYSDIG_COLLECTOR_PORT
              value: 6443
            - name: SYSDIG_EXTRA_CONF
              value: "k8s_cluster_name: <cluster_name>\nk8s_account_id: \"<account_id>\""
          volumeMounts:
            - name: sysdig-run
              mountPath: /opt/draios/run

Embedded Deployment

After instrumenting your workload image, deploy it like the original, with these additions:

  • Pod spec
    • Set serviceAccountName with the ServiceAccount you granted read access to
    • Add a distinct emptyDir volume for each instrumented workload container
  • Instrumented workload containers
    • Mount the emptyDir container-specific volume at /opt/draios/run
    • Set envFrom to provide the Secret Access Key
    • Set the environment variables:
      • SYSDIG_SIDECAR: auto
      • SYSDIG_COLLECTOR: <host>
      • SYSDIG_PORT: 6443
      • SYSDIG_EXTRA_CONF: "k8s_cluster_name: <cluster_name>\nk8s_account_id: <account_id>"
apiVersion: apps/v1
kind: Deployment
metadata:
 name: my-app
 ...
spec:
 selector:
   matchLabels:
     app: my-app
 template:
   ...
   spec:
      # Read permissions
      serviceAccountName: my-app
      # One volume per instrumented container
      volumes:
        - name: sysdig-run-1
          emptyDir: {}
        - name: sysdig-run-2
          emptyDir: {}
     ...
     containers:
       # Instrumented workload container 1
       - name: app-1
         ...
         image: <INSTRUMENTED_APP_1_IMAGE>
          envFrom:
            - secretRef:
                name: sysdig-agent
          env:
            - name: SYSDIG_SIDECAR
              value: auto
            - name: SYSDIG_COLLECTOR
              value: <host>
            - name: SYSDIG_COLLECTOR_PORT
              value: 6443
            - name: SYSDIG_EXTRA_CONF
              value: "k8s_cluster_name: <cluster_name>\nk8s_account_id: \"<account_id>\""
          volumeMounts:
            - name: sysdig-run-1
              mountPath: /opt/draios/run

      # Instrumented workload container 2
       - name: app-2
         ...
         image: <INSTRUMENTED_APP_2_IMAGE>
          envFrom:
            - secretRef:
                name: sysdig-agent
          env:
            - name: SYSDIG_SIDECAR
              value: auto
            - name: SYSDIG_COLLECTOR
              value: <host>
            - name: SYSDIG_COLLECTOR_PORT
              value: 6443
            - name: SYSDIG_EXTRA_CONF
              value: "k8s_cluster_name: <cluster_name>\nk8s_account_id: \"<account_id>\""
          volumeMounts:
            - name: sysdig-run-2
              mountPath: /opt/draios/run
]]>Deploy the Serverless Workload AgentEKS on Fargate (CA) - Verify the Deploymenthttps://docs.sysdig.com/en/sysdig-secure/serverless-eks-fargate/#verify-the-deploymentOnce deployed, the Workload Agent appears under Secure &gt; Integration &gt; Sysdig Agents. When triggered, security events appear under Secure &gt; Detection &amp; Response &gt; All Events. Assuming the RBAC permissions are in place, they are labeled with Kubernetes metadata specific to the region, account, cluster, pod, and container.
  • Once deployed, the Workload Agent appears under Secure > Integration > Sysdig Agents.
  • When triggered, security events appear under Secure > Detection & Response > All Events. Assuming the RBAC permissions are in place, they are labeled with Kubernetes metadata specific to the region, account, cluster, pod, and container.
    • ]]>    Verify the Deployment    EKS on Fargate (CA) - Known Limitationshttps://docs.sysdig.com/en/sysdig-secure/serverless-eks-fargate/#known-limitationsPod detection: The pod is identified by its hostname, so a pod that sets spec.hostname could not be detected. CronJobs: A CronJob’s pod reports its Job as the workload. Missing metadata: container.label.io.kubernetes.* and aws.instanceId are not available. Policy actions: stop/pause/kill container policy actions are disabled
  • Pod detection: The pod is identified by its hostname, so a pod that sets spec.hostname could not be detected.
  • CronJobs: A CronJob’s pod reports its Job as the workload.
  • Missing metadata: container.label.io.kubernetes.* and aws.instanceId are not available.
  • Policy actions: stop/pause/kill container policy actions are disabled
    • ]]>    Known Limitations    EKS on Fargate (CA) - Next Stepshttps://docs.sysdig.com/en/sysdig-secure/serverless-eks-fargate/#next-stepsReview the events in the Sysdig Secure Events feed. Configure the agent. See Configuration.
  • Review the events in the Sysdig Secure Events feed.
  • Configure the agent. See Configuration.
    • ]]>    Next Steps