Kiro CLI supports hooks — scripts that intercept agent actions before they execute. Here are four security hooks you should adopt.

How hooks work

Hooks are shell scripts that fire before an agent uses a tool. They receive JSON context via stdin and control behavior through exit codes: 0 to allow, 2 to block. When a hook exits 2, its stderr is returned to the agent as the reason.

You define them in your agent's JSON config under hooks.preToolUse. Each hook specifies a command (the script path), a description (shown to the agent when blocked), and a matcher that scopes the hook to a specific tool (fs_write, execute_bash, etc.).

Dependency pinning

LiteLLM gets 3.4 million PyPI downloads per day. On March 24, two versions shipped with a credential stealer targeting SSH keys, IAM keypairs, and Kubernetes secrets. Pinning to exact versions is the standard mitigation, but agents don't do it by default.

This hook blocks any write to package.json, requirements.txt, pyproject.toml, or Cargo.toml if versions aren't pinned. boto3>=1.40 gets rejected. boto3==1.40.0 passes.

Hook config:

{
  "matcher": "fs_write",
  "command": ".kiro/hooks/check-dependency-pins.sh",
  "description": "Block writes to dependency files with unpinned versions"
}

Script preview (full source):

#!/bin/bash
# Hook: Validate dependency files have pinned versions before writing.
# Trigger: preToolUse on fs_write
# Exit 0 = allow, Exit 2 = block (returns STDERR to LLM)
set -euo pipefail

EVENT=$(cat)
_HOOK_EVENT="$EVENT" python3 << 'PYEOF'
import json, sys, re, os

def check_package_json(content, filename):
    try:
        data = json.loads(content)
    except Exception:
        return []
    bad = []
    for section in ('dependencies', 'devDependencies', 'peerDependencies'):
        deps = data.get(section, {})
        for name, ver in deps.items():
            if re.search(r'[\^~*x]|>=|>|latest', str(ver)):
                bad.append(f'  {section}.{name}: {ver}')
    return bad

def check_requirements_txt(content, filename):
    bad = []
    for line in content.splitlines():
        line = line.strip()
        if not line or line.startswith('#') or line.startswith('-'):
            continue
        if re.match(r'^[a-zA-Z0-9_.-]+\s*(\[.*\])?\s*==\s*[0-9]', line):
            continue
        bad.append(f'  {line}')
    return bad
# ... checkers for pyproject.toml and Cargo.toml, then dispatch logic
PYEOF

Each ecosystem gets its own checker. package.json catches ^, ~, *, and latest. requirements.txt requires ==. Cargo catches bare versions (which Cargo treats as ^).

Secrets scanning

The hook scans every file write for patterns matching AWS keys, private keys, GitHub tokens, Slack tokens, and generic API key shapes. Match found, write blocked. The agent gets told to use environment variables or a secrets manager instead.

Hook config:

{
  "matcher": "fs_write",
  "command": ".kiro/hooks/check-secrets.sh",
  "description": "Block writes containing secrets or API keys"
}

Script preview (full source):

#!/bin/bash
# Hook: Block writes containing secrets (API keys, private keys, tokens).
# Trigger: preToolUse on fs_write
# Exit 0 = allow, Exit 2 = block (returns STDERR to LLM)
set -euo pipefail

EVENT=$(cat)
_HOOK_EVENT="$EVENT" python3 << 'PYEOF'
import json, sys, re, os

ALLOWLISTED_EXTENSIONS = {'.md', '.example', '.sample', '.template'}
ALLOWLISTED_LINE_PATTERNS = re.compile(r'EXAMPLE|PLACEHOLDER|<[A-Z_]+>')

SECRET_PATTERNS = [
    ('AWS Access Key ID',     re.compile(r'AKIA[0-9A-Z]{16}')),
    ('AWS Secret Access Key', re.compile(r'(?<![A-Za-z0-9/+])[A-Za-z0-9/+=]{40}(?![A-Za-z0-9/+=])')),
    ('RSA/EC Private Key',    re.compile(r'-----BEGIN\s+(RSA|EC|DSA|OPENSSH)?\s*PRIVATE KEY-----')),
    ('GitHub Token',          re.compile(r'gh[ps]_[A-Za-z0-9_]{36,}')),
    ('Slack Token',           re.compile(r'xox[bpors]-[A-Za-z0-9-]+')),
    ('Generic API Key',       re.compile(r'(?i)(api[_-]?key|api[_-]?secret|auth[_-]?token)\s*[:=]\s*["\']?[A-Za-z0-9_\-]{20,}')),
]
# ... scans each line of each file write, reports findings, exits 2 if blocked
PYEOF

