Managing and securing access across multiple AWS accounts and third-party applications can be daunting for organizations. AWS Single Sign-On (SSO) simplifies this process by providing centralized control over user access to AWS resources and integrated applications. AWS SSO ensures that users only need one set of credentials to access all the necessary AWS accounts, reducing security risks and operational overhead.

In this article, we’ll take a detailed look at AWS SSO, explaining how it works, its critical components (such as permission sets), and real-life scenarios where it plays a pivotal role in streamlining access management. We’ll also demonstrate how to automate the entire process using Terraform.

What is AWS Single Sign-On (SSO)?

AWS SSO is a managed service that allows users to access multiple AWS accounts and third-party SaaS applications using a single set of credentials. Instead of maintaining separate credentials for each account or service, AWS SSO integrates with existing identity management systems (e.g., Microsoft Active Directory, SAML-based providers, or AWS SSO Directory) to provide a unified and secure login experience.

Key Features of AWS SSO

• Centralized User Management: Control user access to AWS accounts, groups, and applications from one central location.
• Permission Sets: Reusable permission policies that define what users can and cannot do in AWS accounts.
• Identity Federation: Integration with identity providers such as Microsoft Active Directory (AD) and other SAML 2.0 identity providers.
• Single Sign-On Experience: Once users authenticate, they can access all authorized AWS accounts and applications without needing to re-enter credentials.

Key Components of AWS SSO

To fully grasp how AWS SSO works, it is essential to understand its key components:

1. SSO Instance

An SSO instance is the container where all AWS SSO configurations, such as user assignments, permission sets, and account linkages, reside. Each SSO instance is unique and can be referenced when you automate or configure permissions using tools like Terraform.

2. Identity Source

AWS SSO supports multiple identity sources that manage and authenticate users:

• AWS SSO Directory: A built-in user directory where users are manually created and managed within the AWS SSO console.
• AWS Managed Active Directory: AWS-hosted AD that integrates with AWS SSO, allowing synchronization with your on-premises AD setup.
• SAML 2.0 Identity Providers: For organizations already using SAML-compliant identity providers like Okta, OneLogin, or Azure AD, AWS SSO seamlessly integrates with these providers.

Practical Example: Integrating AWS SSO with Microsoft Active Directory

Imagine a large organization using Microsoft AD for on-premises identity management. AWS SSO can integrate with AD via AWS Directory Service to provide seamless login for AD users. This integration allows AD users to access AWS accounts and resources using their existing AD credentials, without additional authentication steps.

Permission Sets: A Deeper Dive

Permission sets are an essential feature of AWS SSO. These are predefined or custom permission policies that define what users can or cannot do within an AWS account. By applying permission sets to users or groups, AWS SSO simplifies managing permissions for multiple users and accounts.

How Permission Sets Work

Permission sets allow you to decouple users from specific roles. Instead of assigning AWS IAM roles to individual users across accounts, you create permission sets and assign them to users or groups across multiple AWS accounts. This reusable approach reduces management overhead while allowing fine-grained control over permissions.

• AWS-Managed Policies: Permission sets can use AWS-managed policies like AdministratorAccess, ReadOnlyAccess, and more.
• Custom Policies: You can create custom permission sets by writing your own IAM policies for specific access needs.
• Session Duration: When a user logs in via AWS SSO, you can define how long their session lasts. This is useful for controlling the security of sessions.

Practical Scenario: Managing Permissions for Different Departments

Consider a company with multiple AWS accounts for different environments—Development, Staging, and Production. The company has teams of developers, testers, and finance personnel, each requiring different access levels:

• Developers need admin access to the Development account.
• Testers need read-only access to the Staging account.
• Finance personnel need access to billing data in the Production account, but not administrative access.

Using permission sets, you can:

• Assign a DeveloperAccess permission set to the developers that grants AdministratorAccess only in the Development account.
• Assign a ReadOnlyAccess permission set to testers in the Staging account.
• Assign a BillingAccess permission set to the finance team in the Production account.

This approach ensures each team gets only the permissions they need, without over-granting access.

Creating Permission Sets: Step-by-Step

