Having recently completed a comprehensive cloud security posture management (CSPM) and cloud workload protection platform (CWPP) evaluation for our multi-cloud environment, I found Lacework's unified data collection and threat detection model to be architecturally compelling. However, the operational overhead of deploying and maintaining the Lacework agent across dozens of AWS accounts, each with varying provisioning methodologies, presented a significant barrier to a full-scale rollout.
To address this, I've developed a reusable Terraform module designed to automate the deployment of Lacework's agent containers via AWS Systems Manager (SSM) Run Command. The primary design goals were idempotency, minimal service-principal permissions, and compatibility with both organizational-level deployment accounts and individual application accounts. The module abstracts the following core components:
* An SSM State Manager association that creates a scheduled, recurring document (`AWS-QuickSetup`-based) to ensure the Lacework Datacollector container runs on all managed instances.
* A scoped IAM policy for the SSM execution role, granting only the necessary permissions for ECS task execution and secret retrieval (for the agent access token).
* Secure storage of the Lacework agent token in AWS Secrets Manager, with automatic KMS encryption and IAM policy attachment limiting access to the SSM service principal.
* Configurable parameters for agent polling intervals, proxy settings (via environment variables), and resource tagging.
```hcl
module "lacework_agent_ssm" {
source = "github.com/our-org/terraform-aws-lacework-ssm"
lacework_account = "my-company"
lacework_access_token = var.lacework_access_token_secret
ssm_association_name = "lacework-datacollector"
schedule_expression = "rate(1 day)" # Ensures association is reapplied daily
proxy_host = var.proxy_host # Optional, for egress-controlled environments
proxy_port = var.proxy_port
}
# The module internally handles the Secrets Manager secret and the SSM association.
```
Initial deployment across a test bed of 12 accounts (approximately 430 EC2 instances) completed without manual intervention. The SSM association success rate currently sits at 98.7%; the failures correlate with instances that were in a terminated or severely degraded state at the time of association, which is expected. The Lacework console began showing data ingestion from new hosts within the expected 15-minute polling window.
Several observations and potential pitfalls emerged during the module's development and testing:
* **Secret Rotation:** The current design assumes a static agent token. Integrating with a token rotation lifecycle, perhaps via Lacework's API, would require a more complex lambda-backed rotation function. This is a noted limitation.
* **Mixed-Architecture Fleets:** The SSM document uses the `ECS_AWSVPC_BLOCK_DEVICE_MAPPING` setting. For instances with multiple network interfaces or non-standard ECS configurations, the module may require an additional `ssm_association_parameters` override variable for advanced use cases.
* **Cost Monitoring:** The recurring SSM association incurs a minor AWS SSM cost. More significantly, the volume of data Lacework ingests per agent can vary widely. It is crucial to pair this deployment with a budget alert on the Lacework side, as their pricing is consumption-based.
* **Orchestrator Conflicts:** In environments already using ECS or Kubernetes for daemon sets, a direct container deployment via those orchestrators might be more efficient. This SSM approach is primarily targeted for bare EC2 or mixed workloads where a container orchestrator is not universally present.
I am interested in discussing alternative deployment patterns, particularly for Azure and GCP, which were out of scope for this iteration. Has anyone implemented a similar infrastructure-as-code approach using ARM templates or Google Deployment Manager? Furthermore, I am analyzing the performance impact of the agent's `syscall` instrumentation; preliminary benchmarks show a 1-3% increase in syscall latency on a subset of our data-processing nodes, which is within tolerance but warrants monitoring.
Oh, this is a great idea. We're looking at Lacework too, and the agent deployment across accounts was one of my big worries.
When you mention idempotency and minimal permissions, how did you handle that in practice? Did you find the SSM Run Command approach needed any special tweaks to avoid re-running the install on instances that were already healthy, or is that managed by the association itself? Just thinking about cost control from unnecessary API calls.
Also, curious about the IAM policy scope. Does your module assume a centralized deployment account, or can it be run from within each spoke account? Trying to picture how it fits with our AWS Landing Zone setup.
The SSM association state handles idempotency, but it's not free. Each state evaluation triggers a DescribeInstanceInformation API call. At scale across hundreds of instances, that's a recurring cost.
For IAM, your Landing Zone dictates the pattern. A centralized deployment account needs cross-account AssumeRole permissions on the spoke accounts. Running it locally in each spoke is simpler for IAM but multiplies your Terraform state management overhead.
You should also lock down the SSM document permissions. The default managed policy is overly permissive.
cost per transaction is the only metric
You've hit on the exact friction point that often derails these security platform rollouts. Architecturally compelling, operationally heavy. The approach of using SSM State Manager for a scheduled `AWS-QuickSetup` document is solid for ensuring the container's runtime state, but it does create a tight coupling to AWS for an agent that's meant to be multi-cloud.
I'm particularly interested in how you've scoped the IAM policy for ECS task execution. Many vendor-supplied policies are overly broad for pulling their container image. Did you find you needed to grant permissions for the specific ECR repository, or were you able to restrict it further to a curated private repository copy? I've seen the initial pull permissions become a persistent, overly permissive artifact.
One caveat with the recurring document association: if the goal is truly minimal permissions, remember that the SSM agent itself on the instance needs network egress to Lacework's endpoints. That often necessitates VPC endpoint or proxy configurations that fall outside the module's scope, potentially leaving a gap in deployment success.
That's a really smart approach using the SSM State Manager. I went down a similar path, but I used the `AWS-ConfigureAWSPackage` document for the Lacework agent instead of `AWS-QuickSetup`. Found it gave a bit more granular control over the version pinning.
You're absolutely right about the IAM policy scope for ECS. The module I built references a specific, versioned image URI in the ECR policy. It avoids wildcards like `*` on repository names. But you've got me thinking: even that ties you to their public repo. A curated private copy is a great next step for locking it down, adds that extra layer of control over what's actually pulled into your environment.
How did you handle the agent configuration parameters? I ended up stuffing those into the SSM document as parameters, but it felt a bit clunky.
Automate all the things.