ESET PRIVATE Scanning Solution – Table of Contents

Prerequisites

Copy current article URL Share via email

This article (PDF) Whole documentation (PDF)

To deploy ESET PRIVATE Static Scanning Engine, you will need:

Required Skills & Access

•AWS expertise: Experience with AWS Marketplace subscriptions, IAM policies/roles, ECR image pulls, EKS (Kubernetes/eksctl/Helm) or ECS (Fargate/task definitions), YAML/JSON manifests, AWS networking (VPC/SGs/NLB), and basic CloudWatch troubleshooting.

•Active AWS Marketplace subscription: Enables ESET PRIVATE Static Scanning Engine usage, license validation (ListReceivedLicenses), and hourly metering (RegisterUsage). Required for scanner launch.

AWS Service Permissions

•Amazon ECR access: Automatically granted via Marketplace subscription; pulls ESET images (e.g., eset-cloud-scanner-hourly:1.34.0-amd64, eset-private-scanner-agent:1.13.0-amd64).

•Cluster platform: Running EKS (for example single-node t3.xlarge, OIDC-enabled) or ECS Fargate cluster. This example guide here provides complete setup.

IAM Policies and Roles

The example deployments for ECS and EKS are designed in accordance with the principle of least privilege. All AWS Identity and Access Management (IAM) roles and policies are scoped to grant only the minimum permissions required for AWS Marketplace license discovery and usage metering. Permissions are separated by service and execution context to reduce blast radius and prevent unintended access. When reviewing or deploying these components, always pay attention to which particular ECS or EKS cluster, task, or pod the policy or role is related to.

IAM Roles Overview

•EKS IRSA role for AWS Marketplace interactions from EKS workloads

•ECS task role for application‑level Marketplace access

•ECS task execution role for infrastructure‑level task startup operations

Each role serves a single, well‑defined purpose and is not reused across different execution contexts.

EKS IAM Role (IRSA – marketplace-sa)

Purpose: Provides AWS Marketplace access to a Kubernetes workload running in Amazon EKS using IAM Roles for Service Accounts (IRSA).

Attached IAM policies:

•EKSListReceivedLicenses

•AWSMarketplaceMeteringRegisterUsage

Permissions rationale:

•EKSListReceivedLicenses - allows read only access to retrieve AWS Marketplace licenses associated with the account.

•AWSMarketplaceMeteringRegisterUsage - allows reporting of application usage in accordance with AWS Marketplace metering requirements.

Least privilege controls:

•The role is assumable only via IRSA using an EKS OIDC identity provider.

•The trust policy restricts access to:

oA single EKS cluster

oA specific Kubernetes namespace

oA specific Kubernetes service account

•No permissions are granted beyond Marketplace license discovery and metering.

•The role does not allow creation, modification, or deletion of AWS resources.

ECS Application Task Role (ecs-scanner-task-role)

Purpose: Used by the ECS application container at runtime to access AWS Marketplace APIs.

Attached IAM policies:

•ECSListReceivedLicenses

•AWSMarketplaceMeteringRegisterUsage

Permissions rationale:

•Enables the ECS workload to:

oRetrieve Marketplace license information

oReport usage for metering and billing

Least privilege controls:

•The role is assigned only as a task role, not as an execution role.

•Permissions are limited exclusively to AWS Marketplace APIs.

•The role does not provide access to:

oECS cluster or service management

oNetworking, storage, or IAM configuration

•The role is scoped to the specific ECS task definition or service using it.

ECS Task Execution Role (ecs-scanner-execution-role)

Purpose: Used by Amazon ECS during task startup to perform infrastructure level operations.

Attached IAM policy:

•AmazonECSTaskExecutionRolePolicy

Permissions rationale:

•Pulling container images from Amazon ECR

•Writing container logs to Amazon CloudWatch Logs

•Retrieving secrets from AWS Secrets Manager or SSM Parameter Store (if configured)

Least privilege controls:

•This role is separate from the application task role.

•No Marketplace, licensing, or metering permissions are attached.

•Access to secrets is limited to explicitly referenced resources.

•The role is not used by application code at runtime.

User\System Credentials

The Scanner solution does not rely on programmatic system credentials (such as IAM access keys, service account tokens, or API secrets) or cryptographic keys for its operation.

This design eliminates the need for credential rotation processes, key management systems, or periodic secret renewal workflows that are common in other deployments. As a result, credential rotation is not applicable to this solution.

Customers benefit from a simplified security posture with fewer rotating components to monitor and audit.

Network and Connectivity

•ESET Update Servers: Outbound HTTPS to *.eset.com (TCP 443) for malware signature/engine updates. Without connectivity, detection fails. [ESET KB332]

•VPC throughput: Sufficient bandwidth for file transfers between Scanner Agent and Scanner(s) over gRPC (TCP 50051/50053).

•ECS-specific: Public subnets + Security Group allowing inbound TCP/50051 (0.0.0.0/0 for NLB testing) + public IP assignment.

AWS Root User. Customers must NOT use the AWS root user for any setup, configuration, or operational tasks described in this guide.

Always use IAM users or roles with least-privilege permissions. Using the root user poses significant security risks and is not supported for production or operational use.

The ESET Private Scanning Solution supports AWS Instance Metadata Service Version 2 (IMDSv2).

IMDSv1 is not required for the operation of the solution.

When deployed on Amazon ECS or Amazon EKS, the solution uses ECS task roles or IAM Roles for Service Accounts (IRSA) to obtain temporary AWS credentials and does not rely on direct access to the EC2 Instance Metadata Service. Customers may enforce IMDSv2‑only configuration on their infrastructure without impacting functionality.

˄˅