Output:

Variable (referenced in output):

Usage:

module "aws_cloudtrail" {
  source  = "lacework/cloudtrail/aws"
  version = "~> 0.1"

  use_existing_iam_role   = false
  use_existing_cloudtrail = true
  bucket_name             = aws_s3_bucket.global_cloudtrail_storage.id
  bucket_arn              = aws_s3_bucket.global_cloudtrail_storage.arn
  bucket_sse_key_arn      = aws_kms_key.cloudtrail_key.arn
}

data "aws_iam_policy_document" "lacework_kms_decrypt" {
  statement {
    effect = "Allow"
    actions = [
      "kms:Decrypt"
    ]
    resources = [aws_kms_key.cloudtrail_key.arn]
  }
}

resource "aws_iam_policy" "lacework_kms_policy" {
  name        = "lacework-kms-decryption"
  path        = "/"
  description = "Supplimental policy to allow lacework to decrypt log results"
  policy      = data.aws_iam_policy_document.lacework_kms_decrypt.json
}

resource "aws_iam_policy_attachment" "lacework_kms_attach" {
  name       = "lacework-kms-decryption"
  roles      = [module.aws_cloudtrail.iam_role_name]
  policy_arn = aws_iam_policy.lacework_kms_policy.arn
}

The block of code above returns a null value for module.aws_cloudtrail.iam_role_name. We need to attach a kms decrypt policy to allow the iam role created by this module, however the outputs of this module do not reference the resources it creates because the outputs are simply the inputs.

Terraform Plan:

Terraform will perform the following actions:

  # aws_iam_policy_attachment.lacework_kms_attach will be created
  + resource "aws_iam_policy_attachment" "lacework_kms_attach" {
      + id         = (known after apply)
      + name       = "lacework-kms-decryption"
      + policy_arn = "arn:aws:iam::123456789012:policy/lacework-kms-decryption"
      + roles      = [
          + "",
        ]
    }

Plan: 1 to add, 0 to change, 0 to destroy.

Terraform Apply:

undefinedInitializing plugins and modules...
aws_iam_policy_attachment.lacework_kms_attach: Creating...

Error: No Users, Roles, or Groups specified for IAM Policy Attachment lacework-kms-decryption

  on lacework.tf line 29, in resource "aws_iam_policy_attachment" "lacework_kms_attach":
  29: resource "aws_iam_policy_attachment" "lacework_kms_attach" {

Describe the bug

This module only supports AWS provider v4.

Expected behavior

It should also support AWS provider v5, because folks will want to start using that.

Describe the bug
This terraform module requires the aws provider to be installed in the latest 3.X version.
required_providers { aws = "~> 3.64" }
This leads to the error if a customer wants to integrate this module in a codebase using aws provider version 4.X:

Provider tree:

Steps to reproduce
Create a codebase containing the aws provider version 4.X, add this module and try to run terrform init

Expected behavior
This module should support the latest major version of the aws terraform provider.

Please complete the following information):

• Terraform Version: v1.0.11
• Module Version 1.1.0

Feature Request

Describe the Feature Request
The following policy specifies how CloudTrail should be set up. Please enforce this guidance, specifically the MultiRegion aspect within this module.

Is your feature request related to a problem? Please describe
n/a

Describe Preferred Solution
Add a property for enabling multi-region trails.

Additional Context
n/a

Feature Request

Describe the Feature Request
Bucket Policy for CloudTrail log bucket should deny HTTP requests by default.

Is your feature request related to a problem? Please describe
The ISO 27001 report that's generated by Lacework complains about Lacework's own access logs bucket allowing HTTP requests, flagging it as a vulnerability of medium severity.

Describe Preferred Solution
Add policy to access logs bucket, denying HTTP requests.

Additional Context
N/A

Feature Request

Describe the Feature Request
In order to deploy New Consolidated CloudTrail and Configuration Assessment in subaccounts, we need to create our own KMS key and use it for encryption/decryption in all accounts.
However, the create_kms_key condition doesn't support this use case

Is your feature request related to a problem? Please describe
We want to configure the cloudtrail module this way:

• use IAM resource from "lacework/config/aws" module
• use our own KMS CMK

module "aws_cloudtrail" {
  source  = "lacework/cloudtrail/aws"
  version = "~> 2.0.0"

