Permission Sets

Permission Sets in AWS IAM Identity Center are a fundamental component of a well-architected AWS Landing Zone. Effective authorization stems from implementing the Principle of Least Privilege (PoLP), granting AWS principals enough permissions to execute their required tasks. Permission Sets facilitate access management across multiple AWS accounts while maintaining robust security practices.

What are Permission Sets?

Permission Sets in AWS IAM Identity Center are collections of permission policies that define what actions AWS principals can perform across AWS accounts. Permission Sets can be assigned to multiple AWS principals across multiple accounts.

Permission Sets can consist of any of the following policy types:

• AWS Managed Policies: Pre-defined permission policies created and maintained by AWS for common job functions.
• Customer Managed Policies: Custom permission policies created and maintained by customers according to their specific use cases.
• Inline Policies: An IAM policy that gets added directly to the permission set but is limited in size.
• Permission Boundaries: Policies that limit the permissions a principal can have, acting as guardrails.

warning

When you create an inline policy and assign your permission set, IAM Identity Center configures the policies in your AWS accounts for you. When you build your permission set with Customer Managed Policies, you must create the policies in your AWS accounts yourself before you assign the permission set.

What are Account Assignments?

An Account Assignment is a concept in AWS Organizations that describes the different access that AWS principals have on specific AWS accounts. Each Account Assignment grants a specific AWS principal authorization to a specific AWS account using a set of defined Permission Sets. They provide a centralized and consistent way for access management across an entire AWS organization.

In a nutshell, Permission Sets define what actions AWS principals can perform, while Account Assignments specify which accounts those Permission Sets apply to.

Policy Types Used in Permission Sets

AWS Managed Policies

AWS managed permission policies are created and maintained by AWS that you can attach to Permission Sets. AWS managed permission policies cover common job functions to simplify permissions management.

Common AWS Managed Policies

Some of the most commonly used AWS managed policies in Permission Sets include:

• AdministratorAccess: Provides full administrator access to all of the AWS services and resources
• PowerUserAccess: Provides full access to AWS services and resources, but does not allow management of Users and groups
• SupportUser: Provides access to create support tickets and troubleshoot issues in an AWS account
• ReadOnlyAccess: Provides read-only access to all of the AWS services and resources
• ViewOnlyAccess: Provides view-only access to AWS resources and metadata, usually for auditing purposes

Choose from a list of AWS managed policies that might be relevant to a job within your organization:

• Billing: Grants permissions for billing and cost management
• DataScientist: Grants permissions to AWS data analytics services
• DatabaseAdministrator: Grants full access permissions to AWS services and actions required to set up and configure AWS database services
• NetworkAdministrator: Grants full access permissions to AWS services and actions required to set up and configure AWS network resources
• SecurityAudit: The security audit template grants access to read security configuration metadata. It is useful for software that audits the configuration of an AWS account
• SupportUser: This policy grants permissions to troubleshoot and resolve issues in an AWS account. This policy also enables the user to contact AWS support to create and manage cases
• SystemAdministrator: Grants full access permissions necessary for resources required for application and development operations

For a complete list of AWS managed policies, please refer to the AWS managed policies documentation.

Customer Managed Policies

Customer managed policies are custom policies that you can use to define permissions tailored to your specific needs and requirements.

• When you create a permission set with a customer managed policy, you must create an IAM policy with the same name and path in each AWS account where the permission set will be assigned
• They are required for specific use cases that do not match exactly the permissions of AWS managed policies allowing for more granular permissions

Inline Policies Management

Inline policies are AWS policies that are directly embedded into Permission Sets, rather than managed as separate resources.

• When you create an inline policy and assign your permission set, IAM Identity Center configures the policies in your AWS accounts for you
• Inline policies are a good addition to existing job function which are missing certain permissions

Permission Boundaries

Permission Boundaries are a security feature in AWS IAM, used to limit the maximum permissions that can be granted to a principal.

• They act as guardrails, restricting the permissions a principal has
• When used in a permission set, they can limit the maximum permissions granted by AWS/Customer Policies and inline policies

Combining Policies to achieve Least Privilege

One of the key advantages of Permission Sets is that they allow the combination of different policy types, in order to granularly implement the Principle of Least Privilege. A guideline to create Permission Sets is the following:

1. When possible, start with AWS managed policies as a baseline
2. Optionally, use inline policies to add additional permissions
3. If needed, use customer managed policies for granular organization-specific permissions
4. At last, apply permission boundaries to set maximum permissions regardless of other attached policies