It allowlists markdown files and lines containing "EXAMPLE" or "PLACEHOLDER" so documentation passes through. Not a replacement for git-secrets or truffleHog — it's the layer that catches things before they enter git history at all.

Destructive command blocking

Parses every shell command before execution and blocks the irreversible ones. rm -rf /, DROP TABLE, terraform destroy without -target, git push --force to main, kubectl delete namespace kube-system.

Hook config:

{
  "matcher": "execute_bash",
  "command": ".kiro/hooks/guard-destructive-commands.sh",
  "description": "Block dangerous shell commands"
}

Script preview (full source):

#!/bin/bash
# Hook: Block dangerous shell commands that could cause irreversible damage.
# Trigger: preToolUse on execute_bash
# Exit 0 = allow, Exit 2 = block (returns STDERR to LLM)
set -euo pipefail

EVENT=$(cat)
_HOOK_EVENT="$EVENT" python3 << 'PYEOF'
import json, sys, re, os

RULES = [
    # (description, pattern that BLOCKS, pattern that ALLOWS as exception)
    (
        'Recursive delete of root/home',
        re.compile(r'rm\s+.*-[a-zA-Z]*r[a-zA-Z]*f[a-zA-Z]*\s+(/\s|/\s*\(|~\s|~\s*\)|\\(HOME\s|\\)HOME\s*$)', re.MULTILINE),
        None,
    ),
    (
        'SQL destructive operation',
        re.compile(r'\b(DROP\s+(TABLE|DATABASE)|TRUNCATE\s+TABLE)\b', re.IGNORECASE),
        None,
    ),
    (
        'Terraform destroy without target',
        re.compile(r'terraform\s+destroy\b'),
        re.compile(r'terraform\s+destroy\s+.*-target\b'),
    ),
    (
        'Docker system prune',
        re.compile(r'docker\s+system\s+prune\b'),
        None,
    ),
    (
        'Disk format or raw write',
        re.compile(r'\b(mkfs\b|dd\s+if=.*/dev/)'),
        None,
    ),
    (
        'Force push to protected branch',
        re.compile(r'git\s+push\s+.*--force.*\b(main|master|production)\b'),
        None,
    ),
    (
        'Delete critical Kubernetes namespace',
        re.compile(r'kubectl\s+delete\s+namespace\s+(kube-system|production|default)\b'),
        None,
    ),
]
# ... parses command from event, checks each rule, exits 2 if blocked
PYEOF

Safe versions pass through. rm -rf ./node_modules is fine. terraform destroy -target=aws_instance.foo is fine. Each rule has a block pattern and an optional allow pattern for the safe variant.

Config drift protection

This one blocks writes to the steering rules, skills, and agent config directories. The agent can't modify the rules it operates under without explicit user approval.

Hook config:

{
  "matcher": "fs_write",
  "command": ".kiro/hooks/config-drift-guard.sh",
  "description": "Block writes to steering/skills/agents without approval"
}

Full script (source):

#!/bin/bash
# Hook: Block writes to agent config files unless explicitly approved.
# Trigger: preToolUse on fs_write
# Exit 0 = allow, Exit 2 = block (returns STDERR to LLM)
#
# Protected paths: ~/.kiro/steering/, ~/.kiro/skills/, ~/.kiro/agents/
# To allow config writes, set KIRO_ALLOW_CONFIG_WRITES=1
set -euo pipefail

[ "${KIRO_ALLOW_CONFIG_WRITES:-}" = "1" ] && exit 0

EVENT=$(cat)
_HOOK_EVENT="$EVENT" python3 << 'PYEOF'
import json, sys, os

KIRO_DIR = os.path.realpath(os.path.expanduser("~/.kiro"))
PROTECTED = [
    os.path.join(KIRO_DIR, "steering"),
    os.path.join(KIRO_DIR, "skills"),
    os.path.join(KIRO_DIR, "agents"),
]