  consolidated_trail           = true
  use_existing_iam_role        = true
  iam_role_name                = module.aws_config.iam_role_name
  iam_role_arn                 = module.aws_config.iam_role_arn
  iam_role_external_id         = module.aws_config.external_id
  external_id_length           = 1000
  prefix                       = "lacework-integration"
  bucket_name                  = "lacework-cloudtrail"
  log_bucket_name              = "lacework-cloudtrail-access-logs"
  bucket_sse_key_arn           = aws_kms_key.this.key_id
  sns_topic_name               = "lacework"
  sns_topic_encryption_key_arn = aws_kms_key.this.key_id
  sqs_queue_name               = "lacework"
  sqs_encryption_key_arn       = aws_kms_key.this.key_id
  cloudtrail_name              = "lacework"
  lacework_integration_name    = "TF cloudtrail"
  kms_key_rotation             = true
}

│ Error: Invalid count argument
│
│   on .terraform/modules/aws_cloudtrail/main.tf line 36, in resource "aws_kms_key" "lacework_kms_key":
│   36:   count                   = local.create_kms_key
│
│ The "count" value depends on resource attributes that cannot be determined until apply, so Terraform cannot predict how many instances will be created. To work around this, use the -target argument to first apply only the resources
│ that the count depends on.

Feature Request

Describe the Feature Request
Allow filtering events send through SNS

In my particular case, I want to filter from which accounts we are sending data to Lacework by creating an SNS topic with filters and an SQS queue reusing an existing S3 bucket

• We have an Organisational Cloudtrail created on each account
• The parent/root account owns the Organisational Cloudtrail
• Organisation Cloudtrail puts logs into an S3 bucket that is hosted in a different account, our security account

Is your feature request related to a problem? Please describe
At the moment we are using an integration per account but that increases our AWS cost since duplicated AWS Cloudtrail events are not free
We can't ingest all the Cloudtrail events because our contract is limited to a certain number of resources

Describe Preferred Solution
The most recent AWS provider allows setting filter_policy and filter_policy for sns_topic_subscription
https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/sns_topic_subscription#filter_policy

Additional Context

Describe the bug
With module "lacework/cloudtrail/aws" version 1.1.0 I use use_existing_access_log_bucket = true as I have a central logging bucket for S3 access logs.

After upgrading the module to 2.3.1 I get this error message from terraform during plan:

│ Error: Invalid index
│
│   on .terraform/modules/aws_cloudtrail/main.tf line 76, in resource "aws_s3_bucket_logging" "cloudtrail_bucket_logging":
│   76:   target_bucket = aws_s3_bucket.cloudtrail_log_bucket[0].id
│     ├────────────────
│     │ aws_s3_bucket.cloudtrail_log_bucket is empty tuple
│
│ The given key does not identify an element in this collection value: the collection has no elements.

Looking at line 72 to 78 in .terraform/modules/aws_cloudtrail/main.tf I see that the case use_existing_access_log_bucket = true is not handled here. The code just assumes the access logging bucket was also created within its context and therefor fails.

I locally fixed it by changing the code from

// v4 s3 bucket changes
resource "aws_s3_bucket_logging" "cloudtrail_bucket_logging" {
  count         = var.bucket_logs_enabled && !var.use_existing_cloudtrail ? 1 : 0
  bucket        = aws_s3_bucket.cloudtrail_bucket[0].id
  target_bucket = aws_s3_bucket.cloudtrail_log_bucket[0].id
  target_prefix = var.access_log_prefix
}

to

// v4 s3 bucket changes
resource "aws_s3_bucket_logging" "cloudtrail_bucket_logging" {
  count         = var.bucket_logs_enabled && !var.use_existing_cloudtrail ? 1 : 0
  bucket        = aws_s3_bucket.cloudtrail_bucket[0].id
  target_bucket = var.use_existing_access_log_bucket ? local.log_bucket_name : aws_s3_bucket.cloudtrail_log_bucket[0].id # changed line
  target_prefix = var.access_log_prefix
}

Steps to reproduce
use use_existing_access_log_bucket = true in the module aws_cloudtrail

Expected behavior
Usage of already existing S3 buckets by setting use_existing_access_log_bucket = true should work.

Please complete the following information):
Terraform v1.3.5
on linux_amd64

• provider registry.terraform.io/hashicorp/archive v2.2.0
• provider registry.terraform.io/hashicorp/aws v4.41.0
• provider registry.terraform.io/hashicorp/random v3.4.3
• provider registry.terraform.io/hashicorp/template v2.2.0
• provider registry.terraform.io/hashicorp/time v0.9.1
• provider registry.terraform.io/lacework/lacework v1.1.0

Additional context
Add any other context about the problem here.

Feature Request