1. Log in to AWS SSO.
2. Navigate to Permission Sets under the AWS SSO console.
3. Click Create Permission Set.
4. Choose whether to base the permission set on an AWS Managed Policy or create a Custom Policy.
5. Define session duration and apply optional settings like MFA.
6. Review and create the permission set.

Practical Scenario: Custom Permission Sets for Cloud Operations Team

Suppose your Cloud Operations team needs to manage AWS resources without having full administrative access. You can create a custom permission set like this:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "ec2:*",
        "s3:*",
        "cloudwatch:*"
      ],
      "Resource": "*"
    },
    {
      "Effect": "Deny",
      "Action": [
        "iam:*",
        "organizations:*"
      ],
      "Resource": "*"
    }
  ]
}

This permission set allows users to manage EC2, S3, and CloudWatch resources, but restricts them from making changes to IAM roles or AWS Organizations.

Assigning Permission Sets to Users and Groups

Once permission sets are created, the next step is to assign them to users or groups. This can be done through the AWS SSO console or automated using tools like Terraform.

Practical Scenario: Group Assignments

In a scenario where a Finance team needs access to billing data across multiple accounts, you can create a FinanceGroup and assign a billing-related permission set to all accounts they manage. This eliminates the need to assign permissions on a user-by-user basis and ensures consistent access control.

1. Create the permission set (BillingReadOnlyAccess).
2. Go to AWS Accounts in the SSO console.
3. Select the accounts where the group needs access.
4. Assign the BillingReadOnlyAccess permission set to the FinanceGroup.

Real-Life Practical Scenarios for AWS SSO

Let's explore a few real-world use cases to understand how AWS SSO works in action:

Scenario 1: Managing Access for a Multi-Account Setup

A tech company has three AWS accounts—Development, Staging, and Production—with distinct teams managing each environment. By using AWS SSO, the company can create a unified access control system where:

• Developers have full access to development resources.
• Testers have read-only access to the staging environment.
• System Administrators have full administrative access to production.

AWS SSO centralizes all access, and team members can use a single login to switch between accounts.

Solution with AWS SSO and Permission Sets:

• Assign the DeveloperAccess permission set to developers.
• Assign the ReadOnlyAccess permission set to testers.
• Assign the AdminAccess permission set to system administrators.

Scenario 2: External Contractors Needing Temporary Access

Suppose an organization hires external contractors to troubleshoot a production issue. Instead of creating new IAM roles and users, you can:

• Assign the contractors an SSO user account.
• Create a TemporaryAccess permission set that grants them access to production resources for 48 hours (using session duration).
• After the work is done, you can easily revoke access without needing to clean up individual IAM roles.

Scenario 3: Managing Access to AWS Accounts with External IdP

A large organization using Okta as their identity provider wants to grant employees access to AWS resources using their existing corporate credentials. AWS SSO integrates with Okta via SAML 2.0, allowing the organization to:

• Synchronize users and groups from Okta.
• Assign permission sets in AWS SSO based on Okta group memberships.

This setup allows users to log in to AWS using Okta credentials and access multiple AWS accounts seamlessly.

Automating AWS SSO with Terraform

Automation is essential when managing access in large-scale environments. Terraform can be used to automate the entire AWS SSO setup, including permission sets, user assignments, and account linkages.

Terraform Code Example

Here’s a step-by-step guide for automating AWS SSO with Terraform:

Step 1: Set up AWS SSO Instance

provider "aws" {
  region = "us-east-1"
}

resource "aws_ssoadmin_instance" "example" {
  identity_store_id = "d-XXXXXXXXXX"
}

In this snippet, the aws_ssoadmin_instance refers to the SSO instance that has been set up, where identity_store_id is the ID for the directory service or SSO directory you are using. The identity store is either AWS SSO's internal directory or an integrated AD or SAML provider.

Step 2: Create Permission Sets

You can now define permission sets within the SSO instance. For example, you might have a permission set for read-only access and another for admin access.

resource "aws_ssoadmin_permission_set" "readonly" {
  name        = "ReadOnlyAccess"
  description = "Provides read-only access to AWS resources"
  sso_instance_arn = aws_ssoadmin_instance.example.arn
  session_duration = "PT1H"

  managed_policies = [
    "arn:aws:iam::aws:policy/ReadOnlyAccess"
  ]
}