try:
    event = json.loads(os.environ['_HOOK_EVENT'])
except (KeyError, json.JSONDecodeError) as e:
    print(f"Hook error: failed to parse event: {e}", file=sys.stderr)
    sys.exit(1)

inp = event.get('tool_input', {})
ops = inp.get('ops', [inp])
for op in ops:
    path = op.get('path', '')
    if not path:
        continue
    resolved = os.path.realpath(os.path.expanduser(path))
    for protected in PROTECTED:
        if resolved.startswith(protected + os.sep) or resolved == protected:
            print("BLOCKED: Writing to Kiro configuration files requires explicit approval.", file=sys.stderr)
            print(f"File: {resolved}", file=sys.stderr)
            print("Ask the user to approve this change before proceeding.", file=sys.stderr)
            sys.exit(2)
sys.exit(0)
PYEOF
exit $?

An agent optimizing for task completion has an incentive to relax its own constraints. This hook removes that option. Set KIRO_ALLOW_CONFIG_WRITES=1 when you intentionally want to update config.

Putting it all together

Here's the complete hooks config. All four hooks fire on preToolUse — three on fs_write, one on execute_bash:

"hooks": {
  "preToolUse": [
    {
      "matcher": "fs_write",
      "command": ".kiro/hooks/check-dependency-pins.sh",
      "description": "Block writes to dependency files with unpinned versions"
    },
    {
      "matcher": "fs_write",
      "command": ".kiro/hooks/check-secrets.sh",
      "description": "Block writes containing secrets or API keys"
    },
    {
      "matcher": "fs_write",
      "command": ".kiro/hooks/config-drift-guard.sh",
      "description": "Block writes to steering/skills/agents without approval"
    },
    {
      "matcher": "execute_bash",
      "command": ".kiro/hooks/guard-destructive-commands.sh",
      "description": "Block dangerous shell commands"
    }
  ]
}

The design principle

None of these hooks reduce what the agent can do. They validate actions between intent and execution. The agent writes code, runs commands, modifies files — it just clears a checkpoint before doing the irreversible, insecure, or self-modifying ones.

This and more posted to AWS Samples: github.com/aws-samples/sample-kiro-cli-multiagent-development

What hooks are you running? I'd like to hear what others are catching — drop a comment or send me a message.

"You need to run CLI commands non-interactively." "Try again but split it into smaller calls." "Stop — I already told you to use the staging bucket." These corrections are signals. They reveal gaps between what the agent knows and how you actually work. The problem is that most agent setups treat each session as disposable. The agent makes the same mistake on Tuesday that you corrected on Monday.

What if the agent could learn from those corrections — not through fine-tuning or retraining, but by updating its own configuration?

The configuration hierarchy

Kiro CLI organizes agent behavior through a layered configuration system:

• Steering docs — universal behavioral rules that apply to all agents (e.g., "always use non-interactive commands," "pin dependency versions")

• Skills — domain-specific knowledge packages (e.g., AWS CLI best practices, Docker build patterns)

• Agent prompts — per-agent instructions that define personality, capabilities, and constraints

• Hooks — scripts that fire at agent lifecycle points to enforce policy, collect data, or block unsafe operations (e.g., reject unpinned dependencies, prevent unauthorized config changes)

When an agent does something wrong, the root cause usually maps to one of these layers. It either violated a rule that doesn't exist yet, lacked domain knowledge for the task, or has agent-specific instructions that are too vague.

The flywheel concept

The flywheel is a stored prompt that turns session history into configuration improvements. It works in five phases:

Phase 1 — Session analysis. A stop hook logs a lightweight summary after every agent turn to ~/.kiro/flywheel-log.jsonl — timestamp, working directory, and a response preview. The flywheel reads this log first for a fast index of recent activity, then dives into the full session JSONL for correction details: explicit corrections, redirections, cancelled turns followed by rephrased requests, repeated instructions, and frustration signals where the user simplifies their request after a failed attempt.

Phase 2 — Pattern recognition. One-off mistakes get filtered out. The agent groups corrections by theme — "output too verbose," "wrong tool choice," "hallucinated API" — and focuses on patterns that appear across multiple sessions.

