Add CloudFormation IAM Activity Alerts example

[ssilare-adobe]

Overview

This PR adds a production-ready CloudFormation template example for monitoring IAM user creation activities across AWS accounts.

What's Included

• CloudFormation Template: EventBridge rule, SNS topic, and Lambda function for IAM monitoring
• Interactive Deployment Script: Guided setup with validation
• Comprehensive Documentation: Setup instructions, Slack webhook configuration, troubleshooting
• Example Files: Parameters file and deployment guide

Features

• Real-time alerts for IAM events (CreateUser, CreateAccessKey, CreateLoginProfile)
• Flexible notifications (Email via SNS and/or Slack via Lambda)
• Customizable user exclusions for service accounts
• Parameterized for easy sharing across AWS accounts

Files Added

• docs/examples/cloudformation-iam-alerts.md - Main example documentation
• docs/examples/cloudformation-iam-alerts/ - Template, scripts, and detailed documentation
• Updated navigation in README.md, docs/index.md, and mkdocs.yml

AI-First Context

This example demonstrates:

• Spec-driven infrastructure automation
• Template reusability across teams
• Documentation-first approach
• Production-quality with minimal manual intervention

Cost

Expected cost: < $1/month for typical usage (EventBridge + Lambda/SNS free tier eligible)

Security

• Webhook URLs protected with NoEcho
• Minimal IAM permissions
• No credentials stored or transmitted

---

This example provides teams with a ready-to-deploy solution for IAM monitoring that can be easily customized and shared across AWS accounts.

[solaris007]

Hey @ssilare-adobe, thanks for putting this together - useful to have a ready-to-deploy IAM monitoring example. A few things to address:

Security issues in the deployment script:

deploy.sh uses eval to execute the CloudFormation command (line ~188):

eval aws cloudformation $OPERATION \
    --stack-name "$STACK_NAME" \
    --template-body file://"$TEMPLATE_FILE" \
    --parameters $PARAMS \

This is a command injection risk - user-provided input from the read -p prompts flows through eval unsanitized. In a security monitoring tool, this is particularly unfortunate. Use an array instead:

cmd=(aws cloudformation "$OPERATION" --stack-name "$STACK_NAME" ...)
"${cmd[@]}"

Slack webhook stored as plaintext Lambda env var:

NoEcho only prevents CloudFormation from displaying the value. The webhook URL is still readable by anyone with lambda:GetFunctionConfiguration. Consider using Secrets Manager or SSM SecureString, or at minimum note this limitation.

Adobe-specific defaults in a public repo:

The ExcludedUserNames default is portalsvc1,klam-sts-user - these are Adobe-internal service accounts. For a public example, use generic placeholders or leave it empty.

Massive documentation redundancy:

There are three files covering essentially the same content:

• cloudformation-iam-alerts.md (195 lines)
• cloudformation-iam-alerts/README.md (121 lines)
• cloudformation-iam-alerts/IAM-ALERTS-README.md (469 lines)

All three repeat deployment commands, parameter tables, testing instructions, and security notes. I'd consolidate to one doc file + one README that links to it.

Lambda has no error handling:

The Lambda function doesn't wrap the HTTP POST to Slack in a try/except. If the webhook is down or returns an error, the exception propagates unhandled. Worth adding basic error handling and logging.

SNS email template has quoted strings:

The InputTemplate wraps each line in quotes, which will show up as literal quotes in the email body. EventBridge InputTransformer doesn't strip them.

S3 sharing suggests --acl public-read:

The "Sharing with Other Accounts" section in IAM-ALERTS-README.md suggests put-object-acl --acl public-read. Most AWS accounts have S3 Block Public Access enabled by default, and recommending public ACLs in a security-focused example sends the wrong signal. Suggest using S3 presigned URLs or sharing via CloudFormation StackSets instead.

Scope question:

This is a guidelines repo - the examples so far are CLAUDE.md configs and MCP configs (small, config-focused files). A full CloudFormation stack with deploy script, Lambda function, and 1,300+ lines is a different category of content. Would this be better as a standalone repo linked from the guidelines, rather than living inline?