Skip to main content

​
What you’ll learn

This workshop provides a comprehensive introduction to managing users and access controls within your Fast Foundation environment. You will learn how to create and manage users and groups, including the administration of external users and groups provisioned through identity providers such as Okta. The workshop will also cover best practices for assigning inline policies, applying AWS managed policies, and managing group access across AWS accounts within the Fast Foundation multi-account architecture.

​
Prerequisites

Before starting this workshop, ensure you have:

​
Getting Started

Let’s begin by locating the file where user management is accomplished inside the project. In your infrastructure repository, navigate to: 
Infrastructure/
└── infrastructure/
    └── production/
        └── <your-region>/
            └── permissions/
                └── sso/
                    └── main/
                        ├── terragrunt.hcl
                        └── inputs.hcl
The inputs.hcl file contains the configuration for the user management module.
If it isn’t there, your before-hooks will generate/sync it on terragrunt init. Open a terminal in the main directory, and run terragrunt init.

​
Scenario 1: External IdP with SCIM

An external identity provider (IdP) is a service such as Okta or Azure AD that manages users and groups outside of AWS. When integrated with AWS IAM Identity Center, the SCIM (System for Cross-domain Identity Management) standard is used to automatically provision and synchronize users and groups from the external IdP into AWS.

​
Creating Access Groups for externally created Groups

1

Add access group definition

To create a new access group, add an object inside the external_groups key of the inputs.hcl file.
The name MUST match the name of the group created in the External Identity Provider.
locals {
  management_mode  = "external"
  scim_identity_source  = "Okta"

  external_groups = [
    {
      name                    = "FastFoundation - Devs"
      description             = "Administrator Access for External Fast Foundation Devs Team"
      session_duration        = "PT4H"
      customer_managed_policies = []
      
      inline_policies = []
      
      aws_managed_policies = [
        "arn:aws:iam::aws:policy/AdministratorAccess"
      ]
      
      accounts_names = [
        "workload-development",
        "workload-production"
      ]
    }
  ]
}
This particular Access Group will give Administrator Access to all the users inside the “FastFoundation - Devs” group to the workload-development and workload-production accounts.
2

Understand the parameters

Required fields:
  • name – Unique identifier for the group
  • description – What the group is for
  • accounts_names – Which AWS accounts members can access
Optional fields:
  • session_duration – How long access tokens remain valid (default: PT1H)
  • relay_state – URL to redirect users after login
  • aws_managed_policies – AWS-provided policies (by ARN)
  • inline_policies – Custom policies attached to this group
  • customer_managed_policies – ARNs of existing policies in target accounts
3

Apply changes

Save your file and apply:
# Open a terminal in the directory you are working on

# Review planned changes
terragrunt plan

# Save your parameter file to S3 and apply changes
TG_SECRETS=save terragrunt apply

​
Scenario 2: External IdP without SCIM

When an external identity provider (IdP) is integrated with AWS without SCIM, only authentication (sign-in) is handled by the IdP through SAML or OIDC. Users and groups are not automatically provisioned into AWS. This means administrators must manually create and manage users and groups in AWS IAM Identity Center (or IAM), and keep them synchronized with the external IdP.

​
Creating an Access Group

To create an access group when using an External IdP without SCIM, follow these instructions.
Bear in mind that a group with the same name must exist in the External IdP.

​
Creating a User

To create a user when using an External IdP without SCIM, follow these instructions.
Bear in mind that a user with the same name must exist in the External IdP.

​
Common Access Group Patterns

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-production"
  ]
}

​
Add inline policies to access groups

Optionally, you can attach an inline policy to an Access Group. An inline policy is a block of text formatted as an IAM policy that you add directly to your Access Group.
1

Add inline policy definition

locals {
  access_groups = [
    {
      name         = "Developers"
      description  = "Development team access"
      session_duration = "PT8H"
      accounts_names = [
        "workload-development",
        "workload-production"
      ]

      inline_policies = [
        {
          "name": "ListAllMyBuckets",
          "statements": [
            {
              "sid": "ListAllMyBuckets",
              "effect": "Allow",
              "actions": ["s3:ListAllMyBuckets"],
              "resources": ["*"]
            }
          ]
        }
      ]
    }
  ]
}
This access group would allow all the users inside the “Developers” group to list the S3 Buckets in the workload-development and workload-production accounts.
2

Apply changes

Save your file and apply:
# Open a terminal in the directory you are working on

# Review planned changes
terragrunt plan

# Save your parameter file to S3 and apply changes
TG_SECRETS=save terragrunt apply

​
Assign Groups to AWS applications

To grant access to a customer-managed application in AWS IAM Identity Center, you can assign groups to the application. All users who are members of that group will automatically inherit access to the application, simplifying access management and ensuring consistent permission handling. In the Infrastructure AWS account:
  1. Go to AWS Identity Center → Applications → Customer managed
  2. Find and open the application
  3. Click Assign users and groups
  4. Switch to the Groups tab
  5. Select the access groups that need access
  6. Click Assign
Some applications require extra configuration steps before the users can interact with them. For example, the Cloud Connexa VPN Application requires this extra configuration steps.