Phase 3 — Cross-reference. For each pattern, the agent reads the existing steering docs, skills, and agent prompts to determine whether the issue is already covered (but too weakly worded), completely missing, or being ignored.

Phase 4 — Propose changes. The agent writes a structured report with evidence (quoted user messages), root cause analysis, and draft content for each proposed configuration change. Each proposal is classified as a steering update, new skill, or agent prompt modification.

Phase 5 — Interactive review. The agent walks through each proposal. You approve, modify, or skip. Approved changes get applied to the correct files with proper formatting. Nothing ships without your sign-off.

What correction events look like

Kiro stores session data as JSON metadata paired with JSONL conversation logs. Each line in the log is a typed event — user prompts, assistant messages, and tool results. The flywheel scans user prompts for patterns that indicate the preceding assistant action was wrong:

The key insight is that the correction message and the assistant message before it form a pair: what the agent did wrong, and what the user wanted instead. That pair, abstracted into a general principle, becomes a candidate configuration rule.

A concrete example

Across several sessions, the agent generates tool calls with payloads that exceed size limits, forcing the user to say "try again but split up the work." This pattern appears three times in a week.

The flywheel identifies the pattern, checks existing steering docs, finds no rule covering output size management, and proposes a new steering doc:

---
inclusion: always
---

# Output Size Awareness

When writing content through tools (MCP servers, file writes, API calls), check whether the target has size constraints. If the payload is large,split it into multiple smaller operations proactively — don't wait for a failure or user correction.

You review it, tweak the wording, approve. The agent applies it. Next week, the agent chunks large writes automatically.

Why this works

The flywheel works because it operates on the same configuration layer the agent already reads. There's no model retraining, no fine-tuning pipeline, no vector database to maintain. It's just markdown files that get included in the agent's context on every session.

It also works because it's conservative by design. The prompt requires patterns across multiple sessions before proposing a change, quotes actual user messages as evidence, and never applies changes without explicit approval. A preToolUse hook called the "drift guard" enforces this — it blocks any write to steering, skills, or agent config files unless the user has approved the change. You're not handing the agent a blank check to rewrite its own instructions — you're reviewing pull requests against your agent's behavior, with a guardrail that prevents unauthorized self-modification.

The compound effect is what makes it a flywheel. Each correction you make today becomes a rule that prevents the same class of error tomorrow. Over weeks, the agent accumulates your preferences, your team's conventions, and your project's constraints — not as ephemeral context that disappears when the session ends, but as persistent configuration that shapes every future interaction.

Getting started

The implementation is a stored prompt file plus three hook scripts. The stop hook collects turn data passively. The drift guard hook prevents unauthorized config changes. The dependency pinning hook is a bonus — it blocks writes to package.json or requirements.txt with unpinned versions, demonstrating how hooks enforce policy beyond the flywheel use case.

For example code, check out this AWS Sample I published with my Kiro CLI configuration. If you just want an example of the call hook code, I also saved it as a GIST.

Run the flywheel periodically — weekly works well — or whenever you notice the agent repeating a mistake you've already corrected. Each run produces a report, and each approved change makes the next run's report shorter.

The best agent configuration isn't the one you write on day one. It's the one that evolves from how you actually use the tool.

Sometimes it's worse. The company has five, seven, or ten accounts scattered across a loosely structured organization and a handful of standalone accounts with no centralized governance at all. The management account runs production. Service control policies (SCPs) don't apply to it. There's no unified security baseline. The standalone accounts have no guardrails.

If this sounds familiar, you're not alone. It's one of the most common multi-account anti-patterns I see, especially in small and mid-sized companies that grew their AWS footprint organically. The good news: there's a clean path forward. The less obvious news: restructuring your existing organization in place usually isn't it.

This post walks through when and how to create a new AWS Organization, migrate your existing accounts into it, and establish the governance foundation you should have had from the start.

Why running workloads in the management account is a problem

The management account in AWS Organizations has a unique property that makes it a poor home for workloads: SCPs don't restrict it.

