Tailor AWS Identity Center (SSO) Permissions Per Account with IAMbic

Managing permissions at scale is hard.

Managing permissions at scale across multiple AWS accounts - each with different environments and compliance requirements - is even harder.

AWS Identity Center (SSO) aims to simplify access to your AWS accounts, but tailoring the fine-grain cloud permissions for each account remains challenging.

In this post, we’ll show you how to use IAMbic to create an AWS SSO permission set with different permissions per account. The end result? Manage your AWS SSO permission sets alongside the rest of your IAM with IAMbic, and tailor both access and fine-grained cloud permissions. Check out the GitHub Repo, and Docs for more information.

The Power of IAMbic

IAMbic's primary goal is to help cloud teams manage identities and permissions across human identity providers and cloud platforms in a centralized, compliant, and practical manner. By integrating permissions from providers like AWS, Azure AD, Okta, and G-Suite into a single version-controlled repository, IAMbic simplifies managing access and permissions at scale.

With minimal effort, IAMbic will import and continuously update a copy of your existing IAM in version control. It keeps track of all IAM changes, regardless of their origin, resulting in a comprehensive history of permission changes across multiple providers, in a single place, and in a common format.

IAMbic templates are bi-directional, supporting a developer-friendly GitOps workflow to write changes back to the cloud. Each resource supports drift prevention, declarative temporary access, and multi-account awareness in AWS. The goal is to provide greater control, insight, and efficiency in managing cloud access and permissions.

SSO Permission Sets, Tailored by Account

In this tutorial, we will:

1. Create and deploy a multi-account Managed Policy with different permissions depending on the AWS account. This will be referenced in the Permission Set.
2. Create and deploy a new Permission Set, referencing our Customer Managed Policy

‍

Before we get started, we’ll need to set up a local Git repository and configure IAMbic locally. More guidance is in the Getting Started Guide. If you ever get stuck, or have any questions or feedback, please don't hesitate to reach out on Slack!

1. Create and initialize a local Git repository to store your IAMbic templates in. If you don’t have Git, you can download it from git-scm.com

mkdir iambic-templates
cd iambic-templates
git init
cat < .gitignore
**/secrets.yaml
proposed_changes.yaml
venv/
EOF

2. Install IAMbic into a Python Virtual Environment within your iambic-templates repository above. If you don’t have Python, you can download it at python.org.

python3 -m venv venv
. venv/bin/activate
pip install iambic-core

3. Configure AWS credentials for your AWS Organization, and follow the instructions provided by the IAMbic setup wizard. Pay careful attention that you select Yes to enable Identity Center, and select the appropriate region for Identity Center. To run the wizard, you will need adequate permissions to manage CloudFormation Stack Sets, as this process will create IAMbic hub and spoke roles in your environment.

# Before running the next step, first configure AWS credentials for your AWS Organization
iambic setup

After these steps, you should have a repository containing your existing IAM settings across the accounts you’ve configured IAMbic for. This should include your existing AWS Identity Center permission sets. If you do not see these in your repository under resources/aws/identity_center/permission_set, double-check your IAMbic configuration and consider re-running iambic setup.

Creating an AWS SSO Permission Set with Different Permissions per Account

To create a permission set across accounts, we’re going to use IAMbic to create a managed policy across accounts, but with different permissions on each account. We can define this policy using a single template.

After that, we will define our permission set and attach the managed policy to it by name.

Creating a Multi-Account Managed Policy

1. Create a directory to hold the managed policies. IAMbic doesn’t technically care where the file is within the repository, so you can change its location to fit your needs if desired.

mkdir -p resources/aws/iam/managed_policy/all_accounts/

2. Create a new file for our managed policy. Please adjust the account names accordingly (They should match the accounts that were imported into your iambic_config.yaml file).

This managed policy will be applied to all accounts, and every account will block s3:PutObjectAcl. The staging account has read-only access to some services, while the dev account has broader permissions. Both have read-only access to their services due to the arn:aws:iam::aws:policy/ReadOnlyAccess policy which is used as a Permissions Boundary. The iambic_managed: enforced flag ensures IAMbic will automatically prevent and revert any drift in the managed policy across accounts. If changes are made to the policy on any account, IAMbic will restore it to the defined state in Git.

