Skip to main content

​
Understanding the Configuration

User and access group definitions live in your Infrastructure as Code (IaC) repository as Terragrunt parameters. There are two main building blocks:
  • Access Groups
  • Users
Access groups define what users can access and the permissions they have.
access_groups = [
  {
    name                      = "DevelopmentTeam"
    description               = "Full access for development team"
    session_duration          = "PT8H"
    customer_managed_policies = []
    
    inline_policies = [
      {
        name = "EKSClusterAccess"
        statements = [
          {
            sid       = "EKSFullAccess"
            actions   = ["eks:*"]
            resources = ["*"]
          }
        ]
      }
    ]
    
    aws_managed_policies = [
      "arn:aws:iam::aws:policy/PowerUserAccess"
    ]
    
    accounts_names = [
      "workload-development",
      "workload-staging"
    ]
  }
]

​
Access Group Examples

Full administrative rights to specific accounts:
{
  name                 = "InfrastructureAdmins"
  description          = "Full administrative access to infrastructure"
  session_duration     = "PT2H"
  aws_managed_policies = ["arn:aws:iam::aws:policy/AdministratorAccess"]
  accounts_names       = ["infrastructure"]
}
Developer access with custom EKS (Elastic Kubernetes Service) permissions:
{
  name             = "DEV-Developers"
  description      = "Developers Access to DEV accounts."
  relay_state      = "https://console.aws.amazon.com/secretsmanager"
  session_duration = "PT8H"
  
  customer_managed_policies = []
  
  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 = ["*"]
        }
      ]
    },
  ]
  
  aws_managed_policies = []
  
  accounts_names = [
    "workload-development"
  ]
}
Limited, read-only access for audit and compliance teams:
{
  name                 = "Auditors"
  description          = "Read-only access for compliance auditing"
  session_duration     = "PT4H"
  aws_managed_policies = ["arn:aws:iam::aws:policy/ReadOnlyAccess"]
  accounts_names       = [
    "workload-production",
    "workload-development",
    "security-tooling"
  ]
}

​
Best Practices

  • Use descriptive names – Make it obvious what each group is for
  • Follow least privilege – Grant only the permissions required
  • Adjust session durations by environment – Shorter in production, longer in development
  • Document group purposes – Clear descriptions prevent confusion later
  • Review regularly – Periodically audit and remove unused users or groups