This means any guardrails you implement through SCPs like restricting regions, preventing public S3 buckets, requiring encryption don't apply to the management account. If your production workloads run there, they operate outside your governance boundary. The management account should only handle your AWS Organization management, billing, and Identity management through IAM Identity Center.

Beyond SCPs, running workloads in the management account creates additional risks:

• Blast radius. A compromised workload in the management account has implicit access to organizational operations. The management account can create accounts, attach policies, and modify the organization structure.

• Billing confusion. Workload costs in the management account are harder to attribute and track. Separating workloads into dedicated accounts enables cleaner cost allocation.

• Audit complexity. Compliance frameworks expect separation of duties between administrative and workload accounts. Mixing them complicates audit evidence collection.

Why you can't just restructure in place

The intuitive fix is to move workloads out of the management account and restructure the existing organization. For some environments, that works, but there's a structural constraint that often makes it impractical: you cannot demote a management account to a member account.

If your management account runs production workloads and you want it to become a regular member account in a properly structured organization, you can't do that within the existing organization. The management account is the management account — permanently, for that organization.

You also can't transfer the management account role to another account. The only way to change which account is the management account is to create a new organization with a different account at the top.

This is how I think about which option to use:

Before making a final decision, I recommend reading the excellent blog series Moving an Organization member account to another organization to ensure you are not using any organization features that can break applications.

The migration: four phases

Phase 1: Stand up the new organization

Create a new, dedicated AWS account that will serve as the management account for your new organization. This account should have:

• A group email address (not a personal email) for the root user

• MFA enabled on the root user

• No workloads — ever

Create the organization from this account with all features enabled. Then deploy AWS Control Tower as your landing zone foundation. Control Tower automates the creation of a Security OU with dedicated Log Archive and Audit accounts, establishes baseline controls, and provides a framework for ongoing governance.

Design your OU structure based on the AWS Security Reference Architecture (SRA). At minimum, separate security, production workloads, non-production workloads, and sandbox environments.

Phase 2: Establish the security baseline

Before migrating any accounts, establish the security services that will apply organization-wide. Enable these from through delegated administrators:

• AWS Security Hub

• AWS Security Hub CSPM

• Amazon GuardDuty

• Amazon Inspector

Enable these at the organization level so every account that joins the organization automatically inherits the baseline. This is the key advantage of establishing the baseline before migration — you don't have to retrofit security into accounts after the fact.

Phase 3: Migrate accounts

Account migration follows a specific sequence. The order matters because of how AWS Organizations handles the management account.

Step 1: Migrate standalone accounts first. These are the simplest — they aren't in any organization, so there's nothing to leave. From your new management account, send an invitation. From the standalone account, accept it. The account joins the new organization and immediately inherits your SCPs and security baseline.

Step 2: Migrate member accounts from the old organization. This has recently gotten easier with the new feature allowing direct account transfers between organizations. Simply invite your accounts to the new organization, and accept them in the old organization.

Step 3: Migrate the old management account last. The management account can only leave its organization after all member accounts have been removed and the organization is deleted. Once the old organization is dissolved, the former management account becomes a standalone account and can accept an invitation to join the new organization as a regular member account.

This sequence ensures continuity — the old organization continues to function for remaining accounts while you migrate them one at a time.

Before migrating each account, review:

• IAM policies that reference the old organization ID or management account ID