Describe the Feature Request
The CloudTrail created by this Terraform module should support setting up a proper logging integration with CloudWatch.

Is your feature request related to a problem? Please describe
The created CloudTrail is non-compliant with CIS Benchmarks and is listed as a Medium severity in Lacework's generated reports for compliance with AWS ISO 27001:2013 and AWS ISO/IEC 27002:2022.

The non-compliance in question is lacework-global-55.

Describe Preferred Solution
The module creates resources that by default are compliant with CIS Benchmarks.

Add input variables cloudwatch_logs_encryption_enabled, cloudwatch_logs_encryption_key_arn, and cloudwatch_logs_iam_role_arn, and set them in the aws_cloudtrail resource. If no IAM role ARN is provided then one should be created by the module.

Additional Context
I think the changes needed are the following:

variables.tf:

variable "cloudwatch_logs_encryption_enabled" {
  type    = bool
  default = true
}

variable "cloudwatch_logs_encryption_key_arn" {
  type    = string
  default = ""
}

variable "cloudwatch_logs_iam_role_arn" {
  type    = string
  default = ""
}

main.tf:

locals {
  ...
  create_cloudwatch_iam_role = var.cloudwatch_logs_encryption_enabled && var.cloudwatch_logs_iam_role_arn == null
  
  cloudwatch_key_arn = var.cloudwatch_logs_encryption_enabled ? (length(var.cloudwatch_logs_encryption_key_arn) > 0 ? var.cloudwatch_logs_encryption_key_arn : aws_kms_key.lacework_kms_key[0].arn) : ""

  cloudwatch_logstream_arn = "${aws_cloudwatch_log_group.cloudtrail_log_group.arn}:log-stream:${data.aws_caller_identity.current.account_id}_CloudTrail_${data.aws_region.current.name}*" # Reference: https://docs.aws.amazon.com/awscloudtrail/latest/userguide/send-cloudtrail-events-to-cloudwatch-logs.html
}

data "aws_iam_policy_document" "kms_key_policy" {
  ...

  dynamic "statement" {
    for_each = (var.cloudwatch_logs_encryption_enabled && length(var.cloudwatch_logs_encryption_key_arn) == 0) ? [1] : []
    content {
      sid    = "Allow CloudWatch service to encrypt/decrypt"
      effect = "Allow"

      actions = [
        "kms:Encrypt*",
        "kms:Decrypt*",
        "kms:ReEncrypt*",
        "kms:GenerateDataKey*",
        "kms:Describe*"
      ]

      resources = ["*"]
      
      principals {
        type = "Service"
        identifiers = [
          "logs.${data.aws_region.current.name}.amazonaws.com",
        ]
      }

      condition {
        test     = "ArnEquals"
        variable = "kms:EncryptionContext:aws:logs:arn"
        values = [
          "arn:aws:logs:${data.aws_region.current.name}:${data.aws_caller_identity.current.account_id}:log-group:${var.cloudtrail_name}",
        ]
      }
    }
  }
}

resource "aws_cloudwatch_log_group" "cloudtrail_log_group" {
  name              = var.cloudtrail_name
  kms_key_id        = local.cloudwatch_key_arn
  retention_in_days = 90
}

data "aws_iam_policy_document" "cloudtrail_assume_role" {
  count = local.create_cloudwatch_iam_role ? 1 : 0
  
  statement {
    effect = "Allow"

    actions = [
      "sts:AssumeRole",
    ]

    principals {
      type = "Service"
      identifiers = [
        "cloudtrail.amazonaws.com"
      ]
    }
  }
}


data "aws_iam_policy_document" "cloudtrail_logging" {
  count = local.create_cloudwatch_iam_role ? 1 : 0

  statement {
    sid    = "AWSCloudTrailCreateLogStream"
    effect = "Allow"

    actions = [
      "logs:CreateLogStream",
    ]

    resources = [
      local.cloudwatch_logstream_resource,
    ]
  }

  statement {
    sid    = "AWSCloudTrailPutLogEvents"
    effect = "Allow"

    actions = [
      "logs:PutLogEvents",
    ]

    resources = [
      local.cloudwatch_logstream_resource,
    ]
  }
}

resource "aws_iam_policy" "cloudtrail_logging" {
  count = local.create_cloudwatch_iam_role ? 1 : 0
  
  name        = var.cloudtrail_name
  policy      = data.aws_iam_policy_document.cloudtrail_logging[count.index].json
  description = "Allows CloudTrail to create log streams and to put logs in CloudWatch"
}