resource "aws_ssoadmin_permission_set" "admin" {
  name        = "AdministratorAccess"
  description = "Full access to AWS resources"
  sso_instance_arn = aws_ssoadmin_instance.example.arn
  session_duration = "PT4H"

  managed_policies = [
    "arn:aws:iam::aws:policy/AdministratorAccess"
  ]
}

In this example:

• ReadOnlyAccess permission set grants users view-only privileges across all AWS resources.
• AdministratorAccess permission set gives users full access to all resources.

Step 3: Assign Users or Groups to Permission Sets

Next, you will want to assign these permission sets to specific users or groups across AWS accounts. Here’s how you can assign a permission set to a group:

resource "aws_ssoadmin_account_assignment" "group_readonly_assignment" {
  instance_arn       = aws_ssoadmin_instance.example.arn
  permission_set_arn = aws_ssoadmin_permission_set.readonly.arn
  principal_type     = "GROUP"
  principal_id       = "group-xyz"
  target_id          = "123456789012" # AWS Account ID
  target_type        = "AWS_ACCOUNT"
}

resource "aws_ssoadmin_account_assignment" "group_admin_assignment" {
  instance_arn       = aws_ssoadmin_instance.example.arn
  permission_set_arn = aws_ssoadmin_permission_set.admin.arn
  principal_type     = "GROUP"
  principal_id       = "group-abc"
  target_id          = "987654321098" # AWS Account ID
  target_type        = "AWS_ACCOUNT"
}

In this example:

• group-xyz is a group that will receive read-only access to AWS account 123456789012.
• group-abc is a group that will receive administrator access to AWS account 987654321098.

Step 4: Assign Permission Sets to Multiple AWS Accounts

AWS SSO supports multi-account management, so you can assign permission sets across multiple accounts in one go. Here's an example of how to automate it:

resource "aws_ssoadmin_account_assignment" "multi_account_readonly" {
  for_each = toset(["123456789012", "234567890123", "345678901234"]) # AWS Account IDs
  instance_arn       = aws_ssoadmin_instance.example.arn
  permission_set_arn = aws_ssoadmin_permission_set.readonly.arn
  principal_type     = "GROUP"
  principal_id       = "group-xyz"  # Group ID
  target_id          = each.value
  target_type        = "AWS_ACCOUNT"
}

resource "aws_ssoadmin_account_assignment" "multi_account_admin" {
  for_each = toset(["987654321098", "876543210987", "765432109876"]) # AWS Account IDs
  instance_arn       = aws_ssoadmin_instance.example.arn
  permission_set_arn = aws_ssoadmin_permission_set.admin.arn
  principal_type     = "GROUP"
  principal_id       = "group-abc"  # Group ID
  target_id          = each.value
  target_type        = "AWS_ACCOUNT"
}

Here, the for_each loop is used to assign permission sets across multiple AWS accounts. For instance:

• group-xyz will have ReadOnlyAccess to accounts 123456789012, 234567890123, and 345678901234.
• group-abc will have AdministratorAccess to accounts 987654321098, 876543210987, and 765432109876.

This method simplifies the process of assigning the same permission set across multiple accounts.

Step 5: Managing Users and Groups in SSO

To fully automate the AWS SSO process, you also need to manage users or groups within your identity source, whether it’s AWS SSO Directory, Microsoft Active Directory, or a SAML 2.0 provider like Okta.

Scenario: Adding Users to a Group (for AWS SSO Directory)

If you’re using the AWS SSO Directory, you can create and manage users via the console or by automation tools like the AWS SDK or AWS CLI. Here’s a simplified Terraform code to demonstrate how you can assign users to groups if you're managing users within an internal AWS SSO Directory:

resource "aws_iam_user" "developer1" {
  name = "developer1"
}

resource "aws_iam_group" "developers" {
  name = "DevelopersGroup"
}

resource "aws_iam_group_membership" "add_developer1" {
  group = aws_iam_group.developers.name
  users = [aws_iam_user.developer1.name]
}

This snippet creates an IAM User named developer1, a group called DevelopersGroup, and assigns the user to that group. This setup allows AWS SSO to manage user access based on group memberships.

Putting It All Together: AWS SSO and Permission Sets in Action