• SCPs from the old organization that the account depended on (you'll need equivalent policies in the new org)

• Billing — Reserved Instances and Savings Plans transfer with the account, but verify cost allocation tags and billing preferences

• Service integrations — CloudTrail, Config, and other services with organization-level configurations may need reconfiguration

Phase 4: Harden with governance controls

With all accounts in the new organization, implement the governance layer:

Service control policies (SCPs) — Start with deny-list SCPs that prevent the most dangerous actions: disabling CloudTrail, deleting GuardDuty detectors, creating public S3 buckets, or launching resources in unapproved regions. SCPs now apply to every member account — including the account that used to be your old management account.

Resource control policies (RCPs) — A newer complement to SCPs. While SCPs restrict what IAM principals in your accounts can do, RCPs restrict what external principals can do to resources in your accounts. Together, they form the identity and resource boundaries of a data perimeter.

Control Tower enrollment — Enroll all migrated accounts into Control Tower to apply the full set of preventive and detective controls. This provides continuous compliance monitoring and drift detection.

Centralized logging — Verify that CloudTrail organization trails, Config recordings, and VPC Flow Logs all route to the Log Archive account in your Security OU.

Common concerns

"This sounds disruptive — will my workloads go down during migration?"

With proper planning, no. Moving an account between organizations is an administrative operation. It changes the account's organizational membership and billing relationship. It does not affect running resources, VPCs, EC2 instances, databases, or any other infrastructure within the account. Workloads continue running uninterrupted, provided you aren't relying on resource shares in RAM or other organization-specific configuration.

"Can I do this incrementally?"

Yes, and you should. Migrate one or two low-risk accounts first — a sandbox or development account — to validate the process. Confirm that the security baseline applies correctly, billing works as expected, and no IAM policies break. Then migrate production accounts with confidence.

"What about consolidated billing?"

Billing follows the organization. When an account moves to the new organization, its charges appear on the new management account's consolidated bill. Reserved Instances and Savings Plans sharing transfers with the account. Review your billing configuration after each migration to confirm cost allocation tags and billing alerts are intact.

Cleaning up

After all accounts are migrated and the old organization is dissolved:

• Delete the old organization's management account if it's no longer needed, or repurpose it as a workload account in the new organization

• Remove any stale IAM roles, policies, or cross-account trust relationships that reference the old organization ID

• Update any automation, CI/CD pipelines, or scripts that reference the old management account ID or organization ID

• Verify that all accounts appear in Control Tower and that no accounts are in a "not enrolled" state

Conclusion

In this post, I walked through why running workloads in your AWS management account creates a governance gap, why restructuring in place often isn't viable, and how to migrate to a properly structured organization.

The core pattern: create a new organization with a clean, dedicated management account. Establish your security baseline (Security Hub/Security Hub CSPM, GuardDuty, Inspector) before migrating accounts. Migrate standalone accounts first, old organization members second, and the old management account last. Then harden with SCPs, RCPs, and Control Tower enrollment.

If you're operating with a management account that runs workloads or standalone accounts with no governance, this migration is the prerequisite for everything else — cost optimization, security hardening, compliance programs. You can't govern what you can't see, and you can't enforce what doesn't apply.

If you have questions or have gone through this migration yourself, leave a comment — I'd like to hear how it went.

Understanding IAM security models is one of the most important aspects of effectively and safely managing AWS environments. Throughout my work consulting with various companies, I have noticed a trend that many organizations are managing the cloud in similar fashion to how they managed on-premise environments. The purpose of this post is to review some strategies to manage identities for people in AWS and the target audience for this post are users that might be newer to AWS IAM security principles.

AWS IAM Basics

When we talk about IAM, it's important to note the differences between Users, Roles, Policies and Groups

• Users: Users allow you to create identities for users. Users can can be added to groups with policies attached to the group, or have policies attached to them to add permissions. Users can have two types of credentials, Console credentials to access the web console, and Access Keys which are used for programmatic access using the AWS CLI or SDK.

• Groups: Groups allow you to assign policies to the group, and then add users to the group to simplify credential management. Only 10 managed policies can be added to an individual group, but you may also add inline policies that are defined within the group.

• Roles: Roles are used for a few things within AWS, but this boils down primarily to allowing users to assume role into your account, including users from other AWS accounts, as well as allowing AWS services to access resources within your account.

• Policies: Policies are JSON documents that define the permissions that the attached identity (user, group) has access to. You can use conditionals, variables and wildcards in these policies documents to control access based on a variety of factors, such as MFA being used to log in or the AWS Region being used. Managed AWS policies exist for baseline access, but you can also add your own policies for more granular control.

Note that there are other aspects of IAM, such as Identity Providers, where you can connect to SAML or OpenID to set up single sign-on, and the IAM Access Analyzer, but those will be covered in a future post.

Securing IAM Access for Users

To set up a secure access to AWS, there are a few key things to consider:

• All users should only have one IAM user.

• Permissions should be assigned with the least privilege needed for the user.

• Permissions should be assigned by groups, and not individually to users.

• MFA should be enabled for all users

• Access Keys and Passwords should be rotated on a regular basis.

• Using temporary permissions by assuming roles is preferred.

Putting It All Together

To put this all together, let's take a practical example of setting up read access for a user.

First, we will create an administrative role for our user to assume in the console.

One thing to note when creating this role, is we have selected "Another AWS Account" but you can specify the account your user is in as well! One advantage of this approach is you can default to having your users have very little permissions, perhaps only access to IAM to complete basic tasks like setting up MFA, and the ability to assume roles. This is helpful, because if an account is compromised, the attacker will not be able to simply query the API to list your resources or make destructive changes. They would first need to know the role name to assume to have the appropriate level of access. This, admittedly, is a bit of "security through obscurity" but this can still be effective when utilized with other best practices.

Next, we give the role permissions. For this example, I'm giving the AWS managed policy "ReadOnlyAccess"

I'm not adding any tags for this example, but tags are a great way to identify ownership of resources.

Last, but not least, give the role a name, and note the role because you will need it to assume the role.

Now we need a policy document that allows us to assume the role in our (or another!) account.

Let's create a policy to allow access to assume role. Create a policy in the AWS console. If you use the visual editor, choose the STS service and select "AssumeRole" under "Write". Under resources, enter the account number and role name that you want your user to be able to assume. Remember, this can be the current account or another AWS account. You can also wildcard here, so if you use the same role name across all your accounts you can simply wildcard the account number to allow your user to assume that role across all your accounts.

You can also simply enter the JSON as follows. Make sure you change the account number to your account number!

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "sts:AssumeRole",
            "Resource": "arn:aws:iam::123456789012:role/ReadOnlyAccess"
        }
    ]
}