Choosing an appropriate AWS managed policy and then gradually expanding the permissions granted with inline policies allows you to grant only necessary permissions. Using customer managed policies allows for more very granular permissions but require additional effort to maintain in all AWS accounts. Diligently limiting the permission set access with permission boundaries enables you to achieve Least Privilege by allowing only the necessary permissions needed for a given job function.

An important design decision to achieve effective Least Privilege is granting the needed permissions for the specific job, but also granting these permissions only for the required time. Organizations should consider limiting how long the access will last.

AWS Policy Evaluation of Permission Sets

Understanding how AWS evaluates policies is essential for implementing the Principle of Least Privilege effectively with Permission Sets:

1. By default, all the requests in AWS are implicitly denied (implicit deny)
2. Explicit Allow statements can be used to override the default implicit denies
3. An explicit Deny statement takes precedence over any Allow statements (explicit deny)

When using Permission Sets that include multiple policy types, AWS evaluates them according to these rules. This is important to consider when combining different policy types to achieve the desired access level.

Provisioning Permission Sets

The NTC Identity Center Module makes it easy to define and implement your Permission Sets and Account Assignments across your entire AWS Organization. You can specify all of your Permission Sets and Account Assignments in a single configuration:

module "ntc_identity_center" {
  source = "github.com/nuvibit-terraform-collection/terraform-aws-ntc-identity-center?ref=X.X.X"

    # Permission Sets can be a combination of aws and customer managed policies
    # https://docs.aws.amazon.com/singlesignon/latest/userguide/permissionsetcustom.html
    permission_sets = [
    {
      name                = "FinanceDepartmentAccess"
      description         = "This permission set grants access to the Finance department."
      session_duration    = 2 # Session duration in hours, limit it to the minimum necessary.

      # Inline Policy: Adds specific permissions for managing financial reporting S3 buckets
      inline_policy_json  = jsonencode({
        "Version": "2012-10-17",
        "Statement": [
          {
            "Effect": "Allow",
            "Action": [
              "s3:PutObject",
              "s3:GetObject",
              "s3:DeleteObject",
              "s3:ListBucket"
            ],
            "Resource": [
              "arn:aws:s3:::financial-reports-bucket",
              "arn:aws:s3:::financial-reports-bucket/*"
            ]
          }
        ]
      })

      # AWS Managed Policy: Provides read-only access to billing and cost data
      managed_policies = [
        {
          managed_by  = "aws"
          policy_name = "AWSBillingReadOnlyAccess"
          policy_path = "/"
        },
        {
          # WARNING: this policy needs to already exist in AWS accounts
          managed_by  = "customer"
          policy_name = "FinanceToolsAccess"
          policy_path = "/"
        }
      ]

      # Permission Boundary: Restricts access to sensitive financial resources
      boundary_policy = {
        # WARNING: this policy needs to already exist in AWS accounts
        managed_by  = "customer"
        policy_name = "RestrictAMLResources"
        policy_path = "/"
      }
    }
  ]

  account_assignments = [
    {
      account_name = "aws-1111"
      account_id   = "111111111111"
      permissions = [
        {
          permission_set_name : "FinanceDepartmentAccess"
          groups : ["finops-group"]
          users : []
        },
      ]
    }
  ]

}

For comprehensive implementation details, visit the NTC Identity Center Building Block page.

Best Practices

At Nuvibit we recommend the following best practices when implementing Permission Sets:

• AWS Managed Policies: Start with the predefined and streamlined AWS managed policies where applicable
• Inline Policies: Extend with custom policies to add missing permissions
• Customer Managed Policies: Use customer managed policies only when necessary to meet specific business requirements to avoid managing policies in all AWS accounts yourself.
• Permission Boundaries: Use Permission Boundaries to restrict the authorizations that an AWS Managed Policy provides
• Group Assignments: Assign Permission Sets to groups and not directly to users, when possible
• Principle of Least Privilege: Combine policies strategically to enforce least privilege access, granting only the minimum permissions required and limiting them to the shortest necessary duration
• Regular Review: Periodically audit permissions to ensure they are up to date with the needed permissions and the Least Privilege Principle

Conclusion

Permission Sets are a powerful tool for managing access within an AWS organization. By implementing Permission Sets through the NTC Identity Center Building Block, organizations can establish a standardized, scalable, and consistent approach to authorization to achieve both operational efficiency and compliance with the organization's security policies.

Permission Sets are particularly valuable for security and compliance. The combination of AWS and customer managed policies, inline policies, and permission boundaries allows organizations to achieve precise access control to implement permissions compliant with the Principle of Least Privilege. Furthermore, they facilitate the effective management of a well-architected AWS IAM Identity Center that adheres to frameworks such as ISO 27001, PCI-DSS, or any other industry-specific regulation that your organization needs to comply with.