Let’s consider a real-life multi-account setup where AWS SSO is utilized:

Scenario: Centralized Access Control for DevOps, Finance, and Contractors

A company has multiple AWS accounts for Development, Staging, and Production environments. The organization needs different levels of access for three teams:

• DevOps Team: Full access to all environments.
• Finance Team: Read-only access to billing information across all environments.
• Contractors: Temporary read-only access to specific resources in the Staging environment.

Solution:

1. DevOps Team:
   • Permission Set: Use AdministratorAccess.
   • Assignment: Assign the DevOpsGroup to the permission set across all accounts.
2. Finance Team:
   • Permission Set: Use a custom BillingReadOnlyAccess permission set that allows only billing data access.
   • Assignment: Assign the FinanceGroup to this permission set across all accounts.
3. Contractors:
   • Permission Set: Use a StagingReadOnlyAccess permission set with session expiration set to 48 hours.
   • Assignment: Assign individual contractors to the Staging environment and remove access after the project ends.

With this approach:

• DevOps engineers use AWS SSO to switch between AWS accounts using a single sign-on experience and manage resources.
• Finance team members get read-only access to billing data without accessing other resources.
• Contractors can work with restricted access, which is automatically revoked after the project ends.

By centralizing access control and using permission sets, AWS SSO enables flexible, scalable, and secure management of user roles and privileges across an organization's AWS environments.

Best Practices for AWS SSO and Permission Sets

To maximize the effectiveness and security of AWS SSO, consider the following best practices:

1. Least Privilege Principle

Always grant the minimum permissions necessary for users to perform their tasks. Avoid over-privileging by carefully selecting managed policies or crafting precise custom policies.

2. Use Groups Over Individual Assignments

Assign permission sets to user groups rather than individual users. This approach simplifies management and ensures consistency in access control.

3. Regularly Review and Audit Permissions

Periodically review permission sets and assignments to ensure they align with current organizational roles and responsibilities. Utilize AWS tools like AWS IAM Access Analyzer to identify overly permissive policies.

4. Integrate with MFA

Enhance security by enforcing Multi-Factor Authentication (MFA) for accessing sensitive permission sets. AWS SSO supports MFA integration, adding an extra layer of protection.

5. Automate with Infrastructure as Code (IaC)

Use tools like Terraform to automate AWS SSO configurations. Automation ensures consistency, reduces manual errors, and facilitates version control of access configurations.

6. Monitor and Log Access Activities

Enable AWS CloudTrail and AWS Config to monitor and log all access and configuration changes. Regularly analyze logs to detect and respond to unauthorized activities.

7. Implement Session Management Policies

Define appropriate session durations and leverage session policies to control how long users can remain authenticated. Shorter sessions reduce the risk of unauthorized access from compromised credentials.

8. Segregate Duties

Implement segregation of duties by ensuring that no single user has excessive permissions that could lead to security breaches. Use distinct permission sets for different roles to enforce this separation.

9. Document and Communicate Access Policies

Maintain comprehensive documentation of permission sets, their intended use cases, and the groups/users they are assigned to. Communicate these policies clearly to all stakeholders to ensure understanding and compliance.

10. Stay Updated with AWS Best Practices

AWS regularly updates its services and best practices. Stay informed about the latest developments in AWS SSO and IAM to continuously enhance your access management strategy.

Conclusion: AWS SSO Simplifies Access Management

AWS Single Sign-On (SSO) offers a powerful and scalable solution to manage access across multiple AWS accounts and external applications. With permission sets, group assignments, and identity provider integration, organizations can efficiently control who has access to what, enhancing security and operational efficiency.

Key Benefits:

• Centralized Access Management: Streamlines user access across multiple AWS accounts from a single interface.
• Granular Permissions: Utilize permission sets to define precise access controls tailored to organizational roles.
• Scalability: Easily manage access for large numbers of users and multiple AWS accounts.
• Security Enhancements: Enforce security best practices like least privilege, MFA, and session management.
• Automation with Terraform: Implement Infrastructure as Code (IaC) to automate and manage AWS SSO configurations consistently.

By leveraging the full capabilities of AWS SSO, organizations can streamline their operations, reduce complexity, and enhance security across their AWS environments.

Happy Clouding!!!