3. Write the template below to this file in your iambic-templates repository: resources/aws/iam/managed_policy/all_accounts/iambic_test_managed_policy.yaml

template_type: NOQ::AWS::IAM::ManagedPolicy
included_accounts:
  - '*'
identifier: iambic_managed_policy
iambic_managed: enforced
properties:
  policy_document:
    statement:
      - included_accounts:
          - staging
        action:
          - 's3:GetObject'
          - 's3:ListBucket'
          - 'ec2:DescribeInstances'
          - 'logs:DescribeLogGroups'
          - 'logs:DescribeLogStreams'
          - 'logs:FilterLogEvents'
        effect: Allow
        resource:
          - '*'
      - included_accounts:
          - dev
        action:
          - 's3:*'
          - 'ec2:*'
          - 'logs:*'
          - 'lambda:*'
          - 'dynamodb:*'
          - 'sqs:*'
        effect: Allow
        resource:
          - '*'
      - included_accounts:
          - '*'
        action:
          - 's3:putobjectacl'
        effect: Deny
        resource:
          - '*'
    version: '2012-10-17'
  permissions_boundary:
      managed_policy_arn: arn:aws:iam::aws:policy/ReadOnlyAccess
  policy_name: iambic_managed_policy

4. Run the following command to apply your change:

iambic apply resources/aws/iam/managed_policy/all_accounts/iambic_test_managed_policy.yaml

Visually confirm that the expected managed policy (iambic_managed_policy) exists in the AWS console across your accounts. If something doesn’t look right, please feel free to reach out on Slack.

Creating a permission set and attaching the managed policy

Now we’re ready to create our permission set. IAMbic also lets you define access rules, which  allows you to grant access to specific groups of users and even restrict access to certain accounts. In the example below, we will create access rules that grant access to developers and exclude developer-interns and developer-contractors from accessing the staging account. You may need to remove these access rules, or change them to match groups that exist in your environment.

1. First, let’s create a directory for our permission sets:

mkdir -p resources/aws/identity_center/permission_set/

2. Next, write the template below to the following location in your iambic-templates repository: resources/aws/identity_center/permission_set/iambic_test_permission_set.yaml:

template_type: NOQ::AWS::IdentityCenter::PermissionSet
identifier: iambic_test_permission_set
iambic_managed: enforced
access_rules:
  - groups:
      - developers
  - groups:
      - developer-interns
      - developer-contractors
    excluded_accounts:
      - staging
properties:
  name: iambic_test_permission_set
  description: Permission set using a managed policy with different permissions per account
  customer_managed_policy_references:
    - name: iambic_managed_policy

3. Run the following to apply your change:

iambic apply resources/aws/identity_center/permission_set/iambic_test_permission_set.yaml

4. Visually verify that the permission set has the appropriate permissions on each account.

‍

Integration with CI/CD

In an environment with multiple users, you’d probably want to avoid having your users change permissions in AWS directly like this. IAMbic makes the transition to CI/CD smoother by providing a Docker image and Github workflows that facilitate the expiration of temporary access, ensure Git is eventually consistent with the actual IAM state, and apply approved IAM requests back to the cloud.

Here are the general steps that a user would follow with this workflow:

1. Create a Pull Request with their proposed changes.
2. Get the request approved
3. Instruct IAMbic to apply the changes to the cloud by commenting iambic apply on the pull request. IAMbic will apply the change to the cloud, and once successful, merge it into the Git repository.

The GitHub section of the Getting Started guide provides instructions for this transition.

Conclusion

By following the guidance in this blog post, you have successfully used IAMbic to create Permission Sets with different permissions for each account in your AWS organization using managed policies.

You've also defined access rules for specific user groups and restricted access to certain accounts. This process demonstrates how cloud administrators and security practitioners can use IAMbic to efficiently manage permission sets while ensuring security and consistency across multiple accounts.

You may also be interested in our last blog post, AWS Permission Bouncers: Letting Loose in Dev, Keeping it Tight in Prod, which discusses customizing AWS IAM role permissions across accounts.

Lastly, I would be remiss if I didn’t thank Phil Hadviger, David Behroozi, Michael Woodside, Richard Julian, Rogerio Dias, and Darren Nguyen for their feedback on this blog post. Keep it coming!

Join our Slack Community to nerd out on IAM!