resource "aws_iam_role" "cloudtrail_logging" {
  count = local.create_cloudwatch_iam_role ? 1 : 0

  name               = var.cloudtrail_name
  assume_role_policy = data.aws_iam_policy_document.cloudtrail_assume_role[count.index].json
}

resource "aws_iam_role_policy_attachment" "cloudtrail_logging" {
  count = local.create_cloudwatch_iam_role ? 1 : 0

  role       = aws_iam_role.cloudtrail_logging[count.index].name
  policy_arn = aws_iam_policy.cloudtrail_logging[count.index].arn
}

resource "aws_cloudtrail" "lacework_cloudtrail" {
  ...
  enable_logging             = true
  cloud_watch_logs_group_arn = "${aws_cloudwatch_log_group.cloudtrail_log_group.arn}:*"
  cloud_watch_logs_role_arn  = local.create_cloudwatch_iam_role ? coalesce(var.cloudwatch_logs_iam_role_arn, aws_iam_role.cloudtrail_logging.arn) : null
  enable_log_file_validation = var.enable_log_file_validation
  ...
}

Please note that this code has not been properly tested. I've simply adjusted Terraform configurations that I've found elsewhere.

Thanks!

Feature Request

Describe the Feature Request
A user should be able to know the minimum version of the AWS provider that they need to be able to run any given version of this module.

Describe Preferred Solution
Use the required_providers block to set a minimum AWS provider version constraint.

For example, I notice that the multi_region attribute in the KMS key being created here requires version 3.64.0 or higher. It would be a better user experience if Terraform could call out this version constraint specifically, rather than letting a plan/apply fail when the constraint isn't met, as seen below.

Additional Context

$ terraform version
Terraform v0.14.11
+ provider registry.terraform.io/hashicorp/aws v3.57.0

$ terraform plan
Releasing state lock. This may take a few moments...

Error: Unsupported argument

  on .terraform/modules/some_module.lacework_aws_cloudtrail/main.tf line 40, in resource "aws_kms_key" "lacework_kms_key":
  40:   multi_region            = var.kms_key_multi_region

An argument named "multi_region" is not expected here.

Feature Request

Describe the Feature Request
Some folks have already created large buckets that capture many accounts of cloudtrail activity. Allowing that bucket to send notifications to sqs would be more efficient for those end users.

Describe Preferred Solution
A lambda can easily rewrite s3 notifications into a cloudtrail event.

Customers might want to pass tags to the S3 bucket we create,
we should add an input to allow them to do that.

Describe the bug
AWS just recently sent out this mass email to anyone with an affected bucket policy, which would include a lot of users of this module.

Steps to reproduce

Umm, just look at the bucket policy and see if it matches the pattern described in AWS's email, I guess?

Expected behavior

This module should follow AWS's suggestion, most likely by using what they refer to as Recommended alternative 1:

    principals {
      type        = "AWS"
      identifiers = ["*"]
    }

Also in the section where they talk about bucket-lockout, they mention:

we recommend as a best practice that you avoid using Deny statements that cover all S3 actions (s3:* ) on the bucket resource (arn:aws:s3:::example-bucket).

This module may also want to follow that suggestion by removing "arn:aws:s3:::${local.log_bucket_name}" from the resources in the bucket policy, and having it only apply to "arn:aws:s3:::${local.log_bucket_name}/*".

Please complete the following information):

• Terraform Version: Terraform v1.5.6
• Module Version 2.7.6

CloudTrail provides a configuration for enabling log file validation.

The Hashicorp Terraform Module resource supports this setting:

https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/cloudtrail#enable_log_file_validation

There is no input for enabling validation on the trail via the Lacework module:

https://registry.terraform.io/modules/lacework/cloudtrail/aws/latest?tab=inputs

@afiune Sorry for the late inspection on this, I had typed it up in a review of lacework/terraform-aws-ecr#1 and didn't get it submitted in time.

This module currently appears to have dependency conflicts if used in conjunction with our CloudTrail module - we'll need to also allow the use of the 0.3.x Lacework provider for the CloudTrail module, or users will get the following on a terraform init:

Error: Failed to query available provider packages

Could not retrieve the list of available versions for provider
lacework/lacework: no available releases match the given constraints ~> 0.2.0,
~> 0.2, ~> 0.3

