AWS IAM Identity Center logo
Cover Photo by AWS

Problem

Permissions are one of the most difficult to maintain aspects of cloud infrastructure. I find AWS IAM to be the easiest of the cloud IAMs to wrap my head around, but even still, management at scale (hundreds of accounts, thousands of users and permissions) can be a nightmare. IAM Identity Center bridges many of the gaps of traditional IAM, however the management of the tool itself via IaC has been one of my biggest pain points over the last 5 years. Break-glass scenarios, SCIM provisioning, TEAM (AWS’s JIT access solution), new account creation, and countless other edge cases make the code often drift far out from reality. Over the years I’ve chipped away at this automation suite to help solve this PITA once and for all, and I hope others find it useful.

Approach

I have experience in building other reverse-generator tools for systems that are modified by multiple sources (unifi-tf-generator), and have found that the two-phase fetch + generate approach allows for fast iteration. This tool is no different – it fetches all content directly from AWS and caches it as JSON, then processes all of the json through jinja templates into well-formed HCL. Speaking of well formed…

The out-of-the-box HCL for identity center is horrible to read and write. Each combination of user/group, permission set, and account requires a unique terraform resource. To make comprehension of this easier, I’ve built a series of locals maps that store this data hierarchically, and flatten it back into the discrete resources at runtime:

locals {
  account_assignments_map = {
    "Production" = {
      "AdministratorAccess" = {
        "GROUP" = [
          "GlobalAdministrators"
        ]
      },
      "ReadOnlyAccess" = {
        "GROUP" = [
          "Developers", 
          "SecurityAuditors"
        ],
        "USER" = [
          "user@example.com"
        ]
      }
    }
  }
}

In the “Production” AWS account:

  • AdministratorAccess is granted to the GlobalAdministrators group
  • ReadOnlyAccess is granted to the Developers and SecurityAuditors groups
  • ReadOnlyAccess is also granted to the user user@example.com

The hierarchy is: Account → Permission Set → Principal Type (GROUP/USER) → List of principals

This structure is easily navigable in VSCode using Fold All (Ctrl+K Ctrl+0 on Windows/Linux, Cmd+K Cmd+0 on Mac) to collapse the map and drill into specific accounts or permission sets.

Companion Repository

For production implementations, I have created this companion repository to store the generated code, isolating environment data from the “generator” codebase. It includes github actions, codespace definitions, and documentation for end users who need to read/modify the generated HCL. As documented in the repos, it is recommended to import both repositories to your GitHub org for a private, production implementation: