Manage AWS Users & Groups

Understanding the Configuration

User and access group definitions live in your Infrastructure as Code (IaC) repository as Terragrunt parameters. The configuration has three main building blocks:

Permission Sets
Access Groups
Users

Permission sets are reusable policy definitions that can be shared across multiple groups. Each permission set defines the policies and session duration independently from the groups that use it.

permission_sets = {
  "PowerUser" = {
    description          = "Power user access"
    session_duration     = "PT8H"
    aws_managed_policies = ["arn:aws:iam::aws:policy/PowerUserAccess"]
  }
  "EKSAdmin" = {
    description     = "Administrator access to EKS resources"
    relay_state     = "https://console.aws.amazon.com/eks"
    session_duration = "PT1H"
    inline_policies = [
      {
        name = "EKSClusterAccess"
        statements = [
          {
            sid       = "EKSFullAccess"
            actions   = ["eks:*"]
            resources = ["*"]
          }
        ]
      }
    ]
  }
}

Access groups define who can access what. Each group has a list of assignments that map a permission set to a list of accounts. One group can have different permission sets on different accounts.

access_groups = {
  "DevelopmentTeam" = {
    description = "Full access for development team"
    assignments = [
      {
        permission_set = "PowerUser"
        accounts       = ["workload-development", "workload-staging"]
      },
      {
        permission_set = "EKSAdmin"
        accounts       = ["workload-development"]
      }
    ]
  }
}

Users represent individuals in your organization. Each user belongs to one or more groups, which determine their access:

users = [
  {
    display_name = "Jane Smith"
    email        = "jane.smith@company.com"
    given_name   = "Jane"
    family_name  = "Smith"
    groups       = [
      "DevelopmentTeam",
      "LogsReadOnly"
    ]
  }
]

Permission Set Examples

Administrative Access

Full administrative rights:

"Management" = {
  description          = "Administrator access for all member accounts"
  session_duration     = "PT4H"
  aws_managed_policies = ["arn:aws:iam::aws:policy/AdministratorAccess"]
}

Developer Access with Custom Policies

Scoped access to Secrets Manager with tag-based filtering:

"DevSecretsAccess" = {
  description      = "Scoped Secrets Manager access for developers"
  relay_state      = "https://console.aws.amazon.com/secretsmanager"
  session_duration = "PT8H"
  inline_policies = [
    {
      name = "secretsManagerAccess"
      statements = [
        {
          sid     = "readwriteSecrets"
          actions = [
            "secretsmanager:GetSecretValue",
            "secretsmanager:DescribeSecret",
            "secretsmanager:PutSecretValue",
            "secretsmanager:UpdateSecret"
          ]
          resources = ["*"]
          conditions = [
            {
              test     = "StringEquals"
              variable = "aws:resourceTag/team"
              values   = ["developers"]
            }
          ]
        },
        {
          sid       = "listSecrets"
          actions   = ["secretsmanager:ListSecrets"]
          resources = ["*"]
        }
      ]
    }
  ]
}

Read-Only Access

Limited, read-only access for audit and compliance teams:

"ReadOnly" = {
  description          = "Read-only access for compliance auditing"
  session_duration     = "PT4H"
  aws_managed_policies = ["arn:aws:iam::aws:policy/ReadOnlyAccess"]
}

Access Group Examples

Admins — Same permissions everywhere

A group with the same permission set across all accounts:

"InfrastructureAdmins" = {
  description = "Full administrative access to infrastructure"
  assignments = [
    {
      permission_set = "Management"
      accounts = [
        "infrastructure",
        "security-tooling",
        "workload-production",
        "workload-development"
      ]
    }
  ]
}

Developers — Different permissions per environment

A group with PowerUser on dev/staging but ReadOnly on production:

"Developers" = {
  description = "Development team access"
  assignments = [
    {
      permission_set = "PowerUser"
      accounts       = ["workload-development", "workload-staging"]
    },
    {
      permission_set = "ReadOnly"
      accounts       = ["workload-production"]
    }
  ]
}

Auditors — Read-only everywhere

"Auditors" = {
  description = "Read-only access for compliance auditing"
  assignments = [
    {
      permission_set = "ReadOnly"
      accounts = [
        "workload-production",
        "workload-development",
        "security-tooling"
      ]
    }
  ]
}

Best Practices

Define permission sets once, reuse across groups — Avoid duplicating policy definitions
Use descriptive names — Make it obvious what each permission set and group is for
Follow least privilege — Grant only the permissions required
Different permissions per environment — Use multiple assignments to give broader access in dev, restricted in production
Adjust session durations by environment — Shorter in production, longer in development
Review regularly — Periodically audit and remove unused users or groups

Introduction & Key Concepts

AWS SSO Setup

IaC Management

User Management

Application Creation

ArgoCD UI

Workshops

Understanding the Configuration

Permission Set Examples

Access Group Examples

Best Practices

​Understanding the Configuration

​Permission Set Examples

​Access Group Examples

​Best Practices

Understanding the Configuration

Permission Set Examples

Access Group Examples

Best Practices