This appears to be caused by the the Lacework provider version being limited to version = "~> 0.2.0" (

Feature Request

Adding the possibility to create a trail for an organization:

• adding the is_organization_trail argument to the resource "aws_cloudtrail" "lacework_cloudtrail"

Feature Request

Describe the Feature Request

When bucket_logs_enabled is enabled, a logging bucket will be created and access logs from the cloudtrail bucket will be delivered to the logging bucket.

But those access logs in the logging bucket will persist forever without ever expiring. It would be nice to give the user a configurable way to expire those logs, such as a logging_bucket_lifecycle_expiration_in_days variable. If this variable is set by the user, then a lifecycle configuration could be created to expire old logs from the logging bucket after N days.

Describe the bug
We have reconfigured our Cloudtrail integration to use terraform since we have also added two new AWS accounts and our old integration was done manually.
I followed instructions here:
There is this section:

If you do not have an existing SNS topic configured on the existing CloudTrail, the Terraform module automatically creates one, but you must manually attach the SNS topic to the existing CloudTrail.

After doing the manual attachment, if I run the terraform apply again it will remove the manual attachment:

Terraform will perform the following actions:

  # module.altoira_cloudtrail[0].aws_sns_topic_policy.default[0] will be updated in-place
  ~ resource "aws_sns_topic_policy" "default" {
        id     = "arn:aws:sns:us-east-1:<redacted>:lacework-ct-sns-de98b010"
      ~ policy = jsonencode(
          ~ {
              ~ Statement = [
                    {
                        Action    = "SNS:Publish"
                        Effect    = "Allow"
                        Principal = {
                            Service = "cloudtrail.amazonaws.com"
                        }
                        Resource  = "arn:aws:sns:us-east-1:<redacted>:lacework-ct-sns-de98b010"
                        Sid       = "AWSCloudTrailSNSPolicy20131101"
                    },
                  - {
                      - Action    = "SNS:Publish"
                      - Condition = {
                          - StringEquals = {
                              - "AWS:SourceArn" = "arn:aws:cloudtrail:us-east-1:<redacted>:trail/management-events"
                            }
                        }
                      - Effect    = "Allow"
                      - Principal = {
                          - Service = "cloudtrail.amazonaws.com"
                        }
                      - Resource  = "arn:aws:sns:us-east-1:<redacted>:lacework-ct-sns-de98b010"
                      - Sid       = "AWSCloudTrailSNSPolicy20150319"
                    },
                ]
                # (1 unchanged element hidden)
            }
        )
        # (2 unchanged attributes hidden)
    }

Plan: 0 to add, 1 to change, 0 to destroy.

This doesn’t seem like a workable solution since terraform should be run against an environment on an ongoing basis. Can you provide a solution?
Thanks
Steps to reproduce
Outlined in description

Expected behavior
After doing the manual attachment it should be ok to run the terraform configuration again without deleting attachment configuration

Please complete the following information):

» tf version                                                                                                            altoira-nonprod
Terraform v1.3.8
on darwin_arm64
+ provider registry.terraform.io/hashicorp/aws v4.54.0
+ provider registry.terraform.io/hashicorp/random v3.4.3
+ provider registry.terraform.io/hashicorp/time v0.9.1
+ provider registry.terraform.io/lacework/lacework v1.4.0

That's a kind of "latest" pin

In case, if something will be broken in version 0.9999 - all module versions from the time when version = "~> 0.3" was introduced will become broken without any changes to the code.

Which is a little bit violating https://reproducible-builds.org/ (a little bit, because the main reason this site is not about infra at all)

Regarding TF best practices:

For modules maintained within your organization, specifying version ranges may be appropriate if semantic versioning is used consistently or if there is a well-defined release process that avoids unwanted updates.

it +- okay, because you manage both modules, and if you have cross-module change testing CI somewhere.

But if not - better not to have such floating stuff for modules. And update versions when you need or, automate these updates by Renovate/dependabot. For example, here is a quick start solution - https://github.com/SpotOnInc/renovate-config/.

fdfsa

Feature Request

I am already making a change for this. The PR will be up shortly

Description

We use one central bucket for access logging on S3 which we would like to incorporate into Lacework. Unfortunately to do this currently would mean creating our own cloudtrail and bucket which can then tie into the existing access log bucket. As an alternative it seems pretty simple to add an option to use an existing logging bucket and control the logging prefix.

Solution

Adding a use_existing_access_log_bucket flag which will prevent the default access logs bucket from being created.
Adding a access_log_prefix to control logging prefix in said log bucket.

Default logging bucket should only be created if use_existing_cloudtrail and use_existing_access_log_bucket are both false and if bucket_enable_logs is set to true.

To control the selection of the existing log bucket the already created log_bucket_name variable will be used. The access_log_prefix will be defaulted to "logs/" but can be changed.