Action: auto-tag-user requires Lambda?

[andrewegel]

So I'm trying to execute this kind of policy that "finds" users that have spun up an EC2 instance in AWS and didn't bother attaching an owner_email tag to the instance - This sort of Policy should do the trick I thought:

policies:
- name: ec2-auto-tag-user
  resource: ec2
  mode:
    type: cloudtrail
    events:
      - RunInstances
  filters:
    - tag:owner_email: absent
  actions:
    - type: auto-tag-user
      tag: owner_email
      principal_id_tag: CreatorId

But I get the exception:

AssertionError: Lambda function role must be specified

I don't want to have this type of action be performed by a Lambda function, I want the CLI to perform the tagging action. Creating a Lambda function to perform the simple tagging action feels very heavy handed. I tried this sort of Policy:

policies:
- name: ec2-auto-tag-user
  resource: ec2
  filters:
    - tag:owner_email: absent
  actions:
    - type: auto-tag-user
      tag: owner_email
      principal_id_tag: CreatorId

But I get this error:

2023-07-20 11:48:04,870: custodian.commands:ERROR invalid policy file: ... error: Auto tag owner requires an event ...

Which makes sense b/c you need a cloudtrail event to source the CreatorId value.

• Am I missing something Obvious?
• Any tips on how I can accomplish my goal without deploying a Lambda function[1]?

[1] I'm not putting down this functionality, but managing Lambda functions done at my place of work is through other frameworks (Terraform), and I'd rather not deviate from that pattern.

[andrewegel]

Something to elect is here: https://cloudcustodian.io/docs/aws/examples/tagcompliance.html the block:

policies:

- name: asg-tag-compliance-mark-new-day-0
  resource: asg
  mode:
     type: cloudtrail
     events:
        - source: autoscaling.amazonaws.com
          event: CreateAutoScalingGroup
          ids: requestParameters.autoScalingGroupName
  description: |
    Marks newly launched non-compliant ASGs if missing any of the required tags
    also tags the owners.
  comments: |
    Your ASG and ASG instances do not have all the required tags on them and will be suspended
    in 24 hours if all the required tags have not been added.  If tags are not made compliant
    after 3 days your ASG and instances will be deleted.
  filters:
    - "tag:c7n_tag_compliance": absent
    - or: *tag-compliance-filters
  actions:
    - type: mark-for-op
      tag: c7n_tag_compliance
      op: suspend
      days: 1
    - type: auto-tag-user
      tag: CreatorName
      principal_id_tag: CreatorId
    - type: notify
      template: default.html
      priority_header: 1
      subject: "ASG - Missing Required Tags - [custodian {{ account }} - {{ region }}]"
      violation_desc:  |
        Your ASG and related servers are missing the required tags and is now marked
         for suspension if tags not added within 24 hours:
      action_desc: |
        "Actions Taken:  The ASG is marked to be suspended tomorrow if
        required tags don't get added to the ASG"
      to:
        - [email protected]
        - event-owner
      transport:
        type: sqs
        queue: https://sqs.us-east-1.amazonaws.com/XXXXXXXXXX/cloud-custodian-mailer
        region: us-east-1

Doesn't specify a role - trying something similar like:

policies:
- name: ec2-auto-tag-user
  resource: ec2
  mode:
    type: cloudtrail
    events:
      - source: ec2.amazonaws.com
        event: RunInstances
        ids: userIdentity.principalId
  filters:
    - tag:owner_email: absent

I get the same AssertionError: Lambda function role must be specified error - so at minimum this is a documentation bug report.

[ajkerrigan]

Thanks for opening the discussion, you're right about the example policy in the docs - we should specify a role there 👍 .

As for the larger discussion around tagging resources with creator info, there are two high-level options:

1. Run policies with the auto-tag-user action. As you've noticed here, those policies need to run in Lambda mode. They run in response to creation events, and suck information out of those creation events to tag resources. In pull mode we don't have that event context, so we don't know who the creator is.
2. Run c7n-trailcreator to retroactively tag resources in bulk based on digging through CloudTrail history.

The most common path is to set up auto-tag-user policies to catch new resources, and optionally use trailcreator for the backlog. But there's nothing stopping you from using trailcreator to target smaller periodic batches on an ongoing basis.

As for "why not just search cloudtrail from a pull mode policy?" there are a couple reasons for that:

• Searching cloudtrail can be slow and/or expensive especially in a large estate
• The credentials used to run a policy often don't have access to the necessary CloudTrail history