Once you create the policy, attach it to a group, and make sure the users who need access are added to the group.

Assuming the Role

Last, to test this out, click on your IAM username in the header of the IAM console and click on "Switch Roles" - Enter the account number holding the role you will assume, and then the role name that you created earlier.

Once you click on Switch Role, if everything is working correctly your username at the top will show the role you are currently using.

To demonstrate the access as well, I'm logging in to the S3 console. Note that I can see my CloudFormation template bucket:

But I cannot create a new bucket, because I am assuming a role that only has read-only access:

### Wrapping Up So, now that we have a centralized method to manage identity in AWS for our users, important next step is to think about how to audit and manage ongoing usage. In a future post, I'll cover how to use Security Hub, AWS Config and the IAM Access Analyzer to create a strong program around managing identity for users.

Now that you're assuming roles to access permissions in your account(s) I also recommend the AWS Extend Switch Roles plugin for Chrome/Firefox. This helps store your role switch configuration, rather than relying on the Role History within the AWS Console by default.

Lastly, here is a JSON policy document to require logins with MFA for your IAM users to be able to access nearly all AWS resources:

https://gist.github.com/PatrickJD/7aca25836048bf871ea72253c8531854

A more cloud mature organization would have these alarms defined in IAC from the beginning, but when dealing with customers with hundreds of EC2 instances and other resources that have been created in the console, I was looking for a quick way to create standard CloudWatch alarms. With my Windows admin background, PowerShell was a natural choice, also helped by how fantastic the AWS PowerShell tools are. My first iteration wrote directly to CloudWatch alarms by looping through a variable:

This worked well, but there are a few problems…

First, this only adds new alarms, it doesn’t have logic for removing unused alarms. Second, we should really be using Infrastructure-as-code to detect drift and make sure these alarms are not changed in the console. Third, we would have to run this frequently to keep alarms updated, which introduces another manual task (or using AWS Lambda, which has excellent PowerShell support!)

To resolve these issues, I decided to re-write the script to instead write CloudFormation templates, instead of writing alarms directly. The second iteration instead writes a code block through a loop to a CloudFormation Template

This is all tied together by a larger function that calls each individual function:

After a bit of debugging & fixing the template, I’m happy with the results! Deploying with CloudFormation has some nice benefits, including being able to detect drift, customize the template further for outliers (which my original script did not handle well at all) and check our generated template into source control.

I think there is potential in this method to much more! My immediate plan is to write more standard alarm generators for other services and custom metrics, but I think long term this could be an interesting solution to generate CloudFormation templates for existing resources within AWS (similar to Former2) without having to provide access keys to a 3rd party service.